Network Working Group K. Carlberg
Request for Comments: 4375 G11
Category: Informational January 2006
Network Working Group K. Carlberg
Request for Comments: 4375 G11
Category: Informational January 2006
Emergency Telecommunications Services (ETS) Requirements for 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 Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document presents a list of requirements in support of Emergency Telecommunications Service (ETS) within a single administrative domain. This document focuses on a specific set of administrative constraints and scope. Solutions to these requirements are not presented in this document.
本文件列出了在单一管理领域内支持紧急电信服务（ETS）的要求清单。本文件侧重于一组特定的管理约束和范围。本文件未提供这些要求的解决方案。
The objective of this document is to define a set of requirements that support ETS within a single domain. There have been a number of discussions in the IEPREP mailing list, as well as working group meetings, that have questioned the utility of a given mechanism to support ETS. Many have advocated over-provisioning, while others have favored specific schemas to provide a quantifiable measure of service. One constant in these discussions is that the administrative control of the resources plays a significant role in the effectiveness of any proposed solution. Specifically, if one administers a set of resources, a wide variety of approaches can be deployed upon that set. However, once the approach crosses an administrative boundary, its effectiveness comes into question, and at a minimum requires cooperation and trust from other administrative domains. To avoid this question, we constrain our scenario to the resources within a single domain.
本文件的目的是定义一组在单个领域内支持ETS的要求。IEPREP邮件列表中的许多讨论以及工作组会议都对特定机制支持ETS的效用提出了质疑。许多人主张过度配置，而其他人则倾向于使用特定的模式来提供可量化的服务度量。在这些讨论中，一个不变的事实是，对资源的行政控制在任何拟议解决方案的有效性方面发挥着重要作用。具体来说，如果一个人管理一组资源，那么可以在该组资源上部署多种方法。然而，一旦该方法跨越行政边界，其有效性就会受到质疑，至少需要其他行政领域的合作和信任。为了避免这个问题，我们将场景限制为单个域中的资源。
The following provides an explanation of some key terms used in this document.
下文对本文件中使用的一些关键术语进行了解释。
Resource: A resource can be a viewed from the general level as IP nodes such as a router or host as well as the physical media (e.g., fiber) used to connect them. A host can also be referred to in more specific terms as a client, server, or proxy. Resources can also be viewed more specifically in terms of the elements within a node (e.g., CPU, buffer, memory). However, this document shall focus its attention at the node level.
资源：资源可以从一般级别查看，如路由器或主机等IP节点以及用于连接它们的物理介质（如光纤）。主机也可以用更具体的术语称为客户机、服务器或代理。还可以根据节点内的元素（例如CPU、缓冲区、内存）更具体地查看资源。但是，本文件应将注意力集中在节点级别。
Domain: This term has been used in many ways. We constrain its usage in this document to the perspective of the network layer, and view it as being synonymous with an administrative domain. A domain may span large geographic regions and may consist of many types of physical subnetworks.
领域：这个术语已被用在许多方面。我们将其在本文档中的使用限制在网络层的角度，并将其视为管理域的同义词。域可以跨越较大的地理区域，并且可以由许多类型的物理子网络组成。
Administrative Domain: The collection of resources under the control of a single administrative authority. This authority establishes the design and operation of a set of resources (i.e., the network).
管理域：在单个管理权限控制下的资源集合。该机构建立了一套资源（即网络）的设计和运行。
Transit Domain: This is an administrative domain used to forward traffic from one domain to another. An Internet Service Provider (ISP) is an example of a transit domain.
传输域：这是一个管理域，用于将流量从一个域转发到另一个域。Internet服务提供商（ISP）就是传输域的一个例子。
Stub Domain: This is an administrative domain that is either the source or the destination of a flow of IP packets. As a general rule, it does not forward traffic that is destined for other domains. The odd exception to this statement is the case of Mobile IP and its use of "dog-leg" routing to visiting hosts located in foreign networks. An enterprise network is an example of a stub domain.
存根域：这是一个管理域，它是IP数据包流的源或目标。一般来说，它不会转发发送到其他域的流量。这种说法的一个奇怪的例外是移动IP及其使用“狗腿”路由到位于外国网络的访问主机的情况。企业网络是存根域的一个示例。
A list of general requirements for support of ETS is presented in [RFC3689]. The document articulates requirements when considering the broad case of supporting ETS over the Internet. Since that document is not constrained to specific applications, administrative boundaries, or scenarios, the requirements contained within it tend to be quite general in their description and scope. This follows the philosophy behind its inception in that the general requirements are meant to be a baseline followed (if necessary) by more specific requirements that pertain to a more narrow scope.
[RFC3689]中列出了ETS支持的一般要求清单。在考虑通过互联网支持ETS的广泛情况时，本文件明确了要求。由于该文档不局限于特定的应用程序、管理边界或场景，因此其中包含的需求在其描述和范围上往往非常一般。这遵循了其开始时的理念，即一般需求是一个基线（如有必要），由涉及更窄范围的更具体需求遵循。
The requirements presented below in Section 3 are representative of the more narrow scope of a single administrative domain. As in the case of [RFC3689], the requirements articulated in this document represent aspects to be taken into consideration when solutions are being designed, specified, and deployed. Key words such as "MUST",
下文第3节中提出的要求代表了单一行政领域更狭窄的范围。与[RFC3689]一样，本文件中阐述的要求代表了在设计、指定和部署解决方案时需要考虑的方面。关键词如“必须”，
"MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
IETF standards that cover the resources within an administrative domain are within the scope of this document. This includes gateways, routers, servers, etc., that are located and administered within the domain. This document also does not restrict itself to a specific type of application such as Voice over IP.
涵盖管理域内资源的IETF标准在本文件范围内。这包括位于域内并在域内进行管理的网关、路由器、服务器等。本文档也不局限于特定类型的应用程序，如IP语音。
Quality of Service (QoS) mechanisms are also within the scope of this document. These mechanisms may reside at the application, transport, or IP network layer. While QoS mechanisms may exist at the link/physical layer, this document only considers potential mappings of labels or code points.
服务质量（QoS）机制也在本文档的范围内。这些机制可能位于应用程序、传输或IP网络层。虽然QoS机制可能存在于链路/物理层，但本文档仅考虑标签或代码点的潜在映射。
Finally, since this document focuses on a single administrative domain, we do not make any further distinction between transit and stub domains within this document.
最后，由于本文档只关注一个管理域，因此在本文档中，我们不进一步区分传输域和存根域。
Resources owned or operated by other administrative authorities are outside the scope of this document. One example is a SIP server that operates in other domains. Another example is an access link connecting the stub domain and its provider. Controlling only 1/2 of a link (the egress traffic from the stub) is considered insufficient for including inter-domain access links as a subject for this document.
其他管理机构拥有或运营的资源不在本文件范围内。一个例子是在其他域中运行的SIP服务器。另一个示例是连接存根域及其提供程序的访问链接。仅控制1/2的链路（存根的出口流量）被认为不足以将域间访问链路作为本文档的主题。
It must be understood that all of the following requirements pertain to mechanisms chosen by a domain's administrative authority to specifically support ETS. If that authority chooses not to support ETS or if these mechanisms exist within the domain exclusively for a different purpose, then the associated requirement does not apply.
必须理解的是，以下所有要求都与域管理机构选择的专门支持ETS的机制有关。如果该机构选择不支持ETS，或者如果该领域内存在专门用于不同目的的这些机制，则相关要求不适用。
Application or transport layer label mechanisms used for ETS MUST be extensible such that they can support more than one label. These mechanism MUST avoid a single off/on type of label (e.g., a single bit). In addition, designers of such a mechanism MUST assume that there may be more than one set of ETS users.
用于ETS的应用程序或传输层标签机制必须是可扩展的，以便它们能够支持多个标签。这些机制必须避免单个关闭/打开类型的标签（例如，单个位）。此外，这种机制的设计者必须假设可能有一组以上的ETS用户。
Network layer label mechanisms used for ETS SHOULD be extensible such that they can support more than one label. We make this distinction in requirements because there may be fewer bits (a smaller field) available at the network layer than in the transport or application layer.
用于ETS的网络层标签机制应具有可扩展性，以便支持多个标签。我们在需求中进行这种区分是因为网络层的可用位（较小的字段）可能比传输层或应用层的可用位少。
Proxies MAY set ETS labels on behalf of the source of a flow. This may involve removing labels that have been set by upstream node(s).
代理可以代表流的源设置ETS标签。这可能涉及删除上游节点设置的标签。
If proxies take such action, then the security measures discussed in [RFC3689] MUST be considered. More information about security in the single-domain context is found below in Section 5.
如果代理采取此类行动，则必须考虑[RFC3689]中讨论的安全措施。有关单域上下文中的安全性的更多信息，请参见下面的第5节。
[RFC3689] defines a label as an identifier, and the set of characteristics associated with the label as policy. However, QoS in the traditional sense of delay or bandwidth is not automatically bound to a label. MPLS [RFC3031] is an example of a labeling mechanism that can provide specific QoS or simply traffic engineering of labeled flows.
[RFC3689]将标签定义为标识符，将与标签关联的特征集定义为策略。然而，传统意义上的延迟或带宽的QoS不会自动绑定到标签。MPLS[RFC3031]是标签机制的一个示例，它可以提供特定的QoS或简单地对标签流进行流量工程。
In the context of ETS, QoS mechanisms, at either the network or application layer, SHOULD be used when networks cannot be over-provisioned to satisfy high bursts of traffic load. Examples can involve bridging fiber networks to wireless subnetworks, or remote subnetworks connected over expensive bandwidth-constrained wide area links.
在ETS环境中，当网络不能过度配置以满足高突发流量负载时，应使用网络或应用层的QoS机制。示例包括将光纤网络桥接到无线子网，或通过昂贵的带宽受限广域链路连接的远程子网。
Note well. Over-provisioning is a normal cost-effective practice amongst network administrators/engineers. The amount of over-provisioning can be a topic of debate. More in-depth discussion on this topic is presented in the companion Framework document [FRAME].
注意。在网络管理员/工程师中，过度资源调配是一种正常的经济高效的做法。过度供应的数量可能是一个有争议的话题。关于这一主题的更深入讨论将在配套的框架文件[FRAME]中介绍。
Regarding existing IETF-specified applications, augmentations in the form of labeling mechanisms to support ETS MUST NOT adversely affect its legacy usage by non-ETS users. With respect to future applications, such labeling mechanisms SHOULD allow the application to support a "normal" (non-emergency) condition.
对于现有的IETF指定应用程序，以标签机制形式支持ETS的增强不得对非ETS用户的传统使用产生不利影响。对于未来的应用，此类标记机制应允许应用程序支持“正常”（非紧急）条件。
Policy MUST be used to determine the percentage of resources of a mechanism used to support the various (ETS and non-ETS) users. Under certain conditions, this percentage MAY reach 100% for a specific set of users. However, we recommend that this "all-or-nothing" approach be considered with great care.
必须使用策略来确定用于支持各种（ETS和非ETS）用户的机制的资源百分比。在某些条件下，对于特定用户组，此百分比可能达到100%。然而，我们建议谨慎考虑这种“全有或全无”的方法。
There should be a means of forwarding ETS labeled flows to those mechanisms within the domain used to support ETS. Discovery mechanisms SHOULD be used to determine where ETS labeled flows (either data or control) are to be forwarded.
在用于支持ETS的域内，应该有一种将ETS标记的流转发到这些机制的方法。应使用发现机制来确定ETS标记的流（数据流或控制流）的转发位置。
Management Information Bases (MIBs) SHOULD be defined for mechanisms specifically in place to support ETS. These MIBs MAY include objects representing accounting, policy, and authorization.
管理信息库（MIB）应针对支持ETS的机制进行定义。这些MIB可能包括表示记帐、策略和授权的对象。
This section presents issues that arise in considering solutions for the requirements that have been defined for stub domains that support ETS. This section does not specify solutions nor is it to be confused with requirements. Subsequent documents that articulate a more specific set of requirements for a particular service may make a statement about the following issues.
本节介绍了在考虑针对支持ETS的存根域定义的需求的解决方案时出现的问题。本节未规定解决方案，也不得与要求混淆。阐明特定服务的更具体需求集的后续文档可能会对以下问题进行说明。
The form of the service provided to ETS users and articulated in the form of policies may be realized in one of several forms. Better than best effort is probably the service that most ETS users would expect when the communication system is stressed and overall quality has degraded. However, the concept of best available service should also be considered under such stressed conditions. Further, a measure of degraded service may also be desirable to ensure a measure of communication versus none. These services may be made available at the network or application layer.
可以一种形式的ETS服务和多种形式的ETS服务来实现。当通信系统受到压力且整体质量下降时，大多数ETS用户所期望的服务可能比尽力而为要好。然而，在这种压力条件下，也应考虑提供最佳服务的概念。此外，还需要降级服务的度量来确保通信的度量相对于无。这些服务可以在网络或应用层提供。
The issue of making networks fault tolerant is important and yet not one that can be easily articulated in terms of requirements of protocols. Redundancy in connectivity and nodes (be it routers or servers) is probably the most common approach taken by network administrators, and it can be assumed that administrative domains apply this approach in various degrees to their own resources.
使网络具有容错性是一个重要的问题，但不是一个可以很容易地从协议的要求方面阐明的问题。连接和节点（无论是路由器还是服务器）中的冗余可能是网络管理员最常用的方法，可以假设管理域在不同程度上将此方法应用于自己的资源。
This document recommends that readers review and follow the comments and requirements about security presented in [RFC3689]. Having said that, there tend to be many instances where intra-domain security is held at a lower standard (i.e., less stringent) that inter-domain security. For example, while administrators may allow telnet service between resources within an administrative domain, they would only allow SSH access from other domains.
本文件建议读者阅读并遵循[RFC3689]中关于安全性的评论和要求。话虽如此，在许多情况下，域内安全的标准往往低于域间安全。例如，虽然管理员可能允许在管理域内的资源之间使用telnet服务，但他们只允许从其他域进行SSH访问。
The disparity in security policy can be problematic when domains offer services other than best effort for ETS users. Therefore, any support within a domain for ETS should be accompanied by a detailed security policy for users and administrators.
当域为ETS用户提供尽力而为之外的服务时，安全策略的差异可能会产生问题。因此，域内对ETS的任何支持都应附带针对用户和管理员的详细安全策略。
Given the "SHOULD" statement in Section 3.8 concerning MIBs, there are a number of related security considerations that need to be brought to attention to the reader. Specifically, the following:
鉴于第3.8节中关于MIB的“应该”声明，读者需要注意一些相关的安全注意事项。具体而言，以下是：
- Most current deployments of Simple Network Management Protocol (SNMP) are of versions prior to SNMPv3, even though there are well-known security vulnerabilities in those versions of SNMP.
- 大多数当前部署的简单网络管理协议（SNMP）都是SNMPv3之前的版本，尽管这些版本的SNMP中存在众所周知的安全漏洞。
- SNMP versions prior to SNMPv3 cannot support cryptographic security mechanisms. Hence, any use of SNMP prior to version 3 to write or modify MIB objects do so in a non-secure manner. As a result, it may be best to constrain the use of these objects to read-only by MIB managers.
- SNMPv3之前的SNMP版本无法支持加密安全机制。因此，在版本3之前使用SNMP写入或修改MIB对象都是以非安全的方式进行的。因此，最好将这些对象的使用限制为MIB管理器的只读。
- Finally, any MIB defining writable objects should carefully consider the security implications of an SNMP compromise on the mechanism(s) being controlled by those writable MIB objects.
- 最后，定义可写对象的任何MIB应该仔细考虑SNMP妥协对由可写MIB对象控制的机制的安全影响。
Thanks to Ran Atkinson, James Polk, Scott Bradner, Jon Peterson, and Ian Brown for comments on previous versions of this document.
感谢Ran Atkinson、James Polk、Scott Bradner、Jon Peterson和Ian Brown对本文档以前版本的评论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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月。
[RFC3689] Carlberg, K. and R. Atkinson, "General Requirements for Emergency Telecommunication Service (ETS)", RFC 3689, February 2004.
[RFC3689]Carlberg，K.和R.Atkinson，“紧急电信服务（ETS）的一般要求”，RFC 3689，2004年2月。
[FRAME] Carlberg, K., "A Framework for Supporting Emergency Telecommunications Services (ETS) Within a Single Administrative Domain", Work in Progress, December 2005.
[FRAME]Carlberg，K.，“在单一行政领域内支持紧急电信服务（ETS）的框架”，正在进行的工作，2005年12月。
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 Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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 provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。