Network Working Group K. Carlberg
Request for Comments: 4958 G11
Category: Informational July 2007
Network Working Group K. Carlberg
Request for Comments: 4958 G11
Category: Informational July 2007
A Framework for Supporting Emergency Telecommunications Services (ETS) within a Single Administrative Domain
在单一管理领域内支持紧急电信服务（ETS）的框架
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 IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document presents a framework discussing the role of various protocols and mechanisms that could be considered candidates for supporting Emergency Telecommunication Services (ETS) within a single administrative domain. Comments about their potential usage as well as their current deployment are provided to the reader. Specific solutions are not presented.
本文件提供了一个框架，讨论了各种协议和机制的作用，这些协议和机制可被视为在单一管理领域内支持紧急电信服务（ETS）的候选协议和机制。向读者提供有关其潜在用途以及当前部署的评论。没有提出具体的解决办法。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Differences between Single and Inter-Domain ................3
2. Common Practice: Provisioning ...................................4
3. Objective .......................................................5
3.1. Scenarios ..................................................5
4. Topic Areas .....................................................6
4.1. MPLS .......................................................6
4.2. RSVP .......................................................7
4.2.1. Relation to ETS .....................................8
4.3. Policy .....................................................8
4.4. Subnetwork Technologies ....................................9
4.4.1. IEEE 802.1 VLANs ....................................9
4.4.2. IEEE 802.11e QoS ...................................10
4.4.3. Cable Networks .....................................10
4.5. Multicast .................................................11
4.5.1. IP Layer ...........................................12
4.5.2. IEEE 802.1d MAC Bridges ............................12
4.6. Discovery .................................................13
4.7. Differentiated Services (Diffserv) ........................14
5. Security Considerations ........................................14
6. Summary Comments ...............................................15
7. Acknowledgements ...............................................15
8. References .....................................................15
8.1. Normative Reference .......................................15
8.2. Informative References ....................................15
1. Introduction ....................................................3
1.1. Differences between Single and Inter-Domain ................3
2. Common Practice: Provisioning ...................................4
3. Objective .......................................................5
3.1. Scenarios ..................................................5
4. Topic Areas .....................................................6
4.1. MPLS .......................................................6
4.2. RSVP .......................................................7
4.2.1. Relation to ETS .....................................8
4.3. Policy .....................................................8
4.4. Subnetwork Technologies ....................................9
4.4.1. IEEE 802.1 VLANs ....................................9
4.4.2. IEEE 802.11e QoS ...................................10
4.4.3. Cable Networks .....................................10
4.5. Multicast .................................................11
4.5.1. IP Layer ...........................................12
4.5.2. IEEE 802.1d MAC Bridges ............................12
4.6. Discovery .................................................13
4.7. Differentiated Services (Diffserv) ........................14
5. Security Considerations ........................................14
6. Summary Comments ...............................................15
7. Acknowledgements ...............................................15
8. References .....................................................15
8.1. Normative Reference .......................................15
8.2. Informative References ....................................15
This document presents a framework for supporting Emergency Telecommunications Services (ETS) within the scope of a single administrative domain. This narrow scope provides a reference point for considering protocols that could be deployed to support ETS. [rfc4375] is a complementary effort that articulates requirements for a single administrative domain and defines it as "collection of resources under the control of a single administrative authority". We use this other effort as both a starting point and guide for this document.
本文件介绍了在单一管理领域范围内支持紧急电信服务（ETS）的框架。这一狭窄范围为考虑可部署以支持ETS的协议提供了参考点。[rfc4375]是一项补充工作，阐明了单个管理领域的需求，并将其定义为“在单个管理机构的控制下收集资源”。我们将这另一项工作作为本文档的起点和指南。
A different example of a framework document for ETS is [rfc4190], which focused on support for ETS within IP telephony. In this case, the focal point was a particular application whose flows could span multiple autonomous domains. Even though this document uses a somewhat more constrained perspective than [rfc4190], we can still expect some measure of overlap in the areas that are discussed.
ETS框架文件的另一个例子是[rfc4190]，其重点是在IP电话中对ETS的支持。在本例中，焦点是一个特定的应用程序，其流可以跨越多个自治域。尽管本文档使用了比[rfc4190]更受约束的视角，但我们仍然可以预期在所讨论的领域中会有一定程度的重叠。
The progression of our work in the following sections is helped by stating some key differences between the single and inter-domain cases. From a general perspective, one can start by observing the following.
我们在以下各节中的工作进展有助于说明单个领域和跨领域案例之间的一些关键差异。从总体上看，我们可以从观察以下几点开始。
a) Congruent with physical topology of resources, each domain is an authority zone, and there is currently no scalable way to transfer authority between zones.
a) 与资源的物理拓扑一致，每个域都是一个权限区域，目前没有可扩展的方式在区域之间传输权限。
b) Each authority zone is under separate management.
b) 每个管理区都有单独的管理。
c) Authority zones are run by competitors; this acts as further deterrent to transferring authority.
c) 管理区由竞争对手经营；这对移交权力起到了进一步的威慑作用。
As a result of the initial statements in (a) through (c) above, additional observations can be made that distinguish the single and inter-domain cases, as follows.
根据上文（a）至（c）中的初步陈述，可以提出其他意见，区分单一领域和跨领域案例，如下所示。
d) Different policies might be implemented in different administrative domains.
d) 不同的管理域可能会实施不同的策略。
e) There is an absence of any practical method for ingress nodes of a transit domain to authenticate all of the IP network layer packets that have labels indicating a preference or importance.
e) 没有任何实用的方法用于中转域的入口节点对具有指示偏好或重要性的标签的所有IP网络层分组进行认证。
f) Given item (d) above, all current inter-domain QoS mechanisms at the network level generally create easily exploited and significantly painful Denial of Service (DoS) / Distributed Denial of Service (DDoS) attack vectors on the network.
f) 鉴于上述第（d）项，网络级别的所有当前域间QoS机制通常会在网络上创建容易被利用且非常痛苦的拒绝服务（DoS）/分布式拒绝服务（DDoS）攻击向量。
g) A single administrative domain can deploy various mechanisms (e.g., access control lists) into each and every edge device (e.g., ethernet switch or router) to ensure that only authorized end-users (or layer 2 interfaces) are able to emit frames/packets with non-default QoS labels into the network. This is not feasible in the inter-domain case because the inter-domain link contains aggregated flows. In addition, the dissemination of access control lists at the network level is not scalable in the inter-domain case.
g) 单个管理域可以将各种机制（例如，访问控制列表）部署到每个边缘设备（例如，以太网交换机或路由器）中，以确保只有授权的最终用户（或第2层接口）能够向网络发送具有非默认QoS标签的帧/数据包。这在域间情况下不可行，因为域间链路包含聚合流。此外，在域间情况下，访问控制列表在网络级别的分发是不可伸缩的。
h) A single domain can deploy mechanisms into the edge devices to enforce its domain-wide policies -- without having to trust any third party to configure things correctly. This is not possible in the inter-domain case.
h) 单个域可以将机制部署到边缘设备中以强制实施其域范围的策略，而无需信任任何第三方来正确配置。这在域间情况下是不可能的。
While the above is not an all-inclusive set of differences, it does provide some rationale why one may wish to focus efforts in the more constrained scenario of a single administrative domain.
虽然上述差异并非包罗万象，但它确实提供了一些理由，说明为什么人们可能希望将精力集中在单个行政领域的更受限制的场景中。
The IEPREP working group and mailing list have had extensive discussions about over-provisioning. Many of these exchanges have debated the need for QoS mechanisms versus over-provisioning of links.
IEPREP工作组和邮件列表就过度供应进行了广泛讨论。这些交换中的许多都对QoS机制的需要与链路的过度供应进行了辩论。
In reality, most IP network links are provisioned with a percentage of excess capacity beyond that of the average load. The 'shared' resource model together with TCP's congestion avoidance algorithms helps compensate for those cases where spikes or bursts of traffic are experienced by the network.
实际上，大多数IP网络链路都提供了超出平均负载的超额容量百分比。“共享”资源模型以及TCP的拥塞避免算法有助于补偿网络遇到流量峰值或突发的情况。
The thrust of the debate within the IEPREP working group is whether it is always better to over-provision links to such a degree that spikes in load can still be supported with no loss due to congestion. Advocates of this position point to many ISPs in the US that take this approach instead of using QoS mechanisms to honor agreements with their peers or customers. These advocates point to cost effectiveness in comparison to complexity and security issues associated with other approaches.
IEPREP工作组内部辩论的主旨是，是否总是最好将供应链接过度到这样一个程度，即负荷峰值仍然可以得到支持，而不会因拥堵而造成损失。这一立场的倡导者指出，美国许多ISP采用这种方法，而不是使用QoS机制来履行与同行或客户的协议。与其他方法相关的复杂性和安全问题相比，这些倡导者指出了成本效益。
Proponents of QoS mechanisms argue that the relatively low cost of bandwidth enjoyed in the US (particularly, by large ISPs) is not necessarily available throughout the world. Beyond the subject of cost, some domains are comprised of physical networks that support wide disparity in bandwidth capacity -- e.g., attachment points connected to high capacity fiber and lower capacity wireless links.
QoS机制的支持者认为，在美国（特别是大型ISP）所享有的相对较低的带宽成本并不一定在全世界都可用。除了成本问题之外，有些领域还包括支持带宽容量差异很大的物理网络——例如，连接到高容量光纤和低容量无线链路的连接点。
This document does not advocate one of these positions over the other. The author does advocate that network administrators/operators should perform a cost analysis between over-provisioning for spikes versus QoS mechanisms as applied within a domain and its access link to another domain (e.g., a customer and its ISP). This analysis, in addition to examining policies and requirements of the administrative domain, should be the key to deciding how (or if) ETS should be supported within the domain.
本文件不主张这些立场中的一种而不是另一种。作者主张，网络管理员/运营商应在一个域内应用的尖峰过度供应与QoS机制及其与另一个域（例如，客户及其ISP）的访问链路之间进行成本分析。除了检查管理领域的政策和要求外，这种分析应该是决定如何（或是否）在该领域内支持ETS的关键。
If the decision is to rely on over-provisioning, then some of the following sections will have little to no bearing on how ETS is supported within a domain. The exception would be labeling mechanisms used to convey information to other communication architectures (e.g., SIP-to-SS7/ISUP gateways).
如果决定依赖于过度供应，那么以下部分对域内如何支持ETS几乎没有影响。例外情况是用于向其他通信体系结构（例如，SIP-to-SS7/ISUP网关）传递信息的标记机制。
The primary objective is to provide a target measure of service within a domain for flows that have been labeled for ETS. This level may be better than best effort, the best available service that the network (or parts thereof) can offer, or a specific percentage of resource set aside for ETS. [rfc4375] presents a set of requirements in trying to achieve this objective.
主要目标是为已标记为ETS的流提供域内服务的目标度量。这一级别可能比尽力而为、网络（或其部分）能够提供的最佳可用服务或为ETS预留的特定百分比的资源要好。[rfc4375]提出了一系列旨在实现这一目标的要求。
This framework document uses [rfc4375] as a reference point in discussing existing areas of engineering work or protocols that can play a role in supporting ETS within a domain. Discussion of these areas and protocols are not to be confused with expectations that they exist within a given domain. Rather, the subjects discussed in Section 4 below are ones that are recognized as candidates that can exist and could be used to facilitate ETS users or data flows.
本框架文件将[rfc4375]用作讨论现有工程工作领域或协议的参考点，这些工程工作或协议可在支持领域内的ETS方面发挥作用。对这些领域和协议的讨论不应与它们存在于给定领域内的期望相混淆。相反，下文第4节中讨论的主题被认为是可以存在的候选主题，可用于促进ETS用户或数据流。
One of the topics of discussion on the IEPREP mailing list and in the working group meetings is the operating environment of the ETS user. Many variations can be dreamed of with respect to underlying network technologies and applications. Instead of getting lost in hundreds of potential scenarios, we attempt to abstract the scenarios into two simple case examples.
IEPREP邮件列表和工作组会议讨论的主题之一是ETS用户的操作环境。关于底层网络技术和应用程序，可以想象许多变化。我们没有迷失在数百个潜在场景中，而是尝试将场景抽象为两个简单的案例。
(a) A user in their home network attempts to use or leverage any ETS capability within the domain.
(a) 家庭网络中的用户试图使用或利用域内的任何ETS功能。
(b) A user visits a foreign network and attempts to use or leverage any ETS capability within the domain.
(b) 用户访问外部网络并试图使用或利用域内的任何ETS功能。
We borrow the terms "home" and "foreign" network from that used in Mobile IP [rfc3344]. Case (a) is considered the normal and vastly most prevalent scenario in today's Internet. Case (b) above may simply be supported by the Dynamic Host Configuration Protocol (DHCP) [rfc2131], or a static set of addresses, that are assigned to 'visitors' of the network. This effort is predominantly operational in nature and heavily reliant on the management and security policies of that network.
我们借用了移动IP中使用的术语“家庭”和“外国”网络[rfc3344]。案例（a）被认为是当今互联网上最常见的正常情况。上述情况（b）可能仅由动态主机配置协议（DHCP）[rfc2131]或分配给网络“访问者”的静态地址集支持。这项工作主要是操作性的，严重依赖于该网络的管理和安全策略。
A more ambitious way of supporting the mobile user is through the use of the Mobile IP (MIP) protocol. MIP offers a measure of application-transparent mobility as a mobile host moves from one subnetwork to another while keeping the same stable IP address registered at a global anchor point. However, this feature may not always be available or in use. In any case, where it is in use, at least some of the packets destined to and from the mobile host go through the home network.
支持移动用户的一种更为雄心勃勃的方式是通过使用移动IP（MIP）协议。当移动主机从一个子网移动到另一个子网时，MIP提供了应用程序透明移动性的度量，同时保持在全局定位点注册相同的稳定IP地址。但是，此功能可能并不总是可用或正在使用。在任何情况下，在其被使用的地方，至少一些目的地为移动主机和来自移动主机的分组通过家庭网络。
The topic areas presented below are not presented in any particular order or along any specific layering model. They represent capabilities that may be found within an administrative domain. Many are topics of on-going work within the IETF.
下面介绍的主题区域不以任何特定顺序或任何特定分层模型呈现。它们表示可以在管理域中找到的功能。许多是IETF中正在进行的工作主题。
It must be stressed that readers of this document should not expect any of the following to exist within a domain for ETS users. In many cases, while some of the following areas have been standardized and in wide use for several years, others have seen very limited deployment.
必须强调的是，本文件的读者不应期望ETS用户的域中存在以下任何情况。在许多情况下，虽然以下一些领域已经标准化并广泛使用了几年，但其他领域的部署非常有限。
Multiprotocol Label Switching (MPLS) is generally the first protocol that comes to mind when the subject of traffic engineering is brought up. MPLS signaling produces Labeled Switched Paths (LSPs) through a network of Label Switch Routers [rfc3031]. When traffic reaches the ingress boundary of an MPLS domain (which may or may not be congruent with an administrative domain), the packets are classified, labeled, scheduled, and forwarded along an LSP.
多协议标签交换（MPLS）通常是在提出流量工程主题时想到的第一个协议。MPLS信令通过标签交换路由器网络产生标签交换路径（LSP）[rfc3031]。当通信量到达MPLS域的入口边界（其可能与管理域一致，也可能不一致）时，分组被分类、标记、调度并沿着LSP转发。
[rfc3270] describes how MPLS can be used to support Differentiated Services. The RFC discusses the use of the 3-bit EXP (experimental) field to convey the Per Hop Behavior (PHB) to be applied to the packet. As we shall see in later sections, this 3-bit field can be mapped to fields in several other protocols.
[rfc3270]描述了如何使用MPLS来支持差异化服务。RFC讨论了使用3位EXP（实验）字段来传递要应用于数据包的每跳行为（PHB）。我们将在后面的章节中看到，这个3位字段可以映射到其他几个协议中的字段。
The inherent features of classification, scheduling, and labeling are viewed as symbiotic, and therefore, they are often integrated with other protocols and architectures. Examples of this include RSVP and Differentiated Services. Below, we discuss several instances where a given protocol specification or mechanism has been known to be complemented with MPLS. This includes the potential labels that may be associated with ETS. However, we stress that MPLS is only one of several approaches to support traffic engineering. In addition, the complexity of the MPLS protocol and architecture may make it suited only for large domains.
分类、调度和标记的固有特性被视为共生的，因此，它们通常与其他协议和体系结构集成。这方面的例子包括RSVP和差异化服务。下面，我们将讨论几个已知可用MPLS补充的给定协议规范或机制的实例。这包括可能与ETS相关的潜在标签。然而，我们强调MPLS只是支持流量工程的几种方法之一。此外，MPLS协议和体系结构的复杂性可能使其仅适用于大型域。
The original design of RSVP, together with the Integrated Services model, was one of an end-to-end signaling capability to set up a path of reserved resources that spanned networks and administrative domains [rfc2205]. Currently, RSVP has not been widely deployed by network administrators for QoS across domains. Today's limited deployment by network administrators has been mostly constrained to boundaries within a domain, and commonly in conjunction with MPLS signaling. Early deployments of RSVP ran into unanticipated scaling issues; it is not entirely clear how scalable an RSVP approach would be across the Internet.
RSVP的原始设计以及综合服务模型是一种端到端信令能力，用于建立跨网络和管理域的保留资源路径[rfc2205]。目前，网络管理员尚未广泛部署RSVP以实现跨域的QoS。如今，网络管理员的有限部署主要局限于域内的边界，通常与MPLS信令结合使用。RSVP的早期部署遇到了意想不到的扩展问题；目前还不完全清楚RSVP方法在互联网上的可扩展性。
[rfc3209] is one example of how RSVP has evolved to complement efforts that are scoped to operate within a domain. In this case, extensions to RSVP are defined that allow it to establish intra-domain Labeled Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS).
[rfc3209]是RSVP如何发展以补充在域内操作的工作的一个示例。在这种情况下，定义了RSVP的扩展，允许它在多协议标签交换（MPLS）中建立域内标签交换路径（LSP）。
[rfc2750] specifies extensions to RSVP so that it can support generic policy-based admission control. This standard goes beyond the support of the POLICY_DATA object stipulated in [rfc3209], by defining the means of control and enforcement of access and usage policies. While the standard does not advocate a particular policy architecture, the IETF has defined one that can complement [rfc2750] -- we expand on this in Section 4.3 below.
[rfc2750]指定RSVP的扩展，以便它能够支持基于通用策略的准入控制。本标准通过定义访问和使用策略的控制和实施方式，超出了[rfc3209]中规定的策略_数据对象的支持范围。虽然该标准不提倡特定的政策体系结构，但IETF定义了一个可以补充[rfc2750]的体系结构——我们在下面的第4.3节对此进行了扩展。
The ability to reserve resources correlates to an ability to provide preferential service for specifically classified traffic -- the classification being a tuple of 1 or more fields which may or may not include an ETS specific label. In cases where a tuple includes a label that has been defined for ETS usage, the reservation helps ensure that an emergency-related flow will be forwarded towards its destination. Within the scope of this document, this means that RSVP would be used to facilitate the forwarding of traffic within a domain.
保留资源的能力与为特定分类的流量提供优先服务的能力相关——分类是一个由1个或多个字段组成的元组，这些字段可能包括也可能不包括ETS特定的标签。如果元组包含为ETS使用而定义的标签，则保留有助于确保将紧急相关流转发到其目的地。在本文件范围内，这意味着RSVP将用于促进域内流量的转发。
We note that this places an importance on defining a label and an associated field that can be set and/or examined by RSVP-capable nodes.
我们注意到，这非常重视定义标签和相关字段，这些标签和字段可以由支持RSVP的节点设置和/或检查。
Another important observation is that major vendor routers currently constrain their examination of fields for classification to the network and transport layers. This means that application layer labels will mostly likely be ignored by routers/switches.
另一个重要的观察结果是，主要供应商路由器目前将其对分类字段的检查限制在网络和传输层。这意味着路由器/交换机很可能会忽略应用层标签。
The Common Open Policy Service (COPS) protocol [rfc2748] was defined to provide policy control over QoS signaling protocols, such as RSVP. COPS is based on a query/response model in which Policy Enforcement Points (PEPs) interact with Policy Decision Points (i.e., policy servers) to exchange policy information. COPS provides application-level security and can operate over IPsec or TLS. COPS is also a stateful protocol that supports a push model. This means that servers can download new policies or alter existing ones to known clients.
公共开放策略服务（COPS）协议[rfc2748]被定义为对QoS信令协议（如RSVP）提供策略控制。COPS基于查询/响应模型，其中策略执行点（PEP）与策略决策点（即策略服务器）交互以交换策略信息。COPS提供应用程序级安全性，可以通过IPsec或TLS进行操作。COPS也是一种支持推送模型的有状态协议。这意味着服务器可以下载新策略或将现有策略更改为已知客户端。
[rfc2749] articulates the usage of COPS with RSVP. It specifies COPS client types, context objects, and decision objects. Thus, when an RSVP reservation is received by a PEP, the PEP decides whether to accept or reject it based on policy. This policy information can be stored a priori to the reception of the RSVP PATH message, or it can be retrieved on an on-demand basis. A similar course of action could be applied in cases where ETS-labeled control flows are received by the PEP. This of course would require an associated (and new) set of documents that first articulates types of ETS signaling and then specifies its usage with COPS.
[rfc2749]阐述了与RSVP一起使用COP。它指定COPS客户端类型、上下文对象和决策对象。因此，当政治公众人物收到RSVP预约时，政治公众人物根据策略决定是否接受或拒绝该预约。该策略信息可以在接收RSVP PATH消息之前存储，也可以按需检索。如果政治公众人物收到ETS标记的控制流，则可采取类似的措施。当然，这需要一组相关的（和新的）文件，首先阐明ETS信令的类型，然后指定其与COP的使用。
A complementary document to the COPS protocols is COPS Usage for Policy Provisioning (COPS-PR) [rfc3084].
COPS协议的补充文件是COPS策略供应使用（COPS-PR）[rfc3084]。
As a side note, the current lack of deployment by network administrators of RSVP has also played at least an indirect role in the subsequent lack of implementation and deployment of COPS-PR. [rfc3535] is an output from the IAB Network Management Workshop in which the topic of COPS and its current state of deployment was discussed. At the time of that workshop in 2002, COPS-PR was considered a technology/architecture that did not fully meet the needs of network operators. It should also be noted that at the 60th IETF meeting held in San Diego in 2004, COPS was discussed as a candidate protocol that should be declared as historic because of lack of use and concerns about its design. In the future, an altered design of COPS may emerge that addresses the concern of operators, but speculation on that or other possibilities is beyond the scope of this document.
作为旁注，目前RSVP网络管理员缺乏部署也至少间接地影响了后续COPS-PR的实施和部署。[rfc3535]是IAB网络管理研讨会的成果，会上讨论了COPS主题及其当前部署状态。在2002年举办该研讨会时，COPS-PR被认为是一种不能完全满足网络运营商需求的技术/架构。还应注意的是，在2004年圣地亚哥举行的第60次IETF会议上，COPS作为候选协议进行了讨论，由于缺乏使用和对其设计的担忧，应宣布其为历史性协议。将来，可能会出现一种经过修改的COP设计，以解决运营商的问题，但关于这一点或其他可能性的推测超出了本文件的范围。
This is a generalization of work that is considered "under" IP and for the most part outside of the IETF standards body. We discuss some specific topics here because there is a relationship between them and IP in the sense that each physical network interacts at its edge with IP.
这是被视为“在”IP下，并且大部分在IETF标准机构之外的工作的概括。我们在这里讨论一些特定的主题，因为它们与IP之间存在某种关系，即每个物理网络在其边缘与IP进行交互。
The IEEE 802.1q standard defined a tag appended to a Media Access Controller (MAC) frame for support of layer 2 Virtual Local Area Networks (VLANs). This tag has two parts: a VLAN identifier (12 bits) and a Prioritization field of 3 bits. A subsequent standard, IEEE 802.1p, later incorporated into a revision of IEEE 802.1d, defined the Prioritization field of this new tag [iso15802]. It consists of 8 levels of priority, with the highest priority being a value of 7. Vendors may choose a queue per priority codepoint, or aggregate several codepoints to a single queue.
IEEE 802.1q标准定义了附加到媒体访问控制器（MAC）帧的标签，以支持第2层虚拟局域网（VLAN）。此标记有两部分：VLAN标识符（12位）和3位优先级字段。后来的标准IEEE 802.1p（后来并入IEEE 802.1d的修订版）定义了这个新标签的优先级字段[iso15802]。它由8个优先级级别组成，最高优先级为7。供应商可以为每个优先级代码点选择一个队列，或者将多个代码点聚合到一个队列中。
The 3-bit Prioritization field can be easily mapped to the old ToS field of the upper-layer IP header. In turn, these bits can also be mapped to a subset of differentiated codepoints. Bits in the IP header that could be used to support ETS (e.g., specific Diffserv codepoints) can in turn be mapped to the Prioritization bits of 802.1p. This mapping could be accomplished in a one-to-one manner between the 802.1p field and the IP ToS bits, or in an aggregate manner if one considers the entire Diffserv field in the IP header. In either case, because of the scarcity of bits, ETS users should expect that their traffic will be combined or aggregated with the same level of priority as some other types of "important" traffic. In other words, given the existing 3-bit Priority Field for 802.1p, there will not be an exclusive bit value reserved for ETS traffic.
3位优先级字段可以很容易地映射到上层IP报头的旧ToS字段。反过来，这些位也可以映射到一个子集的差异码点。IP报头中可用于支持ETS的位（例如，特定的Diffserv码点）可依次映射到802.1p的优先级位。该映射可以在802.1p字段和IP ToS比特之间以一对一的方式完成，或者如果考虑IP报头中的整个Diffserv字段，则可以以聚合方式完成。在这两种情况下，由于比特的稀缺性，ETS用户应该期望他们的流量将以与某些其他类型的“重要”流量相同的优先级进行组合或聚合。换句话说，考虑到802.1p现有的3位优先级字段，将不会为ETS流量保留排他的位值。
Certain vendors are currently providing mappings between the 802.1p field and the ToS bits. This is in addition to integrating the signaling of RSVP with the low-level inband signaling offered in the Priority field of 802.1p.
某些供应商目前正在提供802.1p字段和ToS位之间的映射。这是除了将RSVP的信令与802.1p的优先级字段中提供的低级别带内信令集成之外的。
It is important to note that the 802.1p standard does not specify the correlation of a layer 2 codepoint to a physical network bandwidth reservation. Instead, this standard provides what has been termed as "best effort QoS". The value of the 802.1p Priority codepoints is realized at the edges: either as the MAC payload is passed to upper layers (like IP), or as it is bridged to other physical networks like Frame Relay. Either of these actions help provide an intra-domain wide propagation of a labeled flow for both layer 2 and layer 3 flows.
需要注意的是，802.1p标准并未规定第2层代码点与物理网络带宽预留的相关性。相反，该标准提供了所谓的“尽力而为的QoS”。802.1p优先级代码点的值是在边缘实现的：当MAC有效载荷传递到上层（如IP）时，或者当它桥接到其他物理网络（如帧中继）时。这些操作中的任何一个都有助于为第2层和第3层流提供标记流的域内传播。
The 802.11e standard is a proposed enhancement that specifies mechanisms to provide QoS to the 802.11 family of protocols for wireless LANs.
802.11e标准是一项拟议的增强功能，它指定了为无线局域网的802.11协议系列提供QoS的机制。
Previously, 802.11 had two modes of operation. One was Distributed Coordination Function (DCF) , which is based on the classic collision detection schema of "listen before sending". A second optional mode is the Point Coordination Function (PCF). The modes splits access time into contention-free and contention-active periods -- transmitting data during the former.
以前，802.11有两种操作模式。一种是分布式协调功能（DCF），它基于“发送前先侦听”的经典冲突检测模式。第二种可选模式是点协调功能（PCF）。这些模式将访问时间分为无争用和争用活动两个阶段——在前者期间传输数据。
The 802.11e standard enhances DCF by adding support for 8 different traffic categories or classifications. Each higher category waits a little less time than the next lower one before it sends its data.
802.11e标准通过增加对8种不同流量类别或分类的支持来增强DCF。在发送数据之前，每个较高类别的等待时间比下一个较低类别的等待时间稍短。
In the case of PCF, a Hybrid Coordination Function has been added that polls stations during contention-free time slots and grants them a specific start time and maximum duration for transmission. This second mode is more complex than enhanced DCF, but the QoS can be more finely tuned to offer specific bandwidth and jitter control. It must be noted that neither enhancement offers a guarantee of service.
在PCF的情况下，添加了混合协调功能，该功能在无争用时隙期间轮询站点，并授予它们特定的开始时间和传输的最大持续时间。第二种模式比增强型DCF更复杂，但QoS可以更精细地调整，以提供特定的带宽和抖动控制。必须注意的是，这两项改进都不能保证服务质量。
The Data Over Cable Service Interface Specification (DOCSIS) is a standard used to facilitate the communication and interaction of the cable subnetwork with upper-layer IP networks [docsis]. Cable subnetworks tend to be asynchronous in terms of data load capacity: typically, 27 M downstream, and anywhere from 320 kb to 10 M upstream (i.e., in the direction of the user towards the Internet).
电缆数据服务接口规范（DOCSIS）是一种标准，用于促进电缆子网与上层IP网络的通信和交互[DOCSIS]。电缆子网在数据负载容量方面往往是异步的：通常为27米的下游，以及320 kb到10米的上游（即用户朝向互联网的方向）。
The evolution of the DOCSIS specification, from 1.0 to 1.1, brought about changes to support a service other than best effort. One of the changes was indirectly added when the 802.1d protocol added the Priority field, which was incorporated within the DOCSIS 1.1 specification. Another change was the ability to perform packet fragmentation of large packets so that Priority-marked packets (i.e., packets marked with non-best effort labels) can be multiplexed in between the fragmented larger packet.
DOCSIS规范从1.0发展到1.1，带来了支持除尽力而为之外的服务的变化。当802.1d协议添加优先级字段时，间接添加了其中一个更改，该字段被合并到DOCSIS 1.1规范中。另一个变化是能够对大数据包执行数据包分段，以便在分段的大数据包之间复用具有优先级标记的数据包（即，具有非尽力而为标签的数据包）。
It's important to note that the DOCSIS specifications do not specify how vendors implement classification, policing, and scheduling of traffic. Hence, operators must rely on mechanisms in Cable Modem Termination Systems (CMTS) and edge routers to leverage indirectly or directly the added specifications of DOCSIS 1.1. As in the case of 802.1p, ETS-labeled traffic would most likely be aggregated with other types of traffic, which implies that an exclusive bit (or set of bits) will not be reserved for ETS users. Policies and other managed configurations will determine the form of the service experienced by ETS labeled traffic.
需要注意的是，DOCSIS规范没有规定供应商如何实现流量的分类、管理和调度。因此，运营商必须依靠电缆调制解调器终端系统（CMT）和边缘路由器中的机制来间接或直接利用DOCSIS 1.1中增加的规范。与802.1p一样，ETS标记的流量很可能与其他类型的流量聚合，这意味着不会为ETS用户保留专用位（或一组位）。策略和其他托管配置将决定ETS标记流量所经历的服务形式。
Traffic engineering and management of ETS labeled flows, including its classification and scheduling at the edges of the DOCSIS cloud, could be accomplished in several ways. A simple schema could be based on non-FIFO queuing mechanisms like class-based weighted fair queuing (or combinations and derivations thereof). The addition of active queue management like Random Early Detection could provide simple mechanisms for dealing with bursty traffic contributing to congestion. A more elaborate scheme for traffic engineering would include the use of MPLS. However, the complexity of MPLS should be taken into consideration before its deployment in networks.
ETS标记流的流量工程和管理，包括DOCSIS云边缘的分类和调度，可以通过多种方式完成。一个简单的模式可以基于非FIFO排队机制，如基于类的加权公平排队（或其组合和派生）。添加主动队列管理（如随机早期检测）可以提供简单的机制来处理导致拥塞的突发流量。一个更复杂的流量工程方案将包括使用MPLS。然而，在将MPLS部署到网络中之前，必须考虑其复杂性。
Network layer multicast has existed for quite a few years. Efforts such as the Mbone (multicast backbone) have provided a form of tunneled multicast that spans domains, but the routing hierarchy of the Mbone can be considered flat and non-congruent with unicast routing. Efforts like the Multicast Source Discovery Protocol [rfc3618] together with the Protocol Independent Multicast - Sparse Mode (PIM-SM) have been used by a small subset of Internet Service Providers to provide forms of inter-domain multicast [rfc4601]. However, network layer multicast has not been accepted as a common production level service by a vast majority of ISPs.
网络层组播已经存在好几年了。诸如Mbone（多播主干网）之类的努力提供了一种跨域的隧道多播形式，但是Mbone的路由层次结构可以被认为是平坦的，与单播路由不一致。互联网服务提供商的一小部分已经使用诸如多播源发现协议[rfc3618]以及协议独立多播-稀疏模式（PIM-SM）的努力来提供域间多播的形式[rfc4601]。然而，网络层组播并没有被绝大多数ISP接受为一种通用的生产级服务。
In contrast, intra-domain multicast in domains has gained more acceptance as an additional network service. Multicast can produce denial-of-service attacks using the any sender model, with the problem made more acute with flood and prune algorithms. Source-
相比之下，域内多播作为一种附加的网络服务得到了更多的认可。多播可以使用任意发送方模型产生拒绝服务攻击，而洪水和剪枝算法使该问题更加严重。来源-
specific multicast [rfc3569], together with access control lists of who is allowed to be a sender, reduces the potential and scope of such attacks.
特定的多播[rfc3569]以及允许谁作为发送者的访问控制列表，降低了此类攻击的可能性和范围。
The value of IP multicast is its efficient use of resources in sending the same datagram to multiple receivers. An extensive discussion on the strengths of and concerns about multicast is outside the scope of this document. However, one can argue that multicast can very naturally complement the push-to-talk feature of land mobile radio (LMR) networks.
IP多播的价值在于它在向多个接收者发送相同的数据报时有效地利用了资源。关于多播的优点和关注点的广泛讨论超出了本文档的范围。然而，有人认为多播可以很自然地补充陆地移动无线电（LMR）网络的按键通话功能。
Push-to-talk is a form of group communication where every user in the "talk group" can participate in the same conversation. LMR is the type of network used by First Responders (e.g., police, firemen, and medical personnel) that are involved in emergencies. Currently, certain vendors and providers are offering push-to-talk service to the general public in addition to First Responders. Some of these systems are operated over IP networks or are interfaced with IP networks to extend the set of users that can communicate with each other. We can consider at least a subset of these systems as either closed IP networks, or domains, since they do not act as transits to other parts of the Internet.
按键通话是一种群组通信形式，“通话组”中的每个用户都可以参与相同的对话。LMR是涉及紧急情况的第一响应者（如警察、消防员和医务人员）使用的网络类型。目前，除了第一响应者之外，某些供应商和提供商还向公众提供一键通服务。其中一些系统通过IP网络运行，或与IP网络连接，以扩展可相互通信的用户集。我们可以将这些系统的至少一个子集看作是封闭的IP网络或域，因为它们不作为因特网的其他部分的转移。
The potential integration of LMR talk groups with IP multicast is an open issue. LMR talk groups are established in a static manner with man-in-the-loop participation in their establishment and teardown. The seamless integration of these talk groups with multicast group addresses is a feature that has not been discussed in open forums.
LMR通话组与IP多播的潜在集成是一个悬而未决的问题。LMR谈话组以静态方式建立，人在回路参与其建立和拆卸。这些通话组与多播组地址的无缝集成是开放论坛中尚未讨论的功能。
The IEEE 802.1d standard specifies fields and capabilities for a number of features. In Section 4.3.2 above, we discussed its use for defining a Prioritization field. The 802.1d standard also covers the topic of filtering MAC layer multicast frames.
IEEE 802.1d标准规定了许多功能的字段和功能。在上面的第4.3.2节中，我们讨论了它用于定义优先级字段。802.1d标准还涵盖了过滤MAC层多播帧的主题。
One of the concerns about multicast is that broadcast storms can arise and generate a denial of service against other users/nodes. Some administrators purposely filter out multicast frames in cases where the subnetwork resource is relatively small (e.g., 802.11 networks). Operational considerations with respect to ETS may wish to consider doing this on an as-needed basis, balancing the conditions of the network with the perceived need for multicast. In cases where filtering out multicast can be activated dynamically, COPS may be a good means of providing consistent domain-wide policy control.
关于多播的一个担忧是，可能会出现广播风暴，并产生针对其他用户/节点的拒绝服务。在子网资源相对较小的情况下（例如802.11网络），一些管理员有意过滤掉多播帧。关于ETS的操作考虑可能希望在需要的基础上考虑这一点，平衡网络的条件与多播的感知需求。在可以动态激活过滤出多播的情况下，COPS可能是提供一致的域范围策略控制的好方法。
If a service is being offered to explicitly support ETS, then it would seem reasonable that discovery of the service may be of benefit. For example, if a domain has a subset of servers that recognize ETS-labeled traffic, then dynamic discovery of where these servers are (or even if they exist) would be more beneficial than relying on statically configured information.
如果提供的服务明确支持ETS，那么发现该服务可能会带来好处似乎是合理的。例如，如果一个域中有一部分服务器可以识别ETS标记的流量，那么动态发现这些服务器的位置（或者即使它们存在）将比依赖静态配置的信息更为有利。
The Service Location Protocol (SLP) [rfc2608] is designed to provide information about the existence, location, and configuration of networked services. In many cases, the name of the host supporting the desired service is needed to be known a priori in order for users to access it. SLP eliminates this requirement by using a descriptive model that identifies the service. Based on this description, SLP then resolves the network address of the service and returns this information to the requester. An interesting design element of SLP is that it assumes that the protocol is run over a collection of nodes that are under the control of a single administrative authority. This model follows the scope of this framework document. However, the scope of SLP may be better suited for parts of an enterprise network versus an entire domain.
服务定位协议（SLP）[rfc2608]旨在提供有关网络服务的存在、位置和配置的信息。在许多情况下，需要事先知道支持所需服务的主机的名称，以便用户访问它。SLP通过使用标识服务的描述性模型消除了这一需求。基于此描述，SLP然后解析服务的网络地址并将此信息返回给请求者。SLP的一个有趣的设计元素是，它假设协议在一个由单个管理机构控制的节点集合上运行。此模型遵循本框架文档的范围。然而，与整个域相比，SLP的范围可能更适合于企业网络的一部分。
Anycasting [rfc1546] is another means of discovering nodes that support a given service. Interdomain anycast addresses, propagated by BGP, represent anycast in a wide scope and have been used by multiple root servers for a while. Anycast can also be realized in a more constrained and limited scope (i.e., solely within a domain or subnet), and as in the case of multicast, it may not be supported.
Anycasting[rfc1546]是发现支持给定服务的节点的另一种方法。由BGP传播的域间选播地址代表范围广泛的选播，并且已经被多个根服务器使用了一段时间。选播还可以在更受约束和限制的范围内实现（即，仅在域或子网内），并且与多播一样，它可能不受支持。
[rfc4291] covers the topic of anycast addresses for IPv6. Unlike SLP, users/applications must know the anycast address associated with the target service. In addition, responses to multiple requests to the anycast address may come from different servers. Lack of response (not due to connectivity problems) correlates to the discovery that a target service is not available. Detailed tradeoffs between this approach and SLP are outside the scope of this framework document.
[rfc4291]介绍了IPv6的选播地址主题。与SLP不同，用户/应用程序必须知道与目标服务关联的选播地址。此外，对选播地址的多个请求的响应可能来自不同的服务器。缺少响应（不是由于连接问题）与发现目标服务不可用相关。此方法和SLP之间的详细权衡超出了本框架文档的范围。
The Dynamic Delegation Discovery System (DDDS) is used to implement a binding of strings to data in order to support dynamically configured delegation systems [rfc3401]. The DDDS functions by mapping some unique string to data stored within a DDDS Database by iteratively applying string transformation rules until a terminal condition is reached. The potential then exists that a client could specify a set of known tags (e.g., RetrieveMail:Pop3) that would identify/discover the appropriate server with which it can communicate.
动态委派发现系统（DDDS）用于实现字符串与数据的绑定，以支持动态配置的委派系统[rfc3401]。DDDS通过迭代应用字符串转换规则将某些唯一字符串映射到DDDS数据库中存储的数据，直到达到终端条件为止。然后，客户机可能会指定一组已知的标记（例如RetrieveMail:Pop3），用于识别/发现与其通信的适当服务器。
There are a number of examples where Diffserv [rfc2474] has been deployed strictly within a domain, with no extension of service to neighboring domains. Various reasons exist for Diffserv not being widely deployed in an inter-domain context, including ones rooted in the complexity and problems in supporting the security requirements for Diffserv codepoints. An extensive discussion on Diffserv deployment is outside the scope of this document.
有许多例子表明，Diffserv[rfc2474]严格部署在一个域中，没有将服务扩展到相邻域。Diffserv没有在域间环境中广泛部署的原因有很多，包括其复杂性和支持Diffserv代码点的安全需求方面的问题。关于Diffserv部署的广泛讨论超出了本文档的范围。
[Baker] presents common examples of various codepoints used for well-known applications. The document does not recommend these associations as being standard or fixed. Rather, the examples in [Baker] provide a reference point for known deployments that can act as a guide for other network administrators.
[Baker]介绍了用于知名应用的各种代码点的常见示例。本文件不建议将这些关联作为标准或固定关联。相反，[Baker]中的示例提供了已知部署的参考点，可作为其他网络管理员的指南。
An argument can be made that Diffserv, with its existing codepoint specifications of Assured Forwarding (AF) and Expedited Forwarding (EF), goes beyond what would be needed to support ETS within a domain. By this we mean that the complexity in terms of maintenance and support of AF or EF may exceed or cause undue burden on the management resources of a domain. Given this possibility, users or network administrators may wish to determine if various queuing mechanisms, like class-based weighted fair queuing, is sufficient to support ETS flows through a domain. Note, as we stated earlier in Section 2, over-provisioning is another option to consider. We assume that if the reader is considering something like Diffserv, then it has been determined that over-provisioning is not a viable option given their individual needs or capabilities.
有人认为，Diffserv及其现有的保证转发（AF）和加速转发（EF）码点规范超出了支持域内ETS所需的范围。这意味着维护和支持AF或EF的复杂性可能超过或对域的管理资源造成不适当的负担。考虑到这种可能性，用户或网络管理员可能希望确定各种排队机制（如基于类的加权公平排队）是否足以支持通过域的ETS流。注意，正如我们在第2节前面所说的，过度配置是另一个需要考虑的选项。我们假设，如果读者正在考虑像Diffserv这样的东西，那么已经确定，考虑到他们的个人需求或能力，过度供应不是一个可行的选择。
Services used to offer better or best available service for a particular set of users (in the case of this document, ETS users) are prime targets for security attacks or simple misuse. Hence, administrators that choose to incorporate additional protocols/services to support ETS are strongly encouraged to consider new policies to address the added potential of security attacks. These policies, and any additional security measures, should be considered independent of any mechanism or equipment that restricts access to the administrative domain.
用于为特定用户（在本文档中为ETS用户）提供更好或最佳可用服务的服务是安全攻击或简单误用的主要目标。因此，强烈建议选择加入额外的协议/服务来支持ETS的管理员考虑新的策略来解决安全攻击的附加潜力。这些策略以及任何其他安全措施应被视为独立于限制访问管理域的任何机制或设备。
Determining how authorization is accomplished is an open issue. Many times the choice is a function of the service that is deployed. One example is source addresses in an access list permitting senders to the multicast group (as described in Section 4.5). Within a single domain environment, cases can be found where network administrators tend to find this approach acceptable. However, other services may
确定如何完成授权是一个悬而未决的问题。很多时候，选择是部署的服务的功能。一个例子是访问列表中的源地址，允许发送者访问多播组（如第4.5节所述）。在单个域环境中，可以发现网络管理员倾向于接受这种方法的情况。但是，其他服务可能会出现问题
require more stringent measures that employ detailed credentials, and possibly multiple levels of access and authentication. Ease of use, deployment, scalability, and susceptibility to security breach all play a role in determining authorization schemas. The potential is that accomplishing this for only a single domain may be easier than at the inter-domain scope, if only in terms of scalability and trust.
要求采取更严格的措施，使用详细的凭据，可能需要多级访问和身份验证。易用性、部署、可扩展性和易受安全漏洞影响都在确定授权模式方面发挥了作用。潜在的可能性是，仅在单个域中实现这一点可能比在域间范围内更容易，如果仅从可伸缩性和信任角度考虑的话。
This document has presented a number of protocols and complementary technologies that can be used to support ETS users. Their selection is dictated by the fact that all or significant portions of the protocols can be operated and controlled within a single administrative domain. It is this reason why other protocols, like those under current development in the Next Steps in Signaling (NSIS) working group, have not been discussed.
本文件介绍了一些可用于支持ETS用户的协议和补充技术。它们的选择取决于这样一个事实，即协议的所有或重要部分都可以在单个管理域内操作和控制。正是由于这个原因，其他协议，如信令（NSIS）工作组下一步中正在开发的协议，没有被讨论。
By listing a variety of efforts in this document, we avoid taking on the role of "king maker" and at the same time indirectly point out that a variety of solutions exist in support of ETS. These solutions may involve QoS, traffic engineering, or simply protection against detrimental conditions (e.g., spikes in traffic load). Again, the choice is up to the reader.
通过在本文件中列出各种努力，我们避免扮演“造王者”的角色，同时间接指出存在各种支持ETS的解决方案。这些解决方案可能涉及QoS、流量工程，或者只是针对有害条件（例如，流量负载峰值）提供保护。同样，选择取决于读者。
Thanks to Ran Atkinson, Scott Bradner, Jon Peterson, and Kimberly King for comments and suggestions on this document.
感谢Ran Atkinson、Scott Bradner、Jon Peterson和Kimberly King对本文档的评论和建议。
[rfc4375] Carlberg, K., "Emergency Telecommunications Services (ETS) Requirements for a Single Administrative Domain", RFC 4375, January 2006.
[rfc4375]Carlberg，K.，“单一管理域的紧急电信服务（ETS）要求”，RFC 4375，2006年1月。
[Baker] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006.
[Baker]Babiarz，J.，Chan，K.，和F.Baker，“区分服务服务类的配置指南”，RFC 45942006年8月。
[docsis] "Data-Over-Cable Service Interface Specifications: Cable Modem to Customer Premise Equipment Interface Specification SP-CMCI-I07-020301", DOCSIS, March 2002, http://www.cablemodem.com.
[docsis]“电缆数据服务接口规范：电缆调制解调器至客户场所设备接口规范SP-CMCI-I07-020301”，docsis，2002年3月，http://www.cablemodem.com.
[iso15802] "Information technology - Telecommunications and
information exchange between systems - Local and
metropolitan area networks - Common specifications - Part
3: Media Access Control (MAC) Bridges: Revision. This is
a revision of ISO/IEC 10038: 1993, 802.1j-1992 and
802.6k-1992. It incorporates P802.11c, P802.1p and
P802.12e." ISO/IEC 15802-3:1998"
[iso15802] "Information technology - Telecommunications and
information exchange between systems - Local and
metropolitan area networks - Common specifications - Part
3: Media Access Control (MAC) Bridges: Revision. This is
a revision of ISO/IEC 10038: 1993, 802.1j-1992 and
802.6k-1992. It incorporates P802.11c, P802.1p and
P802.12e." ISO/IEC 15802-3:1998"
[rfc1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[rfc1546]帕特里奇，C.，门德斯，T.，和W.米利肯，“主持任意广播服务”，RFC15461993年11月。
[rfc2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[rfc2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[rfc2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[rfc2205]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月。
[rfc2474] 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.
[rfc2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[rfc2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[rfc2608]Guttman，E.，Perkins，C.，Veizades，J.，和M.Day，“服务位置协议，版本2”，RFC 26081999年6月。
[rfc2748] Durham, D., Ed., Boyle, J., Cohen, R., Herzog, S., Rajan, R., and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000.
[rfc2748]Durham，D.，Ed.，Boyle，J.，Cohen，R.，Herzog，S.，Rajan，R.，和A.Sastry，“COPS（公共开放政策服务）协议”，RFC 2748，2000年1月。
[rfc2749] Herzog, S., Ed., Boyle, J., Cohen, R., Durham, D., Rajan, R., and A. Sastry, "COPS usage for RSVP", RFC 2749, January 2000.
[rfc2749]Herzog，S.，Ed.，Boyle，J.，Cohen，R.，Durham，D.，Rajan，R.，和A.Sastry，“警察对RSVP的使用”，RFC 2749，2000年1月。
[rfc2750] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.
[rfc2750]Herzog，S.，“策略控制的RSVP扩展”，RFC 2750，2000年1月。
[rfc3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[rfc3031]Rosen，E.，Viswanathan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[rfc3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[rfc3270]Le Faucheur，F.，Wu，L.，Davie，B.，Davari，S.，Vaananen，P.，Krishnan，R.，Cheval，P.，和J.Heinanen，“区分服务的多协议标签交换（MPLS）支持”，RFC 32702002年5月。
[rfc3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[rfc3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[rfc3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[rfc3344]Perkins，C.，Ed.，“IPv4的IP移动支持”，RFC 3344，2002年8月。
[rfc3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001.
[rfc3084]Chan，K.，Seligson，J.，Durham，D.，Gai，S.，McCloghrie，K.，Herzog，S.，Reichmeyer，F.，Yavatkar，R.，和A.Smith，“策略供应的COPS使用（COPS-PR）”，RFC 30842001年3月。
[rfc3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401 October 2002.
[rfc3401]Mealling，M.“动态委托发现系统（DDDS）第一部分：综合DDDS”，RFC 3401，2002年10月。
[rfc3535] Schoenwaelder, J., "Overview of the 2002 IAB Network Management Workshop", RFC 3535, May 2003.
[rfc3535]Schoenwaeld，J.，“2002年IAB网络管理研讨会概述”，RFC 3535，2003年5月。
[rfc3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
[rfc3569]Bhattacharyya，S.，编辑，“源特定多播（SSM）概述”，RFC 3569，2003年7月。
[rfc3618] Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[rfc3618]Fenner，B.，Ed.，和D.Meyer，Ed.，“多播源发现协议（MSDP）”，RFC 3618，2003年10月。
[rfc4190] Carlberg, K., Brown, I., and C. Beard, "Framework for Supporting Emergency Telecommunications Service (ETS) in IP Telephony", RFC 4190, November 2005.
[rfc4190]Carlberg，K.，Brown，I.，和C.Beard，“IP电话中支持紧急电信服务（ETS）的框架”，RFC 41902005年11月。
[rfc4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[rfc4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[rfc4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[rfc4601]Fenner，B.，Handley，M.，Holbrook，H.，和I.Kouvelas，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 46012006年8月。
Author's Address
作者地址
Ken Carlberg G11 123a Versailles Circle Baltimore, MD USA
Ken Carlberg G11 123a美国马里兰州巴尔的摩凡尔赛宫
EMail: carlberg@g11.org.uk
EMail: carlberg@g11.org.uk
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。