< draft-ietf-manet-dlep-07.txt   draft-ietf-manet-dlep-08.txt >
Mobile Ad hoc Networks Working S. Ratliff Mobile Ad hoc Networks Working Group S. Ratliff
Group Independent Consultant Internet-Draft VT iDirect
Internet-Draft B. Berry Intended status: Standards Track B. Berry
Intended status: Standards Track G. Harrison Expires: August 31, 2015
Expires: April 2, 2015 S. Jury S. Jury
Cisco Systems Cisco Systems
D. Satterwhite D. Satterwhite
Broadcom Broadcom
October 24, 2014 R. Taylor
Airbus Defence & Space
February 27, 2015
Dynamic Link Exchange Protocol (DLEP) Dynamic Link Exchange Protocol (DLEP)
draft-ietf-manet-dlep-07 draft-ietf-manet-dlep-08
Abstract Abstract
When routing devices rely on modems to effect communications over When routing devices rely on modems to effect communications over
wireless links, they need timely and accurate knowledge of the wireless links, they need timely and accurate knowledge of the
characteristics of the link (speed, state, etc.) in order to make characteristics of the link (speed, state, etc.) in order to make
forwarding decisions. In mobile or other environments where these forwarding decisions. In mobile or other environments where these
characteristics change frequently, manual configurations or the characteristics change frequently, manual configurations or the
inference of state through routing or transport protocols does not inference of state through routing or transport protocols does not
allow the router to make the best decisions. A bidirectional, event- allow the router to make the best decisions. A bidirectional, event-
driven communication channel between the router and the modem is driven communication channel between the router and the modem is
necessary. necessary.
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on August 31, 2015.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 14, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 8 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 8
2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Mandatory Versus Optional Items . . . . . . . . . . . . . . . . 9 3. Core Features and Optional Extensions . . . . . . . . . . . . 10
4. Credits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. Negotiation of Optional Extensions . . . . . . . . . . . 10
5. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Protocol Extensions . . . . . . . . . . . . . . . . . . . 10
6. Extensions to DLEP . . . . . . . . . . . . . . . . . . . . . . 11 3.3. Experimental Signals and Data Items . . . . . . . . . . . 11
6.1 Protocol Extensions . . . . . . . . . . . . . . . . . . . . 11 4. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2 Vendor Extensions . . . . . . . . . . . . . . . . . . . . . 11 4.1. Mandatory Metrics . . . . . . . . . . . . . . . . . . . . 12
6.3 Experimental Extensions . . . . . . . . . . . . . . . . . . 11 5. Normal Session Flow . . . . . . . . . . . . . . . . . . . . . 12
7. Normal Session Flow . . . . . . . . . . . . . . . . . . . . . 12 5.1. DLEP Router session flow - Discovery case . . . . . . . . 13
7.1 DLEP Router session flow - Discovery case . . . . . . . . . 12 5.2. DLEP Router session flow - Configured case . . . . . . . 13
7.2 DLEP Router session flow - Configured case . . . . . . . . . 12 5.3. DLEP Modem session flow . . . . . . . . . . . . . . . . . 14
7.3 DLEP Modem session flow . . . . . . . . . . . . . . . . . . 13 5.4. Common Session Flow . . . . . . . . . . . . . . . . . . . 14
7.4 Common Session Flow . . . . . . . . . . . . . . . . . . . . 14 6. DLEP Message Processing . . . . . . . . . . . . . . . . . . . 15
8. Mandatory Signals and Data Items . . . . . . . . . . . . . . . 14 6.1. DLEP Signal Header . . . . . . . . . . . . . . . . . . . 16
9. Generic DLEP Signal Definition . . . . . . . . . . . . . . . . 16 6.2. DLEP Generic Data Item . . . . . . . . . . . . . . . . . 16
10. DLEP Data Items . . . . . . . . . . . . . . . . . . . . . . . 16 7. DLEP Signals . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1 DLEP Version . . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Peer Discovery Signal . . . . . . . . . . . . . . . . . . 17
10.2 DLEP Port . . . . . . . . . . . . . . . . . . . . . . . . 18 7.2. Peer Offer Signal . . . . . . . . . . . . . . . . . . . . 18
10.3 Peer Type . . . . . . . . . . . . . . . . . . . . . . . . 18 7.3. Peer Initialization Signal . . . . . . . . . . . . . . . 19
10.4 MAC Address . . . . . . . . . . . . . . . . . . . . . . . 19 7.4. Peer Initialization ACK Signal . . . . . . . . . . . . . 20
10.5 IPv4 Address . . . . . . . . . . . . . . . . . . . . . . . 19 7.5. Peer Update Signal . . . . . . . . . . . . . . . . . . . 21
10.6 IPv6 Address . . . . . . . . . . . . . . . . . . . . . . . 20 7.6. Peer Update ACK Signal . . . . . . . . . . . . . . . . . 22
10.7 Maximum Data Rate (Receive) . . . . . . . . . . . . . . . 21 7.7. Peer Termination Signal . . . . . . . . . . . . . . . . . 23
10.8 Maximum Data Rate (Transmit) . . . . . . . . . . . . . . . 22 7.8. Peer Termination ACK Signal . . . . . . . . . . . . . . . 23
10.9 Current Data Rate (Receive) . . . . . . . . . . . . . . . 22 7.9. Destination Up Signal . . . . . . . . . . . . . . . . . . 24
10.10 Current Data Rate (Transmit) . . . . . . . . . . . . . . 23 7.10. Destination Up ACK Signal . . . . . . . . . . . . . . . . 25
10.11 Latency . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.11. Destination Down Signal . . . . . . . . . . . . . . . . . 26
10.12 Resources (Receive) . . . . . . . . . . . . . . . . . . . 25 7.12. Destination Down ACK Signal . . . . . . . . . . . . . . . 26
10.13 Resources (Transmit) . . . . . . . . . . . . . . . . . . 25 7.13. Destination Update Signal . . . . . . . . . . . . . . . . 26
10.14 Relative Link Quality (Receive) . . . . . . . . . . . . . 26 7.14. Heartbeat Signal . . . . . . . . . . . . . . . . . . . . 28
10.15 Relative Link Quality (Transmit) . . . . . . . . . . . . 27 7.15. Link Characteristics Request Signal . . . . . . . . . . . 28
10.16 Status . . . . . . . . . . . . . . . . . . . . . . . . . 27 7.16. Link Characteristics ACK Signal . . . . . . . . . . . . . 29
10.17 Heartbeat Interval . . . . . . . . . . . . . . . . . . . 28 8. DLEP Data Items . . . . . . . . . . . . . . . . . . . . . . . 30
10.18 Link Characteristics ACK Timer . . . . . . . . . . . . . 28 8.1. DLEP Version . . . . . . . . . . . . . . . . . . . . . . 31
10.19 Credit Window Status . . . . . . . . . . . . . . . . . . 29 8.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.20 Credit Grant Request . . . . . . . . . . . . . . . . . . 30 8.3. DLEP Port . . . . . . . . . . . . . . . . . . . . . . . . 33
10.21 Credit Request . . . . . . . . . . . . . . . . . . . . . 31 8.4. Peer Type . . . . . . . . . . . . . . . . . . . . . . . . 33
10.22 DLEP Optional Signals Supported . . . . . . . . . . . . . 31 8.5. Heartbeat Interval . . . . . . . . . . . . . . . . . . . 34
10.23 DLEP Optional Data Items Supported . . . . . . . . . . . 32 8.6. Extensions Supported . . . . . . . . . . . . . . . . . . 35
10.24 DLEP Vendor Extension . . . . . . . . . . . . . . . . . . 33 8.7. Experimental Definition . . . . . . . . . . . . . . . . . 35
10.25 IPv4 Attached Subnet . . . . . . . . . . . . . . . . . . 33 8.8. MAC Address . . . . . . . . . . . . . . . . . . . . . . . 36
10.26 IPv6 Attached Subnet . . . . . . . . . . . . . . . . . . 34 8.9. IPv4 Address . . . . . . . . . . . . . . . . . . . . . . 37
11. DLEP Protocol Signals . . . . . . . . . . . . . . . . . . . . 35 8.10. IPv6 Address . . . . . . . . . . . . . . . . . . . . . . 37
11.1 Signal TLV Values . . . . . . . . . . . . . . . . . . . . 35 8.11. IPv4 Attached Subnet . . . . . . . . . . . . . . . . . . 38
11.2 Peer Discovery Signal . . . . . . . . . . . . . . . . . . . 36 8.12. IPv6 Attached Subnet . . . . . . . . . . . . . . . . . . 39
11.3 Peer Offer Signal . . . . . . . . . . . . . . . . . . . . . 36 8.13. Maximum Data Rate (Receive) . . . . . . . . . . . . . . . 39
11.4 Peer Initialization Signal . . . . . . . . . . . . . . . . 37 8.14. Maximum Data Rate (Transmit) . . . . . . . . . . . . . . 40
11.5 Peer Initialization ACK Signal . . . . . . . . . . . . . . 37 8.15. Current Data Rate (Receive) . . . . . . . . . . . . . . . 41
11.6 Peer Update Signal . . . . . . . . . . . . . . . . . . . . 38 8.16. Current Data Rate (Transmit) . . . . . . . . . . . . . . 41
11.7 Peer Update ACK Signal . . . . . . . . . . . . . . . . . . 39 8.17. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 42
11.8 Peer Termination Signal . . . . . . . . . . . . . . . . . . 40 8.18. Resources (Receive) . . . . . . . . . . . . . . . . . . . 43
11.9 Peer Termination ACK Signal . . . . . . . . . . . . . . . . 40 8.19. Resources (Transmit) . . . . . . . . . . . . . . . . . . 43
11.10 Destination Up Signal . . . . . . . . . . . . . . . . . . 40 8.20. Relative Link Quality (Receive) . . . . . . . . . . . . . 44
11.11 Destination Up ACK Signal . . . . . . . . . . . . . . . . 41 8.21. Relative Link Quality (Transmit) . . . . . . . . . . . . 45
11.12 Destination Down Signal . . . . . . . . . . . . . . . . . 41 8.22. Link Characteristics ACK Timer . . . . . . . . . . . . . 45
11.13 Destination Down ACK Signal . . . . . . . . . . . . . . . 42 9. Credit-Windowing . . . . . . . . . . . . . . . . . . . . . . 46
11.14 Destination Update Signal . . . . . . . . . . . . . . . . 42 9.1. Credit-Windowing Signals . . . . . . . . . . . . . . . . 46
11.15 Heartbeat Signal . . . . . . . . . . . . . . . . . . . . . 43 9.1.1. Destination Up Signal . . . . . . . . . . . . . . . . 46
11.16 Link Characteristics Request Signal . . . . . . . . . . . 43 9.1.2. Destination Up ACK Signal . . . . . . . . . . . . . . 47
11.17 Link Characteristics ACK Signal . . . . . . . . . . . . . 44 9.1.3. Destination Update Signal . . . . . . . . . . . . . . 47
12. Security Considerations . . . . . . . . . . . . . . . . . . . 45 9.2. Credit-Windowing Data Items . . . . . . . . . . . . . . . 47
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 9.2.1. Credit Window Status . . . . . . . . . . . . . . . . 47
13.1 Registrations . . . . . . . . . . . . . . . . . . . . . . 45 9.2.2. Credit Grant . . . . . . . . . . . . . . . . . . . . 48
13.2 Expert Review: Evaluation Guidelines . . . . . . . . . . . 45 9.2.3. Credit Request . . . . . . . . . . . . . . . . . . . 49
13.3 Signal TLV Type Registration . . . . . . . . . . . . . . . 45 10. Security Considerations . . . . . . . . . . . . . . . . . . . 50
13.4 DLEP Data Item Registrations . . . . . . . . . . . . . . . 46 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
13.5 DLEP Well-known Port . . . . . . . . . . . . . . . . . . . 47 11.1. Registrations . . . . . . . . . . . . . . . . . . . . . 50
13.6 DLEP Multicast Address . . . . . . . . . . . . . . . . . . 47 11.2. Expert Review: Evaluation Guidelines . . . . . . . . . . 51
14. Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . 47 11.3. Signal Type Registration . . . . . . . . . . . . . . . . 51
14.1 Peer Level Signal Flows . . . . . . . . . . . . . . . . . 47 11.4. DLEP Data Item Registrations . . . . . . . . . . . . . . 52
14.1.1 Router Device Restarts Discovery . . . . . . . . . . . 47 11.5. DLEP Status Code Registrations . . . . . . . . . . . . . 53
14.1.2 Router Device Detects Peer Offer Timeout . . . . . . . 48 11.6. DLEP Extensions Registrations . . . . . . . . . . . . . 53
14.1.3 Router Peer Offer Lost . . . . . . . . . . . . . . . . 49 11.7. DLEP Well-known Port . . . . . . . . . . . . . . . . . . 54
14.1.4 Discovery Success . . . . . . . . . . . . . . . . . . 49 11.8. DLEP Multicast Address . . . . . . . . . . . . . . . . . 54
14.1.5 Router Detects a Heartbeat timeout . . . . . . . . . . 50 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54
14.1.6 Modem Detects a Heartbeat timeout . . . . . . . . . . 50 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 54
14.1.7 Peer Terminate (from Modem) Lost . . . . . . . . . . . 51 13.1. Normative References . . . . . . . . . . . . . . . . . . 54
14.1.8 Peer Terminate (from Router) Lost . . . . . . . . . . 51 13.2. Informative References . . . . . . . . . . . . . . . . . 54
14.2 Destination Specific Signal Flows . . . . . . . . . . . . 51 Appendix A. Peer Level Signal Flows . . . . . . . . . . . . . . 54
14.2.1 Modem Destination Up Lost . . . . . . . . . . . . . . 52 A.1. Router Device Restarts Discovery . . . . . . . . . . . . 54
14.2.2 Router Detects Duplicate Destination Ups . . . . . . . 52 A.2. Router Device Detects Peer Offer Timeout . . . . . . . . 55
14.2.3 Destination Up, No Layer 3 Addresses . . . . . . . . . 53 A.3. Router Peer Offer Lost . . . . . . . . . . . . . . . . . 55
14.2.4 Destination Up with IPv4, No IPv6 . . . . . . . . . . 53 A.4. Discovery Success . . . . . . . . . . . . . . . . . . . . 56
14.2.5 Destination Up with IPv4 and IPv6 . . . . . . . . . . 53 A.5. Router Detects a Heartbeat timeout . . . . . . . . . . . 57
14.2.6 Destination Session Success . . . . . . . . . . . . . 54 A.6. Modem Detects a Heartbeat timeout . . . . . . . . . . . . 57
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 54 A.7. Peer Terminate (from Modem) Lost . . . . . . . . . . . . 58
Normative References . . . . . . . . . . . . . . . . . . . . . . . 55 A.8. Peer Terminate (from Router) Lost . . . . . . . . . . . . 58
Informative References . . . . . . . . . . . . . . . . . . . . . . 55 Appendix B. Destination Specific Signal Flows . . . . . . . . . 59
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 B.1. Modem Destination Up Lost . . . . . . . . . . . . . . . . 59
B.2. Router Detects Duplicate Destination Ups . . . . . . . . 59
B.3. Destination Up, No Layer 3 Addresses . . . . . . . . . . 60
B.4. Destination Up with IPv4, No IPv6 . . . . . . . . . . . . 60
B.5. Destination Up with IPv4 and IPv6 . . . . . . . . . . . . 61
B.6. Destination Session Success . . . . . . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62
1. Introduction 1. Introduction
There exist today a collection of modem devices that control links of There exist today a collection of modem devices that control links of
variable datarate and quality. Examples of these types of links variable datarate and quality. Examples of these types of links
include line-of-sight (LOS) terrestrial radios, satellite terminals, include line-of-sight (LOS) terrestrial radios, satellite terminals,
and cable/DSL modems. Fluctuations in speed and quality of these and cable/DSL modems. Fluctuations in speed and quality of these
links can occur due to configuration (in the case of cable/DSL links can occur due to configuration (in the case of cable/DSL
modems), or on a moment-to-moment basis, due to physical phenomena modems), or on a moment-to-moment basis, due to physical phenomena
like multipath interference, obstructions, rain fade, etc. It is also like multipath interference, obstructions, rain fade, etc. It is
quite possible that link quality and datarate varies with respect to also quite possible that link quality and datarate varies with
individual destinations on a link, and with the type of traffic being respect to individual destinations on a link, and with the type of
sent. As an example, consider the case of an 802.11g access point, traffic being sent. As an example, consider the case of an 802.11g
serving 2 associated laptop computers. In this environment, the access point, serving 2 associated laptop computers. In this
answer to the question "What is the datarate on the 802.11g link?" is environment, the answer to the question "What is the datarate on the
"It depends on which associated laptop we're talking about, and on 802.11g link?" is "It depends on which associated laptop we're
what kind of traffic is being sent." While the first laptop, being talking about, and on what kind of traffic is being sent." While the
physically close to the access point, may have a datarate of 54Mbps first laptop, being physically close to the access point, may have a
for unicast traffic, the other laptop, being relatively far away, or datarate of 54Mbps for unicast traffic, the other laptop, being
obstructed by some object, can simultaneously have a datarate of only relatively far away, or obstructed by some object, can simultaneously
32Mbps for unicast. However, for multicast traffic sent from the have a datarate of only 32Mbps for unicast. However, for multicast
access point, all traffic is sent at the base transmission rate traffic sent from the access point, all traffic is sent at the base
(which is configurable, but depending on the model of the access transmission rate (which is configurable, but depending on the model
point, is usually 24Mbps or less). of the access point, is usually 24Mbps or less).
In addition to utilizing variable datarate links, mobile networks are In addition to utilizing variable datarate links, mobile networks are
challenged by the notion that link connectivity will come and go over 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). time, without an effect on a router's interface state (Up or Down).
Effectively utilizing a relatively short-lived connection is Effectively utilizing a relatively short-lived connection is
problematic in IP routed networks, as routing protocols tend to rely problematic in IP routed networks, as routing protocols tend to rely
on interface state and independent timers at OSI Layer 3 to maintain on interface state and independent timers at OSI Layer 3 to maintain
network convergence (e.g. HELLO messages and/or recognition of DEAD network convergence (e.g., HELLO messages and/or recognition of DEAD
routing adjacencies). These dynamic connections can be better routing adjacencies). These dynamic connections can be better
utilized with an event-driven paradigm, where acquisition of a new utilized with an event-driven paradigm, where acquisition of a new
neighbor (or loss of an existing one) is signaled, as opposed to a neighbor (or loss of an existing one) is signaled, as opposed to a
paradigm driven by timers and/or interface state. paradigm driven by timers and/or interface state.
Another complicating factor for mobile networks are the different Another complicating factor for mobile networks are the different
methods of physically connecting the modem devices to the router. methods of physically connecting the modem devices to the router.
Modems can be deployed as an interface card in a router's chassis, or 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 as a standalone device connected to the router via Ethernet or serial
link. In the case of Ethernet or serial attachment, with existing link. In the case of Ethernet or serial attachment, with existing
protocols and techniques, routing software cannot be aware of protocols and techniques, routing software cannot be aware of
convergence events occurring on the radio link (e.g. acquisition or convergence events occurring on the radio link (e.g., acquisition or
loss of a potential routing neighbor), nor can the router be aware of 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 actual capacity of the link. This lack of awareness, along with
the variability in datarate, leads to a situation where finding the the variability in datarate, leads to a situation where finding the
(current) best route through the network to a given destination is (current) best route through the network to a given destination is
difficult to establish and properly maintain. This is especially true difficult to establish and properly maintain. This is especially
of demand-based access schemes such as Demand Assigned Multiple true of demand-based access schemes such as Demand Assigned Multiple
Access (DAMA) implementations used on some satellite systems. With a Access (DAMA) implementations used on some satellite systems. With a
DAMA-based system, additional datarate may be available, but will not DAMA-based system, additional datarate may be available, but will not
be used unless the network devices emit traffic at rate higher than be used unless the network devices emit traffic at a rate higher than
the currently established rate. Increasing the traffic rate does not the currently established rate. Increasing the traffic rate does not
guarantee additional datarate will be allocated; rather, it may guarantee additional datarate will be allocated; rather, it may
result in data loss and additional retransmissions on the link. result in data loss and additional retransmissions on the link.
Addressing the challenges listed above, the authors have developed Addressing the challenges listed above, the authors have developed
the Data Link Exchange Protocol, or DLEP. The DLEP protocol runs the Data Link Exchange Protocol, or DLEP. The DLEP protocol runs
between a router and its attached modem devices, allowing the modem between a router and its attached modem devices, allowing the modem
to communicate link characteristics as they change, and convergence to communicate link characteristics as they change, and convergence
events (acquisition and loss of potential routing destinations). The events (acquisition and loss of potential routing destinations). The
following diagrams are used to illustrate the scope of DLEP packets. following diagrams are used to illustrate the scope of DLEP packets.
|-------Local Node-------| |-------Remote Node------| |-------Local Node-------| |-------Remote Node------|
| | | | | | | |
+--------+ +-------+ +-------+ +--------+ +--------+ +-------+ +-------+ +--------+
| Router |=======| Modem |{~~~~~~~~}| Modem |=======| Router | | Router |=======| Modem |{~~~~~~~~}| Modem |=======| Router |
| | | Device| | Device| | | | | | Device| | Device| | |
+--------+ +-------+ +-------+ +--------+ +--------+ +-------+ +-------+ +--------+
| | | Link | | | | | | Link | | |
|-DLEP--| | Protocol | |-DLEP--| |-DLEP--| | Protocol | |-DLEP--|
| | | (e.g. | | | | | | (e.g. | | |
| | | 802.11) | | | | | | 802.11) | | |
Figure 1: DLEP Network Figure 1: DLEP Network
In Figure 1, when the local modem detects the presence of a remote In Figure 1, when the local modem detects the presence of a remote
node, it (the local modem) sends a signal to its router via the DLEP node, it (the local modem) sends a signal to its router via the DLEP
protocol. Upon receipt of the signal, the local router may take protocol. Upon receipt of the signal, the local router may take
whatever action it deems appropriate, such as initiating discovery whatever action it deems appropriate, such as initiating discovery
protocols, and/or issuing HELLO messages to converge the network. On protocols, and/or issuing HELLO messages to converge the network. On
a continuing, as-needed basis, the modem devices utilize DLEP to a continuing, as-needed basis, the modem devices utilize DLEP to
report any characteristics of the link (datarate, latency, etc) that report any characteristics of the link (datarate, latency, etc) that
have changed. DLEP is independent of the link type and topology have changed. DLEP is independent of the link type and topology
supported by the modem. Note that the DLEP protocol is specified to supported by the modem. Note that the DLEP protocol is specified to
run only on the local link between router and modem. Some over the 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 air signaling may be necessary between the local and remote modem in
order to provide some parameters in DLEP signals between the local order to provide some parameters in DLEP signals between the local
modem and local router, but DLEP does not specify how such over the 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 air signaling is carried out. Over the air signaling is purely a
matter for the modem implementer. matter for the modem implementer.
Figure 2 shows how DLEP can support a configuration where routers are Figure 2 shows how DLEP can support a configuration where routers are
connected with different link types. In this example, Modem A connected with different link types. In this example, Modem A
implements a point-to-point link, and Modem B is connected via a implements a point-to-point link, and Modem B is connected via a
shared medium. In both cases, the DLEP protocol is used to report the shared medium. In both cases, the DLEP protocol is used to report
characteristics of the link (datarate, latency, etc.) to routers. The the characteristics of the link (datarate, latency, etc.) to routers.
modem is also able to use the DLEP session to notify the router when The modem is also able to use the DLEP session to notify the router
the remote node is lost, shortening the time required to re-converge when the remote node is lost, shortening the time required to re-
the network. converge the network.
+--------+ +--------+ +--------+ +--------+
+----+ Modem A| | Modem A+---+ +----+ Modem A| | Modem A+---+
| | Device | <===== // ======> | Device | | | | Device | <===== // ======> | Device | |
| +--------+ P-2-P Link +--------+ | | +--------+ P-2-P Link +--------+ |
+---+----+ +---+----+ +---+----+ +---+----+
| Router | | Router | | Router | | Router |
| | | | | | | |
+---+----+ +---+----+ +---+----+ +---+----+
| +--------+ +--------+ | | +--------+ +--------+ |
+-----+ Modem B| | Modem B| | +-----+ Modem B| | Modem B| |
| Device | o o o o o o o o | Device +--+ | Device | o o o o o o o o | Device +--+
+--------+ o Shared o +--------+ +--------+ o Shared o +--------+
o Medium o o Medium o
o o o o
o o o o
o o o o
o o
+--------+ +--------+
| Modem B| | Modem B|
| Device | | Device |
+---+----+ +---+----+
| |
| |
+---+----+ +---+----+
| Router | | Router |
| | | |
+--------+ +--------+
Figure 2: DLEP Network with Multiple Modem Devices Figure 2: DLEP Network with Multiple Modem Devices
DLEP defines a set of signals used by modems and their attached DLEP defines a set of signals used by modems and their attached
routers. The signals are used to communicate events that occur on the routers. The signals are used to communicate events that occur on
physical link(s) managed by the modem: for example, a remote node the physical link(s) managed by the modem: for example, a remote node
entering or leaving the network, or that the link has changed. entering or leaving the network, or that the link has changed.
Associated with these signals are a set of data items - information Associated with these signals are a set of data items - information
that describes the remote node (e.g., address information), and/or that describes the remote node (e.g., address information), and/or
the characteristics of the link to the remote node. the characteristics of the link to the remote node.
The protocol is defined as a collection of type-length-value (TLV) The protocol is defined as a collection of type-length-value (TLV)
based formats, specifying the signals that are exchanged between a based formats, specifying the signals that are exchanged between a
router and a modem, and the data items associated with the signal. router and a modem, and the data items associated with the signal.
This document specifies transport of DLEP signals and data items via This document specifies transport of DLEP signals and data items via
the TCP transport, with a UDP-based discovery mechanism. Other the TCP transport, with a UDP-based discovery mechanism. Other
transports for the protocol are possible, but are outside the scope transports for the protocol are possible, but are outside the scope
of this document. of this document.
DLEP signals are further defined as mandatory or optional. Signals
will additionally have mandatory and optional data items.
Implementations MUST support all mandatory signals and their
mandatory data items to be considered compliant. Implementations MAY
also support some, or all, of the optional signals and data items.
DLEP uses a session-oriented paradigm between the modem device and DLEP uses a session-oriented paradigm between the modem device and
its associated router. If multiple modem devices are attached to a its associated router. If multiple modem devices are attached to a
router (as in Figure 2), a separate DLEP session MUST exist for each router (as in Figure 2), a separate DLEP session MUST exist for each
modem. If a modem device supports multiple connections to a router modem. If a modem device supports multiple connections to a router
(via multiple logical or physical interfaces), or supports (via multiple logical or physical interfaces), or supports
connections to multiple routers, a separate DLEP session MUST exist connections to multiple routers, a separate DLEP session MUST exist
for each connection. This router/modem session provides a carrier for for each connection. This router/modem session provides a carrier
information exchange concerning "destinations" that are available via for information exchange concerning 'destinations' that are available
the modem device. A "destination" can be either physical (as in the via the modem device. A 'destination' can be either physical (as in
case of a specific far-end router), or a logical destination (as in a the case of a specific far-end router), or a logical destination (as
Multicast group). As such, all of the destination-level exchanges in in a Multicast group). As such, all of the destination-level
DLEP can be envisioned as building an information base concerning the exchanges in DLEP can be envisioned as building an information base
remote nodes, and the link characteristics to those nodes. concerning the remote nodes, and the link characteristics to those
nodes.
Any DLEP signal that is NOT understood by a receiver MUST result in Any DLEP signal that is NOT understood by a receiver MUST result in
an error indication being sent to the originator, and also MUST an error indication being sent to the originator, and also MUST
result in termination of the session between the DLEP peers. Any data result in termination of the session between the DLEP peers. Any
item that is NOT understood by a receiver MUST be ignored. data item that is NOT understood by a receiver MUST be ignored.
Multicast traffic destined for the variable-quality network (the Multicast traffic destined for the variable-quality network (the
network accessed via the DLEP modem) is handled in IP networks by network accessed via the DLEP modem) is handled in IP networks by
deriving a Layer 2 MAC address based on the Layer 3 address. deriving a Layer 2 MAC address based on the Layer 3 address.
Leveraging on this scheme, Multicast traffic is supported in DLEP Leveraging on this scheme, Multicast traffic is supported in DLEP
simply by treating the derived MAC address as any other "destination" simply by treating the derived MAC address as any other 'destination'
(albeit a logical one) in the network. To support these logical (albeit a logical one) in the network. To support these logical
destinations, one of the DLEP participants (typically, the router) destinations, one of the DLEP participants (typically, the router)
informs the other as to the existence of the logical neighbor. The informs the other as to the existence of the logical neighbor. The
modem, once it is aware of the existence of this logical neighbor, modem, once it is aware of the existence of this logical neighbor,
reports link characteristics just as it would for any other reports link characteristics just as it would for any other
destination in the network. The specific algorithms a modem would use destination in the network. The specific algorithms a modem would
to report metrics on multicast (or logical) destinations is outside use to report metrics on multicast (or logical) destinations is
the scope of this specification, and is left to specific outside the scope of this specification, and is left to specific
implementations to decide. implementations to decide.
1.1 Requirements 1.1. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
2. Assumptions 2. Assumptions
Routers and modems that exist as part of the same node (e.g., that Routers and modems that exist as part of the same node (e.g., that
are locally connected) can utilize a discovery technique to locate are locally connected) can utilize a discovery technique to locate
each other, thus avoiding a-priori configuration. The router is each other, thus avoiding a-priori configuration. The router is
responsible for initialing the discovery process, using the Peer responsible for initializing the discovery process, using the Peer
Discovery signal. Discovery signal (Section 7.1).
DLEP utilizes a session-oriented paradigm. A router and modem form a DLEP utilizes a session-oriented paradigm. A router and modem form a
session by completing the discovery process. This router-modem session by completing the discovery process. This router-modem
session persists unless or until it either (1) times out, based on session persists unless or until it either (1) times out, based on
the timeout values supplied, or (2) is explicitly torn down by one of the timeout values supplied, or (2) is explicitly torn down by one of
the participants. Note that while use of timers in DLEP is OPTIONAL, the participants. Note that while use of timers in DLEP is OPTIONAL,
it is strongly recommended that implementations choose to run with it is strongly recommended that implementations choose to run with
timers enabled. timers enabled.
DLEP assumes that participating modems, and their physical links, act DLEP assumes that the MAC address for delivering data traffic is the
as a transparent IEEE 802.1D bridge. Specifically, the assumption is MAC specified in the Destination Up signal (Section 7.9). No
that the destination MAC address for data traffic (frames destined manipulation or or substitution is performed; the MAC address
for the far-end node, as opposed to the DLEP control traffic itself) supplied in Destination Up is used as the OSI Layer 2 Destination MAC
in any frame emitted by the router should be the MAC address of a address. DLEP also assumes that MAC addresses MUST be unique within
device in the remote node. DLEP also assumes that MAC addresses are the context of a router-modem session.
unique within the context of the router-modem session.
DLEP utilizes UDP multicast for single-hop discovery, and TCP for DLEP utilizes UDP multicast for single-hop discovery, and TCP for
transport of the control signals. Therefore, DLEP assumes that the transport of the control signals. Therefore, DLEP assumes that the
modem and router have topologically consistent IP addresses assigned. modem and router have topologically consistent IP addresses assigned.
It is recommended that DLEP implementations utilize IPv6 link-local It is recommended that DLEP implementations utilize IPv6 link-local
addresses to reduce the administrative burden of address assignment. addresses to reduce the administrative burden of address assignment.
This document refers to a remote node as a "Destination". This document refers to a remote node as a 'Destination'.
Destinations can be identified by either the router or the modem, and Destinations can be identified by either the router or the modem, and
represent a specific destination (e.g., an address) that exists on represent a specific destination (e.g., an address) that exists on
the link(s) managed by the modem. A destination MUST contain a MAC the link(s) managed by the modem. A destination MUST contain a MAC
address, it MAY optionally include a Layer 3 address (or addresses). address, it MAY optionally include a Layer 3 address (or addresses).
Destinations MAY refer either to physical devices in the network, or Note that since a destination is a MAC address, the MAC could
to logical destinations, as in a derived multicast MAC address reference a logical destination, as in a derived multicast MAC
associated with a group. As "destinations" are discovered, DLEP address, as well as to a physical device. As destinations are
routers and modems build an information base on destinations discovered, DLEP routers and modems build an information base on
accessible via the modem. Changes in link characteristics MAY then be destinations accessible via the modem. Changes in link
reported as being "modem-wide" (effecting ALL destinations accessed characteristics are then reported as being 'modem-wide' (effecting
via the modem) or MAY be neighbor (destination) specific. ALL destinations accessed via the modem, reported via the Peer Update
signal, Section 7.5) or reported for a specific neighbor (via the
Destination Update signal, Section 7.13).
The DLEP signals concerning destinations thus become the way for The DLEP signals concerning destinations thus become the way for
routers and modems to maintain, and notify each other about, an routers and modems to maintain, and notify each other about, an
information base representing the physical and logical (e.g., information base representing the physical and logical (e.g.,
multicast) destinations accessible via the modem device. The multicast) destinations accessible via the modem device. The
information base would contain addressing information (e.g., MAC information base would contain addressing information (i.e., MAC
address, and OPTIONALLY, Layer 3 addresses), link characteristics address, and OPTIONALLY, Layer 3 addresses), link characteristics
(metrics), and OPTIONALLY, flow control information (credits). (metrics), and OPTIONALLY, flow control information (credits).
DLEP assumes that security on the session (e.g. authentication of DLEP assumes that security on the session (e.g., authentication of
session partners, encryption of traffic, or both) is dealt with by session partners, encryption of traffic, or both) is dealt with by
the underlying transport mechanism (e.g., by using a transport such the underlying transport mechanism (e.g., by using a transport such
as TLS [TLS]). as TLS [RFC5246]).
This document specifies an implementation of the DLEP signals and This document specifies an implementation of the DLEP signals and
data items running over the TCP transport. It is assumed that DLEP data items running over the TCP transport. It is assumed that DLEP
running over other transport mechanisms would be documented running over other transport mechanisms would be documented
separately. separately.
3. Mandatory Versus Optional Items 3. Core Features and Optional Extensions
As mentioned above, DLEP defines a core set of signals and data items DLEP has a core set of signals and data items that MUST be processed
as mandatory. Support for those signals and data items MUST exist in without error by an implementation in order to guarantee
an implementation to guarantee interoperability and therefore make an interoperability and therefore make the implementation DLEP
implementation DLEP compliant. However, a mandatory signal or data compliant. This document defines the core set of signals and data
item is not necessarily required - as an example, consider the data items, listing them as 'mandatory'. It should be noted that some
item entitled "DLEP Optional Signals Supported", defined in section core signals and data items might not be used during the lifetime of
10.22 of this document. The data item allows a DLEP implementation to a single DLEP session, but a compliant implementation MUST support
list all optional behavior it supports, and is sent as a part of the them.
Peer Initialization signal. Receiving implementations MUST be capable
of parsing and understanding the optional signals that are offered.
However, if the sending implementation has chosen NOT to implement
ANY optional functionality, this data item would NOT be included in
the Peer Initialization. Although parsing and understanding the data
item is a mandatory function of a compliant DLEP, the data item
itself MAY, or MAY NOT, appear in the flow. Absence of the mandatory
data item would not be considered a protocol error, but as support
for the core DLEP signals ONLY. Therefore, care should be taken to
differentiate the notion of a mandatory data item versus one that
MUST appear in a given message.
4. Credits While this document represents the best efforts of the co-authors,
and 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 utilized. To support future extension of DLEP, this
document describes an extension negotiation capability to be used
during session initialization via the Extensions Supported data item,
documented in Section 8.6 of this document.
DLEP includes an OPTIONAL credit-windowing scheme analogous to the All extensions are considered OPTIONAL. Only the DLEP functionality
one documented in [RFC5578]. In this scheme, traffic between the listed as 'mandatory' is required by implementation in order to be
router and modem is treated as two unidirectional windows. This DLEP compliant.
document identifies these windows as the "Modem Receive Window", or
MRW, and the "Router Receive Window", or RRW.
If the OPTIONAL credit-windowing scheme is used, credits MUST be This specification defines one extension, Credit processing, exposed
granted by the receiver on a given window - that is, on the "Modem via the Extensions Supported mechanism that implementations MAY chose
Receive Window" (MRW), the modem is responsible for granting credits to implement, or to omit.
to the router, allowing it (the router) to send data to the modem.
Likewise, the router is responsible for granting credits on the RRW,
which allows the modem to send data to the router.
DLEP expresses all credit data in number of octets. The total number 3.1. Negotiation of Optional Extensions
of credits on a window, and the increment to add to a grant, are
always expressed as a 64-bit unsigned quantity.
If used, credits are managed on a neighbor-specific basis; that is, Optional extensions supported by an implementation MUST be declared
separate credit counts are maintained for each neighbor requiring the to potential DLEP peers using the Extensions Supported data item
service. Credits do not apply to the DLEP session that exists between (Section 8.6) during the session initialization sequence. Once both
routers and modems. peers have exchanged initialization signals, an implementation MUST
NOT emit any signal or data item associated with an optional
extension that was not specified in the received initialization
signal from its peer.
5. Metrics 3.2. Protocol Extensions
If/when protocol extensions are required, they should be standardized
either as an update to this document, or as an additional stand-alone
specification. The requests for IANA-controlled registries in this
document contain sufficient reserved space, both in terms of DLEP
signals and DLEP data items, to accomodate future extensions to the
protocol and the data transferred.
3.3. Experimental Signals and Data Items
This document requests numbering space in both the DLEP signal and
data item registries for experimental items. The intent is to allow
for experimentation with new signals and/or data items, while still
retaining the documented DLEP behavior. If a given experiment proves
successful, it SHOULD be documented as an update to this document, or
as a stand-alone specification.
Use of the experimental signals or data items MUST be announced by
inclusion of an Experimental Definition data item (Section 8.7) with
a value agreed upon (a-priori) between the participating peers. The
exact mechanism for a-priori communication of the experimental
definition formats is beyond the scope of this document.
Multiple Experimental Definition data items MAY appear in the Peer
Initialization/Peer Initialization ACK sequence. However, use of
multiple experiments in a single peer session could lead to
interoperability issues or unexpected results (e.g., redefinition of
experimental signals and/or data items), and is therefore
discouraged. It is left to implementations to determine the correct
processing path (e.g., a decision on whether to terminate the peer
session, or to establish a precedence of the conflicting definitions)
if such conflicts arise.
4. Metrics
DLEP includes the ability for the router and modem to communicate DLEP includes the ability for the router and modem to communicate
metrics that reflect the characteristics (e.g. datarate, latency) of metrics that reflect the characteristics (e.g., datarate, latency) of
the variable-quality link in use. DLEP does NOT specify how a given the variable-quality link in use. DLEP does NOT specify how a given
metric value is to be calculated, rather, the protocol assumes that metric value is to be calculated, rather, the protocol assumes that
metrics have been calculated with a "best effort", incorporating all metrics have been calculated with a 'best effort', incorporating all
pertinent data that is available to the modem device. pertinent data that is available to the modem device.
As mentioned in the introduction section of this document, metrics As mentioned in the introduction section of this document, metrics
have to be used within a context - for example, metrics to a unicast have to be used within a context - for example, metrics to a unicast
address in the network. DLEP allows for metrics to be sent within two address in the network. DLEP allows for metrics to be sent within
contexts - metrics for a specific destination within the network two contexts - metrics for a specific destination within the network
(e.g., a specific router), and "modem-wide" (those that apply to all (e.g., a specific router), and 'modem-wide' (those that apply to all
destinations accessed via the modem). Metrics can be further destinations accessed via the modem). Metrics can be further
subdivided into transmit and receive metrics. Metrics supplied on subdivided into transmit and receive metrics. Metrics supplied on
DLEP Peer signals are, by definition, modem-wide; metrics supplied on DLEP Peer signals are, by definition, modem-wide; metrics supplied on
Destination signals are, by definition, used for the specific Destination signals are, by definition, used for the specific
neighbor only. neighbor only.
DLEP modem implementations MUST announce all supported metric items, DLEP modem implementations MUST announce all supported metric items,
and provide default values for those metrics, in the Peer and provide default values for those metrics, in the Peer
Initialization signal. In order to introduce a new metric type, DLEP Initialization signal (Section 7.3). In order to introduce a new
modem implementations MUST terminate the session with the router (via metric type, DLEP modem implementations MUST terminate the session
the Peer Terminate signal), and re-establish the session. with the router (via the Peer Terminate signal, Section 7.7), and re-
establish the session.
It is left to implementations to choose sensible default values based It is left to implementations to choose sensible default values based
on their specific characteristics. Modems having static (non- on their specific characteristics. Modems having static (non-
changing) link metric characteristics MAY report metrics only once changing) link metric characteristics MAY report metrics only once
for a given neighbor (or once on a modem-wide basis, if all for a given neighbor (or once on a modem-wide basis, if all
connections via the modem are of this static nature). connections via the modem are of this static nature).
The approach of allowing for different contexts for metric data The approach of allowing for different contexts for metric data
increases both the flexibility and the complexity of using metric increases both the flexibility and the complexity of using metric
data. This document details the mechanism whereby the data is data. This document details the mechanism whereby the data is
transmitted, however, the specific algorithms (precedence, etc) for transmitted, however, the specific algorithms (precedence, etc) for
utilizing the dual-context metrics is out of scope and not addressed utilizing the dual-context metrics is out of scope and not addressed
by this document. by this document.
6. Extensions to DLEP 4.1. Mandatory Metrics
While this draft represents the best efforts of the co-authors, and
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 utilized. There are three possible avenues for DLEP
extensions: protocol extensions, vendor extensions, and experimental
extensions.
6.1 Protocol Extensions As mentioned above, DLEP modem implementations MUST announce all
supported metric items during session initialization. However, an
implementation MUST include the following list of metrics:
If/when protocol extensions are required, they should be standardized o Maximum Data Rate (Receive) (Section 8.13)
either as an update to this document, or as an additional stand-alone
specification.
6.2 Vendor Extensions o Maximum Data Rate (Transmit) (Section 8.14)
Vendor extensions to DLEP are accommodated via the "DLEP Vendor o Current Data Rate (Receive) (Section 8.15)
Extension" TLV, documented in Section 10.22 of this document. If a
perceived extension exceeds the scope of what can be contained in the
DLEP Vendor Extension TLV, the proposed extension should be addressed
as either an update to this document, or as a stand-alone
specification.
6.3 Experimental Extensions o Current Data Rate (Transmit) (Section 8.16)
This document requests numbering space in both the Signal and Data o Latency (Section 8.17)
Item registries for experimental items. The intent is to allow for
experimentation with new signals and/or data items, while still
retaining the documented DLEP behavior. If a given experiment proves
successful, it SHOULD be documented as an update to this document, or
as a stand-alone specification. Experimental DLEP signals SHOULD be
treated as optional signals - e.g., they SHOULD be announced in the
"DLEP Optional Signals TLV" in Peer Initialization and/or Peer
Initialization ACK. Likewise, experimental data item TLVs SHOULD be
announced in the "DLEP Optioinal Data Items" TLV (also in Peer
Initialization/Peer Initialization ACK).
7. Normal Session Flow 5. Normal Session Flow
Normal session flow for a DLEP router has two sub-cases, depending on Normal session flow for a DLEP router has two sub-cases, depending on
whether the implementation supports the discovery process. Since whether the implementation supports the discovery process. Modem
modems MUST support the discovery process, there is only one implementations MUST support the Discovery case; router
description necessary for modem implementations. The normal flow by implementations MAY support discovery, or rely on a-priori
DLEP partner type is: configuration to define the address(es) of attached modems.
7.1 DLEP Router session flow - Discovery case 5.1. DLEP Router session flow - Discovery case
If the DLEP router implementation is utilizing the optional discovery If the DLEP router implementation is utilizing the optional discovery
mechanism, then the implementation will initialize a UDP socket, mechanism, then the implementation will initialize a UDP socket,
binding it to an arbitrary port. This UDP socket is used to send the binding it to an arbitrary port. This UDP socket is used to send the
Peer Discovery signal to the DLEP link-local multicast address and Peer Discovery signal (Section 7.1) to the DLEP link-local multicast
port (TBD). The implementation then waits on receipt of a Peer Offer address and port (TBD). The implementation then waits on receipt of
signal, which MUST contain the unicast address and port for TCP-based a Peer Offer signal (Section 7.2), which MUST contain the unicast
communication with a DLEP modem. The Peer Offer signal MAY contain address and port for TCP-based communication with a DLEP modem. The
multiple address/port combinations. If more than one address/port Peer Offer signal MAY contain multiple address/port combinations. If
combination is in the Peer Offer, the DLEP router implementation more than one address/port combination is in the Peer Offer, the DLEP
SHOULD consider the list to be in priority sequence, with the "most router implementation SHOULD consider the list to be in priority
desired" address/port combination listed first. However, router sequence, with the 'most desired' address/port combination listed
implementations MAY use their own heuristics to determine the best first. However, router implementations MAY use their own heuristics
address/port combination. At this point, the router implementation to determine the best address/port combination. At this point, the
MAY either destroy the UDP socket, or continue to issue Peer router implementation MAY either destroy the UDP socket, or continue
Discovery signals to the link-local address/port combination. In to issue Peer Discovery signals to the link-local address/port
either case, the TCP session initialization occurs as in the combination. In either case, the TCP session initialization occurs
configured case. as in the configured case.
7.2 DLEP Router session flow - Configured case 5.2. DLEP Router session flow - Configured case
When a DLEP router implementation has the address and port When a DLEP router implementation has the address and port
information for a TCP connection to a modem (obtained either via information for a TCP connection to a modem (obtained either via
configuration or via the discovery process described above), the configuration or via the discovery process described above), the
router will initialize and bind a TCP socket. This socket is used to router will initialize and bind a TCP socket. This socket is used to
connect to the DLEP modem software. After a successful TCP connect, connect to the DLEP modem software. After a successful TCP connect,
the modem implementation MUST issue a Peer Initialization signal to the modem implementation MUST issue a Peer Initialization signal
the DLEP router. The Peer Initialization signal MUST contain TLVs for (Section 7.3) to the DLEP router. The Peer Initialization signal
ALL supported metrics from this modem (e.g. all mandatory metrics MUST contain data items for ALL supported metrics from this modem,
plus all optional metrics supported by the implementation), along along with the default values of those metrics. After sending the
with the default values of those metrics. After sending the Peer Peer Initialization, the modem implementation MUST wait for receipt
Initialization, the modem implementation MUST wait for receipt of a of a Peer Initialization ACK signal (Section 7.4) from the router.
Peer Initialization ACK signal from the router. Receipt of the Peer Receipt of the Peer Initialization ACK signal indicates that the
Initialization ACK indicates that the router has received and router has received and processed the Peer Initialization, and the
processed the Peer Initialization, and the session MUST transition to session MUST transition to the 'in session' state. At this point,
the "in session" state. At this point, signals regarding destinations signals regarding destinations in the network, and/or Peer Update
in the network, and/or Peer Update signals, can flow on the DLEP signals (Section 7.5), can flow on the DLEP session between modem and
session between modem and router. The "in session" state is router. The 'in session' state is maintained until one of the
maintained until one of the following conditions occur: following conditions occur:
o The session is explicitly terminated (using Peer Termination), or o The session is explicitly terminated (using Peer Termination), or
o The session times out, based on supplied timeout values. o The session times out, based on supplied timeout values.
7.3 DLEP Modem session flow 5.3. DLEP Modem session flow
DLEP modem implementations MUST support the discovery mechanism. DLEP modem implementations MUST support the discovery mechanism.
Therefore, the normal flow is as follows: Therefore, the normal flow is as follows:
The implementation will initialize a UDP socket, binding that socket The implementation will initialize a UDP socket, binding that socket
to the DLEP link-local multicast address (TBD) and the DLEP well- to the DLEP link-local multicast address (TBD) and the DLEP well-
known port number (also TBD). The implementation will then initialize known port number (also TBD). The implementation will then
a TCP socket, on a unicast address and port. This socket is used to initialize a TCP socket, on a unicast address and port. This socket
listen for incoming TCP connection requests. is used to listen for incoming TCP connection requests.
When the modem implementation receives a Peer Discovery signal on the When the modem implementation receives a Peer Discovery signal
UDP socket, it responds by issuing a Peer Offer signal to the sender (Section 7.1) on the UDP socket, it responds by issuing a Peer Offer
of the Peer Discovery. The Peer Offer signal MUST contain the unicast signal (Section 7.2) to the sender of the Peer Discovery signal. The
address and port of the TCP listen socket, described above. A DLEP Peer Offer signal MUST contain the unicast address and port of the
modem implementation MAY respond with ALL address/port combinations TCP listen socket, described above. A DLEP modem implementation MAY
that have an active TCP listen posted. If multiple address/port respond with ALL address/port combinations that have an active TCP
combinations are listed, the receiver of the Peer Offer MAY connect listen posted. If multiple address/port combinations are listed, the
on any available address/port pair. Anything other than Peer receiver of the Peer Offer signal MAY connect on any available
Discovery signals received on the UDP socket MUST be silently address/port pair. Anything other than Peer Discovery signals
dropped. received on the UDP socket MUST be silently dropped.
When the DLEP modem implementation accepts a connection via TCP, it When the DLEP modem implementation accepts a connection via TCP, it
MUST send a Peer Initialization signal. The Peer Initialization MUST MUST send a Peer Initialization signal (Section 7.3). The Peer
contain metric TLVs for ALL mandatory metrics, and MUST contain Initialization signal MUST contain metric data items for ALL
metric TLVs for ANY optional metrics supported by the modem. If a new supported metrics. If an additional metric is to be introduced, the
metric is to be introduced, the DLEP session between router and modem DLEP session between router and modem MUST be terminated and
MUST be terminated and restarted, and the new metric described in a restarted, and the new metric described in a Peer Initialization
Peer Initialization signal. signal.
7.4 Common Session Flow 5.4. Common Session Flow
In order to maintain the session between router and modem, periodic In order to maintain the session between router and modem, periodic
"Heartbeat" signals MAY be exchanged. These signals are intended to Heartbeat signals (Section 7.14) MAY be exchanged. These signals are
keep the session alive, and to verify bidirectional connectivity intended to keep the session alive, and to verify bidirectional
between the two participants. DLEP also provides an OPTIONAL Peer connectivity between the two participants. DLEP also provides a Peer
Update signal, intended to communicate some change in status (e.g., a Update signal (Section 7.5), intended to communicate some change in
change of layer 3 address parameters, or a modem-wide link change). status (e.g., a change of layer 3 address parameters, or a modem-wide
link change).
In addition to the local (Peer level) signals above, the participants In addition to the local (Peer level) signals above, the participants
will transmit DLEP signals concerning destinations in the network. will transmit DLEP signals concerning destinations in the network.
These signals trigger creation/maintenance/deletion of destinations These signals trigger creation/maintenance/deletion of destinations
in the information base of the recipient. For example, a modem will in the information base of the recipient. For example, a modem will
inform its attached router of the presence of a new destination via inform its attached router of the presence of a new destination via
the "Destination Up" signal. Receipt of a Destination Up causes the the Destination Up signal (Section 7.9). Receipt of a Destination Up
router to allocate the necessary resources, creating an entry in the causes the router to allocate the necessary resources, creating an
information base with the specifics (e.g., MAC Address, Latency, Data entry in the information base with the specifics (i.e., MAC Address,
Rate, etc) of the neighbor. The loss of a destination is communicated Latency, Data Rate, etc) of the neighbor. The loss of a destination
via the "Destination Down" signal, and changes in status to the is communicated via the Destination Down signal (Section 7.11), and
destination (e.g. varying link quality, or addressing changes) are changes in status to the destination (e.g., varying link quality, or
communicated via the "Destination Update" signal. The information on addressing changes) are communicated via the Destination Update
a given neighbor will persist in the router's information base until signal (Section 7.13). The information on a given neighbor will
(1) a "Destination Down" is received, indicating that the modem has persist in the router's information base until (1) a Destination Down
lost contact with the remote node, or (2) the router/modem session signal is received, indicating that the modem has lost contact with
terminates, indicating that the router has lost contact with its own the remote node, or (2) the router/modem session terminates,
local modem. indicating that the router has lost contact with its own local modem.
Again, metrics can be expressed within the context of a specific Metrics can be expressed within the context of a specific neighbor
neighbor via the Destination Update signal, or on a modem-wide basis via the Destination Update signal, or on a modem-wide basis via the
via the Peer Update signal. In cases where metrics are provided on Peer Update signal. In cases where metrics are provided on the
the router/modem session, the receiver MUST propagate the metrics to router/modem session, the receiver MUST propagate the metrics to all
all destinations in its information base that are accessed via the destinations in its information base that are accessed via the
originator. A DLEP participant MAY send metrics both in a originator. A DLEP participant MAY send metrics both in a router/
router/modem session context (via the Peer Update signal) and a modem session context (via the Peer Update signal) and a specific
specific neighbor context (via Destination Update) at any time. The neighbor context (via Destination Update) at any time. The
heuristics for applying received metrics is left to implementations. heuristics for applying received metrics is left to implementations.
In addition to receiving metrics about the link, DLEP provides an In addition to receiving metrics about the link, DLEP provides a
OPTIONAL signal allowing a router to request a different datarate, or signal allowing a router to request a different datarate, or latency,
latency, from the modem. This signal is referred to as the Link from the modem. This signal is referred to as the Link
Characteristics Signal, and gives the router the ability to deal with Characteristics Request signal (Section 7.15), and gives the router
requisite increases (or decreases) of allocated datarate/latency in the ability to deal with requisite increases (or decreases) of
demand-based schemes in a more deterministic manner. allocated datarate/latency in demand-based schemes in a more
deterministic manner.
8. Mandatory Signals and Data Items 6. DLEP Message Processing
The following DLEP signals are considered core to the specification; Communication between DLEP peers consists of a bidirectional stream
implementations MUST support these signals, and the associated data of signals, each signal consisting of a signal header and an
items, in order to be considered compliant: unordered list of data items. Both signal headers and data items are
encoded as TLV (Type-Length-Value) structures. In this document, the
data items following the signal header are described as being
'contained in' the signal.
Signal Data Items All integer values in all TLV structures MUST be in network byte-
====== ========== order.
Peer Discovery (Router Only) None
Peer Offer (Modem Only) IPv4 Address There is no restriction on the order of data items following a
IPv6 address signal, and the multiplicity of duplicate data items is defined by
DLEP Port the definition of the signal declared by the type in the signal
header.
Peer Initialization Maximum Data Rate (Receive) If an unrecognized, or unexpected signal is received, or a received
Maximum Data Rate (Transmit) signal contains unrecognized, invalid or disallowed duplicate data
Current Data Rate (Receive) items, the receiving peer MUST terminate the session by issuing a
Current Data Rate (Transmit) Peer Termination signal (Section 7.7) with a Status data item
Latency (Section 8.2) containing the most relevant status code, and then
Relative Link Quality (Receive) close the TCP connection:
Relative Link Quality (Transmit)
DLEP Optional Signal Support
DLEP Optional Data Item Support
Peer Initialization ACK Status 6.1. DLEP Signal Header
Peer Termination Status The DLEP signal header contains the following fields:
Peer Termination ACK Status 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | Length | Data Items...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Destination Up MAC Address Figure 3: DLEP Signal Header
Maximum Data Rate (Receive)
Maximum Data Rate (Transmit)
Current Data Rate (Receive)
Current Data Rate (Transmit)
Latency
Relative Link Quality (Receive)
Relative Link Quality (Transmit)
Destination Update MAC Address Signal Type: One of the DLEP Signal Type values defined in this
Maximum Data Rate (Receive) document.
Maximum Data Rate (Transmit)
Current Data Rate (Receive)
Current Data Rate (Transmit)
Latency
Relative Link Quality (Receive)
Relative Link Quality (Transmit)
Destination Down MAC Address Length: The length, expressed as a 16-bit unsigned integer, of all
of the DLEP data items associated with this signal. This length
does not include the length of the header itself
All other DLEP signals and data items are OPTIONAL. Implementations Data Items: One or more DLEP data items, encoded in TLVs, as defined
MAY choose to provide them. Implementations that do not support in this document.
optional signals MUST report an error condition and terminate the
router/modem session upon receipt of any such signal received.
OPTIONAL data items received that are not supported MUST be silently
dropped.
9. Generic DLEP Signal Definition 6.2. DLEP Generic Data Item
The Generic DLEP Signal consists of a sequence of TLVs. The first TLV All DLEP data items contain the following fields:
represents the signal being communicated (e.g., a "Destination Up",
or a "Peer Offer"). Subsequent TLVs contain the data items pertinent
to the signal (e.g., Maximum Data Rate, or Latency, etc).
The Generic DLEP Packet Definition 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 | Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 Figure 4: DLEP Generic Data Item
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Signal TLV Type | Length | DLEP data items... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Signal - One of the DLEP Signal TLV type values Data Item Type: An 8-bit unsigned integer field specifying the data
defined in this document. item being sent.
Length - The length, expressed as a 16-bit Length: An 8-bit length of the value field of the data item.
quantity, of all of the DLEP data items
associated with this signal.
DLEP data items - One or more data items, encoded in TLVs, Value: A field of length <Length> which contains data specific to a
as defined in this document. particular data item.
10. DLEP Data Items 7. DLEP Signals
As mentioned earlier, DLEP protocol signals are transported as a As mentioned above, all DLEP signals begin with the DLEP signal
collection of TLVs. The first TLV present in a DLEP signal MUST be header structure. Therefore, in the following descriptions of
one of the Signal TLVs, documented in section 10. The signals are specific signals, this header structure is assumed, and will not be
followed by one or more data items, indicating the specific changes replicated.
that need to be instantiated in the receiver's information base.
Valid DLEP Data Items are: Following is the set of MANDATORY signals that must be recognized by
a DLEP compliant implementation. As mentioned before, not all
signals may be used during a session, but an implementation MUST
correctly process these signals when received.
TLV TLV The mandatory DLEP signals are:
Value Description
=========================================
TBD DLEP Port
TBD Peer Type
TBD IPv4 Address
TBD IPv6 Address
TBD Maximum Data Rate (Receive) (MDRR)
TBD Maximum Data Rate (Transmit) (MDRT)
TBD Current Data Rate (Receive) (CDRR)
TBD Current Data Rate (Transmit) (CDRT)
TBD Latency
TBD Receive Resources
TBD Transmit Resources
TBD Relative Link Quality (Receive) (RLQR)
TBD Relative Link Quality (Transmit) (RLQT)
TBD Status
TBD Heartbeat Interval/Threshold
TBD Neighbor down ACK timer
TBD Link Characteristics ACK timer
TBD Credit Window Status
TBD Credit Grant
TBD Credit Request
TBD DLEP Optional Signals Supported
TBD DLEP Optional Data Items Supported
TBD DLEP Vendor Extension
DLEP data item TLVs contain the following fields: +---------+-------------------------------+---------------+
| Signal | Description | Section |
+---------+-------------------------------+---------------+
| TBD | Peer Discovery | Section 7.1 |
| TBD | Peer Offer | Section 7.2 |
| TBD | Peer Initialization | Section 7.3 |
| TBD | Peer Initialization ACK | Section 7.4 |
| TBD | Peer Update | Section 7.5 |
| TBD | Peer Update ACK | Section 7.6 |
| TBD | Peer Termination | Section 7.7 |
| TBD | Peer Termination ACK | Section 7.8 |
| TBD | Destination Up | Section 7.9 |
| TBD | Destination Up ACK | Section 7.10 |
| TBD | Destination Down | Section 7.11 |
| TBD | Destination Down ACK | Section 7.12 |
| TBD | Destination Update | Section 7.13 |
| TBD | Heartbeat | Section 7.14 |
| TBD | Link Characteristics Request | Section 7.15 |
| TBD | Link Characteristics ACK | Section 7.16 |
+---------+-------------------------------+---------------+
0 1 2 3 7.1. Peer Discovery Signal
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | Length | Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - An 8-bit unsigned integer field specifying the data A Peer Discovery signal SHOULD be sent by a router to discover DLEP
item being sent. routers in the network. The Peer Offer signal (Section 7.2) is
required to complete the discovery process. Implementations MAY
implement their own retry heuristics in cases where it is determined
the Peer Discovery signal has timed out.
Length - An 8-bit length of the value field of the data item To construct a Peer Discovery signal, the Signal Type value in the
signal header is set to DLEP_PEER_DISCOVERY (value TBD).
Value - A field of length <Length> which contains data The Peer Discovery signal MUST contain one of each of the following
specific to a particular data item. data items:
10.1 DLEP Version o DLEP Version (Section 8.1)
The DLEP Version TLV is a mandatory TLV in the Peer Discovery, o Heartbeat Interval (Section 8.5)
Peer Initialization, and Peer Initialization ACK signals. The Version
TLV is used to indicate the version of the protocol running in the
originator. A DLEP implementation MAY use this information to decide
if the potential session partner is running at a supported level.
The DLEP Version TLV contains the following fields: 7.2. Peer Offer Signal
0 1 2 3 A Peer Offer signal MUST be sent by a DLEP modem in response to a
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 Peer Discovery signal (Section 7.1). Upon receipt, and processing,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ of a Peer Offer signal, the router responds by issuing a TCP connect
|TLV Type =TBD |Length=4 | Major Version | to the address/port combination specified in the received Peer Offer.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minor Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD The Peer Offer signal MUST be sent to the unicast address of the
originator of Peer Discovery.
Length - Length is 4 To construct a Peer Offer signal, the Signal Type value in the signal
header is set to DLEP_PEER_OFFER (value TBD).
Major Version - Major version of the modem or router protocol. The Peer Offer signal MUST contain one of each of the following data
items:
Minor Version - Minor version of the modem or router protocol. o DLEP Version (Section 8.1)
Support of this draft is indicated by setting the Major Version to o Heartbeat Interval (Section 8.5)
'0', and the Minor Version to '7' (e.g. Version 0.7).
10.2 DLEP Port The Peer Offer signal MAY contain one of each of the following data
items:
The DLEP Port TLV is a mandatory TLV in the Peer Offer signal. The o Peer Type (Section 8.4)
DLEP Port TLV is used to indicate the TCP Port number on the DLEP
server available for connections. The receiver MUST use this
information to perform the TCP connect to the DLEP server.
The DLEP Port TLV contains the following fields: o DLEP Port (Section 8.3)
0 1 2 3 The Peer Offer signal MAY contain one or more of any of the following
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 items, with different values:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type =TBD |Length=2 | TCP Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD o IPv4 Address (Section 8.9), with Add/Drop indicator = 1
Length - Length is 2 o IPv6 Address (Section 8.10), with Add/Drop indicator = 1
TCP Port Number - TCP Port number on the DLEP server. If the Peer Offer signal includes a DLEP Port data item, the port
number specified MUST be used to establish the TCP session. If the
DLEP Port number is omitted, the receiver MUST use the DLEP well-
known port number (Section 11.7) to establish the TCP connection.
10.3 Peer Type The IP Address data items indicate the unicast address the receiver
of Peer Offer MUST use when connecting the DLEP TCP session. If
multiple IP Address items are present in the Peer Offer signal,
implementations MAY use their own heuristics to select the address to
connect to. If no IP Address data items are included in the Peer
Offer signal, the receiver MUST use the origin address of the signal
as the IP address to establish the TCP connection.
The Peer Type TLV is an OPTIONAL TLV in both the Peer Discovery and 7.3. Peer Initialization Signal
Peer Offer signals. The Peer Type TLV is used by the router and modem
to give additional information as to its type. The peer type is a
string and is envisioned to be used for informational purposes (e.g.
as output in a display command).
The Peer Type TLV contains the following fields: A Peer Initialization signal MUST be sent by a router as the first
signal 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.
0 1 2 3 If any optional extensions are supported by the implementation, they
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 MUST be enumerated in the Extensions Supported data item. If an
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Extensions Supported data item does NOT exist in a Peer
|TLV Type =TBD |Length= peer |Peer Type String | Initialization signal, the receiver of the signal MUST conclude that
| |type string len| | there is NO support for extensions in the sender.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD If any experimental signals or data items are used by the
implementation, they MUST be enumerated in one or more Experimental
Definition data items. If there are no Experimental Definition data
items in a Peer Initialization signal, the receiver of the signal
MUST conclude that NO experimental definitions are in use by the
sender.
Length - Length of peer type string. To construct a Peer Initialization signal, the Signal Type value in
the signal header is set to DLEP_PEER_INITIALIZATION (value TBD).
Peer Type String - Non-Null terminated string, using UTF-8 encoding. The Peer Initialization signal MUST contain one of each of the
For example, a satellite modem might set this following data items:
variable to 'Satellite terminal'.
10.4 MAC Address o DLEP Version (Section 8.1)
The MAC address TLV MUST appear in all destination-oriented signals o Heartbeat Interval (Section 8.5)
(e.g. Destination Up, Destination Up ACK, Destination Down,
Destination Down ACK, Destination Update, Link Characteristics
Request, and Link Characteristics ACK). The MAC Address TLV contains
the address of the destination on the remote node. The MAC address
MAY be either a physical or a virtual destination. Examples of a
virtual destination would be a multicast MAC address, or the
broadcast MAC (0xFFFFFFFFFFFF).
0 1 2 3 The Peer Initialization signal MAY contain one of each of the
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 following data items:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type =TBD |Length = 6 | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD o Peer Type (Section 8.4)
Length - 6 o Extensions Supported (Section 8.6)
MAC Address - MAC Address of the destination (either physical or The Peer Initialization signal MAY contain one or more of any of the
virtual). following data items, with different values:
10.5 IPv4 Address o Experimental Definition (Section 8.7)
The IPv4 Address TLV is an optional TLV. If supported, it MAY appear 7.4. Peer Initialization ACK Signal
in Destination Up, Destination Update, Peer Initialization, and Peer
Update signals. When included in Destination signals, the IPv4
Address TLV contains the IPv4 address of the destination, as well as
a subnet mask value. In the Peer Update signal, it contains the IPv4
address of the originator of the signal. In either case, the TLV also
contains an indication of whether this is a new or existing address,
or is a deletion of a previously known address.
The IPv4 Address TLV contains the following fields: A Peer Initialization ACK signal MUST be sent in response to a
received Peer Initialization signal (Section 7.3). The Peer
Initialization ACK signal completes the TCP-level DLEP session
establishment; the sender of the signal should transition to an 'in-
session' state when the signal is sent, and the receiver should
transition to the 'in-session' state upon receipt (and successful
parsing) of a Peer Initialization ACK signal.
0 1 2 3 All supported metric data items MUST be included in the Peer
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 Initialization ACK signal, with default values to be used on a
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 'modem-wide' basis. This can be viewed as the modem 'declaring' all
|TLV Type =TBD |Length = 5 | Add/Drop | IPv4 Address | supported metrics at DLEP session initialization. Receipt of any
| | | Indicator | DLEP signal containing a metric data item NOT included in the Peer
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Initialization ACK signal MUST be treated as an error, resulting in
| IPv4 Address | the termination of the DLEP session between router and modem.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD 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 Peer Initialization ACK
signal, the receiver of the signal MUST conclude that there is NO
support for extensions in the sender.
Length - 6 If any experimental signals or data items are used by the
implementation, they MUST be enumerated in one or more Experimental
Definition data items. If there are no Experimental Definition data
items in a Peer Initialization ACK signal, the receiver of the signal
MUST conclude that NO experimental definitions are in use by the
sender.
Add/Drop - Value indicating whether this is a new or existing After the Peer Initialization/Peer Initialization ACK signals have
address (0x01), or a withdrawal of an address (0x02). been successfully exchanged, implementations MUST only utilize
extensions and experimental definitions that are supported by BOTH
peers.
IPv4 Address - The IPv4 address of the destination or peer. To construct a Peer Initialization ACK signal, the Signal Type value
in the signal header is set to DLEP_PEER_INIT_ACK (value TBD).
Subnet Mask - A subnet mask (0-32) to be applied to the IPv4 The Peer Initialization ACK signal MUST contain one of each of the
address. following data items:
10.6 IPv6 Address o DLEP Version (Section 8.1)
The IPv6 Address TLV is an optional TLV. If supported, it MAY be used o Heartbeat Interval (Section 8.5)
in the Destination Up, Destination Update, Peer Initialization, and
Peer Update Signals. When included in Destination signals, this data
item contains the IPv6 address of the destination. In the Peer
Discovery and Peer Update, it contains the IPv6 address of the
originating peer. In either case, the data item also contains an
indication of whether this is a new or existing address, or is a
deletion of a previously known address, as well as a subnet mask.
The IPv6 Address TLV contains the following fields: o Maximum Data Rate (Receive) (Section 8.13)
o Maximum Data Rate (Transmit) (Section 8.14)
0 1 2 3 o Current Data Rate (Receive) (Section 8.15)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type =TBD |Length = 17 | Add/Drop | IPv6 Address |
| | | Indicator | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD o Current Data Rate (Transmit) (Section 8.16)
Length - 17 o Latency (Section 8.17)
Add/Drop - Value indicating whether this is a new or existing The Peer Initialization ACK signal MAY contain one of each of the
address (0x01), or a withdrawal of an address (0x02). following data items:
IPv6 Address - IPv6 Address of the destination or peer. o Status (Section 8.2)
10.7 Maximum Data Rate (Receive) o Peer Type (Section 8.4)
The Maximum Data Rate Receive (MDRR) TLV is a mandatory data item, o Resources (Receive) (Section 8.18)
used in Destination Up, Destination Update, Peer Initialization, Peer
Update, and Link Characteristics ACK Signals to indicate the maximum
theoretical data rate, in bits per second, that can be achieved while
receiving data on the link. When metrics are reported via the signals
listed above, the maximum data rate receive MUST be reported.
0 1 2 3 o Resources (Transmit) (Section 8.19)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type =TBD |Length = 8 | MDRR (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MDRR (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MDRR (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD o Relative Link Quality (Receive) (Section 8.20)
Length - 8
Maximum Data Rate Receive - A 64-bit unsigned number, representing o Relative Link Quality (Transmit) (Section 8.21)
the maximum theoretical data rate, in bits per
second (bps), that can be achieved while
receiving on the link.
10.8 Maximum Data Rate (Transmit) o Extensions Supported (Section 8.6)
The Maximum Data Rate Transmit (MDRT) TLV is a mandatory data item, The Peer Initialization ACK signal MAY contain one or more of any of
used in Destination Up, Destination Update, Peer Initialization, Peer the following data items, with different values:
Update, and Link Characteristics ACK Signals to indicate the maximum
theoretical data rate, in bits per second, that can be achieved while
transmitting data on the link. When metrics are reported via the
signals listed above, the maximum data rate transmit MUST be
reported.
0 1 2 3 o Experimental Definition (Section 8.7)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type =TBD |Length = 8 | MDRT (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MDRT (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MDRT (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD 7.5. Peer Update Signal
Length - 8 A Peer Update signal MAY be sent by a DLEP peer to indicate local
Layer 3 address changes, or for metric changes on a modem-wide basis.
For example, addition of an IPv4 address to the router MAY prompt a
Peer Update signal to its attached DLEP modems. Also, a modem that
changes its Maximum Data Rate for all destinations MAY reflect that
change via a Peer Update signal to its attached router(s).
Maximum Data Rate Transmit - A 64-bit unsigned number, representing Concerning Layer 3 addresses, if the modem is capable of
the maximum theoretical data rate, in bits per understanding and forwarding this information (via proprietary
second (bps), that can be achieved while mechanisms), the address update would prompt any remote DLEP modems
transmitting on the link. (DLEP-enabled modems in a remote node) to issue a Destination Update
signal (Section 7.13) to their local routers with the new (or
deleted) addresses. Modems that do not track Layer 3 addresses
SHOULD silently parse and ignore the Peer Update signal. Modems that
track Layer 3 addresses MUST acknowledge the Peer Update with a Peer
Update ACK signal (Section 7.6). Routers receiving a Peer Update
with metric changes MUST apply the new metric to all destinations
(remote nodes) accessible via the modem. Supporting implementations
are free to employ heuristics to retransmit Peer Update signals. The
sending of Peer Update signals for Layer 3 address changes SHOULD
cease when a either participant (router or modem) determines that the
other implementation does NOT support Layer 3 address tracking.
10.9 Current Data Rate (Receive) If metrics are supplied with the Peer Update signal (e.g., Maximum
Data Rate), these metrics are considered to be modem-wide, and
therefore MUST be applied to all destinations in the information base
associated with the router/modem session.
The Current Data Rate Receive (CDRR) TLV is a mandatory data item, To construct a Peer Update signal, the Signal Type value in the
used in Destination Up, Destination Update, Peer Initialization, Peer signal header is set to DLEP_PEER_UPDATE (value TBD).
Update, Link Characteristics Request, and Link Characteristics ACK
signals to indicate the rate at which the link is currently operating
for receiving traffic. In the case of the Link Characteristics
Request, CDRR represents the desired receive data rate for the link.
When metrics are reported via the signals above (e.g. Destination
Update), the current data rate receive MUST be reported.
The Current Data Rate Receive TLV contains the following fields: The Peer Update signal MAY contain one of each of the following data
items:
0 1 2 3 o Maximum Data Rate (Receive) (Section 8.13)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type =TBD |TLV Flags=0x10 |Length = 8 |CDRR (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CDRR (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CDRR (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD o Maximum Data Rate (Transmit) (Section 8.14)
Length - 8 o Current Data Rate (Receive) (Section 8.15)
Current Data Rate Receive - A 64-bit unsigned number, representing o Current Data Rate (Transmit) (Section 8.16)
the current data rate, in bits per second, that
is currently be achieved while receiving traffic
on the link. When used in the Link
Characteristics Request, CDRR represents the
desired receive rate, in bits per second, on the
link. If there is no distinction between current
and maximum receive data rates, current data
rate receive SHOULD be set equal to the maximum
data rate receive.
10.10 Current Data Rate (Transmit) o Latency (Section 8.17)
The Current Data Rate Receive (CDRT) TLV is a mandatory data item, o Resources (Receive) (Section 8.18)
used in Destination Up, Destination Update, Peer Initialization, Peer
Update, Link Characteristics Request, and Link Characteristics ACK
signals to indicate the rate at which the link is currently operating
for transmitting traffic. In the case of the Link Characteristics
Request, CDRT represents the desired transmit data rate for the link.
When metrics are reported via the signals above (e.g. Destination
Update), the current data rate transmit MUST be reported.
The Current Data Rate Transmit TLV contains the following fields: o Resources (Transmit) (Section 8.19)
0 1 2 3 o Relative Link Quality (Receive) (Section 8.20)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type =TBD |TLV Flags=0x10 |Length = 8 |CDRT (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CDRT (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CDRT (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD o Relative Link Quality (Transmit) (Section 8.21)
Length - 8 The Peer Update signal MAY contain one or more of the following data
items, with different values:
Current Data Rate Transmit - A 64-bit unsigned number, representing o IPv4 Address (Section 8.9)
the current data rate, in bits per second, that
is currently be achieved while transmitting
traffic on the link. When used in the Link
Characteristics Request, CDRT represents the
desired transmit rate, in bits per second, on
the link. If there is no distinction between
current and maximum transmit data rates, current
data rate transmit MUST be set equal to the
maximum data rate transmit.
10.11 Latency o IPv6 Address (Section 8.10)
The Latency TLV is a mandatory data item. It is used in Peer 7.6. Peer Update ACK Signal
Initialization, Destination Up, Destination Update, Peer
Initialization, Peer Update, Link Characteristics Request, and Link
Characteristics ACK signals to indicate the amount of latency on the
link, or in the case of the Link Characteristics Request, to indicate
the maximum latency required on the link.
0 1 2 3 A Peer Update ACK signal MUST be sent by implementations supporting
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 Layer 3 address tracking and/or modem-wide metrics to indicate
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ whether a Peer Update signal (Section 7.5) was successfully
|TLV Type =TBD |Length = 4 | Latency in microseconds | processed. If the Peer Update ACK is issued, it MUST contain a
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Status data item, indicating the success or failure of processing the
| Latency (Cont.) microsecs | received Peer Update.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD To construct a Peer Update ACK signal, the Signal Type value in the
signal header is set to DLEP_PEER_UPDATE_ACK (value TBD).
Length - 4 The Peer Update ACK signal MAY contain one of each of the following
Latency - A 32-bit unsigned value, representing the transmission data items:
delay that a packet encounters as it is transmitted
over the link. In Destination Up, Destination Update,
and Link Characteristics ACK, this value is reported
as delay, in microseconds. The calculation of latency
is implementation dependent. For example, the latency
may be a running average calculated from the internal
queuing. If a device cannot calculate latency, this
TLV SHOUD NOT be issued. In the Link Characteristics
Request Signal, this value represents the maximum
delay, in microseconds, expected on the link.
10.12 Resources (Receive) o Status (Section 8.2)
The Receive Resources TLV is an optional data item. If supported, it A receiver of a Peer Update ACK signal without a Status data item
is used in Destination Up, Destination Update, Peer Initialization, MUST behave as if a Status data item with code 'Success' had been
Peer Update, and Link Characteristics ACK signals to indicate a received.
percentage (0-100) amount of resources (e.g. battery power),
committed to receiving data, remaining on the originating peer.
The Resources TLV contains the following fields: 7.7. Peer Termination Signal
0 1 2 A Peer Termination signal MUST be sent by a DLEP participant when the
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 router/modem session needs to be terminated. Implementations
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ receiving a Peer Termination signal MUST send a Peer Termination ACK
|TLV Type =TBD |Length = 1 | Rcv Resources| signal (Section 7.8) to confirm the termination process. The sender
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ of a Peer Termination signal is free to define its heuristics in
event of a timeout. The receiver of a Peer Termination signal MUST
release all resources allocated for the router/modem session, and
MUST eliminate all destinations in the information base accessible
via the router/modem pair represented by the session. Router and
modem state machines are returned to the 'discovery' state. No
Destination Down signals (Section 7.11) are sent.
TLV Type - TBD To construct a Peer Termination signal, the Signal Type value in the
signal header is set to DLEP_PEER_TERMINATION (value TBD).
Length - 1 The Peer Termination signal MAY contain one of each of the following
data items:
Receive Resources - A percentage, 0-100, representing the amount o Status (Section 8.2)
of remaining resources, such as battery power,
allocated to receiving data. If a device cannot
calculate receive resources, this TLV SHOULD NOT be
issued.
10.13 Resources (Transmit) A receiver of a Peer Termination signal without a Status data item
MUST behave as if a Status data item with status code 'Success' had
been received.
The Transmit Resources TLV is an optional data item. If supported, it 7.8. Peer Termination ACK Signal
is used in Destination Up, Destination Update, Peer Initialization,
Peer Update, and Link Characteristics ACK signals to indicate a
percentage (0-100) amount of resources (e.g. battery power),
committed to transmitting data, remaining on the originating peer.
The Resources TLV contains the following fields: A Peer Termination ACK signal MUST be sent by a DLEP peer in response
to a received Peer Termination signal (Section 7.7). Receipt of a
Peer Termination ACK signal completes the teardown of the router/
modem session.
0 1 2 To construct a Peer Termination ACK signal, the Signal Type value in
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 the signal header is set to DLEP_PEER_TERMINATION_ACK (value TBD).
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type =TBD |Length = 1 | Xmt Resources|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD The Peer Termination ACK signal MAY contain one of each of the
following data items:
Length - 1 o Status (Section 8.2)
Transmit Resources - A percentage, 0-100, representing the amount A receiver of a Peer Termination ACK signal without a Status data
of remaining resources, such as battery power, item MUST behave as if a Status data item with status code 'Success'
allocated to transmitting data. If the transmit had been received.
resources cannot be calculated, then the TLV SHOULD
NOT be issued.
10.14 Relative Link Quality (Receive) 7.9. Destination Up Signal
The Relative Link Quality Receive (RLQR) TLV is an optional data A DLEP participant MUST send a Destination Up signal to report that a
item. If supported, it is used in Peer Initialization, Destination new destination has been detected. A Destination Up ACK signal
Up, Destination Update, Peer Initialization, Peer Update, and Link (Section 7.10) is required to confirm a received Destination Up. A
Characteristics ACK signals to indicate the quality of the link for Destination Up signal can be sent either by the modem, to indicate
receiving data as calculated by the originating peer. that a new remote node has been detected, or by the router, to
indicate the presence of a new logical destination (e.g., a Multicast
group) exists in the network.
The Relative Link Quality (Receive) TLV contains the following The sender of the Destination Up signal is free to define its retry
fields: heuristics in event of a timeout. When a Destination Up signal is
received and successfully processed, the receiver should add
knowledge of the new destination to its information base, indicating
that the destination is accessible via the modem/router pair.
0 1 2 To construct a Destination Up signal, the Signal Type value in the
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 signal header is set to DLEP_DESTINATION_UP (value TBD).
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type =TBD |Length = 1 |RCV Rel. Link |
| | |Quality (RLQR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD The Destination Up signal MUST contain one of each of the following
data items:
Length - 1 o MAC Address (Section 8.8)
Relative Link Quality (Receive) - A non-dimensional number, 1-100, The Destination Up signal MAY contain one of each of the following
representing relative link quality. A value of data items:
100 represents a link of the highest quality.
If a device cannot calculate the RLQR, this
TLV SHOULD NOT be issued.
10.15 Relative Link Quality (Transmit) o Maximum Data Rate (Receive) (Section 8.13)
The Transmit Link Quality Receive (RLQT) TLV is an optional data o Maximum Data Rate (Transmit) (Section 8.14)
item. It is used in Peer Initialization, Destination Up, Destination
Update, Peer Initialization, Peer Update, and Link Characteristics
ACK signals to indicate the quality of the link for transmitting data
as calculated by the originating peer.
The Relative Link Quality (Transmit) TLV contains the following o Current Data Rate (Receive) (Section 8.15)
fields:
0 1 2 o Current Data Rate (Transmit) (Section 8.16)
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type =TBD |Length = 1 |XMT Rel. Link |
| | |Quality (RLQR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD o Latency (Section 8.17)
o Resources (Receive) (Section 8.18)
Length - 1 o Resources (Transmit) (Section 8.19)
Relative Link Quality (Transmit) - A non-dimensional number, 1-100, o Relative Link Quality (Receive) (Section 8.20)
representing relative link quality. A value of
100 represents a link of the highest quality.
If a device cannot calculate the RLQT, this
TLV SHOULD NOT be issued.
10.16 Status o Relative Link Quality (Transmit) (Section 8.21)
The Status TLV is sent as part of an acknowledgement signal, from The Destination Up signal MAY contain one or more of the following
either the modem or the router, to indicate the success or failure of data items, with different values:
a given request.
The Status TLV contains the following fields: o IPv4 Address (Section 8.9)
0 1 2 o IPv6 Address (Section 8.10)
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type =TBD |Length = 1 | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD o IPv4 Attached Subnet (Section 8.11)
Length - 1 o IPv6 Attached Subnet (Section 8.12)
Termination Code - 0 = Success, Non-zero = Failure. Specific values If the sender has IPv4 and/or IPv6 address information for a
of a non-zero termination code depend on the destination it SHOULD include the relevant data items in the
operation requested (e.g. Destination Up, Destination Up signal, reducing the need for the receiver to probe
Destination Down, etc). for any address.
10.17 Heartbeat Interval 7.10. Destination Up ACK Signal
The Heartbeat Interval TLV is a mandatory TLV. It MUST be sent during A DLEP participant MUST send a Destination Up ACK signal to indicate
Peer Initialization to indicate the desired Heartbeat timeout window. whether a Destination Up signal (Section 7.9) was successfully
The receiver MUST either accept the timeout interval supplied by the processed.
sender, or reject the Peer Initialization, and close the socket.
Implementations MUST implement heuristics such that DLEP signals
sent/received reset the timer interval.
The Interval is used to specify a period (in seconds) for Heartbeat To construct a Destination Up ACK signal, the Signal Type value in
Signals (See Section 11.15). By specifying an Interval value of 0, the signal header is set to DLEP_DESTINATION_UP_ACK (value TBD).
implementations MAY indicates the desire to disable Heartbeat signals
entirely (e.g., the Interval is set to an infinite value), however,
it is strongly recommended that implementations use non 0 timer
values.
A DLEP session will be considered inactive, and MUST be torn down, by The Destination Up ACK signal MUST contain one of each of the
an implementation detecting that two (2) Heartbeat intervals have following data items:
transpired without receipt of any DLEP signals.
The Heartbeat Interval TLV contains the following fields: o MAC Address (Section 8.8)
The Destination Up ACK signal MAY contain one of each of the
following data items:
o Status (Section 8.2)
A receiver of a Destination Up ACK signal without a Status data item
MUST behave as if a Status data item with status code 'Success' had
been received.
7.11. Destination Down Signal
A DLEP peer MUST send a Destination Down signal to report when a
destination (a remote node or a multicast group) is no longer
reachable. A Destination Down ACK signal (Section 7.12) MUST be sent
by the recipient of a Destination Down signal to confirm that the
relevant data has been removed from the information base. The sender
of the Destination Down signal is free to define its retry heuristics
in event of a timeout.
To construct a Destination Down signal, the Signal Type value in the
signal header is set to DLEP_DESTINATION_DOWN (value TBD).
The Destination Down signal MUST contain one of each of the following
data items:
o MAC Address (Section 8.8)
7.12. Destination Down ACK Signal
A DLEP participant MUST send a Destination Down ACK signal to
indicate whether a received Destination Down signal (Section 7.11)
was successfully processed. If successfully processed, the sender of
the ACK MUST have removed all entries in the information base that
pertain to the referenced destination.
To construct a Destination Down ACK signal, the Signal Type value in
the signal header is set to DLEP_DESTINATION_DOWN_ACK (value TBD).
The Destination Down ACK signal MUST contain one of each of the
following data items:
o MAC Address (Section 8.8)
The Destination Down ACK signal MAY contain one of each of the
following data items:
o Status (Section 8.2)
A receiver of a Destination Down ACK signal without a Status data
item MUST behave as if a Status data item with status code 'Success'
had been received.
7.13. Destination Update Signal
A DLEP participant SHOULD send the Destination Update signal 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 signal are:
o Change in link metrics (e.g., Data Rates)
o Layer 3 addressing change (for implementations that support it)
To construct a Destination Update signal, the Signal Type value in
the signal header is set to DLEP_DESTINATION_UPDATE (value TBD).
The Destination Update signal MUST contain one of each of the
following data items:
o MAC Address (Section 8.8)
The Destination Update signal MAY contain one of each of the
following data items:
o Maximum Data Rate (Receive) (Section 8.13)
o Maximum Data Rate (Transmit) (Section 8.14)
o Current Data Rate (Receive) (Section 8.15)
o Current Data Rate (Transmit) (Section 8.16)
o Latency (Section 8.17)
o Resources (Receive) (Section 8.18)
o Resources (Transmit) (Section 8.19)
o Relative Link Quality (Receive) (Section 8.20)
o Relative Link Quality (Transmit) (Section 8.21)
The Destination Update signal MAY contain one or more of the
following data items, with different values:
o IPv4 Address (Section 8.9)
o IPv6 Address (Section 8.10)
o IPv4 Attached Subnet (Section 8.11)
o IPv6 Attached Subnet (Section 8.12)
7.14. Heartbeat Signal
A Heartbeat signal SHOULD be sent by a DLEP participant every N
seconds, where N is defined in the Heartbeat Interval field of the
Peer Initialization signal (Section 7.3) or Peer Initialization ACK
signal (Section 7.4). Note that implementations setting the
Heartbeat Interval to 0 effectively set the interval to an infinite
value, therefore, in those cases, this signal SHOULD NOT be sent.
The signal is used by participants to detect when a DLEP session
partner (either the modem or the router) is no longer communicating.
Participants SHOULD allow two (2) heartbeat intervals to expire with
no traffic on the router/modem session before initiating DLEP session
termination procedures.
To construct a Heartbeat signal, the Signal Type value in the signal
header is set to DLEP_PEER_HEARTBEAT (value TBD).
There are no valid data items for the Heartbeat signal.
7.15. Link Characteristics Request Signal
The Link Characteristics Request signal MAY be sent by the router to
request that the modem initiate changes for specific characteristics
of the link. The request can reference either a real (e.g., a remote
node), or a logical (e.g., a multicast group) destination within the
network.
The Link Characteristics Request signal contains either a Current
Data Rate (CDRR or CDRT) data item to request a different datarate
than what is currently allocated, a Latency data item to request that
traffic delay on the link not exceed the specified value, or both. A
Link Characteristics ACK signal (Section 7.16) is required to
complete the request. Issuing a Link Characteristics Request with
ONLY the MAC Address data item is a mechanism a peer MAY use to
request metrics (via the Link Characteristics ACK) from its partner.
The sender of a Link Characteristics Request signal MAY attach a
timer to the request using the Link Characteristics ACK Timer data
item. If a Link Characteristics ACK signal is received after the
timer expires, the sender MUST assume that the request failed.
Implementations are free to define their retry heuristics in event of
a timeout.
To construct a Link Characteristics Request signal, the Signal Type
value in the signal header is set to DLEP_LINK_CHAR_REQ (value TBD).
The Link Characteristics Request signal MUST contain one of each of
the following data items:
o MAC Address (Section 8.8)
The Link Characteristics Request signal MAY contain one of each of
the following data items:
o Link Characteristics ACK Timer (Section 8.22)
o Current Data Rate (Receive) (Section 8.15)
o Current Data Rate (Transmit) (Section 8.16)
o Latency (Section 8.17)
7.16. Link Characteristics ACK Signal
A DLEP participant MUST send a Link Characteristics ACK signal to
indicate whether a received Link Characteristics Request signal
(Section 7.15) was successfully processed. The Link Characteristics
ACK signal SHOULD contain a complete set of metric data items. It
MUST contain the same metric types as the request. The values in the
metric data items in the Link Characteristics ACK signal MUST reflect
the link characteristics after the request has been processed.
If an implementation is not able to alter the characteristics of the
link in the manner requested, then a Status data item with status
code 'Request Denied' MUST be added to the signal.
To construct a Link Characteristics Request ACK signal, the Signal
Type value in the signal header is set to DLEP_LINK_CHAR_ACK (value
TBD).
The Link Characteristics ACK signal MUST contain one of each of the
following data items:
o MAC Address (Section 8.8)
The Link Characteristics ACK signal MAY contain one of each of the
following data items:
o Current Data Rate (Receive) (Section 8.15)
o Current Data Rate (Transmit) (Section 8.16)
o Latency (Section 8.17)
o Resources (Receive) (Section 8.18)
o Resources (Transmit) (Section 8.19)
o Relative Link Quality (Receive) (Section 8.20)
o Relative Link Quality (Transmit) (Section 8.21)
o Status (Section 8.2)
A receiver of a Link Characteristics ACK signal without a Status data
item MUST behave as if a Status data item with status code 'Success'
had been received.
8. DLEP Data Items
Following is the list of MANDATORY data items that must be recognized
by a DLEP compliant implementation. As mentioned before, not all
data items need be used during a session, but an implementation MUST
correctly process these data items when correctly associated with a
signal.
The mandatory DLEP data items are:
+------------+--------------------------------------+---------------+
| Data Item | Description | Section |
+------------+--------------------------------------+---------------+
| TBD | DLEP Version | Section 8.1 |
| TBD | Status | Section 8.2 |
| TBD | DLEP Port | Section 8.3 |
| TBD | Peer Type | Section 8.4 |
| TBD | Heartbeat Interval | Section 8.5 |
| TBD | Extensions Supported | Section 8.6 |
| TBD | Experimental Definition | Section 8.7 |
| TBD | MAC Address | Section 8.8 |
| TBD | IPv4 Address | Section 8.9 |
| TBD | IPv6 Address | Section 8.10 |
| TBD | IPv4 Attached Subnet | Section 8.11 |
| TBD | IPv6 Attached Subnet | Section 8.12 |
| TBD | Maximum Data Rate (Receive) MDRR) | Section 8.13 |
| TBD | Maximum Data Rate (Transmit) (MDRT) | Section 8.14 |
| TBD | Current Data Rate (Receive) (CDRR) | Section 8.15 |
| TBD | Current Data Rate (Transmit) (CDRT) | Section 8.16 |
| TBD | Latency | Section 8.17 |
| TBD | Resources (Receive) (RESR) | Section 8.18 |
| TBD | Resources (Transmit) (REST) | Section 8.19 |
| TBD | Relative Link Quality (Receive) | Section 8.20 |
| | (RLQR) | |
| TBD | Relative Link Quality (Transmit) | Section 8.21 |
| | (RLQT) | |
| TBD | Link Characteristics ACK Timer | Section 8.22 |
+------------+--------------------------------------+---------------+
8.1. DLEP Version
The DLEP Version data item MUST appear in the Peer Discovery
(Section 7.1), Peer Offer (Section 7.2), Peer Initialization
(Section 7.3) and Peer Initialization ACK (Section 7.4) signals The
Version data item is used to indicate the version of the protocol
running in the originator. A DLEP implementation MAY use this
information to decide if the potential session partner is running at
a supported level.
The DLEP Version data item contains the following fields:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type =TBD |Length = 2 | Interval | | Data Item Type| Length = 4 | Major Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minor Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: TBD
TLV Type - TBD Length: 4
Length - 2 Major Version: Major version of the DLEP protocol.
Interval - 0 = Do NOT use heartbeats on this peer-to-peer Minor Version: Minor version of the DLEP protocol.
session. Non-zero = Interval, in seconds, for
heartbeat signals.
10.18 Link Characteristics ACK Timer Support of this draft is indicated by setting the Major Version to
'0', and the Minor Version to '8' (i.e., Version 0.8).
The Link Characteristics ACK Timer TLV is an optional TLV. If 8.2. Status
supported, it MAY be sent during Peer Initialization to indicate the
desired number of seconds to wait for a response to a Link
Characteristics Request. If this TLV is omitted, implementations
supporting the Link Characteristics Request SHOULD choose a default
value.
The Link Characteristics ACK Timer TLV contains the following fields: The Status data item is MAY appear in the Peer Initialization ACK
(Section 7.4), Peer Termination (Section 7.7), Peer Termination ACK
(Section 7.8), Peer Update ACK (Section 7.6), Destination Up ACK
(Section 7.10), Destination Down ACK (Section 7.12) and Link
Characteristics ACK (Section 7.16) signals as part of an
acknowledgement from either the modem or the router, to indicate the
success or failure of the previously received signal.
The Status data item contains the following fields:
0 1 2 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type =TBD |Length = 1 | Interval | | Data Item Type| Length = 1 | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD Data Item Type: TBD
Length - 1 Length: 1
Interval - 0 = Do NOT use timeouts for Link Characteristics Status Code: One of the codes defined below.
requests on this router/modem session. Non-zero =
Interval, in seconds, to wait before considering a
Link Characteristics Request has been lost.
10.19 Credit Window Status +-------------------+-----------------------------------------------+
| Status Code | Reason |
+-------------------+-----------------------------------------------+
| Success | The signal was processed successfully. |
| Unknown Signal | The signal was not recognized by the |
| | implementation. |
| Invalid Signal | One or more data items in the signal are |
| | invalid, unexpected or duplicated. |
| Unexpected Signal | The signal was not expected while the machine |
| | was in this state, e.g., a Peer |
| | Initialization signal after session |
| | establishment. |
| Request Denied | The receiver has not completed the request. |
| Timed Out | The request could not be completed in the |
| | time allowed. |
+-------------------+-----------------------------------------------+
The Credit Window Status TLV is an optional TLV. If credits are 8.3. DLEP Port
supported by the DLEP participants (both the router and the modem),
the Credit Window Status TLV MUST be sent by the participant
receiving a Credit Grant Request for a given destination.
The Credit Window Status TLV contains the following fields: The DLEP Port data item MAY appear in the Peer Offer signal
(Section 7.2). The DLEP Port data item indicates the TCP Port number
on the DLEP server available for connections. If provided, the
receiver MUST use this information to perform the TCP connect to the
DLEP server.
The DLEP Port data item contains the following fields:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type =TBD |Length = 16 | Modem Receive Window Value | | Data Item Type| Length = 2 | TCP Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Modem Receive Window Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Modem Receive Window Value | Router Receive Window Value |
Data Item Type: TBD
Length: 2
TCP Port Number: TCP Port number on the DLEP server.
8.4. Peer Type
The Peer Type data item MAY appear in both the Peer Discovery
(Section 7.1) and Peer Offer (Section 7.2) signals. The Peer Type
data item is used by the router and modem to give additional
information as to its type. The peer type is a string and is
envisioned to 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Receive Window Value | | Data Item Type| Length = peer | Peer Type |
| | type len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Receive Window Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD Data Item Type: TBD
Length - 16 Length: Length of peer type string.
Modem Receive Window Value - A 64-bit unsigned number, indicating Peer Type: UTF-8 encoded string. For example, a satellite modem
the current (or initial) number of might set this variable to "Satellite terminal".
credits available on the Modem Receive
Window.
Router Receive Window Value - A 64-bit unsigned number, indicating An implementation MUST NOT assume the Peer Type is NUL-terminated.
the current (or initial) number of
credits available on the Router Receive
Window.
10.20 Credit Grant Request 8.5. Heartbeat Interval
The Credit Grant Request TLV is an optional TLV. If credits are The Heartbeat Interval data item MUST appear in the Peer Discovery
supported, the Credit Grant Request TLV is sent from a DLEP (Section 7.1), Peer Offer (Section 7.2), Peer Initialization
participant to grant an increment to credits on a window. The Credit (Section 7.3) and Peer Initialization ACK (Section 7.4) signals to
Grant TLV is sent as a data item in either the Destination Up or indicate the desired Heartbeat timeout window. The receiver MUST
Destination Update signals. The value in a Credit Grant TLV either accept the timeout interval supplied by the sender, or reject
represents an increment to be added to any existing credits available the Peer Initialization, and close the socket. Implementations MUST
on the window. Upon successful receipt and processing of a Credit implement heuristics such that DLEP signals sent/received reset the
Grant TLV, the receiver MUST respond with a signal containing a timer interval.
Credit Window Status TLV to report the updated aggregate values for
synchronization purposes.
In the Destination Up signal, when credits are desired, the The Interval is used to specify a period (in seconds) for Heartbeat
originating peer MUST set the initial credit value of the window it signals (Section 7.14). By specifying an Interval value of 0,
controls (e.g. the Modem Receive Window, or Router Receive Window) to implementations MAY indicates the desire to disable Heartbeat signals
an initial, non-zero value. If the receiver of a Destination Up entirely (i.e., the Interval is set to an infinite value), however,
signal with a Credit Grant Request TLV supports credits, the receiver it is strongly recommended that implementations use non 0 timer
MUST either reject the use of credits, via a Destination Up ACK values.
response with the correct Status TLV, or set the initial value from
the data contained in the Credit Window Status TLV. If the
initialization completes successfully, the receiver MUST respond to
the Destination Up signal with a Destination Up ACK signal that
contains a Credit Window Status TLV, initializing its receive window.
The Credit Grant TLV contains the following fields: A DLEP session will be considered inactive, and MUST be torn down, by
an implementation detecting that two (2) Heartbeat intervals have
transpired without receipt of any DLEP signals.
The Heartbeat Interval data item contains the following fields:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type =TBD |Length = 8 | Credit Increment | | Data Item Type| Length = 2 | Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit Increment | Data Item Type: TBD
Length: 2
Interval: 0 = Do NOT use heartbeats on this peer-to-peer session.
Non-zero = Interval, in seconds, for heartbeat signals.
8.6. Extensions Supported
The Extensions Supported data item MAY be used in both the Peer
Initialization and Peer Initialization ACK signals. 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 DLEP Extensions repository.
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 = No. | Extensions List |
| | of values | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit Increment |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD Data Item Type: TBD
Length - 8
Reserved - A 64-bit unsigned number representing the Length: Number of Extensions supported.
additional credits to be assigned to the credit
window. Since credits can only be granted by the
receiver on a window, the applicable credit window
(either the MRW or the RRW) is derived from the
sender of the grant. The Credit Increment MUST NOT
cause the window to overflow; if this condition
occurs, implementations MUST set the credit window
to the maximum value contained in a 64-bit
quantity.
10.21 Credit Request Extension List: A list of extensions supported, identified by their
1-octet value as listed in the extensions registry.
The Credit Request TLV is an optional TLV. If credits are supported, 8.7. Experimental Definition
the Credit Request TLV MAY be sent from either DLEP participant, via
a Destination Update signal, to indicate the desire for the partner
to grant additional credits in order for data transfer to proceed on
the session. If the corresponding Destination Up signal for this
session did NOT contain a Credit Window Status TLV, indicating that
credits are to be used on the session, then the Credit Request TLV
MUST be rejected by the receiver via a Destination Update ACK signal.
The Credit Request TLV contains the following fields: The Experimental Definition data item MAY be used in both the Peer
Initialization and Peer Initialization ACK signals. The Experimental
Definition data item is used by the router and modem to indicate the
formats to be used for experimental signals and data items for the
given peer session. The formats are identified by using a string
that matches the 'name' given to the experiment.
0 1 2 The Experimental Definition item contains the following fields:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type =TBD |Length = 1 | Reserved, MUST|
| | | be set to 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD 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 = len. | Experiment Name |
| | of Experiment | |
| | name | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length - 1 Data Item Type: TBD
Reserved - This field is currently unused and MUST be set to 0. Length: Length of the name string for the Experiment.
10.22 DLEP Optional Signals Supported Experiment Name: UTF-8 encoded string, containing the name of the
experiment being utilized.
The DLEP Optional Signals Supported TLV is a mandatory data item. If An implementation receiving this data item MUST compare the received
optional signals (e.g., the Link Characteristics Request Signal) are string to a list of experiments that it supports. An implementation
supported, they MUST be enumerated with this data item inserted into MUST NOT assume the Experiment Name is NUL-terminated.
the Peer Initialization and Peer Initialization ACK signals. Failure
to indicate optional signals indicates to a receiving peer that the
sending implementation ONLY supports the core (mandatory) items
listed in this specification. Optional signals that are NOT
enumerated in this data item when issuing Peer Initialization or Peer
Initialization ACK MUST NOT be used during the DLEP session.
The DLEP Optional Signals Supported TLV contains the following 8.8. MAC Address
fields:
The MAC address data item MUST appear in all destination-oriented
signals (i.e., Destination Up (Section 7.9), Destination Up ACK
(Section 7.10), Destination Down (Section 7.11), Destination Down ACK
(Section 7.12), Destination Update (Section 7.13), Link
Characteristics Request (Section 7.15), and Link Characteristics ACK
(Section 7.16)). The MAC Address data item contains the address of
the destination on the remote node. The MAC address MAY be either a
physical or a virtual destination. Examples of a virtual destination
would be a multicast MAC address, or the broadcast MAC
(FF:FF:FF:FF:FF:FF).
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type =TBD |Length = 2 + |List of optional signals ... | | Data Item Type| Length = 6 | MAC Address |
| |number of opt. | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |signals. | | | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD Data Item Type: TBD
Length - 2 + the number of optional signals supported Length: 6
List - An enumeration of the optional signal TLV Types
supported by the implementation.
10.23 DLEP Optional Data Items Supported MAC Address: MAC Address of the destination (either physical or
virtual).
The DLEP Optional Data Items Supported TLV is a mandatory data item. 8.9. IPv4 Address
If optional data items (e.g., Resources) are supported, they MUST be
enumerated with this data item inserted into the Peer Initialization
and Peer Initialization ACK signals. Failure to indicate optional
data items indicates to a receiving peer that the sending
implementation ONLY supports the core (mandatory) data items listed
in this specification. Optional data items that are NOT listed in
this data item MUST NOT be used during the DLEP session.
The DLEP Optional Data Items Supported TLV contains the following The IPv4 Address data item MUST appear in the Peer Offer signal
fields: (Section 7.2), and MAY appear in the Peer Update (Section 7.5),
Destination Up (Section 7.9) and Destination Update (Section 7.13)
signals. When included in Destination signals, this data item
contains the IPv4 address of the destination. In the Peer Offer
signal, it contains the IPv4 address of the originating peer to be
used to establish a DLEP session. In either case, the data item also
contains an indication of whether this is a new or existing address,
or is a deletion of a previously known address. When used in a Peer
Offer signal the Add/Drop Indicator MUST be 1 (i.e. Add).
The IPv4 Address data item contains the following fields:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type =TBD |Length = 2 + |List of optional data items ...| | Data Item Type| Length = 5 | Add/Drop | IPv4 Address |
| |number of opt. | | | | | Indicator | |
| |signals. | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD Data Item Type: TBD
Length - 2 + the number of optional data items supported Length: 5
List - An enumeration of the optional data item TLV Types
supported by the implementation.
10.24 DLEP Vendor Extension Add/Drop: Value indicating whether this is a new or existing address
(1), or a withdrawal of an address (0).
The DLEP Vendor Extension data item is an optional data item, and IPv4 Address: The IPv4 address of the destination or peer.
allows for vendor-defined information to be passed between DLEP
participants. The precise data carried in the payload portion of the
data item is vendor-specific, however, the payload MUST adhere to a
Type-Length-Value format. This optional data item is ONLY valid on
Peer Initialization ACK, and if present, SHOULD contain device-
specific information geared to optimizing data transmission/reception
over the modem's link.
The DLEP Vendor Extension Data Item TLV contains the following 8.10. IPv6 Address
fields:
The IPv6 Address data item MUST appear in the Peer Offer signal
(Section 7.2), and MAY appear in the Peer Update (Section 7.5),
Destination Up (Section 7.9) and Destination Update (Section 7.13)
signals. When included in Destination signals, this data item
contains the IPv6 address of the destination. In the Peer Offer
signal, it contains the IPv6 address of the originating peer to be
used to establish a DLEP session. In either case, the data item also
contains an indication of whether this is a new or existing address,
or is a deletion of a previously known address. When used in a Peer
Offer signal the Add/Drop Indicator MUST be 1 (i.e. Add).
The IPv6 Address data item contains the following fields:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type = TBD | Length |OUI Length | Vendor OUI... | | Data Item Type| Length = 17 | Add/Drop | IPv6 Address |
| | | Indicator | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI TLV Subtype | Payload... | | IPv6 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD Data Item Type: TBD
Length - 3 + length of OUI (in octets) + payload length
Vendor OUI - The vendor OUI, as specified in [IEEE] Length: 17
OUI TLV Subtype - A 16-bit quantity, intended to indicate the Add/Drop: Value indicating whether this is a new or existing address
specific device. (1), or a withdrawal of an address (0).
Payload - Vendor-specific payload, formatted as Type, Length, IPv6 Address: IPv6 Address of the destination or peer.
Value construct(s).
10.25 IPv4 Attached Subnet 8.11. IPv4 Attached Subnet
The DLEP IPv4 Attached Subnet is an optional data item, and allows a The DLEP IPv4 Attached Subnet allows a device to declare that it has
device to declare that it has an IPv4 subnet (e.g., a stub network) an IPv4 subnet (e.g., a stub network) attached. Once an IPv4 Subnet
attached. If supported, the DLEP IPv4 Attached Subnet TLV is allowed has been declared on a device, the declaration can NOT be withdrawn
ONLY in the DLEP "Destination Up" signal, and MUST NOT appear more without terminating the destination (via the Destination Down signal)
than once. All other occurrences of the DLEP IPv4 Attached Subnet TLV and re-issuing the Destination Up signal.
MUST be treated as an error. Once an IPv4 Subnet has been declared by
a device, the declaration can NOT be withdrawn without terminating
the destination (via the "Destination Down" signal) and re-issuing
the "Destination Up" signal.
The DLEP IPv4 Attached Subnet data item TLV contains the following The DLEP IPv4 Attached Subnet data item data item contains the
fields: following fields:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type =TBD | Length = 5 | IPv4 Attached Subnet | |Data Item Type | Length = 5 | IPv4 Attached Subnet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Attached Subnet | Subnet Mask | | IPv4 Attached Subnet | Subnet Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD Data Item Type: TBD
Length - 5 Length: 5
IPv4 Subnet - The IPv4 subnet reachable at the destination. IPv4 Subnet: The IPv4 subnet reachable at the destination.
Subnet Mask - A subnet mask (0-32) to be applied to the IPv4 Subnet Mask: A subnet mask (0-32) to be applied to the IPv4 subnet.
subnet.
10.26 IPv6 Attached Subnet 8.12. IPv6 Attached Subnet
The DLEP IPv6 Attached Subnet is an optional data item, and allows a The DLEP IPv6 Attached Subnet allows a device to declare that it has
device to declare that it has an IPv6 subnet (e.g., a stub network) an IPv6 subnet (e.g., a stub network) attached. As in the case of
attached. If supported, the DLEP IPv6 Attached Subnet TLV is allowed the IPv4 attached Subnet data item above, once an IPv6 attached
ONLY in the DLEP "Destination Up" signal, and MUST NOT appear more subnet has been declared, it can NOT be withdrawn without terminating
than once. All other occurrences of the DLEP IPv6 Attached Subnet TLV the destination (via Destination Down) and re-issuing the Destination
MUST be treated as an error. As in the case of the IPv4 attached Up signal.
subnet, once an IPv6 attached subnet has been declared, it can NOT be
withdrawn without terminating the destination (via "Destination
Down") and re-issuing the "Destination Up" signal.
The DLEP IPv6 Attached Subnet data item TLV contains the following The DLEP IPv6 Attached Subnet data item data item contains the
fields: following fields:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TLV Type =TBD |Length = 17 | IPv6 Attached Subnet | | Data Item Type| Length = 17 | IPv6 Attached Subnet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Attached Subnet | | IPv6 Attached Subnet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Attached Subnet | | IPv6 Attached Subnet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Attached Subnet | | IPv6 Attached Subnet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Attached Subnet | Subnet Mask | | IPv6 Attached Subnet | Subnet Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Type - TBD
Length - 17 Data Item Type: TBD
IPv4 Subnet - The IPv6 subnet reachable at the destination. Length: 17
Subnet Mask - A subnet mask (0-128) to be applied to the IPv6 IPv4 Subnet: The IPv6 subnet reachable at the destination.
subnet.
11. DLEP Protocol Signals Subnet Mask: A subnet mask (0-128) to be applied to the IPv6 subnet.
DLEP signals are encoded as a string of Type-Length-Value (TLV) 8.13. Maximum Data Rate (Receive)
constructs. The first TLV in a DLEP signal MUST be a valid DLEP
signal, as defined in section 11.1 of this document. Following the The Maximum Data Rate (Receive) (MDRR) data item MUST appear in the
signal TLV is 0 or more TLVs, representing the data items that are Peer Initialization ACK signal (Section 7.4), and MAY appear in the
appropriate for the signal. The layout of a DLEP signal is thus: Peer Update (Section 7.5), Destination Up (Section 7.9) and
Destination Update (Section 7.13) signals to indicate the maximum
theoretical data rate, in bits per second, that can be achieved while
receiving data on the link.
The Maximum Data Rate (Receive) data item contains the following
fields:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLEP Signal |DLEP Signal length (length of |Start of DLEP | | Data Item Type| Length = 8 | MDRR (bps) |
| Type value |all data items) |data item TLVs |
| (value TBD) | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MDRR (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MDRR (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All DLEP signals begin with this structure. Therefore, in the Data Item Type: TBD
following descriptions of specific signals, this header structure is
assumed, and will not be replicated.
11.1 Signal TLV Values Length: 8
As mentioned above, all DLEP signals begin with the Type value. Valid Maximum Data Rate (Receive): A 64-bit unsigned integer, representing
DLEP signals are: the maximum theoretical data rate, in bits per second (bps), that
can be achieved while receiving on the link.
TLV TLV 8.14. Maximum Data Rate (Transmit)
Value Description
=========================================
TBD Peer Discovery
TBD Peer Offer
TBD Peer Initialization
TBD Peer Update
TBD Peer Update ACK
TBD Peer Termination
TBD Peer Termination ACK
TBD Destination Up
TBD Destination Up ACK
TBD Destination Down
TBD Destination Down ACK
TBD Destination Update
TBD Heartbeat
TBD Link Characteristics Request
TBD Link Characteristics ACK
11.2 Peer Discovery Signal The Maximum Data Rate (Transmit) (MDRT) data item MUST appear in the
Peer Initialization ACK signal (Section 7.4), and MAY appear in the
Peer Update (Section 7.5), Destination Up (Section 7.9) and
Destination Update (Section 7.13) signals to indicate the maximum
theoretical data rate, in bits per second, that can be achieved while
transmitting data on the link.
The Peer Discovery Signal is sent by a router to discover DLEP The Maximum Data Rate (Transmit) data item contains the following
routers in the network. The Peer Offer signal is required to complete fields:
the discovery process. Implementations MAY implement their own retry
heuristics in cases where it is determined the Peer Discovery Signal
has timed out.
To construct a Peer Discovery signal, the initial TLV Type value is 0 1 2 3
set to DLEP_PEER_DISCOVERY (value TBD). The signal TLV MUST be 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
followed by the mandatory Data Item TLVs. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type| Length = 8 | MDRT (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MDRT (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MDRT (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mandatory Data Item TLVs: Data Item Type: TBD
- DLEP Version
- Heartbeat Interval
There are NO optional data items for the Peer Discovery signal.
11.3 Peer Offer Signal Length: 8
The Peer Offer Signal is sent by a DLEP modem in response to a Peer Maximum Data Rate (Transmit): A 64-bit unsigned integer,
Discovery Signal. Upon receipt, and processing, of a Peer Offer representing the maximum theoretical data rate, in bits per second
signal, the router responds by issuing a TCP connect to the (bps), that can be achieved while transmitting on the link.
address/port combination specified in the received Peer Offer.
The Peer Offer signal MUST be sent to the unicast address of the 8.15. Current Data Rate (Receive)
originator of Peer Discovery.
To construct a Peer Offer signal, the initial TLV type value is set The Current Data Rate (Receive) (CDRR) data item MUST appear in the
to DLEP_PEER_OFFER (value TBD). The signal TLV is then followed by Peer Initialization ACK signal (Section 7.4), and MAY appear in the
all mandatory Data Item TLVs, then by any optional Data Item TLVs the Peer Update (Section 7.5), Destination Up (Section 7.9), Destination
implementation supports: Update (Section 7.13), Link Characteristics Request (Section 7.15)
and Link Characteristics ACK (Section 7.16) signals to indicate the
rate at which the link is currently operating for receiving traffic.
When used in the Link Characteristics Request signal, CDRR represents
the desired receive rate, in bits per second, on the link.
Mandatory Data Item TLVs: The Current Data Rate (Receive) data item contains the following
- DLEP Version fields:
- Heartbeat Interval
- At least one (1) IPv4 or IPv6 Address TLV
- DLEP Port
Optional Data Item TLVs: 0 1 2 3
- Peer Type 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
- Status +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type| Length = 8 | CDRR (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CDRR (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CDRR (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
11.4 Peer Initialization Signal Data Item Type: TBD
The Peer Initialization signal is sent by a router to start the DLEP Length: 8
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. If any optional signals
or data items are supported by the implementation, they MUST be
enumerated in the DLEP Optional Signals Supported and DLEP Optional
Data Items Supported items.
Mandatory Data Item TLVs: Current Data Rate (Receive): A 64-bit unsigned integer, representing
- DLEP Version the current data rate, in bits per second, that is currently be
- Heartbeat Interval achieved while receiving traffic on the link.
- Optional Signals Supported
- Optional Data Items Supported
Optional Data Item TLVs:
- Peer Type
If the Optional Signals Supported (or the Optional Data Items
Supported) TLV is absent in Peer Initialization, the receiver of the
signal MUST conclude that there is NO optional support in the
sender.
11.5 Peer Initialization ACK Signal If there is no distinction between current and maximum receive data
rates, current data rate receive MUST be set equal to the maximum
data rate receive.
The Peer Initialization ACK signal is a mandatory signal, sent in 8.16. Current Data Rate (Transmit)
response to a received Peer Initialization signal. The Peer
Initialization ACK signal completes the TCP-level DLEP session
establishment; the sender of the signal should transition to an "in-
session" state when the signal is sent, and the receiver should
transition to the "in-session" state upon receipt (and successful
parsing) of Peer Initialization ACK.
All supported metric data items MUST be included in the Peer The Current Data Rate Receive (CDRT) data item MUST appear in the
Initialization ACK signal, with default values to be used on a Peer Initialization ACK signal (Section 7.4), and MAY appear in the
"modem-wide" basis. This can be viewed as the modem "declaring" all Peer Update (Section 7.5), Destination Up (Section 7.9), Destination
supported metrics at DLEP session initialization. Receipt of any DLEP Update (Section 7.13), Link Characteristics Request (Section 7.15)
signal containing a metric data item NOT included in Peer and Link Characteristics ACK (Section 7.16) signals to indicate the
Initialization ACK MUST be treated as an error, resulting in rate at which the link is currently operating for transmitting
termination of the DLEP session between router and modem. If optional traffic. When used in the Link Characteristics Request signal, CDRT
signals and/or data items are supported by the modem, they MUST be represents the desired transmit rate, in bits per second, on the
enumerated in the DLEP Optional Signals supported and DLEP Optional link.
data items supported TLVs.
The Peer Initialization ACK signal MAY contain the DLEP Vendor The Current Data Rate (Transmit) data item contains the following
Extension data item, as documented in section 10.22 fields:
After the Peer Initialization/Peer Initialization ACK signals have 0 1 2 3
been successfully exchanged, implementations SHOULD only utilize 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
options that are supported in BOTH peers (e.g. router and modem). Any +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
attempt by a DLEP session peer to send an optional signal to a peer | Data Item Type| Length = 8 | CDRT (bps) |
without support MUST result in an error which terminates the session. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Any optional data item sent to a peer without support will be ignored | CDRT (bps) |
and silently dropped. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CDRT (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
To construct a Peer Initialization ACK signal, the initial TLV type Data Item Type: TBD
value is set to DLEP_PEER_INIT_ACK (value TBD). The signal TLV is
then followed by the required data items:
Mandatory Data Item TLVs: Length: 8
- DLEP Version
- Heartbeat Interval
- Maximum Data Rate Receive
- Maximum Data Rate Transmit
- Current Data Rate Receive
- Current Data Rate Transmit
- DLEP Optional Signals Supported
- DLEP Optional Data Items Supported
- Status
Optional Data Item TLVs:
- Peer Type
- DLEP Vendor Extension
- Latency
- Relative Link Quality Receive
- Relative Link Quality Transmit
- Resources (Receive)
- Resources (Transmit)
11.6 Peer Update Signal Current Data Rate (Transmit): A 64-bit unsigned integer,
representing the current data rate, in bits per second, that is
currently be achieved while transmitting traffic on the link.
The Peer Update signal is an optional signal, sent by a DLEP peer to If there is no distinction between current and maximum transmit data
indicate local Layer 3 address changes, or for metric changes on a rates, current data rate transmit MUST be set equal to the maximum
modem-wide basis. For example, addition of an IPv4 address to the data rate transmit.
router MAY prompt a Peer Update signal to its attached DLEP modems.
Also, a modem that changes its Maximum Data Rate for all destinations
MAY reflect that change via a Peer Update Signal to its attached
router(s).
Concerning Layer 3 addresses, if the modem is capable of 8.17. Latency
understanding and forwarding this information (via proprietary
mechanisms), the address update would prompt any remote DLEP modems
(DLEP-enabled modems in a remote node) to issue a "Destination
Update" signal to their local routers with the new (or deleted)
addresses. Modems that do not track Layer 3 addresses SHOULD silently
parse and ignore the Peer Update Signal. Modems that track Layer 3
addresses MUST acknowledge the Peer Update with a Peer Update ACK
signal. Routers receiving a Peer Update with metric changes MUST
apply the new metric to all destinations (remote nodes) accessible
via the modem. Supporting implementations are free to employ
heuristics to retransmit Peer Update signals. The sending of Peer
Update Signals for Layer 3 address changes SHOULD cease when a either
participant (router or modem) determines that the other
implementation does NOT support Layer 3 address tracking.
If metrics are supplied with the Peer Update signal (e.g. Maximum The Latency data item data item MUST appear in the Peer
Data Rate), these metrics are considered to be modem-wide, and Initialization ACK signal (Section 7.4), and MAY appear in the Peer
therefore MUST be applied to all destinations in the information base Update (Section 7.5), Destination Up (Section 7.9), Destination
associated with the router/modem session. Update (Section 7.13), Link Characteristics Request (Section 7.15)
and Link Characteristics ACK (Section 7.16) signals to indicate the
amount of latency, in microseconds, on the link, or in the case of
the Link Characteristics Request, to indicate the maximum latency
required on the link.
To construct a Peer Update signal, the initial TLV type value is set The Latency value is reported as delay. The calculation of latency
to DLEP_PEER_UPDATE (value TBD). The Signal TLV is followed by any is implementation dependent. For example, the latency may be a
OPTIONAL Data Item TLVs. running average calculated from the internal queuing.
Optional Data Item TLVs: 0 1 2 3
- IPv4 Address 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
- IPv6 Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Maximum Data Rate (Receive) | Data Item Type| Length = 4 | Latency in microseconds |
- Maximum Data Rate (Transmit) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Current Data Rate (Receive) | Latency (cont.) microsecs |
- Current Data Rate (Transmit) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Latency Data Item Type: TBD
- Resources (Receive)
- Resources (Transmit)
- Relative Link Quality (Receive)
- Relative Link Quality (Transmit)
11.7 Peer Update ACK Signal Length: 4
The Peer Update ACK signal is an optional signal, and is sent by Latency: A 32-bit unsigned value, representing the transmission
implementations supporting Layer 3 address tracking and/or modem-wide delay that a packet encounters as it is transmitted over the link.
metrics to indicate whether a Peer Update Signal was successfully
processed. If the Peer Update ACK is issued, it MUST contain a Status
data item, indicating the success or failure of processing the
received Peer Update.
To construct a Peer Update ACK signal, the initial TLV type value is 8.18. Resources (Receive)
set to DLEP_PEER_UPDATE_ACK (value TBD). The Status data item TLV is
placed in the packet next, completing the Peer Update ACK.
Mandatory Data Item TLVs: The Resources (Receive) (RESR) data item MAY appear in the Peer
Initialization ACK signal (Section 7.4), Peer Update (Section 7.5),
Destination Up (Section 7.9), Destination Update (Section 7.13) and
Link Characteristics ACK (Section 7.16) signals to indicate the
amount of recources for reception (with 0 meaning 'no resources
available', and 100 meaning 'all resources available') at the
destination. The list of resources that might be considered is
beyond the scope of this document, and is left to implementations to
decide.
- Status The Resources (Receive) data item contains the following fields:
Note that there are NO optional data item TLVs specified for this 0 1 2
signal. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type| Length = 1 | RESR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
11.8 Peer Termination Signal Data Item Type: TBD
The Peer Termination Signal is sent by a DLEP participant when the Length: 1
router/modem session needs to be terminated. Implementations
receiving a Peer Termination signal MUST send a Peer Termination ACK
signal to confirm the termination process. The sender of a Peer
Termination signal is free to define its heuristics in event of a
timeout. The receiver of a Peer Termination Signal MUST release all
resources allocated for the router/modem session, and MUST eliminate
all destinations in the information base accessible via the
router/modem pair represented by the session. Router and modem state
machines are returned to the "discovery" state. No Destination Down
signals are sent.
To construct a Peer Termination signal, the initial TLV type value is Resources (Receive): A percentage, 0-100, representing the amount of
set to DLEP_PEER_TERMINATION (value TBD). The signal TLV is followed resources allocated to receiving data.
by any OPTIONAL Data Item TLVs the implementation supports:
Optional Data Item TLVs: If a device cannot calculate RESR, this data item SHOULD NOT be
issued.
- Status 8.19. Resources (Transmit)
11.9 Peer Termination ACK Signal The Resources (Receive) (RESR) data item MAY appear in the Peer
Initialization ACK signal (Section 7.4), Peer Update (Section 7.5),
Destination Up (Section 7.9), Destination Update (Section 7.13) and
Link Characteristics ACK (Section 7.16) signals to indicate the
amount of recources for transmission (with 0 meaning 'no resources
available', and 100 meaning 'all resources available') at the
destination. The list of resources that might be considered is
beyond the scope of this document, and is left to implementations to
decide.
The Peer Termination Signal ACK is sent by a DLEP peer in response to The Resources (Transmit) data item contains the following fields:
a received Peer Termination order. Receipt of a Peer Termination ACK
signal completes the teardown of the router/modem session.
To construct a Peer Termination ACK signal, the initial TLV type 0 1 2
value is set to DLEP_PEER_TERMINATION_ACK (value TBD). The 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
Identification data item TLV is placed in the packet next, followed +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
by any OPTIONAL TLVs the implementation supports: | Data Item Type| Length = 1 | REST |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Optional Data Item TLVs: Data Item Type: TBD
- Status Length: 1
11.10 Destination Up Signal Resources (Transmit): A percentage, 0-100, representing the amount
of resources allocated to transmitting data.
A DLEP participant sends the Destination Up signal to report that a If a device cannot calculate REST, this data item SHOULD NOT be
new destination has been detected. A Destination Up ACK Signal is issued.
required to confirm a received Destination Up. A Destination Up
signal can be sent either by the modem, to indicate that a new remote
node has been detected, or by the router, to indicate the presence of
a new logical destination (e.g., a Multicast group) exists in the
network.
The sender of the Destination Up Signal is free to define its retry 8.20. Relative Link Quality (Receive)
heuristics in event of a timeout. When a Destination Up signal is
received and successfully parsed, the receiver should add knowledge
of the new destination to its information base, indicating that the
destination is accessible via the modem/router pair.
To construct a Destination Up signal, the initial TLV type value is The Relative Link Quality (Receive) (RLQR) data item MAY appear in
set to DLEP_DESTINATION_UP (value TBD). The MAC Address data item TLV the Peer Initialization ACK signal (Section 7.4), Peer Update
is placed in the packet next, followed by any supported optional Data (Section 7.5), Destination Up (Section 7.9), Destination Update
Item TLVs into the packet: (Section 7.13) and Link Characteristics ACK (Section 7.16) signals to
indicate the quality of the link for receiving data as calculated by
the originating peer.
Optional Data Item TLVs: The Relative Link Quality (Receive) data item contains the following
fields:
- IPv4 Address 0 1 2
- IPv6 Address 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
- Maximum Data Rate (Receive) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Maximum Data Rate (Transmit) | Data Item Type| Length = 1 | RLQR |
- Current Data Rate (Receive) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Current Data Rate (Transmit)
- Latency
- Resources (Receive)
- Resources (Transmit)
- Relative Link Factor (Receive)
- Relative Link Factor (Transmit)
- Credit Window Status
- IPv4 Attached Subnet
- IPv6 Attached Subnet
11.11 Destination Up ACK Signal Data Item Type: TBD
A DLEP participant sends the Destination Up ACK Signal to indicate Length: 1
whether a Destination Up Signal was successfully processed.
To construct a Destination Up ACK signal, the initial TLV type value Relative Link Quality (Receive): A non-dimensional integer, 1-100,
is set to DLEP_DESTINATION_UP_ACK (value TBD). The MAC Address data representing relative link quality. A value of 100 represents a
item TLV is placed in the packet next, containing the MAC address of link of the highest quality.
the DLEP destination. The implementation would then place any
supported optional Data Item TLVs into the packet:
Optional Data Item TLVs: If a device cannot calculate the RLQR, this data item SHOULD NOT be
- Credit Window Status issued.
11.12 Destination Down Signal 8.21. Relative Link Quality (Transmit)
A DLEP peer sends the Destination Down signal to report when a The Relative Link Quality (Transmit) (RLQT) data item MAY appear in
destination (a remote node or a multicast group) is no longer the Peer Initialization ACK signal (Section 7.4), Peer Update
reachable. The Destination Down signal MUST contain the MAC Address (Section 7.5), Destination Up (Section 7.9), Destination Update
data item TLV. Other TLVs as listed are OPTIONAL, and MAY be present (Section 7.13) and Link Characteristics ACK (Section 7.16) signals to
if an implementation supports them. A Destination Down ACK Signal indicate the quality of the link for transmitting data as calculated
MUST be sent by the recipient of a Destination Down signal to confirm by the originating peer.
that the relevant data has been removed from the information base.
The sender of the Destination Down signal is free to define its retry
heuristics in event of a timeout.
To construct a Destination Down signal, the initial TLV type value is The Relative Link Quality (Transmit) data item contains the following
set to DLEP_DESTINATION_DOWN (value TBD). The signal TLV is followed fields:
by the mandatory MAC Address data item TLV.
Note that there are NO OPTIONAL data item TLVs for this signal. 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type| Length = 1 | RLQT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
11.13 Destination Down ACK Signal Data Item Type: TBD
A DLEP participant sends the Destination Down ACK Signal to indicate Length: 1
whether a received Destination Down Signal was successfully
processed. If successfully processed, the sender of the ACK MUST have
removed all entries in the information base that pertain to the
referenced destination. As with the Destination Down signal, there
are NO OPTIONAL Data Item TLVs defined for the Destination Down ACK
signal.
To construct a Destination Down signal, the initial TLV type value is Relative Link Quality (Transmit): A non-dimensional integer, 1-100,
set to DLEP_DESTINATION_DOWN_ACK (value TBD). The mandatory data item representing relative link quality. A value of 100 represents a
TLVs follow: link of the highest quality.
- MAC Address Data item If a device cannot calculate the RLQT, this data item SHOULD NOT be
- Status data item issued.
11.14 Destination Update Signal 8.22. Link Characteristics ACK Timer
A DLEP participant sends the Destination Update signal when it The Link Characteristics ACK Timer data item MAY appear in the Link
detects some change in the information base for a given destination Characterisitics Request signal (Section 7.15) to indicate the
(remote node or multicast group). Some examples of changes that would desired number of seconds to the sender will wait for a response to
prompt a Destination Update signal are: the request. If this data item is omitted, implementations
supporting the Link Characteristics Request SHOULD choose a default
value.
- Change in link metrics (e.g., Data Rates) The Link Characteristics ACK Timer data item contains the following
- Layer 3 addressing change (for implementations that support it) fields:
To construct a Destination Update signal, the initial TLV type value 0 1 2
is set to DLEP_DESTINATION_UPDATE (value TBD). Following the signal 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
TLV are the mandatory Data Item TLVs: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type| Length = 1 | Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MAC Address data item TLV Data Item Type: TBD
Length: 1
After placing the mandatory data item TLV into the packet, the Interval: 0 = Do NOT use timeouts for Link Characteristics requests
implementation would place any supported OPTIONAL data item TLVs. on this router/modem session. Non-zero = Interval, in seconds, to
Possible OPTIONAL data item TLVs are: wait before considering a Link Characteristics Request has been
lost.
- IPv4 Address 9. Credit-Windowing
- IPv6 Address
- Maximum Data Rate (Receive)
- Maximum Data Rate (Transmit)
- Current Data Rate (Receive)
- Current Data Rate (Transmit)
- Latency
- Resources (Receive)
- Resources (Transmit)
- Relative Link Quality (Receive)
- Relative Link Quality (Transmit)
- Credit Window Status
- Credit Grant
- Credit Request
11.15 Heartbeat Signal DLEP includes an OPTIONAL credit-windowing scheme analogous to the
one documented in [RFC5578]. In this scheme, traffic between the
router and modem is treated as two unidirectional windows. This
document identifies these windows as the 'Modem Receive Window', or
MRW, and the 'Router Receive Window', or RRW.
A Heartbeat Signal is sent by a DLEP participant every N seconds, If the OPTIONAL credit-windowing scheme is used, credits MUST be
where N is defined in the "Heartbeat Interval" field of the Peer granted by the receiver on a given window - that is, on the 'Modem
Initialization signal. Note that implementations setting the Receive Window' (MRW), the modem is responsible for granting credits
Heartbeat Interval to 0 effectively set the interval to an infinite to the router, allowing it (the router) to send data to the modem.
value, therefore, in those cases, this signal would NOT be sent. Likewise, the router is responsible for granting credits on the RRW,
which allows the modem to send data to the router.
The signal is used by participants to detect when a DLEP session DLEP expresses all credit data in number of octets. The total number
partner (either the modem or the router) is no longer communicating. of credits on a window, and the increment to add to a grant, are
Participants SHOULD allow two (2) heartbeat intervals to expire with always expressed as a 64-bit unsigned integer quantity.
no traffic on the router/modem session before initiating DLEP session
termination procedures.
To construct a Heartbeat signal, the initial TLV type value is set to If used, credits are managed on a neighbor-specific basis; that is,
DLEP_PEER_HEARTBEAT (value TBD). The signal TLV is followed by the separate credit counts are maintained for each neighbor requiring the
mandatory Heartbeat Interval/Threshold data item. service. Credits do not apply to the DLEP session that exists
between routers and modems.
Note that there are NO OPTIONAL data item TLVs for this signal. If a peer is able to support the OPTIONAL credit-windowing scheme
then it MUST include a Extensions Supported data item (Section 8.6)
including the value DLEP_EXT_CREDITS (value TBD) in the appropriate
Peer Initialization or Peer Initialization ACK signal.
11.16 Link Characteristics Request Signal 9.1. Credit-Windowing Signals
The Link Characteristics Request Signal is an optional signal, and is The credit-windowing scheme introduces no additional DLEP signals.
sent by the router to request that the modem initiate changes for However, if a peer has advertised during session initialization that
specific characteristics of the link. The request can reference it supports the credit-windowing scheme then the following DLEP
either a real (e.g., a remote node), or a logical (e.g., a multicast signals may contain additional credit-windowing data items:
group) destination within the network.
The Link Characteristics Request signal contains either a Current 9.1.1. Destination Up Signal
Data Rate (CDRR or CDRT) TLV to request a different datarate than
what is currently allocated, a Latency TLV to request that traffic
delay on the link not exceed the specified value, or both. A Link
Characteristics ACK Signal is required to complete the request.
Implementations are free to define their retry heuristics in event of
a timeout. Issuing a Link Characteristics Request with ONLY the MAC
Address TLV is a mechanism a peer MAY use to request metrics (via the
Link Characteristics ACK) from its partner.
To construct a Link Characteristics Request signal, the initial TLV The Destination Up signal MAY contain one of each of the following
type value is set to DLEP_Destination_LINK_CHAR_REQ (value TBD). data items:
Following the signal TLV is the mandatory Data Item TLV:
MAC Address data item TLV o Credit Grant (Section 9.2.2)
After placing the mandatory data item TLV into the packet, the 9.1.2. Destination Up ACK Signal
implementation would place any supported OPTIONAL data item TLVs.
Possible optional data item TLVs are:
Current Data Rate - If present, this value represents the NEW (or The Destination Up ACK signal MAY contain one of each of the
unchanged, if the request is denied) Current following data items:
Data Rate in bits per second (bps).
Latency - If present, this value represents the maximum o Credit Window Status (Section 9.2.1)
desired latency (e.g., it is a not-to-exceed
value) in microseconds on the link.
11.17 Link Characteristics ACK Signal 9.1.3. Destination Update Signal
The LInk Characteristics ACK signal is an optional signal, and is The Destination Update signal MAY contain one of each of the
sent by modems supporting it to the router letting the router know following data items:
the success or failure of a requested change in link characteristics.
The Link Characteristics ACK signal SHOULD contain a complete set of
metric data item TLVs. It MUST contain the same TLV types as the
request. The values in the metric data item TLVs in the Link
Characteristics ACK signal MUST reflect the link characteristics
after the request has been processed.
To construct a Link Characteristics Request ACK signal, the initial o Credit Window Status (Section 9.2.1)
TLV type value is set to DLEP_Destination_LINK_CHAR_ACK (value TBD).
Following the signal TLV is the mandatory Data Item TLV:
MAC Address data item TLV o Credit Grant (Section 9.2.2)
After placing the mandatory data item TLV into the packet, the o Credit Request (Section 9.2.3)
implementation would place any supported OPTIONAL data item TLVs.
Possible OPTIONAL data item TLVs are:
Current Data Rate - If present, this value represents the requested 9.2. Credit-Windowing Data Items
data rate in bits per second (bps).
Latency - If present, this value represents the NEW The credit-windowing scheme introduces 3 additional data items. If a
maximum latency (or unchanged, if the request peer has advertised during session initialization that it supports
is denied), expressed in microseconds, on the the credit-windowing scheme then it MUST correctly process the
link. following data items without error.
12. Security Considerations +------------+-----------------------+----------------+
| Data Item | Description | Section |
+------------+-----------------------+----------------+
| TBD | Credit Window Status | Section 9.2.1 |
| TBD | Credit Grant | Section 9.2.2 |
| TBD | Credit Request | Section 9.2.3 |
+------------+-----------------------+----------------+
The protocol does not contain any mechanisms for security (e.g. 9.2.1. Credit Window Status
authentication or encryption). The protocol assumes that any security
would be implemented in the underlying transport (for example, by use
of DTLS or some other mechanism), and is therefore outside the scope
of this document.
13. IANA Considerations If the credit-window scheme is supported by the DLEP participants
(both the router and the modem), the Credit Window Status data item
MUST be sent by the participant receiving a Credit Grant for a given
destination.
The Credit Window 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 = 16 | Modem Receive Window Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Modem Receive Window Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Modem Receive Window Value | Router Receive Window Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Receive Window Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Receive Window Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: TBD
Length: 16
Modem Receive Window Value: A 64-bit unsigned integer, indicating
the current (or initial) number of credits available on the Modem
Receive Window.
Router Receive Window Value: A 64-bit unsigned integer, indicating
the current (or initial) number of credits available on the Router
Receive Window.
9.2.2. Credit Grant
The Credit Grant data item is sent from a DLEP participant to grant
an increment to credits on a window. The Credit Grant data item MAY
appear in the Destination Up (Section 7.9) or Destination Update
(Section 7.13) signals. The value in a Credit Grant data item
represents an increment to be added to any existing credits available
on the window. Upon successful receipt and processing of a Credit
Grant data item, the receiver MUST respond with a signal containing a
Credit Window Status data item to report the updated aggregate values
for synchronization purposes.
In the Destination Up signal, when credits are desired, the
originating peer MUST set the initial credit value of the window it
controls (i.e., the Modem Receive Window, or Router Receive Window)
to an initial, non-zero value. If the receiver of a Destination Up
signal with a Credit Grant data item supports credits, the receiver
MUST either reject the use of credits, via a Destination Up ACK
response containing a Status data item (Section 8.2) with a status
code of 'Request Denied', or set the initial value from the data
contained in the Credit Window Status data item. If the
initialization completes successfully, the receiver MUST respond to
the Destination Up signal with a Destination Up ACK signal that
contains a Credit Window Status data item, initializing its receive
window.
The Credit Grant 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 = 8 | Credit Increment |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit Increment |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credit Increment |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: TBD
Length: 8
Reserved: A 64-bit unsigned integer representing the additional
credits to be assigned to the credit window.
Since credits can only be granted by the receiver on a window, the
applicable credit window (either the MRW or the RRW) is derived from
the sender of the grant. The Credit Increment MUST NOT cause the
window to overflow; if this condition occurs, implementations MUST
set the credit window to the maximum value contained in a 64-bit
quantity.
9.2.3. Credit Request
The Credit Request data item MAY be sent from either DLEP
participant, via the Destination Update signal (Section 7.13), to
indicate the desire for the partner to grant additional credits in
order for data transfer to proceed on the session. If the
corresponding Destination Up signal (Section 7.9) for this session
did NOT contain a Credit Window Status data item, indicating that
credits are to be used on the session, then the Credit Request data
item MUST be rejected by the receiver via a Destination Update ACK
signal containing a Status data item (Section 8.2) with status code
'Request Denied'.
The Credit Request data item contains the following fields:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type| Length = 1 | Reserved, MUST|
| | | be set to 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: TBD
Length: 1
Reserved: This field is currently unused and MUST be set to 0.
10. Security Considerations
The protocol does not contain any mechanisms for security (e.g.,
authentication or encryption). The protocol assumes that any
security would be implemented in the underlying transport (for
example, by use of DTLS or some other mechanism), and is therefore
outside the scope of this document.
11. IANA Considerations
This section specifies requests to IANA. This section specifies requests to IANA.
13.1 Registrations 11.1. Registrations
This specification defines: This specification defines:
o A new repository for DLEP signals, with fifteen values currently o A new repository for DLEP signals, with sixteen values currently
assigned. assigned.
o Reservation of numbering space for Experimental DLEP signals. o Reservation of numbering space for Experimental DLEP signals.
o A new repository for DLEP Data Items, with twenty-one values o A new repository for DLEP data items, with twenty-three values
currently assigned. currently assigned.
o Reservation of numbering space in the Data Items repository for o Reservation of numbering space in the data items repository for
experimental data items. experimental data items.
o A new repository for DLEP status codes.
o A new repository for DLEP extensions, with one value currently
assigned.
o A request for allocation of a well-known port for DLEP o A request for allocation of a well-known port for DLEP
communication. communication.
o A request for allocation of a multicast address for DLEP o A request for allocation of a multicast address for DLEP
discovery. discovery.
13.2 Expert Review: Evaluation Guidelines 11.2. Expert Review: Evaluation Guidelines
No additional guidelines for expert review are anticipated. No additional guidelines for expert review are anticipated.
13.3 Signal TLV Type Registration 11.3. Signal Type Registration
A new repository must be created with the values of the DLEP signals. A new repository must be created with the values of the DLEP signals.
All signal values are in the range [0..255].
Valid signals are: Valid signals are:
o Peer Discovery o Peer Discovery
o Peer Offer
o Peer Initialization o Peer Offer
o Peer Initialization ACK
o Peer Update o Peer Initialization
o Peer Update ACK
o Peer Termination o Peer Initialization ACK
o Peer Termination ACK
o Destination Up o Peer Update
o Destination Up ACK
o Destination Down o Peer Update ACK
o Destination Down ACK
o Destination Update
o Heartbeat
o Link Characteristics Request
o Link Characteristics ACK
o Peer Termination
o Peer Termination ACK
o Destination Up
o Destination Up ACK
o Destination Down
o Destination Down ACK
o Destination Update
o Heartbeat
o Link Characteristics Request
o Link Characteristics ACK
It is also requested that the repository contain space for It is also requested that the repository contain space for
experimental signal types. experimental signal types.
13.4 DLEP Data Item Registrations 11.4. DLEP Data Item Registrations
A new repository for DLEP Data Items must be created. Valid Data A new repository for DLEP data items must be created.
Items are:
o DLEP Version All data item values are in the range [0..255].
o Peer Type
o MAC Address Valid data items are:
o IPv4 Address
o IPv6 Address o DLEP Version
o Maximum Data Rate (Receive)
o Maximum Data Rate (Transmit) o Status
o Current Data Rate (Receive)
o Current Data Rate (Transmit) o DLEP Port
o Latency
o Resources (Receive) o Peer Type
o Resources (Transmit)
o Relative Link Quality (Receive) o Heartbeat Interval
o Relative Link Quality (Transmit)
o Status o Extensions Supported
o Heartbeat Interval/Threshold
o Link Characteristics ACK Timer o Experimental Definition
o Credit Window Status
o Credit Grant o MAC Address
o Credit Request
o DLEP Optional Signals Supported o IPv4 Address
o DLEP Optional Data Items Supported
o DLEP Vendor Extension o IPv6 Address
o IPv4 Attached Subnet
o IPv6 Attached Subnet
o Maximum Data Rate (Receive)
o Maximum Data Rate (Transmit)
o Current Data Rate (Receive)
o Current Data Rate (Transmit)
o Latency
o Resources (Receive)
o Resources (Transmit)
o Relative Link Quality (Receive)
o Relative Link Quality (Transmit)
o Link Characteristics ACK Timer
o Credit Window Status
o Credit Grant
o Credit Request
It is also requested that the registry allocation contain space for It is also requested that the registry allocation contain space for
experimental data items. experimental data items.
13.5 DLEP Well-known Port 11.5. DLEP Status Code Registrations
A new repository for DLEP status codes must be created.
All status codes are in the range [0..255].
Valid status codes are:
o Success (value 0)
o Unknown Signal
o Invalid Signal
o Unexpected Signal
o Request Denied
o Timed Out
11.6. DLEP Extensions Registrations
A new repository for DLEP extensions must be created.
All extension values are in the range [0..255].
Valid extensions are:
o DLEP_EXT_CREDITS - Credit windowing
11.7. DLEP Well-known Port
It is requested that IANA allocate a well-known port number for DLEP It is requested that IANA allocate a well-known port number for DLEP
communication. communication.
13.6 DLEP Multicast Address 11.8. DLEP Multicast Address
It is requested that IANA allocate a multicast address for DLEP It is requested that IANA allocate a multicast address for DLEP
discovery signals. discovery signals.
14. Appendix A. 12. Acknowledgements
14.1 Peer Level Signal Flows The authors 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.
14.1.1 Router Device Restarts Discovery The authors would also like to acknowledge the influence and
contributions of Greg Harrison, Chris Olsen, Martin Duke, Subir Das,
Jaewon Kang, Vikram Kaul, and Nelson Powell.
Router Modem Signal Description 13. References
====================================================================
--------Peer Discovery--------> Router initiates discovery 13.1. Normative References
<--------Peer Offer------------ Modem detects a problem, sends [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
w/ Non-zero Status TLV Peer Offer w/Status TLV indicating Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5578] Berry, B., Ratliff, S., Paradise, E., Kaiser, T., and M.
Adams, "PPP over Ethernet (PPPoE) Extensions for Credit
Flow and Link Metrics", RFC 5578, February 2010.
13.2. Informative References
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
Appendix A. Peer Level Signal Flows
_NB_ The following diagrams are possibly out of date. If there is a
discepancy with the text, then the text is correct.
A.1. Router Device Restarts Discovery
Router Modem Signal Description
====================================================================
--------Peer Discovery--------> Router initiates discovery
<--------Peer Offer------------ Modem detects a problem, sends
w/ Non-zero Status TLV Peer Offer w/Status TLV indicating
the error. the error.
Router accepts failure, restarts Router accepts failure, restarts
discovery process. discovery process.
--------Peer Discovery--------> Router initiates discovery --------Peer Discovery--------> Router initiates discovery
<--------Peer Offer------------ Modem accepts, sends Peer Offer <--------Peer Offer------------ Modem accepts, sends Peer Offer
w/Zero Status TLV indicating w/Zero Status TLV indicating
success. success.
Discovery completed. Discovery completed.
14.1.2 Router Device Detects Peer Offer Timeout A.2. Router Device Detects Peer Offer Timeout
Router Modem Signal Description Router Modem Signal Description
==================================================================== ====================================================================
--------Peer Discovery--------> Router initiates discovery, starts --------Peer Discovery--------> Router initiates discovery, starts
a guard timer. a guard timer.
Router guard timer expires. Router Router guard timer expires. Router
restarts discovery process. restarts discovery process.
--------Peer Discovery--------> Router initiates discovery, starts --------Peer Discovery--------> Router initiates discovery, starts
a guard timer. a guard timer.
<--------Peer Offer------------ Modem accepts, sends Peer Offer <--------Peer Offer------------ Modem accepts, sends Peer Offer
w/Zero Status TLV indicating w/Zero Status TLV indicating
success. success.
Discovery completed. Discovery completed.
14.1.3 Router Peer Offer Lost A.3. Router Peer Offer Lost
Router Modem Signal Description
====================================================================
Router Modem Signal Description <-------Peer Discovery--------- Modem initiates discovery, starts
==================================================================== a guard timer.
<-------Peer Discovery--------- Modem initiates discovery, starts ---------Peer Offer-------|| Router offers availability
a guard timer.
---------Peer Offer-------|| Router offers availability Modem times out on Peer Offer,
restarts discovery process.
Modem times out on Peer Offer, <-------Peer Discovery--------- Modem initiates discovery
restarts discovery process.
<-------Peer Discovery--------- Modem initiates discovery ---------Peer Offer-----------> Router detects subsequent
discovery, internally terminates
the previous, accepts the new
association, sends Peer Offer
w/Status TLV indicating success.
---------Peer Offer-----------> Router detects subsequent Discovery completed.
discovery, internally terminates
the previous, accepts the new
association, sends Peer Offer
w/Status TLV indicating success.
Discovery completed. A.4. Discovery Success
14.1.4 Discovery Success Router Modem Signal Description
====================================================================
Router Modem Signal Description <-------Peer Discovery--------- Modem initiates discovery
====================================================================
<-------Peer Discovery--------- Modem initiates discovery ---------Peer Offer-----------> Router offers availability
---------Peer Offer-----------> Router offers availability <-----Peer Initialization------ Modem Connects on TCP Port
<-----Peer Initialization------ Modem Connects on TCP Port <------Peer Heartbeat----------
<------Peer Heartbeat---------- -------Peer Heartbeat--------->
-------Peer Heartbeat---------> <==============================> Signal flow about destinations
(i.e. Destination Up, Destination
Down, Destination update)
<==============================> Signal flow about destinations <-------Peer Heartbeat---------
(i.e. Destination Up, Destination
Down, Destination update)
<-------Peer Heartbeat--------- -------Peer Heartbeat--------->
-------Peer Heartbeat---------> --------Peer Term Req---------> Terminate Request
--------Peer Term Req---------> Terminate Request
<--------Peer Term Res--------- Terminate Response <--------Peer Term Res--------- Terminate Response
14.1.5 Router Detects a Heartbeat timeout A.5. Router Detects a Heartbeat timeout
Router Modem Signal Description Router Modem Signal Description
==================================================================== ====================================================================
<-------Peer Heartbeat--------- <-------Peer Heartbeat---------
-------Peer Heartbeat---------> -------Peer Heartbeat--------->
||---Peer Heartbeat--------- ||---Peer Heartbeat---------
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-------Peer Heartbeat---------> -------Peer Heartbeat--------->
||---Peer Heartbeat--------- ||---Peer Heartbeat---------
Router Heartbeat Timer expires, Router Heartbeat Timer expires,
detects missing heartbeats. Router detects missing heartbeats. Router
takes down all destination sessions takes down all destination
and terminates the Peer sessions and terminates the Peer
association. association.
------Peer Terminate ---------> Peer Terminate Request ------Peer Terminate ---------> Peer Terminate Request
Modem takes down all destination Modem takes down all destination
sessions, then acknowledges the sessions, then acknowledges the
Peer Terminate Peer Terminate
<----Peer Terminate ACK--------- Peer Terminate ACK <----Peer Terminate ACK--------- Peer Terminate ACK
14.1.6 Modem Detects a Heartbeat timeout
Router Modem Signal Description A.6. Modem Detects a Heartbeat timeout
==================================================================== Router Modem Signal Description
====================================================================
<-------Peer Heartbeat--------- <-------Peer Heartbeat---------
-------Peer Heartbeat------|| -------Peer Heartbeat------||
<-------Peer Heartbeat--------- <-------Peer Heartbeat---------
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
-------Peer Heartbeat------|| -------Peer Heartbeat------||
<-------Peer Heartbeat--------- <-------Peer Heartbeat---------
Modem Heartbeat Timer expires, Modem Heartbeat Timer expires,
detects missing heartbeats. Modem detects missing heartbeats. Modem
takes down all destination sessions takes down all destination
sessions
<-------Peer Terminate-------- Peer Terminate Request <-------Peer Terminate-------- Peer Terminate Request
Router takes down all destination Router takes down all destination
sessions, then acknowledges the sessions, then acknowledges the
Peer Terminate Peer Terminate
------Peer Terminate ACK-----> Peer Terminate ACK ------Peer Terminate ACK-----> Peer Terminate ACK
14.1.7 Peer Terminate (from Modem) Lost A.7. Peer Terminate (from Modem) Lost
Router Modem Signal Description Router Modem Signal Description
==================================================================== ====================================================================
||------Peer Terminate-------- Modem Peer Terminate Request ||------Peer Terminate-------- Modem Peer Terminate Request
Router Heartbeat times out,
terminates association.
--------Peer Terminate-------> Router Peer Terminate Router Heartbeat times out,
terminates association.
<-----Peer Terminate ACK------ Modem sends Peer Terminate ACK --------Peer Terminate-------> Router Peer Terminate
14.1.8 Peer Terminate (from Router) Lost <-----Peer Terminate ACK------ Modem sends Peer Terminate ACK
Router Modem Signal Description A.8. Peer Terminate (from Router) Lost
Router Modem Signal Description
==================================================================== ====================================================================
-------Peer Terminate--------> Router Peer Terminate Request -------Peer Terminate--------> Router Peer Terminate Request
Modem HB times out, Modem HB times out,
terminates association. terminates association.
<------Peer Terminate-------- Modem Peer Terminate <------Peer Terminate-------- Modem Peer Terminate
------Peer Terminate ACK-----> Peer Terminate ACK ------Peer Terminate ACK-----> Peer Terminate ACK
14.2 Destination Specific Signal Flows Appendix B. Destination Specific Signal Flows
14.2.1 Modem Destination Up Lost
Router Modem Signal Description B.1. Modem Destination Up Lost
Router Modem Signal Description
==================================================================== ====================================================================
||-----Destination Up ------------ Modem sends Destination Up ||-----Destination Up ------------ Modem sends Destination Up
Modem timesout on ACK Modem timesout on ACK
<------Destination Up ------------ Modem sends Destination Up <------Destination Up ------------ Modem sends Destination Up
------Destination Up ACK---------> Router accepts the destination ------Destination Up ACK---------> Router accepts the destination
session session
<------Destination Update--------- Modem Destination Metrics <------Destination Update--------- Modem Destination Metrics
. . . . . . . . . . . . . . . .
<------Destination Update--------- Modem Destination Metrics <------Destination Update--------- Modem Destination Metrics
14.2.2 Router Detects Duplicate Destination Ups B.2. Router Detects Duplicate Destination Ups
Router Modem Signal Description
Router Modem Signal Description
==================================================================== ====================================================================
<------Destination Up ------------ Modem sends Destination Up <------Destination Up ------------ Modem sends Destination Up
------Destination Up ACK-------|| Router accepts the destination ------Destination Up ACK-------|| Router accepts the destination
session session
Modem timesout on ACK Modem timesout on ACK
<------Destination Up ------------ Modem resends Destination Up <------Destination Up ------------ Modem resends Destination Up
Router detects duplicate Router detects duplicate
Destination, takes down the Destination, takes down the
previous, accepts the new previous, accepts the new
Destination. Destination.
------Destination Up ACK---------> Router accepts the destination ------Destination Up ACK---------> Router accepts the destination
session session
<------Destination Update--------- Modem Destination Metrics <------Destination Update--------- Modem Destination Metrics
. . . . . . . . . . . . . . . .
<------Destination Update--------- Modem Destination Metrics <------Destination Update--------- Modem Destination Metrics
14.2.3 Destination Up, No Layer 3 Addresses B.3. Destination Up, No Layer 3 Addresses
Router Modem Signal Description
====================================================================
<------Destination Up ------------ Modem sends Destination Up Router Modem Signal Description
====================================================================
------Destination Up ACK---------> Router accepts the destination <------Destination Up ------------ Modem sends Destination Up
session
Router ARPs for IPv4 if defined. ------Destination Up ACK---------> Router accepts the destination
Router drives ND for IPv6 if session
defined.
<------Destination Update--------- Modem Destination Metrics Router ARPs for IPv4 if defined.
. . . . . . . . Router drives ND for IPv6 if
<------Destination Update--------- Modem Destination Metrics defined.
14.2.4 Destination Up with IPv4, No IPv6 <------Destination Update--------- Modem Destination Metrics
. . . . . . . .
<------Destination Update--------- Modem Destination Metrics
Router Modem Signal Description B.4. Destination Up with IPv4, No IPv6
Router Modem Signal Description
==================================================================== ====================================================================
<------Destination Up ------------ Modem sends Destination Up with <------Destination Up ------------ Modem sends Destination Up with
the IPv4 TLV the IPv4 TLV
------Destination Up ACK---------> Router accepts the destination ------Destination Up ACK---------> Router accepts the destination
session session
Router drives ND for IPv6 if Router drives ND for IPv6 if
defined. defined.
<------Destination Update--------- Modem Destination Metrics <------Destination Update--------- Modem Destination Metrics
. . . . . . . . . . . . . . . .
<------Destination Update--------- Modem Destination Metrics <------Destination Update--------- Modem Destination Metrics
14.2.5 Destination Up with IPv4 and IPv6 B.5. Destination Up with IPv4 and IPv6
Router Modem Signal Description Router Modem Signal Description
==================================================================== ====================================================================
<------Destination Up ------------ Modem sends Destination Up with <------Destination Up ------------ Modem sends Destination Up with
the IPv4 and IPv6 TLVs the IPv4 and IPv6 TLVs
------Destination Up ACK---------> Router accepts the destination ------Destination Up ACK---------> Router accepts the destination
session session
<------Destination Update--------- Modem Destination Metrics <------Destination Update--------- Modem Destination Metrics
. . . . . . . . . . . . . . . .
14.2.6 Destination Session Success B.6. Destination Session Success
Router Modem Signal Description
Router Modem Signal Description
==================================================================== ====================================================================
---------Peer Offer-----------> Router offers availability ---------Peer Offer-----------> Router offers availability
-------Peer Heartbeat---------> -------Peer Heartbeat--------->
<------Destination Up ----------- Modem <------Destination Up ----------- Modem
------Destination Up ACK--------> Router ------Destination Up ACK--------> Router
<------Destination Update--------- Modem <------Destination Update--------- Modem
. . . . . . . . . . . . . . . .
<------Destination Update--------- Modem <------Destination Update--------- Modem
Modem initiates the terminate
<------Destination Down ---------- Modem
------Destination Down ACK-------> Router
or
Router initiates the terminate
------Destination Down ----------> Router
<------Destination Down ACK------- Modem
Acknowledgements
The authors 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,
Henning Rogge, and Rick Taylor.
The authors would also like to acknowledge the influence and Modem initiates the terminate
contributions of Chris Olsen, Martin Duke, Subir Das, Jaewon Kang,
Vikram Kaul, and Nelson Powell.
Normative References <------Destination Down ---------- Modem
[RFC5578] Berry, B., Ed., "PPPoE with Credit Flow and Metrics", ------Destination Down ACK-------> Router
RFC 5578, February 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate or
[IEEE] http://standards.ieee.org/develop/regauth/oui/index.html Router initiates the terminate
Informative References ------Destination Down ----------> Router
[TLS] Dierks, T. and Rescorla, E. "The Transport Layer Security <------Destination Down ACK------- Modem
(TLS) Protocol", RFC 5246, August 2008.
Author's Addresses Authors' Addresses
Stan Ratliff Stan Ratliff
Independent Consultant VT iDirect
USA 13861 Sunrise Valley Drive, Suite 300
EMail: ratliffstan@gmail.com Herndon, VA 20171
Bo Berry
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA USA
EMail:
Greg Harrison Email: sratliff@idirect.net
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
EMail: greharri@cisco.com
Bo Berry
Shawn Jury Shawn Jury
Cisco Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: sjury@cisco.com Email: sjury@cisco.com
Darryl Satterwhite Darryl Satterwhite
Broadcom Broadcom
USA
Email: dsatterw@broadcom.com Email: dsatterw@broadcom.com
Rick Taylor
Airbus Defence & Space
Quadrant House
Celtic Springs
Coedkernew
Newport NP10 8FZ
UK
Email: rick.taylor@airbus.com
 End of changes. 546 change blocks. 
1741 lines changed or deleted 2007 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/