RFC 8175
Dynamic Link Exchange Protocol (DLEP)
11. DLEP Signal and Message Structure
DLEP defines two protocol units used in two different ways: Signals and Messages. Signals are only used in the Discovery mechanism and are carried in UDP datagrams. Messages are used bidirectionally over a TCP connection between the participants, in the Session Initialization, In-Session, and Session Termination states.
Both Signals and Messages consist of a Header followed by an unordered list of Data Items. Headers consist of Type and Length information, while Data Items are encoded as TLV (Type-Length-Value) structures. In this document, the Data Items following a Signal or Message Header are described as being "contained in" the Signal or Message. There is no restriction on the order of Data Items following a Header, and the acceptability of duplicate Data Items is defined by the definition of the Signal or Message declared by the type in the Header. All integers in Header fields and values MUST be in network byte order.11.1. DLEP Signal Header
The DLEP Signal Header 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | '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. 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 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 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 specifying 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 contains data specific to a particular Data Item.
12. DLEP Signals and Messages
12.1. General Processing Rules
If an unrecognized or unexpected Signal is received or if a received Signal contains unrecognized, invalid, or disallowed duplicate Data Items, the receiving implementation MUST ignore the Signal. If a Signal is received with a TTL value that is NOT equal to 255, the receiving implementation MUST ignore the Signal. If an unrecognized Message is received, the receiving implementation MUST issue a Session Termination Message (Section 12.9) containing a Status Data Item (Section 13.1) with status code set to 128 'Unknown Message' (see Table 2) and transition to the Session Termination state. 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. Prior to the exchange of Destination Up (Section 12.11) and Destination Up Response (Section 12.12) Messages, or Destination Announce (Section 12.13) and Destination Announce Response (Section 12.14) Messages, no Messages concerning a destination may be sent. An implementation receiving any Message with such an unannounced destination MUST terminate the session by issuing a Session Termination Message containing a Status Data Item with status code set to 131 'Invalid Destination' and transition to the Session Termination state. 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.12.2. Status Code Processing
The behavior of a DLEP participant receiving a Message containing a Status Data Item (Section 13.1) is defined by the failure mode associated with the value of the status code field; see Table 2. All status code values less than 100 have a failure mode of 'Continue'; all other status codes have a failure mode of 'Terminate'. A DLEP participant receiving any Message apart from a Session Termination Message (Section 12.9) containing a Status Data Item with a status code value with failure mode 'Terminate' MUST immediately issue a Session Termination Message echoing the received Status Data Item and then transition to the Session Termination state. A DLEP participant receiving a Message containing a Status Data Item with a status code value with failure mode 'Continue' can continue normal operation of the session.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. 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. 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
A Peer Offer Signal MUST be sent by a DLEP modem in response to a properly formatted and addressed Peer Discovery Signal (Section 12.3). A Peer Offer Signal MUST be encoded within a UDP packet. The IP source and destination fields in the packet MUST be set by swapping the values received in the Peer Discovery Signal. The Peer Offer Signal completes the discovery process; see Section 7.1. To construct a Peer Offer Signal, the Signal Type value in the Signal Header is set to 2 (see "Signal Type Registration" (Section 15.2)). The Peer Offer Signal MAY contain a Peer Type Data Item (Section 13.4). The Peer Offer Signal MAY contain one or more of any of the following Data Items, with different values: o IPv4 Connection Point (Section 13.2) o IPv6 Connection Point (Section 13.3) The IPv4 and IPv6 Connection Point Data Items indicate the unicast address the router MUST use when connecting the DLEP TCP session.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. It is sent by the router after a TCP connect to an address/port combination that was obtained either via receipt of a Peer Offer or from a priori configuration. To construct a Session Initialization Message, the Message Type value in the Message Header is set to 1 (see "Message Type Registration" (Section 15.3)). The Session Initialization Message MUST contain one of each of the following Data Items: o Heartbeat Interval (Section 13.5) o Peer Type (Section 13.4) If DLEP extensions are supported, the Session Initialization Message MUST contain an Extensions Supported Data Item (Section 13.6).
The Session Initialization Message MAY contain one or more of each of the following Data Items, with different values and with the Add/Drop (A) flag (Section 13) set to 1: o IPv4 Address (Section 13.8) o IPv6 Address (Section 13.9) o IPv4 Attached Subnet (Section 13.10) o IPv6 Attached Subnet (Section 13.11) If any optional extensions are supported by the implementation, they MUST be enumerated in the Extensions Supported Data Item. If an Extensions Supported Data Item does not exist in a Session Initialization Message, the modem MUST conclude that there is no support for extensions in the router. DLEP Heartbeats are not started until receipt of the Session Initialization Response Message (Section 12.6), and therefore implementations MUST use their own timeout heuristics for this Message. As an exception to the general rule governing an implementation receiving an unrecognized Data Item in a Message (see Section 12.1), if a Session Initialization Message contains one or more Extensions Supported Data Items announcing support for extensions that the implementation does not recognize, then the implementation MAY ignore Data Items it does not recognize.12.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). To construct a Session Initialization Response Message, the Message Type value in the Message Header is set to 2 (see "Message Type Registration" (Section 15.3)). The Session Initialization Response Message MUST contain one of each of the following Data Items: o Status (Section 13.1) o Peer Type (Section 13.4) o Heartbeat Interval (Section 13.5)
o Maximum Data Rate (Receive) (Section 13.12) o Maximum Data Rate (Transmit) (Section 13.13) o Current Data Rate (Receive) (Section 13.14) o Current Data Rate (Transmit) (Section 13.15) o 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: o Resources (Section 13.17) o Relative Link Quality (Receive) (Section 13.18) o Relative Link Quality (Transmit) (Section 13.19) o 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). 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: o IPv4 Address (Section 13.8) o IPv6 Address (Section 13.9) o IPv4 Attached Subnet (Section 13.10) o IPv6 Attached Subnet (Section 13.11) The Session Initialization Response Message completes the DLEP session establishment; the modem should transition to the In-Session state when the Message is sent, and the router should transition to the In-Session state upon receipt of an acceptable Session Initialization Response Message. All supported metric Data Items MUST be included in the Session Initialization Response Message, with default values to be used on a session-wide basis. This can be viewed as the modem "declaring" all supported metrics at DLEP session initialization. Receipt of any
further DLEP Message containing a metric Data Item not included in the Session Initialization Response Message MUST be treated as an error, resulting in the termination of the DLEP session between router and modem. If any optional extensions are supported by the modem, they MUST be enumerated in the Extensions Supported Data Item. If an Extensions Supported Data Item does not exist in a Session Initialization Response Message, the router MUST conclude that there is no support for extensions in the modem. After the Session Initialization / Session Initialization Response Messages have been successfully exchanged, implementations MUST only use extensions that are supported by both DLEP participants; see Section 7.2.12.7. Session Update Message
A Session Update Message MAY be sent by a DLEP participant, on a session-wide basis, to indicate local Layer 3 address changes and/or metric changes. To construct a Session Update Message, the Message Type value in the Message Header is set to 3 (see "Message Type Registration" (Section 15.3)). The Session Update Message MAY contain one or more of each of the following Data Items, with different values: o IPv4 Address (Section 13.8) o IPv6 Address (Section 13.9) o IPv4 Attached Subnet (Section 13.10) o IPv6 Attached Subnet (Section 13.11) When sent by a modem, the Session Update Message MAY contain one of each of the following Data Items: o Maximum Data Rate (Receive) (Section 13.12) o Maximum Data Rate (Transmit) (Section 13.13) o Current Data Rate (Receive) (Section 13.14)
o Current Data Rate (Transmit) (Section 13.15) o Latency (Section 13.16) When sent by a modem, the Session Update Message MAY contain one of each of the following Data Items, if the Data Item is in use by the session: o Resources (Section 13.17) o Relative Link Quality (Receive) (Section 13.18) o Relative Link Quality (Transmit) (Section 13.19) o Maximum Transmission Unit (MTU) (Section 13.20) If metrics are supplied with the Session Update Message (e.g., Maximum Data Rate), these metrics are considered to be session-wide and therefore MUST be applied to all destinations in the information base associated with the DLEP session. This includes destinations for which metrics may have been stored based on received Destination Update messages. It should be noted that Session Update Messages can be sent by both routers and modems. For example, the addition of an IPv4 address on the router MAY prompt a Session Update Message to its attached modems. Also, for example, a modem that changes its Maximum Data Rate (Receive) for all destinations MAY reflect that change via a Session Update Message to its attached router(s). Concerning Layer 3 addresses and subnets: if the modem is capable of understanding and forwarding this information (via mechanisms not defined by DLEP), the update would prompt any remote DLEP-enabled modems to issue a Destination Update Message (Section 12.17) to their local routers with the new (or deleted) addresses and subnets.12.8. Session Update Response Message
A Session Update Response Message MUST be sent by a DLEP participant when a Session Update Message (Section 12.7) is received. To construct a Session Update Response Message, the Message Type value in the Message Header is set to 4 (see "Message Type Registration" (Section 15.3)). The Session Update Response Message MUST contain a Status Data Item (Section 13.1).
12.9. Session Termination Message
When a DLEP participant determines that the DLEP session needs to be terminated, the participant MUST send (or attempt to send) a Session Termination Message. To construct a Session Termination Message, the Message Type value in the Message Header is set to 5 (see "Message Type Registration" (Section 15.3)). 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.12.10. Session Termination Response Message
A Session Termination Response Message MUST be sent by a DLEP participant when a Session Termination Message (Section 12.9) is received. To construct a Session Termination Response Message, the Message Type value in the Message Header is set to 6 (see "Message Type Registration" (Section 15.3)). There are no valid Data Items for the Session Termination Response Message. Receipt of a Session Termination Response Message completes the teardown of the DLEP session; see Section 7.4.12.11. Destination Up Message
Destination Up Messages MAY be sent by a modem to inform its attached router of the presence of a new reachable destination. To construct a Destination Up Message, the Message Type value in the Message Header is set to 7 (see "Message Type Registration" (Section 15.3)). The Destination Up Message MUST contain a MAC Address Data Item (Section 13.7).
The Destination Up Message SHOULD contain one or more of each of the following Data Items, with different values: o IPv4 Address (Section 13.8) o IPv6 Address (Section 13.9) The Destination Up Message MAY contain one of each of the following Data Items: o Maximum Data Rate (Receive) (Section 13.12) o Maximum Data Rate (Transmit) (Section 13.13) o Current Data Rate (Receive) (Section 13.14) o Current Data Rate (Transmit) (Section 13.15) o Latency (Section 13.16) The Destination Up Message MAY contain one of each of the following Data Items, if the Data Item is in use by the session: o Resources (Section 13.17) o Relative Link Quality (Receive) (Section 13.18) o Relative Link Quality (Transmit) (Section 13.19) o Maximum Transmission Unit (MTU) (Section 13.20) The Destination Up Message MAY contain one or more of each of the following Data Items, with different values: o IPv4 Attached Subnet (Section 13.10) o IPv6 Attached Subnet (Section 13.11) A router receiving a Destination Up Message allocates the necessary resources, creating an entry in the information base with the specifics (MAC Address, Latency, Data Rate, etc.) of the destination. The information about this destination will persist in the router's information base until a Destination Down Message (Section 12.15) is received, indicating that the modem has lost contact with the remote node or that the implementation transitions to the Session Termination state.
12.12. Destination Up Response Message
A router MUST send a Destination Up Response Message when a Destination Up Message (Section 12.11) is received. To construct a Destination Up Response Message, the Message Type value in the Message Header is set to 8 (see "Message Type Registration" (Section 15.3)). The Destination Up Response Message MUST contain one of each of the following Data Items: o MAC Address (Section 13.7) o Status (Section 13.1) A router that wishes to receive further information concerning the destination identified in the corresponding Destination Up Message MUST set the status code of the included Status Data Item to 0 'Success'; see Table 2. If the router has no interest in the destination identified in the corresponding Destination Up Message, then it MAY set the status code of the included Status Data Item to 1 'Not Interested'. A modem receiving a Destination Up Response Message containing a Status Data Item with a status code of any value other than 0 'Success' MUST NOT send further Destination Messages about the destination, e.g., Destination Down (Section 12.15) or Destination Update (Section 12.17) with the same MAC address.12.13. Destination Announce Message
Usually, a modem will discover the presence of one or more remote router/modem pairs and announce each destination's arrival by sending a corresponding Destination Up Message (Section 12.11) to the router. However, there may be times when a router wishes to express an interest in a destination that has yet to be announced, typically a multicast destination. Destination Announce Messages MAY be sent by a router to announce such an interest. A Destination Announce Message MAY also be sent by a router to request information concerning a destination (1) in which the router has previously declined interest, via the 1 'Not Interested' status code in a Destination Up Response Message (Section 12.12) (see Table 2) or (2) that was previously declared as 'down', via the Destination Down Message (Section 12.15).
To construct a Destination Announce Message, the Message Type value in the Message Header is set to 9 (see "Message Type Registration" (Section 15.3)). The Destination Announce Message MUST contain a MAC Address Data Item (Section 13.7). The Destination Announce Message MAY contain zero or more of the following Data Items, with different values: o IPv4 Address (Section 13.8) o IPv6 Address (Section 13.9) One of the advantages of implementing DLEP is to leverage the modem's knowledge of the links between remote destinations, allowing routers to avoid using probed neighbor discovery techniques; therefore, modem implementations SHOULD announce available destinations via the Destination Up Message, rather than relying on Destination Announce Messages.12.14. Destination Announce Response Message
A modem MUST send a Destination Announce Response Message when a Destination Announce Message (Section 12.13) is received. To construct a Destination Announce Response Message, the Message Type value in the Message Header is set to 10 (see "Message Type Registration" (Section 15.3)). The Destination Announce Response Message MUST contain one of each of the following Data Items: o MAC Address (Section 13.7) o Status (Section 13.1) The Destination Announce Response Message MAY contain one or more of each of the following Data Items, with different values: o IPv4 Address (Section 13.8) o IPv6 Address (Section 13.9) o IPv4 Attached Subnet (Section 13.10) o IPv6 Attached Subnet (Section 13.11)
The Destination Announce Response Message MAY contain one of each of the following Data Items: o Maximum Data Rate (Receive) (Section 13.12) o Maximum Data Rate (Transmit) (Section 13.13) o Current Data Rate (Receive) (Section 13.14) o Current Data Rate (Transmit) (Section 13.15) o Latency (Section 13.16) The Destination Announce Response Message MAY contain one of each of the following Data Items, if the Data Item is in use by the session: o Resources (Section 13.17) o Relative Link Quality (Receive) (Section 13.18) o Relative Link Quality (Transmit) (Section 13.19) o Maximum Transmission Unit (MTU) (Section 13.20) If a modem is unable to report information immediately about the requested information -- for example, if the destination is not currently reachable -- the status code in the Status Data Item MUST be set to 2 'Request Denied'; see Table 2. After sending a Destination Announce Response Message containing a Status Data Item with a status code of 0 'Success', a modem then announces changes to the link to the destination via Destination Update Messages. When a successful Destination Announce Response Message is received, the router should add knowledge of 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. A router MAY send a Destination Down Message to report when it no longer requires information concerning a destination.
To construct a Destination Down Message, the Message Type value in the Message Header is set to 11 (see "Message Type Registration" (Section 15.3)). The Destination Down Message MUST contain a MAC Address Data Item (Section 13.7). It should be noted that both modem and router may send a Destination Down Message to their peer, regardless of which participant initially indicated the destination to be 'up'.12.16. Destination Down Response Message
A Destination Down Response Message MUST be sent by the recipient of a Destination Down Message (Section 12.15) to confirm that the relevant data concerning the destination has been removed from the information base. To construct a Destination Down Response Message, the Message Type value in the Message Header is set to 12 (see "Message Type Registration" (Section 15.3)). The Destination Down Response Message MUST contain one of each of the following Data Items: o MAC Address (Section 13.7) o Status (Section 13.1)12.17. Destination Update Message
A modem SHOULD send a Destination Update Message when it detects some change in the information base for a given destination (remote node or multicast group). Some examples of changes that would prompt a Destination Update Message are as follows: o Change in link metrics (e.g., data rates) o Layer 3 addressing change To construct a Destination Update Message, the Message Type value in the Message Header is set to 13 (see "Message Type Registration" (Section 15.3)). The Destination Update Message MUST contain a MAC Address Data Item (Section 13.7).
The Destination Update Message MAY contain one of each of the following Data Items: o Maximum Data Rate (Receive) (Section 13.12) o Maximum Data Rate (Transmit) (Section 13.13) o Current Data Rate (Receive) (Section 13.14) o Current Data Rate (Transmit) (Section 13.15) o Latency (Section 13.16) The Destination Update Message MAY contain one of each of the following Data Items, if the Data Item is in use by the session: o Resources (Section 13.17) o Relative Link Quality (Receive) (Section 13.18) o Relative Link Quality (Transmit) (Section 13.19) o Maximum Transmission Unit (MTU) (Section 13.20) The Destination Update Message MAY contain one or more of each of the following Data Items, with different values: o IPv4 Address (Section 13.8) o IPv6 Address (Section 13.9) o IPv4 Attached Subnet (Section 13.10) o IPv6 Attached Subnet (Section 13.11) Metrics supplied in this Message overwrite metrics provided in a previously received Session Message, Destination Message, or Link Characteristics Message (e.g., Session Initialization, Destination Up, Link Characteristics Response). It should be noted that this Message has no corresponding response.
12.18. Link Characteristics Request Message
The Link Characteristics Request Message MAY be sent by a router to request that the modem initiate changes for specific characteristics of the link. The request can reference either a real destination (e.g., a remote node) or a logical destination (e.g., a multicast group) within the network. To construct a Link Characteristics Request Message, the Message Type value in the Message Header is set to 14 (see "Message Type Registration" (Section 15.3)). The Link Characteristics Request Message MUST contain a MAC Address Data Item (Section 13.7). The Link Characteristics Request Message MUST also contain at least one of each of the following Data Items: o Current Data Rate (Receive) (Section 13.14) o Current Data Rate (Transmit) (Section 13.15) o Latency (Section 13.16) The Link Characteristics Request Message MAY contain either a Current Data Rate (Receive) (CDRR) or Current Data Rate (Transmit) (CDRT) Data Item to request a different data rate than is currently allocated, a Latency Data Item to request that traffic delay on the link not exceed the specified value, or both. The router sending a Link Characteristics Request Message should be aware that a request may take an extended period of time to complete.12.19. Link Characteristics Response Message
A modem MUST send a Link Characteristics Response Message when a Link Characteristics Request Message (Section 12.18) is received. To construct a Link Characteristics Response Message, the Message Type value in the Message Header is set to 15 (see "Message Type Registration" (Section 15.3)). The Link Characteristics Response Message MUST contain one of each of the following Data Items: o MAC Address (Section 13.7) o Status (Section 13.1)
The Link Characteristics Response Message SHOULD contain one of each of the following Data Items: o Maximum Data Rate (Receive) (Section 13.12) o Maximum Data Rate (Transmit) (Section 13.13) o Current Data Rate (Receive) (Section 13.14) o Current Data Rate (Transmit) (Section 13.15) o Latency (Section 13.16) The Link Characteristics Response Message MAY contain one of each of the following Data Items, if the Data Item is in use by the session: o Resources (Section 13.17) o Relative Link Quality (Receive) (Section 13.18) o Relative Link Quality (Transmit) (Section 13.19) o Maximum Transmission Unit (MTU) (Section 13.20) The Link Characteristics Response Message MUST contain a complete set of metric Data Items, referencing all metrics declared in the Session Initialization Response Message (Section 12.6). The values in the metric Data Items in the Link Characteristics Response Message MUST reflect the link characteristics after the request has been processed. If an implementation is not able to alter the characteristics of the link in the manner requested, then the status code of the Status Data Item MUST be set to 2 'Request Denied'; see Table 2.12.20. Heartbeat Message
A Heartbeat Message MUST be sent by a DLEP participant every N milliseconds, where N is defined in the Heartbeat Interval Data Item (Section 13.5) of the Session Initialization Message (Section 12.5) or Session Initialization Response Message (Section 12.6). To construct a Heartbeat Message, the Message Type value in the Message Header is set to 16 (see "Message Type Registration" (Section 15.3)). There are no valid Data Items for the Heartbeat Message.
The Heartbeat Message is used by DLEP participants to detect when a DLEP session peer (either the modem or the router) is no longer communicating; see Section 7.3.1.
(page 37 continued on part 3)
