Network Working Group L. Berger, Ed.
Request for Comments: 4783 LabN
Updates: 3473 December 2006
Category: Standards Track
Network Working Group L. Berger, Ed.
Request for Comments: 4783 LabN
Updates: 3473 December 2006
Category: Standards Track
GMPLS - Communication of Alarm Information
GMPLS-报警信息的通信
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
Abstract
摘要
This document describes an extension to Generalized MPLS (Multi-Protocol Label Switching) signaling to support communication of alarm information. GMPLS signaling already supports the control of alarm reporting, but not the communication of alarm information. This document presents both a functional description and GMPLS-RSVP specifics of such an extension. This document also proposes modification of the RSVP ERROR_SPEC object.
本文档描述了通用MPLS（多协议标签交换）信令的扩展，以支持报警信息的通信。GMPLS信令已经支持报警报告的控制，但不支持报警信息的通信。本文件介绍了此类扩展的功能描述和GMPLS-RSVP细节。本文件还建议修改RSVP ERROR_SPEC对象。
This document updates RFC 3473, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", through the addition of new, optional protocol elements. It does not change, and is fully backward compatible with, the procedures specified in RFC 3473.
本文档通过添加新的可选协议元素来更新RFC 3473，“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”。它不改变RFC 3473中规定的程序，并且完全向后兼容。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Background .................................................3
2. Alarm Information Communication .................................4
3. GMPLS-RSVP Details ..............................................5
3.1. ALARM_SPEC Objects .........................................5
3.1.1. IF_ID ALARM_SPEC (and ERROR_SPEC) TLVs ..............5
3.1.2. Procedures ..........................................9
3.1.3. Error Codes and Values .............................10
3.1.4. Backwards Compatibility ............................11
3.2. Controlling Alarm Communication ...........................11
3.2.1. Updated Admin_Status Object ........................11
3.2.2. Procedures .........................................11
3.3. Message Formats ...........................................12
3.4. Relationship to GMPLS UNI .................................13
3.5. Relationship to GMPLS E-NNI ...............................14
4. Security Considerations ........................................14
5. IANA Considerations ............................................15
5.1. New RSVP Object ...........................................15
5.2. New Interface ID Types ....................................16
5.3. New Registry for Admin-Status Object Bit Fields ...........16
5.4. New RSVP Error Code .......................................16
6. References .....................................................17
6.1. Normative References ......................................17
6.2. Informative References ....................................17
7. Acknowledgments ................................................18
8. Contributors ...................................................18
1. Introduction ....................................................3
1.1. Background .................................................3
2. Alarm Information Communication .................................4
3. GMPLS-RSVP Details ..............................................5
3.1. ALARM_SPEC Objects .........................................5
3.1.1. IF_ID ALARM_SPEC (and ERROR_SPEC) TLVs ..............5
3.1.2. Procedures ..........................................9
3.1.3. Error Codes and Values .............................10
3.1.4. Backwards Compatibility ............................11
3.2. Controlling Alarm Communication ...........................11
3.2.1. Updated Admin_Status Object ........................11
3.2.2. Procedures .........................................11
3.3. Message Formats ...........................................12
3.4. Relationship to GMPLS UNI .................................13
3.5. Relationship to GMPLS E-NNI ...............................14
4. Security Considerations ........................................14
5. IANA Considerations ............................................15
5.1. New RSVP Object ...........................................15
5.2. New Interface ID Types ....................................16
5.3. New Registry for Admin-Status Object Bit Fields ...........16
5.4. New RSVP Error Code .......................................16
6. References .....................................................17
6.1. Normative References ......................................17
6.2. Informative References ....................................17
7. Acknowledgments ................................................18
8. Contributors ...................................................18
GMPLS signaling provides mechanisms that can be used to control the reporting of alarms associated with a label switched path (LSP). This support is provided via Administrative Status Information [RFC3471] and the Admin_Status object [RFC3473]. These mechanisms only control if alarm reporting is inhibited. No provision is made for communication of alarm information within GMPLS.
GMPLS信令提供了可用于控制与标签交换路径（LSP）相关的报警报告的机制。此支持通过管理状态信息[RFC3471]和管理状态对象[RFC3473]提供。这些机制仅在报警报告被禁止时进行控制。没有为GMPLS内的报警信息通信作出规定。
The extension described in this document defines how the alarm information associated with a GMPLS LSP may be communicated along the path of the LSP. Communication both upstream and downstream is supported. The value in communicating such alarm information is that this information is then available at every node along the LSP for display and diagnostic purposes. Alarm information may also be useful in certain traffic protection scenarios, but such uses are out of the scope of this document. Alarm communication is supported via a new object, new error/alarm information TLVs, and a new Administrative Status Information bit.
本文件中描述的扩展定义了与GMPLS LSP相关联的报警信息如何沿LSP路径进行通信。支持上下游通信。传达此类报警信息的价值在于，该信息随后可在LSP沿线的每个节点上用于显示和诊断目的。报警信息在某些交通保护场景中也可能有用，但此类用途不在本文档范围内。通过新对象、新错误/报警信息TLV和新管理状态信息位支持报警通信。
The communication of alarms, as described in this document, is controllable on a per-LSP basis. Such communication may be useful within network configurations where not all nodes support communication to a user for reporting of alarms and/or communication is needed to support specific applications. The support of this functionality is optional.
如本文件所述，警报的通信在每个LSP的基础上是可控的。在并非所有节点都支持与用户通信以报告报警和/或需要通信以支持特定应用的网络配置中，这种通信可能很有用。此功能的支持是可选的。
The communication of alarms within GMPLS does not imply any modification in behavior of processing of alarms, or for the communication of alarms outside of GMPLS. Additionally, the extension described in this document is not intended to replace any (existing) data plane fault propagation techniques.
GMPLS内的报警通信并不意味着对报警处理行为或GMPLS外的报警通信进行任何修改。此外，本文档中描述的扩展并不打算取代任何（现有）数据平面故障传播技术。
The key words "MUST", "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]中所述进行解释。
Problems with data plane state can often be detected by associated data plane hardware components. Such data plane problems are typically filtered based on elapsed time and local policy. Problems that pass the filtering process are normally raised as alarms. These alarms are available for display to operators. They also may be collected centrally through means that are out of the scope of this document.
关联的数据平面硬件组件通常可以检测到数据平面状态的问题。此类数据平面问题通常根据运行时间和本地策略进行过滤。通过过滤过程的问题通常作为警报提出。这些警报可向操作员显示。也可通过本文件范围之外的方式集中收集。
Not all data plane problems cause the LSP to be immediately torn down. Further, there may be a desire, particularly in optical transport networks, to retain an LSP and communicate relevant alarm information even when the data plane state has failed completely.
并非所有数据平面问题都会导致LSP立即被拆除。此外，可能希望，特别是在光传输网络中，即使在数据平面状态完全失效时，也保留LSP并传送相关报警信息。
Although error information can be reported using PathErr, ResvErr, and Notify messages, these messages typically indicate a problem in signaling state and can only report one problem at a time. This makes it hard to correlate all of the problems that may be associated with a single LSP and to allow an operator examining the status of an LSP to view a full list of current problems. This situation is exacerbated by the absence of any way to communicate that a problem has been resolved and a corresponding alarm cleared.
尽管可以使用PathErr、ResvErr和Notify消息报告错误信息，但这些消息通常表示信令状态中存在问题，并且一次只能报告一个问题。这使得很难将可能与单个LSP相关的所有问题关联起来，也很难让检查LSP状态的操作员查看当前问题的完整列表。由于没有任何方式传达问题已解决和相应警报已清除的信息，这种情况更加严重。
The extensions defined in this document allow an operator or a software component to obtain a full list of current alarms associated with all of the resources used to support an LSP. The extensions also ensure that this list is kept up-to-date and synchronized with the real alarm status in the network. Finally, the extensions make the list available at every node traversed by an LSP.
本文档中定义的扩展允许操作员或软件组件获取与用于支持LSP的所有资源相关联的当前报警的完整列表。扩展还确保此列表保持最新，并与网络中的真实报警状态同步。最后，扩展使列表在LSP遍历的每个节点上都可用。
A new object is introduced to carry alarm information details. The details of alarm information are much like the error information carried in the existing ERROR_SPEC objects. For this reason the communication of alarm information uses a format that is based on the communication of error information.
引入了一种新的对象来携带报警信息细节。报警信息的详细信息与现有error_SPEC对象中包含的错误信息非常相似。因此，报警信息的通信使用基于错误信息通信的格式。
The new object introduced to carry alarm information details is called an ALARM_SPEC object. This object has the same format as the ERROR_SPEC object, but uses a new C-Num to avoid the semantics of error processing. Also, additional TLVs are defined for the IF_ID ALARM_SPEC objects to support the communication of information related to a specific alarm. These TLVs may also be useful when included in ERROR_SPEC objects, e.g., when the ERROR_SPEC object is carried within a Notify message.
引入的用于携带报警信息详细信息的新对象称为报警规格对象。此对象的格式与ERROR_SPEC对象相同，但使用新的C-Num来避免错误处理的语义。此外，还为IF_ID ALARM_SPEC对象定义了其他TLV，以支持与特定报警相关的信息通信。当包含在ERROR_SPEC对象中时，这些TLV也可能有用，例如，当ERROR_SPEC对象包含在Notify消息中时。
While the details of alarm information are like the details of existing error communication, the semantics of processing differ. Alarm information will typically relate to changes in data plane state, without changes in control state. Alarm information will always be associated with in-place LSPs. Such information will also typically be most useful to operators and applications other than control plane protocol processing. Finally, while error information is communicated within PathErr, ResvErr, and Notify messages [RFC3473], alarm information will be carried within Path and Resv messages.
虽然报警信息的细节类似于现有错误通信的细节，但处理的语义不同。报警信息通常与数据平面状态的变化有关，而与控制状态的变化无关。报警信息将始终与就地LSP关联。除控制平面协议处理外，此类信息通常对操作员和应用程序最有用。最后，当错误信息在PathErr、ResvErr和Notify消息[RFC3473]中通信时，报警信息将在Path和Resv消息中传输。
Path messages are used to carry alarm information to downstream nodes, and Resv messages are used to carry alarm information to upstream nodes. The intent of sending alarm information both upstream and downstream is to provide the same visibility to alarm information at any point along an LSP. The communication of multiple alarms associated with an LSP is supported. In this case, multiple ALARM_SPEC objects will be carried in the Path or Resv messages.
Path消息用于将报警信息传送到下游节点，Resv消息用于将报警信息传送到上游节点。向上游和下游发送报警信息的目的是在LSP上的任何点提供相同的报警信息可见性。支持与LSP相关的多个报警的通信。在这种情况下，路径或Resv消息中将携带多个报警规格对象。
The addition of alarm information to Path and Resv messages is controlled via a new Administrative Status Information bit. Administrative Status Information is carried in the Admin_Status object.
通过新的管理状态信息位控制向Path和Resv消息添加报警信息。管理状态信息包含在Admin_Status对象中。
This section provides the GMPLS-RSVP [RFC3473] specification for communication of alarm information. The communication of alarm information is OPTIONAL. This section applies to nodes that support communication of alarm information.
本节提供了报警信息通信的GMPLS-RSVP[RFC3473]规范。报警信息的通信是可选的。本节适用于支持报警信息通信的节点。
The ALARM_SPEC objects use the same format as the ERROR_SPEC object, but with class number of 198 (assigned by IANA in the form 11bbbbbb, per Section 3.1.4).
报警规范对象使用与错误规范对象相同的格式，但类号为198（根据第3.1.4节，IANA以11bbbbbb的形式分配）。
o Class = 198, C-Type = 1 Reserved. (C-Type value defined for ERROR_SPEC, but is not defined for use with ALARM_SPEC.)
o 类别=198，C型=1保留。（为错误规范定义的C类型值，但未定义用于报警规范。）
o Class = 198, C-Type = 2 Reserved. (C-Type value defined for ERROR_SPEC, but is not defined for use with ALARM_SPEC.)
o 类别=198，C型=2保留。（为错误规范定义的C类型值，但未定义用于报警规范。）
o IPv4 IF_ID ALARM_SPEC object: Class = 198, C-Type = 3 Definition same as IPv4 IF_ID ERROR_SPEC [RFC3473].
o IPv4 IF_ID ALARM_SPEC对象：Class=198，C-Type=3定义与IPv4 IF_ID ERROR_SPEC[RFC3473]相同。
o IPv6 IF_ID ALARM_SPEC object: Class = 198, C-Type = 4 Definition same as IPv6 IF_ID ERROR_SPEC [RFC3473].
o IPv6 IF_ID ALARM_SPEC对象：Class=198，C-Type=4定义与IPv6 IF_ID ERROR_SPEC[RFC3473]相同。
The following new TLVs are defined for use with the IPv4 and IPv6 IF_ID ALARM_SPEC objects. They may also be used with the IPv4 and IPv6 IF_ID ERROR_SPEC objects. See [RFC3471] Section 9.1.1 for the original definition of these values. Note the length provided below is for the total TLV. All TLVs defined in this section are OPTIONAL.
以下新TLV定义用于IPv4和IPv6 IF\u ID ALARM\u SPEC对象。如果\u ID ERROR\u SPEC对象出现错误，它们也可以与IPv4和IPv6一起使用。有关这些值的原始定义，请参见[RFC3471]第9.1.1节。注：以下提供的长度用于总TLV。本节中定义的所有TLV都是可选的。
The defined TLVs MUST follow any interface identifying TLVs. No rules apply to the relative ordering of the TLVs defined in this section.
定义的TLV必须遵循识别TLV的任何接口。本节中定义的TLV的相对顺序不适用任何规则。
Type Length Description
----------------------------------
512 8 REFERENCE_COUNT
513 8 SEVERITY
514 8 GLOBAL_TIMESTAMP
515 8 LOCAL_TIMESTAMP
516 variable ERROR_STRING
Type Length Description
----------------------------------
512 8 REFERENCE_COUNT
513 8 SEVERITY
514 8 GLOBAL_TIMESTAMP
515 8 LOCAL_TIMESTAMP
516 variable ERROR_STRING
The Reference Count TLV has the following format:
引用计数TLV具有以下格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reference Count: 32 bits
参考计数：32位
The number of times this alarm has been repeated as determined by the reporting node. This field MUST NOT be set to zero, and TLVs received with this field set to zero MUST be ignored.
由报告节点确定的重复此报警的次数。不得将此字段设置为零，并且必须忽略此字段设置为零时接收的TLV。
Only one Reference Count TLV may be included in an object.
一个对象中只能包含一个引用计数TLV。
The Severity TLV has the following format:
严重性TLV的格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Impact | Severity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Impact | Severity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: 20 bits
保留：20位
This field is reserved. It MUST be set to zero on generation, MUST be ignored on receipt, and MUST be forwarded unchanged and unexamined by transit nodes.
此字段是保留的。在生成时必须将其设置为零，在接收时必须忽略，并且必须在未经传输节点检查的情况下进行转发。
Impact: 4 bits
影响：4位
Indicates the impact of the alarm indicated in the TLV. See [M.20] for a general discussion on classification of failures. The following values are defined in this document. The details of the semantics may be found in [M.20].
指示TLV中指示的报警的影响。有关故障分类的一般性讨论，请参见[M.20]。本文件中定义了以下值。语义的详细信息可在[M.20]中找到。
Value Definition
----- ---------------------
0 Unspecified impact
1 Non-Service Affecting (Data traffic not interrupted)
2 Service Affecting (Data traffic is interrupted)
Value Definition
----- ---------------------
0 Unspecified impact
1 Non-Service Affecting (Data traffic not interrupted)
2 Service Affecting (Data traffic is interrupted)
Severity: 8 bits
严重性：8位
Indicates the impact of the alarm indicated in the TLV. See [RFC3877] and [M.3100] for more information on severity. The following values are defined in this document. The details of the semantics may be found in [RFC3877] and [M.3100]:
指示TLV中指示的报警的影响。有关严重性的更多信息，请参见[RFC3877]和[M.3100]。本文件中定义了以下值。语义的详细信息可在[RFC3877]和[M.3100]中找到：
Value Definition
----- ----------
0 Cleared
1 Indeterminate
2 Critical
3 Major
4 Minor
5 Warning
Value Definition
----- ----------
0 Cleared
1 Indeterminate
2 Critical
3 Major
4 Minor
5 Warning
Only one Severity TLV may be included in an object.
一个对象中只能包含一个严重性TLV。
The Global Timestamp TLV has the following format:
全局时间戳TLV具有以下格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Global Timestamp: 32 bits
全局时间戳：32位
An unsigned fixed-point integer that indicates the number of seconds since 00:00:00 UT on 1 January 1970 according to the clock on the node that originates this TLV. This time MAY include leap seconds if they are used by the local clock and SHOULD contain the same time value as used by the node when the alarm is reported through other systems (such as within the Management Plane) if global time is used in those reports.
一个无符号定点整数，根据发起此TLV的节点上的时钟指示自1970年1月1日00:00:00 UT以来的秒数。如果本地时钟使用闰秒，则该时间可能包括闰秒；如果在这些报告中使用全局时间，则该时间应包含与通过其他系统（如管理平面内）报告警报时节点使用的时间值相同的时间值。
Only one Global Timestamp TLV may be included in an object.
一个对象中只能包含一个全局时间戳TLV。
The Local Timestamp TLV has the following format:
本地时间戳TLV具有以下格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Local Timestamp: 32 bits
本地时间戳：32位
Number of seconds reported by the local system clock at the time the associated alarm was detected on the node that originates this TLV. This number is expected to be meaningful in the context of the originating node. For example, it may indicate the number of seconds since the node rebooted or may be a local representation of an unsynchronized real-time clock.
在发起此TLV的节点上检测到相关警报时，本地系统时钟报告的秒数。这个数字在发起节点的上下文中是有意义的。例如，它可以指示自节点重新启动以来的秒数，或者可以是非同步实时时钟的本地表示。
Only one Local Timestamp TLV may be included in an object.
一个对象中只能包含一个本地时间戳TLV。
The Error String TLV has the following format:
错误字符串TLV的格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Error String (NULL padded display string) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Error String (NULL padded display string) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Error String: 32 bits minimum (variable)
错误字符串：最小32位（变量）
A string of characters in US-ASCII, representing the type of error/alarm. This string is padded to the next largest 4-byte boundary using null characters. Null padding is not required when the string is 32-bit aligned. The contents of error string are implementation dependent. See the condition types listed in Appendices of [GR833] for a list of example strings. Note length includes padding.
US-ASCII格式的字符串，表示错误/警报的类型。此字符串使用空字符填充到下一个最大的4字节边界。当字符串为32位对齐时，不需要Null填充。错误字符串的内容取决于实现。有关示例字符串列表，请参见[GR833]附录中列出的条件类型。注长度包括填充。
Multiple Error String TLVs may be included in an object.
一个对象中可能包含多个错误字符串TLV。
This section applies to nodes that support the communication of alarm information. ALARM_SPEC objects are carried in Path and Resv messages. Multiple ALARM_SPEC objects MAY be present.
本节适用于支持报警信息通信的节点。报警规格对象包含在Path和Resv消息中。可能存在多个报警规格对象。
Nodes that support the extensions defined in this document SHOULD store any alarm information from received ALARM_SPEC objects for future use. All ALARM_SPEC objects received in Path messages SHOULD be passed unmodified downstream in the corresponding Path messages. All ALARM_SPEC objects received in Resv messages SHOULD be passed unmodified upstream in the corresponding Resv messages. ALARM_SPEC objects are merged in transmitted Resv messages by including a copy of all ALARM_SPEC objects received in corresponding Resv Messages.
支持本文档中定义的扩展的节点应存储来自接收的alarm_SPEC对象的任何报警信息，以备将来使用。在路径消息中接收的所有报警规范对象应在相应路径消息中未经修改地向下传递。在Resv消息中接收的所有报警规格对象应在相应的Resv消息中未经修改地向上游传递。通过包含在相应Resv消息中接收的所有报警规格对象的副本，报警规格对象合并到传输的Resv消息中。
To advertise local alarm information, a node generates an ALARM_SPEC object for each alarm and adds it to both the Path and Resv messages for the impacted LSP.
为了公布本地报警信息，节点为每个报警生成一个报警规范对象，并将其添加到受影响LSP的Path和Resv消息中。
In all cases, appropriate Error Node Address, Error Code, and Error Values MUST be set (see below for a discussion on Error Code and Error Values). As the InPlace and NotGuilty flags only have meaning in ERROR_SPEC objects, they SHOULD NOT be set. TLVs SHOULD be included in the ALARM_SPEC object to identify the interface, if any, associated with the alarm. The TLVs defined in [RFC3471] for identifying interfaces in the IF_ID ERROR_SPEC object [RFC3473] SHOULD be used for this purpose, but note that TLVs type 4 and 5 (component interfaces) are deprecated by [RFC4201] and SHOULD NOT be used. TLVs SHOULD also be included to indicate the severity (Severity TLV), the time (Global Timestamp and/or Local Timestamp TLVs), and a (brief) string (Error String TLV) associated with the alarm. The reference count TLV MAY also be included to indicate the number of times an alarm has been repeated at the reporting node. ALARM_SPEC objects received from other nodes are not impacted by the addition of local ALARM_SPEC objects, i.e., they continue to be processed as described above. The choice of which alarm or alarms to
在所有情况下，必须设置适当的错误节点地址、错误代码和错误值（有关错误代码和错误值的讨论，请参阅下文）。由于InPlace和NOT有罪标志仅在ERROR_SPEC对象中有意义，因此不应设置它们。TLV应包含在报警规格对象中，以识别与报警相关的接口（如果有）。[RFC3471]中定义的用于标识IF_ID ERROR_SPEC object[RFC3473]中接口的TLV应用于此目的，但请注意，[RFC4201]不推荐使用类型4和5（组件接口）的TLV，不应使用。还应包括TLV，以指示严重性（严重性TLV）、时间（全局时间戳和/或本地时间戳TLV）以及与报警相关的（简短）字符串（错误字符串TLV）。还可以包括参考计数TLV，以指示报警在报告节点重复的次数。从其他节点接收的ALARM_SPEC对象不受添加本地ALARM_SPEC对象的影响，即，它们继续按照上述方式进行处理。选择要发送的一个或多个警报
advertise and which to omit is a local policy matter, and may be configurable by the user.
播发和省略哪个是本地策略问题，用户可以配置。
There are two ways to indicate time. A global timestamp TLV is used to provide an absolute time reference for the occurrence of an alarm. The local timestamp TLV is used to provide time reference for the occurrence of an alarm that is relative to other information advertised by the node. The global timestamp SHOULD be used on nodes that maintain an absolute time reference. Both timestamp TLVs MAY be used simultaneously.
有两种表示时间的方法。全局时间戳TLV用于提供报警发生的绝对时间参考。本地时间戳TLV用于为报警的发生提供时间参考，该报警与节点发布的其他信息相关。全局时间戳应在维护绝对时间引用的节点上使用。两个时间戳tlv可以同时使用。
Note, ALARM_SPEC objects SHOULD NOT be added to the Path and Resv states of LSPs that are in "alarm communication inhibited" state. ALARM_SPEC objects MAY be added to the state of LSPs that are in an "administratively down" state. These states are indicated by the I and A bits of the Admin_Status object; see Section 3.2.
注意，不应将ALARM_SPEC对象添加到处于“ALARM communication inhibited”状态的LSP的路径和Resv状态。报警规格对象可以添加到处于“管理关闭”状态的LSP状态。这些状态由Admin_Status对象的I和A位表示；见第3.2节。
To remove local alarm information, a node simply removes the matching locally generated ALARM_SPEC objects from the outgoing Path and Resv messages. A node MAY modify a locally generated ALARM_SPEC object.
要删除本地报警信息，节点只需从传出路径和Resv消息中删除匹配的本地生成的报警规格对象。节点可以修改本地生成的报警规格对象。
Normal refresh and trigger message processing applies to Path or Resv messages that contain ALARM_SPEC objects. Note that changes in ALARM_SPEC objects from one message to the next may include a modification in the contents of a specific ALARM_SPEC object, or a change in the number of ALARM_SPEC objects present. All changes in ALARM_SPEC objects SHOULD be processed as trigger messages.
正常刷新和触发消息处理适用于包含报警规范对象的Path或Resv消息。请注意，从一条消息到下一条消息的ALARM_SPEC对象更改可能包括修改特定ALARM_SPEC对象的内容，或更改当前ALARM_SPEC对象的数量。报警规格对象中的所有更改都应作为触发消息处理。
Failure to follow the above directives, in particular the ones labeled "SHOULD" and "SHOULD NOT", may result in the alarm information not being properly or fully communicated.
不遵守上述指令，特别是标有“应该”和“不应该”的指令，可能会导致报警信息未正确或充分传达。
The Error Codes and Values used in ALARM_SPEC objects are the same as those used in ERROR_SPEC objects. New Error Code values for use with both ERROR_SPEC and ALARM_SPEC objects may be assigned to support alarm types defined by other standards.
报警规格对象中使用的错误代码和值与错误规格对象中使用的错误代码和值相同。可以为Error_SPEC和ALARM_SPEC对象指定新的错误代码值，以支持其他标准定义的报警类型。
In this document we define one new Error Code. The Error Code uses the value 31 and is referred to as "Alarms". The values used in the Error Values field when the Error Code is "Alarms" are the same as the values defined in the IANAItuProbableCause Textual Convention of IANA-ITU-ALARM-TC-MIB in the Alarm MIB [RFC3877]. Note that these values are managed by IANA; see http://www.iana.org.
在本文档中，我们定义了一个新的错误代码。错误代码使用值31，称为“报警”。错误代码为“报警”时，错误值字段中使用的值与报警MIB[RFC3877]中IANA-ITU-ALARM-TC-MIB的IAAITURPUBLECAUSE文本约定中定义的值相同。请注意，这些值由IANA管理；看见http://www.iana.org.
The support of ALARM_SPEC objects is OPTIONAL. Non-supporting nodes will (according to the rules defined in [RFC2205]) pass the objects through the node unmodified, because the ALARM_SPEC object has a C-Num of the form 11bbbbbb.
报警规格对象的支持是可选的。非支持节点将（根据[RFC2205]中定义的规则）在未修改的情况下通过节点传递对象，因为ALARM_SPEC对象的C-Num格式为11bbbb。
This allows alarm information to be collected and examined in a network built from a collection of nodes some of which support the communication of alarm information, and some of which do not.
这使得报警信息可以在由一组节点构成的网络中收集和检查，其中一些节点支持报警信息的通信，而另一些节点则不支持。
Alarm information communication is controlled via Administrative Status Information as carried in the Admin_Status object. A new bit is defined, called the I bit, that indicates when alarm communication is to be inhibited. The definition of this bit does not modify the procedures defined in Section 7 of [RFC3473].
报警信息通信通过Admin_Status对象中携带的管理状态信息进行控制。定义了一个新位，称为I位，用于指示何时禁止报警通信。该位的定义不修改[RFC3473]第7节中定义的程序。
The format of the Admin_Status object is updated to include the I bit:
Admin_Status对象的格式更新为包含I位：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(196)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |I| |T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(196)| C-Type (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Reserved |I| |T|A|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inhibit Alarm Communication (I): 1 bit When set, indicates that alarm communication is disabled for the LSP and that nodes SHOULD NOT add local alarm information.
禁止报警通信（I）：设置时为1位，表示LSP的报警通信已禁用，且节点不应添加本地报警信息。
See Section 7.1 of [RFC3473] for the definition of the remaining bits.
剩余位的定义见[RFC3473]第7.1节。
The I bit may be set and cleared using the procedures defined in Sections 7.2 and 7.3 of [RFC3473]. A node that receives (or generates) an Admin_Status object with the A or I bits set (1), SHOULD remove all locally generated alarm information from the matching LSP's outgoing Path and Resv messages. When a node receives (or generates) an Admin_Status object with the A and I bits clear (0) and there is local alarm information present, it SHOULD add the local
可使用第477节中的程序C37和第473节定义。接收（或生成）设置了A或I位（1）的Admin_Status对象的节点应从匹配LSP的传出路径和Resv消息中删除所有本地生成的报警信息。当节点接收（或生成）具有a和I位清除（0）的Admin_状态对象，并且存在本地报警信息时，它应该添加本地报警
alarm information to the matching LSP's outgoing Path and Resv messages.
将报警信息发送到匹配LSP的传出路径和Resv消息。
The processing of non-locally generated ALARM_SPEC objects MUST NOT be impacted by the contents of the Admin_Status object; that is, received ALARM_SPEC objects MUST be forwarded unchanged regardless of the received or transmitted settings of the I and A bits. Note that, per [RFC3473], the absence of the Admin_Status object is equivalent to receiving an object containing values all set to zero (0).
非本地生成的报警规格对象的处理不得受到管理状态对象内容的影响；也就是说，无论I位和A位的接收或传输设置如何，接收到的报警规范对象都必须不变地转发。请注意，根据[RFC3473]，缺少Admin_Status对象相当于接收一个包含所有设置为零（0）的值的对象。
I bit related processing behavior MAY be overridden locally based on configuration.
I位相关的处理行为可以根据配置在本地重写。
When generating Notify messages for LSPs with the I bit set, the TLVs described in this document MAY be added to the ERROR_SPEC object sent in the Notify message.
为设置了I位的LSP生成通知消息时，可以将本文档中描述的TLV添加到通知消息中发送的错误规范对象中。
This section presents the RSVP message-related formats as modified by this document. The formats specified in [RFC3473] served as the basis of these formats. The objects are listed in suggested ordering.
本节介绍本文件修改的RSVP消息相关格式。[RFC3473]中规定的格式是这些格式的基础。对象按建议的顺序列出。
The format of a Path message is as follows:
Path消息的格式如下所示：
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <PROTECTION> ]
[ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
[ <ALARM_SPEC> ... ]
<sender descriptor>
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <PROTECTION> ]
[ <LABEL_SET> ... ]
[ <SESSION_ATTRIBUTE> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
[ <ALARM_SPEC> ... ]
<sender descriptor>
<sender descriptor> is not modified by this document.
<sender descriptor>未被此文档修改。
The format of a Resv message is as follows:
Resv消息的格式如下所示：
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
[ <ALARM_SPEC> ... ]
<STYLE> <flow descriptor list>
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <NOTIFY_REQUEST> ]
[ <ADMIN_STATUS> ]
[ <POLICY_DATA> ... ]
[ <ALARM_SPEC> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> is not modified by this document.
<flow descriptor list>未被本文档修改。
[RFC4208] defines how GMPLS may be used in an overlay model to provide a user-to-network interface (UNI). In this model, restrictions may be applied to the information that is signaled between an edge-node and a core-node. This restriction allows the core network to limit the information that is visible outside of the core. This restriction may be made for confidentiality, privacy, or security reasons. It may also be made for operational reasons, for example, if the information is only applicable within the core network.
[RFC4208]定义了如何在覆盖模型中使用GMPLS来提供用户到网络接口（UNI）。在该模型中，可以对在边缘节点和核心节点之间发送信号的信息应用限制。此限制允许核心网络限制核心外部可见的信息。此限制可能出于保密、隐私或安全原因。也可能出于操作原因，例如，如果信息仅适用于核心网络内，那么也可以进行此操作。
The extensions described in this document are candidates for filtering as described in [RFC4208]. In particular, the following observations apply.
本文档中描述的扩展是[RFC4208]中描述的过滤候选。特别是，以下观察结果适用。
o An ingress or egress core-node MAY filter alarms from the GMPLS core to a client-node UNI LSP. This may be to protect information about the core network, or to indicate that the core network is performing or has completed recovery actions for the GMPLS LSP.
o 入口或出口核心节点可以过滤从GMPLS核心到客户端节点UNI LSP的警报。这可能是为了保护有关核心网络的信息，或表明核心网络正在执行或已完成GMPLS LSP的恢复操作。
o An ingress or egress core-node MAY modify alarms from the GMPLS core when sending to a client-node UNI LSP. This may facilitate the UNI client's ability to understand the failure and its effect on the data plane, and enable the UNI client to take corrective actions in a more appropriate manner.
o 当发送到客户端节点UNI LSP时，入口或出口核心节点可以修改来自GMPLS核心的警报。这可能有助于UNI客户端理解故障及其对数据平面的影响，并使UNI客户端能够以更合适的方式采取纠正措施。
o Similarly, an egress core-node MAY choose not to request alarm reporting on Path messages that it sends downstream to the overlay network.
o 类似地，出口核心节点可以选择不请求关于其向下游发送到覆盖网络的路径消息的报警报告。
GMPLS may be used at the external network-to-network interface (E-NNI); see [ASON-APPL]. At this interface, restrictions may be applied to the information that is signaled between an egress and an ingress core-node.
GMPLS可用于外部网络对网络接口（E-NNI）；参见[ASON-APPL]。在该接口处，可以对在出口和入口核心节点之间发信号的信息应用限制。
This restriction allows the ingress core network to limit the information that is visible outside of its core network. This restriction may be made for confidentiality, privacy, or security reasons. It may also be made for operational reasons, for example, if the information is only applicable within the core network.
此限制允许入口核心网络限制在其核心网络之外可见的信息。此限制可能出于保密、隐私或安全原因。也可能出于操作原因，例如，如果信息仅适用于核心网络内，那么也可以进行此操作。
The extensions described in this document are candidates for filtering as described in [ASON-APPL]. In particular, the following observations apply.
本文档中描述的扩展是[ASON-APL]中描述的筛选候选。特别是，以下观察结果适用。
o An ingress or egress core-node MAY filter internal core network alarms. This may be to protect information about the internal network or to indicate that the core network is performing or has completed recovery actions for this LSP.
o 入口或出口核心节点可过滤内部核心网络警报。这可能是为了保护有关内部网络的信息，或者表示核心网络正在执行或已完成此LSP的恢复操作。
o An ingress or egress core-node MAY modify internal core network alarms. This may facilitate the peering E-NNI (i.e., the egress core-node) to understand the failure and its effect on the data plane, and take corrective actions in a more appropriate manner or prolong the generated alarms upstream/downstream as appropriated.
o 入口或出口核心节点可修改内部核心网络警报。这可能有助于对等E-NNI（即出口核心节点）了解故障及其对数据平面的影响，并以更合适的方式采取纠正措施，或根据需要延长生成的上游/下游警报。
o Similarly, an egress/ingress core-node MAY choose not to request alarm reporting on Path messages that it sends downstream.
o 类似地，出口/入口核心节点可以选择不请求关于其向下游发送的路径消息的报警报告。
Some operators may consider alarm information as sensitive. To support environments where this is the case, implementations SHOULD allow the user to disable the generation of ALARM_SPEC objects, or to filter or correlate them at domain boundaries.
有些运营商可能认为报警信息是敏感的。为支持这种情况下的环境，实现应允许用户禁用报警规格对象的生成，或在域边界处对其进行过滤或关联。
This document introduces no additional security considerations. See [RFC3473] for relevant security considerations.
本文档不介绍其他安全注意事项。有关安全注意事项，请参见[RFC3473]。
It may be noted that if the security considerations of [RFC3473] are breached, alarm information may be spoofed. Such spoofing would be at most annoying and cause slight degradation of control plane performance since the details are provided for information only and do not result in protocol actions beyond the exchange of messages to convey the information. If the protocol security is able to be breached sufficiently to allow spoofing of alarm information then
需要注意的是，如果违反了[RFC3473]的安全考虑，则可能会伪造报警信息。这种欺骗最令人恼火，并且会导致控制平面性能的轻微下降，因为提供的详细信息仅用于信息，不会导致除了交换消息以传递信息之外的协议操作。如果能够充分违反协议安全性，从而允许欺骗报警信息，则
considerably more interesting and exciting damage can be caused by spoofing other elements of the protocol messages.
欺骗协议消息的其他元素可能会造成相当有趣和令人兴奋的损害。
IANA administered assignment of new values for namespaces defined in this document and reviewed in this section.
IANA管理本文档中定义的名称空间的新值分配，并在本节中进行了审查。
IANA made the following assignments in the "Class Names, Class Numbers, and Class Types" section of the "RSVP PARAMETERS" registry located at http://www.iana.org/assignments/rsvp-parameters.
IANA在位于的“RSVP参数”注册表的“类名、类号和类类型”部分进行了以下分配：http://www.iana.org/assignments/rsvp-parameters.
A new class named ALARM_SPEC (198) was created in the 11bbbbbb range with following values
在11bbbbbb范围内创建了一个名为ALARM_SPEC（198）的新类，其值如下
o Class = 198, C-Type = 1 RFC 4783 Reserved. (C-Type value defined for ERROR_SPEC, but is not defined for use with ALARM_SPEC.)
o 类别=198，C型=1 RFC 4783保留。（为错误规范定义的C类型值，但未定义用于报警规范。）
o Class = 198, C-Type = 2 RFC 4783 Reserved. (C-Type value defined for ERROR_SPEC, but is not defined for use with ALARM_SPEC.)
o 类别=198，C型=2 RFC 4783保留。（为错误规范定义的C类型值，但未定义用于报警规范。）
o IPv4 IF_ID ALARM_SPEC object: Class = 198, C-Type = 3 RFC 4783 Definition same as IPv4 IF_ID ERROR_SPEC [RFC3473].
o IPv4 IF_ID ALARM_SPEC对象：Class=198，C-Type=3 RFC 4783定义与IPv4 IF_ID ERROR_SPEC[RFC3473]相同。
o IPv6 IF_ID ALARM_SPEC object: Class = 198, C-Type = 4 RFC 4783 Definition same as IPv6 IF_ID ERROR_SPEC [RFC3473].
o IPv6 IF_ID报警_SPEC对象：Class=198，C-Type=4 RFC 4783定义与IPv6 IF_ID错误_SPEC[RFC3473]相同。
The ALARM_SPEC object uses the Error Code and Error Values from the ERROR_SPEC object.
报警规格对象使用错误规格对象中的错误代码和错误值。
IANA made the following assignments in the "Interface_ID Types" section of the "GMPLS Signaling Parameters" registry located at http://www.iana.org/assignments/gmpls-sig-parameters.
IANA在位于的“GMPLS信令参数”注册表的“接口ID类型”部分进行了以下分配：http://www.iana.org/assignments/gmpls-sig-parameters.
512 8 REFERENCE_COUNT RFC 4783 513 8 SEVERITY RFC 4783 514 8 GLOBAL_TIMESTAMP RFC 4783 515 8 LOCAL_TIMESTAMP RFC 4783 516 variable ERROR_STRING RFC 4783
512 8参考计数RFC 4783 513 8严重性RFC 4783 514 8全局时间戳RFC 4783 515 8局部时间戳RFC 4783 516变量错误字符串RFC 4783
IANA created a new section titled "Administrative Status Information Flags" in the "GMPLS Signaling Parameters" registry located at http://www.iana.org/assignments/gmpls-sig-parameters and made the following assignments:
IANA在位于的“GMPLS信令参数”注册表中创建了一个名为“管理状态信息标志”的新部分http://www.iana.org/assignments/gmpls-sig-parameters 并完成了以下任务：
Value Name Reference
----------- -------------------------------- -----------------
0x80000000 Reflect (R) [RFC3473/RFC3471]
0x00000010 Inhibit Alarm Communication (I) RFC 4783
0x00000004 Testing (T) [RFC3473/RFC3471]
0x00000002 Administratively down (A) [RFC3473/RFC3471]
0x00000001 Deletion in progress (D) [RFC3473/RFC3471]
Value Name Reference
----------- -------------------------------- -----------------
0x80000000 Reflect (R) [RFC3473/RFC3471]
0x00000010 Inhibit Alarm Communication (I) RFC 4783
0x00000004 Testing (T) [RFC3473/RFC3471]
0x00000002 Administratively down (A) [RFC3473/RFC3471]
0x00000001 Deletion in progress (D) [RFC3473/RFC3471]
IANA made the following assignments in the "Error Codes and Values" section of the "RSVP PARAMETERS" registry located at http://www.iana.org/assignments/rsvp-parameters.
IANA在位于的“RSVP参数”注册表的“错误代码和值”部分进行了以下分配：http://www.iana.org/assignments/rsvp-parameters.
31 Alarms RFC 4783
31警报RFC 4783
The Error Value sub-codes for this Error Code have values and meanings identical to the values and meanings defined in the IANAItuProbableCause Textual Convention of IANA-ITU-ALARM-TC-MIB in the Alarm MIB [RFC3877]. Note that these values are already managed the IANA.
此错误代码的错误值子代码的值和含义与报警MIB[RFC3877]中IANA-ITU-ALARM-TC-MIB的IAAITURBABLECAUSE文本约定中定义的值和含义相同。请注意，这些值已经由IANA管理。
[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月。
[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月。
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令功能描述”，RFC 3471，2003年1月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management Information Base (MIB)", RFC 3877, September 2004.
[RFC3877]Chisholm，S.和D.Romascanu，“报警管理信息库（MIB）”，RFC 3877，2004年9月。
[M.3100] ITU Recommendation M.3100, "Generic Network Information Model", 1995.
[M.3100]国际电联建议M.3100，“通用网络信息模型”，1995年。
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4201]Kompella，K.，Rekhter，Y.，和L.Berger，“MPLS流量工程（TE）中的链路捆绑”，RFC 42012005年10月。
[M.20] ITU-T, "MAINTENANCE PHILOSOPHY FOR TELECOMMUNICATION NETWORKS", Recommendation M.20, October 1992.
[M.20]ITU-T，“电信网络的维护理念”，建议M.20，1992年10月。
[GR833] Bellcore, "Network Maintenance: Network Element and Transport Surveillance Messages" (GR-833-CORE), Issue 3, February 1999.
[GR833]Bellcore，“网络维护：网元和传输监视消息”（GR-833-CORE），第3期，1999年2月。
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005.
[RFC4208]Swallow，G.，Drake，J.，Ishimatsu，H.，和Y.Rekhter，“通用多协议标签交换（GMPLS）用户网络接口（UNI）：覆盖模型的资源预留协议流量工程（RSVP-TE）支持”，RFC 4208，2005年10月。
[ASON-APPL] Papadimitriou, D., et al., "Generalized MPLS (GMPLS) RSVP-TE signaling usage in support of Automatically Switched Optical Network (ASON)", Work in Progress, July 2005.
[ASON-APL]Papadimitriou，D.，等，“支持自动交换光网络（ASON）的通用MPLS（GMPLS）RSVP-TE信令使用”，正在进行的工作，2005年7月。
Valuable comments and input were received from a number of people, including Wes Doonan, Bert Wijnen for the DISMAN reference, and Tom Petch for getting the DISMAN WG interactions started. We also thank David Black, Lars Eggert, Russ Housley, Dan Romascanu, and Magnus Westerlund for their valuable comments.
许多人都提出了宝贵的意见和建议，包括Wes Doonan、Bert Wijnen（用于Deman参考）和Tom Petch（用于启动Deman WG交互）。我们还感谢大卫·布莱克、拉尔斯·艾格特、罗斯·霍斯利、丹·罗马斯坎努和马格纳斯·韦斯特隆德的宝贵评论。
Contributors are listed in alphabetical order:
贡献者按字母顺序列出：
Deborah Brungard AT&T Labs, Room MT D1-3C22 200 Laurel Avenue Middletown, NJ 07748, USA Phone: (732) 420-1573 EMail: dbrungard@att.com
Deborah Brungard AT&T实验室，美国新泽西州劳雷尔大道中城200号MT D1-3C22室，邮编07748电话：（732）420-1573电子邮件：dbrungard@att.com
Igor Bryskin Adrian Farrel Movaz Networks, Inc. Old Dog Consulting 7926 Jones Branch Drive Suite 615 McLean VA, 22102, USA Phone: +44 (0) 1978 860944 EMail: ibryskin@movaz.com EMail: adrian@olddog.co.uk
Igor Bryskin Adrian Farrel Movaz Networks，Inc.Old Dog Consulting 7926 Jones Branch Drive Suite 615 McLean VA，22102，美国电话：+44（0）1978 860944电子邮件：ibryskin@movaz.com电邮：adrian@olddog.co.uk
Dimitri Papadimitriou (Alcatel) Arun Satyanarayana
Francis Wellesplein 1 Cisco Systems, Inc
B-2018 Antwerpen, Belgium 170 West Tasman Dr.
San Jose, CA 95134 USA
Phone: +32 3 240-8491 Phone: +1 408 853-3206
EMail: dimitri.papadimitriou@alcatel.be EMail: asatyana@cisco.com
Dimitri Papadimitriou (Alcatel) Arun Satyanarayana
Francis Wellesplein 1 Cisco Systems, Inc
B-2018 Antwerpen, Belgium 170 West Tasman Dr.
San Jose, CA 95134 USA
Phone: +32 3 240-8491 Phone: +1 408 853-3206
EMail: dimitri.papadimitriou@alcatel.be EMail: asatyana@cisco.com
Editor's Address
编辑地址
Lou Berger LabN Consulting, L.L.C.
Lou Berger LabN咨询公司，L.L.C。
Phone: +1 301-468-9228
EMail: lberger@labn.net
Phone: +1 301-468-9228
EMail: lberger@labn.net
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（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, 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编辑功能的资金目前由互联网协会提供。