RFC 8175
Dynamic Link Exchange Protocol (DLEP)
Dynamic Link Exchange Protocol (DLEP) 🎀
RFC 8175 💖 is a Standards Track document from the Internet Engineering Task Force (IETF) ✨, dated June 2017 🦋, with ISSN 2070-1721. It's a Standards Track doc, so it's the real deal, not a "just an idea" kind of thing 💅.
Authors (the squad 🫶):
- S. Ratliff, VT iDirect
- S. Jury, Cisco Systems
- D. Satterwhite, Broadcom
- R. Taylor, Airbus Defence & Space
- B. Berry (no affiliation listed)
No "Obsoletes" or "Updates" line appears in this document's header, so it doesn't claim to replace or change any other RFC there 🌸.
Abstract ✨
okay so bestie, picture a router 🧚 that talks to a modem, and the modem is handling a wireless link. The router needs to know what the link is actually like, things like how fast it is and what state it's in, right now, so it can make smart routing choices 👑. Now add mobility or anything else where those link details keep shifting, and it gets messy fr fr. Setting things up by hand doesn't cut it, and guessing the link state from routing or transport protocols doesn't cut it either. The router just can't make the best call that way 😭.
So this document introduces the Dynamic Link Exchange Protocol (DLEP) 💜. It gives the router and the modem a two-way, event-driven channel so they can keep each other posted on changing link characteristics. It's giving real-time updates, no cap 🔥.
Status of This Memo 📜
This is an Internet Standards Track document 💅.
It's a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, received public review, and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 7841 🎀.
For the current status, any errata, and how to send feedback on this document, go to http://www.rfc-editor.org/info/rfc8175 🌈.
Copyright Notice 💜
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved 🦋.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as they stand on the date this document was published. Please actually read these, bestie, because they spell out your rights and restrictions for this document 🙈. Code Components extracted from this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License ⭐.
Table of Contents 📚
1. Introduction ....................................................4
2. Protocol Overview ...............................................7
2.1. Destinations ...............................................8
2.2. Conventions and Terminology ................................9
3. Requirements ....................................................9
4. Implementation Scenarios .......................................10
5. Assumptions ....................................................10
6. Metrics ........................................................11
7. DLEP Session Flow ..............................................12
7.1. Peer Discovery State ......................................12
7.2. Session Initialization State ..............................14
7.3. In-Session State ..........................................14
7.3.1. Heartbeats .........................................15
7.4. Session Termination State .................................15
7.5. Session Reset State .......................................16
7.5.1. Unexpected TCP Connection Termination ..............16
8. Transaction Model ..............................................16
9. Extensions .....................................................17
9.1. Experiments ...............................................18
10. Scalability ...................................................18
11. DLEP Signal and Message Structure .............................18
11.1. DLEP Signal Header .......................................19
11.2. DLEP Message Header ......................................20
11.3. DLEP Generic Data Item ...................................20
12. DLEP Signals and Messages .....................................21
12.1. General Processing Rules .................................21
12.2. Status Code Processing ...................................22
12.3. Peer Discovery Signal ....................................22
12.4. Peer Offer Signal ........................................23
12.5. Session Initialization Message ...........................23
12.6. Session Initialization Response Message ..................24
12.7. Session Update Message ...................................26
12.8. Session Update Response Message ..........................27
12.9. Session Termination Message ..............................28
12.10. Session Termination Response Message ....................28
12.11. Destination Up Message ..................................28
12.12. Destination Up Response Message .........................30
12.13. Destination Announce Message ............................30
12.14. Destination Announce Response Message ...................31
12.15. Destination Down Message ................................32
12.16. Destination Down Response Message .......................33
12.17. Destination Update Message ..............................33
12.18. Link Characteristics Request Message ....................35
12.19. Link Characteristics Response Message ...................35
12.20. Heartbeat Message .......................................36
13. DLEP Data Items ...............................................37
13.1. Status ...................................................38
13.2. IPv4 Connection Point ....................................41
13.3. IPv6 Connection Point ....................................42
13.4. Peer Type ................................................43
13.5. Heartbeat Interval .......................................45
13.6. Extensions Supported .....................................45
13.7. MAC Address ..............................................46
13.8. IPv4 Address .............................................47
13.8.1. IPv4 Address Processing ...........................48
13.9. IPv6 Address .............................................49
13.9.1. IPv6 Address Processing ...........................50
13.10. IPv4 Attached Subnet ....................................51
13.10.1. IPv4 Attached Subnet Processing ..................52
13.11. IPv6 Attached Subnet ....................................53
13.11.1. IPv6 Attached Subnet Processing ..................54
13.12. Maximum Data Rate (Receive) .............................55
13.13. Maximum Data Rate (Transmit) ............................56
13.14. Current Data Rate (Receive) .............................56
13.15. Current Data Rate (Transmit) ............................57
13.16. Latency .................................................58
13.17. Resources ...............................................59
13.18. Relative Link Quality (Receive) .........................60
13.19. Relative Link Quality (Transmit) ........................60
13.20. Maximum Transmission Unit (MTU) .........................61
14. Security Considerations .......................................62
15. IANA Considerations ...........................................63
15.1. Registrations ............................................63
15.2. Signal Type Registrations ................................63
15.3. Message Type Registrations ...............................64
15.4. DLEP Data Item Registrations .............................65
15.5. DLEP Status Code Registrations ...........................66
15.6. DLEP Extension Registrations .............................67
15.7. DLEP IPv4 Connection Point Flags .........................68
15.8. DLEP IPv6 Connection Point Flags .........................68
15.9. DLEP Peer Type Flags .....................................68
15.10. DLEP IPv4 Address Flags .................................69
15.11. DLEP IPv6 Address Flags .................................69
15.12. DLEP IPv4 Attached Subnet Flags .........................69
15.13. DLEP IPv6 Attached Subnet Flags .........................70
15.14. DLEP Well-Known Port ....................................70
15.15. DLEP IPv4 Link-Local Multicast Address ..................70
15.16. DLEP IPv6 Link-Local Multicast Address ..................70
16. References ....................................................71
16.1. Normative References .....................................71
16.2. Informative References ...................................71
Appendix A. Discovery Signal Flows ................................73
Appendix B. Peer-Level Message Flows ..............................73
B.1. Session Initialization .....................................73
B.2. Session Initialization - Refused ...........................74
B.3. Router Changes IP Addresses ................................74
B.4. Modem Changes Session-Wide Metrics .........................75
B.5. Router Terminates Session ..................................75
B.6. Modem Terminates Session ...................................76
B.7. Session Heartbeats .........................................77
B.8. Router Detects a Heartbeat Timeout .........................78
B.9. Modem Detects a Heartbeat Timeout ..........................78
Appendix C. Destination-Specific Message Flows ....................79
C.1. Common Destination Notification ............................79
C.2. Multicast Destination Notification .........................80
C.3. Link Characteristics Request ...............................81
Acknowledgments ...................................................82
Authors' Addresses ................................................82Next up: Section 1, Introduction 🧚 (the content gets real from here, bestie)
1. Introduction ✨
okay so bestie, there's this whole collection of modem devices that control links whose data rate and quality keep changing 🦋 Think line-of-sight (LOS) terrestrial radios, satellite terminals, and broadband modems. The speed and quality can shift because of configuration, or moment to moment because of physical stuff like multipath interference, obstructions, rain fade, etc. ⛈️ It's also totally possible that link quality and data rate differ for each individual destination on a link and depending on the type of traffic being sent. 💅
Here's an example that made me gasp 😭 Imagine an IEEE 802.11 access point serving two associated laptop computers. If someone asks "What is the data rate on the 802.11 link?", the answer is literally "It depends on which associated laptop we're talking about and on what kind of traffic is being sent." 🙈 The laptop sitting close to the access point might get 54 Mbps for unicast traffic, while the other laptop, farther away or blocked by some object, can at the same time only get 32 Mbps for unicast. Multicast is a whole different vibe though: everything sent from the access point for multicast goes out at the base transmission rate, which is configurable but, depending on the model of the access point, is usually 24 Mbps or less. 🌈
Mobile networks have an extra problem too. Link connectivity can come and go over time without changing a router's interface state (Up or Down). 🌸 Using a short-lived connection well is hard in IP routed networks, because IP routing protocols tend to lean on interface state and independent timers to keep the network converged (for example, HELLO messages and/or noticing that DEAD routing adjacencies). ⏱️ Honestly, these dynamic connections are way better suited to an event-driven paradigm, where a new neighbor showing up (or an existing one disappearing) gets signaled, instead of a paradigm driven by timers and/or interface state. ✨ That's exactly what DLEP does, and it does it over a local (1-hop) TCP session, which guarantees delivery of the event messages. 💖
Another plot twist for mobile networks is the different ways modem devices can physically connect to the router. 🎀 A modem can be an interface card in a router's chassis, or a standalone device connected to the router via Ethernet or serial link. With Ethernet attachment, existing protocols and techniques leave routing software unaware of convergence events happening on the radio link (for example, a potential routing neighbor being acquired or lost), and the router can't see the actual capacity of the link either. 😭 That lack of awareness, combined with the variable data rate, makes it really hard to find and properly maintain the (current) best route through the network to a given node. 🧚 This is especially true for demand-based access schemes like Demand Assigned Multiple Access (DAMA) implementations used on some satellite systems. With a DAMA-based system, extra data rate might be available but won't be used unless the network devices emit traffic at a rate higher than the currently established rate. 💀 And cranking up the traffic rate doesn't guarantee more data rate will be allocated. Instead, it may cause data loss and additional retransmissions on the link. Yikes. 🙃
So to fix all of this, the Dynamic Link Exchange Protocol, or DLEP, was developed. 👑 DLEP runs between a router and its attached modem devices, letting the modem devices communicate (1) link characteristics as they change and (2) convergence events (acquisition and loss of potential routing next hops). 🫶 Figures 1 and 2 show the scope of DLEP packets.
|-------Local Node-------| |-------Remote Node------|
| | | |
+--------+ +-------+ +-------+ +--------+
| Router |=======| Modem |{~~~~~~~~}| Modem |=======| Router |
| | | Device| | Device| | |
+--------+ +-------+ +-------+ +--------+
| | | Link | | |
|-DLEP--| | Protocol | |-DLEP--|
| | | (e.g., | | |
| | | 802.11) | | |
Figure 1: DLEP NetworkSo in Figure 1, when the local modem detects a remote node, it (the local modem) sends a message to its router via DLEP. 🔥 The message says what changed on the link (for example, that a remote node was detected), along with a collection of DLEP-defined Data Items that describe the change in more detail. Once the router gets that message, it may take whatever action it deems appropriate, like starting discovery protocols and/or sending out HELLO messages to converge the network. 🌷 On a continuing, as-needed basis, the modem devices use DLEP to report any link characteristics (data rate, latency, etc.) that have changed. DLEP is independent of the link type and topology the modem supports. 🦋 Also, DLEP is only specified to run on the local link between router and modem. Some over-the-air signaling may be needed between the local and remote modem so that some parameters can be included in DLEP Messages between the local modem and local router, but DLEP doesn't specify how that over-the-air signaling is done. That's purely up to the modem implementer. 🧁
Over-the-air signaling is purely a matter for the modem implementer. DLEP stays out of that lane entirely. 💅
Figure 2 shows how DLEP can support a setup where routers are connected with different link types. 🌈 In this example, Modem Device Type A implements a point-to-point link, and Modem Device Type B is connected via a shared medium. Either way, DLEP is used to report the characteristics of the link (data rate, latency, etc.) to the routers. ⭐ The modem can also use the DLEP session to tell the router when the remote node is lost, which shortens the time needed to reconverge the network. Main character energy 👑
+--------+ +--------+
+----+ Modem | | Modem +---+
| | Device | | Device | |
| | Type A | <===== // ======> | Type A | |
| +--------+ Point-to-Point Link +--------+ |
+---+----+ +---+----+
| Router | | Router |
| | | |
+---+----+ +---+----+
| +--------+ +--------+ |
+-----+ Modem | | Modem | |
| Device | o o o o o o o o | Device +--+
| Type B | o Shared o | Type B |
+--------+ o Medium o +--------+
o o
o o
o o
o
+--------+
| Modem |
| Device |
| Type B |
+---+----+
|
|
+---+----+
| Router |
| |
+--------+
Figure 2: DLEP Network with Multiple Modem Devices2. Protocol Overview 🌸
okay so DLEP defines a set of Messages that modems and their attached routers use to talk about events happening on the physical link(s) the modem manages. 🎀 Examples are a remote node entering or leaving the network, or the link changing. 🦋 Each Message comes with a set of Data Items, which is info describing the remote node (for example, address information) and/or the characteristics of the link to that remote node. 💖 Throughout this doc, we call modems and routers taking part in a DLEP session "DLEP Participants", unless a specific difference (like modem or router) actually matters. ✨
DLEP uses a session-oriented paradigm between the modem device and its associated router. 🫶 If several modem devices are attached to one router (as in Figure 2), or the modem supports multiple connections (via multiple logical or physical interfaces), then separate DLEP sessions exist for each modem or connection. 🧚 A router and modem form a session by finishing the discovery and initialization process. That router-modem session sticks around unless or until it either (1) times out, based on the absence of DLEP traffic (including heartbeats) or (2) is explicitly torn down by one of the DLEP participants. ⏳
Real talk, this document is the working group's best effort to be functionally complete 💅 But it's totally expected that DLEP will need extensions as more link types get used. 🌈 Those extensions are defined as additional Messages, Data Items, and/or status codes, plus associated rules of behavior, none of which are defined in this document. 🍓 DLEP has a standard mechanism that lets router and modem implementations negotiate which extensions to use on a per-session basis. 👑
2.1. Destinations 💖
Okay so the router-modem session is basically a carrier for info about "destinations" 📡 that the modem can reach. Either the router or the modem can identify one, and it's a specific, addressable spot you can get to over the link(s) the modem manages 🦋
So DLEP Messages about destinations are how routers and modems keep an information base in sync 🧚. It covers both the physical and logical destinations reachable through the modem, plus the link characteristics to each one. It's giving shared group notes ✨
A destination can be physical or logical. A physical one is something like a far-end router sitting on the variable-quality network. Here's the important bit: for physical destinations, the Media Access Control (MAC) address is the far-end router's, not the modem's 🙈
A logical destination is Multicast. In IP networks, multicast traffic headed for the variable-quality network (the network you reach through the modem) gets a Layer 2 MAC address derived from its Layer 3 address. DLEP rides on that same scheme, so multicast just gets treated like any other destination in the network 💅
To support logical destinations, one DLEP participant (typically the router) tells the other one that the logical destination exists. Once the modem knows about it, the modem reports link characteristics just like it would for any other destination 🌈. The specific algorithms a modem would use to derive metrics on logical destinations are outside the scope of this specification. Implementations get to decide those for themselves 🌸
In every case, when this specification says "destination", it means the addressable locations, logical or physical, that are accessible by the radio link(s) 🎀
2.2. Conventions and Terminology 📖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Translation: these words only carry their special meaning when they're in ALL CAPS 🔥
3. Requirements ✨
DLEP MUST be implemented on a single Layer 2 domain. The protocol identifies next-hop destinations by using the MAC address for delivering data traffic. No manipulation or substitution is performed. The MAC address supplied in all DLEP Messages is used as the Destination MAC address for frames emitted by the participating router. MAC addresses MUST be unique within the context of the router-modem session 💜
To enforce the single Layer 2 domain, implementations MUST support the Generalized TTL Security Mechanism [RFC5082], and implementations MUST adhere to this specification for all DLEP Messages 🔒
DLEP specifies UDP multicast for single-hop discovery signaling and TCP for transport of the Messages. Modems and routers participating in DLEP sessions MUST have topologically consistent IP addresses assigned. It is RECOMMENDED that DLEP implementations utilize IPv6 link-local addresses to reduce the administrative burden of address assignment 🧁
DLEP relies on the guaranteed delivery of its Messages between router and modem, once the 1-hop discovery process is complete. That's why TCP is the pick for carrying the Messages. Other reliable transports for the protocol are possible, but they're outside the scope of this document 🦋
4. Implementation Scenarios 🌸
During development of this specification, two types of deployments were discussed 🗣️
The first one is the "dedicated deployment". In this mode, DLEP routers and modems are either directly connected (for example, using crossover cables to connect interfaces) or connected to a dedicated switch. An example would be a router with a line-of-sight radio connected into one interface, with a satellite modem connected into another interface. In mobile environments, the router and the connected modem (or modems) are placed into a mobile platform, like a vehicle, boat, or airplane. In this mode, when a switch is used, a small number of ancillary devices (for example, a laptop) might also be plugged into the switch. But either way, the resulting network segment is constrained to a small number of devices and is not generally accessible from anywhere else in the network 🚗
The other type is the "networked deployment". In this scenario, the DLEP router and modem (or modems) are placed on a segment that is accessible from other points in the network. Not only are the DLEP router and modem(s) reachable from other points in the network, but the router and a given modem could also be multiple physical hops away from each other. This scenario necessitates the use of Layer 2 tunneling technology to enforce the single-hop requirement of DLEP 🌐
5. Assumptions 🧠
DLEP assumes that a signaling protocol exists between modems participating in a network. This specification does not define the character or behavior of this over-the-air signaling, but it does expect some information to be carried (or derived) by the signaling. Examples are the arrival and departure of modems from this network, and the variation of the link characteristics between modems. That information is then assumed to be used by the modem to implement DLEP 📡
This specification assumes that the link between router and modem is static with respect to data rate and latency, and that this link is not likely to be the cause of a performance bottleneck. In deployments where the router and modem are physically separated by multiple network hops, served by Layer 2 tunneling technology, DLEP statistics on the RF links could be insufficient for routing protocols to make appropriate routing decisions. This would especially become an issue when the Layer 2 tunnel between router and modem is itself served in part (or in total) by a wireless backhaul link 😬
6. Metrics 📊
DLEP includes the ability for the router and modem to communicate metrics that reflect the characteristics (for example, data rate and latency) of the variable-quality link in use. DLEP does not specify how a given metric value is calculated. Instead, the protocol assumes that metrics have been calculated on a "best effort" basis, incorporating all pertinent data that is available to the modem device. Metrics based on large-enough sample sizes will keep short traffic bursts from skewing reported values 🎀
DLEP allows metrics to be sent within two contexts. One is a specific destination within the network (for example, a specific router). The other is "per session", meaning metrics that apply to all destinations accessed via the modem. Most metrics can be further subdivided into transmit and receive metrics. When metrics are provided at the session level, the router propagates them to all entries in its information base for destinations that are accessed via the modem 💅
DLEP modems announce all metric Data Items that will be reported during the session, and provide default values for those metrics, in the Session Initialization Response Message (Section 12.6). To use a metric type that was not included in the Session Initialization Response Message, modem implementations terminate the session with the router (via the Session Termination Message (Section 12.9)) and establish a new session 🔁
A DLEP modem can send metrics in both (1) a session context, via the Session Update Message (Section 12.7), and (2) a specific destination context, via the Destination Update Message (Section 12.17), at any time. The most recently received metric value takes precedence over any earlier value, regardless of context. That means:
- If the router receives metrics in a specific destination context (via the Destination Update Message), then the specific destination is updated with the new metric.
- If the router receives metrics in a session-wide context (via the Session Update Message), then the metrics for all destinations accessed via the modem are updated with the new metric.
It is left to implementations to choose sensible default values based on their specific characteristics. Modems having static (non-changing) link metric characteristics can report metrics only once for a given destination, or once on a session-wide basis if all connections via the modem are of this static nature 🧊
In addition to communicating existing metrics about the link, DLEP provides a Message that lets a router request a different data rate or latency from the modem. This Message is the Link Characteristics Request Message (Section 12.18). It gives the router the ability to deal with requisite increases (or decreases) of allocated data rate/latency in demand-based schemes in a more deterministic manner 🚀
7. DLEP Session Flow 🦋
All DLEP participants of a session transition through a number of distinct states during the lifetime of a DLEP session 💫
- Peer Discovery
- Session Initialization
- In-Session
- Session Termination
- Session Reset
Modems, and routers supporting DLEP discovery, transition through all five of the above states. Routers that rely on preconfigured TCP address/port information start in the Session Initialization state 🌟
Modems MUST support the Peer Discovery state. 👑
7.1. Peer Discovery State 🔍
Okay so first things first, bestie: modems MUST support DLEP Peer Discovery 💖 Routers MAY support the discovery signals, or they can just rely on a priori configuration to find modems. But if a router decides to do DLEP discovery, all signals MUST be supported ✨
In the Peer Discovery state, routers that support DLEP discovery MUST send Peer Discovery Signals (Section 12.3) to kick off modem discovery 🦋
Then the router waits for a Peer Offer Signal (Section 12.4) response from a potential DLEP modem 👀 While it's in the Peer Discovery state, a DLEP router MUST keep sending Peer Discovery Signals repeatedly, at regular intervals. It is RECOMMENDED that this interval be set to 60 seconds. The interval MUST be a minimum of 1 second, and it SHOULD be a configurable parameter 🎀 Also, this whole thing (sending Peer Discovery and waiting for Peer Offer) is outside the DLEP transaction model (Section 8), because the transaction model only describes Messages on a TCP session. Not the same vibe at all 🙈
Routers that get a Peer Offer Signal MUST use one of the modem address/port combinations from that signal to set up a TCP connection to the modem, even if a priori configuration exists. If there are multiple Connection Point Data Items in the Peer Offer Signal, routers SHOULD prioritize IPv6 connection points over IPv4 ones 🌸 If several connection points use the same transport (like IPv6 or IPv4), implementations MAY use their own heuristics to decide the order they get tried in. If a TCP connection can't be made with any of the address/port combos and the Discovery mechanism is in use, the router SHOULD resume issuing Peer Discovery Signals. And if there are no Connection Point Data Items in the Peer Offer Signal, the router MUST use the source address of the UDP packet that carried the Peer Offer Signal as the IP address, plus the DLEP well-known port number. Main character energy in the fallback plan 👑
In the Peer Discovery state, the modem implementation MUST listen for incoming Peer Discovery Signals on the DLEP well-known IPv6 and/or IPv4 link-local multicast address and port 👂 When it gets a valid Peer Discovery Signal, it MUST reply with a Peer Offer Signal.
Modems MUST be prepared to accept a TCP connection from a router that isn't using the Discovery mechanism, so a connection attempt that shows up without a preceding Peer Discovery Signal. Be ready for anyone to slide into the DMs 💅
Implementations of DLEP SHOULD implement, and use, Transport Layer Security (TLS) [RFC5246] to protect the TCP session 🔐 The "dedicated deployments" discussed in "Implementation Scenarios" (Section 4) MAY consider using DLEP without TLS. For all "networked deployments" (again, from "Implementation Scenarios"), implementing and using TLS is STRONGLY RECOMMENDED 🫶 If TLS is going to be used, the TLS session MUST be established before any Messages are passed between peers. And routers that support TLS MUST prioritize connection points that use TLS over the ones that don't ✨
Once the TCP connection is up, and the TLS session is up too if TLS is in use, both modem and router enter the Session Initialization state 🎉 It's up to the router implementation whether Peer Discovery Signals keep getting sent after the device moves into the Session Initialization state. Modem implementations MUST silently ignore Peer Discovery Signals from a router that the implementation already has a TCP connection with. Ignore the repeat knocks, babe 🙄
7.2. Session Initialization State 🌈
When the router enters the Session Initialization state, it MUST send a Session Initialization Message (Section 12.5) to the modem. Then the router MUST wait to receive a Session Initialization Response Message (Section 12.6) from the modem. If that response has a Status Data Item (Section 13.1) with status code set to 0 'Success' (see Table 2 in Section 13.1), it means the modem got and processed the Session Initialization Message, and the router MUST transition to the In-Session state 🥳
When the modem enters the Session Initialization state, it MUST wait to receive a Session Initialization Message from the router. Once it gets one, the modem MUST send a Session Initialization Response Message, and the session MUST transition to the In-Session state. But if the modem gets any Message other than Session Initialization, or it can't parse the Message it received, it MUST NOT send any Message. Instead, it MUST terminate the TCP connection and transition to the Session Reset state 💀
DLEP has an extension negotiation capability that's used in the Session Initialization state. Check out Section 9 for the deets 🧚 Extensions that an implementation supports MUST be declared to potential DLEP participants using the Extensions Supported Data Item (Section 13.6). Once both DLEP participants have swapped initialization Messages, an implementation MUST NOT emit any Message, Signal, Data Item, or status code tied to an extension that wasn't specified in the initialization Message it got from its peer. Don't talk about features your bestie never agreed to 🙅♀️
7.3. In-Session State 💜
In the In-Session state, Messages can flow both ways between DLEP participants. They can signal changes to the session state, the arrival or departure of reachable destinations, or changes in the state of the links to those destinations. This is the main event 🎬
The In-Session state sticks around until one of these things happens:
- The implementation ends the session by sending a Session Termination Message (Section 12.9), or
- Its peer ends the session, which the implementation notices by receiving a Session Termination Message.
Then the implementation MUST transition to the Session Termination state 🚪
7.3.1. Heartbeats 💓
To keep the In-Session state alive, periodic Heartbeat Messages (Section 12.20) MUST be exchanged between router and modem. These Messages keep the session alive and check that the two DLEP participants can still reach each other both ways 📡 It is RECOMMENDED that the interval timer between Heartbeat Messages be set to 60 seconds. The interval MUST be a minimum of 1 second, and it SHOULD be a configurable parameter.
Each DLEP participant is responsible for creating its own Heartbeat Messages 🫧
Getting any valid DLEP Message MUST reset the heartbeat interval timer. In other words, valid DLEP Messages take the place of Heartbeat Messages and make them unnecessary for that stretch of time ✨
An implementation MUST allow a minimum of 2 heartbeat intervals to expire with no Messages from its peer before it terminates the session. When it does terminate, it MUST send a Session Termination Message containing a Status Data Item (Section 13.1) with status code set to 132 'Timed Out' (see Table 2), and then the implementation MUST transition to the Session Termination state. Ghosting has consequences, fr fr 👻
7.4. Session Termination State 🛑
When an implementation enters the Session Termination state after sending a Session Termination Message (Section 12.9) because of an invalid Message or an error, it MUST wait for a Session Termination Response Message (Section 12.10) from its peer. A sender SHOULD allow 4 heartbeat intervals to expire before deciding its peer is unresponsive and before carrying on with session termination. Any other Message received while waiting MUST be silently ignored 🤫
When the sender of the Session Termination Message gets a Session Termination Response Message from its peer, or times out, it MUST transition to the Session Reset state.
When an implementation gets a Session Termination Message from its peer, it enters the Session Termination state. Then it MUST immediately send a Session Termination Response and transition to the Session Reset state 🌷
7.5. Session Reset State 🧹
In the Session Reset state, the implementation MUST perform the following actions:
- Release all resources allocated for the session.
- Eliminate all destinations in the information base represented by the session. Destination Down Messages (Section 12.15) MUST NOT be sent.
- Terminate the TCP connection.
Once those actions are done, the implementation SHOULD return to the relevant initial state:
- For modems: Peer Discovery.
- For routers: either Peer Discovery or Session Initialization, depending on configuration.
Clean slate, fresh start 🍓
7.5.1. Unexpected TCP Connection Termination 😱
If the TCP connection between DLEP participants gets terminated while an implementation is not in the Session Reset state, the implementation MUST immediately transition to the Session Reset state. Plot twist, but we handle it 💅
8. Transaction Model 🔄
DLEP defines a simple Message transaction model. Only one request per destination may be in progress at a time per session. A Message transaction counts as complete once a response matching a previously issued request comes back 📬 If a DLEP participant gets a request for a destination that already has an outstanding request, the implementation MUST terminate the session by issuing a Session Termination Message (Section 12.9) containing a Status Data Item (Section 13.1) with status code set to 129 'Unexpected Message' (see Table 2), and then transition to the Session Termination state. There's no limit on the total number of Message transactions in progress at a time, as long as each transaction refers to a different destination 🎀
Some requests can take a looong time for some DLEP participants to finish. For example, a modem handling a multicast Destination Up request might have to do a complex network reconfiguration 🌐 A sending implementation MUST be able to handle these long-running transactions gracefully 🫶
Also, only one session request can be in progress at a time per session. An example is a Session Initialization Message (Section 12.5). As noted above for Message transactions, a session transaction is complete once a response matching a previously issued request is received. If a DLEP participant gets a session request while another session request is already in progress, it MUST terminate the session by issuing a Session Termination Message containing a Status Data Item with status code set to 129 'Unexpected Message', and then transition to the Session Termination state. While a session transaction is in progress, only the Session Termination Message may be issued. Heartbeat Messages (Section 12.20) MUST NOT be considered part of a session transaction 🙅♀️
DLEP transactions don't time out and can't be cancelled, except for transactions in flight when the DLEP session is reset. If the session is terminated, canceling transactions in progress MUST be performed as part of resetting the state machine. And an implementation can detect whether its peer has failed in some way by using the session heartbeat mechanism during the In-Session state; see Section 7.3 🔍
9. Extensions ✨
Okay bestie, extensions are where the protocol gets to show off 💅. Extensions MUST be negotiated on a per-session basis during session initialization via the Extensions Supported mechanism. Implementations are not required to support any extensions in order to be considered DLEP compliant, so nobody's forced into the glam squad 🫶.
If interoperable protocol extensions are required, they will need to be standardized as either (1) an update to this document or (2) an additional standalone specification. The IANA registries defined in Section 15 of this document have plenty of unassigned space for DLEP Signals, Messages, Data Items, and status codes, so future extensions have room to grow 🌱.
As multiple protocol extensions MAY be announced during session initialization, authors of protocol extensions need to think about how their extension plays with other published ones and spell out any incompatibilities 🧚.
9.1. Experiments
This document registers Private Use [RFC5226] numbering space in the DLEP Signal, Message, Data Item, and status code registries for experimental extensions 🧪. The goal is to let people try out new Signals, Messages, Data Items, and/or status codes while still keeping the documented DLEP behavior intact.
During session initialization, the use of the Private Use Signals, Messages, Data Items, status codes, or behaviors MUST be announced as DLEP extensions. You use extension identifiers from the Private Use space in the "Extension Type Values" registry (Table 3), and the value has to be agreed upon (a priori) between the participants 🤝. DLEP extensions using the Private Use numbering space are commonly called "experiments" 🔬.
Multiple experiments MAY be announced in the Session Initialization Messages. Honestly though, running several experiments in one session could lead to interoperability issues or unexpected results (for example, clashes of experimental Signals, Messages, Data Items, and/or status code types) 😬, so it's discouraged. If conflicts do show up, it's up to each implementation to decide what to do next, like terminating the session or picking a precedence between the conflicting definitions 🤷♀️.
10. Scalability
The protocol is intended to support thousands of destinations on a given modem/router pair 🌍. At that scale, an implementation should consider using techniques that stop it from flooding its peer with a large number of Messages in a short time 🚿. For example, a dampening algorithm could be used to stop a flapping device from generating a huge pile of Destination Up / Destination Down Messages. Main character energy, but make it calm 😌.
Also, hysteresis can soften the impact of rapid, minor fluctuations in link quality 🌊. The specific algorithms for handling flapping destinations and minor changes in link quality are outside the scope of this specification, so you'll have to figure those out on your own 💅.
11. DLEP Signal and Message Structure
DLEP has two protocol units that get used in two different ways: Signals and Messages 💌. Signals are only used in the Discovery mechanism and are carried in UDP datagrams 📦. Messages go back and forth bidirectionally over a TCP connection between the participants, during the Session Initialization, In-Session, and Session Termination states 💬.
Both Signals and Messages are a Header followed by an unordered list of Data Items. Headers hold Type and Length information, and Data Items are encoded as TLV (Type-Length-Value) structures 🎀. In this document, the Data Items that follow a Signal or Message Header are described as being "contained in" the Signal or Message.
There's no restriction on the order of Data Items after a Header 🙌. Whether duplicate Data Items are acceptable depends on the definition of the Signal or Message declared by the type in the Header.
All integers in Header fields and values MUST be in network byte order. No exceptions, no drama 🔢.
11.1. DLEP Signal Header
The DLEP Signal Header has 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 'D' | 'L' | 'E' | 'P' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3: DLEP Signal Header
"DLEP": Every Signal MUST start with the following characters: U+0044, U+004C, U+0045, U+0050. It's the signature that says "this is DLEP, babe" 💖.
Signal Type: A 16-bit unsigned integer containing one of the DLEP Signal Type values defined in this document 🏷️.
Length: The length in octets, expressed as a 16-bit unsigned integer, of all of the DLEP Data Items contained in this Signal. This length MUST NOT include the length of the Signal Header itself. The header doesn't count itself, obviously 🙈.
The DLEP Signal Header is immediately followed by zero or more DLEP Data Items, encoded in TLVs, as defined in this document ✨.
11.2. DLEP Message Header
The DLEP Message Header has 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4: DLEP Message Header
Message Type: A 16-bit unsigned integer containing one of the DLEP Message Type values defined in this document 📨.
Length: The length in octets, expressed as a 16-bit unsigned integer, of all of the DLEP Data Items contained in this Message. This length MUST NOT include the length of the Message Header itself 🫠.
The DLEP Message Header is immediately followed by zero or more DLEP Data Items, encoded in TLVs, as defined in this document 💅.
11.3. DLEP Generic Data Item
All DLEP Data Items contain 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... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 5: DLEP Generic Data Item
Data Item Type: A 16-bit unsigned integer field that specifies the type of Data Item being sent 🧩.
Length: The length in octets, expressed as a 16-bit unsigned integer, of the Value field of the Data Item. This length MUST NOT include the length of the Data Item Type and Length fields 📏.
Value: A field of <Length> octets that holds data specific to a particular Data Item 🎁.
12. DLEP Signals and Messages
12.1. General Processing Rules
Here's the rulebook for handling Signals and Messages, and it's serious business 📜. If an unrecognized or unexpected Signal is received, or if a received Signal contains unrecognized, invalid, or disallowed duplicate Data Items, the receiving implementation MUST ignore the Signal. Bye bye, not today 🚫.
If a Signal is received with a TTL value that is NOT equal to 255, the receiving implementation MUST ignore the Signal 🙅♀️.
If an unrecognized Message is received, the receiving implementation MUST issue a Session Termination Message (Section 12.9) containing a Status Data Item (Section 13.1) with status code set to 128 'Unknown Message' (see Table 2), and then transition to the Session Termination state. Nope, we don't know that one 💀.
If an unexpected Message is received, the receiving implementation MUST issue a Session Termination Message containing a Status Data Item with status code set to 129 'Unexpected Message' and transition to the Session Termination state 😵.
If a received Message contains unrecognized, invalid, or disallowed duplicate Data Items, the receiving implementation MUST issue a Session Termination Message containing a Status Data Item with status code set to 130 'Invalid Data' and transition to the Session Termination state 🚨.
If a packet in the TCP stream is received with a TTL value other than 255, the receiving implementation MUST immediately transition to the Session Reset state. Immediately. No second chances 🔁.
Before the exchange of Destination Up (Section 12.11) and Destination Up Response (Section 12.12) Messages, or Destination Announce (Section 12.13) and Destination Announce Response (Section 12.14) Messages, no Messages concerning a destination may be sent. If an implementation receives any Message with such an unannounced destination, it MUST terminate the session by issuing a Session Termination Message containing a Status Data Item with status code set to 131 'Invalid Destination' and transition to the Session Termination state. You can't gossip about someone who hasn't been introduced yet 🙈.
After exchanging Destination Down (Section 12.15) and Destination Down Response (Section 12.16) Messages, no Messages concerning a destination may be sent until a new Destination Up or Destination Announce Message is sent. An implementation receiving a Message about a destination previously announced as 'down' MUST terminate the session by issuing a Session Termination Message containing a Status Data Item with status code set to 131 'Invalid Destination' and transition to the Session Termination state. Once it's gone, it's gone, unless it comes back with a fresh Up or Announce 🥀.
12.2. Status Code Processing
The behavior of a DLEP participant that receives a Message containing a Status Data Item (Section 13.1) is defined by the failure mode associated with the value of the status code field; see Table 2. All status code values less than 100 have a failure mode of 'Continue'. All other status codes have a failure mode of 'Terminate'. So basically, under 100 is chill, and 100 and up is a whole situation 😤.
A DLEP participant that receives any Message apart from a Session Termination Message (Section 12.9) containing a Status Data Item with a status code value whose failure mode is 'Terminate' MUST immediately issue a Session Termination Message echoing the received Status Data Item, and then transition to the Session Termination state 🛑.
A DLEP participant that receives a Message containing a Status Data Item with a status code value whose failure mode is 'Continue' can continue normal operation of the session. Carry on, queen 👑.
12.3. Peer Discovery Signal
A Peer Discovery Signal SHOULD be sent by a DLEP router to discover DLEP modems in the network; see Section 7.1 🔍. It's the "hello, is anyone out there?" moment 📣.
A Peer Discovery Signal MUST be encoded within a UDP packet. The destination MUST be set to the DLEP well-known address and port number. For routers supporting both IPv4 and IPv6 DLEP operation, it is RECOMMENDED that IPv6 be selected as the transport 🌐. The source IP address MUST be set to the router IP address associated with the DLEP interface. There is no DLEP-specific restriction on source port, so you get to pick that one freely 🎀.
To construct a Peer Discovery Signal, the Signal Type value in the Signal Header is set to 1 (see "Signal Type Registration" (Section 15.2)) 🧁.
The Peer Discovery Signal MAY contain a Peer Type Data Item (Section 13.4) 🫧.
12.4. Peer Offer Signal 💖
okay so a Peer Offer Signal MUST be sent by a DLEP modem whenever it gets a properly formatted and addressed Peer Discovery Signal (Section 12.3). it's giving "hiii, I'm here" 🦋
A Peer Offer Signal MUST be encoded within a UDP packet. The IP source and destination fields in the packet MUST be set by swapping the values received in the Peer Discovery Signal. This is the moment the discovery process wraps up, so see Section 7.1 for the full tea ☕
To build one, the Signal Type value in the Signal Header gets set to 2 (see "Signal Type Registration" (Section 15.2)) ✨
The Peer Offer Signal MAY contain a Peer Type Data Item (Section 13.4) 🎀
The Peer Offer Signal MAY also contain one or more of any of the following Data Items, with different values:
- IPv4 Connection Point (Section 13.2) 🌸
- IPv6 Connection Point (Section 13.3) 🌸
The IPv4 and IPv6 Connection Point Data Items tell everyone the unicast address the router MUST use when connecting the DLEP TCP session. main character address energy 👑
12.5. Session Initialization Message 🧚
A Session Initialization Message MUST be sent by a DLEP router as the first Message of the DLEP TCP session. The router sends it after a TCP connect to an address/port combination it got either from a Peer Offer or from a priori configuration. bestie is introducing herself at the door 🚪
To build one, the Message Type value in the Message Header is set to 1 (see "Message Type Registration" (Section 15.3)) 💅
The Session Initialization Message MUST contain one of each of the following Data Items:
- Heartbeat Interval (Section 13.5) 💜
- Peer Type (Section 13.4) 💜
If DLEP extensions are supported, the Session Initialization Message MUST contain an Extensions Supported Data Item (Section 13.6). no skipping this one bestie 🙈
The Session Initialization Message MAY contain one or more of each of the following Data Items, with different values and with the Add/Drop (A) flag (Section 13) set to 1:
- IPv4 Address (Section 13.8) 🍓
- IPv6 Address (Section 13.9) 🍓
- IPv4 Attached Subnet (Section 13.10) 🍓
- IPv6 Attached Subnet (Section 13.11) 🍓
If any optional extensions are supported by the implementation, they MUST be listed in the Extensions Supported Data Item. If there's no Extensions Supported Data Item in a Session Initialization Message, the modem MUST conclude that the router doesn't support extensions. it's not being rude, it's just the rule 🫶
DLEP Heartbeats don't start until the Session Initialization Response Message arrives (Section 12.6), so implementations MUST use their own timeout heuristics for this Message. ngl that's a little scary but we got this ⏰
As an exception to the general rule for handling an unrecognized Data Item in a Message (see Section 12.1): if a Session Initialization Message has one or more Extensions Supported Data Items announcing extensions the implementation doesn't recognize, then the implementation MAY ignore the Data Items it doesn't recognize. 🌈
12.6. Session Initialization Response Message 🦋
A Session Initialization Response Message MUST be sent by a DLEP modem in response to a received Session Initialization Message (Section 12.5). this is the reply that says "yes, let's do this" 💖
To build one, the Message Type value in the Message Header is set to 2 (see "Message Type Registration" (Section 15.3)) ✨
The Session Initialization Response Message MUST contain one of each of the following Data Items:
- Status (Section 13.1) 💜
- Peer Type (Section 13.4) 💜
- Heartbeat Interval (Section 13.5) 💜
- Maximum Data Rate (Receive) (Section 13.12) 💜
- Maximum Data Rate (Transmit) (Section 13.13) 💜
- Current Data Rate (Receive) (Section 13.14) 💜
- Current Data Rate (Transmit) (Section 13.15) 💜
- Latency (Section 13.16) 💜
The Session Initialization Response Message MUST contain one of each of the following Data Items, if the Data Item will be used during the lifetime of the session:
- Resources (Section 13.17) 🌸
- Relative Link Quality (Receive) (Section 13.18) 🌸
- Relative Link Quality (Transmit) (Section 13.19) 🌸
- Maximum Transmission Unit (MTU) (Section 13.20) 🌸
If DLEP extensions are supported, the Session Initialization Response Message MUST contain an Extensions Supported Data Item (Section 13.6). again, don't skip it 🙈
The Session Initialization Response Message MAY contain one or more of each of the following Data Items, with different values and with the Add/Drop (A) flag (Section 13) set to 1:
- IPv4 Address (Section 13.8) 🍓
- IPv6 Address (Section 13.9) 🍓
- IPv4 Attached Subnet (Section 13.10) 🍓
- IPv6 Attached Subnet (Section 13.11) 🍓
This Message completes the DLEP session establishment. The modem should move to the In-Session state when it sends the Message, and the router should move to the In-Session state once it receives an acceptable Session Initialization Response Message. we're officially in a relationship with the session now 💍
All supported metric Data Items MUST be included in the Session Initialization Response Message, with default values to be used on a session-wide basis. Basically the modem is "declaring" every metric it supports right at session start 📣
Any later DLEP Message that has a metric Data Item NOT included in the Session Initialization Response Message MUST be treated as an error, which terminates the DLEP session between router and modem. 💀 no sneaky new metrics allowed
If any optional extensions are supported by the modem, they MUST be listed in the Extensions Supported Data Item. If there's no Extensions Supported Data Item in a Session Initialization Response Message, the router MUST conclude that the modem doesn't support extensions. 🫶
After the Session Initialization and Session Initialization Response Messages have been successfully exchanged, implementations MUST only use extensions that are supported by both DLEP participants; see Section 7.2. both sides have to agree or it's a no 🙅♀️
12.7. Session Update Message 🌈
A Session Update Message MAY be sent by a DLEP participant, on a session-wide basis, to share local Layer 3 address changes and/or metric changes. it's the "hey, something changed" text 📱
To build one, the Message Type value in the Message Header is set to 3 (see "Message Type Registration" (Section 15.3)) 💅
The Session Update Message MAY contain one or more of each of the following Data Items, with different values:
- IPv4 Address (Section 13.8) 🍓
- IPv6 Address (Section 13.9) 🍓
- IPv4 Attached Subnet (Section 13.10) 🍓
- IPv6 Attached Subnet (Section 13.11) 🍓
When a modem sends it, the Session Update Message MAY contain one of each of the following Data Items:
- Maximum Data Rate (Receive) (Section 13.12) 💜
- Maximum Data Rate (Transmit) (Section 13.13) 💜
- Current Data Rate (Receive) (Section 13.14) 💜
- Current Data Rate (Transmit) (Section 13.15) 💜
- Latency (Section 13.16) 💜
When a modem sends it, the Session Update Message MAY also contain one of each of the following Data Items, if the Data Item is in use by the session:
- Resources (Section 13.17) 🌸
- Relative Link Quality (Receive) (Section 13.18) 🌸
- Relative Link Quality (Transmit) (Section 13.19) 🌸
- Maximum Transmission Unit (MTU) (Section 13.20) 🌸
If metrics come with the Session Update Message (for example, Maximum Data Rate), those metrics count as session-wide, so they MUST be applied to all destinations in the information base associated with the DLEP session. That includes destinations whose metrics may have been stored from earlier Destination Update messages. the whole squad gets the update 👯♀️
It should be noted that Session Update Messages can be sent by both routers and modems. For example, adding an IPv4 address on the router MAY prompt a Session Update Message to its attached modems. Also, a modem that changes its Maximum Data Rate (Receive) for all destinations MAY share that change with a Session Update Message to its attached router(s). 🔥
About Layer 3 addresses and subnets: if the modem can understand and forward this information (through mechanisms DLEP doesn't define), the update would prompt any remote DLEP-enabled modems to send a Destination Update Message (Section 12.17) to their local routers with the new (or deleted) addresses and subnets. it's like a group chat chain reaction 💬✨
12.8. Session Update Response Message 💜
A Session Update Response Message MUST be sent by a DLEP participant when it receives a Session Update Message (Section 12.7). reply to every text, periodt 💅
To build one, the Message Type value in the Message Header is set to 4 (see "Message Type Registration" (Section 15.3)) ✨
The Session Update Response Message MUST contain a Status Data Item (Section 13.1). 🌸
12.9. Session Termination Message 🥀
When a DLEP participant decides the DLEP session needs to end, that participant MUST send (or attempt to send) a Session Termination Message. it's the "ok bye" text, and it still has to go out 📴
To build one, the Message Type value in the Message Header is set to 5 (see "Message Type Registration" (Section 15.3)) 💅
The Session Termination Message MUST contain a Status Data Item (Section 13.1). ✨
It should be noted that Session Termination Messages can be sent by both routers and modems. no one gets to be the only one who ghosts 👻
12.10. Session Termination Response Message 🦋
A Session Termination Response Message MUST be sent by a DLEP participant when it receives a Session Termination Message (Section 12.9). the "seen" receipt 👀
To build one, the Message Type value in the Message Header is set to 6 (see "Message Type Registration" (Section 15.3)) 💅
There are no valid Data Items for the Session Termination Response Message. it's a short and sweet message, no extras needed 🌸
Receiving a Session Termination Response Message completes the teardown of the DLEP session; see Section 7.4. and that's the end of the chapter, bestie 🎀✨
12.11. Destination Up Message 🦋
okay so bestie, the Destination Up Message is how a modem tells its attached router "heyyy, there's a new reachable destination out here!" 💖 Modems are allowed to send these (MAY), and the whole point is to let the router know someone new just showed up in the neighbourhood 🏘️✨
to build one, you set the Message Type in the Message Header to 7 (check out "Message Type Registration" in Section 15.3, it's giving organised 📋).
the MUST-have is a MAC Address Data Item (Section 13.7). no MAC address, no party 🙅♀️💅
you SHOULD include one or more of each of these, with different values 🌸:
- IPv4 Address (Section 13.8)
- IPv6 Address (Section 13.9)
you MAY also include one of each of these, if you want to flex the link stats 📈:
- Maximum Data Rate (Receive) (Section 13.12)
- Maximum Data Rate (Transmit) (Section 13.13)
- Current Data Rate (Receive) (Section 13.14)
- Current Data Rate (Transmit) (Section 13.15)
- Latency (Section 13.16)
and you MAY include one of each of these, but only if that Data Item is actually in use by the session 🧚:
- Resources (Section 13.17)
- Relative Link Quality (Receive) (Section 13.18)
- Relative Link Quality (Transmit) (Section 13.19)
- Maximum Transmission Unit (MTU) (Section 13.20)
and finally you MAY include one or more of each of these, with different values 🌈:
- IPv4 Attached Subnet (Section 13.10)
- IPv6 Attached Subnet (Section 13.11)
when a router gets a Destination Up Message, it allocates the resources it needs and makes an entry in its information base with all the juicy details (MAC Address, Latency, Data Rate, etc.) 🎀 that info then sticks around until a Destination Down Message (Section 12.15) shows up. that happens when the modem has lost contact with the remote node, or when the implementation moves into the Session Termination state. ngl that's a lot of responsibility for one little entry 🥺💜
12.12. Destination Up Response Message 💌
a router MUST send a Destination Up Response Message whenever a Destination Up Message (Section 12.11) comes in. no ghosting allowed 👻🚫
to build it, set the Message Type to 8 (see "Message Type Registration" (Section 15.3), obviously 💅).
this one MUST contain one of each of these:
- MAC Address (Section 13.7)
- Status (Section 13.1)
if the router wants to keep hearing about that destination (the one from the matching Destination Up Message), it MUST set the Status Data Item's status code to 0 'Success'. see Table 2 for the full list of codes 📋✨
if the router is just not that into the destination, it MAY set the status code to 1 'Not Interested' instead 🙄
and here's the tea 🫖: if a modem gets a Destination Up Response Message with any status code that isn't 0 'Success', it MUST NOT send any more Destination messages about that destination with the same MAC address. so that means no Destination Down (Section 12.15) and no Destination Update (Section 12.17) either. the vibe is "we're not talking about this one anymore" 🙊💀
12.13. Destination Announce Message 📣
okay so usually, a modem finds one or more remote router/modem pairs and announces each destination's arrival by sending a Destination Up Message (Section 12.11) to the router. easy peasy 🍓
but sometimes a router wants to show interest in a destination that nobody has announced yet, which is typically a multicast destination. that's where Destination Announce Messages come in 🎤 a router MAY send one to announce that interest.
a router MAY also send one to ask for info about a destination in two situations: (1) it previously declined interest with the 1 'Not Interested' status code in a Destination Up Response Message (Section 12.12) (see Table 2), or (2) the destination was previously declared 'down' with a Destination Down Message (Section 12.15). second chances, bestie 🦋💜
to build it, set the Message Type to 9 (see "Message Type Registration" (Section 15.3) 💅).
this one MUST contain a MAC Address Data Item (Section 13.7). and it MAY contain zero or more of each of these, with different values:
- IPv4 Address (Section 13.8)
- IPv6 Address (Section 13.9)
here's the big idea behind DLEP 🧠✨: the modem already knows how the links between remote destinations are connected, so routers can skip the probing neighbour discovery stuff. that's why modem implementations SHOULD announce available destinations with Destination Up Messages, instead of leaning on Destination Announce Messages. efficiency is everything, periodt 🔥
12.14. Destination Announce Response Message 🌷
a modem MUST send a Destination Announce Response Message whenever a Destination Announce Message (Section 12.13) is received. the modem has to answer, no exceptions 🫶
set the Message Type to 10 (see "Message Type Registration" (Section 15.3)) to build this one 🧚
this one MUST contain one of each of these:
- MAC Address (Section 13.7)
- Status (Section 13.1)
it MAY contain one or more of each of these, with different values:
- IPv4 Address (Section 13.8)
- IPv6 Address (Section 13.9)
- IPv4 Attached Subnet (Section 13.10)
- IPv6 Attached Subnet (Section 13.11)
it MAY also contain one of each of these:
- Maximum Data Rate (Receive) (Section 13.12)
- Maximum Data Rate (Transmit) (Section 13.13)
- Current Data Rate (Receive) (Section 13.14)
- Current Data Rate (Transmit) (Section 13.15)
- Latency (Section 13.16)
and it MAY contain one of each of these, if the Data Item is in use by the session:
- Resources (Section 13.17)
- Relative Link Quality (Receive) (Section 13.18)
- Relative Link Quality (Transmit) (Section 13.19)
- Maximum Transmission Unit (MTU) (Section 13.20)
if the modem can't report the info right away (like if the destination isn't reachable at the moment), the status code in the Status Data Item MUST be set to 2 'Request Denied'. see Table 2 📋
after the modem sends a Destination Announce Response Message with a status code of 0 'Success', it then announces any changes to the link to the destination through Destination Update Messages 📣✨
and when a successful Destination Announce Response Message gets received, the router SHOULD add the available destination to its information base 💜
12.15. Destination Down Message 📉
a modem MUST send a Destination Down Message to report when a destination (a remote node or a multicast group) is no longer reachable. that's a big deal, so it's a MUST 😭
a router MAY send one too, to say it doesn't need info about a destination anymore 🫖
set the Message Type to 11 (see "Message Type Registration" (Section 15.3)) to build it 💅
it MUST contain a MAC Address Data Item (Section 13.7). no MAC address, no message 🙅♀️
and here's a fun fact 🌈: both the modem and the router are allowed to send a Destination Down Message to their peer, no matter which one originally said the destination was 'up'. it's giving equal opportunity 💖
12.16. Destination Down Response Message 🎀
a Destination Down Response Message MUST be sent by whoever receives a Destination Down Message (Section 12.15). it confirms that the relevant data about that destination has been removed from the information base. so the receiver is basically saying "yep, it's gone from my list" 🗑️✅
set the Message Type to 12 (see "Message Type Registration" (Section 15.3)) 🧚
this one MUST contain one of each of these:
- MAC Address (Section 13.7)
- Status (Section 13.1)
12.17. Destination Update Message 🔄
a modem SHOULD send a Destination Update Message when it notices a change in the information base for a given destination (a remote node or a multicast group). some changes that would prompt one are:
- Change in link metrics (e.g., data rates)
- Layer 3 addressing change
set the Message Type to 13 (see "Message Type Registration" (Section 15.3)) 💅
it MUST contain a MAC Address Data Item (Section 13.7) 💜
it MAY contain one of each of these:
- Maximum Data Rate (Receive) (Section 13.12)
- Maximum Data Rate (Transmit) (Section 13.13)
- Current Data Rate (Receive) (Section 13.14)
- Current Data Rate (Transmit) (Section 13.15)
- Latency (Section 13.16)
and it MAY contain one of each of these, if the Data Item is in use by the session:
- Resources (Section 13.17)
- Relative Link Quality (Receive) (Section 13.18)
- Relative Link Quality (Transmit) (Section 13.19)
- Maximum Transmission Unit (MTU) (Section 13.20)
and it MAY contain one or more of each of these, with different values:
- IPv4 Address (Section 13.8)
- IPv6 Address (Section 13.9)
- IPv4 Attached Subnet (Section 13.10)
- IPv6 Attached Subnet (Section 13.11)
metrics in this Message overwrite any metrics from a previously received Session Message, Destination Message, or Link Characteristics Message (e.g., Session Initialization, Destination Up, Link Characteristics Response). so the newest numbers win 📊✨
it should be noted that this Message has no corresponding response. it's a one-way street, bestie 🛣️🌸
12.18. Link Characteristics Request Message 🚦
a router MAY send a Link Characteristics Request Message to ask the modem to change specific characteristics of the link. the request can point at a real destination (like a remote node) or a logical one (like a multicast group) in the network 🌐💕
set the Message Type to 14 (see "Message Type Registration" (Section 15.3)) 🎀
this one MUST contain a MAC Address Data Item (Section 13.7) 🙅♀️
it also MUST contain at least one of each of these:
- Current Data Rate (Receive) (Section 13.14)
- Current Data Rate (Transmit) (Section 13.15)
- Latency (Section 13.16)
it MAY contain a Current Data Rate (Receive) (CDRR) or Current Data Rate (Transmit) (CDRT) Data Item if it wants a different data rate than what's currently allocated. it MAY also contain a Latency Data Item if it wants traffic delay on the link to not exceed a specified value. it can do both, too 🧁
and a heads-up 🙈: a router SHOULD be aware that a request may take an extended period of time to complete. patience is a virtue, bestie 🫶💜
12.19. Link Characteristics Response Message ✨
okay bestie, this is the reply to the Link Characteristics Request from Section 12.18 🦋 A modem MUST send one whenever that request comes in 💅
To build it, set the Message Type value in the Message Header to 15 (see "Message Type Registration" (Section 15.3)) 🎀
The Link Characteristics Response Message MUST contain one of each of these Data Items 🫶
- MAC Address (Section 13.7)
- Status (Section 13.1)
It SHOULD also contain one of each of these, so the other side gets the full picture 💜
- Maximum Data Rate (Receive) (Section 13.12)
- Maximum Data Rate (Transmit) (Section 13.13)
- Current Data Rate (Receive) (Section 13.14)
- Current Data Rate (Transmit) (Section 13.15)
- Latency (Section 13.16)
It MAY also contain one of each of these, but only if the session is actually using that Data Item 🌸
- Resources (Section 13.17)
- Relative Link Quality (Receive) (Section 13.18)
- Relative Link Quality (Transmit) (Section 13.19)
- Maximum Transmission Unit (MTU) (Section 13.20)
The Link Characteristics Response Message MUST contain a complete set of metric Data Items, covering every metric declared in the Session Initialization Response Message (Section 12.6) ✨ The values in those metric Data Items MUST reflect the link characteristics after the request has been processed 🔥
If an implementation can't change the link the way it was asked to, the status code of the Status Data Item MUST be set to 2 'Request Denied'; see Table 2 😭 Denied, but iconic about it 💀
12.20. Heartbeat Message 🧚
A Heartbeat Message MUST be sent by a DLEP participant every N milliseconds 🌈 The N is defined in the Heartbeat Interval Data Item (Section 13.5) of the Session Initialization Message (Section 12.5) or the Session Initialization Response Message (Section 12.6) ⭐
To construct one, set the Message Type value in the Message Header to 16 (see "Message Type Registration" (Section 15.3)) 🍓
There are no valid Data Items for the Heartbeat Message. Zero Data Items, full vibes 🙈
The Heartbeat Message is how DLEP participants figure out when a DLEP session peer (either the modem or the router) has stopped communicating; see Section 7.3.1 🫶 It's basically the "u still there?" text of the protocol 💖
13. DLEP Data Items 🎀
okay so here's the big list of core DLEP Data Items, with their type codes 🌸 Table 1 is the whole catalogue, so save it bestie 💅
+-------------+-----------------------------------------------------+
| Type Code | Description |
+-------------+-----------------------------------------------------+
| 0 | Reserved |
| | |
| 1 | Status (Section 13.1) |
| | |
| 2 | IPv4 Connection Point (Section 13.2) |
| | |
| 3 | IPv6 Connection Point (Section 13.3) |
| | |
| 4 | Peer Type (Section 13.4) |
| | |
| 5 | Heartbeat Interval (Section 13.5) |
| | |
| 6 | Extensions Supported (Section 13.6) |
| | |
| 7 | MAC Address (Section 13.7) |
| | |
| 8 | IPv4 Address (Section 13.8) |
| | |
| 9 | IPv6 Address (Section 13.9) |
| | |
| 10 | IPv4 Attached Subnet (Section 13.10) |
| | |
| 11 | IPv6 Attached Subnet (Section 13.11) |
| | |
| 12 | Maximum Data Rate (Receive) (MDRR) (Section 13.12) |
| | |
| 13 | Maximum Data Rate (Transmit) (MDRT) (Section 13.13) |
| | |
| 14 | Current Data Rate (Receive) (CDRR) (Section 13.14) |
| | |
| 15 | Current Data Rate (Transmit) (CDRT) (Section 13.15) |
| | |
| 16 | Latency (Section 13.16) |
| | |
| 17 | Resources (RES) (Section 13.17) |
| | |
| 18 | Relative Link Quality (Receive) (RLQR) |
| | (Section 13.18) |
| | |
| 19 | Relative Link Quality (Transmit) (RLQT) |
| | (Section 13.19) |
| | |
| 20 | Maximum Transmission Unit (MTU) (Section 13.20) |
| | |
| 21-65407 | Unassigned (available for future extensions) |
| | |
| 65408-65534 | Reserved for Private Use (available for |
| | experiments) |
| | |
| 65535 | Reserved |
+-------------+-----------------------------------------------------+
Table 1: DLEP Data Item Types13.1. Status ✨
okay so for the Session Termination Message (Section 12.9), the Status Data Item tells you why the session is ending 💀. For every response message, it tells you whether the message you just got went through or not 🫶
The Status Data Item has an optional Text field for a little description. What happens to it is totally up to the receiving implementation, so it could get dumped into a log file or just tossed 🗑️. If there's no Text field, the Length field MUST be set to 1 🎀
The Status Data Item looks like this 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code | Text... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's the breakdown:
- Data Item Type:
1 - Length:
1 + Length of Text, in octets - Status Code: one of the status codes from Table 2 below
- Text: a UTF-8 encoded string of Unicode [RFC3629] characters that describes the cause. It's for implementation-defined purposes. Since it's a description, implementations SHOULD limit the characters to printable ones 📝
Also, bestie, an implementation MUST NOT assume the Text field is a NUL-terminated string of printable characters. Don't be that person 🙈
Here's Table 2 with all the status codes 💅
+----------+-------------+------------------+-----------------------+
| Status | Failure | Description | Reason |
| Code | Mode | | |
+----------+-------------+------------------+-----------------------+
| 0 | Continue | Success | The Message was |
| | | | processed |
| | | | successfully. |
| | | | |
| 1 | Continue | Not Interested | The receiver is not |
| | | | interested in this |
| | | | Message subject, |
| | | | e.g., in a |
| | | | Destination Up |
| | | | Response Message |
| | | | (Section 12.12) to |
| | | | indicate no further |
| | | | Messages about the |
| | | | destination. |
| | | | |
| 2 | Continue | Request Denied | The receiver refuses |
| | | | to complete the |
| | | | request. |
| | | | |
| 3 | Continue | Inconsistent | One or more Data |
| | | Data | Items in the Message |
| | | | describe a logically |
| | | | inconsistent state in |
| | | | the network -- for |
| | | | example, in the |
| | | | Destination Up |
| | | | Message |
| | | | (Section 12.11) when |
| | | | an announced subnet |
| | | | clashes with an |
| | | | existing destination |
| | | | subnet. |
| | | | |
| 4-111 | Continue | <Unassigned> | Available for future |
| | | | extensions. |
| | | | |
| 112-127 | Continue | <Reserved for | Available for |
| | | Private Use> | experiments. |
| | | | |
| 128 | Terminate | Unknown Message | The Message was not |
| | | | recognized by the |
| | | | implementation. |
| | | | |
| 129 | Terminate | Unexpected | The Message was not |
| | | Message | expected while the |
| | | | device was in the |
| | | | current state, e.g., |
| | | | a Session |
| | | | Initialization |
| | | | Message |
| | | | (Section 12.5) in |
| | | | the In-Session state. |
| | | | |
| 130 | Terminate | Invalid Data | One or more Data |
| | | | Items in the Message |
| | | | are invalid, |
| | | | unexpected, or |
| | | | incorrectly |
| | | | duplicated. |
| | | | |
| 131 | Terminate | Invalid | The destination |
| | | Destination | included in the |
| | | | Message does not |
| | | | match a previously |
| | | | announced destination |
| | | | -- for example, in |
| | | | the Link |
| | | | Characteristics |
| | | | Response Message |
| | | | (Section 12.19). |
| | | | |
| 132 | Terminate | Timed Out | The session has |
| | | | timed out. |
| | | | |
| 133-239 | Terminate | <Unassigned> | Available for future |
| | | | extensions. |
| | | | |
| 240-254 | Terminate | <Reserved for | Available for |
| | | Private Use> | experiments. |
| | | | |
| 255 | Terminate | Shutting Down | The peer is |
| | | | terminating the |
| | | | session, as it is |
| | | | shutting down. |
+----------+-------------+------------------+-----------------------+
Table 2: DLEP Status Codes13.2. IPv4 Connection Point 🌈
okay this one is about where the router should go to find the modem 🧚 The IPv4 Connection Point Data Item gives you the IPv4 address and, if you want, the TCP port number on the modem that's open for connections. If it's provided, the router MUST use it to start the TCP connection to the modem 🔥
The IPv4 Connection Point Data Item looks like this ✨
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | IPv4 Address... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ...cont. | TCP Port Number (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The breakdown:
- Data Item Type:
2 - Length:
5(or7if the TCP Port Number is included) - Flags: the Flags field, defined below
- IPv4 Address: the IPv4 address listening on the modem
- TCP Port Number: the TCP port number on the modem
If the Length field is 7, the port number specified MUST be used to set up the TCP session 🎯 If the TCP Port Number is left out, so the Length field is 5, the router MUST use the DLEP well-known port number (Section 15.14) to make the TCP connection 🍓
The Flags field looks like this 💜
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |T|
+-+-+-+-+-+-+-+-+- T: the Use TLS flag. It tells you whether the TCP connection to that address and port needs TLS [RFC5246] (1) or doesn't (0) 🔐
- Reserved: MUST be zero. It's left for future assignment 🦋
13.3. IPv6 Connection Point 🌸
Okay so the IPv6 Connection Point Data Item tells you the IPv6 address and, optionally, the TCP port number on the modem that's open for connections 🦋 If it's included, the router MUST use that info to start the TCP connection to the modem. No skipping it, bestie!
The IPv6 Connection Point Data Item has these fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | IPv6 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ...cont. | TCP Port Number (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Data Item Type: 3Length: 17 (or 19 if TCP Port Number included). 🎀Flags: the Flags field, defined below.IPv6 Address: The IPv6 address listening on the modem.TCP Port Number: TCP port number on the modem.
If the Length field is 19, the port number specified MUST be used to establish the TCP session. If the TCP Port Number is omitted, i.e., the Length field is 17, the router MUST use the DLEP well-known port number (Section 15.14) to establish the TCP connection. 💅
The Flags field looks like this:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |T|
+-+-+-+-+-+-+-+-+T: Use TLS flag, indicating whether the TCP connection to the given address and port requires the use of TLS [RFC5246] (1) or not (0).Reserved: MUST be zero. Left for future assignment.
13.4. Peer Type 🦋
The Peer Type Data Item is how the router and modem share extra info about what kind of device they are and the properties of their over-the-air control plane ✨
Some devices have really strict access to the shared RF medium. Satellite modems are a good example, where proprietary protocols make sure a given modem is actually allowed to connect to the shared medium. Governmental and military devices are another example, with elaborate mechanisms that make sure only authorized devices get in 🫶 Then there are modems with no access control at all, like one that supports the 802.11 ad hoc mode of operation. The Secured Medium (S) flag is how a modem says whether access control is in place or not 🔒
The Peer Type Data Item also includes a textual description of the peer. The text is meant for informational purposes, like output in a display command 💖
The Peer Type Data Item has these fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Description... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Data Item Type: 4Length: 1 + Length of Description, in octets.Flags: Flags field, defined below.Description: UTF-8 encoded string of Unicode [RFC3629] characters. For example, a satellite modem might set this variable to "Satellite terminal". Since this Data Item is intended to provide additional information for display commands, sending implementations SHOULD limit the data to printable characters. 🌈
An implementation MUST NOT assume that the Description field is a NUL-terminated string of printable characters. Not a safe bet, bestie 🙈
The Flags field looks like this:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |S|
+-+-+-+-+-+-+-+-+S: Secured Medium flag, used by a modem to indicate whether the shared RF medium implements access control (1) or not (0). The Secured Medium flag only has meaning in Signals and Messages sent by a modem.Reserved: MUST be zero. Left for future assignment.
13.5. Heartbeat Interval ⏱️
The Heartbeat Interval Data Item sets a period in milliseconds for Heartbeat Messages (Section 12.20). Very important timing stuff 👑
The Heartbeat Interval Data Item has these fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Heartbeat Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Data Item Type: 5Length: 4Heartbeat Interval: The interval in milliseconds, expressed as a 32-bit unsigned integer, for Heartbeat Messages. This value MUST NOT be 0. 🚫
As mentioned before, receipt of any valid DLEP Message MUST reset the heartbeat interval timer. In other words, valid DLEP Messages take the place of, and obviate the need for, additional Heartbeat Messages. Multitasking queen 👸✨
13.6. Extensions Supported 🧚
The Extensions Supported Data Item is how the router and modem negotiate extra optional functionality they're willing to support 🌸 The Extensions List is a concatenation of the types of each supported extension, found in the IANA registry titled "Extension Type Values". Each Extension Type definition says which additional Signals and Data Items are supported.
The Extensions Supported Data Item has these fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions List... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Data Item Type: 6Length: Length of the Extensions List in octets. This is twice (2x) the number of extensions.Extensions List: A list of extensions supported, identified by their 2-octet values as listed in the "Extension Type Values" registry.
13.7. MAC Address 🍓
The MAC Address Data Item holds the address of the destination on the remote node 💜
DLEP can support MAC addresses in either EUI-48 or EUI-64 format ("EUI" stands for "Extended Unique Identifier"). There's one big rule though: all MAC addresses for a given DLEP session MUST be in the same format, and they MUST be consistent with the MAC address format of the connected modem. For example, if the modem is connected to the router with an EUI-48 MAC, all destination addresses via that modem MUST be expressed in EUI-48 format. Consistency is everything, no cap 🔥
Examples of a virtual destination are (1) a multicast MAC address or (2) the broadcast MAC address FF:FF:FF:FF:FF:FF. 🌈
The MAC Address Data Item has these 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: MAC Address : (if EUI-64 used) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Data Item Type: 7Length: 6 for EUI-48 format or 8 for EUI-64 format.MAC Address: MAC address of the destination.
13.8. IPv4 Address 🦋
When this Data Item is included in the Session Update Message, it holds the IPv4 address of the peer. When it's included in Destination Messages, it holds the IPv4 address of the destination. Either way, it also says whether this is (1) a new or existing address or (2) a deletion of a previously known address 🌸
The IPv4 Address Data Item has these fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | IPv4 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ...cont. |
+-+-+-+-+-+-+-+-+
Data Item Type: 8Length: 5Flags: Flags field, defined below.IPv4 Address: The IPv4 address of the destination or peer.
The Flags field looks like this:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |A|
+-+-+-+-+-+-+-+-+A: Add/Drop flag, indicating whether this is a new or existing address (1) or a withdrawal of an address (0).Reserved: MUST be zero. Reserved for future use. 🫶
13.8.1. IPv4 Address Processing ✨
okay so, processing an IPv4 Address Data Item MUST be done within the context of the DLEP peer session it shows up in 💅 no mixing sessions, bestie 🫶
how you handle something that's wrong or logically inconsistent depends on which message the Data Item is hiding in, so let's break it down 🦋
If it's inside a Session Message, like a Session Initialization Message (Section 12.5) or a Session Update Message (Section 12.7), the receiver of the inconsistent info MUST send a Session Termination Message (Section 12.9) with a Status Data Item (Section 13.1) whose status code is set to 130 'Invalid Data', and then move into the Session Termination state 😭 harsh, but that's the rule. Some examples of this drama:
- An address Drop operation that references an address the peer doesn't actually have in the current session 💀
- An address Add operation that references an address the peer already got added in the current session 🙈
If it's inside a Destination Message, like a Destination Up Message (Section 12.11) or a Destination Update Message (Section 12.17), the receiver of inconsistent info MAY send the matching response message with a Status Data Item whose status code is set to 3 'Inconsistent Data', but it MUST continue with session processing 🌸 no panicking, just keep going. Some examples:
- An address Add operation that references an address already added to the destination in the current session 🍓
- An address Add operation that references an address tied to a different destination or to the peer in the current session 👑
- An address Add operation that references an address that makes no sense, like one that's defined as not forwardable in [RFC6890] 🙃
- An address Drop operation that references an address not associated with the destination in the current session 🧚
If no response message makes sense here, like with the Destination Update Message, then the implementation MUST continue with session processing 💜
Modems that don't track IPv4 addresses MUST silently ignore IPv4 Address Data Items 🫧 they're just not the ones keeping the receipts, so they say nothing.
13.9. IPv6 Address
the IPv6 Address Data Item is giving "same energy, bigger address" 🌈 when it shows up in the Session Update Message, it carries the IPv6 address of the peer. When it shows up in Destination Messages, it carries the IPv6 address of the destination. Either way, it also tells you whether this is (1) a new or existing address, or (2) a deletion of a previously known address ✨
The IPv6 Address Data Item has these fields, and yes the diagram is long, it's a whole vibe 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | IPv6 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Address |
+-+-+-+-+-+-+-+-+Here's what each piece means:
- Data Item Type: 9
- Length: 17
- Flags: the Flags field, which we cover right below 🦋
- IPv6 Address: the IPv6 address of the destination or peer 💅
The Flags field looks like this:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |A|
+-+-+-+-+-+-+-+-+- A: Add/Drop flag. It tells you whether this is a new or existing address (1), or a withdrawal of an address (0) 🌸
- Reserved: MUST be zero. Reserved for future use 🔒
13.9.1. IPv6 Address Processing ✨
processing the IPv6 Address Data Item MUST be done within the context of the DLEP peer session it's presented on 💖 same rule, different address, still iconic.
the consequences for messy stuff depend on the containing message, so here's the tea 🍵
If it's inside a Session Message, like a Session Initialization Message (Section 12.5) or a Session Update Message (Section 12.7), the receiver of inconsistent information MUST send a Session Termination Message (Section 12.9) with a Status Data Item (Section 13.1) whose status code is set to 130 'Invalid Data', and then transition to the Session Termination state 😭 examples:
- An address Drop operation that references an address that isn't associated with the peer in the current session 💀
- An address Add operation that references an address that has already been added to the peer in the current session 🙈
If it's inside a Destination Message, like a Destination Up Message (Section 12.11) or a Destination Update Message (Section 12.17), the receiver of inconsistent information MAY send the appropriate response message with a Status Data Item whose status code is set to 3 'Inconsistent Data', but it MUST continue with session processing 🌸 examples:
- An address Add operation that references an address already added to the destination in the current session 🍓
- An address Add operation that references an address associated with a different destination or the peer in the current session 👑
- An address Add operation that references an address that makes no sense, for example one defined as not forwardable in [RFC6890] 🙃
- An address Drop operation that references an address not associated with the destination in the current session 🧚
If no response message is appropriate, like with the Destination Update Message, then the implementation MUST continue with session processing 💜
Modems that don't track IPv6 addresses MUST silently ignore IPv6 Address Data Items 🫧 quiet and chill.
13.10. IPv4 Attached Subnet
the DLEP IPv4 Attached Subnet Data Item is how a device says "hey, I've got an IPv4 subnet attached" 🌈 (like a stub network). It can also say it's become aware of an IPv4 subnet at a remote destination, or that it's become aware a subnet at the remote destination is gone 🦋
The DLEP IPv4 Attached Subnet Data Item has these fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | IPv4 Attached Subnet :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ...cont. |Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Data Item Type: 10
- Length: 6
- Flags: the Flags field, defined below 🎀
- IPv4 Attached Subnet: the IPv4 subnet reachable at the destination 💖
- Prefix Length: the length of the prefix (0-32) for the IPv4 subnet. A prefix length outside that range MUST be considered as invalid 🙅♀️
The Flags field is:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |A|
+-+-+-+-+-+-+-+-+- A: Add/Drop flag. It tells you whether this is a new or existing subnet address (1), or a withdrawal of a subnet address (0) 🌸
- Reserved: MUST be zero. Reserved for future use 🔒
13.10.1. IPv4 Attached Subnet Processing ✨
processing the IPv4 Attached Subnet Data Item MUST be done within the context of the DLEP peer session it's presented on 💅
If it's inside a Session Message, like a Session Initialization Message (Section 12.5) or a Session Update Message (Section 12.7), the receiver of inconsistent information MUST send a Session Termination Message (Section 12.9) with a Status Data Item (Section 13.1) whose status code is set to 130 'Invalid Data', and then transition to the Session Termination state 😭 examples:
- A subnet Drop operation that references a subnet not associated with the peer in the current session 💀
- A subnet Add operation that references a subnet that has already been added to the peer in the current session 🙈
If it's inside a Destination Message, like a Destination Up Message (Section 12.11) or a Destination Update Message (Section 12.17), the receiver of inconsistent information MAY send the appropriate response message with a Status Data Item whose status code is set to 3 'Inconsistent Data', but it MUST continue with session processing 🌸 examples:
- A subnet Add operation that references a subnet already added to the destination in the current session 🍓
- A subnet Add operation that references a subnet associated with a different destination in the current session 👑
- A subnet Add operation that references a subnet that makes no sense, for example one defined as not forwardable in [RFC6890] 🙃
- A subnet Drop operation that references a subnet not associated with the destination in the current session 🧚
If no response message is appropriate, like with the Destination Update Message, then the implementation MUST continue with session processing 💜
Modems that don't track IPv4 subnets MUST silently ignore IPv4 Attached Subnet Data Items 🫧
13.11. IPv6 Attached Subnet
the DLEP IPv6 Attached Subnet Data Item does the same job as its IPv4 cousin, just for IPv6 🌈 it lets a device declare that it has an IPv6 subnet (e.g., a stub network) attached, that it's become aware of an IPv6 subnet present at a remote destination, or that it's become aware of the loss of a subnet at the remote destination 🦋
The DLEP IPv6 Attached Subnet Data Item has these fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | IPv6 Attached Subnet :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Attached Subnet :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Attached Subnet :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Attached Subnet :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ...cont. | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Data Item Type: 11
- Length: 18
- Flags: the Flags field, defined below 🎀
- IPv6 Attached Subnet: the IPv6 subnet reachable at the destination 💖
- Prefix Length: the length of the prefix (0-128) for the IPv6 subnet. A prefix length outside that range MUST be considered as invalid 🙅♀️
The Flags field is:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |A|
+-+-+-+-+-+-+-+-+- A: Add/Drop flag. It tells you whether this is a new or existing subnet address (1), or a withdrawal of a subnet address (0) 🌸
- Reserved: MUST be zero. Reserved for future use 🔒
Okay bestie, picking up right where we left off 💅✨
Quick note before we dive in: this part is all about the IPv6 Attached Subnet Processing rules, and then we get into the Maximum and Current data rate items, Latency, Resources and Relative Link Quality. Let's gooo 🦋
13.11. IPv6 Attached Subnet
13.11.1. IPv6 Attached Subnet Processing
okay so the big rule here is that processing an IPv6 Attached Subnet Data Item MUST be done within the context of the DLEP peer session it shows up in 🎀 no mixing sessions, periodt 💖
If the message is a Session Message (like a Session Initialization Message or a Session Update Message), and the receiver spots inconsistent info, it MUST send back a Session Termination Message with a Status Data Item set to status code 130 'Invalid Data' 💀 and then transition to the Session Termination state. Yikes, it's serious. Some examples of this kind of mess-up:
- a subnet Drop operation for a subnet that isn't associated with the peer in the current session 🙈
- a subnet Add operation for a subnet that's already been added to the peer in the current session
If the message is a Destination Message (like a Destination Up Message or a Destination Update Message), the receiver of inconsistent info MAY send the matching response message with a Status Data Item set to status code 3 'Inconsistent Data', but it MUST keep going with session processing 🌸 Not a total meltdown, just a heads up. Examples:
- a subnet Add operation for a subnet that's already been added to the destination in the current session
- a subnet Add operation for a subnet that's associated with a different destination in the current session
- a subnet Add operation for a subnet that makes no sense, like one that's defined as not forwardable in [RFC6890]
- a subnet Drop operation for a subnet that isn't associated with the destination in the current session
If no response message makes sense (the Destination Update Message is the classic example 🍓), then the implementation MUST continue with session processing. Keep vibing ✨
Last one: modems that don't track IPv6 subnets MUST silently ignore IPv6 Attached Subnet Data Items. No drama, just a quiet skip 🫶
13.12. Maximum Data Rate (Receive)
okay so the Maximum Data Rate (Receive) (MDRR) Data Item tells you the maximum theoretical data rate, in bits per second (bps), that can be achieved while receiving data on the link 🚀💜
The MDRR Data Item has these fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MDRR (bps) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: MDRR (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Data Item Type:
12 - Length:
8 - Maximum Data Rate (Receive): a 64-bit unsigned integer, representing the maximum theoretical data rate, in bits per second, that can be achieved while receiving on the link ✨
13.13. Maximum Data Rate (Transmit)
okay so the Maximum Data Rate (Transmit) (MDRT) Data Item is the same vibe but for sending 📤 It tells you the maximum theoretical data rate, in bits per second, that can be achieved while transmitting data on the link 💖
The MDRT Data Item has these fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MDRT (bps) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: MDRT (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Data Item Type:
13 - Length:
8 - Maximum Data Rate (Transmit): a 64-bit unsigned integer, representing the maximum theoretical data rate, in bits per second, that can be achieved while transmitting on the link 🦋
13.14. Current Data Rate (Receive)
okay so the Current Data Rate (Receive) (CDRR) Data Item shows the rate the link is actually running at right now for receiving traffic ⭐
When it's used in the Link Characteristics Request Message (Section 12.18), Current Data Rate (Receive) is the desired receive rate, in bits per second, on the link 🎀
The CDRR Data Item has these fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CDRR (bps) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: CDRR (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Data Item Type:
14 - Length:
8 - Current Data Rate (Receive): a 64-bit unsigned integer, representing the current data rate, in bits per second, that can currently be achieved while receiving traffic on the link 💅
If there's no difference between Current Data Rate (Receive) and Maximum Data Rate (Receive) (Section 13.12), then Current Data Rate (Receive) MUST be set equal to Maximum Data Rate (Receive). Current Data Rate (Receive) MUST NOT exceed Maximum Data Rate (Receive). Hard rule, no exceptions 🔥
13.15. Current Data Rate (Transmit)
okay so the Current Data Rate (Transmit) (CDRT) Data Item is the rate the link is currently running at for sending traffic 📤✨
When it's used in the Link Characteristics Request Message (Section 12.18), Current Data Rate (Transmit) is the desired transmit rate, in bits per second, on the link 🌈
The CDRT Data Item has these fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CDRT (bps) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: CDRT (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Data Item Type:
15 - Length:
8 - Current Data Rate (Transmit): a 64-bit unsigned integer, representing the current data rate, in bits per second, that can currently be achieved while transmitting traffic on the link 🫶
If there's no difference between Current Data Rate (Transmit) and Maximum Data Rate (Transmit) (Section 13.13), then Current Data Rate (Transmit) MUST be set equal to Maximum Data Rate (Transmit). Current Data Rate (Transmit) MUST NOT exceed Maximum Data Rate (Transmit). Iconic rules, fr fr 👑
13.16. Latency
okay so the Latency Data Item tells you how much latency, in microseconds, is on the link 🧚
The Latency value is reported as transmission delay. How latency gets calculated is implementation dependent 💜 For example, the latency could be a running average calculated from the internal queuing 🌸
The Latency Data Item has these fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latency :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Latency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Data Item Type:
16 - Length:
8 - Latency: a 64-bit unsigned integer, representing the transmission delay, in microseconds, that a packet encounters as it is transmitted over the link ⏱️
13.17. Resources
okay so the Resources (RES) Data Item shows how much finite resource is left for sending and receiving data at the destination, as a percentage 🔋 0 means 'no resources remaining' and 100 means 'a full supply' 💖 Assuming that when Resources hits 0, data transmission and/or reception will cease, so yeah, it matters 😭
An example is battery life, but it could also be stuff like available memory for queuing, or CPU idle percentage 🧠 The specific criteria for this metric are out of scope for this specification and are implementation specific, so it's up to the implementation 🌈
This Data Item is meant to be an indication of some capability of the modem and/or router at the destination 🎀
The RES Data Item has these fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES |
+-+-+-+-+-+-+-+-+- Data Item Type:
17 - Length:
1 - Resources: an 8-bit unsigned integer percentage, 0-100, representing the amount of resources available. Any value greater than 100 MUST be considered as invalid 🙅♀️
If a device can't calculate Resources, this Data Item MUST NOT be issued. Big no-no 💀
13.18. Relative Link Quality (Receive)
okay so the Relative Link Quality (Receive) (RLQR) Data Item shows how good the link to a destination is for receiving traffic, with 0 meaning 'worst quality' and 100 meaning 'best quality' 🌟
Quality here means how stable the link is for reception. A destination with high Relative Link Quality (Receive) is expected to have generally stable DLEP metrics, while a destination with low Relative Link Quality (Receive) can be expected to rapidly fluctuate over a wide range 🎢💜
The RLQR Data Item has these fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RLQR |
+-+-+-+-+-+-+-+-+- Data Item Type:
18 - Length:
1 - Relative Link Quality (Receive): a non-dimensional unsigned 8-bit integer, 0-100, representing relative quality of the link for receiving traffic. Any value greater than 100 MUST be considered as invalid 🥰
If a device can't calculate Relative Link Quality (Receive), this Data Item MUST NOT be issued. Periodt 🍓
13.19. Relative Link Quality (Transmit) 🦋
okay so the Relative Link Quality (Transmit) (RLQT) Data Item is how a device tells you how good its link is for sending traffic to a destination 💅. 0 means "worst quality" and 100 means "best quality" ✨.
"Quality" in this context means how stable the link is for transmission 🫶. A destination with high RLQT is expected to have generally stable DLEP metrics, while a destination with low RLQT can be expected to rapidly fluctuate over a wide range 😭. Main character energy is the steady one, bestie.
The RLQT Data Item contains the following fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RLQT |
+-+-+-+-+-+-+-+-+- Data Item Type:
19🎀 - Length:
1🍓 - Relative Link Quality (Transmit): a non-dimensional unsigned 8-bit integer, 0-100, representing the relative quality of the link for transmitting traffic. Any value greater than 100 MUST be considered as invalid. 🙈
If a device cannot calculate Relative Link Quality (Transmit), this Data Item MUST NOT be issued. Nope, not even a little bit 💀
13.20. Maximum Transmission Unit (MTU) 🌸
The Maximum Transmission Unit (MTU) Data Item is used to indicate the maximum size, in octets, of an IP packet that can be transmitted without fragmentation, including headers, but excluding any lower-layer headers ✨. Think of it as the biggest outfit that still fits through the door without getting ripped 🧚.
The Maximum Transmission Unit Data Item contains the following fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Data Item Type:
20👑 - Length:
2💜 - Maximum Transmission Unit: the maximum size, in octets, of an IP packet that can be transmitted without fragmentation, including headers, but excluding any lower-layer headers. 🦋
If a device cannot calculate Maximum Transmission Unit, this Data Item MUST NOT be issued. Again, no exceptions, periodt 💅
14. Security Considerations 🔥
okay this section is SERIOUS, so pay attention 👀 The potential security concerns when using DLEP are as follows:
- An attacker might pretend to be a DLEP participant, either at DLEP session initialization or by injection of DLEP Messages once a session has been established.
- DLEP Data Items could be altered by an attacker, causing the receiving implementation to inappropriately alter its information base concerning network status.
- An attacker could join an unsecured radio network and inject over-the-air signals that maliciously influence the information reported by a DLEP modem, causing a router to forward traffic to an inappropriate destination.
The implications of attacks on DLEP peers are directly proportional to the extent to which DLEP data is used within the control plane 😭. While the use of DLEP data in other control-plane components is out of scope for this document, as an example, if DLEP statistics are incorporated into route cost calculations, adversaries masquerading as a DLEP peer and injecting malicious data via DLEP could cause suboptimal route selection, adversely impacting network performance. Similar issues can arise if DLEP data is used as an input to policing algorithms -- injection of malicious data via DLEP can cause those policing algorithms to make incorrect decisions, degrading network throughput 💀
For these reasons, security of the DLEP transport must be considered at both the transport layer and Layer 2 🔒
At the transport layer, when TLS is in use, each peer SHOULD check the validity of credentials presented by the other peer during TLS session establishment. Implementations following the "dedicated deployments" model attempting to use TLS MAY (1) need to consider the use of pre-shared keys for credentials, (2) provide specialized techniques for peer identity validation, and (3) refer to [RFC5487] for additional details. Implementations following the "networked deployment" model described in "Implementation Scenarios" (Section 4) SHOULD refer to [RFC7525] for additional details. 🫶
At Layer 2, since DLEP is restricted to operation over a single (possibly logical) hop, implementations SHOULD also secure the Layer 2 link. Examples of technologies that can be deployed to secure the Layer 2 link include [IEEE-802.1AE] and [IEEE-802.1X]. 🦋
By examining the Secured Medium flag in the Peer Type Data Item (Section 13.4), a router can decide if it is able to trust the information supplied via a DLEP modem. If this is not the case, then the router SHOULD consider restricting the size of attached subnets, announced in IPv4 Attached Subnet Data Items (Section 13.10) and/or IPv6 Attached Subnet Data Items (Section 13.11), that are considered for route selection. ✨
To avoid potential denial-of-service attacks, it is RECOMMENDED that implementations using the Peer Discovery mechanism (1) maintain an information base of hosts that persistently fail Session Initialization, even though those hosts have provided an acceptable Peer Discovery Signal and (2) ignore any subsequent Peer Discovery Signals from such hosts. Block the repeat offenders, bestie 🙅♀️
This specification does not address security of the data plane, as it (the data plane) is not affected, and standard security procedures can be employed. 🌈
15. IANA Considerations 🧚
15.1. Registrations 🎀
IANA has created a new protocol registry for the Dynamic Link Exchange Protocol (DLEP). The remainder of this section details the new DLEP-specific registries 💖
15.2. Signal Type Registrations 💜
IANA has created a new DLEP registry, named "Signal Type Values".
The following table provides initial registry values and the policies, as defined by [RFC5226], that apply to the registry:
+--------------+--------------------------------------+
| Type Code | Description/Policy |
+--------------+--------------------------------------+
| 0 | Reserved |
| 1 | Peer Discovery Signal |
| 2 | Peer Offer Signal |
| 3-65519 | Unassigned / Specification Required |
| 65520-65534 | Reserved for Private Use |
| 65535 | Reserved |
+--------------+--------------------------------------+15.3. Message Type Registrations 🌸
IANA has created a new DLEP registry, named "Message Type Values".
The following table provides initial registry values and the policies, as defined by [RFC5226], that apply to the registry:
+--------------+------------------------------------------+
| Type Code | Description/Policy |
+--------------+------------------------------------------+
| 0 | Reserved |
| | |
| 1 | Session Initialization Message |
| | |
| 2 | Session Initialization Response Message |
| | |
| 3 | Session Update Message |
| | |
| 4 | Session Update Response Message |
| | |
| 5 | Session Termination Message |
| | |
| 6 | Session Termination Response Message |
| | |
| 7 | Destination Up Message |
| | |
| 8 | Destination Up Response Message |
| | |
| 9 | Destination Announce Message |
| | |
| 10 | Destination Announce Response Message |
| | |
| 11 | Destination Down Message |
| | |
| 12 | Destination Down Response Message |
| | |
| 13 | Destination Update Message |
| | |
| 14 | Link Characteristics Request Message |
| | |
| 15 | Link Characteristics Response Message |
| | |
| 16 | Heartbeat Message |
| | |
| 17-65519 | Unassigned / Specification Required |
| | |
| 65520-65534 | Reserved for Private Use |
| | |
| 65535 | Reserved |
+--------------+------------------------------------------+15.4. DLEP Data Item Registrations 🎀
okay so IANA made a brand new DLEP registry called "Data Item Type Values" 💖 Here are the starter values, plus the policies from [RFC5226] that apply to it:
+-------------------+------------------------------------------+
| Type Code | Description/Policy |
+-------------------+------------------------------------------+
| 0 | Reserved |
| | |
| 1 | Status |
| | |
| 2 | IPv4 Connection Point |
| | |
| 3 | IPv6 Connection Point |
| | |
| 4 | Peer Type |
| | |
| 5 | Heartbeat Interval |
| | |
| 6 | Extensions Supported |
| | |
| 7 | MAC Address |
| | |
| 8 | IPv4 Address |
| | |
| 9 | IPv6 Address |
| | |
| 10 | IPv4 Attached Subnet |
| | |
| 11 | IPv6 Attached Subnet |
| | |
| 12 | Maximum Data Rate (Receive) (MDRR) |
| | |
| 13 | Maximum Data Rate (Transmit) (MDRT) |
| | |
| 14 | Current Data Rate (Receive) (CDRR) |
| | |
| 15 | Current Data Rate (Transmit) (CDRT) |
| | |
| 16 | Latency |
| | |
| 17 | Resources (RES) |
| | |
| 18 | Relative Link Quality (Receive) (RLQR) |
| | |
| 19 | Relative Link Quality (Transmit) (RLQT) |
| | |
| 20 | Maximum Transmission Unit (MTU) |
| | |
| 21-65407 | Unassigned / Specification Required |
| | |
| 65408-65534 | Reserved for Private Use |
| | |
| 65535 | Reserved |
+-------------------+------------------------------------------+15.5. DLEP Status Code Registrations 🍓
IANA also made a new DLEP registry for status codes, called "Status Code Values" ✨ Same deal: here's the starter table and the [RFC5226] policies that go with it.
+--------------+---------------+------------------------------------+
| Status Code | Failure Mode | Description/Policy |
+--------------+---------------+------------------------------------+
| 0 | Continue | Success |
| | | |
| 1 | Continue | Not Interested |
| | | |
| 2 | Continue | Request Denied |
| | | |
| 3 | Continue | Inconsistent Data |
| | | |
| 4-111 | Continue | Unassigned / Specification |
| | | Required |
| | | |
| 112-127 | Continue | Private Use |
| | | |
| 128 | Terminate | Unknown Message |
| | | |
| 129 | Terminate | Unexpected Message |
| | | |
| 130 | Terminate | Invalid Data |
| | | |
| 131 | Terminate | Invalid Destination |
| | | |
| 132 | Terminate | Timed Out |
| | | |
| 133-239 | Terminate | Unassigned / Specification |
| | | Required |
| | | |
| 240-254 | Terminate | Reserved for Private Use |
| | | |
| 255 | Terminate | Shutting Down |
+--------------+---------------+------------------------------------+15.6. DLEP Extension Registrations 🦋
Next up is a DLEP registry named "Extension Type Values" 🧚 Here's the initial table, with the [RFC5226] policies that apply.
+--------------+--------------------------------------+
| Code | Description/Policy |
+--------------+--------------------------------------+
| 0 | Reserved |
| 1-65519 | Unassigned / Specification Required |
| 65520-65534 | Reserved for Private Use |
| 65535 | Reserved |
+--------------+--------------------------------------+
Table 3: DLEP Extension Types15.7. DLEP IPv4 Connection Point Flags 🌈
IANA made a registry called "IPv4 Connection Point Flags" 💜 The flag table is below, and the [RFC5226] policies apply to it.
+------------+--------------------------------------+
| Bit | Description/Policy |
+------------+--------------------------------------+
| 0-6 | Unassigned / Specification Required |
| 7 | Use TLS [RFC5246] indicator |
+------------+--------------------------------------+15.8. DLEP IPv6 Connection Point Flags 🌸
Same vibe for the "IPv6 Connection Point Flags" registry 🫶 Here's the table, governed by the [RFC5226] policies.
+------------+--------------------------------------+
| Bit | Description/Policy |
+------------+--------------------------------------+
| 0-6 | Unassigned / Specification Required |
| 7 | Use TLS [RFC5246] indicator |
+------------+--------------------------------------+15.9. DLEP Peer Type Flags 👑
IANA created a registry named "Peer Type Flags" ✨ The table is below, and the [RFC5226] policies apply.
+------------+--------------------------------------+
| Bit | Description/Policy |
+------------+--------------------------------------+
| 0-6 | Unassigned / Specification Required |
| 7 | Secured Medium indicator |
+------------+--------------------------------------+15.10. DLEP IPv4 Address Flags 🍓
There's a registry called "IPv4 Address Flags" 💅 Here's the initial table, with the [RFC5226] policies that apply to it.
+------------+--------------------------------------+
| Bit | Description/Policy |
+------------+--------------------------------------+
| 0-6 | Unassigned / Specification Required |
| 7 | Add/Drop indicator |
+------------+--------------------------------------+15.11. DLEP IPv6 Address Flags 🦋
And then the "IPv6 Address Flags" registry 💖 Table below, same [RFC5226] policies.
+------------+--------------------------------------+
| Bit | Description/Policy |
+------------+--------------------------------------+
| 0-6 | Unassigned / Specification Required |
| 7 | Add/Drop indicator |
+------------+--------------------------------------+15.12. DLEP IPv4 Attached Subnet Flags 🧚
IANA made a registry called "IPv4 Attached Subnet Flags" 🌈 The table is below, and the [RFC5226] policies apply.
+------------+--------------------------------------+
| Bit | Description/Policy |
+------------+--------------------------------------+
| 0-6 | Unassigned / Specification Required |
| 7 | Add/Drop indicator |
+------------+--------------------------------------+15.13. DLEP IPv6 Attached Subnet Flags 💜
Last one in this batch: the "IPv6 Attached Subnet Flags" registry 🎀 Here's the table, with the [RFC5226] policies that go with it.
+------------+--------------------------------------+
| Bit | Description/Policy |
+------------+--------------------------------------+
| 0-6 | Unassigned / Specification Required |
| 7 | Add/Drop indicator |
+------------+--------------------------------------+15.14. DLEP Well-Known Port 🎀
okay bestie, IANA gave DLEP the port number 854 💖 It's listed in the "Service Name and Transport Protocol Port Number Registry" at <http://www.iana.org/assignments/service-names-port-numbers/> for "DLEP", the protocol this document defines. The assignment is valid for TCP and UDP 🦋
15.15. DLEP IPv4 Link-Local Multicast Address 🌸
IANA also reserved the IPv4 multicast address 224.0.0.117 in the registry at <http://www.iana.org/assignments/multicast-addresses>, and it's labeled "DLEP Discovery" ✨ So that's the address for DLEP discovery on IPv4 🧚
15.16. DLEP IPv6 Link-Local Multicast Address 💜
Same vibe for IPv6! IANA assigned the IPv6 multicast address FF02:0:0:0:0:0:1:7 in the registry at <http://www.iana.org/assignments/ipv6-multicast-addresses>, labeled "DLEP Discovery" 👑
16. References ✨
16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, <http://www.rfc-editor.org/info/rfc5082>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
16.2. Informative References
[IEEE-802.1AE] "IEEE Standards for Local and Metropolitan Area Networks: Media Access Control (MAC) Security", DOI 10.1109/IEEESTD.2006.245590, <http://ieeexplore.ieee.org/document/1678345/>.
[IEEE-802.1X] "IEEE Standards for Local and metropolitan area networks-- Port-Based Network Access Control", DOI 10.1109/IEEESTD.2010.5409813, <http://ieeexplore.ieee.org/document/5409813/>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5487] Badra, M., "Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode", RFC 5487, DOI 10.17487/RFC5487, March 2009, <http://www.rfc-editor.org/info/rfc5487>.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013, <http://www.rfc-editor.org/info/rfc6890>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
Appendix A. Discovery Signal Flows 🦋
ok this part is a little picture book 📖 Here's how discovery plays out between the Router and the Modem 💅
Router Modem Signal Description
========================================================================
| Router initiates discovery,
| starts a timer, sends Peer
|-------Peer Discovery---->X Discovery Signal.
~ ~ ~ ~ ~ ~ ~ Router discovery timer expires
without receiving Peer Offer.
| Router sends another Peer
|-------Peer Discovery---------->| Discovery Signal.
|
| Modem receives Peer Discovery
| Signal.
|
| Modem sends Peer Offer with
|<--------Peer Offer-------------| Connection Point information.
:
: Router MAY cancel discovery timer
: and stop sending Peer Discovery
: Signals.Appendix B. Peer-Level Message Flows 💜
Now the peer-level story 🧚 Each flow below is a little movie of messages going back and forth between the Router and the Modem ✨
B.1. Session Initialization 🌈
Router Modem Message Description
========================================================================
| Router connects to discovered or
| preconfigured Modem Connection
|--TCP connection established---> Point.
|
| Router sends Session
|----Session Initialization----->| Initialization Message.
|
| Modem receives Session
| Initialization Message.
|
| Modem sends Session Initialization
|<--Session Initialization Resp.-| Response with 'Success' Status
| | Data Item.
| |
|<<============================>>| Session established.
: : Heartbeats begin.B.2. Session Initialization - Refused 🙈
Router Modem Message Description
========================================================================
| Router connects to discovered or
| preconfigured Modem Connection
|--TCP connection established---> Point.
|
| Router sends Session
|-----Session Initialization---->| Initialization Message.
|
| Modem receives Session
| Initialization Message and
| will not support the advertised
| extensions.
|
| Modem sends Session Initialization
| Response with 'Request Denied'
|<-Session Initialization Resp.--| Status Data Item.
|
|
| Router receives negative Session
| Initialization Response, closes
||---------TCP close------------|| TCP connection.B.3. Router Changes IP Addresses 🍓
Router Modem Message Description
========================================================================
| Router sends Session Update
|-------Session Update---------->| Message to announce change of
| IP address.
|
| Modem receives Session Update
| Message and updates internal
| state.
|
|<----Session Update Response----| Modem sends Session Update
| Response.B.4. Modem Changes Session-Wide Metrics 🦋
Router Modem Message Description
========================================================================
| Modem sends Session Update Message
| to announce change of session-wide
|<--------Session Update---------| metrics.
|
| Router receives Session Update
| Message and updates internal
| state.
|
|----Session Update Response---->| Router sends Session Update
| Response.B.5. Router Terminates Session 💅
Router Modem Message Description
========================================================================
| Router sends Session Termination
|------Session Termination------>| Message with Status Data Item.
| |
|-------TCP shutdown (send)---> | Router stops sending Messages.
|
| Modem receives Session
| Termination, stops counting
| received heartbeats, and stops
| sending heartbeats.
|
| Modem sends Session Termination
|<---Session Termination Resp.---| Response with Status 'Success'.
|
| Modem stops sending Messages.
|
||---------TCP close------------|| Session terminated.B.6. Modem Terminates Session 🌸
Router Modem Message Description
========================================================================
| Modem sends Session Termination
|<----Session Termination--------| Message with Status Data Item.
|
| Modem stops sending Messages.
|
| Router receives Session
| Termination, stops counting
| received heartbeats, and stops
| sending heartbeats.
|
| Router sends Session Termination
|---Session Termination Resp.--->| Response with 'Success' Status.
|
| Router stops sending Messages.
|
||---------TCP close------------|| Session terminated.B.7. Session Heartbeats 💖
Router Modem Message Description
========================================================================
|----------Heartbeat------------>| Router sends Heartbeat Message.
|
| Modem resets heartbeats missed
| counter.
~ ~ ~ ~ ~ ~ ~
|---------[Any Message]--------->| When the Modem receives any
| Message from the Router.
|
| Modem resets heartbeats missed
| counter.
~ ~ ~ ~ ~ ~ ~
|<---------Heartbeat-------------| Modem sends Heartbeat Message.
|
| Router resets heartbeats missed
| counter.
~ ~ ~ ~ ~ ~ ~
|<--------[Any Message]----------| When the Router receives any
| Message from the Modem.
|
| Modem resets heartbeats missed
| counter.B.8. Router Detects a Heartbeat Timeout ⭐
Router Modem Message Description
========================================================================
X<----------------------| Router misses a heartbeat.
| X<----------------------| Router misses too many
| heartbeats.
|
|
|------Session Termination------>| Router sends Session Termination
| Message with 'Timeout' Status
| Data Item.: Termination proceeds...
okay so the modem gives up on the session and sends the termination message with the 'Timeout' status, and then everything just keeps going, bestie 💅
B.9. Modem Detects a Heartbeat Timeout ✨
the modem is the one who notices the heartbeats stopped coming. literally the vibe is "I've been waiting and you're not answering 💀"
Router Modem Message Description
========================================================================
|---------------------->X Modem misses a heartbeat.
|---------------------->X | Modem misses too many
| heartbeats.
|
|
|<-----Session Termination-------| Modem sends Session Termination
| Message with 'Timeout' Status
| Data Item.
:
: Termination proceeds...Appendix C. Destination-Specific Message Flows 🦋
this appendix is all about how destinations get announced, updated, and dropped. it's giving choreography 🎀
C.1. Common Destination Notification 🌸
the modem is the one who spots a new logical destination, so it's the one that starts the whole Destination Up thing. the router replies with a response. the metrics can change and the modem keeps the router posted with updates, and when the destination stops being reachable the modem sends a Destination Down. the router then updates its internal state and answers back ✨
Router Modem Message Description
========================================================================
| Modem detects a new logical
| destination is reachable and
|<-------Destination Up----------| sends Destination Up Message.
|
|------Destination Up Resp.----->| Router sends Destination Up
| Response.
~ ~ ~ ~ ~ ~ ~
| Modem detects change in logical
| destination metrics and sends
|<-------Destination Update------| Destination Update Message.
~ ~ ~ ~ ~ ~ ~
| Modem detects change in logical
| destination metrics and sends
|<-------Destination Update------| Destination Update Message.
~ ~ ~ ~ ~ ~ ~
| Modem detects logical destination
| is no longer reachable and sends
|<-------Destination Down--------| Destination Down Message.
|
| Router receives Destination Down,
| updates internal state, and sends
|------Destination Down Resp.--->| Destination Down Response Message.C.2. Multicast Destination Notification 🧚
this one flips it around. the router is the one who notices a multicast destination is in use, so the router sends the announce. the modem then sets up its internal state to monitor it, and the same update and down dance follows, just with the router now doing the Destination Down 🔥
Router Modem Message Description
========================================================================
| Router detects a new multicast
| destination is in use and sends
|-----Destination Announce------>| Destination Announce Message.
|
| Modem updates internal state to
| monitor multicast destination and
|<-----Dest. Announce Resp.------| sends Destination Announce
Response.
~ ~ ~ ~ ~ ~ ~
| Modem detects change in multicast
| destination metrics and sends
|<-------Destination Update------| Destination Update Message.
~ ~ ~ ~ ~ ~ ~
| Modem detects change in multicast
| destination metrics and sends
|<-------Destination Update------| Destination Update Message.
~ ~ ~ ~ ~ ~ ~
| Router detects multicast
| destination is no longer in use
|--------Destination Down------->| and sends Destination Down
| Message.
|
| Modem receives Destination Down,
| updates internal state, and sends
|<-----Destination Down Resp.----| Destination Down Response Message.C.3. Link Characteristics Request 💜
last but definitely not least: the router wants different link characteristics for a destination that's already been announced by one of the peers. so it sends a request, and the modem tries to adjust the link to match and replies with the new values. main character energy 👑
Router Modem Message Description
========================================================================
Destination has already been
~ ~ ~ ~ ~ ~ ~ announced by either peer.
| Router requires different
| characteristics for the
| destination and sends Link
|--Link Characteristics Request->| Characteristics Request Message.
|
| Modem attempts to adjust link
| properties to meet the received
| request and sends a Link
| Characteristics Response
|<---Link Characteristics Resp.--| Message with the new values.Acknowledgments 🫶
bestie, we have to shout out the people who made this happen! The DLEP design team gave us invaluable insight, and they are Teco Boot, Bow-Nan Cheng, John Dowdell, and Henning Rogge. literally the real MVPs 🌈
We also owe a big thank you to Greg Harrison, Chris Olsen, Martin Duke, Subir Das, Jaewon Kang, Vikram Kaul, Nelson Powell, Lou Berger, and Victoria Pritchard for their influence and contributions. you all ate 🍓✨
Authors' Addresses 💖
Stan Ratliff
VT iDirect
13861 Sunrise Valley Drive, Suite 300
Herndon, VA 20171
United States of America
Email: sratliff@idirect.net
Shawn Jury
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
United States of America
Email: sjury@cisco.com
Darryl Satterwhite
Broadcom
Email: dsatterw@broadcom.com
Rick Taylor
Airbus Defence & Space
Quadrant House
Celtic Springs
Coedkernew
Newport NP10 8FZ
United Kingdom
Email: rick.taylor@airbus.com
Bo Berry📦 where this page comes from
- ietf: rfc8175 2017-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms