RFC 8175
Dynamic Link Exchange Protocol (DLEP)
13. DLEP Data Items
The core DLEP Data Items are as follows: +-------------+-----------------------------------------------------+ | 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
For the Session Termination Message (Section 12.9), the Status Data Item indicates a reason for the termination. For all response messages, the Status Data Item is used to indicate the success or failure of the previously received Message. The Status Data Item includes an optional Text field that can be used to provide a textual description of the status. The use of the Text field is entirely up to the receiving implementation, e.g., it could be output to a log file or discarded. If no Text field is supplied with the Status Data Item, the Length field MUST be set to 1. The Status Data Item contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Item Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Code | Text... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: 1 Length: 1 + Length of Text, in octets. Status Code: One of the status codes defined in Table 2 below.
Text: UTF-8 encoded string of Unicode [RFC3629] characters, describing the cause, used for implementation-defined purposes. Since this field is used for description purposes, implementations SHOULD limit characters in this field to printable characters. An implementation MUST NOT assume that the Text field is a NUL-terminated string of printable characters. +----------+-------------+------------------+-----------------------+ | 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
The IPv4 Connection Point Data Item indicates the IPv4 address and, optionally, the TCP port number on the modem available for connections. If provided, the router MUST use this information to initiate the TCP connection to the modem. The IPv4 Connection Point Data Item contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Item Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | IPv4 Address... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ...cont. | TCP Port Number (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: 2 Length: 5 (or 7 if TCP Port Number included). Flags: Flags field, defined below. IPv4 Address: The IPv4 address listening on the modem. TCP Port Number: TCP port number on the modem. If the Length field is 7, the port number specified MUST be used to establish the TCP session. If the TCP Port Number is omitted, i.e., the Length field is 5, the router MUST use the DLEP well-known port number (Section 15.14) to establish the TCP connection.
The Flags field is defined as:
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.3. IPv6 Connection Point
The IPv6 Connection Point Data Item indicates the IPv6 address and,
optionally, the TCP port number on the modem available for
connections. If provided, the router MUST use this information to
initiate the TCP connection to the modem.
The IPv6 Connection Point Data Item contains the following fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | IPv6 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ...cont. | TCP Port Number (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: 3
Length: 17 (or 19 if TCP Port Number included).
Flags: 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 is defined as: 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 used by the router and modem to give additional information as to its type and the properties of the over-the-air control plane. With some devices, access to the shared RF medium is strongly controlled. One example of this would be satellite modems -- where protocols, proprietary in nature, have been developed to ensure that a given modem has authorization to connect to the shared medium. Another example of this class of modems is governmental/military devices, where elaborate mechanisms have been developed to ensure that only authorized devices can connect to the shared medium. Contrasting with the above, there are modems where no such access control is used. An example of this class of modem would be one that supports the 802.11 ad hoc mode of operation. The Secured Medium (S) flag is used to indicate if access control is in place. The Peer Type Data Item includes a textual description of the peer; it is envisioned that the text will be used for informational purposes (e.g., as output in a display command).
The Peer Type Data Item contains the following fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Description... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: 4
Length: 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.
The Flags field is defined as:
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 is used to specify a period in milliseconds for Heartbeat Messages (Section 12.20). The Heartbeat Interval Data Item contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Item Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Heartbeat Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: 5 Length: 4 Heartbeat 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 (i.e., valid DLEP Messages take the place of, and obviate the need for, additional Heartbeat Messages).13.6. Extensions Supported
The Extensions Supported Data Item is used by the router and modem to negotiate additional optional functionality they are willing to support. The Extensions List is a concatenation of the types of each supported extension, found in the IANA registry titled "Extension Type Values". Each Extension Type definition includes which additional Signals and Data Items are supported.
The Extensions Supported Data Item contains the following fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions List... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: 6
Length: Length of the Extensions List in octets. This is twice (2x)
the number of extensions.
Extensions List: A list of extensions supported, identified by their
2-octet values as listed in the "Extension Type Values" registry.
13.7. MAC Address
The MAC Address Data Item contains 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"), with the restriction
that all MAC addresses for a given DLEP session MUST be in the same
format and MUST be consistent with the MAC address format of the
connected modem (e.g., if the modem is connected to the router with
an EUI-48 MAC, all destination addresses via that modem MUST be
expressed in EUI-48 format).
Examples of a virtual destination would be (1) a multicast MAC
address or (2) the broadcast MAC address (FF:FF:FF:FF:FF:FF).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: MAC Address : (if EUI-64 used) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data Item Type: 7 Length: 6 for EUI-48 format or 8 for EUI-64 format. MAC Address: MAC address of the destination.13.8. IPv4 Address
When included in the Session Update Message, this Data Item contains the IPv4 address of the peer. When included in Destination Messages, this Data Item contains the IPv4 address of the destination. In either case, the Data Item also contains an indication of whether this is (1) a new or existing address or (2) a deletion of a previously known address. The IPv4 Address Data Item contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Item Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | IPv4 Address : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ...cont. | +-+-+-+-+-+-+-+-+ Data Item Type: 8 Length: 5 Flags: Flags field, defined below. IPv4 Address: The IPv4 address of the destination or peer. The Flags field is defined as: 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
Processing of the IPv4 Address Data Item MUST be done within the context of the DLEP peer session on which it is presented. The handling of erroneous or logically inconsistent conditions depends upon the type of the message that contains the Data Item, as follows: If the containing message is a Session Message, e.g., a Session Initialization Message (Section 12.5) or Session Update Message (Section 12.7), the receiver of inconsistent information MUST issue a Session Termination Message (Section 12.9) containing a Status Data Item (Section 13.1) with status code set to 130 'Invalid Data' and transition to the Session Termination state. Examples of such conditions are: o An address Drop operation referencing an address that is not associated with the peer in the current session. o An address Add operation referencing an address that has already been added to the peer in the current session. If the containing message is a Destination Message, e.g., a Destination Up Message (Section 12.11) or Destination Update Message (Section 12.17), the receiver of inconsistent information MAY issue the appropriate response message containing a Status Data Item with status code set to 3 'Inconsistent Data' but MUST continue with session processing. Examples of such conditions are: o An address Add operation referencing an address that has already been added to the destination in the current session. o An address Add operation referencing an address that is associated with a different destination or the peer in the current session. o An address Add operation referencing an address that makes no sense -- for example, defined as not forwardable in [RFC6890]. o An address Drop operation referencing an address that is not associated with the destination in the current session. If no response message is appropriate -- for example, the Destination Update Message -- then the implementation MUST continue with session processing. Modems that do not track IPv4 addresses MUST silently ignore IPv4 Address Data Items.
13.9. IPv6 Address
When included in the Session Update Message, this Data Item contains the IPv6 address of the peer. When included in Destination Messages, this Data Item contains the IPv6 address of the destination. In either case, the Data Item also contains an indication of whether this is (1) a new or existing address or (2) a deletion of a previously known address. The IPv6 Address Data Item contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Item Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | IPv6 Address : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : IPv6 Address : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : IPv6 Address : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : IPv6 Address : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : IPv6 Address | +-+-+-+-+-+-+-+-+ Data Item Type: 9 Length: 17 Flags: Flags field, defined below. IPv6 Address: The IPv6 address of the destination or peer. The Flags field is defined as: 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.9.1. IPv6 Address Processing
Processing of the IPv6 Address Data Item MUST be done within the context of the DLEP peer session on which it is presented. The handling of erroneous or logically inconsistent conditions depends upon the type of the message that contains the Data Item, as follows: If the containing message is a Session Message, e.g., a Session Initialization Message (Section 12.5) or Session Update Message (Section 12.7), the receiver of inconsistent information MUST issue a Session Termination Message (Section 12.9) containing a Status Data Item (Section 13.1) with status code set to 130 'Invalid Data' and transition to the Session Termination state. Examples of such conditions are: o An address Drop operation referencing an address that is not associated with the peer in the current session. o An address Add operation referencing an address that has already been added to the peer in the current session. If the containing message is a Destination Message, e.g., a Destination Up Message (Section 12.11) or Destination Update Message (Section 12.17), the receiver of inconsistent information MAY issue the appropriate response message containing a Status Data Item with status code set to 3 'Inconsistent Data' but MUST continue with session processing. Examples of such conditions are: o An address Add operation referencing an address that has already been added to the destination in the current session. o An address Add operation referencing an address that is associated with a different destination or the peer in the current session. o An address Add operation referencing an address that makes no sense -- for example, defined as not forwardable in [RFC6890]. o An address Drop operation referencing an address that is not associated with the destination in the current session. If no response message is appropriate -- for example, the Destination Update Message -- then the implementation MUST continue with session processing. Modems that do not track IPv6 addresses MUST silently ignore IPv6 Address Data Items.
13.10. IPv4 Attached Subnet
The DLEP IPv4 Attached Subnet Data Item allows a device to declare that it has an IPv4 subnet (e.g., a stub network) attached, that it has become aware of an IPv4 subnet being present at a remote destination, or that it has become aware of the loss of a subnet at the remote destination. The DLEP IPv4 Attached Subnet Data Item contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Item Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | IPv4 Attached Subnet : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ...cont. |Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: 10 Length: 6 Flags: Flags field, defined below. IPv4 Attached Subnet: The IPv4 subnet reachable at the destination. Prefix Length: Length of the prefix (0-32) for the IPv4 subnet. A prefix length outside the specified range MUST be considered as invalid. The Flags field is defined as: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Reserved |A| +-+-+-+-+-+-+-+-+ A: Add/Drop flag, indicating whether this is a new or existing subnet address (1) or a withdrawal of a subnet address (0). Reserved: MUST be zero. Reserved for future use.
13.10.1. IPv4 Attached Subnet Processing
Processing of the IPv4 Attached Subnet Data Item MUST be done within the context of the DLEP peer session on which it is presented. If the containing message is a Session Message, e.g., a Session Initialization Message (Section 12.5) or Session Update Message (Section 12.7), the receiver of inconsistent information MUST issue a Session Termination Message (Section 12.9) containing a Status Data Item (Section 13.1) with status code set to 130 'Invalid Data' and transition to the Session Termination state. Examples of such conditions are: o A subnet Drop operation referencing a subnet that is not associated with the peer in the current session. o A subnet Add operation referencing a subnet that has already been added to the peer in the current session. If the containing message is a Destination Message, e.g., a Destination Up Message (Section 12.11) or Destination Update Message (Section 12.17), the receiver of inconsistent information MAY issue the appropriate response message containing a Status Data Item with status code set to 3 'Inconsistent Data' but MUST continue with session processing. Examples of such conditions are: o A subnet Add operation referencing a subnet that has already been added to the destination in the current session. o A subnet Add operation referencing a subnet that is associated with a different destination in the current session. o A subnet Add operation referencing a subnet that makes no sense -- for example, defined as not forwardable in [RFC6890]. o A subnet Drop operation referencing a subnet that is not associated with the destination in the current session. If no response message is appropriate -- for example, the Destination Update Message -- then the implementation MUST continue with session processing. Modems that do not track IPv4 subnets MUST silently ignore IPv4 Attached Subnet Data Items.
13.11. IPv6 Attached Subnet
The DLEP IPv6 Attached Subnet Data Item allows a device to declare that it has an IPv6 subnet (e.g., a stub network) attached, that it has become aware of an IPv6 subnet being present at a remote destination, or that it has become aware of the loss of a subnet at the remote destination. The DLEP IPv6 Attached Subnet Data Item contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Item Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | IPv6 Attached Subnet : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : IPv6 Attached Subnet : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : IPv6 Attached Subnet : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : IPv6 Attached Subnet : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ...cont. | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: 11 Length: 18 Flags: Flags field, defined below. IPv6 Attached Subnet: The IPv6 subnet reachable at the destination. Prefix Length: Length of the prefix (0-128) for the IPv6 subnet. A prefix length outside the specified range MUST be considered as invalid.
The Flags field is defined as:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |A|
+-+-+-+-+-+-+-+-+
A: Add/Drop flag, indicating whether this is a new or existing
subnet address (1) or a withdrawal of a subnet address (0).
Reserved: MUST be zero. Reserved for future use.
13.11.1. IPv6 Attached Subnet Processing
Processing of the IPv6 Attached Subnet Data Item MUST be done within
the context of the DLEP peer session on which it is presented.
If the containing message is a Session Message, e.g., a Session
Initialization Message (Section 12.5) or Session Update Message
(Section 12.7), the receiver of inconsistent information MUST issue a
Session Termination Message (Section 12.9) containing a Status Data
Item (Section 13.1) with status code set to 130 'Invalid Data' and
transition to the Session Termination state. Examples of such
conditions are:
o A subnet Drop operation referencing a subnet that is not
associated with the peer in the current session.
o A subnet Add operation referencing a subnet that has already been
added to the peer in the current session.
If the containing message is a Destination Message, e.g., a
Destination Up Message (Section 12.11) or Destination Update Message
(Section 12.17), the receiver of inconsistent information MAY issue
the appropriate response message containing a Status Data Item with
status code set to 3 'Inconsistent Data' but MUST continue with
session processing. Examples of such conditions are:
o A subnet Add operation referencing a subnet that has already been
added to the destination in the current session.
o A subnet Add operation referencing a subnet that is associated
with a different destination in the current session.
o A subnet Add operation referencing a subnet that makes no sense --
for example, defined as not forwardable in [RFC6890].
o A subnet Drop operation referencing a subnet that is not
associated with the destination in the current session.
If no response message is appropriate -- for example, the Destination
Update Message -- then the implementation MUST continue with session
processing.
Modems that do not track IPv6 subnets MUST silently ignore IPv6
Attached Subnet Data Items.
13.12. Maximum Data Rate (Receive)
The Maximum Data Rate (Receive) (MDRR) Data Item is used to indicate
the maximum theoretical data rate, in bits per second (bps), that can
be achieved while receiving data on the link.
The Maximum Data Rate (Receive) Data Item contains the following
fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MDRR (bps) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: MDRR (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)
The Maximum Data Rate (Transmit) (MDRT) Data Item is used to indicate the maximum theoretical data rate, in bits per second, that can be achieved while transmitting data on the link. The Maximum Data Rate (Transmit) Data Item contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Item Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MDRT (bps) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : MDRT (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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)
The Current Data Rate (Receive) (CDRR) Data Item is used to indicate the rate at which the link is currently operating for receiving traffic. When used in the Link Characteristics Request Message (Section 12.18), Current Data Rate (Receive) represents the desired receive rate, in bits per second, on the link.
The Current Data Rate (Receive) Data Item contains the following
fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CDRR (bps) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: CDRR (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 is no distinction between Current Data Rate (Receive) and
Maximum Data Rate (Receive) (Section 13.12), Current Data Rate
(Receive) MUST be set equal to Maximum Data Rate (Receive). Current
Data Rate (Receive) MUST NOT exceed Maximum Data Rate (Receive).
13.15. Current Data Rate (Transmit)
The Current Data Rate (Transmit) (CDRT) Data Item is used to indicate
the rate at which the link is currently operating for transmitting
traffic.
When used in the Link Characteristics Request Message
(Section 12.18), Current Data Rate (Transmit) represents the desired
transmit rate, in bits per second, on the link.
The Current Data Rate (Transmit) Data Item contains the following
fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CDRT (bps) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: CDRT (bps) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 is no distinction between Current Data Rate (Transmit) and
Maximum Data Rate (Transmit) (Section 13.13), Current Data Rate
(Transmit) MUST be set equal to Maximum Data Rate (Transmit).
Current Data Rate (Transmit) MUST NOT exceed Maximum Data Rate
(Transmit).
13.16. Latency
The Latency Data Item is used to indicate the amount of latency, in
microseconds, on the link.
The Latency value is reported as transmission delay. The calculation
of latency is implementation dependent. For example, the latency may
be a running average calculated from the internal queuing.
The Latency Data Item contains the following fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latency :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Latency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
The Resources (RES) Data Item is used to indicate the amount of finite resources available for data transmission and reception at the destination as a percentage, with 0 meaning 'no resources remaining' and 100 meaning 'a full supply', assuming that when Resources reaches 0 data transmission and/or reception will cease. An example of such resources is battery life, but this could also include resources such as available memory for queuing, or CPU idle percentage. The specific criteria to be used for this metric is out of scope for this specification and is implementation specific. This Data Item is designed to be used as an indication of some capability of the modem and/or router at the destination. The Resources Data Item contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Item Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RES | +-+-+-+-+-+-+-+-+ 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 cannot calculate Resources, this Data Item MUST NOT be issued.
13.18. Relative Link Quality (Receive)
The Relative Link Quality (Receive) (RLQR) Data Item is used to indicate the quality of the link to a destination for receiving traffic, with 0 meaning 'worst quality' and 100 meaning 'best quality'. Quality in this context is defined as an indication of the stability of a link for reception; a destination with high Relative Link Quality (Receive) is expected to have generally stable DLEP metrics, and the metrics of a destination with low Relative Link Quality (Receive) can be expected to rapidly fluctuate over a wide range. The Relative Link Quality (Receive) Data Item contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Item Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RLQR | +-+-+-+-+-+-+-+-+ 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 cannot calculate Relative Link Quality (Receive), this Data Item MUST NOT be issued.13.19. Relative Link Quality (Transmit)
The Relative Link Quality (Transmit) (RLQT) Data Item is used to indicate the quality of the link to a destination for transmitting traffic, with 0 meaning 'worst quality' and 100 meaning 'best quality'. Quality in this context is defined as an indication of the stability of a link for transmission; a destination with high Relative Link Quality (Transmit) is expected to have generally stable DLEP metrics, and the metrics of a destination with low Relative Link Quality (Transmit) can be expected to rapidly fluctuate over a wide range.
The Relative Link Quality (Transmit) Data Item contains the following
fields:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RLQT |
+-+-+-+-+-+-+-+-+
Data Item Type: 19
Length: 1
Relative Link Quality (Transmit): A non-dimensional unsigned 8-bit
integer, 0-100, representing relative quality of the link for
transmitting traffic. Any value greater than 100 MUST be
considered as invalid.
If a device cannot calculate Relative Link Quality (Transmit), this
Data Item MUST NOT be issued.
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.
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.
(page 62 continued on part 4)
