Network Working Group H. Schulzrinne
Request for Comments: 3487 Columbia University
Category: Informational February 2003
Network Working Group H. Schulzrinne
Request for Comments: 3487 Columbia University
Category: Informational February 2003
Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP)
会话启动协议（SIP）的资源优先级机制要求
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 Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document summarizes requirements for prioritizing access to circuit-switched network, end system and proxy resources for emergency preparedness communications using the Session Initiation Protocol (SIP).
本文件总结了使用会话启动协议（SIP）对电路交换网络、终端系统和代理资源的访问进行优先级排序的要求，以用于应急准备通信。
Table of Contents
目录
1. Introduction ................................................ 2
2. Terminology ................................................. 3
3. Resources ................................................... 4
4. Network Topologies .......................................... 5
5. Network Models .............................................. 6
6. Relationship to Emergency Call Services ..................... 7
7. SIP Call Routing ............................................ 8
8. Policy and Mechanism ........................................ 8
9. Requirements ................................................ 9
10. Security Requirements ....................................... 12
10.1 Authentication and Authorization ....................... 12
10.2 Confidentiality and Integrity .......................... 13
10.3 Anonymity .............................................. 14
10.4 Denial-of-Service Attacks .............................. 14
11. Security Considerations ..................................... 15
12. Acknowledgements ............................................ 15
13. Normative References ........................................ 15
14. Informative References ...................................... 15
15. Author's Address ............................................ 16
16. Full Copyright Statement .................................... 17
1. Introduction ................................................ 2
2. Terminology ................................................. 3
3. Resources ................................................... 4
4. Network Topologies .......................................... 5
5. Network Models .............................................. 6
6. Relationship to Emergency Call Services ..................... 7
7. SIP Call Routing ............................................ 8
8. Policy and Mechanism ........................................ 8
9. Requirements ................................................ 9
10. Security Requirements ....................................... 12
10.1 Authentication and Authorization ....................... 12
10.2 Confidentiality and Integrity .......................... 13
10.3 Anonymity .............................................. 14
10.4 Denial-of-Service Attacks .............................. 14
11. Security Considerations ..................................... 15
12. Acknowledgements ............................................ 15
13. Normative References ........................................ 15
14. Informative References ...................................... 15
15. Author's Address ............................................ 16
16. Full Copyright Statement .................................... 17
During emergencies, communications resources including telephone circuits, IP bandwidth and gateways between the circuit-switched and IP networks may become congested. Congestion can occur due to heavy usage, loss of resources caused by the natural or man-made disaster and attacks on the network during man-made emergencies. This congestion may make it difficult for persons charged with emergency assistance, recovery or law enforcement to coordinate their efforts. As IP networks become part of converged or hybrid networks along with public and private circuit-switched (telephone) networks, it becomes necessary to ensure that these networks can assist during such emergencies.
在紧急情况下，包括电话电路、IP带宽和电路交换网络与IP网络之间的网关在内的通信资源可能会变得拥挤。由于大量使用、自然或人为灾难造成的资源损失以及人为紧急情况下对网络的攻击，可能会发生拥塞。这种拥挤可能使负责紧急援助、恢复或执法的人员难以协调其工作。随着IP网络与公共和专用电路交换（电话）网络一起成为融合或混合网络的一部分，有必要确保这些网络在此类紧急情况下能够提供帮助。
There are many IP-based services that can assist during emergencies. This memo only covers requirements for real-time communications applications involving the Session Initiation Protocol (SIP) [1], including voice-over-IP, multimedia conferencing and instant messaging/presence.
有许多基于IP的服务可以在紧急情况下提供帮助。本备忘录仅涵盖涉及会话启动协议（SIP）[1]的实时通信应用程序的要求，包括IP语音、多媒体会议和即时消息/状态。
This document takes no position as to which mode of communication is preferred during an emergency, as such discussion appears to be of little practical value. Based on past experience, real-time communications is likely to be an important component of any overall suite of applications, particularly for coordination of emergency-related efforts.
本文件不确定在紧急情况下首选哪种通信方式，因为此类讨论似乎没有什么实际价值。根据过去的经验，实时通信可能是任何一整套应用程序的重要组成部分，特别是在协调与紧急情况有关的工作方面。
As we will describe in detail below, such Session Initiation Protocol (SIP) [1] applications involve at least five different resources that may become scarce and congested during emergencies. In order to improve emergency response, it may become necessary to prioritize access to such resources during periods of emergency-induced resource scarcity. We call this "resource prioritization".
正如我们将在下面详细描述的那样，此类会话发起协议（SIP）[1]应用程序涉及至少五种不同的资源，这些资源在紧急情况下可能变得稀缺和拥挤。为了改进应急反应，可能有必要在紧急情况引起的资源短缺期间优先获得这些资源。我们称之为“资源优先化”。
This document describes requirements rather than possible existing or new protocol features. Although it is scoped to deal with SIP-based applications, this should not be taken to imply that mechanisms have to be SIP protocol features such as header fields, methods or URI parameters.
本文档描述的是需求，而不是可能的现有或新协议功能。虽然它的范围是处理基于SIP的应用程序，但这不应被认为意味着机制必须是SIP协议特性，例如头字段、方法或URI参数。
The document is organized as follows. In Section 2, we explain core technical terms and acronyms that are used throughout the document. Section 3 describes the five types of resources that may be subject to resource prioritization. Section 4 enumerates four network hybrids that determine which of these resources are relevant. Since the design choices may be constrained by the assumptions placed on
该文件的组织如下。在第2节中，我们将解释贯穿整个文档的核心技术术语和首字母缩略词。第3节描述了可能需要进行资源优先级排序的五种资源类型。第4节列举了四种网络混合，以确定哪些资源是相关的。因为设计选择可能会受到假设的约束
the IP network, Section 5 attempts to classify networks into categories according to the restrictions placed on modifications and traffic classes.
IP网络第5节试图根据对修改和通信量类别的限制将网络分类。
Since this is a major source of confusion due to similar names, Section 6 attempts to distinguish emergency call services placed by civilians from the topic of this document.
由于这是由于名称相似而引起混淆的主要原因，第6节试图将平民提供的紧急呼叫服务与本文件的主题区分开来。
Request routing is a core component of SIP, covered in Section 7.
请求路由是SIP的核心组件，将在第7节中介绍。
Providing resource priority entails complex implementation choices, so that a single priority scheme leads to a set of algorithms that manage queues, resource consumption and resource usage of existing calls. Even within a single administrative domain, the combination of mechanisms is likely to vary. Since it will also depend on the interaction of different policies, it appears inappropriate to have SIP applications specify the precise mechanisms. Section 8 discusses the call-by-value (specification of mechanisms) and call-by-reference (invoke labeled policy) distinction.
提供资源优先级需要复杂的实现选择，因此单一优先级方案会产生一组算法，用于管理队列、资源消耗和现有调用的资源使用。即使在单个管理领域内，机制的组合也可能会有所不同。由于它还取决于不同策略的交互，因此让SIP应用程序指定精确的机制似乎是不合适的。第8节讨论了按值调用（机制规范）和按引用调用（调用标记策略）的区别。
Based on these discussions, Section 9 summarizes some general requirements that try to achieve generality and feature-transparency across hybrid networks.
基于这些讨论，第9节总结了一些一般要求，这些要求试图实现混合网络的通用性和特性透明性。
The most challenging component of resource prioritization is likely to be security (Section 10). Without adequate security mechanisms, resource priority may cause more harm than good, so that the section attempts to enumerate some of the specific threats present when resource prioritization is being employed.
资源优先排序最具挑战性的部分可能是安全（第10节）。如果没有适当的安全机制，资源优先可能弊大于利，因此本节试图列举在采用资源优先时存在的一些具体威胁。
CSN: Circuit-switched network, encompassing both private (closed) networks and the public switched telephone network (PSTN).
CSN：电路交换网络，包括专用（封闭）网络和公共交换电话网（PSTN）。
ETS: Emergency telecommunications service, identifying a communications service to be used during large-scale emergencies that allows authorized individuals to communicate. Such communication may reach end points either within a closed network or any endpoint on the CSN or the Internet. The communication service may use voice, video, text or other multimedia streams.
紧急通信服务：紧急通信服务，识别在大规模紧急情况下使用的通信服务，允许授权人员进行通信。这种通信可以到达封闭网络内的端点或CSN或因特网上的任何端点。通信服务可以使用语音、视频、文本或其他多媒体流。
Request: In this document, we define "request" as any SIP request. This includes call setup requests, instant message requests and event notification requests.
请求：在本文档中，我们将“请求”定义为任何SIP请求。这包括呼叫设置请求、即时消息请求和事件通知请求。
Prioritized access to at least five resource types may be useful:
对至少五种资源类型的优先访问可能有用：
Gateway resources: The number of channels (trunks) on a CSN gateway is finite. Resource prioritization may prioritize access to these channels, by priority queuing or preemption.
网关资源：CSN网关上的通道（中继）数量是有限的。资源优先级可以通过优先级队列或抢占来对这些通道的访问进行优先级排序。
CSN resources: Resources in the CSN itself, away from the access gateway, may be congested. This is the domain of traditional resource prioritization mechanisms such as MLPP and GETS, where circuits are granted to ETS communications based on queuing priority or preemption (if allowed by local telecommunication regulatory policy and local administrative procedures). A gateway may also use alternate routing (Section 8) to increase the probability of call completion.
CSN资源：CSN本身中远离接入网关的资源可能会拥挤。这是传统资源优先级机制（如MLPP和GET）的领域，其中电路根据排队优先级或抢占（如果当地电信监管政策和当地管理程序允许）授予ETS通信。网关还可以使用备用路由（第8部分）来增加呼叫完成的概率。
Specifying CSN behavior is beyond the scope of this document, but as noted below, a central requirement is to be able to invoke all such behaviors from an IP endpoint.
指定CSN行为超出了本文档的范围，但如下所述，中心要求是能够从IP端点调用所有此类行为。
IP network resources: SIP may initiate voice and multimedia sessions. In many cases, audio and video streams are inelastic and have tight delay and loss requirements. Under conditions of IP network overload, emergency services applications may not be able to obtain sufficient bandwidth in any network. When there are insufficient network resources for all users and it is not practical to simply add more resources, quality of service management is necessary to solve this problem. This is orthogonal to SIP, out of the scope for SIP, and as such these requirements will be discussed in another document.
IP网络资源：SIP可以启动语音和多媒体会话。在许多情况下，音频和视频流是非弹性的，并且具有严格的延迟和丢失要求。在IP网络过载的情况下，紧急服务应用程序可能无法在任何网络中获得足够的带宽。当所有用户都没有足够的网络资源时，简单地添加更多的资源是不现实的，就需要服务质量管理来解决这个问题。这与SIP正交，超出了SIP的范围，因此这些要求将在另一个文档中讨论。
Bandwidth used for SIP signaling itself may be subject to prioritization.
用于SIP信令本身的带宽可能会受到优先级的限制。
Receiving end system resources: End systems may include automatic call distribution systems (ACDs) or media servers as well as traditional telephone-like devices. Gateways are also end systems, but have been discussed earlier.
接收端系统资源：端系统可能包括自动呼叫分配系统（ACD）或媒体服务器以及传统的类似电话的设备。网关也是终端系统，但前面已经讨论过。
Since the receiving end system can only manage a finite number of sessions, a prioritized call may need to preempt an existing call or indicate to the callee that a high-priority call is waiting. (The precise user agent behavior is beyond the scope of this document and considered a matter of policy and implementation.)
由于接收端系统只能管理有限数量的会话，因此优先呼叫可能需要抢占现有呼叫或向被叫方指示高优先级呼叫正在等待。（准确的用户代理行为超出了本文档的范围，并被视为一个政策和实施问题。）
Such terminating services may be needed to avoid overloading, say, an emergency coordination center. However, other approaches beyond prioritization, e.g., random request dropping by geographic origin, need to be employed if the number of prioritized calls exceeds the terminating capacity. Such approaches are beyond the scope of this memo.
可能需要这种终止服务来避免过载，例如紧急协调中心。然而，如果优先呼叫的数量超过了终止容量，则需要采用除优先排序之外的其他方法，例如，按地理来源随机丢弃请求。这些方法超出了本备忘录的范围。
SIP proxy resources: While SIP proxies often have large request handling capacities, their capacity is likely to be smaller than their access network bandwidth. (This is true in particular since different SIP requests consume vastly different amounts of proxy computational resources, depending on whether they invoke external services, sip-cgi [2] and CPL [3] scripts, etc. Thus, avoiding proxy overload by restricting access bandwidth is likely to lead to inefficient utilization of the proxy.) Therefore, some types of proxies may need to silently drop selected SIP requests under overload, reject requests, with overload indication or provide multiple queues with different drop and scheduling priorities for different types of SIP requests. However, this is strictly an implementation issue and does not appear to influence the protocol requirements nor the on-the-wire protocol. Thus, it is out of scope for the protocol requirements discussion pursued here.
SIP代理资源：虽然SIP代理通常具有较大的请求处理能力，但其容量可能小于其接入网络带宽。（这尤其是真实的，因为不同的SIP请求消耗的代理计算资源量大不相同，这取决于它们是否调用外部服务、SIP cgi[2]和CPL[3]脚本等。因此，通过限制访问带宽来避免代理过载可能会导致代理的低效利用。），某些类型的代理可能需要在过载情况下以静默方式丢弃选定的SIP请求，拒绝具有过载指示的请求，或者为不同类型的SIP请求提供具有不同丢弃和调度优先级的多个队列。但是，这严格地说是一个实现问题，似乎不会影响协议要求或在线协议。因此，这超出了此处讨论的协议要求的范围。
Responses should naturally receive the same treatment as the corresponding request. Responses already have to be securely mapped to requests, so this requirement does not pose a significant burden. Since proxies often do not maintain call state, it is not generally feasible to assign elevated priority to requests originating from a lower-privileged callee back to the higher-privileged caller.
回复自然应得到与相应请求相同的处理。响应已经必须安全地映射到请求，因此此需求不会造成重大负担。由于代理通常不维护调用状态，因此通常不可能将来自较低权限的被调用方的请求的提升优先级分配回较高权限的调用方。
There is no requirement that a single mechanism be used for all five resources.
没有要求对所有五种资源使用单一机制。
We consider four types of combinations of IP and circuit-switched networks.
我们考虑IP和电路交换网络的四种类型的组合。
IP end-to-end: Both request originator and destination are on an IP network, without intervening CSN-IP gateways. Here, any SIP request could be subject to prioritization.
IP端到端：请求发起方和目的地都位于IP网络上，不需要干预CSN-IP网关。在这里，任何SIP请求都可能受到优先级的限制。
IP-to-CSN (IP at the start): The request originator is in the IP network, while the callee is in the CSN. Clearly, this model only applies to SIP-originated phone calls, not generic SIP requests such as those supporting instant messaging services.
IP到CSN（起始IP）：请求发起人位于IP网络中，而被叫方位于CSN中。显然，此模型仅适用于SIP发起的电话呼叫，而不适用于支持即时消息服务的一般SIP请求。
CSN-to-IP (IP at the end): A call originates in the CSN and terminates, via an Internet telephony gateway, in the IP network.
CSN到IP（终端IP）：呼叫在CSN中发起，并通过Internet电话网关在IP网络中终止。
CSN-IP-CSN (IP bridging): This is a concatenation of the two previous ones. It is worth calling out specifically to note that the two CSN sides may use different signaling protocols. Also, the originating CSN endpoint and the gateway to the IP network may not know the nature of the terminating CSN. Thus, encapsulation of originating CSN information is insufficient.
CSN-IP-CSN（IP桥接）：这是前两个的串联。值得特别指出的是，CSN双方可能使用不同的信令协议。此外，起始CSN端点和到IP网络的网关可能不知道终止CSN的性质。因此，原始CSN信息的封装是不够的。
The bridging model (IP-CSN-IP) can be treated as the concatenation of the IP-to-CSN and CSN-to-IP cases.
桥接模型（IP-CSN-IP）可以被视为IP到CSN和CSN到IP案例的串联。
It is worth emphasizing that CSN-to-IP gateways are unlikely to know whether the final destination is in the IP network, the CSN or, via SIP forking, in both.
值得强调的是，CSN-to-IP网关不太可能知道最终目的地是在IP网络中，还是在CSN中，或者通过SIP分叉，在两者中。
These models differ in the type of controllable resources, identified as gateway, CSN, IP network resources, proxy and receiver. Items marked as (x) are beyond the scope of this document.
这些模型在可控资源的类型上有所不同，可识别为网关、CSN、IP网络资源、代理和接收器。标记为（x）的项目超出了本文件的范围。
Topology Gateway CSN IP proxy receiver
_________________________________________________
IP-end-to-end (x) (x) x
IP-to-CSN x x (x) (x) (x)
CSN-to-IP x x (x) (x) x
CSN-IP-CSN x x (x) (x) (x)
Topology Gateway CSN IP proxy receiver
_________________________________________________
IP-end-to-end (x) (x) x
IP-to-CSN x x (x) (x) (x)
CSN-to-IP x x (x) (x) x
CSN-IP-CSN x x (x) (x) (x)
There are at least four IP network models that influence the requirements for resource priority. Each model inherits the restrictions of the model above it.
至少有四种IP网络模型会影响资源优先级的要求。每个模型都继承其上方模型的限制。
Pre-configured for ETS: In a pre-configured network, an ETS application can use any protocol carried in IP packets and modify the behavior of existing protocols. As an example, if an ETS agency owns the IP network, it can add traffic shaping, scheduling or support for a resource reservation protocol to routers.
为ETS预先配置：在预先配置的网络中，ETS应用程序可以使用IP数据包中携带的任何协议，并修改现有协议的行为。例如，如果ETS代理拥有IP网络，它可以向路由器添加流量整形、调度或对资源预留协议的支持。
Transparent: In a transparent network, an ETS application can rely on the network to forward all valid IP packets, however, the ETS application cannot modify network elements. Commercial ISP offer transparent networks as long as they do not filter certain types of packets. Networks employing firewalls, NATs and "transparent" proxies are not transparent. Sometimes, these types of networks are also called common-carrier networks since they carry IP packets without concern as to their content.
透明：在透明网络中，ETS应用程序可以依靠网络转发所有有效的IP数据包，但ETS应用程序不能修改网络元素。商业ISP提供透明网络，只要它们不过滤某些类型的数据包。使用防火墙、NAT和“透明”代理的网络是不透明的。有时，这些类型的网络也被称为公共载波网络，因为它们携带IP分组而不关心其内容。
SIP/RTP transparent: Networks that are SIP/RTP transparent allow users to place and receive SIP calls. The network allows ingress and egress for all valid SIP messages, possibly subject to authentication. Similarly, it allows RTP media streams in both directions. However, it may block, in either inbound or outbound direction, other protocols such as RSVP or it may disallow non-zero DSCPs. There are many degrees of SIP/RTP transparency, e.g., depending on whether firewalls require inspection of SDP content, thus precluding end-to-end encryption of certain SIP message bodies, or whether only outbound calls are allowed. Many firewalled corporate networks and semi-public access networks such as in hotels are likely to fall into this category.
SIP/RTP透明：SIP/RTP透明的网络允许用户放置和接收SIP呼叫。网络允许所有有效的SIP消息进出，可能需要进行身份验证。类似地，它允许RTP媒体流双向传输。然而，它可能在入站或出站方向上阻止其他协议，如RSVP，或者它可能不允许非零DSCP。SIP/RTP的透明度有很多，例如，取决于防火墙是否需要检查SDP内容，从而排除某些SIP消息体的端到端加密，或者是否只允许出站呼叫。许多防火墙企业网络和半公共接入网络（如酒店）可能属于这一类。
Restricted SIP networks: In restricted SIP networks, users may be restricted to particular SIP applications and cannot add SIP protocol elements such as header fields or use SIP methods beyond a prescribed set. It appears likely that 3GPP/3GPP2 networks will fall into this category, at least initially.
受限SIP网络：在受限SIP网络中，用户可能受限于特定的SIP应用程序，并且不能添加SIP协议元素（如标头字段）或使用超出规定集的SIP方法。看来3GPP/3GPP2网络至少在最初可能会属于这一类。
A separate and distinct problem are SIP networks that administratively prohibit or fail to configure access to special access numbers, e.g., the 710 area code used by GETS. Such operational failures are beyond the reach of a protocol specification.
另一个不同的问题是SIP网络，它在管理上禁止或无法配置对特殊访问号码的访问，例如GETS使用的710区号。此类操作故障超出了协议规范的范围。
It appears desirable that ETS users can employ the broadest possible set of networks during an emergency. Thus, it appears preferable that protocol enhancements work at least in SIP/RTP transparent networks and are added explicitly to restricted SIP networks.
在紧急情况下，ETS用户可以使用尽可能广泛的网络似乎是可取的。因此，协议增强至少在SIP/RTP透明网络中起作用，并且显式地添加到受限SIP网络中似乎更可取。
The existing GETS system relies on a transparent network, allowing use from most unmodified telephones, while MLPP systems are typically pre-configured.
现有的GETS系统依赖于透明网络，允许大多数未经修改的电话使用，而MLPP系统通常是预先配置的。
The resource priority mechanisms are used to have selected individuals place calls with elevated priority during times when the network is suffering from a shortage of resources. Generally, calls for emergency help placed by non-officials (e.g., "911" and "112" calls) do not need resource priority under normal circumstances. If such emergency calls are placed during emergency-induced network resource shortages, the call identifier itself is sufficient to identify the emergency nature of the call. Adding an indication of resource priority may be less appropriate, as this would require that all such calls carry this indicator. Also, it opens another attack
资源优先级机制用于让选定的个人在网络资源短缺时以较高的优先级拨打电话。一般来说，非官方人员发出的紧急求助电话（如“911”和“112”电话）在正常情况下不需要资源优先级。如果在由紧急情况引起的网络资源短缺期间拨打此类紧急呼叫，则呼叫标识符本身足以识别呼叫的紧急性质。添加资源优先级指示可能不太合适，因为这将要求所有此类呼叫都带有此指示。此外，它还会引发另一次攻击
mechanism, where non-emergency calls are marked as emergency calls. (If network elements can recognize the request URI as an emergency call, they would not need the resource priority mechanism.)
机制，其中非紧急呼叫被标记为紧急呼叫。（如果网元可以将请求URI识别为紧急呼叫，则不需要资源优先级机制。）
The routing of a SIP request, i.e., the proxies it visits and the UAs it ends up at, may depend on the fact that the SIP request is an ETS request. The set of destinations may be larger or smaller, depending on the SIP request routing policies implemented by proxies. For example, certain gateways may be reserved for ETS use and thus only be reached by labeled SIP requests.
SIP请求的路由，即它访问的代理和它最终到达的UAs，可能取决于SIP请求是ETS请求这一事实。根据代理实现的SIP请求路由策略，目的地集可能更大或更小。例如，某些网关可能保留供ETS使用，因此只能通过标记的SIP请求访问。
Most priority mechanisms can be roughly categorized by whether they:
大多数优先级机制可以大致分类为：
o use a priority queue for resource attempts,
o 对资源尝试使用优先级队列，
o make additional resources available (e.g., via alternate routing (ACR)), or
o 提供额外资源（例如，通过备用路由（ACR）），或
o preempt existing resource users (e.g., calls.)
o 抢占现有资源用户（例如呼叫）
For example, in GETS, alternate routing attempts to use alternate GETS-enabled interexchange carriers (IXC) if it cannot be completed through the first-choice carrier.
例如，在GETS中，如果无法通过首选载波完成，则备用路由尝试使用备用GETS启用的交换载波（IXC）。
Priority mechanisms may also exempt certain calls from network management traffic controls.
优先级机制还可以免除某些呼叫的网络管理流量控制。
The choice between these mechanisms depends on the operational needs and characteristics of the network, e.g., on the number of active requests in the system and the fraction of prioritized calls. Generally, if the number of prioritized calls is small compared to the system capacity and the system capacity is large, it is likely that another call will naturally terminate in short order when a higher-priority call arrives. Thus, it is conceivable that the priority indication can cause preemption in some network entities, while elsewhere it just influences whether requests are queued instead of discarded and what queueing policy is being applied.
这些机制之间的选择取决于网络的操作需求和特征，例如，取决于系统中活动请求的数量和优先呼叫的比例。通常，如果优先呼叫的数量与系统容量相比较小，且系统容量较大，则当更高优先级的呼叫到达时，另一个呼叫很可能会在短时间内自然终止。因此，可以想象，优先级指示会在某些网络实体中导致抢占，而在其他地方，它只会影响请求是否排队而不是丢弃，以及应用了什么排队策略。
Some namespaces may inherently imply a preemption policy, while others may be silent on whether preemption is to be used or not, leaving this to local entity policy.
某些名称空间可能固有地暗示抢占策略，而其他名称空间可能对是否使用抢占保持沉默，将此留给本地实体策略。
Similarly, the precise relationships between labels, e.g., what fraction of capacity is set aside for each priority level, is also a matter of local policy. This is similar to how differentiated services labels are handled.
类似地，标签之间的精确关系，例如，为每个优先级留出多少容量，也是当地政策的问题。这类似于处理差异化服务标签的方式。
In the PSTN and certain private circuit-switched networks, such as those run by military organizations, calls are marked in various ways to indicate priorities. We call this a "priority scheme".
在PSTN和某些专用电路交换网络（如军事组织运营的网络）中，呼叫以各种方式进行标记，以指示优先级。我们称之为“优先计划”。
Below are some requirements for providing a similar feature in a SIP environment; security requirements are discussed in Section 10. We will refer to the feature as a "SIP indication" and to requests carrying such an indication as "labelled requests".
以下是在SIP环境中提供类似功能的一些要求；第10节讨论了安全要求。我们将此功能称为“SIP指示”，并将带有此类指示的请求称为“带标签的请求”。
Note: Not all the following requirements are possible to meet at once. They may represent in some case tradeoffs that must be considered by the designer.
注：并非所有以下要求都可以同时满足。在某些情况下，它们可能代表设计者必须考虑的权衡。
REQ-1: Not specific to one scheme or country: The SIP indication should support existing and future priority schemes. For example, there are currently at least four priority schemes in widespread use: Q.735, also implemented by the U.S. defense telephone network ("DSN" or "Autovon") and NATO, has five levels, the United States GETS (Government Emergency Telecommunications Systems) scheme with implied higher priority and the British Government Telephone Preference Scheme (GTPS) system, which provides three priority levels for receipt of dial tone.
REQ-1：不特定于一个方案或国家：SIP指示应支持现有和未来的优先方案。例如，目前至少有四种优先方案在广泛使用：Q.735，也由美国国防电话网（“DSN”或“Autovon”）和北约实施，有五个级别，美国获得（政府紧急电信系统）具有隐含较高优先级的方案和英国政府电话优惠方案（GTPS）系统，该系统为接收拨号音提供三个优先级。
The SIP indication may support these existing CSN priority schemes through the use of different namespaces.
SIP指示可以通过使用不同的名称空间来支持这些现有的CSN优先级方案。
Private-use namespaces may also be useful for certain applications.
专用名称空间也可能对某些应用程序有用。
REQ-2: Independent of particular network architecture: The SIP indication should work in the widest variety of SIP-based systems. It should not be restricted to particular operators or types of networks, such as wireless networks or protocol profiles and dialects in certain types of networks. The originator of a SIP request cannot be expected to know what kind of circuit-switched technology is used by the destination gateway.
REQ-2：独立于特定的网络架构：SIP指示应在最广泛的基于SIP的系统中工作。它不应局限于特定的运营商或网络类型，例如无线网络或协议配置文件以及某些类型网络中的方言。不能期望SIP请求的发起人知道目标网关使用哪种电路交换技术。
REQ-3: Invisible to network (IP) layer: The SIP indication must be usable in IP networks that are unaware of the enhancement and in SIP/RTP-transparent networks.
REQ-3：网络不可见（IP）层：SIP指示必须在不知道增强的IP网络和SIP/RTP透明网络中可用。
This requirement can be translated to mean that the request has to be a valid SIP request and that out-of-band signaling is not acceptable.
这一要求可以解释为请求必须是有效的SIP请求，并且带外信令是不可接受的。
REQ-4: Mapping of existing schemes: Existing CSN schemes must be translatable to SIP-based systems.
REQ-4：现有方案的映射：现有CSN方案必须可转换为基于SIP的系统。
REQ-5: No loss of information: For the CSN-IP-CSN case, there should be no loss of signaling information caused by translation from CSN signaling SIP and back from SIP to CSN signaling if both circuit-switched networks use the same priority scheme. Loss of information may be unavoidable if the destination CSN uses a different priority scheme from the origin.
REQ-5：无信息丢失：对于CSN-IP-CSN情况，如果两个电路交换网络使用相同的优先级方案，则从CSN信令SIP和从SIP到CSN信令的转换不会导致信令信息丢失。如果目的地CSN使用与源站不同的优先级方案，则信息丢失可能是不可避免的。
One cannot assume that both CSNs are using the same signaling protocol or protocol version, such as ISUP, so that transporting ISUP objects in MIME [4,5] is unlikely to be sufficient.
我们不能假设两个CSN使用相同的信令协议或协议版本，例如ISUP，因此在MIME[4,5]中传输ISUP对象是不够的。
REQ-6: Extensibility: Any naming scheme specified as part of the SIP indication should allow for future expansion. Expanded naming schemes may be needed as resource priority is applied in additional private networks, or if VoIP-specific priority schemes are defined.
REQ-6：可扩展性：作为SIP指示的一部分指定的任何命名方案都应允许将来扩展。当资源优先级应用于其他专用网络时，或者如果定义了特定于VoIP的优先级方案，则可能需要扩展命名方案。
REQ-7: Separation of policy and mechanism: The SIP indication should not describe a particular detailed treatment, as it is likely that this depends on the nature of the resource and local policy. Instead, it should invoke a particular named policy. As an example, instead of specifying that a certain SIP request should be granted queueing priority, not cause preemption, but be restricted to three-minute sessions, the request invokes a certain named policy that may well have those properties in a particular implementation. An IP-to-CSN gateway may need to be aware of the specific actions required for the policy, but the protocol indication itself should not.
REQ-7：策略和机制的分离：SIP指示不应描述特定的详细处理，因为这可能取决于资源和本地策略的性质。相反，它应该调用特定的命名策略。例如，该请求调用特定的命名策略，该策略在特定实现中很可能具有这些属性，而不是指定某个SIP请求应被授予排队优先级，而不是导致抢占，而是被限制为三分钟会话。IP到CSN网关可能需要知道策略所需的特定操作，但协议指示本身不应该知道。
Even in the CSN, the same MLPP indication may result in different behavior for different networks.
即使在CSN中，相同的MLPP指示也可能导致不同网络的不同行为。
REQ-8: Method-neutral: The SIP indication chosen should work for any SIP method, not just, say, INVITE.
REQ-8：方法中立：选择的SIP指示应该适用于任何SIP方法，而不仅仅是INVITE。
REQ-9: Default behavior: Network terminals configured to use a priority scheme may occasionally end up making calls in a network that does not support such a scheme. In those cases, the protocol must support a sensible default behavior that treats the call no worse than a call that did not invoke the priority scheme. Some networks may choose to disallow calls unless they have a suitable
REQ-9：默认行为：配置为使用优先级方案的网络终端有时可能会在不支持这种方案的网络中拨打电话。在这些情况下，协议必须支持合理的默认行为，该行为对待调用的效果不比不调用优先级方案的调用差。一些网络可能会选择不允许呼叫，除非他们有合适的
priority marking and appropriate authentication. This is a matter of local policy.
优先级标记和适当的身份验证。这是一个地方政策问题。
REQ-10: Address-neutral: Any address or URI scheme may be a valid destination and must be usable with the priority scheme. The SIP indication cannot rely on identifying a set of destination addresses or URI schemes for special treatment. This requirement is motivated by existing ETS systems. For example, in GETS and similar systems, the caller can reach any PSTN destination with increased probability of call completion, not just a limited set. (This does not preclude local policy that allows or disallows, say, calls to international numbers for certain users.)
REQ-10：地址中立：任何地址或URI方案都可能是有效的目的地，并且必须与优先级方案一起使用。SIP指示不能依赖于识别一组目标地址或URI方案以进行特殊处理。这一要求受到现有ETS系统的推动。例如，在GET和类似的系统中，呼叫者可以到达任何PSTN目的地，并且呼叫完成的概率增加，而不仅仅是有限的一组。（这并不排除允许或不允许某些用户拨打国际号码的本地政策。）
Some schemes may have an open set of destinations, such as any valid E.164 number or any valid domestic telephone number, while others may only reach a limited set of destinations.
一些方案可能有一组开放的目的地，例如任何有效的E.164号码或任何有效的国内电话号码，而其他方案可能只到达有限的目的地。
REQ-11: Identity-independent: The user identity, such as the From header field in SIP, is insufficient to identify the priority level of the request. The same identity can issue non-prioritized requests as well as prioritized ones, with the range of priorities determined by the job function of the caller. The choice of the priority is made based on human judgement, following a set of general rules that are likely to be applied by analogy rather than precise mapping of each condition. For example, a particular circumstance may be considered similarly grave compared to one which is listed explicitly.
REQ-11：标识独立：用户标识（如SIP中的From头字段）不足以标识请求的优先级。同一身份可以发出非优先级请求，也可以发出优先级请求，优先级范围由调用方的作业功能决定。优先权的选择是基于人类的判断，遵循一套一般规则，这些规则可能通过类比而不是每个条件的精确映射来应用。例如，与明确列出的情况相比，特定情况可能被视为同样严重。
REQ-12: Independent of network location: While some existing CSN schemes restrict the set of priorities based on the line identity, it is recognized that future IP-based schemes should be flexible enough to avoid such reliance. Instead, a combination of authenticated user identity, user choice and policy determines the request treatment.
REQ-12：独立于网络位置：虽然一些现有的CSN方案限制基于线路标识的优先级集，但人们认识到，未来基于IP的方案应足够灵活，以避免这种依赖。相反，经过身份验证的用户身份、用户选择和策略的组合决定了请求的处理方式。
REQ-13: Multiple simultaneous schemes: Some user agents will need to support multiple different priority schemes, as several will remain in use in networks run by different agencies and operators. (Not all user agents will have the means of authorizing callers using different schemes, and thus may be configured at run-time to only recognize certain namespaces.)
REQ-13：多个同时方案：一些用户代理将需要支持多个不同的优先级方案，因为在由不同机构和运营商运行的网络中仍将使用多个优先级方案。（并非所有用户代理都可以使用不同的方案授权呼叫者，因此可能会在运行时配置为仅识别某些名称空间。）
REQ-14: Discovery: A terminal should be able to discover which, if any, priority namespaces are supported by a network element. Discovery may be explicit, where a user agent requests a list of the supported namespaces or it may be implicit, where it attempts to use a particular namespace and is then told that this namespace is not supported. This does not imply that every element has to
REQ-14：发现：终端应该能够发现网元支持的优先级名称空间（如果有）。发现可以是显式的，其中用户代理请求支持的名称空间列表，也可以是隐式的，它尝试使用特定的名称空间，然后被告知不支持该名称空间。这并不意味着每个元素都必须
support the priority scheme. However, entities should be able discover whether a network element supports it or not.
支持优先权计划。但是，实体应该能够发现网元是否支持它。
REQ-15: Testing: It must be possible to test the system outside of emergency conditions, to increase the chances that all elements work during an actual emergency. In particular, critical elements such as indication, authentication, authorization and call routing must be testable. Testing under load is desirable. Thus, it is desirable that the SIP indication is available continuously, not just during emergencies.
REQ-15：测试：必须能够在紧急情况之外测试系统，以增加所有元件在实际紧急情况下工作的可能性。特别是，指示、身份验证、授权和呼叫路由等关键要素必须是可测试的。在负载下测试是可取的。因此，希望SIP指示持续可用，而不仅仅是在紧急情况期间。
REQ-16: 3PCC: The system has to work with SIP third-party call control.
REQ-16:3PCC：系统必须使用SIP第三方呼叫控制。
REQ-17: Proxy-visible: Proxies may want to use the indication to influence request routing (see Section 7) or impose additional authentication requirements.
REQ-17：代理可见：代理可能希望使用指示来影响请求路由（见第7节）或施加额外的身份验证要求。
Any resource priority mechanism can be abused to obtain resources and thus deny service to other users. While the indication itself does not have to provide separate authentication, any SIP request carrying such information has more rigorous authentication requirements than regular requests. Below, we describe authentication and authorization aspects, confidentiality and privacy requirements, protection against denial of service attacks and anonymity requirements. Additional discussion can be found in [6].
任何资源优先级机制都可能被滥用以获取资源，从而拒绝向其他用户提供服务。虽然指示本身不必提供单独的认证，但任何携带此类信息的SIP请求都比常规请求具有更严格的认证要求。下面，我们将介绍身份验证和授权方面、保密性和隐私要求、针对拒绝服务攻击的保护以及匿名性要求。更多讨论见[6]。
SEC-1: More rigorous: Prioritized access to network and end system resources enumerated in Section 3 imposes particularly stringent requirements on authentication and authorization mechanisms since access to prioritized resources may impact overall system stability and performance, not just result in theft of, say, a single phone call.
第1节：更严格：第3节中列举的对网络和终端系统资源的优先访问对身份验证和授权机制提出了特别严格的要求，因为对优先资源的访问可能会影响整个系统的稳定性和性能，而不仅仅会导致（比如）一个电话被盗。
The authentication and authorization requirements for ETS calls are, in particular, much stronger than for emergency calls (112, 911), where wide access is the design objective, sacrificing caller identification if necessary.
特别是，ETS呼叫的认证和授权要求比紧急呼叫（112911）强得多，紧急呼叫的设计目标是广泛接入，必要时牺牲呼叫者识别。
SEC-2: Attack protection: Under certain emergency conditions, the network infrastructure, including its authentication and authorization mechanism, may be under attack. Thus, authentication and authorization must be able to survive such attacks and defend the resources against these attacks.
第2节：攻击防护：在某些紧急情况下，网络基础设施（包括其身份验证和授权机制）可能受到攻击。因此，身份验证和授权必须能够经受住此类攻击，并保护资源免受这些攻击。
Mechanisms to delegate authentication and to authenticate as early as possible are required. In particular, the number of packets and the amount of other resources such as computation or storage that an unauthorized user can consume needs to be minimized.
需要委派身份验证和尽早进行身份验证的机制。特别地，需要最小化未经授权的用户可以使用的数据包的数量和诸如计算或存储之类的其他资源的量。
Unauthorized users must not be able to block CSN resources, as they are likely to be more scarce than packet resources. This implies that authentication and authorization must take place on the IP network side rather than using, say, a CSN circuit to authenticate the caller via a DTMF sequence.
未经授权的用户不能阻止CSN资源，因为它们可能比数据包资源更稀缺。这意味着身份验证和授权必须在IP网络侧进行，而不是使用（比如）CSN电路通过DTMF序列对呼叫者进行身份验证。
Given the urgency during emergency events, normal statistical fraud detection may be less effective, thus placing a premium on reliable authentication.
考虑到紧急事件期间的紧迫性，正常的统计欺诈检测可能不太有效，因此需要重视可靠的身份验证。
SIP nodes should be able to independently verify the authorization of requests to receive prioritized service and not rely on transitive trust within the network.
SIP节点应该能够独立地验证请求的授权以接收优先服务，而不依赖于网络内的可传递信任。
SEC-3: Independent of mechanism: Any indication of the resource priority must be independent of the authentication mechanism, since end systems will impose different constraints on the applicable authentication mechanisms. For example, some end systems may only allow user input via a 12-digit keypad, while others may have the ability to acquire biometrics or read smartcards.
第3节：独立于机制：资源优先级的任何指示必须独立于认证机制，因为终端系统将对适用的认证机制施加不同的约束。例如，一些终端系统可能只允许用户通过12位数字键盘输入，而其他终端系统可能具有获取生物特征或读取智能卡的能力。
SEC-4: Non-trusted end systems: Since ETS users may use devices that are not their own, systems should support authentication mechanisms that do not require the user to reveal her secret, such as a PIN or password, to the device.
第4节：不受信任的终端系统：由于ETS用户可能使用非他们自己的设备，因此系统应支持不要求用户向设备泄露其秘密（如PIN或密码）的身份验证机制。
SEC-5: Replay: The authentication mechanisms must be resistant to replay attacks.
第5节：重播：身份验证机制必须抵抗重播攻击。
SEC-6: Cut-and-paste: The authentication mechanisms must be resistant to cut-and-paste attacks.
第6节：剪切粘贴：身份验证机制必须能够抵抗剪切粘贴攻击。
SEC-7: Bid-down: The authentication mechanisms must be resistant to bid down attacks.
第7节：降级：身份验证机制必须能够抵抗降级攻击。
SEC-8: Confidentiality: All aspects of ETS are likely to be sensitive and should be protected from unlawful intercept and alteration. In particular, requirements for protecting the confidentiality of communications relationships may be higher than for normal commercial service. For SIP, the To, From,
第8节：保密性：ETS的所有方面都可能是敏感的，应受到保护，防止非法拦截和篡改。特别是，保护通信关系机密性的要求可能高于正常商业服务的要求。对于SIP，收件人，发件人，
Organization, Subject, Priority and Via header fields are examples of particularly sensitive information. Callers may be willing to sacrifice confidentiality if the only alternative is abandoning the call attempt.
组织、主题、优先级和Via标题字段是特别敏感信息的示例。如果唯一的选择是放弃呼叫尝试，那么呼叫者可能愿意牺牲保密性。
Unauthorized users must not be able to discern that a particular request is using a resource priority mechanism, as that may reveal sensitive information about the nature of the request to the attacker. Information not required for request routing should be protected end-to-end from intermediate SIP nodes.
未经授权的用户不能识别特定请求正在使用资源优先级机制，因为这可能会向攻击者透露有关请求性质的敏感信息。请求路由不需要的信息应该受到来自中间SIP节点的端到端保护。
The act of authentication, e.g., by contacting a particular server, itself may reveal that a user is requesting prioritized service.
身份验证行为（例如，通过联系特定服务器）本身可能表明用户正在请求优先服务。
SIP allows protection of header fields not used for request routing via S/MIME, while hop-by-hop channel confidentiality can be provided by TLS or IPsec.
SIP允许通过S/MIME保护不用于请求路由的报头字段，而逐跳通道机密性可由TLS或IPsec提供。
SEC-9: Anonymity: Some users may wish to remain anonymous to the request destination. For the reasons noted earlier, users have to authenticate themselves towards the network carrying the request. The authentication may be based on capabilities and noms, not necessarily their civil name.
第9节：匿名性：一些用户可能希望对请求目的地保持匿名。出于前面提到的原因，用户必须向承载请求的网络进行身份验证。认证可以基于功能和名称，而不一定基于其民用名称。
Clearly, they may remain anonymous towards the request destination, using the network-asserted identity and general privacy mechanisms [7,8].
显然，他们可以使用网络声明的身份和一般隐私机制对请求目的地保持匿名[7,8]。
SEC-10: Denial-of-service: ETS systems are likely to be subject to deliberate denial-of-service attacks during certain types of emergencies. DOS attacks may be launched on the network itself as well as its authentication and authorization mechanism.
第10节：拒绝服务：在某些类型的紧急情况下，ETS系统可能会受到故意的拒绝服务攻击。DOS攻击可能会在网络本身及其身份验证和授权机制上发起。
SEC-11: Minimize resource use by unauthorized users: Systems should minimize the amount of state, computation and network resources that an unauthorized user can command.
第11节：最小化未授权用户的资源使用：系统应最小化未授权用户可以命令的状态、计算和网络资源量。
SEC-12: Avoid amplification: The system must not amplify attacks by causing the transmission of more than one packet or SIP request to a network address whose reachability has not been verified.
第12节：避免放大：系统不得通过将多个数据包或SIP请求传输到未验证其可达性的网络地址来放大攻击。
Section 10 discusses the security issues related to priority indication for SIP in detail and derives requirements for the SIP indicator. As discussed in Section 6, identification of priority service should avoid multiple concurrent mechanisms, to avoid allowing attackers to exploit inconsistent labeling.
第10节详细讨论了与SIP优先级指示相关的安全问题，并导出了SIP指示器的要求。如第6节所述，优先级服务的标识应避免多个并发机制，以避免攻击者利用不一致的标记进行攻击。
Ran Atkinson, Fred Baker, Scott Bradner, Ian Brown, Ken Carlberg, Janet Gunn, Kimberly King, Rohan Mahy and James Polk provided helpful comments.
Ran Atkinson、Fred Baker、Scott Bradner、Ian Brown、Ken Carlberg、Janet Gunn、Kimberly King、Rohan Mahy和James Polk提供了有益的评论。
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[1] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[2] Lennox, J., Schulzrinne, H. and J. Rosenberg, "Common Gateway Interface for SIP", RFC 3050, January 2001.
[2] Lennox，J.，Schulzrinne，H.和J.Rosenberg，“SIP的公共网关接口”，RFC 3050，2001年1月。
[3] Lennox J. and H. Schulzrinne, "CPL: A language for user control of internet telephony services", Work in Progress.
[3] Lennox J.和H.Schulzrinne，“CPL：互联网电话服务的用户控制语言”，正在进行中。
[4] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG objects", RFC 3204, December 2001.
[4] Zimmerer，E.，Peterson，J.，Vemuri，A.，Ong，L.，Audet，F.，Watson，M.和M.Zonoun，“ISUP和QSIG对象的MIME媒体类型”，RFC 32042001年12月。
[5] Vemuri, A. and J. Peterson, "Session Initiation Protocol for Telephones (SIP-T): (SIP-T)", BCP 63, RFC 3372, September 2002.
[5] Vemuri，A.和J.Peterson，“电话会话启动协议（SIP-T）：（SIP-T）”，BCP 63，RFC 3372，2002年9月。
[6] Brown, I., "A security framework for emergency communications", Work in Progress.
[6] 布朗，I.，“紧急通信安全框架”，正在进行中。
[7] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[7] Peterson，J.，“会话启动协议（SIP）的隐私机制”，RFC3323，2002年11月。
[8] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002.
[8] 沃森，M.，“网络断言身份的短期要求”，RFC 33242002年11月。
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA
美国纽约州纽约市阿姆斯特丹大道1214号哥伦比亚大学计算机科学系
EMail: schulzrinne@cs.columbia.edu
EMail: schulzrinne@cs.columbia.edu
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。