Network Working Group T. Nadeau, Ed.
Request for Comments: 3811 Cisco Systems, Inc.
Category: Standards Track J. Cucchiara, Ed.
Marconi Communications, Inc.
June 2004
Network Working Group T. Nadeau, Ed.
Request for Comments: 3811 Cisco Systems, Inc.
Category: Standards Track J. Cucchiara, Ed.
Marconi Communications, Inc.
June 2004
Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management
多协议标签交换（MPLS）管理的文本约定（TC）定义
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 Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This memo defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Multiprotocol Label Switching (MPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS related MIB modules that would otherwise define their own representations.
本备忘录定义了一个管理信息库（MIB）模块，其中包含表示常用多协议标签交换（MPLS）管理信息的文本约定。其目的是将这些文本约定（TC）导入并在MPLS相关的MIB模块中使用，否则这些模块将定义它们自己的表示。
Table of Contents
目录
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Internet-Standard Management Framework. . . . . . . . . . 2
3. MPLS Textual Conventions MIB Definitions. . . . . . . . . . . 2
4. References. . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Normative References. . . . . . . . . . . . . . . . . . 16
4.2. Informative References. . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Contributors. . . . . . . . . . . . . . . . . . . . . . . . . 18
8 Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 19
9. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 19
10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 20
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Internet-Standard Management Framework. . . . . . . . . . 2
3. MPLS Textual Conventions MIB Definitions. . . . . . . . . . . 2
4. References. . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Normative References. . . . . . . . . . . . . . . . . . 16
4.2. Informative References. . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Contributors. . . . . . . . . . . . . . . . . . . . . . . . . 18
8 Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 19
9. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 19
10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 20
This document defines a MIB module which contains Textual Conventions for Multiprotocol Label Switching (MPLS) networks. These Textual Conventions should be imported by MIB modules which manage MPLS networks.
本文档定义了一个MIB模块，其中包含多协议标签交换（MPLS）网络的文本约定。这些文本约定应由管理MPLS网络的MIB模块导入。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
For an introduction to the concepts of MPLS, see [RFC3031].
有关MPLS概念的介绍，请参见[RFC3031]。
For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410].
有关描述当前互联网标准管理框架的文件的详细概述，请参阅RFC 3410[RFC3410]第7节。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
托管对象通过虚拟信息存储（称为管理信息库或MIB）进行访问。MIB对象通常通过简单网络管理协议（SNMP）进行访问。MIB中的对象是使用管理信息结构（SMI）中定义的机制定义的。本备忘录规定了符合SMIv2的MIB模块，如STD 58、RFC 2578[RFC2578]、STD 58、RFC 2579[RFC2579]和STD 58、RFC 2580[RFC2580]所述。
MPLS-TC-STD-MIB DEFINITIONS ::= BEGIN
MPLS-TC-STD-MIB DEFINITIONS ::= BEGIN
IMPORTS
进口
MODULE-IDENTITY, Unsigned32, Integer32, transmission FROM SNMPv2-SMI -- [RFC2578]
模块标识，无符号32，整数32，来自SNMPv2 SMI的传输--[RFC2578]
TEXTUAL-CONVENTION FROM SNMPv2-TC; -- [RFC2579]
SNMPv2 TC的文本约定；——[RFC2579]
mplsTCStdMIB MODULE-IDENTITY LAST-UPDATED "200406030000Z" -- June 3, 2004 ORGANIZATION "IETF Multiprotocol Label Switching (MPLS) Working Group." CONTACT-INFO " Thomas D. Nadeau
mplsTCStdMIB模块标识最后更新的“200406030000Z”-2004年6月3日组织“IETF多协议标签交换（MPLS）工作组”。联系信息“Thomas D.Nadeau”
Cisco Systems, Inc. tnadeau@cisco.com
思科系统公司。tnadeau@cisco.com
Joan Cucchiara Marconi Communications, Inc. jcucchiara@mindspring.com
琼·库奇亚拉·马可尼通信公司。jcucchiara@mindspring.com
Cheenu Srinivasan Bloomberg L.P. cheenu@bloomberg.net
切努·斯里尼瓦桑·布隆伯格有限公司。cheenu@bloomberg.net
Arun Viswanathan Force10 Networks, Inc. arunv@force10networks.com
Arun Viswanathan Force10网络公司。arunv@force10networks.com
Hans Sjostrand ipUnplugged hans@ipunplugged.com
汉斯·索斯特兰·伊普兰拔掉了插头hans@ipunplugged.com
Kireeti Kompella Juniper Networks kireeti@juniper.net
Kireeti Kompella Juniper网络kireeti@juniper.net
Email comments to the MPLS WG Mailing List at mpls@uu.net." DESCRIPTION "Copyright (C) The Internet Society (2004). The initial version of this MIB module was published in RFC 3811. For full legal notices see the RFC itself or see: http://www.ietf.org/copyrights/ianamib.html
通过电子邮件向MPLS WG邮件列表发送评论，地址为mpls@uu.net.“说明”版权所有（C）互联网协会（2004年）。该MIB模块的初始版本发布在RFC 3811中。有关完整的法律通知，请参阅RFC本身或参阅：http://www.ietf.org/copyrights/ianamib.html
This MIB module defines TEXTUAL-CONVENTIONs for concepts used in Multiprotocol Label Switching (MPLS) networks."
此MIB模块为多协议标签交换（MPLS）网络中使用的概念定义文本约定。”
REVISION "200406030000Z" -- June 3, 2004 DESCRIPTION "Initial version published as part of RFC 3811."
修订版“200406030000Z”-2004年6月3日描述“作为RFC 3811的一部分发布的初始版本”
::= { mplsStdMIB 1 }
::= { mplsStdMIB 1 }
mplsStdMIB OBJECT IDENTIFIER
MPLSTDMIB对象标识符
::= { transmission 166 }
::= { transmission 166 }
MplsAtmVcIdentifier ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
MplsAtmVcIdentifier ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current DESCRIPTION "A Label Switching Router (LSR) that creates LDP sessions on ATM interfaces uses the VCI or VPI/VCI field to hold the LDP Label.
状态当前描述“在ATM接口上创建LDP会话的标签交换路由器（LSR）使用VCI或VPI/VCI字段保存LDP标签。
VCI values MUST NOT be in the 0-31 range. The values 0 to 31 are reserved for other uses by the ITU and ATM Forum. The value of 32 can only be used for the Control VC, although values greater than 32 could be configured for the Control VC.
VCI值不得在0-31范围内。值0至31保留给ITU和ATM论坛的其他用途。值32只能用于控件VC，但可以为控件VC配置大于32的值。
If a value from 0 to 31 is used for a VCI the management entity controlling the LDP subsystem should reject this with an inconsistentValue error. Also, if the value of 32 is used for a VC which is NOT the Control VC, this should result in an inconsistentValue error." REFERENCE "MPLS using LDP and ATM VC Switching, RFC3035." SYNTAX Integer32 (32..65535)
如果VCI使用0到31之间的值，则控制LDP子系统的管理实体应拒绝该值，并出现不一致的值错误。此外，如果32的值用于非控制VC的VC，这将导致不一致的值错误。“参考”使用LDP和ATM VC交换的MPLS，RFC3035。“语法整数32（32..65535）
MplsBitRate ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"If the value of this object is greater than zero,
then this represents the bandwidth of this MPLS
interface (or Label Switched Path) in units of
'1,000 bits per second'.
MplsBitRate ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"If the value of this object is greater than zero,
then this represents the bandwidth of this MPLS
interface (or Label Switched Path) in units of
'1,000 bits per second'.
The value, when greater than zero, represents the bandwidth of this MPLS interface (rounded to the nearest 1,000) in units of 1,000 bits per second. If the bandwidth of the MPLS interface is between ((n * 1000) - 500) and ((n * 1000) + 499), the value of this object is n, such that n > 0.
该值大于零时表示此MPLS接口的带宽（四舍五入到最接近的1000），单位为每秒1000位。如果MPLS接口的带宽在（（n*1000）-500）和（（n*1000）+499）之间，则该对象的值为n，使得n>0。
If the value of this object is 0 (zero), this means that the traffic over this MPLS interface is considered to be best effort." SYNTAX Unsigned32 (0|1..4294967295)
如果此对象的值为0（零），这意味着此MPLS接口上的通信量被认为是最大努力。”SYNTAX Unsigned32（0 | 1..4294967295）
MplsBurstSize ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
MplsBurstSize ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current DESCRIPTION "The number of octets of MPLS data that the stream may send back-to-back without concern for policing. The value of zero indicates that an implementation does not support Burst Size." SYNTAX Unsigned32 (0..4294967295)
STATUS current DESCRIPTION“流可以背对背发送的MPLS数据的八位字节数，而无需考虑策略。零值表示实现不支持突发大小。”语法Unsigned32（0..4294967295）
MplsExtendedTunnelId ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A unique identifier for an MPLS Tunnel. This may
represent an IPv4 address of the ingress or egress
LSR for the tunnel. This value is derived from the
Extended Tunnel Id in RSVP or the Ingress Router ID
for CR-LDP."
REFERENCE
"RSVP-TE: Extensions to RSVP for LSP Tunnels,
[RFC3209].
MplsExtendedTunnelId ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A unique identifier for an MPLS Tunnel. This may
represent an IPv4 address of the ingress or egress
LSR for the tunnel. This value is derived from the
Extended Tunnel Id in RSVP or the Ingress Router ID
for CR-LDP."
REFERENCE
"RSVP-TE: Extensions to RSVP for LSP Tunnels,
[RFC3209].
Constraint-Based LSP Setup using LDP, [RFC3212]." SYNTAX Unsigned32(0..4294967295)
使用LDP[RFC3212]的基于约束的LSP设置。“语法无符号32（0..4294967295）
MplsLabel ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This value represents an MPLS label as defined in
[RFC3031], [RFC3032], [RFC3034], [RFC3035] and
[RFC3471].
MplsLabel ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This value represents an MPLS label as defined in
[RFC3031], [RFC3032], [RFC3034], [RFC3035] and
[RFC3471].
The label contents are specific to the label being represented, such as:
标签内容特定于所表示的标签，例如：
* The label carried in an MPLS shim header (for LDP this is the Generic Label) is a 20-bit number represented by 4 octets. Bits 0-19 contain a label or a reserved label value. Bits 20-31 MUST be zero.
* MPLS垫片头中携带的标签（对于LDP，这是通用标签）是由4个八位字节表示的20位数字。位0-19包含标签或保留标签值。位20-31必须为零。
The following is quoted directly from [RFC3032]. There are several reserved label values:
以下内容直接引自[RFC3032]。有几个保留标签值：
i. A value of 0 represents the 'IPv4 Explicit NULL Label'. This label value is only legal at the bottom of the label stack. It indicates that the label stack must be popped, and the forwarding of the packet must then be based on the
i. 值0表示“IPv4显式空标签”。此标签值仅在标签堆栈底部合法。它表示必须弹出标签堆栈，然后数据包的转发必须基于
IPv4 header.
IPv4标头。
ii. A value of 1 represents the 'Router Alert Label'. This label value is legal anywhere in the label stack except at the bottom. When a received packet contains this label value at the top of the label stack, it is delivered to a local software module for processing. The actual forwarding of the packet is determined by the label beneath it in the stack. However, if the packet is forwarded further, the Router Alert Label should be pushed back onto the label stack before forwarding. The use of this label is analogous to the use of the 'Router Alert Option' in IP packets [RFC2113]. Since this label cannot occur at the bottom of the stack, it is not associated with a particular network layer protocol.
二、值1表示“路由器警报标签”。此标签值在标签堆栈中除底部以外的任何位置都是合法的。当接收到的数据包在标签堆栈顶部包含此标签值时，它将被传送到本地软件模块进行处理。数据包的实际转发由堆栈中数据包下面的标签决定。但是，如果数据包被进一步转发，则在转发之前，路由器警报标签应该被推回到标签堆栈上。此标签的使用类似于IP数据包[RFC2113]中“路由器警报选项”的使用。由于此标签不能出现在堆栈的底部，因此它与特定的网络层协议没有关联。
iii. A value of 2 represents the 'IPv6 Explicit NULL Label'. This label value is only legal at the bottom of the label stack. It indicates that the label stack must be popped, and the forwarding of the packet must then be based on the IPv6 header.
iii.值2表示“IPv6显式空标签”。此标签值仅在标签堆栈底部合法。它表示必须弹出标签堆栈，然后数据包的转发必须基于IPv6报头。
iv. A value of 3 represents the 'Implicit NULL Label'. This is a label that an LSR may assign and distribute, but which never actually appears in the encapsulation. When an LSR would otherwise replace the label at the top of the stack with a new label, but the new label is 'Implicit NULL', the LSR will pop the stack instead of doing the replacement. Although this value may never appear in the encapsulation, it needs to be specified in the Label Distribution Protocol, so a value is reserved.
iv.值3表示“隐式空标签”。这是一个LSR可以分配和分发的标签，但它实际上从未出现在封装中。如果LSR以其他方式使用新标签替换堆栈顶部的标签，但新标签为“隐式NULL”，则LSR将弹出堆栈，而不是进行替换。尽管此值可能永远不会出现在封装中，但需要在标签分发协议中指定，因此保留一个值。
v. Values 4-15 are reserved.
v. 保留值4-15。
* The frame relay label can be either 10-bits or
* 帧中继标签可以是10位或10位
23-bits depending on the DLCI field size and the upper 22-bits or upper 9-bits must be zero, respectively.
取决于DLCI字段大小的23位和上限22位或上限9位必须分别为零。
* For an ATM label the lower 16-bits represents the VCI, the next 12-bits represents the VPI and the remaining bits MUST be zero.
* 对于ATM标签，低16位表示VCI，下12位表示VPI，其余位必须为零。
* The Generalized-MPLS (GMPLS) label contains a value greater than 2^24-1 and used in GMPLS as defined in [RFC3471]." REFERENCE "Multiprotocol Label Switching Architecture, RFC3031.
*通用MPLS（GMPLS）标签包含大于2^24-1的值，并在[RFC3471]“参考”多协议标签交换体系结构RFC3031中定义的GMPLS中使用。
MPLS Label Stack Encoding, [RFC3032].
MPLS标签堆栈编码[RFC3032]。
Use of Label Switching on Frame Relay Networks, RFC3034.
在帧中继网络上使用标签切换，RFC3034。
MPLS using LDP and ATM VC Switching, RFC3035. Generalized Multiprotocol Label Switching (GMPLS) Architecture, [RFC3471]." SYNTAX Unsigned32 (0..4294967295)
MPLS使用LDP和ATM VC交换，RFC3035。通用多协议标签交换（GMPLS）体系结构，[RFC3471]。“语法无符号32（0..4294967295）
MplsLabelDistributionMethod ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The label distribution method which is also called
the label advertisement mode [RFC3036].
Each interface on an LSR is configured to operate
in either Downstream Unsolicited or Downstream
on Demand."
REFERENCE
"Multiprotocol Label Switching Architecture,
RFC3031.
MplsLabelDistributionMethod ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The label distribution method which is also called
the label advertisement mode [RFC3036].
Each interface on an LSR is configured to operate
in either Downstream Unsolicited or Downstream
on Demand."
REFERENCE
"Multiprotocol Label Switching Architecture,
RFC3031.
LDP Specification, RFC3036, Section 2.6.3."
SYNTAX INTEGER {
downstreamOnDemand(1),
downstreamUnsolicited(2)
}
LDP Specification, RFC3036, Section 2.6.3."
SYNTAX INTEGER {
downstreamOnDemand(1),
downstreamUnsolicited(2)
}
MplsLdpIdentifier ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d:2d"
STATUS current
DESCRIPTION
"The LDP identifier is a six octet
MplsLdpIdentifier ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d:2d"
STATUS current
DESCRIPTION
"The LDP identifier is a six octet
quantity which is used to identify a Label Switching Router (LSR) label space.
用于标识标签交换路由器（LSR）标签空间的数量。
The first four octets identify the LSR and must be a globally unique value, such as a 32-bit router ID assigned to the LSR, and the last two octets identify a specific label space within the LSR." SYNTAX OCTET STRING (SIZE (6))
前四个八位字节标识LSR，并且必须是全局唯一值，例如分配给LSR的32位路由器ID，最后两个八位字节标识LSR内的特定标签空间。“语法八位字节字符串（大小（6））
MplsLsrIdentifier ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The Label Switching Router (LSR) identifier is the
first 4 bytes of the Label Distribution Protocol
(LDP) identifier."
SYNTAX OCTET STRING (SIZE (4))
MplsLdpLabelType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The Layer 2 label types which are defined for MPLS
LDP and/or CR-LDP are generic(1), atm(2), or
frameRelay(3)."
SYNTAX INTEGER {
generic(1),
atm(2),
frameRelay(3)
}
MplsLsrIdentifier ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The Label Switching Router (LSR) identifier is the
first 4 bytes of the Label Distribution Protocol
(LDP) identifier."
SYNTAX OCTET STRING (SIZE (4))
MplsLdpLabelType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The Layer 2 label types which are defined for MPLS
LDP and/or CR-LDP are generic(1), atm(2), or
frameRelay(3)."
SYNTAX INTEGER {
generic(1),
atm(2),
frameRelay(3)
}
MplsLSPID ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A unique identifier within an MPLS network that is
assigned to each LSP. This is assigned at the head
end of the LSP and can be used by all LSRs
to identify this LSP. This value is piggybacked by
the signaling protocol when this LSP is signaled
within the network. This identifier can then be
used at each LSR to identify which labels are
being swapped to other labels for this LSP. This
object can also be used to disambiguate LSPs that
share the same RSVP sessions between the same
source and destination.
MplsLSPID ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A unique identifier within an MPLS network that is
assigned to each LSP. This is assigned at the head
end of the LSP and can be used by all LSRs
to identify this LSP. This value is piggybacked by
the signaling protocol when this LSP is signaled
within the network. This identifier can then be
used at each LSR to identify which labels are
being swapped to other labels for this LSP. This
object can also be used to disambiguate LSPs that
share the same RSVP sessions between the same
source and destination.
For LSPs established using CR-LDP, the LSPID is composed of the ingress LSR Router ID (or any of its own IPv4 addresses) and a locally unique CR-LSP ID to that LSR. The first two bytes carry
对于使用CR-LDP建立的LSP，LSPID由入口LSR路由器ID（或其自身的任何IPv4地址）和该LSR的本地唯一CR-LSP ID组成。前两个字节携带
the CR-LSPID, and the remaining 4 bytes carry the Router ID. The LSPID is useful in network management, in CR-LSP repair, and in using an already established CR-LSP as a hop in an ER-TLV.
CR-LSPID和剩余的4个字节携带路由器ID。LSPID在网络管理、CR-LSP修复以及将已建立的CR-LSP用作ER-TLV中的跳时非常有用。
For LSPs signaled using RSVP-TE, the LSP ID is defined as a 16-bit (2 byte) identifier used in the SENDER_TEMPLATE and the FILTER_SPEC that can be changed to allow a sender to share resources with itself. The length of this object should only be 2 or 6 bytes. If the length of this octet string is 2 bytes, then it must identify an RSVP-TE LSPID, or it is 6 bytes, it must contain a CR-LDP LSPID." REFERENCE "RSVP-TE: Extensions to RSVP for LSP Tunnels, [RFC3209].
对于使用RSVP-TE发送信号的LSP，LSP ID定义为发送方模板和筛选器规范中使用的16位（2字节）标识符，可以更改该标识符以允许发送方与其自身共享资源。此对象的长度应仅为2或6个字节。如果此八位字节字符串的长度为2字节，则它必须标识RSVP-TE LSPID，或者它是6字节，它必须包含CR-LDP LSPID。“参考”RSVP-TE:LSP隧道RSVP的扩展[RFC3209]。
Constraint-Based LSP Setup using LDP, [RFC3212]." SYNTAX OCTET STRING (SIZE (2|6))
使用LDP[RFC3212]的基于约束的LSP设置。“语法八位组字符串（大小（2 | 6））
MplsLspType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Types of Label Switch Paths (LSPs)
on a Label Switching Router (LSR) or a
Label Edge Router (LER) are:
MplsLspType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Types of Label Switch Paths (LSPs)
on a Label Switching Router (LSR) or a
Label Edge Router (LER) are:
unknown(1) -- if the LSP is not known to be one of the following.
未知（1）——如果不知道LSP是以下之一。
terminatingLsp(2) -- if the LSP terminates on the LSR/LER, then this is an egressing LSP which ends on the LSR/LER,
终止LSP（2）——如果LSP在LSR/LER上终止，则这是一个在LSR/LER上终止的出口LSP，
originatingLsp(3) -- if the LSP originates from this LSR/LER, then this is an ingressing LSP which is the head-end of the LSP,
发起LSP（3）——如果LSP源自此LSR/LER，则这是一个进入LSP，它是LSP的前端，
crossConnectingLsp(4) -- if the LSP ingresses and egresses on the LSR, then it is cross-connecting on that
交叉连接LSP（4）——如果LSP在LSR上进出，则它在该LSR上交叉连接
LSR."
SYNTAX INTEGER {
unknown(1),
terminatingLsp(2),
originatingLsp(3),
crossConnectingLsp(4)
}
LSR."
SYNTAX INTEGER {
unknown(1),
terminatingLsp(2),
originatingLsp(3),
crossConnectingLsp(4)
}
MplsOwner ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This object indicates the local network
management subsystem that originally created
the object(s) in question. The values of
this enumeration are defined as follows:
MplsOwner ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This object indicates the local network
management subsystem that originally created
the object(s) in question. The values of
this enumeration are defined as follows:
unknown(1) - the local network management subsystem cannot discern which component created the object.
未知（1）-本地网络管理子系统无法识别是哪个组件创建了对象。
other(2) - the local network management subsystem is able to discern which component created the object, but the component is not listed within the following choices, e.g., command line interface (cli).
其他（2）-本地网络管理子系统能够识别哪个组件创建了对象，但该组件未在以下选项中列出，例如命令行界面（cli）。
snmp(3) - The Simple Network Management Protocol was used to configure this object initially.
snmp（3）-简单网络管理协议最初用于配置此对象。
ldp(4) - The Label Distribution Protocol was used to configure this object initially.
ldp（4）-最初使用标签分发协议配置此对象。
crldp(5) - The Constraint-Based Label Distribution Protocol was used to configure this object initially.
crldp（5）-基于约束的标签分发协议最初用于配置此对象。
rsvpTe(6) - The Resource Reservation Protocol was used to configure this object initially.
rsvpTe（6）-资源保留协议最初用于配置此对象。
policyAgent(7) - A policy agent (perhaps in combination with one of the above protocols) was used to configure this object initially.
policyAgent（7）-最初使用策略代理（可能与上述协议之一结合）配置此对象。
An object created by any of the above choices MAY be modified or destroyed by the same or a different choice." SYNTAX INTEGER { unknown(1),
由上述任一选项创建的对象可能会被相同或不同的选项修改或销毁。“语法整数{unknown（1），
other(2), snmp(3), ldp(4), crldp(5), rsvpTe(6), policyAgent(7) }
其他（2）、snmp（3）、ldp（4）、crldp（5）、rsvpTe（6）、policyAgent（7）}
MplsPathIndexOrZero ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A unique identifier used to identify a specific
path used by a tunnel. A value of 0 (zero) means
that no path is in use."
SYNTAX Unsigned32(0..4294967295)
MplsPathIndexOrZero ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A unique identifier used to identify a specific
path used by a tunnel. A value of 0 (zero) means
that no path is in use."
SYNTAX Unsigned32(0..4294967295)
MplsPathIndex ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A unique value to index (by Path number) an
entry in a table."
SYNTAX Unsigned32(1..4294967295)
MplsPathIndex ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A unique value to index (by Path number) an
entry in a table."
SYNTAX Unsigned32(1..4294967295)
MplsRetentionMode ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The label retention mode which specifies whether
an LSR maintains a label binding for a FEC
learned from a neighbor that is not its next hop
for the FEC.
MplsRetentionMode ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The label retention mode which specifies whether
an LSR maintains a label binding for a FEC
learned from a neighbor that is not its next hop
for the FEC.
If the value is conservative(1) then advertised label mappings are retained only if they will be used to forward packets, i.e., if label came from a valid next hop.
如果该值为保守值（1），则仅当广告标签映射将用于转发数据包时（即，如果标签来自有效的下一跳），才会保留广告标签映射。
If the value is liberal(2) then all advertised label mappings are retained whether they are from a valid next hop or not." REFERENCE "Multiprotocol Label Switching Architecture, RFC3031.
如果该值为自由值（2），则保留所有播发标签映射，无论它们是否来自有效的下一跳。“参考”多协议标签交换体系结构，RFC3031。
LDP Specification, RFC3036, Section 2.6.2."
SYNTAX INTEGER {
conservative(1),
liberal(2)
}
LDP Specification, RFC3036, Section 2.6.2."
SYNTAX INTEGER {
conservative(1),
liberal(2)
}
MplsTunnelAffinity ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Describes the configured 32-bit Include-any,
include-all, or exclude-all constraint for
constraint-based link selection."
REFERENCE
"RSVP-TE: Extensions to RSVP for LSP Tunnels,
RFC3209, Section 4.7.4."
SYNTAX Unsigned32(0..4294967295)
MplsTunnelAffinity ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Describes the configured 32-bit Include-any,
include-all, or exclude-all constraint for
constraint-based link selection."
REFERENCE
"RSVP-TE: Extensions to RSVP for LSP Tunnels,
RFC3209, Section 4.7.4."
SYNTAX Unsigned32(0..4294967295)
MplsTunnelIndex ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A unique index into mplsTunnelTable.
For tunnels signaled using RSVP, this value
should correspond to the RSVP Tunnel ID
used for the RSVP-TE session."
SYNTAX Unsigned32 (0..65535)
MplsTunnelIndex ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A unique index into mplsTunnelTable.
For tunnels signaled using RSVP, this value
should correspond to the RSVP Tunnel ID
used for the RSVP-TE session."
SYNTAX Unsigned32 (0..65535)
MplsTunnelInstanceIndex ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The tunnel entry with instance index 0
should refer to the configured tunnel
interface (if one exists).
MplsTunnelInstanceIndex ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The tunnel entry with instance index 0
should refer to the configured tunnel
interface (if one exists).
Values greater than 0, but less than or equal to 65535, should be used to indicate signaled (or backup) tunnel LSP instances. For tunnel LSPs signaled using RSVP, this value should correspond to the RSVP LSP ID used for the RSVP-TE LSP.
大于0但小于或等于65535的值应用于指示信号（或备份）隧道LSP实例。对于使用RSVP发送信号的隧道LSP，该值应与用于RSVP-TE LSP的RSVP LSP ID相对应。
Values greater than 65535 apply to FRR detour instances." SYNTAX Unsigned32(0|1..65535|65536..4294967295)
大于65535的值适用于FRR迂回实例。“语法无符号32（0 | 1..65535 | 65536..4294967295）
TeHopAddressType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A value that represents a type of address for a
Traffic Engineered (TE) Tunnel hop.
TeHopAddressType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A value that represents a type of address for a
Traffic Engineered (TE) Tunnel hop.
unknown(0) An unknown address type. This value MUST be used if the value of the corresponding TeHopAddress object is a
未知（0）未知的地址类型。如果相应TeHopAddress对象的值为
zero-length string. It may also be used to indicate a TeHopAddress which is not in one of the formats defined below.
零长度字符串。它还可用于指示不是以下定义格式之一的地址。
ipv4(1) An IPv4 network address as defined by the InetAddressIPv4 TEXTUAL-CONVENTION [RFC3291].
ipv4（1）由InetAddressIPv4文本约定[RFC3291]定义的ipv4网络地址。
ipv6(2) A global IPv6 address as defined by the InetAddressIPv6 TEXTUAL-CONVENTION [RFC3291].
ipv6（2）由InetAddressIPv6文本约定[RFC3291]定义的全局ipv6地址。
asnumber(3) An Autonomous System (AS) number as defined by the TeHopAddressAS TEXTUAL-CONVENTION.
asnumber（3）由TechopAddressAS文本约定定义的自治系统（AS）编号。
unnum(4) An unnumbered interface index as defined by the TeHopAddressUnnum TEXTUAL-CONVENTION.
unnum（4）根据TeHopAddressUnnum文本约定定义的未编号接口索引。
lspid(5) An LSP ID for TE Tunnels (RFC3212) as defined by the MplsLSPID TEXTUAL-CONVENTION.
lspid（5）根据MPLSSPID文本约定定义的TE隧道（RFC3212）的LSP ID。
Each definition of a concrete TeHopAddressType value must be accompanied by a definition of a TEXTUAL-CONVENTION for use with that TeHopAddress.
具体TeHopAddressType值的每个定义都必须附带一个文本约定的定义，以便与该TeHopAddress一起使用。
To support future extensions, the TeHopAddressType TEXTUAL-CONVENTION SHOULD NOT be sub-typed in object type definitions. It MAY be sub-typed in compliance statements in order to require only a subset of these address types for a compliant implementation.
为了支持将来的扩展，TeHopAddressType文本约定不应在对象类型定义中进行子类型化。它可以在符合性声明中进行子类型化，以便在符合性实现中只需要这些地址类型的子集。
Implementations must ensure that TeHopAddressType objects and any dependent objects (e.g., TeHopAddress objects) are consistent. An inconsistentValue error must be generated if an attempt to change a TeHopAddressType object would, for example, lead to an undefined TeHopAddress value that is not defined herein. In particular, TeHopAddressType/TeHopAddress pairs must be changed together if the address type changes (e.g., from ipv6(2) to ipv4(1))."
实现必须确保TeHopAddressType对象和任何依赖对象（例如TeHopAddress对象）是一致的。例如，如果试图更改TeHopAddressType对象将导致此处未定义的未定义TeHopAddress值，则必须生成不一致值错误。特别是，如果地址类型发生变化（例如，从ipv6（2）到ipv4（1）），则必须同时更改TeHopAddressType/TeHopAddress对。”
REFERENCE "TEXTUAL-CONVENTIONs for Internet Network Addresses, RFC3291.
参考“互联网网络地址的文本约定，RFC3291。
Constraint-Based LSP Setup using LDP, [RFC3212]"
使用LDP[RFC3212]的基于约束的LSP设置”
SYNTAX INTEGER {
unknown(0),
ipv4(1),
ipv6(2),
asnumber(3),
unnum(4),
lspid(5)
}
SYNTAX INTEGER {
unknown(0),
ipv4(1),
ipv6(2),
asnumber(3),
unnum(4),
lspid(5)
}
TeHopAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Denotes a generic Tunnel hop address,
that is, the address of a node which
an LSP traverses, including the source
and destination nodes. An address may be
very concrete, for example, an IPv4 host
address (i.e., with prefix length 32);
if this IPv4 address is an interface
address, then that particular interface
must be traversed. An address may also
specify an 'abstract node', for example,
an IPv4 address with prefix length
less than 32, in which case, the LSP
can traverse any node whose address
falls in that range. An address may
also specify an Autonomous System (AS),
in which case the LSP can traverse any
node that falls within that AS.
TeHopAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Denotes a generic Tunnel hop address,
that is, the address of a node which
an LSP traverses, including the source
and destination nodes. An address may be
very concrete, for example, an IPv4 host
address (i.e., with prefix length 32);
if this IPv4 address is an interface
address, then that particular interface
must be traversed. An address may also
specify an 'abstract node', for example,
an IPv4 address with prefix length
less than 32, in which case, the LSP
can traverse any node whose address
falls in that range. An address may
also specify an Autonomous System (AS),
in which case the LSP can traverse any
node that falls within that AS.
A TeHopAddress value is always interpreted within the context of an TeHopAddressType value. Every usage of the TeHopAddress TEXTUAL-CONVENTION is required to specify the TeHopAddressType object which provides the context. It is suggested that the TeHopAddressType object is logically registered before the object(s) which use the TeHopAddress TEXTUAL-CONVENTION if they appear in the same logical row.
TechopAddress值始终在TechopAddressType值的上下文中解释。每次使用TeHopAddress文本约定都需要指定提供上下文的TeHopAddressType对象。建议将TeHopAddressType对象逻辑注册在使用TeHopAddress文本约定的对象之前（如果它们出现在同一逻辑行中）。
The value of a TeHopAddress object must always be
TeHopAddress对象的值必须始终为
consistent with the value of the associated TeHopAddressType object. Attempts to set a TeHopAddress object to a value which is inconsistent with the associated TeHopAddressType must fail with an inconsistentValue error." SYNTAX OCTET STRING (SIZE (0..32))
与关联的TeHopAddressType对象的值一致。尝试将TeHopAddress对象设置为与关联的TeHopAddressType不一致的值必须失败，并出现不一致的值错误。“语法八位组字符串（大小（0..32））
TeHopAddressAS ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Represents a two or four octet AS number.
The AS number is represented in network byte
order (MSB first). A two-octet AS number has
the two MSB octets set to zero."
REFERENCE
"Textual Conventions for Internet Network
Addresses, [RFC3291]. The
InetAutonomousSystemsNumber TEXTUAL-CONVENTION
has a SYNTAX of Unsigned32, whereas this TC
has a SYNTAX of OCTET STRING (SIZE (4)).
Both TCs represent an autonomous system number
but use different syntaxes to do so."
SYNTAX OCTET STRING (SIZE (4))
TeHopAddressAS ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Represents a two or four octet AS number.
The AS number is represented in network byte
order (MSB first). A two-octet AS number has
the two MSB octets set to zero."
REFERENCE
"Textual Conventions for Internet Network
Addresses, [RFC3291]. The
InetAutonomousSystemsNumber TEXTUAL-CONVENTION
has a SYNTAX of Unsigned32, whereas this TC
has a SYNTAX of OCTET STRING (SIZE (4)).
Both TCs represent an autonomous system number
but use different syntaxes to do so."
SYNTAX OCTET STRING (SIZE (4))
TeHopAddressUnnum ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Represents an unnumbered interface:
TeHopAddressUnnum ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Represents an unnumbered interface:
octets contents encoding 1-4 unnumbered interface network-byte order
八位字节内容编码1-4无编号接口网络字节顺序
The corresponding TeHopAddressType value is unnum(5)." SYNTAX OCTET STRING(SIZE(4))
对应的TeHopAddressType值为unnum（5）。“语法八位字节字符串（大小（4））
END
终止
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113]Katz，D.，“IP路由器警报选项”，RFC 21131997年2月。
[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月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP: 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP:26，RFC 2434，1998年10月。
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578]McCloghrie，K.，Perkins，D.，和J.Schoenwaeld，“管理信息的结构版本2（SMIv2）”，STD 58，RFC 2578，1999年4月。
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579]McCloghrie，K.，Perkins，D.，和J.Schoenwaeld，“SMIv2的文本约定”，STD 58，RFC 2579，1999年4月。
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[RFC2580]McCloghrie，K.，Perkins，D.，和J.Schoenwaeld，“SMIv2的一致性声明”，STD 58，RFC 25801999年4月。
[RFC3031] Rosen, E., Viswananthan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]Rosen，E.，Viswananthan，A.，和R.Callon，“多协议标签交换体系结构”，RFC 30312001年1月。
[RFC3032] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Federokow, G., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032]Rosen，E.，Rekhter，Y.，Tappan，D.，Farinaci，D.，Federokow，G.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[RFC3034] Conta, A., Doolan, P., and A. Malis, "Use of Label Switching on Frame Relay Networks Specification", RFC 3034, January 2001.
[RFC3034]Conta，A.，Doolan，P.，和A.Malis，“帧中继网络上标签切换的使用规范”，RFC 3034，2001年1月。
[RFC3035] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., Swallow, G., Rekhter, Y., and P. Doolan, "MPLS using LDP and ATM VC Switching", RFC 3035, January 2001.
[RFC3035]Davie，B.，Lawrence，J.，McCloghrie，K.，Rosen，E.，Swallow，G.，Rekhter，Y.，和P.Doolan，“使用LDP和ATM VC交换的MPLS”，RFC 3035，2001年1月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3036]Andersson，L.，Doolan，P.，Feldman，N.，Fredette，A.，和B.Thomas，“LDP规范”，RFC 3036，2001年1月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3212] Jamoussi, B., Ed., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.
[RFC3212]Jamoussi，B.，Ed.，Andersson，L.，Callon，R.，Dantu，R.，Wu，L.，Doolan，P.，Worster，T.，Feldman，N.，Fredette，A.，Girish，M.，Gray，E.，Heinanen，J.，Kilty，T.，和A.Malis，“使用LDP的基于约束的LSP设置”，RFC 32122002年1月。
[RFC3291] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 3291, May 2002.
[RFC3291]Daniele，M.，Haberman，B.，Routhier，S.，和J.Schoenwaeld，“互联网网络地址的文本约定”，RFC 3291，2002年5月。
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3471, January 2003.
[RFC3471]Berger，L.，编辑，“通用多协议标签交换（GMPLS）体系结构”，RFC 3471，2003年1月。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410]Case，J.，Mundy，R.，Partain，D.，和B.Stewart，“互联网标准管理框架的介绍和适用性声明”，RFC 34102002年12月。
This module does not define any management objects. Instead, it defines a set of textual conventions which may be used by other MPLS MIB modules to define management objects.
此模块不定义任何管理对象。相反，它定义了一组文本约定，其他MPLS MIB模块可以使用这些文本约定来定义管理对象。
Meaningful security considerations can only be written in the MIB modules that define management objects. Therefore, this document has no impact on the security of the Internet.
有意义的安全注意事项只能写入定义管理对象的MIB模块中。因此，本文件不影响互联网的安全。
IANA has made a MIB OID assignment under the transmission branch, that is, assigned the mplsStdMIB under { transmission 166 }. This sub-id is requested because 166 is the ifType for mpls(166) and is available under transmission.
IANA在传输分支下进行了MIB OID分配，即在{transmission 166}下分配了mplsStdMIB。请求此子id是因为166是mpls（166）的ifType，并且在传输时可用。
In the future, MPLS related standards track MIB modules should be rooted under the mplsStdMIB subtree. The IANA is requested to manage that namespace. New assignments can only be made via a Standards Action as specified in [RFC2434].
将来，与MPLS相关的标准跟踪MIB模块应该扎根在MPLSTDMIB子树下。请求IANA来管理该名称空间。新分配只能通过[RFC2434]中规定的标准行动进行。
The IANA has also assigned { mplsStdMIB 1 } to the MPLS-TC-STD-MIB specified in this document.
IANA还将{mplsStdMIB 1}分配给本文件中指定的MPLS-TC-STD-MIB。
This document was created by combining TEXTUAL-CONVENTIONS from current MPLS MIBs and a TE-WG MIB. Co-authors on each of these MIBs contributed to the TEXTUAL-CONVENTIONS contained in this MIB and also contributed greatly to the revisions of this document. These co-authors addresses are included here because they are useful future contacts for information about this document. These co-authors are:
本文档是通过结合当前MPLS MIB和TE-WG MIB的文本约定创建的。这些MIB的共同作者对本MIB中包含的文本约定做出了贡献，并对本文件的修订做出了重大贡献。这些共同作者的地址包括在这里，因为它们是关于本文档信息的有用的未来联系人。这些共同作者是：
Cheenu Srinivasan Bloomberg L.P. 499 Park Ave. New York, NY 10022
Cheenu Srinivasan Bloomberg L.P.纽约州纽约市公园大道499号，邮编10022
Phone: +1-212-893-3682
EMail: cheenu@bloomberg.net
Phone: +1-212-893-3682
EMail: cheenu@bloomberg.net
Arun Viswanathan Force10 Networks, Inc. 1440 McCarthy Blvd Milpitas, CA 95035
加利福尼亚州米尔皮塔斯麦卡锡大道1440号Arun Viswanathan Force10 Networks，Inc.95035
Phone: +1-408-571-3516
EMail: arunv@force10networks.com
Phone: +1-408-571-3516
EMail: arunv@force10networks.com
Hans Sjostrand ipUnplugged P.O. Box 101 60 S-121 28 Stockholm, Sweden
Hans Sjostrand Ipo，瑞典斯德哥尔摩，邮政信箱101 60 S-121 28
Phone: +46-8-725-5900
EMail: hans@ipunplugged.com
Phone: +46-8-725-5900
EMail: hans@ipunplugged.com
Kireeti Kompella Juniper Networks 1194 Mathilda Ave Sunnyvale, CA 94089
Kireeti Kompella Juniper Networks 1194 Mathilda Ave Sunnyvale，加利福尼亚州94089
Phone: +1-408-745-2000
EMail: kireeti@juniper.net
Phone: +1-408-745-2000
EMail: kireeti@juniper.net
This document is a product of the MPLS Working Group. The editors and contributors would like to thank Mike MacFadden and Adrian Farrel for their helpful comments on several reviews. Also, the editors and contributors would like to give a special acknowledgement to Bert Wijnen for his many detailed reviews. Bert's assistance and guidance is greatly appreciated.
本文件是MPLS工作组的产品。编辑和撰稿人感谢迈克·麦克法登和阿德里安·法雷尔对几篇评论的有益评论。此外，编辑和撰稿人希望特别感谢伯特·维恩（Bert Wijnen）的许多详细评论。非常感谢伯特的帮助和指导。
Thomas D. Nadeau Cisco Systems, Inc. BXB300/2/ 300 Beaver Brook Road Boxborough, MA 01719
Thomas D.Nadeau Cisco Systems，Inc.马萨诸塞州Boxborough市比弗布鲁克路BXB300/2/300号，邮编01719
Phone: +1-978-936-1470
EMail: tnadeau@cisco.com
Phone: +1-978-936-1470
EMail: tnadeau@cisco.com
Joan E. Cucchiara Marconi Communications, Inc. 900 Chelmsford Street Lowell, MA 01851
Joan E.Cucchiara Marconi通信有限公司，马萨诸塞州洛厄尔切姆斯福德街900号，邮编01851
Phone: +1-978-275-7400
EMail: jcucchiara@mindspring.com
Phone: +1-978-275-7400
EMail: jcucchiara@mindspring.com
Copyright (C) The Internet Society (2004). 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.
版权所有（C）互联网协会（2004年）。本文件受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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。