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

RFC 8175

 
 
 

Dynamic Link Exchange Protocol (DLEP)

Part 2 of 4, p. 18 to 37
Prev Section       Next Section

 


prevText      Top      ToC       Page 18 
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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Next Section