Dynamic Link Exchange Protocol (DLEP)
Extracted elements (31)
All metric Data Items that will be used during a session must be declared with default values in the Session Initialization Response. This 'declare-at-initialization' design ensures the router immediately knows the modem's full metric capability, and prevents runtime introduction of unanticipated metric types that could complicate routing decisions.
DLEP uses an event-driven paradigm rather than timer-based inference (as used by routing protocol hellos and dead-adjacency timers) because mobile wireless links acquire and lose neighbors without any change to router interface state. Explicit event signaling over a reliable local TCP session substantially shortens routing convergence time.
DLEP uses UDP multicast for peer discovery and TCP for all session messages. TCP was chosen because DLEP relies on guaranteed, ordered delivery of link-state events; losing a Destination Down notification, for example, could cause persistent routing black holes. UDP is used only for the initial single-hop discovery exchange, which falls outside the transaction model.
When multiple Connection Point Data Items appear in a Peer Offer Signal, routers SHOULD prioritize IPv6 connection points over IPv4. DLEP RECOMMENDED that implementations use IPv6 link-local addresses to reduce address-assignment administrative burden. Peer Discovery Signals SHOULD also prefer IPv6 when the router supports both.
A DLEP participant receiving any Message (other than a Session Termination Message) that contains a Status Data Item with failure mode 'Terminate' (status code ≥ 100) MUST immediately issue a Session Termination Message echoing the received Status Data Item and transition to the Session Termination state.
All integers in DLEP Header fields and values MUST be in network byte order (big-endian).
All supported metric Data Items MUST be declared with default values in the Session Initialization Response Message. Receipt of any subsequent DLEP Message containing a metric Data Item not included in the Session Initialization Response MUST be treated as an error resulting in session termination.
DLEP enforces a per-destination transaction model: only one request per destination may be in progress at a time. If a participant receives a request for a destination with an outstanding request, it MUST terminate the session with status code 129 'Unexpected Message'. There is no restriction on total concurrent transactions, provided each references a different destination.
DLEP MUST be implemented on a single Layer 2 domain. MAC addresses MUST be unique within the router-modem session, and the MAC address supplied in all DLEP Messages is used unmodified as the Destination MAC address for frames emitted by the participating router.
Extensions MUST be negotiated per-session during initialization via the Extensions Supported Data Item. Once initialization Messages have been exchanged, an implementation MUST NOT emit any Message, Signal, Data Item, or status code associated with an extension not declared in the peer's initialization Message.
If an unrecognized Message is received, the implementation MUST issue a Session Termination Message with status code 128 'Unknown Message'. If a Message contains unrecognized, invalid, or disallowed duplicate Data Items, the implementation MUST terminate the session with status code 130 'Invalid Data'.
Implementations MUST support the Generalized TTL Security Mechanism (RFC 5082) and MUST adhere to it for all DLEP Messages. Signals received with TTL ≠ 255 MUST be silently ignored; TCP packets received with TTL ≠ 255 MUST cause an immediate transition to the Session Reset state.
Implementations SHOULD implement and use TLS (RFC 5246) to protect the TCP session; for 'networked deployments' TLS is STRONGLY RECOMMENDED. If TLS is used, the TLS session MUST be established before any Messages are passed between peers. Routers supporting TLS MUST prioritize TLS connection points over non-TLS ones.
Periodic Heartbeat Messages MUST be exchanged during In-Session state. An implementation MUST allow a minimum of 2 heartbeat intervals to expire with no Messages from its peer before terminating the session with status code 132 'Timed Out'. Receipt of any valid DLEP Message MUST reset the heartbeat interval timer.
Prior to exchanging Destination Up/Destination Announce messages for a destination, no Messages concerning that destination may be sent. An implementation receiving a Message with an undeclared destination MUST terminate the session with status code 131 'Invalid Destination'. The same applies after Destination Down exchange until a new Destination Up is issued.
The router MUST send a Session Initialization Message as the first Message of the TCP session. If a modem receives any Message other than Session Initialization first, or fails to parse it, it MUST NOT send any Message, MUST terminate the TCP connection, and MUST transition to Session Reset state.
DLEP uses two protocol unit types: Signals (UDP datagrams, used only for Peer Discovery) and Messages (TCP, bidirectional during Session Initialization, In-Session, and Session Termination states). Both consist of a type/length header followed by an unordered list of TLV Data Items.
The Destination Announce Message (type 9, router→modem) lets a router express interest in a destination not yet announced by the modem—typically a logical multicast destination. The modem responds with a Destination Announce Response (type 10), which MAY include link metrics; if the destination is unreachable, the status MUST be 2 'Request Denied'.
The Destination Up Message (type 7, modem→router) announces a newly reachable destination identified by its MAC Address, along with optional address and metric Data Items. The router acknowledges with a Destination Up Response (type 8); if not interested, the router sets status 1 'Not Interested' and the modem MUST NOT send further Messages about that destination.
The Link Characteristics Request Message (type 14, router→modem) requests that the modem alter link characteristics (Current Data Rate and/or Latency) for a specific destination. The modem responds with a Link Characteristics Response (type 15) containing a complete set of all declared metric Data Items reflecting the state after processing.
The Peer Discovery Signal (type 1) is sent by routers to the DLEP well-known IPv4 or IPv6 link-local multicast address/port. The modem responds with a Peer Offer Signal (type 2) containing IPv4/IPv6 Connection Point Data Items specifying the TCP address/port. If no Connection Point Data Items are included, the router uses the UDP source address and the DLEP well-known port.
The Session Initialization Message (type 1, from router) and Session Initialization Response Message (type 2, from modem) establish the session. Together they declare supported extensions, peer type, heartbeat intervals, and all metric Data Items (with defaults) that will be used during the session lifetime.
The Session Update Message (type 3) may be sent by either participant to communicate session-wide metric changes or Layer 3 address changes. When metric Data Items are included, they MUST be applied to all destinations in the information base for that session, overwriting any per-destination metrics previously stored.
The Status Data Item (type 1) carries an 8-bit Status Code and an optional UTF-8 Text description. Status codes < 100 have failure mode 'Continue'; codes ≥ 100 have failure mode 'Terminate'. Key codes: 0 'Success', 1 'Not Interested', 2 'Request Denied', 128 'Unknown Message', 129 'Unexpected Message', 130 'Invalid Data', 131 'Invalid Destination', 132 'Timed Out'.
RFC 8175 establishes the following IANA registries: DLEP Signal Type Values, DLEP Message Type Values, DLEP Data Item Type Values (0–65535 with Private Use range 65408–65534), DLEP Status Code Values, DLEP Extension Type Values, DLEP IPv4/IPv6 Connection Point Flags, DLEP Peer Type Flags, DLEP IPv4/IPv6 Address Flags, DLEP IPv4/IPv6 Attached Subnet Flags. A well-known UDP port and IPv4/IPv6 link-local multicast addresses are also registered.
DLEP enforces its single-hop requirement via GTSM (RFC 5082) with TTL=255. In 'networked deployments' where router and modem are reachable from other network points, Layer 2 tunneling technology MUST be used to maintain the single-hop invariant. Without TLS, a rogue participant on the same segment could inject false link metrics or destination events, directly influencing routing decisions.
TLS is STRONGLY RECOMMENDED for networked deployments and SHOULD be implemented in all cases. 'Dedicated deployments' (directly connected or dedicated-switch topologies) MAY omit TLS. The absence of TLS leaves DLEP session messages unauthenticated and susceptible to spoofing or metric manipulation.
DLEP sessions traverse five ordered states: Peer Discovery → Session Initialization → In-Session → Session Termination → Session Reset. Modems MUST support Peer Discovery; routers using preconfigured TCP addresses start at Session Initialization. Unexpected TCP termination while not in Session Reset MUST immediately force a transition to Session Reset.
All DLEP Data Items are encoded as TLVs: 16-bit Data Item Type, 16-bit Length (octets of the Value field, excluding Type and Length fields), followed by a variable-length Value field. There is no ordering requirement for Data Items within a Signal or Message.
The DLEP Message Header consists of a 16-bit Message Type followed by a 16-bit Length indicating total octets of Data Items (not including the header itself). Carried over TCP.
The DLEP Signal Header begins with the 4-byte ASCII magic 'DLEP' (U+0044 U+004C U+0045 U+0050), followed by a 16-bit Signal Type and a 16-bit Length indicating total octets of Data Items (not including the header). Carried in UDP datagrams only.