Network Working Group A. Conta
Request for Comments: 3034 Transwitch Corporation
Category: Standards Track P. Doolan
Ennovate
A. Malis
Vivace Networks, Inc.
January 2001
Network Working Group A. Conta
Request for Comments: 3034 Transwitch Corporation
Category: Standards Track P. Doolan
Ennovate
A. Malis
Vivace Networks, Inc.
January 2001
Use of Label Switching on Frame Relay Networks Specification
帧中继网络上标签切换的使用规范
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 (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This document defines the model and generic mechanisms for Multiprotocol Label Switching on Frame Relay networks. Furthermore, it extends and clarifies portions of the Multiprotocol Label Switching Architecture described in [ARCH] and the Label Distribution Protocol (LDP) described in [LDP] relative to Frame Relay Networks. MPLS enables the use of Frame Relay Switches as Label Switching Routers (LSRs).
本文件定义了帧中继网络上多协议标签切换的模型和通用机制。此外，它扩展并澄清了[ARCH]中描述的多协议标签交换体系结构和[LDP]中描述的标签分发协议（LDP）相对于帧中继网络的部分内容。MPLS允许使用帧中继交换机作为标签交换路由器（LSR）。
Table of Contents
目录
1. Introduction................................................2
2. Terminology.................................................3
3. Special Characteristics of Frame Relay Switches.............4
4. Label Encapsulation.........................................5
5. Frame Relay Label Switching Processing......................6
5.1 Use of DLCIs..............................................6
5.2 Homogeneous LSPs..........................................7
5.3 Heterogeneous LSPs........................................7
5.4 Frame Relay Label Switching Loop Prevention and Control...7
5.4.1 FR-LSRs Loop Control - MPLS TTL Processing.............7
5.4.2 Performing MPLS TTL calculations.......................8
5.5 Label Processing by Ingress FR-LSRs......................12
1. Introduction................................................2
2. Terminology.................................................3
3. Special Characteristics of Frame Relay Switches.............4
4. Label Encapsulation.........................................5
5. Frame Relay Label Switching Processing......................6
5.1 Use of DLCIs..............................................6
5.2 Homogeneous LSPs..........................................7
5.3 Heterogeneous LSPs........................................7
5.4 Frame Relay Label Switching Loop Prevention and Control...7
5.4.1 FR-LSRs Loop Control - MPLS TTL Processing.............7
5.4.2 Performing MPLS TTL calculations.......................8
5.5 Label Processing by Ingress FR-LSRs......................12
5.6 Label Processing by Core FR-LSRs.........................12
5.7 Label Processing by Egress FR-LSRs.......................13
6. Label Switching Control Component for Frame Relay.........13
6.1 Hybrid Switches (Ships in the Night) ...................14
7. Label Allocation and Maintenance Procedures ..............15
7.1 Edge LSR Behavior........................................15
7.2 Efficient use of label space-Merging FR-LSRs.............18
7.3 LDP message fields specific to Frame Relay...............19
8. Security Considerations .................................21
9. Acknowledgments .........................................21
10. References ..............................................22
11. Authors' Addresses ......................................23
12. Full Copyright Statement ................................24
5.6 Label Processing by Core FR-LSRs.........................12
5.7 Label Processing by Egress FR-LSRs.......................13
6. Label Switching Control Component for Frame Relay.........13
6.1 Hybrid Switches (Ships in the Night) ...................14
7. Label Allocation and Maintenance Procedures ..............15
7.1 Edge LSR Behavior........................................15
7.2 Efficient use of label space-Merging FR-LSRs.............18
7.3 LDP message fields specific to Frame Relay...............19
8. Security Considerations .................................21
9. Acknowledgments .........................................21
10. References ..............................................22
11. Authors' Addresses ......................................23
12. Full Copyright Statement ................................24
The Multiprotocol Label Switching Architecture is described in [ARCH]. It is possible to use Frame Relay switches as Label Switching Routers. Such Frame Relay switches run network layer routing algorithms (such as OSPF, IS-IS, etc.), and their forwarding is based on the results of these routing algorithms. No specific Frame Relay routing is needed.
[ARCH]中描述了多协议标签交换体系结构。可以使用帧中继交换机作为标签交换路由器。这种帧中继交换机运行网络层路由算法（如OSPF、IS-IS等），它们的转发基于这些路由算法的结果。不需要特定的帧中继路由。
When a Frame Relay switch is used for label switching, the top (current) label, on which forwarding decisions are based, is carried in the DLCI field of the Frame Relay data link layer header of a frame. Additional information carried along with the top (current) label, but not processed by Frame Relay switching, along with other labels, if the packet is multiply labeled, are carried in the generic MPLS encapsulation defined in [STACK].
当帧中继交换机用于标签交换时，转发决策所基于的顶部（当前）标签携带在帧的帧中继数据链路层报头的DLCI字段中。与顶部（当前）标签一起携带但未经帧中继交换处理的附加信息，以及其他标签（如果数据包是多重标签的话），在[STACK]中定义的通用MPLS封装中携带。
Frame Relay permanent virtual circuits (PVCs) could be configured to carry label switching based traffic. The DLCIs would be used as MPLS Labels and the Frame Relay switches would become Frame Relay Label Switching Routers, while the MPLS traffic would be encapsulated according to this specification, and would be forwarded based on network layer routing information.
帧中继永久虚拟电路（PVC）可以配置为承载基于标签交换的业务。DLCI将用作MPLS标签，帧中继交换机将成为帧中继标签交换路由器，而MPLS流量将根据此规范进行封装，并将基于网络层路由信息进行转发。
The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined in RFC 2119.
关键字必须、不得、可、可选、必需、推荐、应、不应、不应按照RFC 2119中的定义进行解释。
This document is a companion document to [STACK] and [ATM].
本文件是[STACK]和[ATM]的配套文件。
LSR
LSR
A Label Switching Router (LSR) is a device which implements the label switching control and forwarding components described in [ARCH].
标签交换路由器（LSR）是一种实现[ARCH]中所述标签交换控制和转发组件的设备。
LC-FR
LC-FR
A label switching controlled Frame Relay (LC-FR) interface is a Frame Relay interface controlled by the label switching control component. Packets traversing such an interface carry labels in the DLCI field.
标签切换控制帧中继（LC-FR）接口是由标签切换控制组件控制的帧中继接口。穿过此类接口的数据包在DLCI字段中携带标签。
FR-LSR
FR-LSR
A FR-LSR is an LSR with one or more LC-FR interfaces which forwards frames between two such interfaces using labels carried in the DLCI field.
FR-LSR是具有一个或多个LC-FR接口的LSR，该接口使用DLCI字段中携带的标签在两个此类接口之间转发帧。
FR-LSR domain
FR-LSR域
A FR-LSR domain is a set of FR-LSRs, which are mutually interconnected by LC-FR interfaces.
FR-LSR域是一组FR LSR，它们通过LC-FR接口相互连接。
Edge Set
边集
The Edge Set of an FR-LSR domain is the set of LSRs, which are connected to the domain by LC-FR interfaces.
FR-LSR域的边缘集是通过LC-FR接口连接到域的LSR集。
Forwarding Encapsulation
转发封装
The Forwarding Encapsulation is the type of MPLS encapsulation (Frame Relay, ATM, Generic) of a packet that determines the packet's MPLS forwarding, or the network layer encapsulation if that packet is forwarded based on the network layer (IP, etc...)header.
转发封装是确定数据包的MPLS转发的数据包的MPLS封装类型（帧中继、ATM、通用），或者如果数据包是基于网络层（IP等）报头转发的，则为网络层封装。
Input Encapsulation
输入封装
The Input Encapsulation is the type of MPLS encapsulation (Frame Relay, ATM, Generic) of a packet when that packet is received on an LSR's interface, or the network layer (IP, etc...)encapsulation if that packet has no MPLS encapsulation.
当在LSR接口上接收到数据包时，输入封装是数据包的MPLS封装类型（帧中继、ATM、通用），或者如果该数据包没有MPLS封装，则为网络层（IP等）封装。
Output Encapsulation
输出封装
The Output Encapsulation is the type of MPLS encapsulation (Frame Relay, ATM, Generic) of a packet when that packet is transmitted on an LSR's interface, or the network layer (IP, etc...)encapsulation if that packet has no MPLS encapsulation.
当数据包在LSR接口上传输时，输出封装是数据包的MPLS封装类型（帧中继、ATM、通用），或者如果数据包没有MPLS封装，则输出封装是网络层（IP等）封装。
Input TTL
输入TTL
The Input TTL is the MPLS TTL of the top of the stack when a labeled packet is received on an LSR interface, or the network layer (IP) TTL if the packet is not labeled.
当在LSR接口上接收到标记的数据包时，输入TTL是堆栈顶部的MPLS TTL，如果数据包未标记，则输入TTL是网络层（IP）TTL。
Output TTL
输出TTL
The Output TTL is the MPLS TTL of the top of the stack when a labeled packet is transmitted on an LSR interface, or the network layer (IP) TTL if the packet is not labeled.
当在LSR接口上传输标记的数据包时，输出TTL是堆栈顶部的MPLS TTL，如果数据包未标记，则输出TTL是网络层（IP）TTL。
Additionally, this document uses terminology from [ARCH].
此外，本文件使用[ARCH]中的术语。
While the label switching architecture permits considerable
flexibility in LSR implementation, a FR-LSR is constrained by the
capabilities of the (possibly pre-existing) hardware and the
restrictions on such matters as frame format imposed by the
Multiprotocol Interconnect over Frame Relay [MIFR], or Frame Relay
standards [FRF], etc.... Because of these constraints, some special
procedures are required for FR-LSRs.
While the label switching architecture permits considerable
flexibility in LSR implementation, a FR-LSR is constrained by the
capabilities of the (possibly pre-existing) hardware and the
restrictions on such matters as frame format imposed by the
Multiprotocol Interconnect over Frame Relay [MIFR], or Frame Relay
standards [FRF], etc.... Because of these constraints, some special
procedures are required for FR-LSRs.
Some of the key features of Frame Relay switches that affect their behavior as LSRs are:
帧中继交换机作为LSR影响其行为的一些关键功能包括：
- the label swapping function is performed on fields (DLCI) in the frame's Frame Relay data link header; this dictates the size and placement of the label(s) in a packet. The size of the DLCI field can be 10 (default) or 23 bits, and it can span two or four bytes in the header.
- 标签交换功能在帧的帧中继数据链路报头中的字段（DLCI）上执行；这决定了标签在数据包中的大小和位置。DLCI字段的大小可以是10位（默认值）或23位，并且可以在报头中跨越两个或四个字节。
- there is generally no capability to perform a 'TTL-decrement' function as is performed on IP headers in routers.
- 通常不具备在路由器的IP头上执行“TTL递减”功能的能力。
- congestion control is performed by each node based on parameters that are passed at circuit creation. Flags in the frame headers may be set as a consequence of congestion, or exceeding the contractual parameters of the circuit.
- 拥塞控制由每个节点根据创建回路时传递的参数执行。帧头中的标志可作为拥塞的结果设置，或超过电路的合同参数。
- although in a standard switch it may be possible to configure multiple input DLCIs to one output DLCI resulting in a multipoint-to-point circuit, multipoint-to-multipoint VCs are generally not fully supported.
- 虽然在标准交换机中，可以将多个输入DLCI配置为一个输出DLCI，从而形成多点对点电路，但通常不完全支持多点对多点VCs。
This document describes ways of applying label switching to Frame Relay switches, which work within these constraints.
本文档描述了将标签切换应用于帧中继交换机的方法，这些交换机在这些约束条件下工作。
By default, all labeled packets should be transmitted with the generic label encapsulation as defined in [STACK], using the frame relay null encapsulation mechanism:
默认情况下，应使用[STACK]中定义的通用标签封装，使用帧中继空封装机制传输所有标记的数据包：
0 1 (Octets)
+-----------------------+-----------------------+
(Octets)0 | |
/ Q.922 Address /
/ (length 'n' equals 2 or 4) /
| |
+-----------------------+-----------------------+
n | . |
/ . /
/ MPLS packet /
| . |
+-----------------------+-----------------------+
0 1 (Octets)
+-----------------------+-----------------------+
(Octets)0 | |
/ Q.922 Address /
/ (length 'n' equals 2 or 4) /
| |
+-----------------------+-----------------------+
n | . |
/ . /
/ MPLS packet /
| . |
+-----------------------+-----------------------+
"n" is the length of the Q.922 Address which can be 2 or 4 octets.
“n”是Q.922地址的长度，可以是2或4个八位字节。
The Q.922 [ITU] representation of a DLCI (in canonical order - the first bit is stored in the least significant, i.e., the right-most bit of a byte in memory) [CANON] is the following:
DLCI的Q.922[ITU]表示（按规范顺序-第一位存储在最低有效位，即内存中字节的最右边位）[CANON]如下所示：
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(octet) 0 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
1 | DLCI(low order) | 0 | 0 | 0 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----+
(octet) 0 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
1 | DLCI(low order) | 0 | 0 | 0 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
10 bits DLCI
10位DLCI
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----00
(octet) 0 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----
1 | DLCI | 0 | 0 | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
2 | DLCI | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
3 | DLCI (low order) | 0 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
7 6 5 4 3 2 1 0 (bit order)
+-----+-----+-----+-----+-----+-----+-----+-----00
(octet) 0 | DLCI(high order) | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----
1 | DLCI | 0 | 0 | 0 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
2 | DLCI | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
3 | DLCI (low order) | 0 | 1 |
+-----+-----+-----+-----+-----+-----+-----+-----+
23 bits DLCI
23位DLCI
The use of the frame relay null encapsulation implies that labels implicitly encode the network protocol type.
使用帧中继空封装意味着标签隐式编码网络协议类型。
Rules regarding the construction of the label stack, and error messages returned to the frame source are also described in [STACK].
[stack]中还介绍了有关标签堆栈构造的规则以及返回到帧源的错误消息。
The generic encapsulation contains "n" labels for a label stack of depth "n" [STACK], where the top stack entry carries significant values for the EXP, S , and TTL fields [STACK] but not for the label, which is rather carried in the DLCI field of the Frame Relay data link header encoded in Q.922 [ITU] address format.
通用封装包含深度为“n”[stack]的标签堆栈的“n”标签，其中顶部堆栈条目包含EXP、S和TTL字段[stack]的有效值，但不包含标签的有效值，而标签则包含在以Q.922[ITU]地址格式编码的帧中继数据链路头的DLCI字段中。
Label switching is accomplished by associating labels with routes and using the label value to forward packets, including determining the value of any replacement label. See [ARCH] for further details. In a FR-LSR, the top (current) MPLS label is carried in the DLCI field of the Frame Relay data link layer header of the frame. The top label carries implicitly information about the network protocol type.
标签交换通过将标签与路由关联并使用标签值转发数据包来完成，包括确定任何替换标签的值。有关更多详细信息，请参见[ARCH]。在FR-LSR中，顶部（当前）MPLS标签携带在帧的帧中继数据链路层报头的DLCI字段中。顶部标签隐含了有关网络协议类型的信息。
For two connected FR-LSRs, a full-duplex connection must be available for LDP. The DLCI for the LDP VC is assigned a value by way of configuration, similar to configuring the DLCI used to run IP routing protocols between the switches.
对于两个连接的FR LSR，LDP必须具有全双工连接。LDP VC的DLCI通过配置的方式分配一个值，类似于配置用于在交换机之间运行IP路由协议的DLCI。
With the exception of this configured value, the DLCI values used for MPLS in the two directions of the link may be treated as belonging to two independent spaces, i.e., VCs may be half-duplex, each direction with its own DLCI.
除此配置值外，链路两个方向上用于mpl的DLCI值可被视为属于两个独立空间，即vc可为半双工，每个方向具有其自己的DLCI。
The allowable ranges of DLCIs, the size of DLCIs, and the support for VC merging MUST be communicated through LDP messages. Note that the range of DLCIs used for labels depends on the size of the DLCI field.
DLCI的允许范围、DLCI的大小以及对VC合并的支持必须通过LDP消息进行通信。请注意，用于标签的DLCI范围取决于DLCI字段的大小。
If <LSR1, LSR2, LSR3> is an LSP, it is possible that LSR1, LSR2, and LSR3 will use the same encoding of the label stack when transmitting packet P from LSR1, to LSR2, and then to LSR3. Such an LSP is homogeneous.
如果<LSR1，LSR2，LSR3>是一个LSP，那么在将数据包P从LSR1传输到LSR2，然后传输到LSR3时，LSR1，LSR2和LSR3可能会使用标签堆栈的相同编码。这样的LSP是同质的。
If <LSR1, LSR2, LSR3> is an LSP, it is possible that LSR1 will use one encoding of the label stack when transmitting packet P to LSR2, but LSR2 will use a different encoding when transmitting a packet P to LSR3. In general, the MPLS architecture supports LSPs with different label stack encodings on different hops. When a labeled packet is received, the LSR must decode it to determine the current value of the label stack, then must operate on the label stack to determine the new label value of the stack, and then encode the new value appropriately before transmitting the labeled packet to its next hop.
如果<LSR1，LSR2，LSR3>是一个LSP，那么在将分组P发送到LSR2时，LSR1可能会使用标签堆栈的一种编码，但在将分组P发送到LSR3时，LSR2将使用不同的编码。通常，MPLS体系结构支持在不同跳上使用不同标签堆栈编码的LSP。当接收到带标签的数据包时，LSR必须对其进行解码以确定标签堆栈的当前值，然后必须对标签堆栈进行操作以确定堆栈的新标签值，然后在将带标签的数据包传输到其下一跳之前对新值进行适当编码。
Naturally there will be MPLS networks which contain a combination of Frame Relay switches operating as LSRs, and other LSRs, which operate using other MPLS encapsulations, such as the Generic (MPLS shim header), or ATM encapsulation. In such networks there may be some LSRs, which have Frame Relay interfaces as well as MPLS Generic ("MPLS Shim") interfaces. This is one example of an LSR with different label stack encodings on different hops of the same LSP. Such an LSR may swap off a Frame Relay encoded label on an incoming interface and replace it with a label encoded into a Generic MPLS (MPLS shim) header on the outgoing interface.
自然会有MPLS网络，其中包含作为LSR运行的帧中继交换机和使用其他MPLS封装（如通用（MPLS垫片头）或ATM封装）运行的其他LSR的组合。在这种网络中，可能存在一些具有帧中继接口以及MPLS通用（“MPLS垫片”）接口的LSR。这是在同一LSP的不同跃点上具有不同标签堆栈编码的LSR的一个示例。这样的LSR可以交换传入接口上的帧中继编码标签，并用编码到传出接口上的通用MPLS（MPLS垫片）报头中的标签替换它。
FR-LSRs SHOULD operate on loop free FR-LSPs or LSP Frame Relay segments. Therefore, FR-LSRs SHOULD use loop detection and MAY use loop prevention mechanisms as described in [ARCH], and [LDP].
FR LSR应在无环路FR LSP或LSP帧中继段上运行。因此，FR LSR应使用环路检测，并可使用[ARCH]和[LDP]中所述的环路预防机制。
The MPLS TTL encoded in the MPLS label stack is a mechanism used to:
MPLS标签堆栈中编码的MPLS TTL是一种用于：
(a) suppress loops;
(a) 抑制循环；
(b) limit the scope of a packet.
(b) 限制数据包的范围。
When a packet travels along an LSP, it should emerge with the same TTL value that it would have had if it had traversed the same sequence of routers without having been label switched. If the packet travels along a hierarchy of LSPs, the total number of LSR-hops traversed should be reflected in its TTL value when it emerges from the hierarchy of LSPs [ARCH].
当一个数据包沿着LSP传输时，它应该以相同的TTL值出现，如果它在没有标签交换的情况下穿越相同的路由器序列，它应该具有相同的TTL值。如果数据包沿着LSP的层次结构移动，那么当它从LSP的层次结构中出现时，经过的LSR跳总数应该反映在其TTL值中[ARCH]。
The initial value of the MPLS TTL is loaded into a newly pushed label stack entry from the previous TTL value, whether that is from the network layer header when no previous label stack existed, or from a pre-existent lower level label stack entry.
MPLS TTL的初始值从上一个TTL值加载到新推送的标签堆栈条目中，无论该值是在不存在上一个标签堆栈时从网络层头加载的，还是从先前存在的较低级别标签堆栈条目加载的。
A FR-LSR switching same level labeled packets does not decrement the MPLS TTL. A sequence of such FR-LSR is a "non-TTL segment".
FR-LSR交换相同级别标记的数据包不会减少MPLS TTL。这种FR-LSR的序列是“非TTL段”。
When a packet emerges from a "non-TTL LSP segment", it should however reflect in the TTL the number of LSR-hops it traversed. In the unicast case, this can be achieved by propagating a meaningful LSP length or LSP Frame Relay segment length to the FR-LSR ingress nodes, enabling the ingress to decrement the TTL value before forwarding packets into a non-TTL LSP segment [ARCH].
当数据包从“非TTL LSP段”中出现时，它应该在TTL中反映它所经过的LSR跳数。在单播情况下，这可以通过向FR-LSR入口节点传播有意义的LSP长度或LSP帧中继段长度来实现，使得入口能够在将分组转发到非TTL LSP段[ARCH]之前减小TTL值。
When an ingress FR-LSR determines upon decrementing the MPLS TTL that a particular packet's TTL will expire before the packet reaches the egress of the "non-TTL LSP segment", the FR-LSR MUST not label switch the packet, but rather follow the specifications in [STACK] in an attempt to return an error message to the packet's source:
当入口FR-LSR在减少MPLS TTL时确定特定分组的TTL将在分组到达“非TTL LSP段”的出口之前过期时，FR-LSR不得标记交换分组，而是遵循[STACK]中的规范，试图将错误消息返回到分组的源：
- it treats the packet as an expired packet and return an ICMP message to its source.
- 它将该数据包视为过期数据包，并将ICMP消息返回其源。
- it forwards the packet, as an unlabeled packet, with a TTL that reflects the IP (network layer) forwarding.
- 它使用反映IP（网络层）转发的TTL将数据包作为未标记的数据包进行转发。
If the incoming TTL is 1, only the first option applies.
如果传入TTL为1，则只有第一个选项适用。
In the multicast case, a meaningful LSP length or LSP segment length is propagated to the FR-LSR egress node, enabling the egress to decrement the TTL value before forwarding packets out of the non-TTL LSP segment.
在多播情况下，有意义的LSP长度或LSP段长度被传播到FR-LSR出口节点，使得出口能够在将分组转发出非TTL LSP段之前减小TTL值。
The calculation applied to the "input TTL" that yields the "output TTL" depends on (i)the "input encapsulation", (ii)the "forwarding encapsulation", and (iii)the "output encapsulation". The relationship among (i),(ii), and (iii), can be defined as a function
应用于产生“输出TTL”的“输入TTL”的计算取决于（i）“输入封装”、（ii）“转发封装”和（iii）“输出封装”。（i）、（ii）和（iii）之间的关系可以定义为一个函数
"D" of "input encapsulation" (ie), "forwarding encapsulation" (fe), and "output encapsulation" (oe). Subsequently the calculation applied to the "input TTL" to yield the "output TTL" can be described as:
“输入封装”（ie）、“转发封装”（fe）和“输出封装”（oe）的“D”。随后，应用于“输入TTL”以产生“输出TTL”的计算可以描述为：
output TTL = input TTL - D(ie, fe, oe)
output TTL = input TTL - D(ie, fe, oe)
or in a brief notation:
或者简单地说：
output TTL = input TTL - d
输出TTL=输入TTL-d
where "d" has three possible values: "0","1", or "the number of hops of the LSP segment":
其中“d”有三个可能的值：“0”、“1”或“LSP段的跳数”：
For unicast transmission:
对于单播传输：
+================+=================+=================+=================+
| | Type of | Type of | Type of |
| d | Input | Forwarding | Output |
| | Encapsulation | Encapsulation | Encapsulation |
+================+=================+=================+=================+
| 0 | Frame Relay | Frame Relay | Frame Relay |
+----------------+-----------------+-----------------+-----------------+
| 1 | any | Generic MPLS | Generic MPLS |
+----------------+-----------------+-----------------+-----------------+
| number of hops | | Generic MPLS | |
| of | any | or | Frame Relay |
| LSP segment | |IP(network layer)| |
+================+=================+=================+=================+
+================+=================+=================+=================+
| | Type of | Type of | Type of |
| d | Input | Forwarding | Output |
| | Encapsulation | Encapsulation | Encapsulation |
+================+=================+=================+=================+
| 0 | Frame Relay | Frame Relay | Frame Relay |
+----------------+-----------------+-----------------+-----------------+
| 1 | any | Generic MPLS | Generic MPLS |
+----------------+-----------------+-----------------+-----------------+
| number of hops | | Generic MPLS | |
| of | any | or | Frame Relay |
| LSP segment | |IP(network layer)| |
+================+=================+=================+=================+
The "number of hops of the LSP segment" is the value of the "hop count" that is attached with the label used when the packet is forwarded, if LDP [LDP] has provided such a "hop count" value when it distributed the label for the LSP, that is the LDP message had a "hop count object". If LDP didn't provide a "hop count", or it provided an "unknown" value, the default value of the "number of hops of the segment" is 1.
“LSP段的跳数”是附加在分组转发时使用的标签上的“跳数”的值，如果LDP[LDP]在为LSP分发标签时提供了这样的“跳数”值，即LDP消息具有“跳数对象”。如果LDP没有提供“跳数”，或者它提供了“未知”值，“段的跳数”的默认值为1。
When sending a label binding upstream, the "hop count" associated with the corresponding binding from downstream, if different than the "unknown" value, MUST be incremented by 1, and the result transmitted upstream as the hop count associated with the new binding (the "unknown" value is transmitted unchanged). If the new "hop count" value exceeds the "maximum" value, the FR-LSR MUST NOT pass the binding upstream, but instead MUST send an error upstream [LDP][ARCH].
当向上游发送标签绑定时，与来自下游的相应绑定相关联的“跃点计数”（如果不同于“未知”值）必须增加1，并且向上游传输的结果作为与新绑定相关联的跃点计数（“未知”值传输不变）。如果新的“跃点计数”值超过“最大”值，则FR-LSR不得通过上游绑定，而是必须向上游[LDP][ARCH]发送错误。
For multicast transmission:
对于多播传输：
+================+=================+=================+=================+
| | Type of | Type of | Type of |
| d | Input | Forwarding | Output |
| | Encapsulation | Encapsulation | Encapsulation |
+================+=================+=================+=================+
| 0 | Frame Relay | Frame Relay | Frame Relay |
+----------------+-----------------+-----------------+-----------------+
| | | Generic MPLS | |
| 1 | any | or | Frame Relay |
| | |IP(network layer)| |
+----------------+-----------------+-----------------+-----------------+
| number of hops | | Generic MPLS | |
| of | Frame Relay | or | any |
| LSP segment | |IP(network layer)| |
+================+=================+=================+=================+
+================+=================+=================+=================+
| | Type of | Type of | Type of |
| d | Input | Forwarding | Output |
| | Encapsulation | Encapsulation | Encapsulation |
+================+=================+=================+=================+
| 0 | Frame Relay | Frame Relay | Frame Relay |
+----------------+-----------------+-----------------+-----------------+
| | | Generic MPLS | |
| 1 | any | or | Frame Relay |
| | |IP(network layer)| |
+----------------+-----------------+-----------------+-----------------+
| number of hops | | Generic MPLS | |
| of | Frame Relay | or | any |
| LSP segment | |IP(network layer)| |
+================+=================+=================+=================+
Referring to the "forwarding encapsulation" with the abbreviation "I" for IP (network layer), "G" for Generic MPLS, and "F" for Frame Relay MPLS, referring to an LSR interface with the abbreviation "i" if the input or output encapsulation is IP and no MPLS encapsulation, "g" when the input or output MPLS encapsulation is Generic MPLS, "f" when it is Frame Relay, "a" when it is ATM, and furthermore considering the symbols "iIf", "gGf", "fFf", etc... as LSRs with input, forwarding and output encapsulations as referred above, the following describes examples of TTL calculations for the Homogeneous and Heterogeneous LSPs discussed in previous sections:
对于IP（网络层），“G”表示通用MPLS，而“F”表示帧中继MPLS，如果输入或输出封装为IP且没有MPLS封装，则参考缩写为“I”的“转发封装”，如果输入或输出MPLS封装为通用MPLS，则参考缩写为“G”的LSR接口，“F”当它是帧中继时，“a”当它是ATM时，并且进一步考虑符号“iIf”、“gGf”、“fFf”等。。。作为具有如上所述的输入、转发和输出封装的LSR，以下描述了在前面章节中讨论的同质和异质LSP的TTL计算示例：
Homogeneous LSP
---------------
IP_ttl = n IP_ttl=mpls_ttl-1 = n-6
--------->iIf fIi--------->
| mpls_ttl = n-5 ^
| |
number of hops 1| Frame Relay |5
| |
V 2 3 4 |
fFf--->fFf--->fFf--->fFf
Homogeneous LSP
---------------
IP_ttl = n IP_ttl=mpls_ttl-1 = n-6
--------->iIf fIi--------->
| mpls_ttl = n-5 ^
| |
number of hops 1| Frame Relay |5
| |
V 2 3 4 |
fFf--->fFf--->fFf--->fFf
"iIf" is "ingress LSR" in Frame Relay LSP and
calculates: mpls_ttl = IP_TTL - number of hops = n-5
"fIi" is "egress LSR" from Frame Relay LSP, and
calculates: IP_ttl = mpls_ttl-1 = n-6
"iIf" is "ingress LSR" in Frame Relay LSP and
calculates: mpls_ttl = IP_TTL - number of hops = n-5
"fIi" is "egress LSR" from Frame Relay LSP, and
calculates: IP_ttl = mpls_ttl-1 = n-6
Heterogeneous LSP
-----------------
ingress LSR egress LSR
IP_ttl = n IP_ttl = n - 15
links LAN PPP FR ATM PPP FR LAN
--->iIg-->gGg-->gGf fGa aGg-->gGf fGg-->gIi--->
hops 1 2 | 6 | | 9 | 10 | 13 ^ 14 15
|1 4| |1 3| |1 3|
V 2 3 | V 2 | V 2 |
fFf-->fFf-->fFf aAa-->aAa fFf-->fFf
mpls_ttl
n-1 n-2 (n-2)-4=n-6 (n-6)-3=n-9 n-10 n-13 n-14
Heterogeneous LSP
-----------------
ingress LSR egress LSR
IP_ttl = n IP_ttl = n - 15
links LAN PPP FR ATM PPP FR LAN
--->iIg-->gGg-->gGf fGa aGg-->gGf fGg-->gIi--->
hops 1 2 | 6 | | 9 | 10 | 13 ^ 14 15
|1 4| |1 3| |1 3|
V 2 3 | V 2 | V 2 |
fFf-->fFf-->fFf aAa-->aAa fFf-->fFf
mpls_ttl
n-1 n-2 (n-2)-4=n-6 (n-6)-3=n-9 n-10 n-13 n-14
"iIg" is "ingress LSR" in LSP; it calculates: mpls_ttl=n-1
"gGf" is "egress LSR" from Generic MPLS segment, and
"ingress LSR" in Frame Relay segment and calculates: mpls_ttl=n-6
"fGa" "egress LSR" from Frame Relay segment, and
"ingress LSR" in ATM segment and calculates: mpls_ttl=n-9
"gGf" is "egress LSR" from Generic MPLS segment, and
"ingress LSR" in Frame Relay segment and calculates: mpls_ttl=n-13
"fGg" is "egress LSR" from Frame Relay segment, and
ingress LSR" in Generic MPLS segment and calculates: mpls_ttl=n-14
"gIi" is "egress LSR" from LSP and calculates: IP_ttl=n-15
"iIg" is "ingress LSR" in LSP; it calculates: mpls_ttl=n-1
"gGf" is "egress LSR" from Generic MPLS segment, and
"ingress LSR" in Frame Relay segment and calculates: mpls_ttl=n-6
"fGa" "egress LSR" from Frame Relay segment, and
"ingress LSR" in ATM segment and calculates: mpls_ttl=n-9
"gGf" is "egress LSR" from Generic MPLS segment, and
"ingress LSR" in Frame Relay segment and calculates: mpls_ttl=n-13
"fGg" is "egress LSR" from Frame Relay segment, and
ingress LSR" in Generic MPLS segment and calculates: mpls_ttl=n-14
"gIi" is "egress LSR" from LSP and calculates: IP_ttl=n-15
And further examples:
还有其他例子：
Frame Relay Unicast -- TTL calculated at ingress
帧中继单播——在入口计算的TTL
(ingress LSR) 1 2 3 4
x--->---+--->---+--->>--+-->>---x (egress LSR)
o.ttl=i.ttl-4 | 2 3
^
hops 1|
|
x (ingress LSR)
o.ttl=i.ttl-3
(ingress LSR) 1 2 3 4
x--->---+--->---+--->>--+-->>---x (egress LSR)
o.ttl=i.ttl-4 | 2 3
^
hops 1|
|
x (ingress LSR)
o.ttl=i.ttl-3
Frame Relay Multicast -- TTL calculated at egress
帧中继多播——出口处计算的TTL
(egress LSR)x o.ttl=i.ttl-3
hops |
^3
(ingress LSR) | o.ttl=i.ttl-4
x--->---+--->---+--->---+--->---x (egress LSR)
1 2 3 4
(egress LSR)x o.ttl=i.ttl-3
hops |
^3
(ingress LSR) | o.ttl=i.ttl-4
x--->---+--->---+--->---+--->---x (egress LSR)
1 2 3 4
When a packet first enters an MPLS domain, the packet is forwarded by normal network layer forwarding operations with the exception that the outgoing encapsulation will include an MPLS label stack [STACK] with at least one entry. The frame relay null encapsulation will carry information about the network layer protocol implicitly in the label, which MUST be associated only with that network protocol. The TTL field in the top label stack entry is filled with the network layer TTL (or hop limit) resulted after network layer forwarding [STACK]. The further FR-LSR processing is similar in both possible cases:
当数据包第一次进入MPLS域时，该数据包通过正常的网络层转发操作进行转发，但传出封装将包括具有至少一个条目的MPLS标签栈[栈]。帧中继空封装将在标签中隐式携带有关网络层协议的信息，该标签必须仅与该网络协议关联。top label stack条目中的TTL字段由网络层转发[stack]后产生的网络层TTL（或跃点限制）填充。在两种可能的情况下，进一步的FR-LSR处理类似：
(a) the LSP is homogeneous -- Frame Relay only -- and the FR-LSR is the ingress.
(a) LSP是同构的（仅限帧中继），FR-LSR是入口。
(b) the LSP is heterogeneous -- Frame Relay, PPP, Ethernet, ATM, etc... segments form the LSP -- and the FR-LSR is the ingress into a Frame Relay segment.
(b) the LSP is heterogeneous -- Frame Relay, PPP, Ethernet, ATM, etc... segments form the LSP -- and the FR-LSR is the ingress into a Frame Relay segment.translate error, please retry
For unicast packets, the MPLS TTL SHOULD be decremented with the number of hops of the Frame Relay LSP (homogeneous), or Frame Relay segment of the LSP (heterogeneous). An LDP constructing the LSP SHOULD pass meaningful information to the ingress FR-LSR regarding the number of hops of the "non-TTL segment".
对于单播分组，MPLS TTL应随着帧中继LSP（同质）或LSP（异质）的帧中继段的跳数而减小。构造LSP的LDP应当向入口FR-LSR传递关于“非TTL段”的跳数的有意义的信息。
For multicast packets, the MPLS TTL SHOULD be decremented by 1. An LDP constructing the LSP SHOULD pass meaningful information to the egress FR-LSR regarding the number of hops of the "non-TTL segment".
对于多播数据包，MPLS TTL应该减少1。构造LSP的LDP应当向出口FR-LSR传递关于“非TTL段”的跳数的有意义的信息。
Next, the MPLS encapsulated packet is passed down to the Frame Relay data link driver with the top label as output DLCI. The Frame Relay frame carrying the MPLS encapsulated packet is forwarded onto the Frame Relay VC to the next LSR.
接下来，将MPLS封装的分组向下传递到帧中继数据链路驱动器，顶部标签作为输出DLCI。承载MPLS封装的分组的帧中继帧被转发到帧中继VC上到下一个LSR。
In a FR-LSR, the current (top) MPLS label is carried in the DLCI field of the Frame Relay data link layer header of the frame. Just as in conventional Frame Relay, for a frame arriving at an interface, the DLCI carried by the Frame Relay data link header is looked up in the DLCI Information Base, replaced with the correspondent output DLCI, and transmitted on the outgoing interface (forwarded to the next hop node).
在FR-LSR中，当前（顶部）MPLS标签携带在帧的帧中继数据链路层报头的DLCI字段中。与传统的帧中继一样，对于到达接口的帧，帧中继数据链路报头携带的DLCI在DLCI信息库中查找，替换为相应的输出DLCI，并在输出接口上传输（转发到下一跳节点）。
The current label information is also carried in the top of the label stack. In the top-level entry, all fields except the label information, which is carried and switched in the Frame Relay frame data link-layer header, are of current significance.
当前标签信息也包含在标签堆栈的顶部。在顶层条目中，除了标签信息（在帧中继帧数据链路层报头中携带和切换）之外的所有字段都具有当前意义。
When reaching the end of a Frame Relay LSP, the FR-LSR pops the label stack [ARCH]. If the label popped is the last label, it is necessary to determine the particular network layer protocol which is being carried. The label stack carries no explicit information to identify the network layer protocol. This must be inferred from the value of the label which is popped from the stack.
当到达帧中继LSP的末端时，FR-LSR弹出标签堆栈[ARCH]。如果弹出的标签是最后一个标签，则需要确定正在承载的特定网络层协议。标签堆栈不携带用于标识网络层协议的明确信息。这必须从从堆栈中弹出的标签值推断出来。
If the label popped is not the last label, the previous top level MPLS TTL is propagated to the new top label stack entry.
如果弹出的标签不是最后一个标签，则先前的顶级MPLS TTL将传播到新的顶级标签堆栈项。
If the FR-LSR is the egress switch of a Frame Relay segment of a hybrid LSP, and the end of the Frame Relay segment is not the end of the LSP, the MPLS packet will be processed for forwarding onto the next segment of the LSP based on the information held in the Next Hop Label Forwarding Entry (NHLFE) [ARCH]. The output label is set to the value from the NHLFE, and the MPLS TTL is decremented by the appropriate value depending the type of the output interface and the type of transmit operation (see section 6.3). Further, the MPLS packet is forwarded according to the MPLS specifications for the particular link of the next segment of the LSP.
如果FR-LSR是混合LSP的帧中继段的出口交换机，并且帧中继段的末端不是LSP的末端，则将基于下一跳标签转发条目（NHLFE）中保存的信息来处理MPLS分组以转发到LSP的下一段[ARCH]。输出标签设置为NHLFE的值，MPLS TTL根据输出接口的类型和传输操作的类型减少适当的值（见第6.3节）。此外，根据用于LSP的下一段的特定链路的MPLS规范转发MPLS分组。
For unicast packets, the MPLS TTL SHOULD be decremented by one if the output interface is a generic one, or with the number of hops of the next ATM segment of the LSP (heterogeneous), if the output interface is an ATM (non-TTL) interface.
对于单播数据包，如果输出接口是通用接口，则MPLS TTL应减少1；如果输出接口是ATM（非TTL）接口，则应减少LSP（异构）下一个ATM段的跳数。
For multicast packets, the MPLS TTL SHOULD be decremented by the number of hops of the FR segment being exited. An LDP constructing the LSP SHOULD pass meaningful information to the egress FR-LSR regarding the number of hops of the FR "non-TTL segment".
对于多播数据包，MPLS TTL应该减少正在退出的FR段的跳数。构造LSP的LDP应当向出口FR-LSR传递关于FR“非TTL段”的跳数的有意义的信息。
To support label switching a Frame Relay Switch MUST implement the control component of label switching, which consists primarily of label allocation and maintenance procedures. Label binding information MAY be communicated by several mechanisms, one of which is the Label Distribution Protocol (LDP) [LDP].
为了支持标签切换，帧中继交换机必须实现标签切换的控制组件，该组件主要包括标签分配和维护程序。标签绑定信息可以通过几种机制进行通信，其中之一是标签分发协议（LDP）[LDP]。
Since the label switching control component uses information learned directly from network layer routing protocols, this implies that the switch MUST participate as a peer in these protocols (e.g., OSPF, IS-IS).
由于标签交换控制组件使用直接从网络层路由协议学习的信息，这意味着交换机必须作为对等方参与这些协议（例如，OSPF、IS-IS）。
In some cases, LSRs may use other protocols (e.g., RSVP, PIM, BGP) to distribute label bindings. In these cases, a Frame Relay LSR should participate in these protocols.
在某些情况下，LSR可能使用其他协议（如RSVP、PIM、BGP）来分发标签绑定。在这些情况下，帧中继LSR应该参与这些协议。
In the case where Frame Relay circuits are established via LDP, or RSVP, or others, with no involvement from traditional Frame Relay mechanisms, it is assumed that circuit establishing contractual information such as input/output maximum frame size, incoming/outgoing requested/agreed throughput, incoming/outgoing acceptable throughput, incoming/outgoing burst size, incoming/outgoing frame rate, used in transmitting, and congestion control MAY be passed to the FR-LSRs through RSVP, or can be statically configured. It is also assumed that congestion control and frame header flagging as a consequence of congestion, would be done by the FR-LSRs in a similar fashion as for traditional Frame Relay circuits. With the goal of emulating a best-effort router as default, the default VC parameters, in the absence of LDP, RSVP, or other mechanisms participation to setting such parameters, should be zero CIR, so that input policing will set the DE bit in incoming frames, but no frames are dropped.
在通过LDP或RSVP或其他方式建立帧中继电路而不涉及传统帧中继机制的情况下，假设建立契约信息的电路，例如输入/输出最大帧大小、传入/传出请求/约定吞吐量、传入/传出可接受吞吐量，传入/传出突发大小、用于传输的传入/传出帧速率和拥塞控制可以通过RSVP传递给FR lsr，或者可以静态配置。还假设，由于拥塞，FR LSR将以与传统帧中继电路类似的方式进行拥塞控制和帧报头标记。出于将尽力而为路由器模拟为默认值的目的，在没有LDP、RSVP或其他机制参与设置此类参数的情况下，默认VC参数应为零CIR，以便输入监控将在传入帧中设置DE位，但不会丢弃任何帧。
Control and state information for the circuits based on MPLS MAY be communicated through LDP.
基于MPLS的电路的控制和状态信息可以通过LDP进行通信。
Support of label switching on a Frame Relay switch requires conformance only to [FRF] (framing, bit-stuffing, headers, FCS) except for section 2.3 (PVC control signaling procedures, aka LMI). Q.933 signaling for PVCs and/or SVCs is not required. PVC and/or SVC signaling may be used for non-MPLS (standard Frame Relay) PVCs and/or SVCs when both are running on the same interface as MPLS, as discussed in the next section.
除了第2.3节（PVC控制信令程序，又名LMI）之外，支持帧中继交换机上的标签切换只需要符合[FRF]（成帧、比特填充、报头、FCS）。Q.933不需要PVC和/或SVC的信号。PVC和/或SVC信令可用于非MPLS（标准帧中继）PVC和/或SVC，当两者在与MPLS相同的接口上运行时，如下一节所述。
The existence of the label switching control component on a Frame Relay switch does not preclude the ability to support the Frame Relay control component defined by the ITU and Frame Relay Forum on the same switch and the same interfaces (NICs). The two control components, label switching and those defined by ITU/Frame Relay Forum, would operate independently.
帧中继交换机上存在标签交换控制组件并不排除在同一交换机和同一接口（NIC）上支持ITU和帧中继论坛定义的帧中继控制组件的能力。标签交换和ITU/帧中继论坛定义的两个控制组件将独立运行。
Definition of how such a device operates is beyond the scope of this document. However, only a small amount of information needs to be consistent between the two control components, such as the portions of the DLCI space which are available to each component.
此类设备如何运行的定义超出了本文件的范围。然而，只有少量信息需要在两个控制组件之间保持一致，例如每个组件可用的DLCI空间部分。
The mechanisms and message formats of a Label Distribution Protocol are documented in [ARCH] and [LDP]. The "downstream-on-demand" label allocation and maintenance mechanism discussed in this section MUST be used by FR-LSRs that do not support VC merging, and it MAY also be used by FR-LSRs that do support VC merging (note that this mechanism applies to hop-by-hop routed traffic):
标签分发协议的机制和消息格式见[ARCH]和[LDP]。本节讨论的“下游按需”标签分配和维护机制必须由不支持VC合并的FR LSR使用，也可由支持VC合并的FR LSR使用（注意，此机制适用于逐跳路由流量）：
Consider a member of the Edge Set of a FR-LSR domain. Assume that, as a result of its routing calculations, it selects a FR-LSR as the next hop of a certain route (FEC), and that the next hop is reachable via a LC-Frame Relay interface. Assume that the next-hop FR-LSR is an "LDP-peer" [ARCH][LDP]. The Edge LSR sends an LDP "request" message for a label binding from the next hop, downstream LSR. When the Edge LSR receives in response from the downstream LSR the label binding information in an LDP "mapping" message, the label is stored in the Label Information Base (LIB) as an outgoing label for that FEC. The "mapping" message may contain the "hop count" object, which represents the number of hops a packet will take to cross the FR-LSR domain to the Egress FR-LSR when using this label. This information may be stored for TTL calculation. Once this is done, the LSR may use MPLS forwarding to transmit packets in that FEC.
考虑FR LSR域的边缘集的成员。假设，作为其路由计算的结果，它选择FR-LSR作为特定路由（FEC）的下一跳，并且下一跳可通过LC帧中继接口到达。假设下一跳FR-LSR是“LDP对等方”[ARCH][LDP]。边缘LSR从下一跳（下游LSR）发送用于标签绑定的LDP“请求”消息。当边缘LSR响应地从下游LSR接收LDP“映射”消息中的标签绑定信息时，标签被存储在标签信息库（LIB）中，作为该FEC的传出标签。“映射”消息可以包含“跃点计数”对象，该对象表示当使用该标签时，数据包将通过FR-LSR域到达出口FR-LSR的跃点数。此信息可存储用于TTL计算。一旦完成，LSR可以使用MPLS转发来在该FEC中传输分组。
When a member of the Edge Set of the FR-LSR domain receives an LDP "request" message from a FR-LSR for a FEC, it means it is the Egress-FR-LSR. It allocates a label, creates a new entry in its Label Information Base (LIB), places that label in the incoming label component of the entry, and returns (via LDP) a "mapping" message containing the allocated label back upstream to the LDP peer that originated the request. The "mapping" message contains the "hop count" object value set to 1.
当FR-LSR域的边缘集的成员接收到来自FEC的FR-LSR的LDP“请求”消息时，这意味着它是出口FR LSR。它分配一个标签，在其标签信息库（LIB）中创建一个新条目，将该标签放置在条目的传入标签组件中，并（通过LDP）将包含分配标签的“映射”消息返回到发起请求的LDP对等方的上游。“映射”消息包含设置为1的“跃点计数”对象值。
When a routing calculation causes an Edge LSR to change the next hop for a route, and the former next hop was in the FR-LSR domain, the Edge LSR should notify the former next hop (via an LDP "release" message) that the label binding associated with the route is no longer needed.
当路由计算导致边缘LSR更改路由的下一个跃点，且前一个下一个跃点位于FR-LSR域中时，边缘LSR应通知前一个下一个跃点（通过LDP“release”消息）与路由关联的标签绑定不再需要。
When a Frame Relay-LSR receives an LDP "request" message for a certain route (FEC) from an LDP peer connected to the FR-LSR over a LC-FR interface, the FR-LSR takes the following actions:
当帧中继LSR从通过LC-FR接口连接到FR-LSR的LDP对等方接收到特定路由（FEC）的LDP“请求”消息时，FR-LSR采取以下动作：
- it allocates a label, creates a new entry in its Label Information Base (LIB), and places that label in the incoming label component of the entry;
- 它分配一个标签，在其标签信息库（LIB）中创建一个新条目，并将该标签放置在条目的传入标签组件中；
- it propagates the "request", by sending an LDP "request" message to the next hop LSR, downstream for that route (FEC);
- 它通过向该路由（FEC）下游的下一跳LSR发送LDP“请求”消息来传播“请求”；
In the "ordered control" mode [ARCH], the FR-LSR will wait for its "request" to be responded from downstream with a "mapping" message before returning the "mapping" upstream in response to a "request" ("ordered control" approach [ARCH]). In this case, the FR-LSR increments the hop count it received from downstream and uses this value in the "mapping" it returns upstream.
在“有序控制”模式[ARCH]中，FR-LSR将等待其“请求”得到下游“映射”消息的响应，然后返回上游“映射”以响应“请求”（“有序控制”方法[ARCH]）。在这种情况下，FR-LSR增加从下游接收的跃点计数，并在其返回上游的“映射”中使用该值。
Alternatively, the FR-LSR may return the binding upstream without waiting for a binding from downstream ("independent control" approach [ARCH]). In this case, it uses a reserved value for hop count in the "mapping", indicating that it is 'unknown'. The correct value for hop count will be returned later, as described below.
或者，FR-LSR可以在不等待下游绑定的情况下返回上游绑定（“独立控制”方法[ARCH]）。在这种情况下，它在“映射”中为跃点计数使用保留值，表示它是“未知的”。稍后将返回正确的跃点计数值，如下所述。
Since both the "ordered" and "independent" control has advantages and disadvantages, this is left as an implementation, or configuration choice.
由于“有序”和“独立”控制各有优缺点，因此这将作为一种实现或配置选择。
Once the FR-LSR receives in response the label binding in an LDP "mapping" message from the next hop, it places the label into the outgoing label component of the LIB entry.
一旦FR-LSR收到来自下一跳的LDP“映射”消息中的标签绑定作为响应，它就会将标签放入LIB条目的传出标签组件中。
Note that a FR-LSR, or a member of the edge set of a FR-LSR domain, may receive multiple binding requests for the same route (FEC) from the same FR-LSR. It must generate a new "mapping" for each "request" (assuming adequate resources to do so), and retain any existing mapping(s). For each "request" received, a FR-LSR should also generate a new binding "request" toward the next hop for the route (FEC).
注意，FR-LSR或FR-LSR域的边缘集的成员可以从同一FR-LSR接收同一路由（FEC）的多个绑定请求。它必须为每个“请求”生成一个新的“映射”（假设有足够的资源），并保留任何现有映射。对于接收到的每个“请求”，FR-LSR还应向路由的下一跳（FEC）生成新的绑定“请求”。
When a routing calculation causes a FR-LSR to change the next hop for a route (FEC), the FR-LSR should notify the former next hop (via an LDP "release" message) that the label binding associated with the route is no longer needed.
当路由计算导致FR-LSR更改路由（FEC）的下一跳时，FR-LSR应通知前一个下一跳（通过LDP“release”消息）与路由相关联的标签绑定不再需要。
When a LSR receives a notification that a particular label binding is no longer needed, the LSR may deallocate the label associated with the binding, and destroy the binding. This mode is the "conservative
当LSR收到不再需要特定标签绑定的通知时，LSR可能会取消分配与该绑定关联的标签，并销毁该绑定。这种模式是“保守的”
label retention mode" [ARCH]. In the case where a FR-LSR receives such notification and destroys the binding, it should notify the next hop for the route that the label binding is no longer needed. If a LSR does not destroy the binding (the FR-LSR is configured in "liberal label retention mode" [ARCH]), it may re-use the binding only if it receives a request for the same route with the same hop count as the request that originally caused the binding to be created.
标签保留模式“[ARCH]。如果FR-LSR收到此类通知并销毁绑定，它应通知路由的下一个跃点不再需要标签绑定。如果LSR未销毁绑定（FR-LSR在“自由标签保留模式”[ARCH]中配置），仅当它接收到与最初创建绑定的请求具有相同跳数的同一路由请求时，它才可以重新使用绑定。
When a route changes, the label bindings are re-established from the point where the route diverges from the previous route. LSRs upstream of that point are (with one exception, noted below) oblivious to the change. Whenever a LSR changes its next hop for a particular route, if the new next hop is a FR-LSR or a member of the edge set reachable via a LC-FR interface, then for each entry in its LIB associated with the route the LSR should request (via LDP) a binding from the new next hop.
当管线发生更改时，标签绑定将从管线偏离上一条管线的点重新建立。该点上游的LSR（有一个例外，如下所述）不受变化影响。每当LSR为特定路由更改其下一跳时，如果新的下一跳是FR-LSR或可通过LC-FR接口访问的边缘集的成员，则对于其LIB中与路由相关联的每个条目，LSR应（通过LDP）从新的下一跳请求绑定。
When a FR-LSR receives a label binding from a downstream neighbor, it may already have provided a corresponding label binding for this route to an upstream neighbor, either because it is using "independent control" or because the new binding from downstream is the result of a routing change. In this case, it should extract the hop count from the new binding and increment it by one. If the new hop count is different from that which was previously conveyed to the upstream neighbor (including the case where the upstream neighbor was given the value 'unknown') the FR-LSR must notify the upstream neighbor of the change. Each FR-LSR in turn increments the hop count and passes it upstream until it reaches the ingress Edge LSR.
当FR-LSR从下游邻居接收到标签绑定时，它可能已经为该路由向上游邻居提供了相应的标签绑定，因为它正在使用“独立控制”，或者因为来自下游的新绑定是路由更改的结果。在这种情况下，它应该从新绑定中提取跃点计数，并将其递增1。如果新的跃点计数不同于先前传送给上游邻居的跃点计数（包括上游邻居被赋予“未知”值的情况），则FR-LSR必须将该变化通知上游邻居。每个FR-LSR依次递增跃点计数并将其向上游传递，直到到达入口边缘LSR。
Whenever a FR-LSR originates a label binding request to its next hop LSR as a result of receiving a label binding request from another (upstream) LSR, and the request to the next hop LSR is not satisfied, the FR-LSR should destroy the binding created in response to the received request, and notify the requester (via an LDP "withdraw" message).
当FR-LSR由于接收到来自另一个（上游）LSR的标签绑定请求而向其下一跳LSR发起标签绑定请求，且对下一跳LSR的请求未得到满足时，FR-LSR应销毁响应接收到的请求而创建的绑定，并通知请求者（通过LDP“撤回”消息）。
When an LSR determines that it has lost its LDP session with another LSR, the following actions are taken:
当一个LSR确定它丢失了与另一个LSR的LDP会话时，将采取以下措施：
- MUST discard any binding information learned via this connection;
- 必须放弃通过此连接获取的任何绑定信息；
- For any label bindings that were created as a result of receiving label binding requests from the peer, the LSR may destroy these bindings (and deallocate labels associated with these binding).
- 对于由于从对等方接收标签绑定请求而创建的任何标签绑定，LSR可能会销毁这些绑定（并取消分配与这些绑定关联的标签）。
The above discussion assumes that an edge LSR will request one label for each prefix in its routing table that has a next hop in the FR-LSR domain. In fact, it is possible to significantly reduce the number of labels needed by having the edge LSR request instead one label for several routes. Use of many-to-one mappings between routes (address prefixes) and labels using the notion of Forwarding Equivalence Classes (as described in [ARCH]) provides a mechanism to conserve the number of labels.
上面的讨论假设边缘LSR将为其路由表中具有FR-LSR域中的下一跳的每个前缀请求一个标签。事实上，通过将边缘LSR请求改为多条路由的一个标签，可以显著减少所需标签的数量。使用转发等价类的概念（如[ARCH]中所述），在路由（地址前缀）和标签之间使用多对一映射，提供了一种保存标签数量的机制。
Note that conserving label space (VC merging) may be restricted in case the frame traffic requires Frame Relay fragmentation. The issue is that Frame Relay fragments must be transmitted in sequence, i.e., fragments of distinct frames must not be interleaved. If the fragmenting FR-LSR ensures the transmission in sequence of all fragments of a frame, without interleaving with fragments of other frames, then label conservation (VC merging) can be performed.
注意，在帧通信需要帧中继分段的情况下，保存标签空间（VC合并）可能会受到限制。问题是帧中继片段必须按顺序传输，即不同帧的片段不得交错。如果分段FR-LSR确保一个帧的所有片段按顺序传输，而不与其他帧的片段交错，则可以执行标签保护（VC合并）。
When label conservation is used, when a FR-LSR receives a binding request from an upstream LSR for a certain FEC, and it does already have an outgoing label binding for that FEC, it does not need to issue a downstream binding request. Instead, it may allocate an incoming label, and return that label in a binding to the upstream requester. Packets received from the requester, with that label as top label, will be forwarded after replacing the label with the existing outgoing label for that FEC. If the FR-LSR does not have an outgoing label binding for that FEC, but does have an outstanding request for one, it need not issue another request. This means that in a label conservation case, a FR-LSR must respond with a new binding for every upstream request, but it may need to send one binding request downstream.
当使用标签保护时，当FR-LSR从上游LSR接收到针对某个FEC的绑定请求，并且它已经具有针对该FEC的传出标签绑定时，它不需要发出下游绑定请求。相反，它可以分配一个传入标签，并将该标签以绑定的形式返回给上游请求者。从请求者接收到的数据包（该标签为顶部标签）将在用该FEC的现有传出标签替换标签后转发。如果FR-LSR没有该FEC的传出标签绑定，但有一个未完成的请求，则无需发出另一个请求。这意味着在标签保护情况下，FR-LSR必须为每个上游请求响应一个新绑定，但它可能需要向下游发送一个绑定请求。
In case of label conservation, if a change in the routing table causes FR-LSR to select a new next hop for one of its FECs, it MAY release the binding for that route from the former next hop. If it doesn't already have a corresponding binding for the new next hop, it must request one (note that the choice depends on the label retention mode [ARCH]).
在标签保护的情况下，如果路由表中的更改导致FR-LSR为其FEC之一选择新的下一跳，则它可能会从前一个下一跳中释放该路由的绑定。如果它还没有新的下一跳的相应绑定，它必须请求一个（注意，选择取决于标签保留模式[ARCH]）。
If a new binding is obtained, which contain a hop count that differs from that of the old binding, the FR-LSR must process the new hop count: increment by 1, if different than "unknown", and notify the upstream neighbors who have label bindings for this FEC of the new value. To ensure that loops will be detected, if the new hop count exceeds the "maximum" value, the label values for this FEC must be withdrawn from all upstream neighbors to whom a binding was previously sent.
如果获得新绑定，其中包含与旧绑定不同的跃点计数，FR-LSR必须处理新的跃点计数：递增1，如果不同于“未知”，并将新值通知具有此FEC标签绑定的上游邻居。为确保检测到循环，如果新的跃点计数超过“最大”值，则必须从先前向其发送绑定的所有上游邻居中提取此FEC的标签值。
The Label Distribution Protocol [LDP] messages exchanged between two Frame Relay "LDP-peer" LSRs may contain Frame Relay specific information such as:
在两个帧中继“LDP对等”LSR之间交换的标签分发协议[LDP]消息可以包含帧中继特定信息，例如：
"Frame Relay Label Range":
“帧中继标签范围”：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Len| Minimum DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Maximum DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Len| Minimum DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Maximum DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
with the following fields:
具有以下字段：
Reserved This fields are reserved. They must be set to zero on transmission and must be ignored on receipt.
保留此字段为保留字段。它们在传输时必须设置为零，在接收时必须忽略。
Len This field specifies the number of bits of the DLCI. The following values are supported:
Len此字段指定DLCI的位数。支持以下值：
Len DLCI bits
Len-DLCI位
0 10 2 23
0 10 2 23
Len values 1 and 3 are reserved for future use.
Len值1和3保留供将来使用。
Minimum DLCI This 23 bit field is the binary value of the lower bound of a block of Data Link Connection Identifiers (DLCIs) that is supported by the originating FR-LSR. The Minimum DLCI should be right justified in this field and the preceding bits should be set to 0.
最小DLCI此23位字段是原始FR-LSR支持的数据链路连接标识符（DLCI）块下限的二进制值。最小DLCI应在此字段中右对齐，并且前面的位应设置为0。
Maximum DLCI This 23 bit field is the binary value of the upper bound of a block of Data Link Connection Identifiers (DLCIs) that is supported by the originating FR-LSR. The Maximum DLCI should be right justified in this field and the preceding bits should be set to 0.
最大DLCI此23位字段是原始FR-LSR支持的数据链路连接标识符（DLCI）块上限的二进制值。此字段中的最大DLCI应右对齐，并且前面的位应设置为0。
"Frame Relay Merge":
“帧中继合并”：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |M|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |M|
+-+-+-+-+-+-+-+-+
with the following fields:
具有以下字段：
Merge One bit field that specifies the merge capabilities of the FR-LSR:
合并一位字段，指定FR-LSR的合并功能：
Value Meaning
价值意义
0 Merge NOT supported 1 Merge supported
不支持0合并不支持1合并
A FR-LSR that supports VC merging MUST ensure that fragmented frames from distinct incoming DLCIs are not interleaved on the outgoing DLCI.
支持VC合并的FR-LSR必须确保来自不同传入DLCI的碎片帧不会在传出DLCI上交错。
Reserved This field is reserved. It must be set to zero on transmission and must be ignored on receipt.
保留此字段为保留字段。传输时必须将其设置为零，接收时必须忽略。
and "Frame Relay Label":
和“帧中继标签”：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Len| DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Len| DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
with the following fields:
具有以下字段：
Reserved This field is reserved. It must be set to zero on transmission and must be ignored on receipt.
保留此字段为保留字段。传输时必须将其设置为零，接收时必须忽略。
Len This field specifies the number of bits of the DLCI. The following values are supported:
Len此字段指定DLCI的位数。支持以下值：
Len DLCI bits
Len-DLCI位
0 10 2 23
0 10 2 23
Len values 1 and 3 are reserved for future use.
Len值1和3保留供将来使用。
DLCI The binary value of the Frame Relay Label. The significant number of bits (10 or 23) of the label value are to be encoded into the Data Link Connection Identifier (DLCI) field when part of the Frame Relay data link header (see Section 4.).
DLCI帧中继标签的二进制值。作为帧中继数据链路头的一部分时，标签值的有效位数（10或23）将被编码到数据链路连接标识符（DLCI）字段中（参见第4节）。
This section looks at the security aspects of:
本节介绍以下方面的安全性：
(a) frame traffic,
(a) 帧通信量，
(b) label distribution.
(b) 标签分发。
MPLS encapsulation has no effect on authenticated or encrypted network layer packets, that is IP packets that are authenticated or encrypted will incur no change.
MPLS封装对经过身份验证或加密的网络层数据包没有影响，也就是说，经过身份验证或加密的IP数据包不会发生任何更改。
The MPLS protocol has no mechanisms of its own to protect against misdirection of packets or the impersonation of an LSR by accident or malicious intent.
MPLS协议没有自己的机制来防止数据包的错误定向或由于意外或恶意意图而模拟LSR。
Altering by accident or forgery an existent label in the DLCI field of the Frame Relay data link layer header of a frame or one or more fields in a potentially following label stack affects the forwarding of that frame.
意外更改或伪造帧的帧中继数据链路层报头的DLCI字段中的现有标签或潜在后续标签堆栈中的一个或多个字段会影响该帧的转发。
The label distribution mechanism can be secured by applying the appropriate level of security to the underlying protocol carrying label information - authentication or encryption - see [LDP].
标签分发机制可以通过对承载标签信息的底层协议（身份验证或加密）应用适当的安全级别来实现安全保护，请参见[LDP]。
The initial version of this document was derived from the Label Switching over ATM document [ATM].
本文档的初始版本源自ATM文档[ATM]上的标签交换。
Thanks for the extensive reviewing and constructive comments from (in alphabetical order) Dan Harrington, Milan Merhar, Martin Mueller, Eric Rosen. Also thanks to George Swallow for the suggestion to use null encapsulation, and to Eric Gray for his reviewing.
感谢Dan Harrington、Milan Merhar、Martin Mueller、Eric Rosen（按字母顺序）的广泛评论和建设性意见。还要感谢George Swallow建议使用空封装，以及Eric Gray的评论。
Also thanks to Nancy Feldman and Bob Thomas for their collaboration in including the LDP messages specific to Frame Relay LSRs.
还要感谢Nancy Feldman和Bob Thomas在包括帧中继LSR特定的LDP消息方面的合作。
[MIFR] Bradley, T., Brown, C. and A. Malis, "Multiprotocol Interconnect over Frame Relay", RFC 2427, September 1998.
[MIFR]Bradley，T.，Brown，C.和A.Malis，“帧中继上的多协议互连”，RFC 2427，1998年9月。
[ARCH] Rosen, E., Callon, R. and A. Vishwanathan, "Multi-Protocol Label Switching Architecture", RFC 3031, January 2001.
[ARCH]Rosen，E.，Callon，R.和A.Vishwanathan，“多协议标签交换架构”，RFC 3031，2001年1月。
[LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and R. Thomas, "Label Distribution Protocol", RFC 3036, January 2001.
[LDP]Andersson，L.，Doolan，P.，Feldman，N.，Fredette，A.和R.Thomas，“标签分发协议”，RFC 3036，2001年1月。
[STACK] Rosen, E., Rehter, Y., Tappan, D., Farinacci, D., Fedorkow, G., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[STACK]Rosen，E.，Rehter，Y.，Tappan，D.，Farinaci，D.，Fedorkow，G.，Li，T.和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月。
[ATM] Davie, B., Lawrence, J., McCloghrie, M., Rosen, E., Swallow, G., Rekhter, Y., and P. Doolan, "Use of Label Switching with ATM", RFC 3035, January 2001.
[ATM]Davie，B.，Lawrence，J.，McCloghrie，M.，Rosen，E.，Swallow，G.，Rekhter，Y.，和P.Doolan，“标签交换与ATM的使用”，RFC 3035，2001年1月。
[ITU] International Telecommunications Union, "ISDN Data Link Layer Specification for Frame Mode Bearer Services", ITU-T Recommendation Q.922, 1992.
[ITU]国际电信联盟，“帧模式承载业务的ISDN数据链路层规范”，ITU-T建议Q.922，1992年。
[FRF] Frame Relay Forum, User-to-Network Implementation Agreement (UNI), FRF 1.1, January 19, 1996.
[FRF]帧中继论坛，用户到网络实施协议（UNI），FRF 1.11996年1月19日。
Alex Conta Transwitch Corporation 3 Enterprise Drive Shelton, CT 06484
Alex Conta Transwitch Corporation 3企业大道谢尔顿，CT 06484
Phone: 1-203-929-8810 EMail: aconta@txc.com
电话：1-203-929-8810电子邮件：aconta@txc.com
Paul Doolan Ennovate Networks 60 Codman Hill Rd Boxborough MA 01719
保罗·杜兰·恩诺瓦特网络马萨诸塞州博克斯伯勒市科德曼山路60号01719
Phone: 1-978-263-2002 EMail: pdoolan@ennovatenetworks.com
电话：1-978-263-2002电子邮件：pdoolan@ennovatenetworks.com
Andrew G. Malis Vivace Networks, Inc. 2730 Orchard Parkway San Jose, CA 95134 USA
Andrew G.Malis Vivace Networks，Inc.美国加利福尼亚州圣何塞市果园大道2730号，邮编95134
Phone: 1-408-383-7223 Fax: 1-408-904-4748 EMail: Andy.Malis@vivacenetworks.com
电话：1-408-383-7223传真：1-408-904-4748电子邮件：安迪。Malis@vivacenetworks.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。