tech-invite   World Map
3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 8175

 
 
 

Dynamic Link Exchange Protocol (DLEP)

Part 3 of 4, p. 37 to 62
Prev Section       Next Section

 


prevText      Top      ToC       Page 37 
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)                     |
   |             |                                                     |

Top      Up      ToC       Page 38 
   | 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 Types

13.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.

Top      Up      ToC       Page 39 
   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.               |
   |          |             |                  |                       |

Top      Up      ToC       Page 40 
   | 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.           |
   |          |             |                  |                       |

Top      Up      ToC       Page 41 
   | 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 Codes

13.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.

Top      Up      ToC       Page 42 
   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.

Top      Up      ToC       Page 43 
   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).

Top      Up      ToC       Page 44 
   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.

Top      Up      ToC       Page 45 
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.

Top      Up      ToC       Page 46 
   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)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 47 
   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.

Top      Up      ToC       Page 48 
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.

Top      Up      ToC       Page 49 
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.

Top      Up      ToC       Page 50 
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.

Top      Up      ToC       Page 51 
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.

Top      Up      ToC       Page 52 
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.

Top      Up      ToC       Page 53 
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.

Top      Up      ToC       Page 54 
   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.

Top      Up      ToC       Page 55 
   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.

Top      Up      ToC       Page 56 
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.

Top      Up      ToC       Page 57 
   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)                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 58 
   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.

Top      Up      ToC       Page 59 
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.

Top      Up      ToC       Page 60 
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.

Top      Up      ToC       Page 61 
   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.

Top      Up      ToC       Page 62 
   If a device cannot calculate Maximum Transmission Unit, this Data
   Item MUST NOT be issued.



(page 62 continued on part 4)

Next Section