Internet Engineering Task Force (IETF) S. Ratliff
Request for Comments: 8175 VT iDirect
Category: Standards Track S. Jury
ISSN: 2070-1721 Cisco Systems
D. Satterwhite
Broadcom
R. Taylor
Airbus Defence & Space
B. Berry
June 2017
Internet Engineering Task Force (IETF) S. Ratliff
Request for Comments: 8175 VT iDirect
Category: Standards Track S. Jury
ISSN: 2070-1721 Cisco Systems
D. Satterwhite
Broadcom
R. Taylor
Airbus Defence & Space
B. Berry
June 2017
Dynamic Link Exchange Protocol (DLEP)
动态链路交换协议（DLEP）
Abstract
摘要
When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make routing decisions. In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. This document introduces a new protocol called the Dynamic Link Exchange Protocol (DLEP), which provides a bidirectional, event-driven communication channel between the router and the modem to facilitate communication of changing link characteristics.
当路由设备依赖调制解调器通过无线链路进行通信时，它们需要及时准确地了解链路的特性（速度、状态等），以便做出路由决策。在这些特性频繁变化的移动或其他环境中，手动配置或通过路由或传输协议推断状态不允许路由器做出最佳决策。本文档介绍了一种称为动态链路交换协议（DLEP）的新协议，该协议在路由器和调制解调器之间提供了一个双向、事件驱动的通信通道，以促进不断变化的链路特性的通信。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8175.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8175.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................4
2. Protocol Overview ...............................................7
2.1. Destinations ...............................................8
2.2. Conventions and Terminology ................................9
3. Requirements ....................................................9
4. Implementation Scenarios .......................................10
5. Assumptions ....................................................10
6. Metrics ........................................................11
7. DLEP Session Flow ..............................................12
7.1. Peer Discovery State ......................................12
7.2. Session Initialization State ..............................14
7.3. In-Session State ..........................................14
7.3.1. Heartbeats .........................................15
7.4. Session Termination State .................................15
7.5. Session Reset State .......................................16
7.5.1. Unexpected TCP Connection Termination ..............16
8. Transaction Model ..............................................16
9. Extensions .....................................................17
9.1. Experiments ...............................................18
10. Scalability ...................................................18
11. DLEP Signal and Message Structure .............................18
11.1. DLEP Signal Header .......................................19
11.2. DLEP Message Header ......................................20
11.3. DLEP Generic Data Item ...................................20
12. DLEP Signals and Messages .....................................21
12.1. General Processing Rules .................................21
12.2. Status Code Processing ...................................22
12.3. Peer Discovery Signal ....................................22
12.4. Peer Offer Signal ........................................23
12.5. Session Initialization Message ...........................23
1. Introduction ....................................................4
2. Protocol Overview ...............................................7
2.1. Destinations ...............................................8
2.2. Conventions and Terminology ................................9
3. Requirements ....................................................9
4. Implementation Scenarios .......................................10
5. Assumptions ....................................................10
6. Metrics ........................................................11
7. DLEP Session Flow ..............................................12
7.1. Peer Discovery State ......................................12
7.2. Session Initialization State ..............................14
7.3. In-Session State ..........................................14
7.3.1. Heartbeats .........................................15
7.4. Session Termination State .................................15
7.5. Session Reset State .......................................16
7.5.1. Unexpected TCP Connection Termination ..............16
8. Transaction Model ..............................................16
9. Extensions .....................................................17
9.1. Experiments ...............................................18
10. Scalability ...................................................18
11. DLEP Signal and Message Structure .............................18
11.1. DLEP Signal Header .......................................19
11.2. DLEP Message Header ......................................20
11.3. DLEP Generic Data Item ...................................20
12. DLEP Signals and Messages .....................................21
12.1. General Processing Rules .................................21
12.2. Status Code Processing ...................................22
12.3. Peer Discovery Signal ....................................22
12.4. Peer Offer Signal ........................................23
12.5. Session Initialization Message ...........................23
12.6. Session Initialization Response Message ..................24
12.7. Session Update Message ...................................26
12.8. Session Update Response Message ..........................27
12.9. Session Termination Message ..............................28
12.10. Session Termination Response Message ....................28
12.11. Destination Up Message ..................................28
12.12. Destination Up Response Message .........................30
12.13. Destination Announce Message ............................30
12.14. Destination Announce Response Message ...................31
12.15. Destination Down Message ................................32
12.16. Destination Down Response Message .......................33
12.17. Destination Update Message ..............................33
12.18. Link Characteristics Request Message ....................35
12.19. Link Characteristics Response Message ...................35
12.20. Heartbeat Message .......................................36
13. DLEP Data Items ...............................................37
13.1. Status ...................................................38
13.2. IPv4 Connection Point ....................................41
13.3. IPv6 Connection Point ....................................42
13.4. Peer Type ................................................43
13.5. Heartbeat Interval .......................................45
13.6. Extensions Supported .....................................45
13.7. MAC Address ..............................................46
13.8. IPv4 Address .............................................47
13.8.1. IPv4 Address Processing ...........................48
13.9. IPv6 Address .............................................49
13.9.1. IPv6 Address Processing ...........................50
13.10. IPv4 Attached Subnet ....................................51
13.10.1. IPv4 Attached Subnet Processing ..................52
13.11. IPv6 Attached Subnet ....................................53
13.11.1. IPv6 Attached Subnet Processing ..................54
13.12. Maximum Data Rate (Receive) .............................55
13.13. Maximum Data Rate (Transmit) ............................56
13.14. Current Data Rate (Receive) .............................56
13.15. Current Data Rate (Transmit) ............................57
13.16. Latency .................................................58
13.17. Resources ...............................................59
13.18. Relative Link Quality (Receive) .........................60
13.19. Relative Link Quality (Transmit) ........................60
13.20. Maximum Transmission Unit (MTU) .........................61
14. Security Considerations .......................................62
15. IANA Considerations ...........................................63
15.1. Registrations ............................................63
15.2. Signal Type Registrations ................................63
15.3. Message Type Registrations ...............................64
15.4. DLEP Data Item Registrations .............................65
15.5. DLEP Status Code Registrations ...........................66
12.6. Session Initialization Response Message ..................24
12.7. Session Update Message ...................................26
12.8. Session Update Response Message ..........................27
12.9. Session Termination Message ..............................28
12.10. Session Termination Response Message ....................28
12.11. Destination Up Message ..................................28
12.12. Destination Up Response Message .........................30
12.13. Destination Announce Message ............................30
12.14. Destination Announce Response Message ...................31
12.15. Destination Down Message ................................32
12.16. Destination Down Response Message .......................33
12.17. Destination Update Message ..............................33
12.18. Link Characteristics Request Message ....................35
12.19. Link Characteristics Response Message ...................35
12.20. Heartbeat Message .......................................36
13. DLEP Data Items ...............................................37
13.1. Status ...................................................38
13.2. IPv4 Connection Point ....................................41
13.3. IPv6 Connection Point ....................................42
13.4. Peer Type ................................................43
13.5. Heartbeat Interval .......................................45
13.6. Extensions Supported .....................................45
13.7. MAC Address ..............................................46
13.8. IPv4 Address .............................................47
13.8.1. IPv4 Address Processing ...........................48
13.9. IPv6 Address .............................................49
13.9.1. IPv6 Address Processing ...........................50
13.10. IPv4 Attached Subnet ....................................51
13.10.1. IPv4 Attached Subnet Processing ..................52
13.11. IPv6 Attached Subnet ....................................53
13.11.1. IPv6 Attached Subnet Processing ..................54
13.12. Maximum Data Rate (Receive) .............................55
13.13. Maximum Data Rate (Transmit) ............................56
13.14. Current Data Rate (Receive) .............................56
13.15. Current Data Rate (Transmit) ............................57
13.16. Latency .................................................58
13.17. Resources ...............................................59
13.18. Relative Link Quality (Receive) .........................60
13.19. Relative Link Quality (Transmit) ........................60
13.20. Maximum Transmission Unit (MTU) .........................61
14. Security Considerations .......................................62
15. IANA Considerations ...........................................63
15.1. Registrations ............................................63
15.2. Signal Type Registrations ................................63
15.3. Message Type Registrations ...............................64
15.4. DLEP Data Item Registrations .............................65
15.5. DLEP Status Code Registrations ...........................66
15.6. DLEP Extension Registrations .............................67
15.7. DLEP IPv4 Connection Point Flags .........................68
15.8. DLEP IPv6 Connection Point Flags .........................68
15.9. DLEP Peer Type Flags .....................................68
15.10. DLEP IPv4 Address Flags .................................69
15.11. DLEP IPv6 Address Flags .................................69
15.12. DLEP IPv4 Attached Subnet Flags .........................69
15.13. DLEP IPv6 Attached Subnet Flags .........................70
15.14. DLEP Well-Known Port ....................................70
15.15. DLEP IPv4 Link-Local Multicast Address ..................70
15.16. DLEP IPv6 Link-Local Multicast Address ..................70
16. References ....................................................71
16.1. Normative References .....................................71
16.2. Informative References ...................................71
Appendix A. Discovery Signal Flows ................................73
Appendix B. Peer-Level Message Flows ..............................73
B.1. Session Initialization .....................................73
B.2. Session Initialization - Refused ...........................74
B.3. Router Changes IP Addresses ................................74
B.4. Modem Changes Session-Wide Metrics .........................75
B.5. Router Terminates Session ..................................75
B.6. Modem Terminates Session ...................................76
B.7. Session Heartbeats .........................................77
B.8. Router Detects a Heartbeat Timeout .........................78
B.9. Modem Detects a Heartbeat Timeout ..........................78
Appendix C. Destination-Specific Message Flows ....................79
C.1. Common Destination Notification ............................79
C.2. Multicast Destination Notification .........................80
C.3. Link Characteristics Request ...............................81
Acknowledgments ...................................................82
Authors' Addresses ................................................82
15.6. DLEP Extension Registrations .............................67
15.7. DLEP IPv4 Connection Point Flags .........................68
15.8. DLEP IPv6 Connection Point Flags .........................68
15.9. DLEP Peer Type Flags .....................................68
15.10. DLEP IPv4 Address Flags .................................69
15.11. DLEP IPv6 Address Flags .................................69
15.12. DLEP IPv4 Attached Subnet Flags .........................69
15.13. DLEP IPv6 Attached Subnet Flags .........................70
15.14. DLEP Well-Known Port ....................................70
15.15. DLEP IPv4 Link-Local Multicast Address ..................70
15.16. DLEP IPv6 Link-Local Multicast Address ..................70
16. References ....................................................71
16.1. Normative References .....................................71
16.2. Informative References ...................................71
Appendix A. Discovery Signal Flows ................................73
Appendix B. Peer-Level Message Flows ..............................73
B.1. Session Initialization .....................................73
B.2. Session Initialization - Refused ...........................74
B.3. Router Changes IP Addresses ................................74
B.4. Modem Changes Session-Wide Metrics .........................75
B.5. Router Terminates Session ..................................75
B.6. Modem Terminates Session ...................................76
B.7. Session Heartbeats .........................................77
B.8. Router Detects a Heartbeat Timeout .........................78
B.9. Modem Detects a Heartbeat Timeout ..........................78
Appendix C. Destination-Specific Message Flows ....................79
C.1. Common Destination Notification ............................79
C.2. Multicast Destination Notification .........................80
C.3. Link Characteristics Request ...............................81
Acknowledgments ...................................................82
Authors' Addresses ................................................82
There exist today a collection of modem devices that control links of variable data rate and quality. Examples of these types of links include line-of-sight (LOS) terrestrial radios, satellite terminals, and broadband modems. Fluctuations in speed and quality of these links can occur due to configuration, or on a moment-to-moment basis, due to physical phenomena like multipath interference, obstructions, rain fade, etc. It is also quite possible that link quality and data rate vary with respect to individual destinations on a link and with the type of traffic being sent. As an example, consider the case of an IEEE 802.11 access point serving two associated laptop computers. In this environment, the answer to the question "What is the data rate on the 802.11 link?" is "It depends on which associated laptop we're talking about and on what kind of traffic is being sent." While the first laptop, being physically close to the access
现在有一组调制解调器设备，它们控制可变数据速率和质量的链路。这些链路类型的示例包括视线（LOS）地面无线电、卫星终端和宽带调制解调器。这些链路的速度和质量可能会因配置而发生波动，或因物理现象（如多径干扰、障碍物、雨衰、，等等。链路质量和数据速率也很可能因链路上的各个目的地和发送的流量类型而不同。作为一个例子，考虑IEEE 802.11接入点为两个相关的膝上型计算机服务的情况。在这种环境下，“802.11链路上的数据速率是多少？”这个问题的答案是“这取决于我们谈论的是哪个相关的笔记本电脑，以及发送的是什么样的流量。”而第一台笔记本电脑在物理上接近接入点
point, may have a data rate of 54 Mbps for unicast traffic, the other laptop, being relatively far away or obstructed by some object, can simultaneously have a data rate of only 32 Mbps for unicast. However, for multicast traffic sent from the access point, all traffic is sent at the base transmission rate (which is configurable but, depending on the model of the access point, is usually 24 Mbps or less).
点，单播流量的数据速率可能为54 Mbps，另一台笔记本电脑相对较远或被某些对象阻挡，同时单播流量的数据速率仅为32 Mbps。但是，对于从接入点发送的多播流量，所有流量都以基本传输速率发送（基本传输速率是可配置的，但根据接入点的型号，通常为24Mbps或更低）。
In addition to utilizing links that have variable data rates, mobile networks are challenged by the notion that link connectivity will come and go over time, without an effect on a router's interface state (Up or Down). Effectively utilizing a relatively short-lived connection is problematic in IP routed networks, as IP routing protocols tend to rely on interface state and independent timers to maintain network convergence (e.g., HELLO messages and/or recognition of DEAD routing adjacencies). These dynamic connections can be better utilized with an event-driven paradigm, where acquisition of a new neighbor (or loss of an existing one) is signaled, as opposed to a paradigm driven by timers and/or interface state. DLEP not only implements such an event-driven paradigm but does so over a local (1-hop) TCP session, which guarantees delivery of the event messages.
除了利用具有可变数据速率的链路之外，移动网络还面临着这样一个概念的挑战：链路连接将随着时间的推移而变化，而不会影响路由器的接口状态（向上或向下）。在IP路由网络中，有效利用相对短命的连接是有问题的，因为IP路由协议往往依赖接口状态和独立计时器来维持网络收敛（例如，HELLO消息和/或对死路由邻接的识别）。与计时器和/或接口状态驱动的范例相反，事件驱动范例可以更好地利用这些动态连接，在事件驱动范例中，新邻居的获取（或现有邻居的丢失）是以信号表示的。DLEP不仅实现了这样一个事件驱动的范例，而且还通过本地（1-hop）TCP会话实现了这一点，这保证了事件消息的传递。
Another complicating factor for mobile networks are the different methods of physically connecting the modem devices to the router. Modems can be deployed as an interface card in a router's chassis, or as a standalone device connected to the router via Ethernet or serial link. In the case of Ethernet attachment, with existing protocols and techniques, routing software cannot be aware of convergence events occurring on the radio link (e.g., acquisition or loss of a potential routing neighbor), nor can the router be aware of the actual capacity of the link. This lack of awareness, along with the variability in data rate, leads to a situation where finding the (current) best route through the network to a given node is difficult to establish and properly maintain. This is especially true of demand-based access schemes such as Demand Assigned Multiple Access (DAMA) implementations used on some satellite systems. With a DAMA-based system, additional data rate may be available but will not be used unless the network devices emit traffic at a rate higher than the currently established rate. Increasing the traffic rate does not guarantee that additional data rate will be allocated; rather, it may result in data loss and additional retransmissions on the link.
移动网络的另一个复杂因素是将调制解调器设备物理连接到路由器的不同方法。调制解调器可以部署为路由器机箱中的接口卡，也可以部署为通过以太网或串行链路连接到路由器的独立设备。在以太网连接的情况下，使用现有协议和技术，路由软件无法感知无线链路上发生的聚合事件（例如，潜在路由邻居的获取或丢失），路由器也无法感知链路的实际容量。这种缺乏意识，加上数据速率的可变性，导致难以建立和正确维护通过网络到给定节点的（当前）最佳路由的情况。这对于基于需求的接入方案尤其如此，例如一些卫星系统上使用的需求分配多址（DAMA）实现。对于基于DAMA的系统，可以使用额外的数据速率，但除非网络设备以高于当前建立速率的速率发出流量，否则不会使用额外的数据速率。增加通信速率并不保证会分配额外的数据速率；相反，它可能会导致数据丢失和链路上的额外重传。
Addressing the challenges listed above, the Dynamic Link Exchange Protocol, or DLEP, has been developed. DLEP runs between a router and its attached modem devices, allowing the modem devices to communicate (1) link characteristics as they change and (2) convergence events (acquisition and loss of potential routing next hops). Figures 1 and 2 illustrate the scope of DLEP packets.
为了应对上述挑战，开发了动态链路交换协议（DLEP）。DLEP在路由器及其连接的调制解调器设备之间运行，允许调制解调器设备通信（1）链路特性变化和（2）收敛事件（获取和丢失下一跳的潜在路由）。图1和图2说明了DLEP数据包的范围。
|-------Local Node-------| |-------Remote Node------|
| | | |
+--------+ +-------+ +-------+ +--------+
| Router |=======| Modem |{~~~~~~~~}| Modem |=======| Router |
| | | Device| | Device| | |
+--------+ +-------+ +-------+ +--------+
| | | Link | | |
|-DLEP--| | Protocol | |-DLEP--|
| | | (e.g., | | |
| | | 802.11) | | |
|-------Local Node-------| |-------Remote Node------|
| | | |
+--------+ +-------+ +-------+ +--------+
| Router |=======| Modem |{~~~~~~~~}| Modem |=======| Router |
| | | Device| | Device| | |
+--------+ +-------+ +-------+ +--------+
| | | Link | | |
|-DLEP--| | Protocol | |-DLEP--|
| | | (e.g., | | |
| | | 802.11) | | |
Figure 1: DLEP Network
图1:DLEP网络
In Figure 1, when the local modem detects the presence of a remote node, it (the local modem) sends a message to its router via DLEP. The message consists of an indication of what change has occurred on the link (e.g., the presence of a remote node detected), along with a collection of DLEP-defined Data Items that further describe the change. Upon receipt of the message, the local router may take whatever action it deems appropriate, such as initiating discovery protocols and/or issuing HELLO messages to converge the network. On a continuing, as-needed basis, the modem devices use DLEP to report any characteristics of the link (data rate, latency, etc.) that have changed. DLEP is independent of the link type and topology supported by the modem. Note that DLEP is specified to run only on the local link between router and modem. Some over-the-air signaling may be necessary between the local and remote modem in order to provide some parameters in DLEP Messages between the local modem and local router, but DLEP does not specify how such over-the-air signaling is carried out. Over-the-air signaling is purely a matter for the modem implementer.
在图1中，当本地调制解调器检测到远程节点时，它（本地调制解调器）通过DLEP向其路由器发送消息。该消息包括对链路上发生的更改的指示（例如，检测到远程节点的存在），以及进一步描述更改的DLEP定义的数据项集合。在收到消息后，本地路由器可采取其认为适当的任何行动，例如启动发现协议和/或发出HELLO消息以汇聚网络。根据需要，调制解调器设备持续使用DLEP来报告已更改的链路特性（数据速率、延迟等）。DLEP与调制解调器支持的链路类型和拓扑无关。请注意，指定DLEP仅在路由器和调制解调器之间的本地链路上运行。本地和远程调制解调器之间可能需要一些空中信令，以便在本地调制解调器和本地路由器之间的DLEP消息中提供一些参数，但是DLEP没有指定如何执行这种空中信令。空中信令纯粹是调制解调器实现者的事情。
Figure 2 shows how DLEP can support a configuration where routers are connected with different link types. In this example, Modem Device Type A implements a point-to-point link, and Modem Device Type B is connected via a shared medium. In both cases, DLEP is used to report the characteristics of the link (data rate, latency, etc.) to routers. The modem is also able to use the DLEP session to notify the router when the remote node is lost, shortening the time required to reconverge the network.
图2显示了DLEP如何支持路由器通过不同链路类型连接的配置。在此示例中，调制解调器设备类型A实现点对点链路，而调制解调器设备类型B通过共享介质连接。在这两种情况下，DLEP用于向路由器报告链路的特性（数据速率、延迟等）。调制解调器还能够使用DLEP会话在远程节点丢失时通知路由器，从而缩短重新汇聚网络所需的时间。
+--------+ +--------+
+----+ Modem | | Modem +---+
| | Device | | Device | |
| | Type A | <===== // ======> | Type A | |
| +--------+ Point-to-Point Link +--------+ |
+---+----+ +---+----+
| Router | | Router |
| | | |
+---+----+ +---+----+
| +--------+ +--------+ |
+-----+ Modem | | Modem | |
| Device | o o o o o o o o | Device +--+
| Type B | o Shared o | Type B |
+--------+ o Medium o +--------+
o o
o o
o o
o
+--------+
| Modem |
| Device |
| Type B |
+---+----+
|
|
+---+----+
| Router |
| |
+--------+
+--------+ +--------+
+----+ Modem | | Modem +---+
| | Device | | Device | |
| | Type A | <===== // ======> | Type A | |
| +--------+ Point-to-Point Link +--------+ |
+---+----+ +---+----+
| Router | | Router |
| | | |
+---+----+ +---+----+
| +--------+ +--------+ |
+-----+ Modem | | Modem | |
| Device | o o o o o o o o | Device +--+
| Type B | o Shared o | Type B |
+--------+ o Medium o +--------+
o o
o o
o o
o
+--------+
| Modem |
| Device |
| Type B |
+---+----+
|
|
+---+----+
| Router |
| |
+--------+
Figure 2: DLEP Network with Multiple Modem Devices
图2：具有多个调制解调器设备的DLEP网络
DLEP defines a set of Messages used by modems and their attached routers to communicate events that occur on the physical link(s) managed by the modem: for example, a remote node entering or leaving the network, or that the link has changed. Associated with these Messages are a set of Data Items -- information that describes the remote node (e.g., address information) and/or the characteristics of the link to the remote node. Throughout this document, we refer to modems/routers participating in a DLEP session as "DLEP Participants", unless a specific distinction (e.g., modem or router) is required.
DLEP定义了调制解调器及其连接的路由器使用的一组消息，用于通信调制解调器管理的物理链路上发生的事件：例如，远程节点进入或离开网络，或者链路已更改。与这些消息相关联的是一组数据项——描述远程节点的信息（例如，地址信息）和/或到远程节点的链接的特征。在本文档中，我们将参与DLEP会话的调制解调器/路由器称为“DLEP参与者”，除非需要特殊区分（例如调制解调器或路由器）。
DLEP uses a session-oriented paradigm between the modem device and its associated router. If multiple modem devices are attached to a router (as in Figure 2) or the modem supports multiple connections
DLEP在调制解调器设备及其相关路由器之间使用面向会话的范例。如果多个调制解调器设备连接到路由器（如图2所示），或者调制解调器支持多个连接
(via multiple logical or physical interfaces), then separate DLEP sessions exist for each modem or connection. A router and modem form a session by completing the discovery and initialization process. This router-modem session persists unless or until it either (1) times out, based on the absence of DLEP traffic (including heartbeats) or (2) is explicitly torn down by one of the DLEP participants.
（通过多个逻辑或物理接口），则每个调制解调器或连接存在单独的DLEP会话。路由器和调制解调器通过完成发现和初始化过程形成会话。此路由器调制解调器会话持续存在，除非或直到（1）超时（基于缺少DLEP通信量（包括心跳）或（2）被其中一个DLEP参与者明确中断。
While this document represents the best efforts of the working group to be functionally complete, it is recognized that extensions to DLEP will in all likelihood be necessary as more link types are used. Such extensions are defined as additional Messages, Data Items, and/or status codes, and associated rules of behavior, that are not defined in this document. DLEP contains a standard mechanism for router and modem implementations to negotiate the available extensions to use on a per-session basis.
虽然本文件代表了工作组为实现功能完整所做的最大努力，但人们认识到，随着使用更多链路类型，极有可能需要对DLEP进行扩展。此类扩展定义为本文档中未定义的其他消息、数据项和/或状态代码以及相关行为规则。DLEP包含路由器和调制解调器实现的标准机制，用于协商每个会话使用的可用扩展。
The router-modem session provides a carrier for information exchange concerning "destinations" that are available via the modem device. Destinations can be identified by either the router or the modem and represent a specific, addressable location that can be reached via the link(s) managed by the modem.
路由器调制解调器会话提供了一个载体，用于交换有关通过调制解调器设备可用的“目的地”的信息。目的地可由路由器或调制解调器识别，并表示可通过调制解调器管理的链路到达的特定可寻址位置。
The DLEP Messages concerning destinations thus become the way for routers and modems to maintain, and notify each other about, an information base representing the physical and logical destinations accessible via the modem device, as well as the link characteristics to those destinations.
因此，关于目的地的DLEP消息成为路由器和调制解调器维护并相互通知表示可通过调制解调器设备访问的物理和逻辑目的地以及到这些目的地的链路特性的信息库的方式。
A destination can be either physical or logical. The example of a physical destination would be that of a remote, far-end router attached via the variable-quality network. It should be noted that for physical destinations the Media Access Control (MAC) address is the address of the far-end router, not the modem.
目的地可以是物理的，也可以是逻辑的。物理目的地的示例是通过可变质量网络连接的远程远端路由器。应该注意的是，对于物理目的地，媒体访问控制（MAC）地址是远端路由器的地址，而不是调制解调器的地址。
The example of a logical destination is Multicast. Multicast traffic destined for the variable-quality network (the network accessed via the modem) is handled in IP networks by deriving a Layer 2 MAC address based on the Layer 3 address. Leveraging on this scheme, multicast traffic is supported in DLEP simply by treating the derived MAC address as any other destination in the network.
逻辑目的地的示例是多播。目的地为可变质量网络（通过调制解调器访问的网络）的多播通信在IP网络中通过基于第3层地址导出第2层MAC地址来处理。利用此方案，只需将派生的MAC地址视为网络中的任何其他目的地，即可在DLEP中支持多播通信。
To support these logical destinations, one of the DLEP participants (typically, the router) informs the other as to the existence of the logical destination. The modem, once it is aware of the existence of this logical destination, reports link characteristics just as it
为了支持这些逻辑目的地，一个DLEP参与者（通常是路由器）通知另一个逻辑目的地的存在。调制解调器一旦意识到这个逻辑目的地的存在，就会像它一样报告链路特性
would for any other destination in the network. The specific algorithms a modem would use to derive metrics on logical destinations are outside the scope of this specification; these algorithms are left to specific implementations to decide.
将为网络中的任何其他目的地。调制解调器用于在逻辑目的地上导出度量的特定算法不在本规范的范围内；这些算法留给具体的实现来决定。
In all cases, when this specification uses the term "destination", it refers to the addressable locations, either logical or physical, that are accessible by the radio link(s).
在所有情况下，当本规范使用术语“目的地”时，它指的是无线电链路可访问的可寻址位置（逻辑或物理）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
DLEP MUST be implemented on a single Layer 2 domain. The protocol identifies next-hop destinations by using the MAC address for delivering data traffic. No manipulation or substitution is performed; the MAC address supplied in all DLEP Messages is used as the Destination MAC address for frames emitted by the participating router. MAC addresses MUST be unique within the context of the router-modem session.
DLEP必须在单个第2层域上实现。该协议通过使用MAC地址发送数据流量来识别下一跳目的地。未进行任何操纵或替换；所有DLEP消息中提供的MAC地址用作参与路由器发射的帧的目标MAC地址。MAC地址在路由器调制解调器会话的上下文中必须是唯一的。
To enforce the single Layer 2 domain, implementations MUST support the Generalized TTL Security Mechanism [RFC5082], and implementations MUST adhere to this specification for all DLEP Messages.
为了实施单层2域，实现必须支持通用TTL安全机制[RFC5082]，并且实现必须遵守所有DLEP消息的本规范。
DLEP specifies UDP multicast for single-hop discovery signaling and TCP for transport of the Messages. Modems and routers participating in DLEP sessions MUST have topologically consistent IP addresses assigned. It is RECOMMENDED that DLEP implementations utilize IPv6 link-local addresses to reduce the administrative burden of address assignment.
DLEP为单跳发现信令指定UDP多播，为消息传输指定TCP。参与DLEP会话的调制解调器和路由器必须分配拓扑一致的IP地址。建议DLEP实现利用IPv6链路本地地址来减少地址分配的管理负担。
DLEP relies on the guaranteed delivery of its Messages between router and modem, once the 1-hop discovery process is complete -- hence, the specification of TCP to carry the Messages. Other reliable transports for the protocol are possible but are outside the scope of this document.
一旦一跳发现过程完成，DLEP就依赖于路由器和调制解调器之间消息的有保证的传递——因此，TCP的规范是用来承载消息的。协议的其他可靠传输是可能的，但不在本文件的范围内。
During development of this specification, two types of deployments were discussed.
在本规范的开发过程中，讨论了两种类型的部署。
The first can be viewed as a "dedicated deployment". In this mode, DLEP routers and modems are either directly connected (e.g., using crossover cables to connect interfaces) or connected to a dedicated switch. An example of this type of deployment would be a router with a line-of-sight radio connected into one interface, with a satellite modem connected into another interface. In mobile environments, the router and the connected modem (or modems) are placed into a mobile platform (e.g., a vehicle, boat, or airplane). In this mode, when a switch is used, it is possible that a small number of ancillary devices (e.g., a laptop) are also plugged into the switch. But in either event, the resulting network segment is constrained to a small number of devices and is not generally accessible from anywhere else in the network.
第一个可以被视为“专用部署”。在此模式下，DLEP路由器和调制解调器直接连接（例如，使用交叉电缆连接接口）或连接到专用交换机。这种部署的一个例子是一个路由器，它的一个接口连接有一个可视无线电，另一个接口连接有一个卫星调制解调器。在移动环境中，路由器和连接的调制解调器（或多个调制解调器）放置在移动平台（例如，车辆、船只或飞机）中。在该模式下，当使用交换机时，少量辅助设备（例如笔记本电脑）也可能插入交换机。但在这两种情况下，生成的网段都被限制在少数设备上，并且通常无法从网络中的任何其他位置访问。
The other type of deployment envisioned can be viewed as a "networked deployment". In this type of scenario, the DLEP router and modem (or modems) are placed on a segment that is accessible from other points in the network. In this scenario, not only are the DLEP router and modem(s) accessible from other points in the network; the router and a given modem could be multiple physical hops away from each other. This scenario necessitates the use of Layer 2 tunneling technology to enforce the single-hop requirement of DLEP.
设想的另一种部署类型可以被视为“网络化部署”。在这种情况下，DLEP路由器和调制解调器（或多个调制解调器）放置在可以从网络中的其他点访问的网段上。在这种情况下，不仅可以从网络中的其他点访问DLEP路由器和调制解调器；路由器和给定的调制解调器可以是彼此之间的多个物理跃点。该场景需要使用第2层隧道技术来强制执行DLEP的单跳要求。
DLEP assumes that a signaling protocol exists between modems participating in a network. This specification does not define the character or behavior of this over-the-air signaling but does expect some information to be carried (or derived) by the signaling, such as the arrival and departure of modems from this network, and the variation of the link characteristics between modems. This information is then assumed to be used by the modem to implement DLEP.
DLEP假设参与网络的调制解调器之间存在信令协议。本规范未定义该空中信令的特征或行为，但期望通过该信令携带（或导出）一些信息，例如调制解调器从该网络的到达和离开，以及调制解调器之间链路特性的变化。然后假设调制解调器使用此信息来实现DLEP。
This specification assumes that the link between router and modem is static with respect to data rate and latency and that this link is not likely to be the cause of a performance bottleneck. In deployments where the router and modem are physically separated by multiple network hops, served by Layer 2 tunneling technology, DLEP statistics on the RF links could be insufficient for routing protocols to make appropriate routing decisions. This would
本规范假设路由器和调制解调器之间的链路在数据速率和延迟方面是静态的，并且该链路不可能成为性能瓶颈的原因。在路由器和调制解调器由多个网络跃点物理分离的部署中，由第2层隧道技术提供服务，射频链路上的DLEP统计数据可能不足以让路由协议做出适当的路由决策。这会
especially become an issue in cases where the Layer 2 tunnel between router and modem is itself served in part (or in total) with a wireless backhaul link.
特别是在路由器和调制解调器之间的第2层隧道本身部分（或全部）由无线回程链路提供服务的情况下，这将成为一个问题。
DLEP includes the ability for the router and modem to communicate metrics that reflect the characteristics (e.g., data rate, latency) of the variable-quality link in use. DLEP does not specify how a given metric value is to be calculated; rather, the protocol assumes that metrics have been calculated by a "best effort", incorporating all pertinent data that is available to the modem device. Metrics based on large-enough sample sizes will preclude short traffic bursts from adversely skewing reported values.
DLEP包括路由器和调制解调器通信度量的能力，这些度量反映了所使用的可变质量链路的特征（例如，数据速率、延迟）。DLEP没有指定如何计算给定的度量值；相反，该协议假定度量是通过“最大努力”计算的，包括调制解调器设备可用的所有相关数据。基于足够大样本量的指标将防止短流量突发对报告值产生不利的倾斜。
DLEP allows for metrics to be sent within two contexts -- metrics for a specific destination within the network (e.g., a specific router), and "per session" (those that apply to all destinations accessed via the modem). Most metrics can be further subdivided into transmit and receive metrics. In cases where metrics are provided at the session level, the router propagates the metrics to all entries in its information base for destinations that are accessed via the modem.
DLEP允许在两个上下文中发送度量——网络中特定目的地的度量（例如，特定路由器）和“每会话”（适用于通过调制解调器访问的所有目的地的度量）。大多数度量可以进一步细分为发送和接收度量。在会话级别提供度量的情况下，路由器将度量传播到其信息库中通过调制解调器访问的目的地的所有条目。
DLEP modems announce all metric Data Items that will be reported during the session, and provide default values for those metrics, in the Session Initialization Response Message (Section 12.6). In order to use a metric type that was not included in the Session Initialization Response Message, modem implementations terminate the session with the router (via the Session Termination Message (Section 12.9)) and establish a new session.
DLEP调制解调器在会话初始化响应消息（第12.6节）中宣布将在会话期间报告的所有度量数据项，并提供这些度量的默认值。为了使用会话初始化响应消息中未包含的度量类型，调制解调器实现终止与路由器的会话（通过会话终止消息（第12.9节））并建立新会话。
A DLEP modem can send metrics in both (1) a session context, via the Session Update Message (Section 12.7) and (2) a specific destination context, via the Destination Update Message (Section 12.17), at any time. The most recently received metric value takes precedence over any earlier value, regardless of context -- that is:
DLEP调制解调器可随时通过会话更新消息（第12.7节）发送（1）会话上下文中的度量，以及通过目标更新消息（第12.17节）发送（2）特定目标上下文中的度量。无论上下文如何，最近收到的度量值优先于任何较早的值，即：
1. If the router receives metrics in a specific destination context (via the Destination Update Message), then the specific destination is updated with the new metric.
1. 如果路由器接收到特定目的地上下文中的度量（通过目的地更新消息），则使用新度量更新特定目的地。
2. If the router receives metrics in a session-wide context (via the Session Update Message), then the metrics for all destinations accessed via the modem are updated with the new metric.
2. 如果路由器在会话范围的上下文中（通过会话更新消息）接收到度量，则通过调制解调器访问的所有目的地的度量将用新度量更新。
It is left to implementations to choose sensible default values based on their specific characteristics. Modems having static (non-changing) link metric characteristics can report metrics only once for a given destination (or once on a session-wide basis, if all connections via the modem are of this static nature).
让实现根据其特定特性选择合理的默认值。具有静态（不变）链路度量特征的调制解调器只能为给定目的地报告一次度量（或者在会话范围内报告一次，如果通过调制解调器的所有连接都是静态的）。
In addition to communicating existing metrics about the link, DLEP provides a Message allowing a router to request a different data rate or latency from the modem. This Message is the Link Characteristics Request Message (Section 12.18); it gives the router the ability to deal with requisite increases (or decreases) of allocated data rate/latency in demand-based schemes in a more deterministic manner.
除了通信链路的现有指标外，DLEP还提供一条消息，允许路由器从调制解调器请求不同的数据速率或延迟。该消息为链路特性请求消息（第12.18节）；它使路由器能够以更确定的方式处理基于需求的方案中分配的数据速率/延迟的必要增加（或减少）。
All DLEP participants of a session transition through a number of distinct states during the lifetime of a DLEP session:
在DLEP会话的生命周期内，会话转换的所有DLEP参与者都会经历许多不同的状态：
o Peer Discovery
o 对等发现
o Session Initialization
o 会话初始化
o In-Session
o 会期
o Session Termination
o 会话终止
o Session Reset
o 会话重置
Modems, and routers supporting DLEP discovery, transition through all five of the above states. Routers that rely on preconfigured TCP address/port information start in the Session Initialization state.
调制解调器和支持DLEP发现的路由器在上述所有五种状态下转换。依赖预配置的TCP地址/端口信息的路由器在会话初始化状态下启动。
Modems MUST support the Peer Discovery state.
调制解调器必须支持对等发现状态。
Modems MUST support DLEP Peer Discovery; routers MAY support the discovery signals or rely on a priori configuration to locate modems. If a router chooses to support DLEP discovery, all signals MUST be supported.
调制解调器必须支持DLEP对等发现；路由器可支持发现信号或依赖先验配置来定位调制解调器。如果路由器选择支持DLEP发现，则必须支持所有信号。
In the Peer Discovery state, routers that support DLEP discovery MUST send Peer Discovery Signals (Section 12.3) to initiate modem discovery.
在对等发现状态下，支持DLEP发现的路由器必须发送对等发现信号（第12.3节）以启动调制解调器发现。
The router implementation then waits for a Peer Offer Signal (Section 12.4) response from a potential DLEP modem. While in the Peer Discovery state, Peer Discovery Signals MUST be sent repeatedly by a DLEP router, at regular intervals. It is RECOMMENDED that this interval be set to 60 seconds. The interval MUST be a minimum of 1 second; it SHOULD be a configurable parameter. Note that this operation (sending Peer Discovery and waiting for Peer Offer) is outside the DLEP transaction model (Section 8), as the transaction model only describes Messages on a TCP session.
路由器实现然后等待来自潜在DLEP调制解调器的对等提供信号（第12.4节）响应。处于对等发现状态时，DLEP路由器必须定期重复发送对等发现信号。建议将此间隔设置为60秒。间隔必须至少为1秒；它应该是一个可配置的参数。请注意，此操作（发送对等发现并等待对等提供）在DLEP事务模型（第8节）之外，因为事务模型仅描述TCP会话上的消息。
Routers receiving a Peer Offer Signal MUST use one of the modem address/port combinations from the Peer Offer Signal to establish a TCP connection to the modem, even if a priori configuration exists. If multiple Connection Point Data Items exist in the received Peer Offer Signal, routers SHOULD prioritize IPv6 connection points over IPv4 connection points. If multiple connection points exist with the same transport (e.g., IPv6 or IPv4), implementations MAY use their own heuristics to determine the order in which they are tried. If a TCP connection cannot be achieved using any of the address/port combinations and the Discovery mechanism is in use, then the router SHOULD resume issuing Peer Discovery Signals. If no Connection Point Data Items are included in the Peer Offer Signal, the router MUST use the source address of the UDP packet containing the Peer Offer Signal as the IP address, and the DLEP well-known port number.
接收对等提供信号的路由器必须使用来自对等提供信号的调制解调器地址/端口组合之一来建立到调制解调器的TCP连接，即使存在先验配置。如果接收到的对等提供信号中存在多个连接点数据项，路由器应优先考虑IPv6连接点而不是IPv4连接点。如果存在具有相同传输（例如IPv6或IPv4）的多个连接点，则实现可能会使用它们自己的试探法来确定尝试它们的顺序。如果无法使用任何地址/端口组合实现TCP连接，并且发现机制正在使用，则路由器应恢复发出对等发现信号。如果对等提供信号中不包含连接点数据项，路由器必须使用包含对等提供信号的UDP数据包的源地址作为IP地址，以及DLEP已知端口号。
In the Peer Discovery state, the modem implementation MUST listen for incoming Peer Discovery Signals on the DLEP well-known IPv6 and/or IPv4 link-local multicast address and port. On receipt of a valid Peer Discovery Signal, it MUST reply with a Peer Offer Signal.
在对等发现状态下，调制解调器实现必须侦听DLEP已知IPv6和/或IPv4链路本地多播地址和端口上的传入对等发现信号。在收到有效的对等发现信号时，它必须用对等提供信号进行应答。
Modems MUST be prepared to accept a TCP connection from a router that is not using the Discovery mechanism, i.e., a connection attempt that occurs without a preceding Peer Discovery Signal.
调制解调器必须准备好接受来自未使用发现机制的路由器的TCP连接，即在没有先前对等发现信号的情况下发生的连接尝试。
Implementations of DLEP SHOULD implement, and use, Transport Layer Security (TLS) [RFC5246] to protect the TCP session. The "dedicated deployments" discussed in "Implementation Scenarios" (Section 4) MAY consider the use of DLEP without TLS. For all "networked deployments" (again, discussed in "Implementation Scenarios"), the implementation and use of TLS are STRONGLY RECOMMENDED. If TLS is to be used, then the TLS session MUST be established before any Messages are passed between peers. Routers supporting TLS MUST prioritize connection points using TLS over those that do not.
DLEP的实现应该实现并使用传输层安全性（TLS）[RFC5246]来保护TCP会话。在“实现场景”（第4节）中讨论的“专用部署”可以考虑不使用TLS的DLIP。对于所有“网络化部署”（同样在“实施场景”中讨论），强烈建议实施和使用TLS。如果要使用TLS，则必须在对等方之间传递任何消息之前建立TLS会话。支持TLS的路由器必须优先考虑使用TLS的连接点，而不是不使用TLS的连接点。
Upon establishment of a TCP connection, and the establishment of a TLS session if TLS is in use, both modem and router enter the Session Initialization state. It is up to the router implementation if Peer Discovery Signals continue to be sent after the device has
在建立TCP连接和TLS会话（如果TLS正在使用）时，调制解调器和路由器都会进入会话初始化状态。如果在设备启动后继续发送对等发现信号，则取决于路由器实现
transitioned to the Session Initialization state. Modem implementations MUST silently ignore Peer Discovery Signals from a router with which a given implementation already has a TCP connection.
已转换到会话初始化状态。调制解调器实现必须静默地忽略来自路由器的对等发现信号，给定实现已经与该路由器有TCP连接。
On entering the Session Initialization state, the router MUST send a Session Initialization Message (Section 12.5) to the modem. The router MUST then wait for receipt of a Session Initialization Response Message (Section 12.6) from the modem. Receipt of the Session Initialization Response Message containing a Status Data Item (Section 13.1) with status code set to 0 'Success' (see Table 2 in Section 13.1) indicates that the modem has received and processed the Session Initialization Message, and the router MUST transition to the In-Session state.
进入会话初始化状态时，路由器必须向调制解调器发送会话初始化消息（第12.5节）。然后，路由器必须等待从调制解调器收到会话初始化响应消息（第12.6节）。收到包含状态代码设置为0“成功”的状态数据项（第13.1节）的会话初始化响应消息（见第13.1节中的表2）表示调制解调器已接收并处理会话初始化消息，路由器必须转换到会话内状态。
On entering the Session Initialization state, the modem MUST wait for receipt of a Session Initialization Message from the router. Upon receipt of a Session Initialization Message, the modem MUST send a Session Initialization Response Message, and the session MUST transition to the In-Session state. If the modem receives any Message other than Session Initialization or it fails to parse the received Message, it MUST NOT send any Message, and it MUST terminate the TCP connection and transition to the Session Reset state.
进入会话初始化状态时，调制解调器必须等待从路由器收到会话初始化消息。收到会话初始化消息后，调制解调器必须发送会话初始化响应消息，并且会话必须转换到会话内状态。如果调制解调器接收到除会话初始化以外的任何消息，或者无法解析接收到的消息，则不得发送任何消息，并且必须终止TCP连接并转换到会话重置状态。
DLEP provides an extension negotiation capability to be used in the Session Initialization state; see Section 9. Extensions supported by an implementation MUST be declared to potential DLEP participants using the Extensions Supported Data Item (Section 13.6). Once both DLEP participants have exchanged initialization Messages, an implementation MUST NOT emit any Message, Signal, Data Item, or status code associated with an extension that was not specified in the received initialization Message from its peer.
DLEP提供在会话初始化状态下使用的扩展协商能力；见第9节。实现支持的扩展必须使用扩展支持的数据项（第13.6节）向潜在的DLEP参与者声明。一旦两个DLEP参与者交换了初始化消息，实现就不能发出任何消息、信号、数据项或与从对等方接收的初始化消息中未指定的扩展相关的状态代码。
In the In-Session state, Messages can flow in both directions between DLEP participants, indicating changes to the session state, the arrival or departure of reachable destinations, or changes of the state of the links to the destinations.
在会话中状态下，消息可以在DLEP参与者之间双向流动，指示会话状态的更改、可到达目的地的到达或离开，或者指向目的地的链路状态的更改。
The In-Session state is maintained until one of the following conditions occurs:
会话中状态将一直保持，直到出现以下情况之一：
o The implementation terminates the session by sending a Session Termination Message (Section 12.9), or
o 实现通过发送会话终止消息来终止会话（第12.9节），或
o Its peer terminates the session, indicated by receiving a Session Termination Message.
o 其对等方通过接收会话终止消息来终止会话。
The implementation MUST then transition to the Session Termination state.
然后，实现必须转换到会话终止状态。
In order to maintain the In-Session state, periodic Heartbeat Messages (Section 12.20) MUST be exchanged between router and modem. These Messages are intended to keep the session alive and to verify bidirectional connectivity between the two DLEP participants. It is RECOMMENDED that the interval timer between Heartbeat Messages be set to 60 seconds. The interval MUST be a minimum of 1 second; it SHOULD be a configurable parameter.
为了保持会话状态，路由器和调制解调器之间必须交换周期性心跳消息（第12.20节）。这些消息旨在使会话保持活动状态，并验证两个DLEP参与者之间的双向连接。建议将心跳消息之间的间隔计时器设置为60秒。间隔必须至少为1秒；它应该是一个可配置的参数。
Each DLEP participant is responsible for the creation of Heartbeat Messages.
每个DLEP参与者负责创建心跳消息。
Receipt of any valid DLEP Message MUST reset the heartbeat interval timer (i.e., valid DLEP Messages take the place of, and obviate the need for, additional Heartbeat Messages).
收到任何有效的DLEP消息都必须重置心跳间隔计时器（即，有效的DLEP消息取代并消除对额外心跳消息的需要）。
An implementation MUST allow a minimum of 2 heartbeat intervals to expire with no Messages from its peer before terminating the session. When terminating the session, a Session Termination Message containing a Status Data Item (Section 13.1) with status code set to 132 'Timed Out' (see Table 2) MUST be sent, and then the implementation MUST transition to the Session Termination state.
在终止会话之前，实现必须允许至少2个心跳间隔在没有来自对等方的消息的情况下过期。终止会话时，必须发送包含状态代码设置为132“超时”（见表2）的状态数据项（第13.1节）的会话终止消息，然后实现必须转换到会话终止状态。
When an implementation enters the Session Termination state after sending a Session Termination Message (Section 12.9) as the result of an invalid Message or error, it MUST wait for a Session Termination Response Message (Section 12.10) from its peer. A sender SHOULD allow 4 heartbeat intervals to expire before assuming that its peer is unresponsive and before continuing with session termination. Any other Message received while waiting MUST be silently ignored.
当由于无效消息或错误而发送会话终止消息（第12.9节）后，实现进入会话终止状态时，它必须等待来自其对等方的会话终止响应消息（第12.10节）。发送方应允许4个心跳间隔过期，然后再假设其对等方没有响应，然后再继续终止会话。在等待时收到的任何其他消息都必须以静默方式忽略。
When the sender of the Session Termination Message receives a Session Termination Response Message from its peer or times out, it MUST transition to the Session Reset state.
当会话终止消息的发送方从其对等方收到会话终止响应消息或超时时，它必须转换到会话重置状态。
When an implementation receives a Session Termination Message from its peer, it enters the Session Termination state, and then it MUST immediately send a Session Termination Response and transition to the Session Reset state.
当实现从其对等方接收到会话终止消息时，它将进入会话终止状态，然后它必须立即发送会话终止响应并转换到会话重置状态。
In the Session Reset state, the implementation MUST perform the following actions:
在会话重置状态下，实现必须执行以下操作：
o Release all resources allocated for the session.
o 释放分配给会话的所有资源。
o Eliminate all destinations in the information base represented by the session. Destination Down Messages (Section 12.15) MUST NOT be sent.
o 删除会话表示的信息库中的所有目标。不得发送目的地停机消息（第12.15节）。
o Terminate the TCP connection.
o 终止TCP连接。
Having completed these actions, the implementation SHOULD return to the relevant initial state:
完成这些操作后，实施应恢复到相关的初始状态：
o For modems: Peer Discovery.
o 对于调制解调器：对等发现。
o For routers: either Peer Discovery or Session Initialization, depending on configuration.
o 对于路由器：对等发现或会话初始化，具体取决于配置。
If the TCP connection between DLEP participants is terminated when an implementation is not in the Session Reset state, the implementation MUST immediately transition to the Session Reset state.
如果在实现未处于会话重置状态时终止了DLEP参与者之间的TCP连接，则该实现必须立即转换到会话重置状态。
DLEP defines a simple Message transaction model: only one request per destination may be in progress at a time per session. A Message transaction is considered complete when a response matching a previously issued request is received. If a DLEP participant receives a request for a destination for which there is already an outstanding request, the implementation MUST terminate the session by issuing a Session Termination Message (Section 12.9) containing a Status Data Item (Section 13.1) with status code set to 129 'Unexpected Message' (see Table 2) and transition to the Session
DLEP定义了一个简单的消息事务模型：每个目的地每次只能有一个请求在进行中。当收到与先前发出的请求匹配的响应时，消息事务被视为已完成。如果一个DLEP参与者收到一个目的地的请求，而该目的地已经有一个未完成的请求，则实施必须通过发出一条会话终止消息（第12.9节）来终止会话，该消息包含一个状态数据项（第13.1节），状态代码设置为129“意外消息”（见表2），并转换到会话
Termination state. There is no restriction on the total number of Message transactions in progress at a time, as long as each transaction refers to a different destination.
终止状态。只要每个事务指向不同的目的地，则对一次进行中的消息事务总数没有限制。
It should be noted that some requests may take a considerable amount of time for some DLEP participants to complete; for example, a modem handling a multicast Destination Up request may have to perform a complex network reconfiguration. A sending implementation MUST be able to handle such long-running transactions gracefully.
需要注意的是，一些DLEP参与者完成某些请求可能需要相当长的时间；例如，处理多播目的地上行请求的调制解调器可能必须执行复杂的网络重新配置。发送实现必须能够优雅地处理此类长时间运行的事务。
Additionally, only one session request, e.g., a Session Initialization Message (Section 12.5), may be in progress at a time per session. As noted above for Message transactions, a session transaction is considered complete when a response matching a previously issued request is received. If a DLEP participant receives a session request while there is already a session request in progress, it MUST terminate the session by issuing a Session Termination Message containing a Status Data Item with status code set to 129 'Unexpected Message' and transition to the Session Termination state. Only the Session Termination Message may be issued when a session transaction is in progress. Heartbeat Messages (Section 12.20) MUST NOT be considered part of a session transaction.
此外，每个会话一次只能进行一个会话请求，例如会话初始化消息（第12.5节）。如上所述，对于消息事务，当接收到与先前发出的请求匹配的响应时，会话事务被视为已完成。如果DLEP参与者在已有会话请求正在进行时收到会话请求，则必须通过发出会话终止消息来终止会话，该消息包含状态代码设置为129“意外消息”的状态数据项，并转换到会话终止状态。当会话事务正在进行时，只能发出会话终止消息。心跳消息（第12.20节）不得视为会话事务的一部分。
DLEP transactions do not time out and are not cancellable, except for transactions in flight when the DLEP session is reset. If the session is terminated, canceling transactions in progress MUST be performed as part of resetting the state machine. An implementation can detect if its peer has failed in some way by use of the session heartbeat mechanism during the In-Session state; see Section 7.3.
除重置DLEP会话时正在进行的事务外，DLEP事务不会超时且不可取消。如果会话终止，则必须在重置状态机时执行取消正在进行的事务。实现可以通过在会话状态期间使用会话心跳机制来检测其对等方是否以某种方式失败；见第7.3节。
Extensions MUST be negotiated on a per-session basis during session initialization via the Extensions Supported mechanism. Implementations are not required to support any extensions in order to be considered DLEP compliant.
在会话初始化期间，必须通过扩展支持的机制在每个会话的基础上协商扩展。实现不需要支持任何扩展就可以被认为是符合DLEP的。
If interoperable protocol extensions are required, they will need to be standardized as either (1) an update to this document or (2) an additional standalone specification. The IANA registries defined in Section 15 of this document contain sufficient unassigned space for DLEP Signals, Messages, Data Items, and status codes to accommodate future extensions to the protocol.
如果需要可互操作的协议扩展，则需要将其标准化为（1）本文档的更新或（2）附加的独立规范。本文件第15节中定义的IANA注册表包含足够的未分配空间，用于DLEP信号、消息、数据项和状态代码，以适应协议的未来扩展。
As multiple protocol extensions MAY be announced during session initialization, authors of protocol extensions need to consider the interaction of their extensions with other published extensions and specify any incompatibilities.
由于在会话初始化期间可以宣布多个协议扩展，协议扩展的作者需要考虑它们的扩展与其他已发布的扩展的交互，并且指定任何不兼容。
This document registers Private Use [RFC5226] numbering space in the DLEP Signal, Message, Data Item, and status code registries for experimental extensions. The intent is to allow for experimentation with new Signals, Messages, Data Items, and/or status codes while still retaining the documented DLEP behavior.
本文档在实验扩展的DLEP信号、消息、数据项和状态码注册表中注册私用[RFC5226]编号空间。其目的是允许对新信号、消息、数据项和/或状态代码进行实验，同时仍保留记录的DLEP行为。
During session initialization, the use of the Private Use Signals, Messages, Data Items, status codes, or behaviors MUST be announced as DLEP extensions, using extension identifiers from the Private Use space in the "Extension Type Values" registry (Table 3), with a value agreed upon (a priori) between the participants. DLEP extensions using the Private Use numbering space are commonly referred to as "experiments".
在会话初始化期间，私用信号、消息、数据项、状态代码或行为的使用必须作为DLEP扩展来宣布，使用来自“扩展类型值”注册表（表3）中私用空间的扩展标识符，并在参与者之间商定（先验）一个值。使用专用编号空间的DLEP扩展通常被称为“实验”。
Multiple experiments MAY be announced in the Session Initialization Messages. However, the use of multiple experiments in a single session could lead to interoperability issues or unexpected results (e.g., clashes of experimental Signals, Messages, Data Items, and/or status code types) and is therefore discouraged. It is left to implementations to determine the correct processing path (e.g., a decision on whether to terminate the session or establish a precedence of the conflicting definitions) if such conflicts arise.
会话初始化消息中可能会宣布多个实验。但是，在单个会话中使用多个实验可能会导致互操作性问题或意外结果（例如，实验信号、消息、数据项和/或状态代码类型的冲突），因此不鼓励这样做。如果出现此类冲突，则由实现来确定正确的处理路径（例如，决定是否终止会话或建立冲突定义的优先级）。
The protocol is intended to support thousands of destinations on a given modem/router pair. On a large scale, an implementation should consider employing techniques to prevent flooding its peer with a large number of Messages in a short time. For example, a dampening algorithm could be employed to prevent a flapping device from generating a large number of Destination Up / Destination Down Messages.
该协议旨在支持给定调制解调器/路由器对上的数千个目的地。在很大程度上，一个实现应该考虑采用技术来防止在短时间内用大量消息淹没其对等点。例如，可以使用阻尼算法来防止拍打设备生成大量目的地向上/目的地向下消息。
Also, the use of techniques such as a hysteresis can lessen the impact of rapid, minor fluctuations in link quality. The specific algorithms for handling flapping destinations and minor changes in link quality are outside the scope of this specification.
此外，使用滞后等技术可以减少链路质量快速、微小波动的影响。处理摆动目的地和链路质量微小变化的特定算法不在本规范的范围内。
DLEP defines two protocol units used in two different ways: Signals and Messages. Signals are only used in the Discovery mechanism and are carried in UDP datagrams. Messages are used bidirectionally over a TCP connection between the participants, in the Session Initialization, In-Session, and Session Termination states.
DLEP定义了以两种不同方式使用的两个协议单元：信号和消息。信号仅在发现机制中使用，并在UDP数据报中传输。消息在会话初始化、会话中和会话终止状态下，通过参与者之间的TCP连接双向使用。
Both Signals and Messages consist of a Header followed by an unordered list of Data Items. Headers consist of Type and Length information, while Data Items are encoded as TLV (Type-Length-Value) structures. In this document, the Data Items following a Signal or Message Header are described as being "contained in" the Signal or Message.
信号和消息都由一个标题和一个无序的数据项列表组成。标头由类型和长度信息组成，而数据项编码为TLV（类型长度值）结构。在本文档中，信号或消息头后面的数据项被描述为“包含在”信号或消息中。
There is no restriction on the order of Data Items following a Header, and the acceptability of duplicate Data Items is defined by the definition of the Signal or Message declared by the type in the Header.
标题后面的数据项顺序没有限制，重复数据项的可接受性由标题中类型声明的信号或消息的定义定义。
All integers in Header fields and values MUST be in network byte order.
头字段和值中的所有整数必须按网络字节顺序排列。
The DLEP Signal Header contains the following fields:
DLEP信号头包含以下字段：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 'D' | 'L' | 'E' | 'P' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 'D' | 'L' | 'E' | 'P' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: DLEP Signal Header
图3:DLEP信号头
"DLEP": Every Signal MUST start with the following characters: U+0044, U+004C, U+0045, U+0050.
“DLEP”：每个信号必须以以下字符开头：U+0044、U+004C、U+0045、U+0050。
Signal Type: A 16-bit unsigned integer containing one of the DLEP Signal Type values defined in this document.
信号类型：一个16位无符号整数，包含本文档中定义的一个DLEP信号类型值。
Length: The length in octets, expressed as a 16-bit unsigned integer, of all of the DLEP Data Items contained in this Signal. This length MUST NOT include the length of the Signal Header itself.
长度：此信号中包含的所有DLEP数据项的长度（以八位字节为单位），表示为16位无符号整数。该长度不得包括信号头本身的长度。
The DLEP Signal Header is immediately followed by zero or more DLEP Data Items, encoded in TLVs, as defined in this document.
DLEP信号头后面紧跟着零个或多个以TLV编码的DLEP数据项，如本文档中所定义。
The DLEP Message Header contains the following fields:
DLEP消息头包含以下字段：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: DLEP Message Header
图4:DLEP消息头
Message Type: A 16-bit unsigned integer containing one of the DLEP Message Type values defined in this document.
消息类型：一个16位无符号整数，包含本文档中定义的一个DLEP消息类型值。
Length: The length in octets, expressed as a 16-bit unsigned integer, of all of the DLEP Data Items contained in this Message. This length MUST NOT include the length of the Message Header itself.
长度：此消息中包含的所有DLEP数据项的长度（以八位字节为单位），表示为16位无符号整数。此长度不得包括消息头本身的长度。
The DLEP Message Header is immediately followed by zero or more DLEP Data Items, encoded in TLVs, as defined in this document.
DLEP消息头后面紧跟着零个或多个以TLV编码的DLEP数据项，如本文档中所定义。
All DLEP Data Items contain the following fields:
所有DLEP数据项都包含以下字段：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: DLEP Generic Data Item
图5:DLEP通用数据项
Data Item Type: A 16-bit unsigned integer field specifying the type of Data Item being sent.
数据项类型：一个16位无符号整数字段，指定要发送的数据项的类型。
Length: The length in octets, expressed as a 16-bit unsigned integer, of the Value field of the Data Item. This length MUST NOT include the length of the Data Item Type and Length fields.
长度：数据项的值字段的长度（以八位字节为单位），表示为16位无符号整数。此长度不得包括数据项类型和长度字段的长度。
Value: A field of <Length> octets that contains data specific to a particular Data Item.
值：<Length>八位字节的字段，包含特定数据项的特定数据。
If an unrecognized or unexpected Signal is received or if a received Signal contains unrecognized, invalid, or disallowed duplicate Data Items, the receiving implementation MUST ignore the Signal.
如果接收到无法识别或意外的信号，或者接收到的信号包含无法识别、无效或不允许的重复数据项，则接收实现必须忽略该信号。
If a Signal is received with a TTL value that is NOT equal to 255, the receiving implementation MUST ignore the Signal.
如果接收到TTL值不等于255的信号，则接收实现必须忽略该信号。
If an unrecognized Message is received, the receiving implementation MUST issue a Session Termination Message (Section 12.9) containing a Status Data Item (Section 13.1) with status code set to 128 'Unknown Message' (see Table 2) and transition to the Session Termination state.
如果接收到无法识别的消息，接收实现必须发出会话终止消息（第12.9节），其中包含状态代码设置为128“未知消息”（见表2）的状态数据项（第13.1节），并转换到会话终止状态。
If an unexpected Message is received, the receiving implementation MUST issue a Session Termination Message containing a Status Data Item with status code set to 129 'Unexpected Message' and transition to the Session Termination state.
如果收到意外消息，接收实现必须发出会话终止消息，其中包含状态代码设置为129“意外消息”的状态数据项，并转换到会话终止状态。
If a received Message contains unrecognized, invalid, or disallowed duplicate Data Items, the receiving implementation MUST issue a Session Termination Message containing a Status Data Item with status code set to 130 'Invalid Data' and transition to the Session Termination state.
如果收到的消息包含无法识别、无效或不允许的重复数据项，则接收实现必须发出包含状态代码设置为130“无效数据”的状态数据项的会话终止消息，并转换到会话终止状态。
If a packet in the TCP stream is received with a TTL value other than 255, the receiving implementation MUST immediately transition to the Session Reset state.
如果接收到TCP流中的数据包的TTL值不是255，则接收实现必须立即转换到会话重置状态。
Prior to the exchange of Destination Up (Section 12.11) and Destination Up Response (Section 12.12) Messages, or Destination Announce (Section 12.13) and Destination Announce Response (Section 12.14) Messages, no Messages concerning a destination may be sent. An implementation receiving any Message with such an unannounced destination MUST terminate the session by issuing a Session Termination Message containing a Status Data Item with status code set to 131 'Invalid Destination' and transition to the Session Termination state.
在交换目的地向上（第12.11节）和目的地向上响应（第12.12节）消息或目的地通告（第12.13节）和目的地通告响应（第12.14节）消息之前，不得发送与目的地有关的任何消息。接收任何带有此类未通知目的地的消息的实现必须通过发出包含状态代码设置为131“无效目的地”的状态数据项的会话终止消息并转换到会话终止状态来终止会话。
After exchanging Destination Down (Section 12.15) and Destination Down Response (Section 12.16) Messages, no Messages concerning a destination may be sent until a new Destination Up or Destination Announce Message is sent. An implementation receiving a Message about a destination previously announced as 'down' MUST terminate the
交换目的地关闭（第12.15节）和目的地关闭响应（第12.16节）消息后，在发送新的目的地启动或目的地公告消息之前，不得发送与目的地有关的消息。接收到有关先前宣布为“关闭”的目的地的消息的实现必须终止
session by issuing a Session Termination Message containing a Status Data Item with status code set to 131 'Invalid Destination' and transition to the Session Termination state.
通过发出包含状态代码设置为131“无效目标”的状态数据项的会话终止消息，并转换到会话终止状态。
The behavior of a DLEP participant receiving a Message containing a Status Data Item (Section 13.1) is defined by the failure mode associated with the value of the status code field; see Table 2. All status code values less than 100 have a failure mode of 'Continue'; all other status codes have a failure mode of 'Terminate'.
接收包含状态数据项（第13.1节）的消息的DLEP参与者的行为由与状态代码字段值相关联的故障模式定义；见表2。所有小于100的状态代码值具有“继续”故障模式；所有其他状态代码的故障模式为“终止”。
A DLEP participant receiving any Message apart from a Session Termination Message (Section 12.9) containing a Status Data Item with a status code value with failure mode 'Terminate' MUST immediately issue a Session Termination Message echoing the received Status Data Item and then transition to the Session Termination state.
除会话终止消息（第12.9节）外，收到包含状态代码值为故障模式“Terminate”的状态数据项的任何消息的DLEP参与者必须立即发出会话终止消息，响应收到的状态数据项，然后转换到会话终止状态。
A DLEP participant receiving a Message containing a Status Data Item with a status code value with failure mode 'Continue' can continue normal operation of the session.
DLEP参与者接收到包含状态数据项的消息，该状态数据项的状态代码值为故障模式“Continue”，可以继续会话的正常操作。
A Peer Discovery Signal SHOULD be sent by a DLEP router to discover DLEP modems in the network; see Section 7.1.
DLEP路由器应发送对等发现信号，以发现网络中的DLEP调制解调器；见第7.1节。
A Peer Discovery Signal MUST be encoded within a UDP packet. The destination MUST be set to the DLEP well-known address and port number. For routers supporting both IPv4 and IPv6 DLEP operation, it is RECOMMENDED that IPv6 be selected as the transport. The source IP address MUST be set to the router IP address associated with the DLEP interface. There is no DLEP-specific restriction on source port.
对等发现信号必须在UDP数据包中进行编码。目标必须设置为DLEP已知地址和端口号。对于同时支持IPv4和IPv6 DLEP操作的路由器，建议选择IPv6作为传输。源IP地址必须设置为与DLEP接口关联的路由器IP地址。源端口上没有特定于DLEP的限制。
To construct a Peer Discovery Signal, the Signal Type value in the Signal Header is set to 1 (see "Signal Type Registration" (Section 15.2)).
为了构造对等发现信号，将信号头中的信号类型值设置为1（参见“信号类型注册”（第15.2节））。
The Peer Discovery Signal MAY contain a Peer Type Data Item (Section 13.4).
对等发现信号可能包含对等类型数据项（第13.4节）。
A Peer Offer Signal MUST be sent by a DLEP modem in response to a properly formatted and addressed Peer Discovery Signal (Section 12.3).
对等提供信号必须由DLEP调制解调器发送，以响应正确格式化和寻址的对等发现信号（第12.3节）。
A Peer Offer Signal MUST be encoded within a UDP packet. The IP source and destination fields in the packet MUST be set by swapping the values received in the Peer Discovery Signal. The Peer Offer Signal completes the discovery process; see Section 7.1.
对等提供信号必须在UDP数据包中进行编码。必须通过交换对等发现信号中接收的值来设置数据包中的IP源和目标字段。对等方提供信号完成发现过程；见第7.1节。
To construct a Peer Offer Signal, the Signal Type value in the Signal Header is set to 2 (see "Signal Type Registration" (Section 15.2)).
为了构造对等提供信号，将信号头中的信号类型值设置为2（参见“信号类型注册”（第15.2节））。
The Peer Offer Signal MAY contain a Peer Type Data Item (Section 13.4).
对等报价信号可能包含对等类型的数据项（第13.4节）。
The Peer Offer Signal MAY contain one or more of any of the following Data Items, with different values:
对等要约信号可以包含具有不同值的以下任一数据项中的一个或多个：
o IPv4 Connection Point (Section 13.2)
o IPv4连接点（第13.2节）
o IPv6 Connection Point (Section 13.3)
o IPv6连接点（第13.3节）
The IPv4 and IPv6 Connection Point Data Items indicate the unicast address the router MUST use when connecting the DLEP TCP session.
IPv4和IPv6连接点数据项表示路由器在连接DLEP TCP会话时必须使用的单播地址。
A Session Initialization Message MUST be sent by a DLEP router as the first Message of the DLEP TCP session. It is sent by the router after a TCP connect to an address/port combination that was obtained either via receipt of a Peer Offer or from a priori configuration.
会话初始化消息必须作为DLEP TCP会话的第一条消息由DLEP路由器发送。它由路由器在TCP连接到通过接收对等提供或从先验配置获得的地址/端口组合后发送。
To construct a Session Initialization Message, the Message Type value in the Message Header is set to 1 (see "Message Type Registration" (Section 15.3)).
要构造会话初始化消息，消息头中的消息类型值设置为1（请参阅“消息类型注册”（第15.3节））。
The Session Initialization Message MUST contain one of each of the following Data Items:
会话初始化消息必须包含以下每个数据项之一：
o Heartbeat Interval (Section 13.5)
o 心跳间隔（第13.5节）
o Peer Type (Section 13.4)
o 对等类型（第13.4节）
If DLEP extensions are supported, the Session Initialization Message MUST contain an Extensions Supported Data Item (Section 13.6).
如果支持DLEP扩展，会话初始化消息必须包含扩展支持的数据项（第13.6节）。
The Session Initialization Message MAY contain one or more of each of the following Data Items, with different values and with the Add/Drop (A) flag (Section 13) set to 1:
会话初始化消息可以包含以下每个数据项中的一个或多个，具有不同的值，并且添加/删除（A）标志（第13节）设置为1：
o IPv4 Address (Section 13.8)
o IPv4地址（第13.8节）
o IPv6 Address (Section 13.9)
o IPv6地址（第13.9节）
o IPv4 Attached Subnet (Section 13.10)
o IPv4连接的子网（第13.10节）
o IPv6 Attached Subnet (Section 13.11)
o IPv6连接子网（第13.11节）
If any optional extensions are supported by the implementation, they MUST be enumerated in the Extensions Supported Data Item. If an Extensions Supported Data Item does not exist in a Session Initialization Message, the modem MUST conclude that there is no support for extensions in the router.
如果实现支持任何可选扩展，则必须在扩展支持的数据项中枚举它们。如果会话初始化消息中不存在支持扩展的数据项，则调制解调器必须断定路由器中不支持扩展。
DLEP Heartbeats are not started until receipt of the Session Initialization Response Message (Section 12.6), and therefore implementations MUST use their own timeout heuristics for this Message.
在收到会话初始化响应消息（第12.6节）之前，不会启动DLEP心跳，因此实现必须为此消息使用自己的超时试探法。
As an exception to the general rule governing an implementation receiving an unrecognized Data Item in a Message (see Section 12.1), if a Session Initialization Message contains one or more Extensions Supported Data Items announcing support for extensions that the implementation does not recognize, then the implementation MAY ignore Data Items it does not recognize.
作为管理在消息中接收未识别数据项的实现的一般规则的例外（参见第12.1节），如果会话初始化消息包含一个或多个支持扩展的数据项，宣布支持该实现无法识别的扩展，然后，实现可能会忽略它无法识别的数据项。
A Session Initialization Response Message MUST be sent by a DLEP modem in response to a received Session Initialization Message (Section 12.5).
会话初始化响应消息必须由DLEP调制解调器发送，以响应接收到的会话初始化消息（第12.5节）。
To construct a Session Initialization Response Message, the Message Type value in the Message Header is set to 2 (see "Message Type Registration" (Section 15.3)).
要构造会话初始化响应消息，将消息头中的消息类型值设置为2（请参阅“消息类型注册”（第15.3节））。
The Session Initialization Response Message MUST contain one of each of the following Data Items:
会话初始化响应消息必须包含以下每个数据项之一：
o Status (Section 13.1)
o 状态（第13.1节）
o Peer Type (Section 13.4)
o 对等类型（第13.4节）
o Heartbeat Interval (Section 13.5)
o 心跳间隔（第13.5节）
o Maximum Data Rate (Receive) (Section 13.12)
o 最大数据速率（接收）（第13.12节）
o Maximum Data Rate (Transmit) (Section 13.13)
o 最大数据速率（传输）（第13.13节）
o Current Data Rate (Receive) (Section 13.14)
o 当前数据速率（接收）（第13.14节）
o Current Data Rate (Transmit) (Section 13.15)
o 当前数据速率（传输）（第13.15节）
o Latency (Section 13.16)
o 延迟（第13.16节）
The Session Initialization Response Message MUST contain one of each of the following Data Items, if the Data Item will be used during the lifetime of the session:
如果数据项将在会话的生存期内使用，则会话初始化响应消息必须包含以下每个数据项之一：
o Resources (Section 13.17)
o 资源（第13.17节）
o Relative Link Quality (Receive) (Section 13.18)
o 相对链路质量（接收）（第13.18节）
o Relative Link Quality (Transmit) (Section 13.19)
o 相对链路质量（传输）（第13.19节）
o Maximum Transmission Unit (MTU) (Section 13.20)
o 最大传输单位（MTU）（第13.20节）
If DLEP extensions are supported, the Session Initialization Response Message MUST contain an Extensions Supported Data Item (Section 13.6).
如果支持DLEP扩展，会话初始化响应消息必须包含扩展支持的数据项（第13.6节）。
The Session Initialization Response Message MAY contain one or more of each of the following Data Items, with different values and with the Add/Drop (A) flag (Section 13) set to 1:
会话初始化响应消息可以包含以下每个数据项中的一个或多个，具有不同的值，并且添加/删除（A）标志（第13节）设置为1：
o IPv4 Address (Section 13.8)
o IPv4地址（第13.8节）
o IPv6 Address (Section 13.9)
o IPv6地址（第13.9节）
o IPv4 Attached Subnet (Section 13.10)
o IPv4连接的子网（第13.10节）
o IPv6 Attached Subnet (Section 13.11)
o IPv6连接子网（第13.11节）
The Session Initialization Response Message completes the DLEP session establishment; the modem should transition to the In-Session state when the Message is sent, and the router should transition to the In-Session state upon receipt of an acceptable Session Initialization Response Message.
会话初始化响应消息完成DLEP会话建立；发送消息时，调制解调器应转换为会话内状态，路由器在收到可接受的会话初始化响应消息时应转换为会话内状态。
All supported metric Data Items MUST be included in the Session Initialization Response Message, with default values to be used on a session-wide basis. This can be viewed as the modem "declaring" all supported metrics at DLEP session initialization. Receipt of any
会话初始化响应消息中必须包含所有支持的度量数据项，并在会话范围内使用默认值。这可以看作是调制解调器在DLEP会话初始化时“声明”所有支持的度量。收到任何
further DLEP Message containing a metric Data Item not included in the Session Initialization Response Message MUST be treated as an error, resulting in the termination of the DLEP session between router and modem.
此外，包含未包含在会话初始化响应消息中的度量数据项的DLEP消息必须视为错误，从而导致路由器和调制解调器之间的DLEP会话终止。
If any optional extensions are supported by the modem, they MUST be enumerated in the Extensions Supported Data Item. If an Extensions Supported Data Item does not exist in a Session Initialization Response Message, the router MUST conclude that there is no support for extensions in the modem.
如果调制解调器支持任何可选扩展，则必须在支持的扩展数据项中枚举这些扩展。如果会话初始化响应消息中不存在支持扩展的数据项，路由器必须断定调制解调器中不支持扩展。
After the Session Initialization / Session Initialization Response Messages have been successfully exchanged, implementations MUST only use extensions that are supported by both DLEP participants; see Section 7.2.
会话初始化/会话初始化响应消息成功交换后，实现必须仅使用两个DLEP参与者都支持的扩展；见第7.2节。
A Session Update Message MAY be sent by a DLEP participant, on a session-wide basis, to indicate local Layer 3 address changes and/or metric changes.
DLEP参与者可在会话范围内发送会话更新消息，以指示本地第3层地址更改和/或度量更改。
To construct a Session Update Message, the Message Type value in the Message Header is set to 3 (see "Message Type Registration" (Section 15.3)).
要构造会话更新消息，消息头中的消息类型值设置为3（请参阅“消息类型注册”（第15.3节））。
The Session Update Message MAY contain one or more of each of the following Data Items, with different values:
会话更新消息可能包含以下每个数据项中的一个或多个，具有不同的值：
o IPv4 Address (Section 13.8)
o IPv4地址（第13.8节）
o IPv6 Address (Section 13.9)
o IPv6地址（第13.9节）
o IPv4 Attached Subnet (Section 13.10)
o IPv4连接的子网（第13.10节）
o IPv6 Attached Subnet (Section 13.11)
o IPv6连接子网（第13.11节）
When sent by a modem, the Session Update Message MAY contain one of each of the following Data Items:
由调制解调器发送时，会话更新消息可能包含以下数据项之一：
o Maximum Data Rate (Receive) (Section 13.12)
o 最大数据速率（接收）（第13.12节）
o Maximum Data Rate (Transmit) (Section 13.13)
o 最大数据速率（传输）（第13.13节）
o Current Data Rate (Receive) (Section 13.14)
o 当前数据速率（接收）（第13.14节）
o Current Data Rate (Transmit) (Section 13.15)
o 当前数据速率（传输）（第13.15节）
o Latency (Section 13.16)
o 延迟（第13.16节）
When sent by a modem, the Session Update Message MAY contain one of each of the following Data Items, if the Data Item is in use by the session:
由调制解调器发送时，如果会话正在使用以下数据项，则会话更新消息可能包含其中一个数据项：
o Resources (Section 13.17)
o 资源（第13.17节）
o Relative Link Quality (Receive) (Section 13.18)
o 相对链路质量（接收）（第13.18节）
o Relative Link Quality (Transmit) (Section 13.19)
o 相对链路质量（传输）（第13.19节）
o Maximum Transmission Unit (MTU) (Section 13.20)
o 最大传输单位（MTU）（第13.20节）
If metrics are supplied with the Session Update Message (e.g., Maximum Data Rate), these metrics are considered to be session-wide and therefore MUST be applied to all destinations in the information base associated with the DLEP session. This includes destinations for which metrics may have been stored based on received Destination Update messages.
如果在会话更新消息中提供了度量（例如，最大数据速率），则这些度量被视为会话范围，因此必须应用于与DLEP会话相关联的信息库中的所有目的地。这包括根据接收到的目的地更新消息存储度量的目的地。
It should be noted that Session Update Messages can be sent by both routers and modems. For example, the addition of an IPv4 address on the router MAY prompt a Session Update Message to its attached modems. Also, for example, a modem that changes its Maximum Data Rate (Receive) for all destinations MAY reflect that change via a Session Update Message to its attached router(s).
应该注意的是，会话更新消息可以由路由器和调制解调器发送。例如，在路由器上添加IPv4地址可能会向其连接的调制解调器提示会话更新消息。此外，例如，改变其所有目的地的最大数据速率（接收）的调制解调器可通过会话更新消息将该改变反映到其连接的路由器。
Concerning Layer 3 addresses and subnets: if the modem is capable of understanding and forwarding this information (via mechanisms not defined by DLEP), the update would prompt any remote DLEP-enabled modems to issue a Destination Update Message (Section 12.17) to their local routers with the new (or deleted) addresses and subnets.
关于第3层地址和子网：如果调制解调器能够理解和转发此信息（通过DLEP未定义的机制），则更新将提示任何远程启用DLEP的调制解调器向其本地路由器发送带有新（或删除）地址和子网的目的地更新消息（第12.17节）。
A Session Update Response Message MUST be sent by a DLEP participant when a Session Update Message (Section 12.7) is received.
当收到会话更新消息（第12.7节）时，DLEP参与者必须发送会话更新响应消息。
To construct a Session Update Response Message, the Message Type value in the Message Header is set to 4 (see "Message Type Registration" (Section 15.3)).
要构造会话更新响应消息，消息头中的消息类型值设置为4（请参阅“消息类型注册”（第15.3节））。
The Session Update Response Message MUST contain a Status Data Item (Section 13.1).
会话更新响应消息必须包含状态数据项（第13.1节）。
When a DLEP participant determines that the DLEP session needs to be terminated, the participant MUST send (or attempt to send) a Session Termination Message.
当DLEP参与者确定需要终止DLEP会话时，该参与者必须发送（或尝试发送）会话终止消息。
To construct a Session Termination Message, the Message Type value in the Message Header is set to 5 (see "Message Type Registration" (Section 15.3)).
要构造会话终止消息，消息头中的消息类型值设置为5（请参阅“消息类型注册”（第15.3节））。
The Session Termination Message MUST contain a Status Data Item (Section 13.1).
会话终止消息必须包含状态数据项（第13.1节）。
It should be noted that Session Termination Messages can be sent by both routers and modems.
应该注意，会话终止消息可以由路由器和调制解调器发送。
A Session Termination Response Message MUST be sent by a DLEP participant when a Session Termination Message (Section 12.9) is received.
当收到会话终止消息（第12.9节）时，DLEP参与者必须发送会话终止响应消息。
To construct a Session Termination Response Message, the Message Type value in the Message Header is set to 6 (see "Message Type Registration" (Section 15.3)).
要构造会话终止响应消息，消息头中的消息类型值设置为6（请参阅“消息类型注册”（第15.3节））。
There are no valid Data Items for the Session Termination Response Message.
会话终止响应消息没有有效的数据项。
Receipt of a Session Termination Response Message completes the teardown of the DLEP session; see Section 7.4.
接收到会话终止响应消息，完成DLEP会话的拆卸；见第7.4节。
Destination Up Messages MAY be sent by a modem to inform its attached router of the presence of a new reachable destination.
目的地上行消息可由调制解调器发送，以通知其连接的路由器存在新的可到达目的地。
To construct a Destination Up Message, the Message Type value in the Message Header is set to 7 (see "Message Type Registration" (Section 15.3)).
要构造目的地Up消息，消息头中的消息类型值设置为7（请参阅“消息类型注册”（第15.3节））。
The Destination Up Message MUST contain a MAC Address Data Item (Section 13.7).
目标Up消息必须包含MAC地址数据项（第13.7节）。
The Destination Up Message SHOULD contain one or more of each of the following Data Items, with different values:
目标向上消息应包含以下每个数据项中的一个或多个，具有不同的值：
o IPv4 Address (Section 13.8)
o IPv4地址（第13.8节）
o IPv6 Address (Section 13.9)
o IPv6地址（第13.9节）
The Destination Up Message MAY contain one of each of the following Data Items:
目标向上消息可能包含以下数据项之一：
o Maximum Data Rate (Receive) (Section 13.12)
o 最大数据速率（接收）（第13.12节）
o Maximum Data Rate (Transmit) (Section 13.13)
o 最大数据速率（传输）（第13.13节）
o Current Data Rate (Receive) (Section 13.14)
o 当前数据速率（接收）（第13.14节）
o Current Data Rate (Transmit) (Section 13.15)
o 当前数据速率（传输）（第13.15节）
o Latency (Section 13.16)
o 延迟（第13.16节）
The Destination Up Message MAY contain one of each of the following Data Items, if the Data Item is in use by the session:
如果会话正在使用数据项，则目标Up消息可能包含以下每个数据项中的一个：
o Resources (Section 13.17)
o 资源（第13.17节）
o Relative Link Quality (Receive) (Section 13.18)
o 相对链路质量（接收）（第13.18节）
o Relative Link Quality (Transmit) (Section 13.19)
o 相对链路质量（传输）（第13.19节）
o Maximum Transmission Unit (MTU) (Section 13.20)
o 最大传输单位（MTU）（第13.20节）
The Destination Up Message MAY contain one or more of each of the following Data Items, with different values:
目标向上消息可能包含以下每个数据项中的一个或多个，具有不同的值：
o IPv4 Attached Subnet (Section 13.10)
o IPv4连接的子网（第13.10节）
o IPv6 Attached Subnet (Section 13.11)
o IPv6连接子网（第13.11节）
A router receiving a Destination Up Message allocates the necessary resources, creating an entry in the information base with the specifics (MAC Address, Latency, Data Rate, etc.) of the destination. The information about this destination will persist in the router's information base until a Destination Down Message (Section 12.15) is received, indicating that the modem has lost contact with the remote node or that the implementation transitions to the Session Termination state.
接收目的地上行消息的路由器分配必要的资源，在信息库中创建一个条目，其中包含目的地的具体信息（MAC地址、延迟、数据速率等）。有关此目的地的信息将保留在路由器的信息库中，直到收到目的地关闭消息（第12.15节），表明调制解调器已与远程节点失去联系，或实现转换到会话终止状态。
A router MUST send a Destination Up Response Message when a Destination Up Message (Section 12.11) is received.
当收到目的地上行消息（第12.11节）时，路由器必须发送目的地上行响应消息。
To construct a Destination Up Response Message, the Message Type value in the Message Header is set to 8 (see "Message Type Registration" (Section 15.3)).
要构造目的地向上响应消息，消息头中的消息类型值设置为8（请参阅“消息类型注册”（第15.3节））。
The Destination Up Response Message MUST contain one of each of the following Data Items:
目标向上响应消息必须包含以下每个数据项之一：
o MAC Address (Section 13.7)
o MAC地址（第13.7节）
o Status (Section 13.1)
o 状态（第13.1节）
A router that wishes to receive further information concerning the destination identified in the corresponding Destination Up Message MUST set the status code of the included Status Data Item to 0 'Success'; see Table 2.
希望接收有关相应目的地Up消息中标识的目的地的进一步信息的路由器必须将包含的状态数据项的状态代码设置为0“成功”；见表2。
If the router has no interest in the destination identified in the corresponding Destination Up Message, then it MAY set the status code of the included Status Data Item to 1 'Not Interested'.
如果路由器对相应的目的地Up消息中标识的目的地不感兴趣，那么它可以将包括的状态数据项的状态代码设置为1“不感兴趣”。
A modem receiving a Destination Up Response Message containing a Status Data Item with a status code of any value other than 0 'Success' MUST NOT send further Destination Messages about the destination, e.g., Destination Down (Section 12.15) or Destination Update (Section 12.17) with the same MAC address.
接收到包含状态代码为0“成功”以外任何值的状态数据项的目标向上响应消息的调制解调器不得发送关于目标的进一步目标消息，例如，具有相同MAC地址的目标向下（第12.15节）或目标更新（第12.17节）。
Usually, a modem will discover the presence of one or more remote router/modem pairs and announce each destination's arrival by sending a corresponding Destination Up Message (Section 12.11) to the router. However, there may be times when a router wishes to express an interest in a destination that has yet to be announced, typically a multicast destination. Destination Announce Messages MAY be sent by a router to announce such an interest.
通常，调制解调器会发现存在一个或多个远程路由器/调制解调器对，并通过向路由器发送相应的目的地上行消息（第12.11节）来宣布每个目的地的到达。然而，有时路由器希望对尚未宣布的目的地（通常是多播目的地）表示兴趣。目的地通告消息可由路由器发送以通告这样的兴趣。
A Destination Announce Message MAY also be sent by a router to request information concerning a destination (1) in which the router has previously declined interest, via the 1 'Not Interested' status code in a Destination Up Response Message (Section 12.12) (see Table 2) or (2) that was previously declared as 'down', via the Destination Down Message (Section 12.15).
目的地通告消息也可由路由器发送，以通过目的地向上响应消息（第12.12节）（见表2）或（2）中的“不感兴趣”状态代码请求与路由器先前拒绝感兴趣的目的地（1）有关的信息，该目的地（1）先前被声明为“关闭”，通过目的地停机信息（第12.15节）。
To construct a Destination Announce Message, the Message Type value in the Message Header is set to 9 (see "Message Type Registration" (Section 15.3)).
要构造目的地公告消息，消息头中的消息类型值设置为9（请参阅“消息类型注册”（第15.3节））。
The Destination Announce Message MUST contain a MAC Address Data Item (Section 13.7).
目的地公告消息必须包含MAC地址数据项（第13.7节）。
The Destination Announce Message MAY contain zero or more of the following Data Items, with different values:
目标公告消息可能包含以下具有不同值的零个或多个数据项：
o IPv4 Address (Section 13.8)
o IPv4地址（第13.8节）
o IPv6 Address (Section 13.9)
o IPv6地址（第13.9节）
One of the advantages of implementing DLEP is to leverage the modem's knowledge of the links between remote destinations, allowing routers to avoid using probed neighbor discovery techniques; therefore, modem implementations SHOULD announce available destinations via the Destination Up Message, rather than relying on Destination Announce Messages.
实现DLEP的优点之一是利用调制解调器对远程目的地之间链路的了解，允许路由器避免使用探测邻居发现技术；因此，调制解调器实现应该通过目的地向上消息来宣布可用的目的地，而不是依赖目的地宣布消息。
A modem MUST send a Destination Announce Response Message when a Destination Announce Message (Section 12.13) is received.
当接收到目的地公告消息（第12.13节）时，调制解调器必须发送目的地公告响应消息。
To construct a Destination Announce Response Message, the Message Type value in the Message Header is set to 10 (see "Message Type Registration" (Section 15.3)).
要构造目的地公告响应消息，消息头中的消息类型值设置为10（请参阅“消息类型注册”（第15.3节））。
The Destination Announce Response Message MUST contain one of each of the following Data Items:
目标公告响应消息必须包含以下数据项之一：
o MAC Address (Section 13.7)
o MAC地址（第13.7节）
o Status (Section 13.1)
o 状态（第13.1节）
The Destination Announce Response Message MAY contain one or more of each of the following Data Items, with different values:
目标公告响应消息可能包含以下每个数据项中的一个或多个，具有不同的值：
o IPv4 Address (Section 13.8)
o IPv4地址（第13.8节）
o IPv6 Address (Section 13.9)
o IPv6地址（第13.9节）
o IPv4 Attached Subnet (Section 13.10)
o IPv4连接的子网（第13.10节）
o IPv6 Attached Subnet (Section 13.11)
o IPv6连接子网（第13.11节）
The Destination Announce Response Message MAY contain one of each of the following Data Items:
目标公告响应消息可能包含以下数据项之一：
o Maximum Data Rate (Receive) (Section 13.12)
o 最大数据速率（接收）（第13.12节）
o Maximum Data Rate (Transmit) (Section 13.13)
o 最大数据速率（传输）（第13.13节）
o Current Data Rate (Receive) (Section 13.14)
o 当前数据速率（接收）（第13.14节）
o Current Data Rate (Transmit) (Section 13.15)
o 当前数据速率（传输）（第13.15节）
o Latency (Section 13.16)
o 延迟（第13.16节）
The Destination Announce Response Message MAY contain one of each of the following Data Items, if the Data Item is in use by the session:
如果会话正在使用数据项，则目标公告响应消息可能包含以下数据项之一：
o Resources (Section 13.17)
o 资源（第13.17节）
o Relative Link Quality (Receive) (Section 13.18)
o 相对链路质量（接收）（第13.18节）
o Relative Link Quality (Transmit) (Section 13.19)
o 相对链路质量（传输）（第13.19节）
o Maximum Transmission Unit (MTU) (Section 13.20)
o 最大传输单位（MTU）（第13.20节）
If a modem is unable to report information immediately about the requested information -- for example, if the destination is not currently reachable -- the status code in the Status Data Item MUST be set to 2 'Request Denied'; see Table 2.
如果调制解调器无法立即报告有关请求信息的信息（例如，如果当前无法到达目的地），则状态数据项中的状态代码必须设置为2“请求被拒绝”；见表2。
After sending a Destination Announce Response Message containing a Status Data Item with a status code of 0 'Success', a modem then announces changes to the link to the destination via Destination Update Messages.
发送包含状态代码为0“Success”的状态数据项的目标公告响应消息后，调制解调器通过目标更新消息宣布对目标链接的更改。
When a successful Destination Announce Response Message is received, the router should add knowledge of the available destination to its information base.
当接收到成功的目的地通告响应消息时，路由器应将可用目的地的知识添加到其信息库中。
A modem MUST send a Destination Down Message to report when a destination (a remote node or a multicast group) is no longer reachable.
当目标（远程节点或多播组）不再可访问时，调制解调器必须发送目标关闭消息以报告。
A router MAY send a Destination Down Message to report when it no longer requires information concerning a destination.
当路由器不再需要关于目的地的信息时，它可以发送目的地关闭消息以进行报告。
To construct a Destination Down Message, the Message Type value in the Message Header is set to 11 (see "Message Type Registration" (Section 15.3)).
要构造目的地下行消息，消息头中的消息类型值设置为11（请参阅“消息类型注册”（第15.3节））。
The Destination Down Message MUST contain a MAC Address Data Item (Section 13.7).
目标停机消息必须包含MAC地址数据项（第13.7节）。
It should be noted that both modem and router may send a Destination Down Message to their peer, regardless of which participant initially indicated the destination to be 'up'.
应该注意的是，调制解调器和路由器都可以向其对等方发送目的地下行消息，而不管哪个参与者最初将目的地指示为“上行”。
A Destination Down Response Message MUST be sent by the recipient of a Destination Down Message (Section 12.15) to confirm that the relevant data concerning the destination has been removed from the information base.
目的地停机响应消息必须由目的地停机消息的接收者发送（第12.15节），以确认与目的地相关的数据已从信息库中删除。
To construct a Destination Down Response Message, the Message Type value in the Message Header is set to 12 (see "Message Type Registration" (Section 15.3)).
为了构造目的地下行响应消息，将消息头中的消息类型值设置为12（请参阅“消息类型注册”（第15.3节））。
The Destination Down Response Message MUST contain one of each of the following Data Items:
目标停机响应消息必须包含以下每个数据项之一：
o MAC Address (Section 13.7)
o MAC地址（第13.7节）
o Status (Section 13.1)
o 状态（第13.1节）
A modem SHOULD send a Destination Update Message when it detects some change in the information base for a given destination (remote node or multicast group). Some examples of changes that would prompt a Destination Update Message are as follows:
当调制解调器检测到给定目的地（远程节点或多播组）的信息库发生变化时，应发送目的地更新消息。提示目标更新消息的一些更改示例如下：
o Change in link metrics (e.g., data rates)
o 链路指标的变化（例如，数据速率）
o Layer 3 addressing change
o 第3层寻址更改
To construct a Destination Update Message, the Message Type value in the Message Header is set to 13 (see "Message Type Registration" (Section 15.3)).
要构造目的地更新消息，消息头中的消息类型值设置为13（请参阅“消息类型注册”（第15.3节））。
The Destination Update Message MUST contain a MAC Address Data Item (Section 13.7).
目标更新消息必须包含MAC地址数据项（第13.7节）。
The Destination Update Message MAY contain one of each of the following Data Items:
目标更新消息可能包含以下数据项之一：
o Maximum Data Rate (Receive) (Section 13.12)
o 最大数据速率（接收）（第13.12节）
o Maximum Data Rate (Transmit) (Section 13.13)
o 最大数据速率（传输）（第13.13节）
o Current Data Rate (Receive) (Section 13.14)
o 当前数据速率（接收）（第13.14节）
o Current Data Rate (Transmit) (Section 13.15)
o 当前数据速率（传输）（第13.15节）
o Latency (Section 13.16)
o 延迟（第13.16节）
The Destination Update Message MAY contain one of each of the following Data Items, if the Data Item is in use by the session:
如果会话正在使用数据项，则目标更新消息可能包含以下数据项之一：
o Resources (Section 13.17)
o 资源（第13.17节）
o Relative Link Quality (Receive) (Section 13.18)
o 相对链路质量（接收）（第13.18节）
o Relative Link Quality (Transmit) (Section 13.19)
o 相对链路质量（传输）（第13.19节）
o Maximum Transmission Unit (MTU) (Section 13.20)
o 最大传输单位（MTU）（第13.20节）
The Destination Update Message MAY contain one or more of each of the following Data Items, with different values:
目标更新消息可能包含以下每个数据项中的一个或多个，具有不同的值：
o IPv4 Address (Section 13.8)
o IPv4地址（第13.8节）
o IPv6 Address (Section 13.9)
o IPv6地址（第13.9节）
o IPv4 Attached Subnet (Section 13.10)
o IPv4连接的子网（第13.10节）
o IPv6 Attached Subnet (Section 13.11)
o IPv6连接子网（第13.11节）
Metrics supplied in this Message overwrite metrics provided in a previously received Session Message, Destination Message, or Link Characteristics Message (e.g., Session Initialization, Destination Up, Link Characteristics Response).
此消息中提供的度量覆盖先前接收到的会话消息、目标消息或链路特性消息（例如，会话初始化、目标向上、链路特性响应）中提供的度量。
It should be noted that this Message has no corresponding response.
应注意，此消息没有相应的响应。
The Link Characteristics Request Message MAY be sent by a router to request that the modem initiate changes for specific characteristics of the link. The request can reference either a real destination (e.g., a remote node) or a logical destination (e.g., a multicast group) within the network.
链路特性请求消息可由路由器发送，以请求调制解调器针对链路的特定特性发起更改。请求可以引用网络内的真实目的地（例如，远程节点）或逻辑目的地（例如，多播组）。
To construct a Link Characteristics Request Message, the Message Type value in the Message Header is set to 14 (see "Message Type Registration" (Section 15.3)).
为了构造链路特性请求消息，消息头中的消息类型值设置为14（参见“消息类型注册”（第15.3节））。
The Link Characteristics Request Message MUST contain a MAC Address Data Item (Section 13.7).
链路特性请求消息必须包含MAC地址数据项（第13.7节）。
The Link Characteristics Request Message MUST also contain at least one of each of the following Data Items:
链路特性请求消息还必须至少包含以下每个数据项中的一个：
o Current Data Rate (Receive) (Section 13.14)
o 当前数据速率（接收）（第13.14节）
o Current Data Rate (Transmit) (Section 13.15)
o 当前数据速率（传输）（第13.15节）
o Latency (Section 13.16)
o 延迟（第13.16节）
The Link Characteristics Request Message MAY contain either a Current Data Rate (Receive) (CDRR) or Current Data Rate (Transmit) (CDRT) Data Item to request a different data rate than is currently allocated, a Latency Data Item to request that traffic delay on the link not exceed the specified value, or both.
链路特性请求消息可以包含用于请求不同于当前分配的数据速率的当前数据速率（接收）（CDRR）或当前数据速率（传输）（CDRT）数据项、用于请求链路上的业务延迟不超过指定值的延迟数据项，或者两者都包含。
The router sending a Link Characteristics Request Message should be aware that a request may take an extended period of time to complete.
发送链路特性请求消息的路由器应该知道，请求可能需要较长的时间才能完成。
A modem MUST send a Link Characteristics Response Message when a Link Characteristics Request Message (Section 12.18) is received.
当收到链路特性请求消息（第12.18节）时，调制解调器必须发送链路特性响应消息。
To construct a Link Characteristics Response Message, the Message Type value in the Message Header is set to 15 (see "Message Type Registration" (Section 15.3)).
为了构造链路特性响应消息，消息头中的消息类型值设置为15（参见“消息类型注册”（第15.3节））。
The Link Characteristics Response Message MUST contain one of each of the following Data Items:
链路特性响应消息必须包含以下数据项之一：
o MAC Address (Section 13.7)
o MAC地址（第13.7节）
o Status (Section 13.1)
o 状态（第13.1节）
The Link Characteristics Response Message SHOULD contain one of each of the following Data Items:
链路特性响应消息应包含以下数据项之一：
o Maximum Data Rate (Receive) (Section 13.12)
o 最大数据速率（接收）（第13.12节）
o Maximum Data Rate (Transmit) (Section 13.13)
o 最大数据速率（传输）（第13.13节）
o Current Data Rate (Receive) (Section 13.14)
o 当前数据速率（接收）（第13.14节）
o Current Data Rate (Transmit) (Section 13.15)
o 当前数据速率（传输）（第13.15节）
o Latency (Section 13.16)
o 延迟（第13.16节）
The Link Characteristics Response Message MAY contain one of each of the following Data Items, if the Data Item is in use by the session:
如果会话正在使用数据项，则链路特性响应消息可以包含以下每个数据项中的一个：
o Resources (Section 13.17)
o 资源（第13.17节）
o Relative Link Quality (Receive) (Section 13.18)
o 相对链路质量（接收）（第13.18节）
o Relative Link Quality (Transmit) (Section 13.19)
o 相对链路质量（传输）（第13.19节）
o Maximum Transmission Unit (MTU) (Section 13.20)
o 最大传输单位（MTU）（第13.20节）
The Link Characteristics Response Message MUST contain a complete set of metric Data Items, referencing all metrics declared in the Session Initialization Response Message (Section 12.6). The values in the metric Data Items in the Link Characteristics Response Message MUST reflect the link characteristics after the request has been processed.
链路特性响应消息必须包含一整套度量数据项，引用会话初始化响应消息（第12.6节）中声明的所有度量。链路特性响应消息中度量数据项中的值必须反映处理请求后的链路特性。
If an implementation is not able to alter the characteristics of the link in the manner requested, then the status code of the Status Data Item MUST be set to 2 'Request Denied'; see Table 2.
如果实现无法以请求的方式改变链路的特性，则状态数据项的状态代码必须设置为2“请求被拒绝”；见表2。
A Heartbeat Message MUST be sent by a DLEP participant every N milliseconds, where N is defined in the Heartbeat Interval Data Item (Section 13.5) of the Session Initialization Message (Section 12.5) or Session Initialization Response Message (Section 12.6).
DLEP参与者必须每N毫秒发送一次心跳消息，其中N在会话初始化消息（第12.5节）或会话初始化响应消息（第12.6节）的心跳间隔数据项（第13.5节）中定义。
To construct a Heartbeat Message, the Message Type value in the Message Header is set to 16 (see "Message Type Registration" (Section 15.3)).
要构造心跳消息，消息头中的消息类型值设置为16（请参阅“消息类型注册”（第15.3节））。
There are no valid Data Items for the Heartbeat Message.
检测信号消息没有有效的数据项。
The Heartbeat Message is used by DLEP participants to detect when a DLEP session peer (either the modem or the router) is no longer communicating; see Section 7.3.1.
DLEP参与者使用心跳消息来检测DLEP会话对等方（调制解调器或路由器）何时不再通信；见第7.3.1节。
The core DLEP Data Items are as follows:
核心DLEP数据项如下所示：
+-------------+-----------------------------------------------------+
| Type Code | Description |
+-------------+-----------------------------------------------------+
| 0 | Reserved |
| | |
| 1 | Status (Section 13.1) |
| | |
| 2 | IPv4 Connection Point (Section 13.2) |
| | |
| 3 | IPv6 Connection Point (Section 13.3) |
| | |
| 4 | Peer Type (Section 13.4) |
| | |
| 5 | Heartbeat Interval (Section 13.5) |
| | |
| 6 | Extensions Supported (Section 13.6) |
| | |
| 7 | MAC Address (Section 13.7) |
| | |
| 8 | IPv4 Address (Section 13.8) |
| | |
| 9 | IPv6 Address (Section 13.9) |
| | |
| 10 | IPv4 Attached Subnet (Section 13.10) |
| | |
| 11 | IPv6 Attached Subnet (Section 13.11) |
| | |
| 12 | Maximum Data Rate (Receive) (MDRR) (Section 13.12) |
| | |
| 13 | Maximum Data Rate (Transmit) (MDRT) (Section 13.13) |
| | |
| 14 | Current Data Rate (Receive) (CDRR) (Section 13.14) |
| | |
| 15 | Current Data Rate (Transmit) (CDRT) (Section 13.15) |
| | |
| 16 | Latency (Section 13.16) |
| | |
| 17 | Resources (RES) (Section 13.17) |
| | |
+-------------+-----------------------------------------------------+
| Type Code | Description |
+-------------+-----------------------------------------------------+
| 0 | Reserved |
| | |
| 1 | Status (Section 13.1) |
| | |
| 2 | IPv4 Connection Point (Section 13.2) |
| | |
| 3 | IPv6 Connection Point (Section 13.3) |
| | |
| 4 | Peer Type (Section 13.4) |
| | |
| 5 | Heartbeat Interval (Section 13.5) |
| | |
| 6 | Extensions Supported (Section 13.6) |
| | |
| 7 | MAC Address (Section 13.7) |
| | |
| 8 | IPv4 Address (Section 13.8) |
| | |
| 9 | IPv6 Address (Section 13.9) |
| | |
| 10 | IPv4 Attached Subnet (Section 13.10) |
| | |
| 11 | IPv6 Attached Subnet (Section 13.11) |
| | |
| 12 | Maximum Data Rate (Receive) (MDRR) (Section 13.12) |
| | |
| 13 | Maximum Data Rate (Transmit) (MDRT) (Section 13.13) |
| | |
| 14 | Current Data Rate (Receive) (CDRR) (Section 13.14) |
| | |
| 15 | Current Data Rate (Transmit) (CDRT) (Section 13.15) |
| | |
| 16 | Latency (Section 13.16) |
| | |
| 17 | Resources (RES) (Section 13.17) |
| | |
| 18 | Relative Link Quality (Receive) (RLQR) |
| | (Section 13.18) |
| | |
| 19 | Relative Link Quality (Transmit) (RLQT) |
| | (Section 13.19) |
| | |
| 20 | Maximum Transmission Unit (MTU) (Section 13.20) |
| | |
| 21-65407 | Unassigned (available for future extensions) |
| | |
| 65408-65534 | Reserved for Private Use (available for |
| | experiments) |
| | |
| 65535 | Reserved |
+-------------+-----------------------------------------------------+
| 18 | Relative Link Quality (Receive) (RLQR) |
| | (Section 13.18) |
| | |
| 19 | Relative Link Quality (Transmit) (RLQT) |
| | (Section 13.19) |
| | |
| 20 | Maximum Transmission Unit (MTU) (Section 13.20) |
| | |
| 21-65407 | Unassigned (available for future extensions) |
| | |
| 65408-65534 | Reserved for Private Use (available for |
| | experiments) |
| | |
| 65535 | Reserved |
+-------------+-----------------------------------------------------+
Table 1: DLEP Data Item Types
表1:DLEP数据项类型
For the Session Termination Message (Section 12.9), the Status Data Item indicates a reason for the termination. For all response messages, the Status Data Item is used to indicate the success or failure of the previously received Message.
对于会话终止消息（第12.9节），状态数据项表示终止的原因。对于所有响应消息，状态数据项用于指示先前接收的消息的成功或失败。
The Status Data Item includes an optional Text field that can be used to provide a textual description of the status. The use of the Text field is entirely up to the receiving implementation, e.g., it could be output to a log file or discarded. If no Text field is supplied with the Status Data Item, the Length field MUST be set to 1.
状态数据项包括可选的文本字段，可用于提供状态的文本描述。文本字段的使用完全取决于接收实现，例如，它可以输出到日志文件或被丢弃。如果状态数据项未提供文本字段，则长度字段必须设置为1。
The Status Data Item contains the following fields:
状态数据项包含以下字段：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code | Text... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code | Text... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: 1
数据项类型：1
Length: 1 + Length of Text, in octets.
长度：1+文本长度，以八位字节为单位。
Status Code: One of the status codes defined in Table 2 below.
状态代码：下表2中定义的状态代码之一。
Text: UTF-8 encoded string of Unicode [RFC3629] characters, describing the cause, used for implementation-defined purposes. Since this field is used for description purposes, implementations SHOULD limit characters in this field to printable characters.
Text:Unicode[RFC3629]字符的UTF-8编码字符串，描述原因，用于实现定义的目的。由于此字段用于描述目的，因此实现应将此字段中的字符限制为可打印字符。
An implementation MUST NOT assume that the Text field is a NUL-terminated string of printable characters.
实现不能假定文本字段是以NUL结尾的可打印字符字符串。
+----------+-------------+------------------+-----------------------+
| Status | Failure | Description | Reason |
| Code | Mode | | |
+----------+-------------+------------------+-----------------------+
| 0 | Continue | Success | The Message was |
| | | | processed |
| | | | successfully. |
| | | | |
| 1 | Continue | Not Interested | The receiver is not |
| | | | interested in this |
| | | | Message subject, |
| | | | e.g., in a |
| | | | Destination Up |
| | | | Response Message |
| | | | (Section 12.12) to |
| | | | indicate no further |
| | | | Messages about the |
| | | | destination. |
| | | | |
| 2 | Continue | Request Denied | The receiver refuses |
| | | | to complete the |
| | | | request. |
| | | | |
| 3 | Continue | Inconsistent | One or more Data |
| | | Data | Items in the Message |
| | | | describe a logically |
| | | | inconsistent state in |
| | | | the network -- for |
| | | | example, in the |
| | | | Destination Up |
| | | | Message |
| | | | (Section 12.11) when |
| | | | an announced subnet |
| | | | clashes with an |
| | | | existing destination |
| | | | subnet. |
| | | | |
+----------+-------------+------------------+-----------------------+
| Status | Failure | Description | Reason |
| Code | Mode | | |
+----------+-------------+------------------+-----------------------+
| 0 | Continue | Success | The Message was |
| | | | processed |
| | | | successfully. |
| | | | |
| 1 | Continue | Not Interested | The receiver is not |
| | | | interested in this |
| | | | Message subject, |
| | | | e.g., in a |
| | | | Destination Up |
| | | | Response Message |
| | | | (Section 12.12) to |
| | | | indicate no further |
| | | | Messages about the |
| | | | destination. |
| | | | |
| 2 | Continue | Request Denied | The receiver refuses |
| | | | to complete the |
| | | | request. |
| | | | |
| 3 | Continue | Inconsistent | One or more Data |
| | | Data | Items in the Message |
| | | | describe a logically |
| | | | inconsistent state in |
| | | | the network -- for |
| | | | example, in the |
| | | | Destination Up |
| | | | Message |
| | | | (Section 12.11) when |
| | | | an announced subnet |
| | | | clashes with an |
| | | | existing destination |
| | | | subnet. |
| | | | |
| 4-111 | Continue | <Unassigned> | Available for future |
| | | | extensions. |
| | | | |
| 112-127 | Continue | <Reserved for | Available for |
| | | Private Use> | experiments. |
| | | | |
| 128 | Terminate | Unknown Message | The Message was not |
| | | | recognized by the |
| | | | implementation. |
| | | | |
| 129 | Terminate | Unexpected | The Message was not |
| | | Message | expected while the |
| | | | device was in the |
| | | | current state, e.g., |
| | | | a Session |
| | | | Initialization |
| | | | Message |
| | | | (Section 12.5) in |
| | | | the In-Session state. |
| | | | |
| 130 | Terminate | Invalid Data | One or more Data |
| | | | Items in the Message |
| | | | are invalid, |
| | | | unexpected, or |
| | | | incorrectly |
| | | | duplicated. |
| | | | |
| 131 | Terminate | Invalid | The destination |
| | | Destination | included in the |
| | | | Message does not |
| | | | match a previously |
| | | | announced destination |
| | | | -- for example, in |
| | | | the Link |
| | | | Characteristics |
| | | | Response Message |
| | | | (Section 12.19). |
| | | | |
| 132 | Terminate | Timed Out | The session has |
| | | | timed out. |
| | | | |
| 133-239 | Terminate | <Unassigned> | Available for future |
| | | | extensions. |
| | | | |
| 4-111 | Continue | <Unassigned> | Available for future |
| | | | extensions. |
| | | | |
| 112-127 | Continue | <Reserved for | Available for |
| | | Private Use> | experiments. |
| | | | |
| 128 | Terminate | Unknown Message | The Message was not |
| | | | recognized by the |
| | | | implementation. |
| | | | |
| 129 | Terminate | Unexpected | The Message was not |
| | | Message | expected while the |
| | | | device was in the |
| | | | current state, e.g., |
| | | | a Session |
| | | | Initialization |
| | | | Message |
| | | | (Section 12.5) in |
| | | | the In-Session state. |
| | | | |
| 130 | Terminate | Invalid Data | One or more Data |
| | | | Items in the Message |
| | | | are invalid, |
| | | | unexpected, or |
| | | | incorrectly |
| | | | duplicated. |
| | | | |
| 131 | Terminate | Invalid | The destination |
| | | Destination | included in the |
| | | | Message does not |
| | | | match a previously |
| | | | announced destination |
| | | | -- for example, in |
| | | | the Link |
| | | | Characteristics |
| | | | Response Message |
| | | | (Section 12.19). |
| | | | |
| 132 | Terminate | Timed Out | The session has |
| | | | timed out. |
| | | | |
| 133-239 | Terminate | <Unassigned> | Available for future |
| | | | extensions. |
| | | | |
| 240-254 | Terminate | <Reserved for | Available for |
| | | Private Use> | experiments. |
| | | | |
| 255 | Terminate | Shutting Down | The peer is |
| | | | terminating the |
| | | | session, as it is |
| | | | shutting down. |
+----------+-------------+------------------+-----------------------+
| 240-254 | Terminate | <Reserved for | Available for |
| | | Private Use> | experiments. |
| | | | |
| 255 | Terminate | Shutting Down | The peer is |
| | | | terminating the |
| | | | session, as it is |
| | | | shutting down. |
+----------+-------------+------------------+-----------------------+
Table 2: DLEP Status Codes
表2:DLEP状态代码
The IPv4 Connection Point Data Item indicates the IPv4 address and, optionally, the TCP port number on the modem available for connections. If provided, the router MUST use this information to initiate the TCP connection to the modem.
IPv4连接点数据项表示IPv4地址以及调制解调器上可用于连接的TCP端口号（可选）。如果提供，路由器必须使用此信息启动到调制解调器的TCP连接。
The IPv4 Connection Point Data Item contains the following fields:
IPv4连接点数据项包含以下字段：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | IPv4 Address... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ...cont. | TCP Port Number (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | IPv4 Address... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ...cont. | TCP Port Number (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: 2
数据项类型：2
Length: 5 (or 7 if TCP Port Number included).
长度：5（如果包含TCP端口号，则为7）。
Flags: Flags field, defined below.
标志：标志字段，定义如下。
IPv4 Address: The IPv4 address listening on the modem.
IPv4地址：在调制解调器上侦听的IPv4地址。
TCP Port Number: TCP port number on the modem.
TCP端口号：调制解调器上的TCP端口号。
If the Length field is 7, the port number specified MUST be used to establish the TCP session. If the TCP Port Number is omitted, i.e., the Length field is 5, the router MUST use the DLEP well-known port number (Section 15.14) to establish the TCP connection.
如果长度字段为7，则必须使用指定的端口号来建立TCP会话。如果省略TCP端口号，即长度字段为5，则路由器必须使用DLEP已知端口号（第15.14节）来建立TCP连接。
The Flags field is defined as:
标志字段定义为：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |T|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |T|
+-+-+-+-+-+-+-+-+
T: Use TLS flag, indicating whether the TCP connection to the given address and port requires the use of TLS [RFC5246] (1) or not (0).
T:使用TLS标志，指示到给定地址和端口的TCP连接是否需要使用TLS[RFC5246]（1）或（0）。
Reserved: MUST be zero. Left for future assignment.
保留：必须为零。留作将来的任务。
The IPv6 Connection Point Data Item indicates the IPv6 address and, optionally, the TCP port number on the modem available for connections. If provided, the router MUST use this information to initiate the TCP connection to the modem.
IPv6连接点数据项表示IPv6地址以及调制解调器上可用于连接的TCP端口号（可选）。如果提供，路由器必须使用此信息启动到调制解调器的TCP连接。
The IPv6 Connection Point Data Item contains the following fields:
IPv6连接点数据项包含以下字段：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | IPv6 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ...cont. | TCP Port Number (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | IPv6 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ...cont. | TCP Port Number (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: 3
数据项类型：3
Length: 17 (or 19 if TCP Port Number included).
长度：17（如果包含TCP端口号，则为19）。
Flags: Flags field, defined below.
标志：标志字段，定义如下。
IPv6 Address: The IPv6 address listening on the modem.
IPv6地址：在调制解调器上侦听的IPv6地址。
TCP Port Number: TCP port number on the modem.
TCP端口号：调制解调器上的TCP端口号。
If the Length field is 19, the port number specified MUST be used to establish the TCP session. If the TCP Port Number is omitted, i.e., the Length field is 17, the router MUST use the DLEP well-known port number (Section 15.14) to establish the TCP connection.
如果长度字段为19，则必须使用指定的端口号来建立TCP会话。如果省略TCP端口号，即长度字段为17，则路由器必须使用DLEP已知端口号（第15.14节）来建立TCP连接。
The Flags field is defined as:
标志字段定义为：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |T|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |T|
+-+-+-+-+-+-+-+-+
T: Use TLS flag, indicating whether the TCP connection to the given address and port requires the use of TLS [RFC5246] (1) or not (0).
T:使用TLS标志，指示到给定地址和端口的TCP连接是否需要使用TLS[RFC5246]（1）或（0）。
Reserved: MUST be zero. Left for future assignment.
保留：必须为零。留作将来的任务。
The Peer Type Data Item is used by the router and modem to give additional information as to its type and the properties of the over-the-air control plane.
路由器和调制解调器使用对等类型数据项提供有关其类型和空中控制平面属性的附加信息。
With some devices, access to the shared RF medium is strongly controlled. One example of this would be satellite modems -- where protocols, proprietary in nature, have been developed to ensure that a given modem has authorization to connect to the shared medium. Another example of this class of modems is governmental/military devices, where elaborate mechanisms have been developed to ensure that only authorized devices can connect to the shared medium. Contrasting with the above, there are modems where no such access control is used. An example of this class of modem would be one that supports the 802.11 ad hoc mode of operation. The Secured Medium (S) flag is used to indicate if access control is in place.
对于某些设备，对共享射频介质的访问受到严格控制。其中一个例子是卫星调制解调器——在这种情况下，已经开发出了具有专有性质的协议，以确保给定的调制解调器具有连接到共享介质的授权。这类调制解调器的另一个例子是政府/军事设备，在这些设备中，已经开发了复杂的机制，以确保只有授权设备才能连接到共享介质。与上述情况相反，有些调制解调器不使用这种访问控制。此类调制解调器的一个示例是支持802.11自组织操作模式的调制解调器。安全介质标志用于指示访问控制是否到位。
The Peer Type Data Item includes a textual description of the peer; it is envisioned that the text will be used for informational purposes (e.g., as output in a display command).
对等类型数据项包括对等的文本描述；预计文本将用于信息目的（例如，作为显示命令中的输出）。
The Peer Type Data Item contains the following fields:
对等类型数据项包含以下字段：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Description... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Description... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: 4
数据项类型：4
Length: 1 + Length of Description, in octets.
长度：1+描述长度，以八位字节为单位。
Flags: Flags field, defined below.
标志：标志字段，定义如下。
Description: UTF-8 encoded string of Unicode [RFC3629] characters. For example, a satellite modem might set this variable to "Satellite terminal". Since this Data Item is intended to provide additional information for display commands, sending implementations SHOULD limit the data to printable characters.
描述：Unicode[RFC3629]字符的UTF-8编码字符串。例如，卫星调制解调器可能会将此变量设置为“卫星终端”。由于此数据项旨在为显示命令提供附加信息，因此发送实现应将数据限制为可打印字符。
An implementation MUST NOT assume that the Description field is a NUL-terminated string of printable characters.
实现不能假定描述字段是以NUL结尾的可打印字符字符串。
The Flags field is defined as:
标志字段定义为：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |S|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |S|
+-+-+-+-+-+-+-+-+
S: Secured Medium flag, used by a modem to indicate whether the shared RF medium implements access control (1) or not (0). The Secured Medium flag only has meaning in Signals and Messages sent by a modem.
S：安全介质标志，由调制解调器用于指示共享射频介质是否实现访问控制（1）或（0）。安全介质标志仅在调制解调器发送的信号和消息中有意义。
Reserved: MUST be zero. Left for future assignment.
保留：必须为零。留作将来的任务。
The Heartbeat Interval Data Item is used to specify a period in milliseconds for Heartbeat Messages (Section 12.20).
心跳间隔数据项用于指定心跳消息的周期（以毫秒为单位）（第12.20节）。
The Heartbeat Interval Data Item contains the following fields:
心跳间隔数据项包含以下字段：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Heartbeat Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Heartbeat Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: 5
数据项类型：5
Length: 4
长度：4
Heartbeat Interval: The interval in milliseconds, expressed as a 32-bit unsigned integer, for Heartbeat Messages. This value MUST NOT be 0.
Heartbeat Interval：心跳消息的间隔（以毫秒为单位），表示为32位无符号整数。此值不能为0。
As mentioned before, receipt of any valid DLEP Message MUST reset the heartbeat interval timer (i.e., valid DLEP Messages take the place of, and obviate the need for, additional Heartbeat Messages).
如前所述，收到任何有效的DLEP消息都必须重置心跳间隔计时器（即，有效的DLEP消息取代并消除对额外心跳消息的需要）。
The Extensions Supported Data Item is used by the router and modem to negotiate additional optional functionality they are willing to support. The Extensions List is a concatenation of the types of each supported extension, found in the IANA registry titled "Extension Type Values". Each Extension Type definition includes which additional Signals and Data Items are supported.
路由器和调制解调器使用扩展支持的数据项协商它们愿意支持的其他可选功能。扩展列表是每个受支持扩展类型的串联，可在标题为“扩展类型值”的IANA注册表中找到。每个扩展类型定义包括支持哪些附加信号和数据项。
The Extensions Supported Data Item contains the following fields:
支持的扩展数据项包含以下字段：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions List... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions List... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: 6
数据项类型：6
Length: Length of the Extensions List in octets. This is twice (2x) the number of extensions.
长度：扩展列表的长度（以八位字节为单位）。这是扩展数量的两倍。
Extensions List: A list of extensions supported, identified by their 2-octet values as listed in the "Extension Type Values" registry.
扩展列表：支持的扩展列表，由“扩展类型值”注册表中列出的2个八位字节值标识。
The MAC Address Data Item contains the address of the destination on the remote node.
MAC地址数据项包含远程节点上的目标地址。
DLEP can support MAC addresses in either EUI-48 or EUI-64 format ("EUI" stands for "Extended Unique Identifier"), with the restriction that all MAC addresses for a given DLEP session MUST be in the same format and MUST be consistent with the MAC address format of the connected modem (e.g., if the modem is connected to the router with an EUI-48 MAC, all destination addresses via that modem MUST be expressed in EUI-48 format).
DLEP可以支持EUI-48或EUI-64格式的MAC地址（“EUI”代表“扩展唯一标识符”），但限制条件是给定DLEP会话的所有MAC地址必须采用相同的格式，并且必须与所连接调制解调器的MAC地址格式一致（例如，如果调制解调器通过EUI-48 MAC连接到路由器，则通过该调制解调器的所有目标地址必须以EUI-48格式表示）。
Examples of a virtual destination would be (1) a multicast MAC address or (2) the broadcast MAC address (FF:FF:FF:FF:FF:FF).
虚拟目的地的示例为（1）多播MAC地址或（2）广播MAC地址（FF:FF:FF:FF:FF）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: MAC Address : (if EUI-64 used) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: MAC Address : (if EUI-64 used) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: 7
数据项类型：7
Length: 6 for EUI-48 format or 8 for EUI-64 format.
长度：EUI-48格式为6，EUI-64格式为8。
MAC Address: MAC address of the destination.
MAC地址：目的地的MAC地址。
When included in the Session Update Message, this Data Item contains the IPv4 address of the peer. When included in Destination Messages, this Data Item contains the IPv4 address of the destination. In either case, the Data Item also contains an indication of whether this is (1) a new or existing address or (2) a deletion of a previously known address.
当包含在会话更新消息中时，此数据项包含对等方的IPv4地址。当包含在目标消息中时，此数据项包含目标的IPv4地址。在这两种情况下，数据项还包含以下指示：（1）新地址还是现有地址，或（2）删除先前已知的地址。
The IPv4 Address Data Item contains the following fields:
IPv4地址数据项包含以下字段：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | IPv4 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ...cont. |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | IPv4 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ...cont. |
+-+-+-+-+-+-+-+-+
Data Item Type: 8
数据项类型：8
Length: 5
长度：5
Flags: Flags field, defined below.
标志：标志字段，定义如下。
IPv4 Address: The IPv4 address of the destination or peer.
IPv4地址：目标或对等方的IPv4地址。
The Flags field is defined as:
标志字段定义为：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |A|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |A|
+-+-+-+-+-+-+-+-+
A: Add/Drop flag, indicating whether this is a new or existing address (1) or a withdrawal of an address (0).
A:添加/删除标志，指示这是新地址还是现有地址（1）或地址的撤消（0）。
Reserved: MUST be zero. Reserved for future use.
保留：必须为零。保留供将来使用。
Processing of the IPv4 Address Data Item MUST be done within the context of the DLEP peer session on which it is presented.
IPv4地址数据项的处理必须在其所在的DLEP对等会话的上下文中完成。
The handling of erroneous or logically inconsistent conditions depends upon the type of the message that contains the Data Item, as follows:
错误或逻辑不一致条件的处理取决于包含数据项的消息类型，如下所示：
If the containing message is a Session Message, e.g., a Session Initialization Message (Section 12.5) or Session Update Message (Section 12.7), the receiver of inconsistent information MUST issue a Session Termination Message (Section 12.9) containing a Status Data Item (Section 13.1) with status code set to 130 'Invalid Data' and transition to the Session Termination state. Examples of such conditions are:
如果包含的消息是会话消息，例如会话初始化消息（第12.5节）或会话更新消息（第12.7节），则不一致信息的接收方必须发出包含状态数据项（第13.1节）的会话终止消息（第12.9节）状态代码设置为130“无效数据”，并转换为会话终止状态。这些情况的例子如下：
o An address Drop operation referencing an address that is not associated with the peer in the current session.
o 引用与当前会话中的对等方不关联的地址的地址删除操作。
o An address Add operation referencing an address that has already been added to the peer in the current session.
o 引用已在当前会话中添加到对等方的地址的地址添加操作。
If the containing message is a Destination Message, e.g., a Destination Up Message (Section 12.11) or Destination Update Message (Section 12.17), the receiver of inconsistent information MAY issue the appropriate response message containing a Status Data Item with status code set to 3 'Inconsistent Data' but MUST continue with session processing. Examples of such conditions are:
如果包含的消息是目的地消息，例如，目的地上行消息（第12.11节）或目的地更新消息（第12.17节），则不一致信息的接收方可发出包含状态代码设置为3“不一致数据”的状态数据项的适当响应消息，但必须继续进行会话处理。这些情况的例子如下：
o An address Add operation referencing an address that has already been added to the destination in the current session.
o 地址添加操作，引用已在当前会话中添加到目标的地址。
o An address Add operation referencing an address that is associated with a different destination or the peer in the current session.
o 地址添加操作，引用与当前会话中的其他目标或对等方关联的地址。
o An address Add operation referencing an address that makes no sense -- for example, defined as not forwardable in [RFC6890].
o 一种地址添加操作，引用一个毫无意义的地址——例如，在[RFC6890]中定义为不可转发。
o An address Drop operation referencing an address that is not associated with the destination in the current session.
o 引用与当前会话中的目标不关联的地址的地址删除操作。
If no response message is appropriate -- for example, the Destination Update Message -- then the implementation MUST continue with session processing.
如果没有合适的响应消息（例如，目标更新消息），那么实现必须继续进行会话处理。
Modems that do not track IPv4 addresses MUST silently ignore IPv4 Address Data Items.
不跟踪IPv4地址的调制解调器必须以静默方式忽略IPv4地址数据项。
When included in the Session Update Message, this Data Item contains the IPv6 address of the peer. When included in Destination Messages, this Data Item contains the IPv6 address of the destination. In either case, the Data Item also contains an indication of whether this is (1) a new or existing address or (2) a deletion of a previously known address.
当包含在会话更新消息中时，此数据项包含对等方的IPv6地址。当包含在目标消息中时，此数据项包含目标的IPv6地址。在这两种情况下，数据项还包含以下指示：（1）新地址还是现有地址，或（2）删除先前已知的地址。
The IPv6 Address Data Item contains the following fields:
IPv6地址数据项包含以下字段：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | IPv6 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Address |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | IPv6 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Address |
+-+-+-+-+-+-+-+-+
Data Item Type: 9
数据项类型：9
Length: 17
长度：17
Flags: Flags field, defined below.
标志：标志字段，定义如下。
IPv6 Address: The IPv6 address of the destination or peer.
IPv6地址：目标或对等方的IPv6地址。
The Flags field is defined as:
标志字段定义为：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |A|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |A|
+-+-+-+-+-+-+-+-+
A: Add/Drop flag, indicating whether this is a new or existing address (1) or a withdrawal of an address (0).
A:添加/删除标志，指示这是新地址还是现有地址（1）或地址的撤消（0）。
Reserved: MUST be zero. Reserved for future use.
保留：必须为零。保留供将来使用。
Processing of the IPv6 Address Data Item MUST be done within the context of the DLEP peer session on which it is presented.
IPv6地址数据项的处理必须在其所在的DLEP对等会话的上下文中完成。
The handling of erroneous or logically inconsistent conditions depends upon the type of the message that contains the Data Item, as follows:
错误或逻辑不一致条件的处理取决于包含数据项的消息类型，如下所示：
If the containing message is a Session Message, e.g., a Session Initialization Message (Section 12.5) or Session Update Message (Section 12.7), the receiver of inconsistent information MUST issue a Session Termination Message (Section 12.9) containing a Status Data Item (Section 13.1) with status code set to 130 'Invalid Data' and transition to the Session Termination state. Examples of such conditions are:
如果包含的消息是会话消息，例如会话初始化消息（第12.5节）或会话更新消息（第12.7节），则不一致信息的接收方必须发出包含状态数据项（第13.1节）的会话终止消息（第12.9节）状态代码设置为130“无效数据”，并转换为会话终止状态。这些情况的例子如下：
o An address Drop operation referencing an address that is not associated with the peer in the current session.
o 引用与当前会话中的对等方不关联的地址的地址删除操作。
o An address Add operation referencing an address that has already been added to the peer in the current session.
o 引用已在当前会话中添加到对等方的地址的地址添加操作。
If the containing message is a Destination Message, e.g., a Destination Up Message (Section 12.11) or Destination Update Message (Section 12.17), the receiver of inconsistent information MAY issue the appropriate response message containing a Status Data Item with status code set to 3 'Inconsistent Data' but MUST continue with session processing. Examples of such conditions are:
如果包含的消息是目的地消息，例如，目的地上行消息（第12.11节）或目的地更新消息（第12.17节），则不一致信息的接收方可发出包含状态代码设置为3“不一致数据”的状态数据项的适当响应消息，但必须继续进行会话处理。这些情况的例子如下：
o An address Add operation referencing an address that has already been added to the destination in the current session.
o 地址添加操作，引用已在当前会话中添加到目标的地址。
o An address Add operation referencing an address that is associated with a different destination or the peer in the current session.
o 地址添加操作，引用与当前会话中的其他目标或对等方关联的地址。
o An address Add operation referencing an address that makes no sense -- for example, defined as not forwardable in [RFC6890].
o 一种地址添加操作，引用一个毫无意义的地址——例如，在[RFC6890]中定义为不可转发。
o An address Drop operation referencing an address that is not associated with the destination in the current session.
o 引用与当前会话中的目标不关联的地址的地址删除操作。
If no response message is appropriate -- for example, the Destination Update Message -- then the implementation MUST continue with session processing.
如果没有合适的响应消息（例如，目标更新消息），那么实现必须继续进行会话处理。
Modems that do not track IPv6 addresses MUST silently ignore IPv6 Address Data Items.
不跟踪IPv6地址的调制解调器必须以静默方式忽略IPv6地址数据项。
The DLEP IPv4 Attached Subnet Data Item allows a device to declare that it has an IPv4 subnet (e.g., a stub network) attached, that it has become aware of an IPv4 subnet being present at a remote destination, or that it has become aware of the loss of a subnet at the remote destination.
DLEP IPv4附加子网数据项允许设备声明其已附加IPv4子网（例如存根网络），它已意识到远程目标上存在IPv4子网，或者它已意识到远程目标上的子网丢失。
The DLEP IPv4 Attached Subnet Data Item contains the following fields:
DLEP IPv4连接的子网数据项包含以下字段：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | IPv4 Attached Subnet :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ...cont. |Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | IPv4 Attached Subnet :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ...cont. |Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: 10
数据项类型：10
Length: 6
长度：6
Flags: Flags field, defined below.
标志：标志字段，定义如下。
IPv4 Attached Subnet: The IPv4 subnet reachable at the destination.
IPv4连接的子网：可在目标位置访问的IPv4子网。
Prefix Length: Length of the prefix (0-32) for the IPv4 subnet. A prefix length outside the specified range MUST be considered as invalid.
前缀长度：IPv4子网的前缀长度（0-32）。超出指定范围的前缀长度必须视为无效。
The Flags field is defined as:
标志字段定义为：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |A|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |A|
+-+-+-+-+-+-+-+-+
A: Add/Drop flag, indicating whether this is a new or existing subnet address (1) or a withdrawal of a subnet address (0).
A：添加/删除标志，指示这是新的或现有的子网地址（1）还是子网地址（0）的撤消。
Reserved: MUST be zero. Reserved for future use.
保留：必须为零。保留供将来使用。
Processing of the IPv4 Attached Subnet Data Item MUST be done within the context of the DLEP peer session on which it is presented.
IPv4连接的子网数据项的处理必须在其所在的DLEP对等会话的上下文中完成。
If the containing message is a Session Message, e.g., a Session Initialization Message (Section 12.5) or Session Update Message (Section 12.7), the receiver of inconsistent information MUST issue a Session Termination Message (Section 12.9) containing a Status Data Item (Section 13.1) with status code set to 130 'Invalid Data' and transition to the Session Termination state. Examples of such conditions are:
如果包含的消息是会话消息，例如会话初始化消息（第12.5节）或会话更新消息（第12.7节），则不一致信息的接收方必须发出包含状态数据项（第13.1节）的会话终止消息（第12.9节）状态代码设置为130“无效数据”，并转换为会话终止状态。这些情况的例子如下：
o A subnet Drop operation referencing a subnet that is not associated with the peer in the current session.
o 引用与当前会话中的对等方不关联的子网的子网删除操作。
o A subnet Add operation referencing a subnet that has already been added to the peer in the current session.
o 引用已在当前会话中添加到对等方的子网的子网添加操作。
If the containing message is a Destination Message, e.g., a Destination Up Message (Section 12.11) or Destination Update Message (Section 12.17), the receiver of inconsistent information MAY issue the appropriate response message containing a Status Data Item with status code set to 3 'Inconsistent Data' but MUST continue with session processing. Examples of such conditions are:
如果包含的消息是目的地消息，例如，目的地上行消息（第12.11节）或目的地更新消息（第12.17节），则不一致信息的接收方可发出包含状态代码设置为3“不一致数据”的状态数据项的适当响应消息，但必须继续进行会话处理。这些情况的例子如下：
o A subnet Add operation referencing a subnet that has already been added to the destination in the current session.
o 引用已在当前会话中添加到目标的子网的子网添加操作。
o A subnet Add operation referencing a subnet that is associated with a different destination in the current session.
o 引用与当前会话中的不同目标关联的子网的子网添加操作。
o A subnet Add operation referencing a subnet that makes no sense -- for example, defined as not forwardable in [RFC6890].
o 子网添加操作引用的子网毫无意义，例如，在[RFC6890]中定义为不可转发。
o A subnet Drop operation referencing a subnet that is not associated with the destination in the current session.
o 引用与当前会话中的目标不关联的子网的子网删除操作。
If no response message is appropriate -- for example, the Destination Update Message -- then the implementation MUST continue with session processing.
如果没有合适的响应消息（例如，目标更新消息），那么实现必须继续进行会话处理。
Modems that do not track IPv4 subnets MUST silently ignore IPv4 Attached Subnet Data Items.
不跟踪IPv4子网的调制解调器必须以静默方式忽略IPv4连接的子网数据项。
The DLEP IPv6 Attached Subnet Data Item allows a device to declare that it has an IPv6 subnet (e.g., a stub network) attached, that it has become aware of an IPv6 subnet being present at a remote destination, or that it has become aware of the loss of a subnet at the remote destination.
DLEP IPv6附加子网数据项允许设备声明其已附加IPv6子网（例如，存根网络）、已意识到远程目的地存在IPv6子网或已意识到远程目的地丢失子网。
The DLEP IPv6 Attached Subnet Data Item contains the following fields:
DLEP IPv6连接的子网数据项包含以下字段：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | IPv6 Attached Subnet :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Attached Subnet :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Attached Subnet :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Attached Subnet :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ...cont. | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | IPv6 Attached Subnet :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Attached Subnet :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Attached Subnet :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Attached Subnet :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ...cont. | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: 11
数据项类型：11
Length: 18
长度：18
Flags: Flags field, defined below.
标志：标志字段，定义如下。
IPv6 Attached Subnet: The IPv6 subnet reachable at the destination.
IPv6连接的子网：可在目标上访问的IPv6子网。
Prefix Length: Length of the prefix (0-128) for the IPv6 subnet. A prefix length outside the specified range MUST be considered as invalid.
前缀长度：IPv6子网的前缀长度（0-128）。超出指定范围的前缀长度必须视为无效。
The Flags field is defined as:
标志字段定义为：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |A|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |A|
+-+-+-+-+-+-+-+-+
A: Add/Drop flag, indicating whether this is a new or existing subnet address (1) or a withdrawal of a subnet address (0).
A：添加/删除标志，指示这是新的或现有的子网地址（1）还是子网地址（0）的撤消。
Reserved: MUST be zero. Reserved for future use.
保留：必须为零。保留供将来使用。
Processing of the IPv6 Attached Subnet Data Item MUST be done within the context of the DLEP peer session on which it is presented.
必须在呈现IPv6连接子网数据项的DLEP对等会话的上下文中处理该数据项。
If the containing message is a Session Message, e.g., a Session Initialization Message (Section 12.5) or Session Update Message (Section 12.7), the receiver of inconsistent information MUST issue a Session Termination Message (Section 12.9) containing a Status Data Item (Section 13.1) with status code set to 130 'Invalid Data' and transition to the Session Termination state. Examples of such conditions are:
如果包含的消息是会话消息，例如会话初始化消息（第12.5节）或会话更新消息（第12.7节），则不一致信息的接收方必须发出包含状态数据项（第13.1节）的会话终止消息（第12.9节）状态代码设置为130“无效数据”，并转换为会话终止状态。这些情况的例子如下：
o A subnet Drop operation referencing a subnet that is not associated with the peer in the current session.
o 引用与当前会话中的对等方不关联的子网的子网删除操作。
o A subnet Add operation referencing a subnet that has already been added to the peer in the current session.
o 引用已在当前会话中添加到对等方的子网的子网添加操作。
If the containing message is a Destination Message, e.g., a Destination Up Message (Section 12.11) or Destination Update Message (Section 12.17), the receiver of inconsistent information MAY issue the appropriate response message containing a Status Data Item with status code set to 3 'Inconsistent Data' but MUST continue with session processing. Examples of such conditions are:
如果包含的消息是目的地消息，例如，目的地上行消息（第12.11节）或目的地更新消息（第12.17节），则不一致信息的接收方可发出包含状态代码设置为3“不一致数据”的状态数据项的适当响应消息，但必须继续进行会话处理。这些情况的例子如下：
o A subnet Add operation referencing a subnet that has already been added to the destination in the current session.
o 引用已在当前会话中添加到目标的子网的子网添加操作。
o A subnet Add operation referencing a subnet that is associated with a different destination in the current session.
o 引用与当前会话中的不同目标关联的子网的子网添加操作。
o A subnet Add operation referencing a subnet that makes no sense -- for example, defined as not forwardable in [RFC6890].
o 子网添加操作引用的子网毫无意义，例如，在[RFC6890]中定义为不可转发。
o A subnet Drop operation referencing a subnet that is not associated with the destination in the current session.
o 引用与当前会话中的目标不关联的子网的子网删除操作。
If no response message is appropriate -- for example, the Destination Update Message -- then the implementation MUST continue with session processing.
如果没有合适的响应消息（例如，目标更新消息），那么实现必须继续进行会话处理。
Modems that do not track IPv6 subnets MUST silently ignore IPv6 Attached Subnet Data Items.
不跟踪IPv6子网的调制解调器必须以静默方式忽略IPv6连接的子网数据项。
The Maximum Data Rate (Receive) (MDRR) Data Item is used to indicate the maximum theoretical data rate, in bits per second (bps), that can be achieved while receiving data on the link.
最大数据速率（接收）（MDRR）数据项用于指示在链路上接收数据时可以达到的最大理论数据速率，单位为比特/秒（bps）。
The Maximum Data Rate (Receive) Data Item contains the following fields:
最大数据速率（接收）数据项包含以下字段：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MDRR (bps) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: MDRR (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MDRR (bps) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: MDRR (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: 12
数据项类型：12
Length: 8
长度：8
Maximum Data Rate (Receive): A 64-bit unsigned integer, representing the maximum theoretical data rate, in bits per second, that can be achieved while receiving on the link.
最大数据速率（接收）：一个64位无符号整数，表示链路上接收时可以达到的最大理论数据速率，单位为位/秒。
The Maximum Data Rate (Transmit) (MDRT) Data Item is used to indicate the maximum theoretical data rate, in bits per second, that can be achieved while transmitting data on the link.
最大数据速率（传输）（MDRT）数据项用于指示在链路上传输数据时可以达到的最大理论数据速率，单位为比特/秒。
The Maximum Data Rate (Transmit) Data Item contains the following fields:
最大数据速率（传输）数据项包含以下字段：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MDRT (bps) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: MDRT (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MDRT (bps) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: MDRT (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: 13
数据项类型：13
Length: 8
长度：8
Maximum Data Rate (Transmit): A 64-bit unsigned integer, representing the maximum theoretical data rate, in bits per second, that can be achieved while transmitting on the link.
最大数据速率（传输）：一个64位无符号整数，表示在链路上传输时可以达到的最大理论数据速率，单位为比特/秒。
The Current Data Rate (Receive) (CDRR) Data Item is used to indicate the rate at which the link is currently operating for receiving traffic.
当前数据速率（接收）（CDRR）数据项用于指示链路当前用于接收流量的速率。
When used in the Link Characteristics Request Message (Section 12.18), Current Data Rate (Receive) represents the desired receive rate, in bits per second, on the link.
当在链路特性请求消息（第12.18节）中使用时，当前数据速率（Receive）表示链路上的期望接收速率，单位为比特/秒。
The Current Data Rate (Receive) Data Item contains the following fields:
当前数据速率（接收）数据项包含以下字段：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CDRR (bps) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: CDRR (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CDRR (bps) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: CDRR (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: 14
数据项类型：14
Length: 8
长度：8
Current Data Rate (Receive): A 64-bit unsigned integer, representing the current data rate, in bits per second, that can currently be achieved while receiving traffic on the link.
当前数据速率（Receive）：一个64位无符号整数，表示当前数据速率（以位/秒为单位），当前在链路上接收流量时可以实现该速率。
If there is no distinction between Current Data Rate (Receive) and Maximum Data Rate (Receive) (Section 13.12), Current Data Rate (Receive) MUST be set equal to Maximum Data Rate (Receive). Current Data Rate (Receive) MUST NOT exceed Maximum Data Rate (Receive).
如果当前数据速率（接收）和最大数据速率（接收）之间没有区别（第13.12节），则当前数据速率（接收）必须设置为等于最大数据速率（接收）。当前数据速率（接收）不得超过最大数据速率（接收）。
The Current Data Rate (Transmit) (CDRT) Data Item is used to indicate the rate at which the link is currently operating for transmitting traffic.
当前数据速率（传输）（CDRT）数据项用于指示链路当前用于传输业务的速率。
When used in the Link Characteristics Request Message (Section 12.18), Current Data Rate (Transmit) represents the desired transmit rate, in bits per second, on the link.
当在链路特性请求消息（第12.18节）中使用时，当前数据速率（传输）表示链路上的期望传输速率，单位为比特/秒。
The Current Data Rate (Transmit) Data Item contains the following fields:
当前数据速率（传输）数据项包含以下字段：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CDRT (bps) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: CDRT (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CDRT (bps) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: CDRT (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: 15
数据项类型：15
Length: 8
长度：8
Current Data Rate (Transmit): A 64-bit unsigned integer, representing the current data rate, in bits per second, that can currently be achieved while transmitting traffic on the link.
当前数据速率（传输）：一个64位无符号整数，表示当前数据速率（以位/秒为单位），当前在链路上传输流量时可以达到该速率。
If there is no distinction between Current Data Rate (Transmit) and Maximum Data Rate (Transmit) (Section 13.13), Current Data Rate (Transmit) MUST be set equal to Maximum Data Rate (Transmit). Current Data Rate (Transmit) MUST NOT exceed Maximum Data Rate (Transmit).
如果当前数据速率（传输）和最大数据速率（传输）（第13.13节）之间没有区别，则当前数据速率（传输）必须设置为等于最大数据速率（传输）。当前数据速率（传输）不得超过最大数据速率（传输）。
The Latency Data Item is used to indicate the amount of latency, in microseconds, on the link.
延迟数据项用于指示链路上的延迟量（以微秒为单位）。
The Latency value is reported as transmission delay. The calculation of latency is implementation dependent. For example, the latency may be a running average calculated from the internal queuing.
延迟值报告为传输延迟。延迟的计算取决于实现。例如，延迟可以是从内部队列计算的运行平均值。
The Latency Data Item contains the following fields:
延迟数据项包含以下字段：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latency :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Latency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latency :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Latency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: 16
数据项类型：16
Length: 8
长度：8
Latency: A 64-bit unsigned integer, representing the transmission delay, in microseconds, that a packet encounters as it is transmitted over the link.
延迟：64位无符号整数，表示数据包在链路上传输时遇到的传输延迟（以微秒为单位）。
The Resources (RES) Data Item is used to indicate the amount of finite resources available for data transmission and reception at the destination as a percentage, with 0 meaning 'no resources remaining' and 100 meaning 'a full supply', assuming that when Resources reaches 0 data transmission and/or reception will cease.
资源（RES）数据项用于以百分比表示目的地可用于数据传输和接收的有限资源量，0表示“无剩余资源”，100表示“完全供应”，假设资源达到0时，数据传输和/或接收将停止。
An example of such resources is battery life, but this could also include resources such as available memory for queuing, or CPU idle percentage. The specific criteria to be used for this metric is out of scope for this specification and is implementation specific.
此类资源的一个例子是电池寿命，但这也可能包括资源，如用于排队的可用内存或CPU空闲百分比。用于此度量的特定标准超出了本规范的范围，并且是特定于实现的。
This Data Item is designed to be used as an indication of some capability of the modem and/or router at the destination.
此数据项设计用于指示目的地的调制解调器和/或路由器的某些功能。
The Resources Data Item contains the following fields:
资源数据项包含以下字段：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES |
+-+-+-+-+-+-+-+-+
Data Item Type: 17
数据项类型：17
Length: 1
长度：1
Resources: An 8-bit unsigned integer percentage, 0-100, representing the amount of resources available. Any value greater than 100 MUST be considered as invalid.
资源：8位无符号整数百分比，0-100，表示可用资源量。任何大于100的值都必须视为无效。
If a device cannot calculate Resources, this Data Item MUST NOT be issued.
如果设备无法计算资源，则不得发布此数据项。
The Relative Link Quality (Receive) (RLQR) Data Item is used to indicate the quality of the link to a destination for receiving traffic, with 0 meaning 'worst quality' and 100 meaning 'best quality'.
相对链路质量（接收）（RLQR）数据项用于指示到接收流量目的地的链路质量，0表示“最差质量”，100表示“最佳质量”。
Quality in this context is defined as an indication of the stability of a link for reception; a destination with high Relative Link Quality (Receive) is expected to have generally stable DLEP metrics, and the metrics of a destination with low Relative Link Quality (Receive) can be expected to rapidly fluctuate over a wide range.
在这种情况下，质量被定义为接收链路稳定性的指示；具有高相对链路质量（Receive）的目的地预期具有通常稳定的DLEP度量，并且具有低相对链路质量（Receive）的目的地的度量可预期在宽范围内快速波动。
The Relative Link Quality (Receive) Data Item contains the following fields:
相对链接质量（接收）数据项包含以下字段：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RLQR |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RLQR |
+-+-+-+-+-+-+-+-+
Data Item Type: 18
数据项类型：18
Length: 1
长度：1
Relative Link Quality (Receive): A non-dimensional unsigned 8-bit integer, 0-100, representing relative quality of the link for receiving traffic. Any value greater than 100 MUST be considered as invalid.
相对链路质量（Receive）：一个无量纲无符号8位整数，0-100，表示接收流量的链路的相对质量。任何大于100的值都必须视为无效。
If a device cannot calculate Relative Link Quality (Receive), this Data Item MUST NOT be issued.
如果设备无法计算相对链路质量（接收），则不得发布此数据项。
The Relative Link Quality (Transmit) (RLQT) Data Item is used to indicate the quality of the link to a destination for transmitting traffic, with 0 meaning 'worst quality' and 100 meaning 'best quality'.
相对链路质量（传输）（RLQT）数据项用于指示到传输业务目的地的链路质量，0表示“最差质量”，100表示“最佳质量”。
Quality in this context is defined as an indication of the stability of a link for transmission; a destination with high Relative Link Quality (Transmit) is expected to have generally stable DLEP metrics, and the metrics of a destination with low Relative Link Quality (Transmit) can be expected to rapidly fluctuate over a wide range.
在这种情况下，质量被定义为传输链路稳定性的指示；具有高相对链路质量（传输）的目的地预期具有通常稳定的DLEP度量，并且具有低相对链路质量（传输）的目的地的度量可以预期在宽范围内快速波动。
The Relative Link Quality (Transmit) Data Item contains the following fields:
相对链路质量（传输）数据项包含以下字段：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RLQT |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RLQT |
+-+-+-+-+-+-+-+-+
Data Item Type: 19
数据项类型：19
Length: 1
长度：1
Relative Link Quality (Transmit): A non-dimensional unsigned 8-bit integer, 0-100, representing relative quality of the link for transmitting traffic. Any value greater than 100 MUST be considered as invalid.
相对链路质量（传输）：无量纲无符号8位整数，0-100，表示传输流量的链路的相对质量。任何大于100的值都必须视为无效。
If a device cannot calculate Relative Link Quality (Transmit), this Data Item MUST NOT be issued.
如果设备无法计算相对链路质量（传输），则不得发布此数据项。
The Maximum Transmission Unit (MTU) Data Item is used to indicate the maximum size, in octets, of an IP packet that can be transmitted without fragmentation, including headers, but excluding any lower-layer headers.
最大传输单元（MTU）数据项用于指示可以在不分段的情况下传输的IP数据包的最大大小（以八位字节为单位），包括报头，但不包括任何较低层报头。
The Maximum Transmission Unit Data Item contains the following fields:
最大传输单位数据项包含以下字段：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: 20
数据项类型：20
Length: 2
长度：2
Maximum Transmission Unit: The maximum size, in octets, of an IP packet that can be transmitted without fragmentation, including headers, but excluding any lower-layer headers.
最大传输单位：一个IP数据包的最大大小，以八位字节为单位，可以在没有碎片的情况下传输，包括报头，但不包括任何较低层的报头。
If a device cannot calculate Maximum Transmission Unit, this Data Item MUST NOT be issued.
如果设备无法计算最大传输单位，则不得发布此数据项。
The potential security concerns when using DLEP are as follows:
使用DLEP时的潜在安全问题如下：
1. An attacker might pretend to be a DLEP participant, either at DLEP session initialization or by injection of DLEP Messages once a session has been established.
1. 攻击者可以在DLEP会话初始化时或在会话建立后通过注入DLEP消息假装为DLEP参与者。
2. DLEP Data Items could be altered by an attacker, causing the receiving implementation to inappropriately alter its information base concerning network status.
2. 攻击者可以更改DLEP数据项，从而导致接收实现不适当地更改其有关网络状态的信息库。
3. An attacker could join an unsecured radio network and inject over-the-air signals that maliciously influence the information reported by a DLEP modem, causing a router to forward traffic to an inappropriate destination.
3. 攻击者可以加入不安全的无线网络，并通过空中注入信号，恶意影响DLEP调制解调器报告的信息，从而导致路由器将流量转发到不适当的目的地。
The implications of attacks on DLEP peers are directly proportional to the extent to which DLEP data is used within the control plane. While the use of DLEP data in other control-plane components is out of scope for this document, as an example, if DLEP statistics are incorporated into route cost calculations, adversaries masquerading as a DLEP peer and injecting malicious data via DLEP could cause suboptimal route selection, adversely impacting network performance. Similar issues can arise if DLEP data is used as an input to policing algorithms -- injection of malicious data via DLEP can cause those policing algorithms to make incorrect decisions, degrading network throughput.
攻击DLEP对等点的影响与控制平面内使用DLEP数据的程度成正比。虽然在其他控制平面组件中使用DLEP数据超出了本文件的范围，但例如，如果将DLEP统计数据纳入路由成本计算，则伪装为DLEP对等方并通过DLEP注入恶意数据的对手可能会导致次优路由选择，从而对网络性能产生不利影响。如果将DLEP数据用作监控算法的输入，也会出现类似的问题——通过DLEP注入恶意数据会导致监控算法做出错误决策，从而降低网络吞吐量。
For these reasons, security of the DLEP transport must be considered at both the transport layer and Layer 2.
由于这些原因，必须在传输层和第2层同时考虑DLEP传输的安全性。
At the transport layer, when TLS is in use, each peer SHOULD check the validity of credentials presented by the other peer during TLS session establishment. Implementations following the "dedicated deployments" model attempting to use TLS MAY (1) need to consider the use of pre-shared keys for credentials, (2) provide specialized techniques for peer identity validation, and (3) refer to [RFC5487] for additional details. Implementations following the "networked deployment" model described in "Implementation Scenarios" (Section 4) SHOULD refer to [RFC7525] for additional details.
在传输层，当使用TLS时，每个对等方应在TLS会话建立期间检查另一对等方提供的凭据的有效性。遵循“专用部署”模型尝试使用TLS的实现可以（1）考虑使用预共享密钥来进行凭证，（2）提供用于对等体身份验证的专门技术，和（3）参考[RCF587]以获得额外的细节。按照“实施方案”（第4节）中所述的“网络部署”模型实施，有关更多详细信息，请参阅[RFC7525]。
At Layer 2, since DLEP is restricted to operation over a single (possibly logical) hop, implementations SHOULD also secure the Layer 2 link. Examples of technologies that can be deployed to secure the Layer 2 link include [IEEE-802.1AE] and [IEEE-802.1X].
在第2层，由于DLEP仅限于在单个（可能是逻辑）跃点上进行操作，因此实现还应确保第2层链路的安全。可用于保护第2层链路的技术示例包括[IEEE-802.1AE]和[IEEE-802.1X]。
By examining the Secured Medium flag in the Peer Type Data Item (Section 13.4), a router can decide if it is able to trust the information supplied via a DLEP modem. If this is not the case, then the router SHOULD consider restricting the size of attached subnets, announced in IPv4 Attached Subnet Data Items (Section 13.10) and/or IPv6 Attached Subnet Data Items (Section 13.11), that are considered for route selection.
通过检查对等类型数据项中的安全介质标志（第13.4节），路由器可以决定是否能够信任通过DLEP调制解调器提供的信息。如果情况不是这样，那么路由器应该考虑限制在IPv4附加子网数据项（第13.10节）和/或IPv6附加子网数据项（第13.11节）中所宣布的附加子网的大小，这被认为是路由选择。
To avoid potential denial-of-service attacks, it is RECOMMENDED that implementations using the Peer Discovery mechanism (1) maintain an information base of hosts that persistently fail Session Initialization, even though those hosts have provided an acceptable Peer Discovery Signal and (2) ignore any subsequent Peer Discovery Signals from such hosts.
为了避免潜在的拒绝服务攻击，建议使用对等发现机制的实现（1）维护会话初始化持续失败的主机的信息库，即使这些主机提供了可接受的对等发现信号（2）忽略来自此类主机的任何后续对等发现信号。
This specification does not address security of the data plane, as it (the data plane) is not affected, and standard security procedures can be employed.
本规范不涉及数据平面的安全性，因为它（数据平面）不受影响，可以采用标准的安全程序。
IANA has created a new protocol registry for the Dynamic Link Exchange Protocol (DLEP). The remainder of this section details the new DLEP-specific registries.
IANA为动态链路交换协议（DLEP）创建了一个新的协议注册表。本节的其余部分详细介绍了新的特定于DLEP的注册表。
IANA has created a new DLEP registry, named "Signal Type Values".
IANA创建了一个新的DLEP注册表，名为“信号类型值”。
The following table provides initial registry values and the policies, as defined by [RFC5226], that apply to the registry:
下表提供了适用于注册表的初始注册表值和[RFC5226]定义的策略：
+--------------+--------------------------------------+
| Type Code | Description/Policy |
+--------------+--------------------------------------+
| 0 | Reserved |
| 1 | Peer Discovery Signal |
| 2 | Peer Offer Signal |
| 3-65519 | Unassigned / Specification Required |
| 65520-65534 | Reserved for Private Use |
| 65535 | Reserved |
+--------------+--------------------------------------+
+--------------+--------------------------------------+
| Type Code | Description/Policy |
+--------------+--------------------------------------+
| 0 | Reserved |
| 1 | Peer Discovery Signal |
| 2 | Peer Offer Signal |
| 3-65519 | Unassigned / Specification Required |
| 65520-65534 | Reserved for Private Use |
| 65535 | Reserved |
+--------------+--------------------------------------+
IANA has created a new DLEP registry, named "Message Type Values".
IANA创建了一个新的DLEP注册表，名为“消息类型值”。
The following table provides initial registry values and the policies, as defined by [RFC5226], that apply to the registry:
下表提供了适用于注册表的初始注册表值和[RFC5226]定义的策略：
+--------------+------------------------------------------+
| Type Code | Description/Policy |
+--------------+------------------------------------------+
| 0 | Reserved |
| | |
| 1 | Session Initialization Message |
| | |
| 2 | Session Initialization Response Message |
| | |
| 3 | Session Update Message |
| | |
| 4 | Session Update Response Message |
| | |
| 5 | Session Termination Message |
| | |
| 6 | Session Termination Response Message |
| | |
| 7 | Destination Up Message |
| | |
| 8 | Destination Up Response Message |
| | |
| 9 | Destination Announce Message |
| | |
| 10 | Destination Announce Response Message |
| | |
| 11 | Destination Down Message |
| | |
+--------------+------------------------------------------+
| Type Code | Description/Policy |
+--------------+------------------------------------------+
| 0 | Reserved |
| | |
| 1 | Session Initialization Message |
| | |
| 2 | Session Initialization Response Message |
| | |
| 3 | Session Update Message |
| | |
| 4 | Session Update Response Message |
| | |
| 5 | Session Termination Message |
| | |
| 6 | Session Termination Response Message |
| | |
| 7 | Destination Up Message |
| | |
| 8 | Destination Up Response Message |
| | |
| 9 | Destination Announce Message |
| | |
| 10 | Destination Announce Response Message |
| | |
| 11 | Destination Down Message |
| | |
| 12 | Destination Down Response Message |
| | |
| 13 | Destination Update Message |
| | |
| 14 | Link Characteristics Request Message |
| | |
| 15 | Link Characteristics Response Message |
| | |
| 16 | Heartbeat Message |
| | |
| 17-65519 | Unassigned / Specification Required |
| | |
| 65520-65534 | Reserved for Private Use |
| | |
| 65535 | Reserved |
+--------------+------------------------------------------+
| 12 | Destination Down Response Message |
| | |
| 13 | Destination Update Message |
| | |
| 14 | Link Characteristics Request Message |
| | |
| 15 | Link Characteristics Response Message |
| | |
| 16 | Heartbeat Message |
| | |
| 17-65519 | Unassigned / Specification Required |
| | |
| 65520-65534 | Reserved for Private Use |
| | |
| 65535 | Reserved |
+--------------+------------------------------------------+
IANA has created a new DLEP registry, named "Data Item Type Values".
IANA创建了一个新的DLEP注册表，名为“数据项类型值”。
The following table provides initial registry values and the policies, as defined by [RFC5226], that apply to the registry:
下表提供了适用于注册表的初始注册表值和[RFC5226]定义的策略：
+-------------------+------------------------------------------+
| Type Code | Description/Policy |
+-------------------+------------------------------------------+
| 0 | Reserved |
| | |
| 1 | Status |
| | |
| 2 | IPv4 Connection Point |
| | |
| 3 | IPv6 Connection Point |
| | |
| 4 | Peer Type |
| | |
| 5 | Heartbeat Interval |
| | |
| 6 | Extensions Supported |
| | |
| 7 | MAC Address |
| | |
| 8 | IPv4 Address |
| | |
| 9 | IPv6 Address |
| | |
| 10 | IPv4 Attached Subnet |
+-------------------+------------------------------------------+
| Type Code | Description/Policy |
+-------------------+------------------------------------------+
| 0 | Reserved |
| | |
| 1 | Status |
| | |
| 2 | IPv4 Connection Point |
| | |
| 3 | IPv6 Connection Point |
| | |
| 4 | Peer Type |
| | |
| 5 | Heartbeat Interval |
| | |
| 6 | Extensions Supported |
| | |
| 7 | MAC Address |
| | |
| 8 | IPv4 Address |
| | |
| 9 | IPv6 Address |
| | |
| 10 | IPv4 Attached Subnet |
| | |
| 11 | IPv6 Attached Subnet |
| | |
| 12 | Maximum Data Rate (Receive) (MDRR) |
| | |
| 13 | Maximum Data Rate (Transmit) (MDRT) |
| | |
| 14 | Current Data Rate (Receive) (CDRR) |
| | |
| 15 | Current Data Rate (Transmit) (CDRT) |
| | |
| 16 | Latency |
| | |
| 17 | Resources (RES) |
| | |
| 18 | Relative Link Quality (Receive) (RLQR) |
| | |
| 19 | Relative Link Quality (Transmit) (RLQT) |
| | |
| 20 | Maximum Transmission Unit (MTU) |
| | |
| 21-65407 | Unassigned / Specification Required |
| | |
| 65408-65534 | Reserved for Private Use |
| | |
| 65535 | Reserved |
+-------------------+------------------------------------------+
| | |
| 11 | IPv6 Attached Subnet |
| | |
| 12 | Maximum Data Rate (Receive) (MDRR) |
| | |
| 13 | Maximum Data Rate (Transmit) (MDRT) |
| | |
| 14 | Current Data Rate (Receive) (CDRR) |
| | |
| 15 | Current Data Rate (Transmit) (CDRT) |
| | |
| 16 | Latency |
| | |
| 17 | Resources (RES) |
| | |
| 18 | Relative Link Quality (Receive) (RLQR) |
| | |
| 19 | Relative Link Quality (Transmit) (RLQT) |
| | |
| 20 | Maximum Transmission Unit (MTU) |
| | |
| 21-65407 | Unassigned / Specification Required |
| | |
| 65408-65534 | Reserved for Private Use |
| | |
| 65535 | Reserved |
+-------------------+------------------------------------------+
IANA has created a new DLEP registry, named "Status Code Values".
IANA创建了一个新的DLEP注册表，名为“状态代码值”。
The following table provides initial registry values and the policies, as defined by [RFC5226], that apply to the registry:
下表提供了适用于注册表的初始注册表值和[RFC5226]定义的策略：
+--------------+---------------+------------------------------------+
| Status Code | Failure Mode | Description/Policy |
+--------------+---------------+------------------------------------+
| 0 | Continue | Success |
| | | |
| 1 | Continue | Not Interested |
| | | |
| 2 | Continue | Request Denied |
| | | |
| 3 | Continue | Inconsistent Data |
| | | |
| 4-111 | Continue | Unassigned / Specification |
| | | Required |
+--------------+---------------+------------------------------------+
| Status Code | Failure Mode | Description/Policy |
+--------------+---------------+------------------------------------+
| 0 | Continue | Success |
| | | |
| 1 | Continue | Not Interested |
| | | |
| 2 | Continue | Request Denied |
| | | |
| 3 | Continue | Inconsistent Data |
| | | |
| 4-111 | Continue | Unassigned / Specification |
| | | Required |
| | | |
| 112-127 | Continue | Private Use |
| | | |
| 128 | Terminate | Unknown Message |
| | | |
| 129 | Terminate | Unexpected Message |
| | | |
| 130 | Terminate | Invalid Data |
| | | |
| 131 | Terminate | Invalid Destination |
| | | |
| 132 | Terminate | Timed Out |
| | | |
| 133-239 | Terminate | Unassigned / Specification |
| | | Required |
| | | |
| 240-254 | Terminate | Reserved for Private Use |
| | | |
| 255 | Terminate | Shutting Down |
+--------------+---------------+------------------------------------+
| | | |
| 112-127 | Continue | Private Use |
| | | |
| 128 | Terminate | Unknown Message |
| | | |
| 129 | Terminate | Unexpected Message |
| | | |
| 130 | Terminate | Invalid Data |
| | | |
| 131 | Terminate | Invalid Destination |
| | | |
| 132 | Terminate | Timed Out |
| | | |
| 133-239 | Terminate | Unassigned / Specification |
| | | Required |
| | | |
| 240-254 | Terminate | Reserved for Private Use |
| | | |
| 255 | Terminate | Shutting Down |
+--------------+---------------+------------------------------------+
IANA has created a new DLEP registry, named "Extension Type Values".
IANA创建了一个新的DLEP注册表，名为“扩展类型值”。
The following table provides initial registry values and the policies, as defined by [RFC5226], that apply to the registry:
下表提供了适用于注册表的初始注册表值和[RFC5226]定义的策略：
+--------------+--------------------------------------+
| Code | Description/Policy |
+--------------+--------------------------------------+
| 0 | Reserved |
| 1-65519 | Unassigned / Specification Required |
| 65520-65534 | Reserved for Private Use |
| 65535 | Reserved |
+--------------+--------------------------------------+
+--------------+--------------------------------------+
| Code | Description/Policy |
+--------------+--------------------------------------+
| 0 | Reserved |
| 1-65519 | Unassigned / Specification Required |
| 65520-65534 | Reserved for Private Use |
| 65535 | Reserved |
+--------------+--------------------------------------+
Table 3: DLEP Extension Types
表3:DLEP扩展类型
IANA has created a new DLEP registry, named "IPv4 Connection Point Flags".
IANA创建了一个新的DLEP注册表，名为“IPv4连接点标志”。
The following table provides initial registry values and the policies, as defined by [RFC5226], that apply to the registry:
下表提供了适用于注册表的初始注册表值和[RFC5226]定义的策略：
+------------+--------------------------------------+
| Bit | Description/Policy |
+------------+--------------------------------------+
| 0-6 | Unassigned / Specification Required |
| 7 | Use TLS [RFC5246] indicator |
+------------+--------------------------------------+
+------------+--------------------------------------+
| Bit | Description/Policy |
+------------+--------------------------------------+
| 0-6 | Unassigned / Specification Required |
| 7 | Use TLS [RFC5246] indicator |
+------------+--------------------------------------+
IANA has created a new DLEP registry, named "IPv6 Connection Point Flags".
IANA创建了一个新的DLEP注册表，名为“IPv6连接点标志”。
The following table provides initial registry values and the policies, as defined by [RFC5226], that apply to the registry:
下表提供了适用于注册表的初始注册表值和[RFC5226]定义的策略：
+------------+--------------------------------------+
| Bit | Description/Policy |
+------------+--------------------------------------+
| 0-6 | Unassigned / Specification Required |
| 7 | Use TLS [RFC5246] indicator |
+------------+--------------------------------------+
+------------+--------------------------------------+
| Bit | Description/Policy |
+------------+--------------------------------------+
| 0-6 | Unassigned / Specification Required |
| 7 | Use TLS [RFC5246] indicator |
+------------+--------------------------------------+
IANA has created a new DLEP registry, named "Peer Type Flags".
IANA创建了一个新的DLEP注册表，名为“对等类型标志”。
The following table provides initial registry values and the policies, as defined by [RFC5226], that apply to the registry:
下表提供了适用于注册表的初始注册表值和[RFC5226]定义的策略：
+------------+--------------------------------------+
| Bit | Description/Policy |
+------------+--------------------------------------+
| 0-6 | Unassigned / Specification Required |
| 7 | Secured Medium indicator |
+------------+--------------------------------------+
+------------+--------------------------------------+
| Bit | Description/Policy |
+------------+--------------------------------------+
| 0-6 | Unassigned / Specification Required |
| 7 | Secured Medium indicator |
+------------+--------------------------------------+
IANA has created a new DLEP registry, named "IPv4 Address Flags".
IANA已经创建了一个新的DLEP注册表，名为“IPv4地址标志”。
The following table provides initial registry values and the policies, as defined by [RFC5226], that apply to the registry:
下表提供了适用于注册表的初始注册表值和[RFC5226]定义的策略：
+------------+--------------------------------------+
| Bit | Description/Policy |
+------------+--------------------------------------+
| 0-6 | Unassigned / Specification Required |
| 7 | Add/Drop indicator |
+------------+--------------------------------------+
+------------+--------------------------------------+
| Bit | Description/Policy |
+------------+--------------------------------------+
| 0-6 | Unassigned / Specification Required |
| 7 | Add/Drop indicator |
+------------+--------------------------------------+
IANA has created a new DLEP registry, named "IPv6 Address Flags".
IANA已经创建了一个新的DLEP注册表，名为“IPv6地址标志”。
The following table provides initial registry values and the policies, as defined by [RFC5226], that apply to the registry:
下表提供了适用于注册表的初始注册表值和[RFC5226]定义的策略：
+------------+--------------------------------------+
| Bit | Description/Policy |
+------------+--------------------------------------+
| 0-6 | Unassigned / Specification Required |
| 7 | Add/Drop indicator |
+------------+--------------------------------------+
+------------+--------------------------------------+
| Bit | Description/Policy |
+------------+--------------------------------------+
| 0-6 | Unassigned / Specification Required |
| 7 | Add/Drop indicator |
+------------+--------------------------------------+
IANA has created a new DLEP registry, named "IPv4 Attached Subnet Flags".
IANA已经创建了一个新的DLEP注册表，名为“IPv4附加子网标志”。
The following table provides initial registry values and the policies, as defined by [RFC5226], that apply to the registry:
下表提供了适用于注册表的初始注册表值和[RFC5226]定义的策略：
+------------+--------------------------------------+
| Bit | Description/Policy |
+------------+--------------------------------------+
| 0-6 | Unassigned / Specification Required |
| 7 | Add/Drop indicator |
+------------+--------------------------------------+
+------------+--------------------------------------+
| Bit | Description/Policy |
+------------+--------------------------------------+
| 0-6 | Unassigned / Specification Required |
| 7 | Add/Drop indicator |
+------------+--------------------------------------+
IANA has created a new DLEP registry, named "IPv6 Attached Subnet Flags".
IANA创建了一个新的DLEP注册表，名为“IPv6附加子网标志”。
The following table provides initial registry values and the policies, as defined by [RFC5226], that apply to the registry:
下表提供了适用于注册表的初始注册表值和[RFC5226]定义的策略：
+------------+--------------------------------------+
| Bit | Description/Policy |
+------------+--------------------------------------+
| 0-6 | Unassigned / Specification Required |
| 7 | Add/Drop indicator |
+------------+--------------------------------------+
+------------+--------------------------------------+
| Bit | Description/Policy |
+------------+--------------------------------------+
| 0-6 | Unassigned / Specification Required |
| 7 | Add/Drop indicator |
+------------+--------------------------------------+
IANA has assigned the value 854 in the "Service Name and Transport Protocol Port Number Registry" found at <http://www.iana.org/assignments/service-names-port-numbers/> for use by "DLEP", as defined in this document. This assignment is valid for TCP and UDP.
IANA已在位于的“服务名称和传输协议端口号注册表”中分配了854值<http://www.iana.org/assignments/service-names-port-numbers/>供本文件中定义的“DLEP”使用。此分配对TCP和UDP有效。
IANA has assigned the IPv4 multicast address 224.0.0.117 in the registry found at <http://www.iana.org/assignments/multicast-addresses> for use as "DLEP Discovery".
IANA已在位于的注册表中分配IPv4多播地址224.0.0.117<http://www.iana.org/assignments/multicast-addresses>用作“DLEP发现”。
IANA has assigned the IPv6 multicast address FF02:0:0:0:0:0:1:7 in the registry found at <http://www.iana.org/assignments/ipv6-multicast-addresses> for use as "DLEP Discovery".
IANA已在位于的注册表中分配IPv6多播地址FF02:0:0:0:0:1:7<http://www.iana.org/assignments/ipv6-multicast-addresses>用作“DLEP发现”。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，DOI 10.17487/RFC3629，2003年11月<http://www.rfc-editor.org/info/rfc3629>.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, <http://www.rfc-editor.org/info/rfc5082>.
[RFC5082]Gill，V.，Heasley，J.，Meyer，D.，Savola，P.，Ed.，和C.Pignataro，“广义TTL安全机制（GTSM）”，RFC 5082，DOI 10.17487/RFC5082，2007年10月<http://www.rfc-editor.org/info/rfc5082>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<http://www.rfc-editor.org/info/rfc8174>.
[IEEE-802.1AE] "IEEE Standards for Local and Metropolitan Area Networks: Media Access Control (MAC) Security", DOI 10.1109/IEEESTD.2006.245590, <http://ieeexplore.ieee.org/document/1678345/>.
[IEEE-802.1AE]“局域网和城域网的IEEE标准：媒体访问控制（MAC）安全”，DOI 10.1109/IEEESTD.2006.245590<http://ieeexplore.ieee.org/document/1678345/>.
[IEEE-802.1X] "IEEE Standards for Local and metropolitan area networks-- Port-Based Network Access Control", DOI 10.1109/IEEESTD.2010.5409813, <http://ieeexplore.ieee.org/document/5409813/>.
[IEEE-802.1X]“局域网和城域网的IEEE标准——基于端口的网络访问控制”，DOI 10.1109/IEEESTD.2010.5409813<http://ieeexplore.ieee.org/document/5409813/>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC5487] Badra, M., "Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode", RFC 5487, DOI 10.17487/RFC5487, March 2009, <http://www.rfc-editor.org/info/rfc5487>.
[RFC5487]Badra，M.，“具有SHA-256/384和AES伽罗瓦计数器模式的TLS预共享密钥密码套件”，RFC 5487，DOI 10.17487/RFC5487，2009年3月<http://www.rfc-editor.org/info/rfc5487>.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013, <http://www.rfc-editor.org/info/rfc6890>.
[RFC6890]Cotton，M.，Vegoda，L.，Bonica，R.，Ed.，和B.Haberman，“特殊用途IP地址注册”，BCP 153，RFC 6890，DOI 10.17487/RFC6890，2013年4月<http://www.rfc-editor.org/info/rfc6890>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015年5月<http://www.rfc-editor.org/info/rfc7525>.
Router Modem Signal Description
========================================================================
Router Modem Signal Description
========================================================================
| Router initiates discovery,
| starts a timer, sends Peer
|-------Peer Discovery---->X Discovery Signal.
| Router initiates discovery,
| starts a timer, sends Peer
|-------Peer Discovery---->X Discovery Signal.
~ ~ ~ ~ ~ ~ ~ Router discovery timer expires without receiving Peer Offer.
~~~~~~~路由器发现计时器在未收到对等方提供的情况下过期。
| Router sends another Peer
|-------Peer Discovery---------->| Discovery Signal.
|
| Modem receives Peer Discovery
| Signal.
|
| Modem sends Peer Offer with
|<--------Peer Offer-------------| Connection Point information.
:
: Router MAY cancel discovery timer
: and stop sending Peer Discovery
: Signals.
| Router sends another Peer
|-------Peer Discovery---------->| Discovery Signal.
|
| Modem receives Peer Discovery
| Signal.
|
| Modem sends Peer Offer with
|<--------Peer Offer-------------| Connection Point information.
:
: Router MAY cancel discovery timer
: and stop sending Peer Discovery
: Signals.
Router Modem Message Description
========================================================================
Router Modem Message Description
========================================================================
| Router connects to discovered or
| preconfigured Modem Connection
|--TCP connection established---> Point.
|
| Router sends Session
|----Session Initialization----->| Initialization Message.
|
| Modem receives Session
| Initialization Message.
|
| Modem sends Session Initialization
|<--Session Initialization Resp.-| Response with 'Success' Status
| | Data Item.
| |
|<<============================>>| Session established.
: : Heartbeats begin.
| Router connects to discovered or
| preconfigured Modem Connection
|--TCP connection established---> Point.
|
| Router sends Session
|----Session Initialization----->| Initialization Message.
|
| Modem receives Session
| Initialization Message.
|
| Modem sends Session Initialization
|<--Session Initialization Resp.-| Response with 'Success' Status
| | Data Item.
| |
|<<============================>>| Session established.
: : Heartbeats begin.
Router Modem Message Description
========================================================================
Router Modem Message Description
========================================================================
| Router connects to discovered or
| preconfigured Modem Connection
|--TCP connection established---> Point.
|
| Router sends Session
|-----Session Initialization---->| Initialization Message.
|
| Modem receives Session
| Initialization Message and
| will not support the advertised
| extensions.
|
| Modem sends Session Initialization
| Response with 'Request Denied'
|<-Session Initialization Resp.--| Status Data Item.
|
|
| Router receives negative Session
| Initialization Response, closes
||---------TCP close------------|| TCP connection.
| Router connects to discovered or
| preconfigured Modem Connection
|--TCP connection established---> Point.
|
| Router sends Session
|-----Session Initialization---->| Initialization Message.
|
| Modem receives Session
| Initialization Message and
| will not support the advertised
| extensions.
|
| Modem sends Session Initialization
| Response with 'Request Denied'
|<-Session Initialization Resp.--| Status Data Item.
|
|
| Router receives negative Session
| Initialization Response, closes
||---------TCP close------------|| TCP connection.
Router Modem Message Description
========================================================================
Router Modem Message Description
========================================================================
| Router sends Session Update
|-------Session Update---------->| Message to announce change of
| IP address.
|
| Modem receives Session Update
| Message and updates internal
| state.
|
|<----Session Update Response----| Modem sends Session Update
| Response.
| Router sends Session Update
|-------Session Update---------->| Message to announce change of
| IP address.
|
| Modem receives Session Update
| Message and updates internal
| state.
|
|<----Session Update Response----| Modem sends Session Update
| Response.
Router Modem Message Description
========================================================================
Router Modem Message Description
========================================================================
| Modem sends Session Update Message
| to announce change of session-wide
|<--------Session Update---------| metrics.
|
| Router receives Session Update
| Message and updates internal
| state.
|
|----Session Update Response---->| Router sends Session Update
| Response.
| Modem sends Session Update Message
| to announce change of session-wide
|<--------Session Update---------| metrics.
|
| Router receives Session Update
| Message and updates internal
| state.
|
|----Session Update Response---->| Router sends Session Update
| Response.
Router Modem Message Description
========================================================================
Router Modem Message Description
========================================================================
| Router sends Session Termination
|------Session Termination------>| Message with Status Data Item.
| |
|-------TCP shutdown (send)---> | Router stops sending Messages.
|
| Modem receives Session
| Termination, stops counting
| received heartbeats, and stops
| sending heartbeats.
|
| Modem sends Session Termination
|<---Session Termination Resp.---| Response with Status 'Success'.
|
| Modem stops sending Messages.
|
||---------TCP close------------|| Session terminated.
| Router sends Session Termination
|------Session Termination------>| Message with Status Data Item.
| |
|-------TCP shutdown (send)---> | Router stops sending Messages.
|
| Modem receives Session
| Termination, stops counting
| received heartbeats, and stops
| sending heartbeats.
|
| Modem sends Session Termination
|<---Session Termination Resp.---| Response with Status 'Success'.
|
| Modem stops sending Messages.
|
||---------TCP close------------|| Session terminated.
Router Modem Message Description
========================================================================
Router Modem Message Description
========================================================================
| Modem sends Session Termination
|<----Session Termination--------| Message with Status Data Item.
|
| Modem stops sending Messages.
|
| Router receives Session
| Termination, stops counting
| received heartbeats, and stops
| sending heartbeats.
|
| Router sends Session Termination
|---Session Termination Resp.--->| Response with Status 'Success'.
|
| Router stops sending Messages.
|
||---------TCP close------------|| Session terminated.
| Modem sends Session Termination
|<----Session Termination--------| Message with Status Data Item.
|
| Modem stops sending Messages.
|
| Router receives Session
| Termination, stops counting
| received heartbeats, and stops
| sending heartbeats.
|
| Router sends Session Termination
|---Session Termination Resp.--->| Response with Status 'Success'.
|
| Router stops sending Messages.
|
||---------TCP close------------|| Session terminated.
Router Modem Message Description
========================================================================
Router Modem Message Description
========================================================================
|----------Heartbeat------------>| Router sends Heartbeat Message.
|
| Modem resets heartbeats missed
| counter.
|----------Heartbeat------------>| Router sends Heartbeat Message.
|
| Modem resets heartbeats missed
| counter.
~ ~ ~ ~ ~ ~ ~
~ ~ ~ ~ ~ ~ ~
|---------[Any Message]--------->| When the Modem receives any
| Message from the Router.
|
| Modem resets heartbeats missed
| counter.
|---------[Any Message]--------->| When the Modem receives any
| Message from the Router.
|
| Modem resets heartbeats missed
| counter.
~ ~ ~ ~ ~ ~ ~
~ ~ ~ ~ ~ ~ ~
|<---------Heartbeat-------------| Modem sends Heartbeat Message.
|
| Router resets heartbeats missed
| counter.
|<---------Heartbeat-------------| Modem sends Heartbeat Message.
|
| Router resets heartbeats missed
| counter.
~ ~ ~ ~ ~ ~ ~
~ ~ ~ ~ ~ ~ ~
|<--------[Any Message]----------| When the Router receives any
| Message from the Modem.
|
| Modem resets heartbeats missed
| counter.
|<--------[Any Message]----------| When the Router receives any
| Message from the Modem.
|
| Modem resets heartbeats missed
| counter.
Router Modem Message Description
========================================================================
Router Modem Message Description
========================================================================
X<----------------------| Router misses a heartbeat.
X<----------------------| Router misses a heartbeat.
| X<----------------------| Router misses too many
| heartbeats.
|
|
|------Session Termination------>| Router sends Session Termination
| Message with 'Timeout' Status
| Data Item.
:
: Termination proceeds...
| X<----------------------| Router misses too many
| heartbeats.
|
|
|------Session Termination------>| Router sends Session Termination
| Message with 'Timeout' Status
| Data Item.
:
: Termination proceeds...
Router Modem Message Description
========================================================================
Router Modem Message Description
========================================================================
|---------------------->X Modem misses a heartbeat.
|---------------------->X Modem misses a heartbeat.
|---------------------->X | Modem misses too many
| heartbeats.
|
|
|<-----Session Termination-------| Modem sends Session Termination
| Message with 'Timeout' Status
| Data Item.
:
: Termination proceeds...
|---------------------->X | Modem misses too many
| heartbeats.
|
|
|<-----Session Termination-------| Modem sends Session Termination
| Message with 'Timeout' Status
| Data Item.
:
: Termination proceeds...
Router Modem Message Description
========================================================================
Router Modem Message Description
========================================================================
| Modem detects a new logical
| destination is reachable and
|<-------Destination Up----------| sends Destination Up Message.
|
|------Destination Up Resp.----->| Router sends Destination Up
| Response.
| Modem detects a new logical
| destination is reachable and
|<-------Destination Up----------| sends Destination Up Message.
|
|------Destination Up Resp.----->| Router sends Destination Up
| Response.
~ ~ ~ ~ ~ ~ ~
| Modem detects change in logical
| destination metrics and sends
|<-------Destination Update------| Destination Update Message.
~ ~ ~ ~ ~ ~ ~
| Modem detects change in logical
| destination metrics and sends
|<-------Destination Update------| Destination Update Message.
~ ~ ~ ~ ~ ~ ~
| Modem detects change in logical
| destination metrics and sends
|<-------Destination Update------| Destination Update Message.
~ ~ ~ ~ ~ ~ ~
| Modem detects change in logical
| destination metrics and sends
|<-------Destination Update------| Destination Update Message.
~ ~ ~ ~ ~ ~ ~
| Modem detects logical destination
| is no longer reachable and sends
|<-------Destination Down--------| Destination Down Message.
|
| Router receives Destination Down,
| updates internal state, and sends
|------Destination Down Resp.--->| Destination Down Response Message.
~ ~ ~ ~ ~ ~ ~
| Modem detects logical destination
| is no longer reachable and sends
|<-------Destination Down--------| Destination Down Message.
|
| Router receives Destination Down,
| updates internal state, and sends
|------Destination Down Resp.--->| Destination Down Response Message.
Router Modem Message Description
========================================================================
Router Modem Message Description
========================================================================
| Router detects a new multicast
| destination is in use and sends
|-----Destination Announce------>| Destination Announce Message.
|
| Modem updates internal state to
| monitor multicast destination and
|<-----Dest. Announce Resp.------| sends Destination Announce
Response.
| Router detects a new multicast
| destination is in use and sends
|-----Destination Announce------>| Destination Announce Message.
|
| Modem updates internal state to
| monitor multicast destination and
|<-----Dest. Announce Resp.------| sends Destination Announce
Response.
~ ~ ~ ~ ~ ~ ~
| Modem detects change in multicast
| destination metrics and sends
|<-------Destination Update------| Destination Update Message.
~ ~ ~ ~ ~ ~ ~
| Modem detects change in multicast
| destination metrics and sends
|<-------Destination Update------| Destination Update Message.
~ ~ ~ ~ ~ ~ ~
| Modem detects change in multicast
| destination metrics and sends
|<-------Destination Update------| Destination Update Message.
~ ~ ~ ~ ~ ~ ~
| Modem detects change in multicast
| destination metrics and sends
|<-------Destination Update------| Destination Update Message.
~ ~ ~ ~ ~ ~ ~
| Router detects multicast
| destination is no longer in use
|--------Destination Down------->| and sends Destination Down
| Message.
|
| Modem receives Destination Down,
| updates internal state, and sends
|<-----Destination Down Resp.----| Destination Down Response Message.
~ ~ ~ ~ ~ ~ ~
| Router detects multicast
| destination is no longer in use
|--------Destination Down------->| and sends Destination Down
| Message.
|
| Modem receives Destination Down,
| updates internal state, and sends
|<-----Destination Down Resp.----| Destination Down Response Message.
Router Modem Message Description
========================================================================
Router Modem Message Description
========================================================================
Destination has already been ~ ~ ~ ~ ~ ~ ~ announced by either peer.
目标已由任一对等方宣布。
| Router requires different
| characteristics for the
| destination and sends Link
|--Link Characteristics Request->| Characteristics Request Message.
|
| Modem attempts to adjust link
| properties to meet the received
| request and sends a Link
| Characteristics Response
|<---Link Characteristics Resp.--| Message with the new values.
| Router requires different
| characteristics for the
| destination and sends Link
|--Link Characteristics Request->| Characteristics Request Message.
|
| Modem attempts to adjust link
| properties to meet the received
| request and sends a Link
| Characteristics Response
|<---Link Characteristics Resp.--| Message with the new values.
Acknowledgments
致谢
We would like to acknowledge and thank the members of the DLEP design team, who have provided invaluable insight. The members of the design team are Teco Boot, Bow-Nan Cheng, John Dowdell, and Henning Rogge.
我们要感谢DLEP设计团队的成员，他们提供了宝贵的见解。设计团队的成员包括Teco Boot、Bow Nan Cheng、John Dowdell和Henning Rogge。
We would also like to acknowledge the influence and contributions of Greg Harrison, Chris Olsen, Martin Duke, Subir Das, Jaewon Kang, Vikram Kaul, Nelson Powell, Lou Berger, and Victoria Pritchard.
我们还要感谢格雷格·哈里森、克里斯·奥尔森、马丁·杜克、苏比尔·达斯、杰文·康、维克拉姆·考尔、纳尔逊·鲍威尔、卢·伯杰和维多利亚·普里查德的影响和贡献。
Authors' Addresses
作者地址
Stan Ratliff VT iDirect 13861 Sunrise Valley Drive, Suite 300 Herndon, VA 20171 United States of America Email: sratliff@idirect.net
Stan Ratliff VT iDirect 13861日出谷大道，弗吉尼亚州赫恩登300号套房20171美国电子邮件：sratliff@idirect.net
Shawn Jury Cisco Systems 170 West Tasman Drive San Jose, CA 95134 United States of America Email: sjury@cisco.com
Shawn Jury Cisco Systems 170西塔斯曼大道圣何塞，加利福尼亚州95134美利坚合众国电子邮件：sjury@cisco.com
Darryl Satterwhite Broadcom Email: dsatterw@broadcom.com
Darryl Satterwhite Broadcom电子邮件：dsatterw@broadcom.com
Rick Taylor Airbus Defence & Space Quadrant House Celtic Springs Coedkernew Newport NP10 8FZ United Kingdom Email: rick.taylor@airbus.com
里克·泰勒空中客车防务与空间象限之家凯尔特斯普林斯科德克内W纽波特NP10 8FZ英国电子邮件：里克。taylor@airbus.com
Bo Berry
博贝里