Mobile Ad hoc Networks Working                                S. Ratliff
Group                                                           B. Berry
Internet-Draft                                               G. Harrison
Intended status: Standards Track                          D. Satterwhite
Expires: August 10, 2012 March 3, 2013                                     Cisco Systems
                                                                 S. Jury
                                                                  NetApp
                                                        February 6,
                                                         August 30, 2012

                 Dynamic Link Exchange Protocol (DLEP)
                         draft-ietf-manet-dlep-02
                        draft-ietf-manet-dlep-03

Abstract

   When routing devices rely on modems to effect communications over
   wireless links, they need timely and accurate knowledge of the
   characteristics of the link (speed, state, etc.) in order to make
   forwarding decisions. In mobile or other environments where these
   characteristics change frequently, manual configurations or the
   inference of state through routing or transport protocols does not
   allow the router to make the best decisions. A bidirectional, event-
   driven communication channel between the router and the modem is
   necessary.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 10, 2012    . February 21, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1  Requirements  . . . . . . . . . . . . . . . . . . . . . . .  6  7
   2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . .  6 .  7
   3. Credits . . . . . . . . . . . . . . . . . . . . . . . . . . .  7 .  8
   4. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . .  7 .  9
   5. Extensions to DLEP  . . . . . . . . . . . . . . . . . . . . . .  8 10
   6. Normal Session Flow . . . . . . . . . . . . . . . . . . . . .  8
   7.  Generic DLEP Packet Definition . 10
   7. Mandatory Signals and Data Items  . . . . . . . . . . . . . . .  9 12
   8.  Message Header Format Generic DLEP Packet Definition  . . . . . . . . . . . . . . . . 13
   9. DLEP Data Items . . . . 10
   9.  Message TLV Block Format . . . . . . . . . . . . . . . . . . . 10
   10. DLEP Sub-TLVs . 13
     9.1  Identification  . . . . . . . . . . . . . . . . . . . . . . 14
     9.2  DLEP Version  . 11
     10.1.  Identification Sub-TLV. . . . . . . . . . . . . . . . . . 12
     10.2.  DLEP Version Sub-TLV. . . . . . 15
     9.3  Peer Type . . . . . . . . . . . . . 13
     10.3.  Peer Type Sub-TLV . . . . . . . . . . . . 16
     9.4  MAC Address . . . . . . . . 14
     10.4.  MAC Address Sub-TLV . . . . . . . . . . . . . . . . 16
     9.5  IPv4 Address  . . . 14
     10.5.  IPv4 Address Sub-TLV. . . . . . . . . . . . . . . . . . . 15
     10.6. . . 17
     9.6  IPv6 Address Sub-TLV.  . . . . . . . . . . . . . . . . . . 16
     10.7. . . . . . 18
     9.7  Maximum Data Rate Sub-TLV . . . . . . . . . . . . . . . . 16
     10.8. . . . . . 18
     9.8  Current Data Rate Sub-TLV . . . . . . . . . . . . . . . . 17
     10.9.  Latency Sub-TLV . . . . . 19
     9.9  Expected Forwarding Time  . . . . . . . . . . . . . . . . 18
     10.10. Resources Sub-TLV . 20
     9.10  Latency  . . . . . . . . . . . . . . . . . . . . . 18
     10.11. Expected Forwarding Time Sub-TLV. . . . . 20
     9.11  Resources  . . . . . . . . 19
     10.12. . . . . . . . . . . . . . . . . 21
     9.12  Relative Link Quality Sub-TLV  . . . . . . . . . . . . . . 20
     10.13. Peer Termination Sub-TLV. . . . . . 22
     9.13  Status . . . . . . . . . . . 20
     10.14. Heartbeat Interval Sub-TLV. . . . . . . . . . . . . . . . 21
     10.15. 22
     9.14  Heartbeat Threshold Sub-TLV Interval/Threshold . . . . . . . . . . . . . . . 21
     10.16. 23
     9.15  Link Characteristics ACK Timer Sub-TLV. . . . . . . . . . 22
     10.17. . . . . . 24
     9.16  Credit Window Status Sub-TLV. . . . . . . . . . . . . . . 23
     10.18. . . . . . 24
     9.17  Credit Grant Sub-TLV. Request . . . . . . . . . . . . . . . . . . 24
     10.19. . 25
     9.18  Credit Request Sub-TLV. . . . . . . . . . . . . . . . . . 24
   11. . . . . . 26
   10. DLEP Protocol Messages . . . . . . . . . . . . . . . . . . . 25
     11.1.  Message Block . 27
     10.1  Signal TLV Values  . . . . . . . . . . . . . . . . 25
   12.  Peer Discovery Messages . . . . 27
   11. Peer Discovery Message . . . . . . . . . . . . . . . 26
     12.1.  Attached Peer Discovery Message . . . . . 28
   12. Peer Offer Message . . . . . . . . 26
     12.2.  Detached Peer Discovery Message . . . . . . . . . . . . . 27 . 28
   13. Peer Offer ACK Message . . . . . . . . . . . . . . . . . . . . . . 29
   14. Peer Update Message. Message  . . . . . . . . . . . . . . . . . . . . . 30
   15. Peer Update ACK Message. Message  . . . . . . . . . . . . . . . . . . . 31
   16. Peer Termination Message . . . . . . . . . . . . . . . . . . . 32 31
   17. Peer Termination ACK Message . . . . . . . . . . . . . . . . . 33 31
   18. Neighbor Up Message  . . . . . . . . . . . . . . . . . . . . . 33 32
   19. Neighbor Up ACK Message. Message  . . . . . . . . . . . . . . . . . . . 35 32
   20. Neighbor Down Message  . . . . . . . . . . . . . . . . . . . . 35 33
   21. Neighbor Down ACK Message. Message  . . . . . . . . . . . . . . . . . . 36 33
   22. Neighbor Update Message  . . . . . . . . . . . . . . . . . . . 37 34
   23. Neighbor Address Update Message. Heartbeat Message  . . . . . . . . . . . . . . . 38
   24. Neighbor Address Update ACK Message. . . . . . . . 34
   24. Link Characteristics Request Message . . . . . . 39
   25. Heartbeat Message . . . . . . . 35
   25. Link Characteristics ACK Message . . . . . . . . . . . . . . . 40 36
   26. Link Characteristics Message  Security Considerations . . . . . . . . . . . . . . . . . 40
   27. Link Characteristics ACK Message . . 36
   27.  IANA Considerations . . . . . . . . . . . . . . 42
   28. Security Considerations. . . . . . . . 36
     27.1  Registrations  . . . . . . . . . . . . 43
   29. IANA Considerations. . . . . . . . . . . 36
     27.2  Expert Review: Evaluation Guidelines . . . . . . . . . . . 43
     29.1 37
     27.3  Signal (Message) TLV Registrations. . Type Registration . . . . . . . . . . 37
     27.4  DLEP Data Item Registrations . . . . . . . . . 43
     29.2  Expert Review: Evaluation Guidelines . . . . . . 38
     27.5  DLEP Well-known Port . . . . . 43
     29.3  Message TLV Type Registrations . . . . . . . . . . . . . . 43
     29.4 38
     27.6  DLEP Order Registrations Multicast Address . . . . . . . . . . . . . . . . . 44
     29.5  DLEP Sub-TLV Type Registrations. . 38
   30. Appendix A.  . . . . . . . . . . . . 44
   30. Appendix A . . . . . . . . . . . . . 38
     30.1  Peer Level Message Flows . . . . . . . . . . . . . 45

1. Introduction

   There exist today a collection of modem devices that control links of
   variable bandwidth and quality. Examples of these types of links
   include line-of-sight (LOS) radios, satellite terminals, and cable/
   DSL modems. Fluctuations in speed and quality of these links can
   occur due to configuration (in the case of cable/DSL modems), or on . . . . 38
       30.1.1  Modem Device Restarts Discovery  . . . . . . . . . . . 38
       30.1.2  Modem Device Detects Peer Offer Timeout  . . . . . . . 39
       30.1.3  Router Peer Offer Lost . . . . . . . . . . . . . . . . 40
       30.1.4  Discovery Success  . . . . . . . . . . . . . . . . . . 40
       30.1.5  Router Detects a
   moment-to-moment basis, due to physical phenomena like multipath
   interference, obstructions, rain fade, etc. It is also quite possible
   that link quality and bandwidth varies with respect to individual
   neighbors on Heartbeat timeout . . . . . . . . . . 41
       30.1.6  Modem Detects a link, and with the type of traffic being sent. As an
   example, consider the case of an 802.11g access point, serving 2
   associated laptop computers. In this environment, the answer to the
   question "What is the bandwidth on the 802.11g link?" is "It depends
   on which associated laptop we're talking about, and on what kind of
   traffic is being sent." While the first laptop, being physically
   close to the access point, may have a bandwidth of 54Mbps for
   unicast traffic, the other laptop, being relatively far away, or
   obstructed by some object, can simultaneously have a bandwidth of
   only 32Mbps for unicast. However, for multicast traffic sent from the
   access point, all traffic is sent at the base transmission rate
   (which is configurable, but depending on the model of the access
   point, is usually 24Mbps or less).

   In addition to utilizing variable bandwidth links, mobile networks
   are challenged by the notion that link connectivity will come and go
   over time.  Effectively utilizing a relatively short-lived connection
   is problematic in IP routed networks, as routing protocols tend to
   rely on independent timers at OSI Layer 3 to maintain network
   convergence (e.g. HELLO messages and/or recognition of DEAD routing
   adjacencies). These short-lived connections can be better utilized
   with an event-driven paradigm, where acquisition of a new neighbor
   (or loss of an existing one) is somehow signaled, as opposed to a
   timer-driven paradigm.

   Another complicating factor for mobile networks are the different
   methods of physically connecting the modem devices to the router.
   Modems can be deployed as an interface card in a router's
   chassis, or as a standalone device connected to the router via
   Ethernet, USB, or even a serial link. In the case of Ethernet or
   serial attachment, with existing protocols and techniques, routing
   software cannot be aware of convergence events occurring on the
   radio link (e.g. acquisition or loss of a potential routing
   neighbor), nor can the router be aware of the actual capacity of
   the link. This lack of awareness, along with the variability in
   bandwidth, leads to a situation where quality of service (QoS)
   profiles are extremely difficult to establish and properly
   maintain. This is especially true of demand-based access schemes
   such as Demand Assigned Multiple Access (DAMA) implementations
   used on some satellite systems. With a DAMA-based system,
   additional bandwidth may be available, but will not be used
   unless the network devices emit traffic at rate higher than the
   currently established rate. Increasing the traffic rate does not
   guarantee additional bandwidth will be allocated; rather, it may
   result in data loss and additional retransmissions on the link.

   In attempting to address the challenges listed above, the authors
   have developed the Data Link Exchange Protocol, or DLEP. The DLEP
   protocol runs between a router and its attached modem devices,
   allowing the modem to communicate link characteristics as they
   change, and convergence events (acquisition and loss of potential
   routing neighbors). The following diagrams are used to illustrate
   the scope of DLEP sessions.

   |-----Local Neighbor-----|          |-----Remote Neighbor----|
   |                        |          |     (far-end device)   |

   +--------+       +-------+          +-------+       +--------+
   | Router |=======| Modem |{~~~~~~~~}| Modem |=======| Router |
   |        |       | Device|          | Device|       |        |
   +--------+       +-------+          +-------+       +--------+

            |       |       | Link     |       |       |
            |-DLEP--|       | Protocol |       |-DLEP--|
            |       |       | (e.g.    |       |       |
            |       |       | 802.11)  |       |       |

                          Figure 1: DLEP Network

   In Figure 1, when a local client (Modem device) detects the
   presence of a remote neighbor, it sends an indication to its
   local router via the DLEP session. Upon receipt of the indication,
   the local router would take appropriate action (e.g. initiation
   of discovery or HELLO protocols) to converge the network. After
   notification of the new neighbor, the modem device utilizes the
   DLEP session to report the characteristics of the link (bandwidth,
   latency, etc) to the router on an as-needed basis.

   DLEP is independent of the underlying link type and topology.
   Figure 2 shows how DLEP can support a configuration whereby
   routers are connected with different link types and with different
   network configurations. In this setup, the routers are connected
   with two different devices (Modem device A and Modem device B).
   Modem A is connected via a point-to-point link, whereas Modem B
   is connected via a shared medium. In both cases, the DLEP session
   is used to report the characteristics of the link (bandwidth,
   latency, etc.) to network neighbors on an as-needed basis. The
   modem is also able to use the DLEP session to notify the router
   when the remote neighbor is lost, shortening the time required to
   re-converge the network.

              +--------+                      +--------+       +------+ Modem A|                      | Modem A+-----+       |      | Device |  <===== // ======>   | Device |     |       |      +--------+      P-t-P Link      +--------+     |       |                       Protocol                      |   +---+----+                                            +---+----+   | Router |                                            | Router |   |        |                                            |        |   +---+----+                                            +---+----+       |                                                     +       |      +--------+                      +--------+     |       +------+ Modem B|                      | Modem B|     |              | Device |   o o o o o o o o    | Device +-----+              +--------+    o  Shared   o     +--------+                             o Medium  o                              o       o                               o     o                                o   o                                  o                             +--------+                             | Modem B|                             | Device |                             +---+----+                                 |                                 |                             +---+----+                             | Router |                             |        |                             +--------+                Figure 2: DLEP Network with Multiple Modem Devices

   DLEP exists as a collection of type-length-value (TLV) based messages
   using [RFC5444] formatting. The protocol can be used for both Ethernet
   attached modems (utilizing, for example, a UDP socket for transport
   of the RFC 5444 packets), or in environments where the modem is an
   interface card in a chassis (via a message passing scheme). DLEP
   utilizes a session paradigm between the modem device and its
   associated router. If multiple modem devices are attached to a
   router (as in FIgure 2), a separate DLEP session MUST exist for each
   modem. If a modem device supports multiple connections to a router
   (via multiple logical or physical interfaces), or supports
   connections to multiple routers, a separate DLEP session MUST exist
   for each connection.

1.1  Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119].

2. Assumptions

   In order to implement discovery in the DLEP protocol (thereby
   avoiding some configuration), we have defined a first-speaker and a
   passive-listener scheme. Borrowing from existing terminology, this
   document refers to the first-speaker as the 'client', and the passive
   listener as the 'server', even though there is no client/server
   relationship in the classic sense. In a typical deployment, a router
   would appear as the DLEP 'server', and an attached modem device would
   act as the 'client' (e.g. the initiator for discovery).

   DLEP assumes that participating clients appear to the server as a
   transparent bridge - specifically, the assumption is that the
   destination MAC address for data traffic in any frame emitted by
   the server should be the MAC address of the next-hop router or end-
   device, and not the MAC address of any of the intervening clients.

   DLEP assumes that security on the session (e.g. authentication of
   session partners, encryption of traffic, or both) is dealt with by
   the underlying transport mechanism for the RFC 5444 packets (e.g. by
   using a transport such as DTLS [DTLS]).

   DLEP utilizes a session-oriented paradigm. There are two classes
   of sessions - the first is identified as a 'peer session'. The
   peer session exists between a DLEP server and a DLEP client. All
   DLEP messages between client and server are transmitted within the
   context of the peer session.

   The other type of DLEP session is referred to as a 'neighbor session'. Heartbeat timeout  . . . . . . . . . . 41
       30.1.7  Peer Terminate (from Modem) Lost . . . . . . . . . . . 42
       30.1.8  Peer Terminate (from Router) Lost  . . . . . . . . . . 42
     30.2  Neighbor sessions can be instantiated by either the DLEP server or
   client, and represent an identifiable destination (i.e. an address)
   within the network. Examples of a destination would be a unicast
   address (for either a next-hop router, or for an end-station), or
   a multicast address. A DLEP neighbor session MUST exist for every
   destination that exists in the network.

   The optional [RFC5444] message header Sequence Number MUST be
   included in all DLEP packets. Sequence Numbers start at 1 and are
   incremented by one for each original Specific Message Flows  . . . . . . . . . . . . . 42
       30.2.1  Modem Neighbor Up Lost . . . . . . . . . . . . . . . . 43
       30.2.2  Router Detects Duplicate Neighbor Ups  . . . . . . . . 43
       30.2.3  Neighbor Up, No Layer 3 Addresses  . . . . . . . . . . 44
       30.2.4  Neighbor Up with IPv4, No IPv6 . . . . . . . . . . . . 44
       30.2.5  Neighbor Up with IPv4 and retransmitted message.  The
   unsigned 16-bit Sequence Number rolls over at 65535 to IPv6 . . . . . . . . . . . . 44
       30.2.6  Neighbor Session Success . . . . . . . . . . . . . . . 45
   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 45
   Normative References . . . . . . . . . . . . . . . . . . . . . . . 45
   Informative References . . . . . . . . . . . . . . . . . . . . . . 46
   Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46

1.  A
   Sequence Number of 0 is not valid. Sequence Numbers are unique
   within the context of a DLEP session. Sequence numbers are used in
   DLEP to correlate a response to Introduction

   There exist today a request.

3. Credits

   DLEP includes an OPTIONAL credit-windowing scheme analogous to the
   one documented in [RFC5578]. In this scheme, traffic between the
   DLEP client collection of modem devices that control links of
   variable bandwidth and the DLEP server is treated as two unidirectional
   windows. This document identifies quality. Examples of these windows as the "Client
   Receive Window", or CRW, types of links
   include line-of-sight (LOS) radios, satellite terminals, and
   cable/DSL modems. Fluctuations in speed and quality of these links
   can occur due to configuration (in the "Server Receive Window", case of cable/DSL modems), or SRW.

   If credits are used, they MUST be granted by the receiver
   on a
   given window - that is, on the "Client Receive Window" (CRW),
   the DLEP client is responsible for granting credits to the server,
   allowing it (the server) to send data moment-to-moment basis, due to the client. Likewise,
   the DLEP server physical phenomena like multipath
   interference, obstructions, rain fade, etc. It is responsible for granting credits on the SRW,
   which allows the client to send data to the server.

   DLEP expresses all credit data in number of octets. The total number
   of credits on a window, also quite possible
   that link quality and the increment to add bandwidth varies with respect to a grant, are
   always expressed as a 64-bit unsigned quantity.

   If used, credits are managed individual
   neighbors on a neighbor session basis; that is,
   separate credit counts are maintained for each neighbor session
   requiring the service. Credits do not apply to DLEP peer sessions.

4. Metrics

   DLEP includes the ability for the client link, and server to communicate
   metrics that reflect with the characteristics (e.g. bandwidth, latency) type of the variable-quality link in use. traffic being sent. As mentioned in an
   example, consider the
   introduction section case of an 802.11g access point, serving 2
   associated laptop computers. In this document, metrics have to be used
   within a context - for example, metrics to a unicast address in environment, the network. DLEP allows for metrics answer to be sent within two
   contexts - neighbor session context (those for a given destination
   within the network), and peer session context (those that apply
   to all destinations accessed via
   question "What is the DLEP client). Metrics
   supplied bandwidth on DLEP Peer messages are, by definition, in the context
   of a peer session; metrics supplied 802.11g link?" is "It depends
   on Neighbor messages are, by
   definition, used in the context of a neighbor session.

   Supplying metrics in a peer session context gives clients the
   ability to supply default metrics which associated laptop we're talking about, and on a 'device-wide' basis. It what kind of
   traffic is
   left to implementations being sent." While the first laptop, being physically
   close to choose sensible default values based on
   their specific characteristics. Additionally, the metrics (either
   at access point, may have a peer or neighbor session context) MAY be used to report non-
   changing, or static, metrics. Clients having static link metric
   characteristics SHOULD report metrics only once bandwidth of 54Mbps for a given
   neighbor session (or peer session, if all connections via unicast
   traffic, the client
   are of this static nature).

   The approach other laptop, being relatively far away, or obstructed
   by some object, can simultaneously have a bandwidth of allowing only 32Mbps
   for different contexts unicast. However, for metric data
   increases both the flexibility and the complexity of using metric
   data. This document details the mechanism whereby the data is
   transmitted, however, multicast traffic sent from the specific algorithms for utilizing access
   point, all traffic is sent at the
   dual-context metrics base transmission rate (which is out of scope and not addressed by this
   document.

5. Extensions to DLEP

   While this draft represents
   configurable, but depending on the best efforts model of the co-authors, and
   the working group, to be functionally complete, it access point, is recognized
   that extensions
   usually 24Mbps or less).

   In addition to DLEP will in all likelihood be necessary as more
   link types utilizing variable bandwidth links, mobile networks
   are utilized. To allow for future innovation, the draft
   allocates numbering space for experimental orders and sub-TLVs. DLEP
   implementations MUST be capable of parsing and acting on the orders
   and sub-TLVs as documented in this specification. DLEP orders/sub-TLVs
   in the experimental numbering range SHOULD be silently dropped challenged by an
   implementation if they are not understood. The intent of the
   experimental numbering space notion that link connectivity will come and go
   over time.  Effectively utilizing a relatively short-lived connection
   is problematic in IP routed networks, as routing protocols tend to allow for further development
   rely on independent timers at OSI Layer 3 to maintain network
   convergence (e.g. HELLO messages and/or recognition of
   DLEP protocol features and function. If subsequent development yields
   new features with sufficient applicability, those features should DEAD routing
   adjacencies). These short-lived connections can be
   either included in better utilized
   with an update event-driven paradigm, where acquisition of this specification, or documented in
   a standalone specification.

6. Normal Session Flow

   A session between a client and a server new neighbor
   (or loss of an existing one) is established by exchanging signaled, as opposed to a timer-
   driven paradigm.

   Another complicating factor for mobile networks are the different
   methods of physically connecting the "Peer Discovery" and "Peer Offer" messages described below.

   The flows described modem devices to the router.
   Modems can be deployed as an interface card in this document create a state-full protocol
   between client and server. Both client and server initialize in router's chassis, or
   as a
   "discovery" state, and standalone device connected to the client issues router via Ethernet, USB, or
   even a "Peer Discovery" message.
   When serial link. In the server receives a Peer Discovery, it responds case of Ethernet or serial attachment,
   with a "Peer
   Offer" message, existing protocols and enters an "in session" state with the client.
   Receipt techniques, routing software cannot be
   aware of convergence events occurring on the Peer Offer at radio link (e.g.
   acquisition or loss of a potential routing neighbor), nor can the client causes it (the client) to
   transition into
   router be aware of the "in session" state.

   Once that exchange has successfully occurred, messages transferred
   in actual capacity of the context link. This lack of
   awareness, along with the peer session will consist variability in bandwidth, leads to a
   situation where quality of
   o  Periodic 'Heartbeat' messages, intended service (QoS) profiles are extremely
   difficult to keep the peer session
      alive, establish and to verify bidirectional connectivity, and/or
   o  Peer Update messages, indicating some change in status that one properly maintain. This is especially true
   of demand-based access schemes such as Demand Assigned Multiple
   Access (DAMA) implementations used on some satellite systems. With a
   DAMA-based system, additional bandwidth may be available, but will
   not be used unless the peers needs to communicate to network devices emit traffic at rate higher
   than the currently established rate. Increasing the traffic rate does
   not guarantee additional bandwidth will be allocated; rather, it may
   result in data loss and additional retransmissions on the other.

   In addition to link.

   Addressing the messages challenges listed above, the peers will transmit DLEP
   messages concerning destinations in authors have developed
   the network. These messages
   trigger creation/maintenance/termination of 'neighbor sessions'. For
   example, Data Link Exchange Protocol, or DLEP. The DLEP protocol runs
   between a peer will inform router and its DLEP partner of attached modem devices, allowing the presence modem
   to communicate link characteristics as they change, and convergence
   events (acquisition and loss of a
   new destination via potential routing neighbors). The
   following diagrams are used to illustrate the "Neighbor Up" message. Receipt scope of a Neighbor
   Up causes DLEP packets.

   |-------Local Node-------|          |-------Remote Node------|
   |                        |          |                        |
   +--------+       +-------+          +-------+       +--------+
   | Router |=======| Modem |{~~~~~~~~}| Modem |=======| Router |
   |        |       | Device|          | Device|       |        |
   +--------+       +-------+          +-------+       +--------+
            |       |       | Link     |       |       |
            |-DLEP--|       | Protocol |       |-DLEP--|
            |       |       | (e.g.    |       |       |
            |       |       | 802.11)  |       |       |

                          Figure 1: DLEP Network

   In Figure 1, when the receiving peer to allocate local modem detects the necessary resources,
   creating presence of a neighbor session, and transition remote
   node, it (the local modem) sends a signal to an "in session" state
   on its router via the newly created neighbor session. The in-session state persists
   until notification of neighbor loss is received, or by optional
   timeout due to inactivity.

   The loss DLEP
   protocol. Upon receipt of a destination is communicated via the "Neighbor Down"
   message, and changes in status to signal, the destination (e.g. varying
   link quality, or addressing changes) are communicated via a
   "Neighbor Update" message.

   Again, metrics can be expressed within local router may take
   whatever action it deems appropriate, such as initiating discovery
   protocols, and/or issuing HELLO messages to converge the context of network. On
   a neighbor
   session via continuing, as-needed basis, the Neighbor Update message, or within modem devices utilize DLEP to
   report any characteristics of the context link (bandwidth, latency, etc) that
   have changed. DLEP is independent of
   a peer session (reflecting the link as a whole) via type and topology
   supported by the Peer Update
   message. In cases modem.

   Figure 2 shows how DLEP can support a configuration where metrics routers are provided on the peer session, the
   receiving peer MUST propagate the metrics to all neighbor sessions
   accessed via the peer.
   connected with different link types. In this example, Modem A DLEP peer MAY send metrics both in a peer
   session context (via the Peer Update message) and
   implements a neighbor session
   context (via Neighbor Update) at any time. The heuristics for
   applying received peer session point-to-point link, and neighbor session metrics Modem B is left
   to implementations. connected via a
   shared medium. In addition to receiving metrics about both cases, the link, DLEP provides for
   the ability for a server protocol is used to request a different amount of bandwidth,
   or latency, from the client via report the Link Characteristics Message.
   This allows
   characteristics of the server link (bandwidth, latency, etc.) to deal with requisite increases (or decreases)
   of allocated bandwidth/latency in demand-based schemes in a more
   deterministic manner.

7. Generic DLEP Packet Definition routers.
   The Generic DLEP Packet Definition follows modem is also able to use the format for packets
   defined in [RFC5444].

   The Generic DLEP Packet Definition 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version| Flags session to notify the router
   when the remote node is lost, shortening the time required to re-
   converge the network.

            +--------+                     +--------+
       +----+ Modem A|                     | Packet Sequence Number Modem A+---+
       | Packet TLV    | Device |  <===== // ======>  | Device |   | Block...
       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    +--------+      P-2-P Link     +--------+   | Message (Contains DLEP message)...
   +---+----+                                       +---+----+
   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Version                - Version of RFC 5444 specification on
                            which the packet/messages/TLVs are
                            constructed.

   Flags                  - 4 bit field. All bits MUST be ignored
                            by DLEP implementations.

   Packet Sequence Number - If present, the packet sequence number
                            is parsed and ignored. DLEP does NOT
                            use or generate packet sequence numbers.

   Packet TLV block       - A TLV block which contains packet level
                            TLV information. DLEP implementations
                            MUST NOT use this TLV block.

   Message                - The packet MAY contain zero or more
                            messages, however, DLEP messages are
                            encoded within an RFC 5444 Message
                            TLV Block.

8. Message Header Format

   DLEP utilizes the following format for the RFC 5444 message header

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Router |    Msg Type   |Msg Flg|AddrLen|          Message Size                                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Router |          Message Seq Num
   |           TLV Block...        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Type                                       |        |
   +---+----+                                       +---+----+
       |     +--------+                     +--------+  |
       +-----+ Modem B|                     | Modem B|  |
             | Device |   o o o o o o o o   | Device +--+
             +--------+    o  Shared   o    +--------+
                            o Medium  o
                             o       o
                              o     o
                               o   o
                                 o
                            +--------+
                            | Modem B|
                            | Device |
                            +---+----+
                                |
                                |
                            +---+----+
                            | Router |
                            |        |
                            +--------+

            Figure 2: DLEP Network with Multiple Modem Devices

   DLEP defines a set of logical signals used by modems and their
   attached routers. The signals are used to communicate events that
   occur on the physical link(s) managed by the modem: for example, a
   remote node entering or leaving the network, or that the link has
   changed. Associated with these signals are a set of data items - An 8-bit field which specifies
   information that describes the type remote node (e.g., address
   information), and/or the characteristics of the message. For DLEP, this field
                            contains DLEP_MESSAGE (value TBD)

   Message Flags          - Set link to 0x1 (bit 3, mhasseqnum bit the remote
   node.

   The protocol is
                            set).  All other bits defined as a collection of type-length-value (TLV)
   based messages, specifying the signals that are unused exchanged between a
   router and a modem, and MUST
                            be set to '0'.

   Message Address Length - A 4-bit unsigned integer field encoding the
                            length data items associated with the signal.
   This document specifies transport of all addresses included in this
                            message. DLEP implementations do not use signals and data items via
   the UDP transport. Other transports for the protocol are possible,
   but are outside the scope of this field; contents SHOULD document.

   DLEP signals are further defined as mandatory or optional. Signals
   will additionally have mandatory and optional data items.
   Implementations MUST support all mandatory signals and their
   mandatory data items to be ignored.

   Message Size           - A 16-bit unsigned integer field which
                            specifies the number considered compliant. Implementations MAY
   also support some, or all, of octets that make up the message including optional signals and data items.

   DLEP uses a session-oriented paradigm between the message header.

   Message Sequence Number - A 16-bit unsigned integer field modem device and
   its associated router. If multiple modem devices are attached to a
   router (as in Figure 2), a separate DLEP session MUST exist for each
   modem. If a modem device supports multiple connections to a router
   (via multiple logical or physical interfaces), or supports
   connections to multiple routers, a separate DLEP session MUST exist
   for each connection. This router/modem session provides a carrier for
   information exchange concerning neighbors (remote nodes) that
                             contains a sequence number, generated by are
   accessible via the originator modem device. As such, all of the message. Sequence
                             numbers range from 1 to 65535. Sequence
                             numbers roll over at 65535 to 1; 0 is
                             invalid.

   TLV Block               - TLV Block included neighbor-level
   exchanges in the message.

9. Message TLV Block Format

   The DLEP protocol is organized can be envisioned as a set of orders, each with a
   collection of Sub-TLVs. The Sub-TLVs carry building an information needed
   to process and/or establish context (e.g. base
   concerning the MAC address of a
   far-end router), remote nodes, and the 'tlv-type' field link characteristics to those
   nodes.

   Multicast traffic is handled in IP networks by deriving a Layer 2 MAC
   address based on the message TLV
   block carries the DLEP order itself. The Layer 3 address. Leveraging on this scheme,
   Multicast traffic is supported in DLEP orders are
   enumerated simply by treating the derived
   MAC address as any other destination in section 11.1 of this document, and the messages
   created using network. To support these orders are documented in sections 12 through
   27.
   logical destinations, one of the DLEP uses participants (typically, the following settings for an RFC 5444 Message TLV
   block:

   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |       TLVs Length             |  TLV Type     | TLV Flags     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    Length    |       Value...                                 |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLVs Length - A 16-bit unsigned integer field that contains
   router) informs the total
                 number other as to the existence of octets in all the logical
   neighbor. The modem, once it is aware of the immediately following
                 TLV elements (tlvs-length not included).

   TLV Type    - An 8-bit unsigned integer field specifying existence of this
   logical neighbor, reports link characteristics just as it would for
   any other destination in the network. The specific algorithms a modem
   would use to report metrics on multicast (or logical) destinations is
   outside the type scope of the TLV. DLEP uses this field specification, and is left to specify the DLEP
                 order. Valid DLEP orders are defined specific
   implementations to decide.

1.1  Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in section 11.1
                 of this document.

   TLV Flags   - An 8-bit flags bit field. Bit 3 (thasvalue) MUST be
                 set; all other bits
   document are not used and MUST be set to '0'.

   Length      - Length of the 'Value' field be interpreted as described in BCP 14, RFC 2119
   [RFC2119].

2. Assumptions

   Routers and modems that exist as part of the TLV

   Value       - A field of length <Length> which contains data
                 specific to same node (e.g., that
   are locally connected) can utilize a particular TLV type. discovery technique to locate
   each other, thus avoiding a-priori configuration. Either entity (the
   router or the modem) can initiate the discovery process. In cases
   where both entities initiate discovery, a race condition can occur.
   When this race condition occurs, the router MUST cease its active
   discovery, and respond to the modem's request.

   DLEP
                 case, this field will consist of utilizes a collection session-oriented paradigm. A router and modem form a
   session by completing the discovery process. This router-modem
   session persists unless or until it either (1) times out, based on
   the timeout values supplied, or (2) is explicitly torn down by one of
                 DLEP sub-TLVs appropriate for
   the DLEP action
                 specified participants. Note that use of timers in the TLV type field.

10. DLEP sub-TLVs

   DLEP protocol messages are transported in is OPTIONAL; that
   is, implementations can choose to run with no timers (or effectively,
   timers set to an RFC 5444 message TLV.
   All infinite value).

   DLEP messages use the RFC 5444 DLEP_MESSAGE value (TBD). The
   protocol messages consist of assumes that participating modems, and their physical links, act
   as a DLEP order, encoded in transparent bridge. Specifically, the assumption is that the 'tlv-type'
   field
   destination MAC address for data traffic in any frame emitted by the message TLV block, with the 'value' field of
   router should be the TLV
   block containing a collection (1 or more) DLEP sub-TLVs.

   The format MAC address of DLEP Sub-TLVs is consistent with RFC 5444 in that the
   Sub-TLVs contain a flag field device in addition to the type, length, and
   value fields. Valid DLEP Sub-TLVs are:

          TLV      TLV
          Value    Description
          =========================================
          TBD      Identification sub-TLV
          TBD remote node. DLEP Version sub-TLV
          TBD      Peer Type sub-TLV
          TBD
   also assumes that MAC Address sub-TLV
          TBD      IPv4 Address sub-TLV
          TBD      IPv6 Address sub-TLV
          TBD      Maximum Data Rate (MDR) sub-TLV
          TBD      Current Data Rate (CDR) sub-TLV
          TBD      Latency sub-TLV
          TBD      Resources sub-TLV
          TBD      Expected Forwarding Time (ETX) sub-TLV
          TBD      Relative Link Quality (RLQ) sub-TLV
          TBD      Status sub-TLV
          TBD      Heartbeat Interval sub-TLV
          TBD      Heartbeat Threshold sub-TLV
          TBD      Neighbor down ACK timer sub-TLV
          TBD      Link Characteristics ACK timer sub-TLV
          TBD      Credit Window Status sub-TLV
          TBD      Credit Grant sub-TLV
          TBD      Credit Request sub-TLV

   DLEP sub-TLVs 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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  TLV Type     |TLV Flags=0x10 | Length        | Value...      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type    - An 8-bit unsigned integer field specifying addresses are unique within the type context of the sub-TLV.

   TLV Flags   - An 8-bit flags bit field. Bit 3 (thasvalue) MUST be
                 set, all other bits are not used and MUST be set
   router-modem session.

   This document refers to
                 '0'.

   Length      - An 8-bit length of a remote node as a "Neighbor". Neighbors can
   be identified by either the value field of router or the sub-TLV

   Value       - A field of length <Length> which contains data
                 specific to modem, and represent a particular sub-TLV.

10.1  Identification Sub-TLV

   This Sub-TLV MUST exist in
   specific destination (e.g., an address) that exists on the TLV Block for all link(s)
   managed by the modem. Examples of a destination include a MAC
   address, a unicast Layer 3 address, or a multicast Layer 3 address.
   As "neighbors" are discovered, DLEP messages, routers and
   MUST be modems build an
   information base on destinations accessible via the first Sub-TLV of modem. Changes in
   link characteristics MAY then be reported as being "modem-wide"
   (effecting ALL neighbors accessed via the message. Further, there MUST modem) or MAY be ONLY
   one Identification Sub-TLV in neighbor
   (destination) specific.

   The DLEP signals concerning neighbors thus become the way for routers
   and modems to maintain, and notify each other about, an RFC 5444 message TLV block. information
   base representing the physical and logical (e.g., multicast)
   destinations accessible via the modem device. The
   Identification sub-TLV contains client information base
   would contain addressing information (e.g., MAC address, and server identification
   OPTIONALLY, Layer 3 addresses), link characteristics (metrics), and
   OPTIONALLY, flow control information used to establish (credits).

   DLEP assumes that security on the proper context session (e.g. authentication of
   session partners, encryption of traffic, or both) is dealt with by
   the underlying transport mechanism (e.g., by using a transport such
   as DTLS [DTLS]).

   Sequence Numbers for processing DLEP
   protocol messages.

   The Identification sub-TLV 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 messages start at 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV Type = TBD |TLV Flags=0x10 |Length = 8     | Server ID     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Server ID                  | Client ID     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Client ID                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type      - Value TBD

   TLV Flags     - 0x10, Bit 3 (thasvalue) is set, all other bits and are
                   unused incremented by
   one for each original and MUST be set retransmitted message.  The unsigned 16-bit
   Sequence Number rolls over at 65535 to '0'.

   Length        - 8

   Server ID     - Indicates 0. Sequence Numbers are unique
   within the Server ID context of the a DLEP session.

   Client ID     - indicates the Client ID Sequence numbers are used in
   DLEP to correlate a response to a request.

   This document specifies an implementation of the DLEP session.

   When the client initiates discovery (via the Peer Discovery message),
   it MUST set signals and
   data items running over the Client ID to UDP transport, utilizing a 32-bit quantity well-known UDP
   Port number. It is assumed that will DLEP running over other transport
   mechanisms would be used documented separately.

3. Credits

   DLEP includes an OPTIONAL credit-windowing scheme analogous to
   uniquely identify the
   one documented in [RFC5578]. In this session from scheme, traffic between the client-side. The client
   router and modem is treated as two unidirectional windows. This
   document identifies these windows as the "Modem Receive Window", or
   MRW, and the "Router Receive Window", or RRW.

   If credits are used, they MUST
   set be granted by the Server ID receiver on a given
   window - that is, on the "Modem Receive Window" (MRW), the modem is
   responsible for granting credits to '0'. When responding the router, allowing it (the
   router) to send data to the Peer Discovery
   message, modem. Likewise, the server MUST echo router is
   responsible for granting credits on the RRW, which allows the modem
   to send data to the Client ID, router.

   DLEP expresses all credit data in number of octets. The total number
   of credits on a window, and MUST supply its own
   unique 32-bit quantity the increment to add to a grant, are
   always expressed as a 64-bit unsigned quantity.

   If used, credits are managed on a neighbor-specific basis; that is,
   separate credit counts are maintained for each neighbor requiring the
   service. Credits do not apply to identify the DLEP session from the server's
   perspective. After that exists between
   routers and modems.

4. Metrics

   DLEP includes the Peer Discovery/Peer Offer exchange, both ability for the
   Client ID router and the Server ID MUST be set modem to communicate
   metrics that reflect the values obtained from characteristics (e.g. bandwidth, latency) of
   the Peer DIscovery/Peer Offer sequence.

10.2  DLEP Version Sub-TLV

   The DLEP Version Sub-TLV is an OPTIONAL TLV variable-quality link in use. As mentioned in both the Peer
   Discovery and Peer Offer messages. The Version Sub-TLV is introduction
   section of this document, metrics have to be used within a context -
   for example, metrics to
   indicate a unicast address in the client or server version of network. DLEP allows
   for metrics to be sent within two contexts - metrics for a specific
   neighbor (those for a given destination within the protocol. The client network), and server MAY use this information
   "modem-wide" (those that apply to decide if all destinations accessed via the peer is running
   at a supported level.

   The
   modem). Metrics supplied on DLEP Version Sub-TLV contains Peer signals are, by definition,
   modem-wide; metrics supplied on Neighbor signals are, by definition,
   used for 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV Type =TBD  |TLV Flags=0x10 |Length=4       | Major Version |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Major Version |       Minor Version           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type      - TBD
   TLV Flags     - 0x10, Bit 3 (thasvalue) specific neighbor only.

   It is set, all other bits are
                   not used and MUST left to implementations to choose sensible default values based
   on their specific characteristics. Additionally, this mechanism
   (either at a modem-wide or specific neighbor context) MAY be set used to '0'.

   Length        - Length is 4

   Major Version - Major version of the client
   report non-changing, or router protocol.

   Minor Version - Minor version of static, metrics. Modems having static link
   metric characteristics MAY report metrics only once for a given
   neighbor (or once on a modem-wide basis, if all connections via the client or router protocol.

   Support
   modem are of this draft is indicated by setting static nature).

   The approach of allowing for different contexts for metric data
   increases both the Major Version
   to '1', flexibility and the Minor Version to '2' (e.g. Version 1.2).

10.3  Peer Type Sub-TLV

   The Peer Type Sub-TLV complexity of using metric
   data. This document details the mechanism whereby the data is used by
   transmitted, however, the specific algorithms (precedence, etc) for
   utilizing the server dual-context metrics is out of scope and client to give
   additional information as not addressed
   by this document.

5. Extensions to its type. It is an OPTIONAL sub-TLV in
   both DLEP

   While this draft represents the Peer Discovery Message and best efforts of the Peer Offer message. The peer
   type is a string co-authors, and is envisioned
   the working group, to be used for informational
   purposes (e.g. as output in a display command).

   The Peer Type sub-TLV 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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Type =TBD  |TLV Flags=0x10 |Length= peer   |Peer Type Str  |
  |               |               |type string len|Max Len = 80   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type         - TBD

   TLV Flags        - 0x10, Bit 3 (thasvalue) functionally complete, it is set, recognized that
   extensions to DLEP will in all other bits likelihood be necessary as more link
   types are not used utilized. To allow for future innovation, the draft
   allocates numbering space for experimental implementations of both
   signals and data items.

   DLEP implementations MUST be set capable of parsing and acting on the
   mandatory signals and data items as documented in this specification.
   DLEP signals/data items that are optional, or are in the experimental
   numbering range SHOULD be silently dropped by an implementation if
   they are not understood.

   The intent of the optional signals and data items, as well as the
   experimental numbering space, is to '0'.

   Length           - Length allow for further development of peer type string (80 bytes maximum).

   Peer Type String - Non-Null terminated peer type string,
   DLEP protocol features and function. Having experimental space
   reserved for both signals and data items gives maximum
                      length of 80 bytes. flexibility
   for extending the protocol as conditions warrant. For example, a satellite
                      modem might set this variable
   experimental data items could be used by implementations to 'Satellite
                      terminal'.

10.4  MAC Address Sub-TLV

   The MAC address Sub-TLV MUST appear in all neighbor-oriented
   messages (e.g. Neighbor Up, Neighbor Up ACK, Neighbor Down, Neighbor
   Down ACK, Neighbor Update, Link Characteristics Request, send
   additional metrics. A combination of experimental signals, and Link
   Characteristics ACK). The MAC Address sub-TLV contains
   associated data items, could be used to implement new flow control
   schemes. If subsequent research and development define new features
   and function, then it should be standardized either as an update to
   this document, or as an additional stand-alone specification.

6. Normal Session Flow

   At the address start of a run, DLEP implementations (both router and modem)
   initialize the far-end (neighbor) destination, communications path. In a UDP implementation, this
   includes opening a socket and may binding to the well-known port address
   (TBD). Once the communications path is established, an implementation
   would either, depending on configuration, proceed to periodically
   issue a "Peer Discovery" message. The Peer Discovery MAY be sent
   either via the multicast address allocated for DLEP (TBD), or via a physical
   unicast address, or drop into a virtual destination. Examples "passive receive" mode, waiting on
   receipt of a virtual destination would
   be Peer Discovery.

   Both modem and router initialize in a multicast MAC address, or "discovery" state. Either the broadcast MAC (0xFFFFFFFFFFFF).

   The MAC Address sub-TLV contains
   modem, 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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Type =TBD  |TLV Flags=0x10 |Length = 6     |MAC Address    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      MAC Address                              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | MAC Address   |
  +-+-+-+-+-+-+-+-+

   TLV Type    - TBD

   TLV Flags   - 0x10, Bit 3 (thasvalue) is set, all other bits are not
                 used and MUST router, or both, will then issue a "Peer Discovery"
   signal. The Peer Discovery signal MAY be set issued to '0'.

   Length      - 6

   MAC Address - MAC Address a unicast address
   (if a-priori knowledge of the destination (either physical address exists), or
                 virtual).

10.5  IPv4 Address Sub-TLV to the multicast
   address TBD.

   The IPv4 Address Sub-TLV receiver of a Peer Discovery message responds with a "Peer Offer"
   signal to indicate readiness to participate in the DLEP session. The
   receiver of a Peer Offer message responds with a "Peer Offer ACK"
   message, completing discovery. While the Peer Discovery message MAY
   be used in Neighbor Up, Neighbor
   Update, sent to the DLEP multicast address (TBD), the Peer Offer, and all
   subsequent traffic, is sent to the unicast address that originated
   the Peer Update Messages, if Discovery. Once the Peer Offer signal is acknowledged, both
   participants (router and modem) transition to the "in session" state,
   creating a logical, stateful session between the modem and the
   router. Subsequent DLEP signals are then processed within the client is aware context
   of this router/modem session. DLEP partners use these signals to
   build their respective information bases regarding destinations that
   are accessible via the
   Layer 3 address. When included in Neighbor messages, the IPv4
   Address sub-TLV contains modem, and link characteristics associated
   with those destinations.

   The "in session" state created by the IPv4 address discovery signals is maintained
   until one of the far-end neighbor.
   In the following conditions occur:

   o  The session is explicitly terminated (using Peer Update message, it contains Termination), or
   o  The session times out, based on supplied timeout values.

   In order to maintain the IPv4 address of session between router and modem, OPTIONAL
   periodic "Heartbeat" messages MAY be exchanged. These messages are
   intended to keep the
   sending peer. In either case, session alive, and to verify bidirectional
   connectivity between the sub-TLV two participants. DLEP also contains provides for an
   indication of whether this is a new or existing address, or is
   OPTIONAL Peer Update message, intended to communicate some change in
   status (e.g., a
   deletion change of a previously known address.

   The IPv4 Address Sub-TLV 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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Type =TBD  |TLV Flags=0x10 |Length = 5     |   Add/Drop    |
  |               |               |               |   Indicator   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    IPv4 Address                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type     - TBD

   TLV Flags    - 0x10, Bit layer 3 (thasvalue) is set, all other bits are not
                  used and MUST be set address parameters, or a modem-wide
   link change).

   In addition to '0'.

   Length       - 5

   Add/Drop     - Value indicating whether this is the messages above, the participants will transmit
   DLEP messages concerning destinations in the network. These messages
   trigger creation/maintenance/deletion of "neighbors" in the
   information base of the recipient. For example, a new or existing
   Indicator      address (0x01), or modem will inform
   its attached router of the presence of a withdrawal new destination via the
   "Neighbor Up" signal. Receipt of a Neighbor Up causes the router to
   allocate the necessary resources, creating an address (0x02).

   IPv4 Address - IPv4 Address entry in the
   information base with the specifics (e.g., MAC Address, Latency, Data
   Rate, etc) of the far-end neighbor neighbor. The loss of a destination is communicated
   via the "Neighbor Down" signal, and changes in status to the
   destination (e.g. varying link quality, or peer.

10.6  IPv6 Address Sub-TLV addressing changes) are
   communicated via the "Neighbor Update" signal. The IPv6 Address Sub-TLV MAY be used information on a
   given neighbor will persist in Neighbor Up, Neighbor
   Update, and Peer Update Messages, if the client router's information base until
   (1) a "Neighbor Down" is aware of received, indicating that the
   Layer 3 address. When included in Neighbor messages, modem has lost
   contact with the IPv6
   Address sub-TLV contains remote node, or (2) the IPv6 address router/modem session
   terminates, indicating that the router has lost contact with its own
   local modem.

   Again, metrics can be expressed within the context of a specific
   neighbor via the far-end neighbor.
   In Neighbor Update message, or on a modem-wide basis
   via the Peer Update, it contains Update message. In cases where metrics are provided on
   the IPv6 address of router/modem session, the
   originating peer. receiver MUST propagate the metrics to
   all neighbors in its information base that are accessed via the
   originator. A DLEP participant MAY send metrics both in a
   router/modem session context (via the Peer Update message) and a
   specific neighbor context (via Neighbor Update) at any time. The
   heuristics for applying received metrics is left to implementations.

   In either case, addition to receiving metrics about the sub-TLV also contains link, DLEP provides an
   indication of whether this is
   OPTIONAL signal allowing a new or existing address, router to request a different amount of
   bandwidth, or latency, from the modem. This signal is a
   deletion referred to as
   the Link Characteristics Message, and gives the router the ability to
   deal with requisite increases (or decreases) of allocated
   bandwidth/latency in demand-based schemes in a previously known address. more deterministic
   manner.

7. Mandatory Signals and Data Items

   The IPv6 Address sub-TLV 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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Type =TBD  |TLV Flags=0x10 |Length = 17    |   Add/Drop    |
  |               |               |               |   Indicator   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        IPv6 Address                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        IPv6 Address                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        IPv6 Address                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        IPv6 Address                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type     - TBD

   TLV Flags    - 0x10, Bit 3 (thasvalue) is set, all other bits DLEP signals are not
                  used and considered core to the specification;
   implementations MUST be set support these signals, and the associated data
   items, in order to '0'.

   Length       - 17

   Add/Drop     - Value indicating whether this is a new or
   Indicator      existing address (0x01), or a withdrawal of
                  an address (0x02).

   IPv6 Address - IPv6 be considered compliant:

         Signal                        Data Items
         ======                        ==========
         Attached Peer Discovery       Identification

         Peer Offer                    Identification

         Peer Offer ACK                Status

         Peer Termination              Identification

         Peer Termination ACK          Status

         Neighbor Up                   Identification
                                       MAC Address of the far-end neighbor or peer.

10.7
                                       Maximum Data Rate Sub-TLV

   The
                                       Current Data Rate
                                       Latency
                                       Resources
                                       Relative Link Quality

         Neighbor Update               Identification
                                       MAC Address
                                       Maximum Data Rate (MDR) Sub-TLV is used in Neighbor Up,
                                       Current Data Rate
                                       Latency
                                       Resources
                                       Relative Link Quality

         Neighbor
   Update, Peer Discovery, Peer Update, Down                 Identification
                                       MAC Address

   All other DLEP signals and Link Characteristics ACK
   Messages to indicate the maximum theoretical data rate, in bits per
   second, that can be achieved on the link. When metrics items are reported
   via OPTIONAL. Implementations
   MAY choose to provide them. Implementations that do not support
   optional signals and data items SHOULD parse, and silently drop, all
   unsupported signals and/or data items.

8. Generic DLEP Packet Definition

   The Generic DLEP Packet consists of a sequence of TLVs. The first TLV
   represents the messages listed above, signal being communicated (e.g., a "Neighbor Up", or a
   "Peer Offer"). Subsequent TLVs contain the maximum data rate MUST be reported.

   The items pertinent to
   the signal (e.g., Maximum Data Rate sub-TLV Rate, or Latency, etc).

   The Generic DLEP Packet Definition 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV
   |Signal TLV Type =TBD  |TLV Flags=0x10 |Length = 8 |  MDR (bps)    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length        |                        MDR (bps) DLEP data items...           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        MDR (bps)              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type

      Signal               -  TBD One of the DLEP Signal TLV Flags type values
                             defined in this document.

      Length               -  0x10, Bit 3 (thasvalue) is set, The length of all other
                            bits of the DLEP data items
                             associated with this signal.

      DLEP data items      - One or more data items, encoded in TLVs,
                             as defined in this document.

9. DLEP Data Items

   As mentioned earlier, DLEP protocol messages are not used and transported as a
   collection of TLVs. The first TLV present in a DLEP message MUST be set to '0'.

   Length                -  8

   Maximum Data Rate     -  A 64-bit unsigned number, representing
   one of the
                            maximum theoretical data rate, Signal TLVs, documented in bits per
                            second (bps), section [INSERT REFERENCE
   HERE]. The signals are followed by one or more data items, indicating
   the specific changes that can need to be achieved on instantiated in the
                            link.

10.8  Current receiver's
   information base.

   Valid DLEP Data Items are:

          TLV      TLV
          Value    Description
          =========================================
          TBD      Identification
          TBD      DLEP Version
          TBD      Peer Type
          TBD      IPv4 Address
          TBD      IPv6 Address
          TBD      Maximum Data Rate Sub-TLV

   The (MDR)
          TBD      Current Data Rate (CDR) Sub-TLV is used in Neighbor Up, Neighbor
   Update, Peer Discovery, Peer Update, Link Characteristics Request,
   and
          TBD      Latency
          TBD      Resources
          TBD      Expected Forwarding Time (EFT)
          TBD      Relative Link Characteristics Quality (RLQ)
          TBD      Status
          TBD      Heartbeat Interval/Threshold
          TBD      Neighbor down ACK messages to indicate the rate at which
   the link is currently operating, or in the case of the timer
          TBD      Link Characteristics Request, the desired ACK timer
          TBD      Credit Window Status
          TBD      Credit Grant
          TBD      Credit Request

   DLEP data rate for the link.

   The Current Data Rate sub-TLV contains item TLVs 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV
   |  TLV Type =TBD  |TLV Flags=0x10 |Length = 8     |CDR (bps)     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length        |                        CDR (bps) Value...                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        CDR (bps)              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type    -  TBD

   TLV Flags             -  0x10, Bit 3 (thasvalue) is set, all other
                            bits are not used and MUST be set to '0'. An 8-bit unsigned integer field specifying the data
                 item being sent.

   Length      -  8

   Current Data Rate     -  A 64-bit unsigned number, representing An 8-bit length of the
                            current rate, in bits per second (bps),
                            on value field of the link. When reporting metrics (e.g,
                            in Neighbor Up, Neighbor Down, Peer
                            Discovery, Peer Update, or Link
                            Characteristics ACK), if there is no
                            distinction between current and maximum
                            data rates, current data rate SHOULD be
                            set equal to the maximum item

   Value       - A field of length <Length> which contains data rate.

10.9  Expected Forwarding Time Sub-TLV

   The Expected Forwarding Time (EFT) Sub-TLV is used in Neighbor Up,
   Neighbor Update, Peer Discovery, and Peer Update messages
                 specific to indicate
   the typical latency between the arrival of a given packet at the
   transmitting device particular data item.

9.1  Identification

   This data item MUST exist in all DLEP messages, and MUST be the reception of the packet at the other end first
   data item of the link. EFT combines transmission time, idle time, waiting time,
   freezing time, and queuing time to message (e.g., it MUST immediately follow the degree that those values are
   meaningful to signal
   TLV). Further, there MUST be ONLY one Identification data item in a given transmission medium.
   DLEP message. The Expected Forwarding Time sub-TLV data item contains identification information used
   to establish the following fields: proper context (e.g., the router/modem session) for
   processing DLEP protocol messages.

   The format of the Identification Data Item is:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV Type =TBD  |TLV Flags=0x10 |Length = 4 TBD  |   EFT (ms) Length = 8     |         Router ID           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        EFT            Router ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         Modem ID            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Modem ID             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type      - Value TBD

   TLV Flags

   Length        -  0x10, Bit 3 (thasvalue) is set, all other
                            bits are not 8

   Router ID     - Indicates the Router ID of the DLEP session.

   Modem ID      - indicates the Modem ID of the DLEP session.

   During transmission of a DLEP Peer Discovery signal, the transmitter
   MUST set its ID to a 32-bit quantity that will be used and to uniquely
   identify this session from the transmitter's perspective. The other
   ID value MUST be set the to '0'.

   Length                -  4

   Current Data Rate     -  A When responding to the Peer
   Discovery signal (via the Peer Offer signal), the transmitter MUST
   echo any received ID value, and MUST supply its own unique 32-bit unsigned number, representing
   quantity to identify the
                            expected forwarding time, in milliseconds, session from its perspective. After the Peer
   Discovery/Peer Offer exchange, subsequent signals on this DLEP
   session MUST contain the link.

10.10  Latency Sub-TLV ID values obtained from the Peer
   Discovery/Peer Offer sequence.

9.2  DLEP Version

   The Latency Sub-TLV DLEP Version TLV is used an OPTIONAL TLV in Neighbor Up, Neighbor Update, Peer
   Discovery, both the Peer Update, Link Characteristics Request, Discovery
   and Link
   Characteristics ACK messages Peer Offer messages. The Version TLV is used to indicate the amount
   version of latency on the link, or protocol running in the case of the Link Characteristics Request, originator. A participant MAY
   use this information to
   indicate decide if the maximum latency required (e.g. potential session partner is
   running at a should-not-exeed value)
   on the link. supported level.

   The Latency Sub-TLV DLEP Version TLV 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV Type =TBD  |TLV Flags=0x10 |Length = 2     |Latency (ms)  |Length=4       |         Major Version         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Latency (ms)
   |
  +-+-+-+-+-+-+-+-+       Minor Version           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type      - TBD

   TLV Flags             -  0x10, Bit 3 (thasvalue) is set, all other
                            bits are not used and MUST be set to '0'.
   Length        -  2

   Latency               -  The transmission delay that a packet
                            encounters as it is transmitted over the
                            link. In Neighbor Up, Neighbor Update,
                            and Link Characteristics ACK, this value Length is reported in absolute delay, in
                            milliseconds. The calculation 4

   Major Version - Major version of latency
                            is implementation dependent. For example,
                            the latency may be a running average
                            calculated from the internal queuing. If
                            a device cannot calculate latency, it
                            SHOULD be reported as 0. In modem or router protocol.

   Minor Version - Minor version of the Link
                            Characteristics Request Message, modem or router protocol.

   Support of this value
                            represents draft is indicated by setting the maximum delay, in
                            milliseconds, expected on Major Version
   to '1', and the link.

10.11  Resources Sub-TLV Minor Version to '3' (e.g. Version 1.3).

9.3  Peer Type

   The Resources Sub-TLV Peer Type TLV is used an OPTIONAL TLV in Neighbor Up, Neighbor Update, both the Peer
   Discovery, Discovery and
   Peer Update, Offer messages. The Peer Type TLV is used by the router and Link Characteristics ACK messages
   modem to
   indicate give additional information as to its type. The peer type is
   a percentage (0-100) amount of resources string and is envisioned to be used for informational purposes
   (e.g. battery
   power) remaining on the originating peer. as output in a display command).

   The Resources Peer Type TLV 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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Type =TBD  |TLV Flags=0x10 |Length = 1  |Length= peer   |Peer Type String               |   Resources
  |               |type string len|Max Len = 80                   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type         - TBD

   TLV Flags             -  0x10, Bit 3 (thasvalue) is set, all other
                            bits are not used and MUST be set to '0'.

   Length           -  1
   Resources Length of peer type string (80 octets maximum).

   Peer Type String -  A percentage, 0-100, representing the
                            amount Non-Null terminated string, maximum length of remaining resources, such as
                            battery power. If resources cannot be
                            calculated, 80
                      octets. For example, a value of 100 SHOULD be
                            reported.

10.12  Relative Link Quality Sub-TLV satellite modem might set
                      this variable to 'Satellite terminal'.

9.4  MAC Address

   The Relative Link Quality (RLQ) Sub-TLV is used MAC address TLV MUST appear in all neighbor-oriented signals
   (e.g. Neighbor Up, Neighbor Up ACK, Neighbor Down, Neighbor Down ACK,
   Neighbor Update, Peer Discovery, Peer Update, Link Characteristics Request, and Link
   Characteristics ACK messages to indicate ACK). The MAC Address TLV contains the quality address of the link
   as calculated by
   destination on the originating peer. remote node. The Relative Link Quality sub-TLV contains MAC address MAY be either a
   physical or a virtual destination. Examples of a virtual destination
   would be a multicast MAC address, or the following fields: broadcast MAC
   (0xFFFFFFFFFFFF).

    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

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV Type =TBD  |TLV Flags=0x10  |Length = 1     |Relative Link  | 6     |          MAC Address          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |Quality (RLQ)                      MAC Address                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type    - TBD

   Length      - 6

   MAC Address - MAC Address of the destination (either physical or
                 virtual).

9.5  IPv4 Address

   The IPv4 Address TLV Flags             -  0x10, Bit 3 (thasvalue) is set, all other
                            bits are not used an OPTIONAL TLV. If supported, it MAY appear
   in Neighbor Up, Neighbor Update, and MUST be set to '0'.

   Length                -  1

   Relative Link Quality -  A non-dimensional number, 0-100,
                            representing relative link quality. A value Peer Update messages. When
   included in Neighbor messages, the IPv4 Address TLV contains the IPv4
   address of 100 represents the neighbor, as well as a link of subnet mask value. In the highest
                            quality. If Peer
   Update message, it contains the RLQ cannot be calculated, a
                            value IPv4 address of 100 SHOULD be reported.

10.13  Status Sub-TLV

   The Status Sub-TLV is sent from the originator of the
   message. In either case, the client TLV also contains an indication of
   whether this is a new or server to
   indicate the success existing address, or failure is a deletion of a given request
   previously known address.

   The Status Sub-TLV IPv4 Address TLV 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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Type =TBD  |TLV Flags=0x10  |Length = 1 6     |   Add/Drop    | IPv4 Address  |
  |     Code               |               |   Indicator   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            IPv4 Address                       |  Subnet Mask  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type     - TBD

   TLV Flags        - 0x10, Bit 3 (thasvalue) is set, all other bits
                      are not used and MUST be set to '0'.

   Length       - 1

   Termination Code 6

   Add/Drop     - 0 = Success
                      Non-zero = Failure. Specific values of Value indicating whether this is a non-
                      zero termination code depend on the operation
                      requested (e.g. Neighbor Up, Neighbor Down, etc).

10.14  Heartbeat Interval Sub-TLV new or existing
                  IPv4 address

   IPv4 Address - The Heartbeat Interval Sub-TLV MAY be sent from IPv4 address of the client during
   Peer Discovery neighbor or peer.

   Subnet Mask  - A subnet mask (0-32) to be applied to indicate the desired Heartbeat timeout window. IPv4
                  address.

9.6  IPv6 Address

   The IPv6 Address TLV is an OPTIONAL TLV. If included supported, it MAY be used
   in the Neighbor Up, Neighbor Update, Peer Discovery, and Peer Update
   Messages. When included in Neighbor messages, this data item contains
   the server MUST either accept the
   timeout interval, or reject IPv6 address of the Peer Discovery. Failing to include neighbor. In the Heartbeat Interval Sub-TLV in Peer Discovery indicates a
   desire to establish and Peer
   Update, it contains the peer-to-peer DLEP session without an
   activity timeout (e.g. IPv6 address of the originating peer. In
   either case, the data item also contains an infinite timeout value). indication of whether
   this is a new or existing address, or is a deletion of a previously
   known address, as well as a subnet mask.

   The Heartbeat Interval Sub-TLV IPv6 Address TLV 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV Type =TBD  |TLV Flags=0x10  |Length = 1 18    | Interval   Add/Drop    | IPv6 Address  |
   |               |               |   Indicator   |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        IPv6 Address                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        IPv6 Address                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        IPv6 Address                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                IPv6 Address                   | Subnet Mask   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type     - TBD

   TLV Flags        - 0x10, Bit 3 (thasvalue) is set, all other bits are
                      not used and MUST be set to '0'.

   Length       - 1

   Interval 18

   Add/Drop     - 0 = Do NOT use heartbeats on Value indicating whether this peer-to-peer
                      session. Non-zero = Interval, in seconds, for
                      heartbeat messages.

10.15  Heartbeat Threshold Sub-TLV

   The Heartbeat Threshold Sub-TLV MAY be sent from the client during
   Peer Discovery to indicate the desired number of windows, is a new or existing
                  address (0x01), or a withdrawal of time
   (Heartbeat Interval) seconds, to wait before either peer declares
   the peer session lost. In this case, the overall amount an address (0x02).

   IPv6 Address - IPv6 Address of time
   before a peer session is declared lost is expressed as
   (Interval * Threshold), where 'Interval' is the neighbor or peer.

   Subnet Mask  - A subnet mask value in the
   Heartbeat Interval sub-TLV, documented above. If this sub-TLV is
   included by (0-128) to be applied to the client Ipv6
                  address.

9.7  Maximum Data Rate

   The Maximum Data Rate (MDR) TLV is used in the Neighbor Up, Neighbor
   Update, Peer Discovery, the client MUST also
   specify the Heartbeat Interval sub-TLV with a non-zero interval. If
   this sub-TLV is received during Peer Discovery, the server MUST
   either accept Update, and Link Characteristics ACK
   Messages to indicate the threshold, or reject maximum theoretical data rate, in bits per
   second, that can be achieved on the Peer Discovery. If link. When metrics are reported
   via the
   Heartbeat Interval Sub-TLV is included, but this Sub-TLV is
   omitted, then a threshold of '1' is assumed.

   The Heartbeat Threshold Sub-TLV contains messages listed above, the following fields: maximum data rate MUST be
   reported.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV Type =TBD  |TLV Flags=0x10  |Length = 1 8     | Threshold          MDR (bps)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        MDR (bps)                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           MDR (bps)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type          -  TBD

   TLV Flags        - 0x10, Bit 3 (thasvalue) is set, all other bits are
                      not used and MUST be set to '0'.

   Length            - 1

   Threshold  8

   Maximum Data Rate - 0 = Do NOT use heartbeats on this peer-to-peer
                      session. Non-zero = Number of windows, of
                      Heartbeat Interval seconds, to wait before
                      declaring a peer-to-peer session to  A 64-bit unsigned number, representing the
                        maximum theoretical data rate, in bits per
                        second (bps), that can be lost.

10.16 achieved on the link.

9.8  Current Data Rate

   The Current Data Rate (CDR) TLV is used in Neighbor Up, Neighbor
   Update, Peer Discovery, Peer Update, Link Characteristics ACK Timer Sub-TLV

   The Request,
   and Link Characteristic Characteristics ACK Timer Sub-TLV MAY be sent from the
   client during Peer Discovery messages to indicate the desired number of
   seconds the server should wait for a response to a Link
   Characteristics Request. If this sub-TLV is received during Peer
   Discovery, the server MUST either accept the timeout value, or
   reject rate at which
   the Peer Discovery. If this Sub-TLV link is omitted,
   implementations SHOULD choose a default value.

   The currently operating, or in the case of the Link
   Characteristics ACK Timer Sub-TLV Request, the desired data rate for the link. When
   metrics are reported via the messages above, the current data rate
   MUST be reported.

   The Current Data Rate TLV 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV Type =TBD  |TLV Flags=0x10 |Length = 1 8     |CDR (bps)      | Interval
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        CDR (bps)                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        CDR (bps)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type          -  TBD

   TLV Flags        - 0x10, Bit 3 (thasvalue) is set, all other bits are
                      not used and MUST be set to '0'.

   Length            - 1

   Interval  8

   Current Data Rate - 0 = Do NOT use timeouts for Link Characteristics
                      requests  A 64-bit unsigned number, representing the
                        current data rate, in bits per second, that is
                        currently be achieved on this peer-to-peer session.
                      Non-zero = Interval, the link, or the
                        desired data rate in seconds, to wait before
                      considering a bits per second in the Link
                        Characteristics Request has
                      been lost.

10.17  Credit Window Status Sub-TLV

   The Credit Window Status Sub-TLV MUST be sent by the DLEP peer
   originating a Neighbor Up message when use of credits message. If there is desired
   for a given session. In the Neighbor Up message, when credits
   are desired, the originating peer no
                        distinction between current and maximum data
                        rates, current data rate MUST be set the value of the
   window it controls (e.g. the Client Receive Window, or Server
   Receive Window) equal to an initial, non-zero value.
                        the maximum data rate.

9.9  Expected Forwarding Time

   The peer receiving
   a Expected Forwarding Time (EFT) TLV is is an OPTIONAL data item.
   If supported, it MAY be used in Neighbor Up message with a Credit Window Status Sub-TLV MUST
   either reject Up, Neighbor Update, Peer
   Discovery, and Peer Update messages to indicate the use typical latency
   between the arrival of credits, via a Neighbor Up ACK response
   with the correct Status Sub-TLV, or set given packet at the initial value from transmitting device and
   the data contained in reception of the Credit Window Status Sub-TLV. If packet at the
   initialization completes successfully, other end of the receiving peer MUST
   respond link. EFT
   combines transmission time, idle time, waiting time, freezing time,
   and queuing time to the Neighbor Up message with a Neighbor Up ACK message degree that contains those values are meaningful to a Credit Window Status Sub-TLV, initializing its
   receive window.
   given transmission medium.

   The Credit Window Status Sub-TLV Expected Forwarding Time TLV 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV Type =TBD  |TLV Flags=0x10  |Length = 16    | Client Receive|
  |               |               |               | Window value  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                Client Receive Window Value                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        Client Receive Window Value            | Server Receive|
  |                                               | Window Value  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4     |                Server Receive Window Value           EFT (ms)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Server Receive Window Value            EFT (ms)           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type    -  TBD

   TLV Flags        - 0x10, Bit 3 (thasvalue) is set, all other bits
                      are not used and MUST be set to '0'.

   Length      - 16

   Client Receive   - A 64-bit unsigned number, indicating the
   Window value       current (or initial) number of credits
                      available on the Client Receive Window.

   Server Receive  4

   EFT         -  A 64-bit 32-bit unsigned number, indicating representing the
   Window Value       current (or initial) number of credits
                      available expected
                  forwarding time, in milliseconds, on the Server Receive Window.

10.18  Credit Grant Sub-TLV

   The Credit Grant Request Sub-TLV MAY be sent from either DLEP
   peer to grant an increment to credits on a window. link.

9.10  Latency

   The Credit
   Grant Sub-TLV Latency TLV is sent as part of a Neighbor Update message. The
   value used in a Credit Grant Sub-TLV represents an increment to be
   added Neighbor Up, Neighbor Update, Peer
   Discovery, Peer Update, Link Characteristics Request, and Link
   Characteristics ACK messages to any existing credits available indicate the amount of latency on the window. Upon
   successful receipt and processing
   link, or in the case of a Credit Grant Sub-TLV, the
   receiving peer SHOULD respond with a DLEP Neighbor Update message
   containing a Credit Window Status Sub-TLV Link Characteristics Request, to report indicate
   the updated
   aggregate values for synchronization purposes.

   The Credit Grant Sub-TLV contains maximum latency required on the following fields: link. When metrics are reported
   via the messages above, Latency MUST be reported.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV Type =TBD  |TLV Flags=0x10  |Length = 8     | Credit        |
  |               |               |               | Increment     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2     |                      Credit Increment        Latency (ms)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Credit Increment                   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type    -  TBD

   TLV Flags        - 0x10, Bit 3 (thasvalue) is set, all other bits
                      are not used and MUST be set to '0'.

   Length      - 0

   Reserved  2

   Latency     -  A 64-bit 16-bit unsigned number value, representing the
                      additional credits to be assigned to the
                      credit window. Since credits can only be
                      granted by the receiver on transmission
                  delay that a window, the
                      applicable credit window (either the CRW or
                      the SRW) packet encounters as it is derived from the sender of the
                      grant. The Credit Increment MUST NOT cause transmitted
                  over the window to overflow; if link. In Neighbor Up, Neighbor Update, and
                  Link Characteristics ACK, this condition
                      occurs, implementations MUST set the credit
                      window to the maximum value contained is reported as
                  delay, in a
                      64-bit quantity.

10.19  Credit Request Sub-TLV milliseconds. The Credit Request Sub-TLV MAY be sent from either DLEP peer, via
   a Neighbor Update order, to indicate the desire for calculation of latency is
                  implementation dependent. For example, the partner to
   grant additional credits in order for data transfer to proceed on latency may
                  be a running average calculated from the session. internal
                  queuing. If the corresponding Neighbor Up message for this
   session did NOT contain a Credit Window Status Sub-TLV, indicating
   that credits are to device cannot calculate latency, it MUST
                  be used on the session, then reported as 0. In the Credit Link Characteristics Request
   Sub-TLV MUST be rejected, by sending a Neighbor Update ACK containing
   a Status Sub-TLV, by
                  Message, this value represents the receiving peer. If credits are maximum delay, in use
                  milliseconds, expected on the session, then the receiving peer MAY respond with a DLEP link.

9.11  Resources

   The Resources TLV is used in Neighbor Update message containing Up, Neighbor Update, Peer
   Discovery, Peer Update, and Link Characteristics ACK messages to
   indicate a Credit Grant Sub-TLV with
   an increment percentage (0-100) amount of credits for resources (e.g. battery
   power) remaining on the session. originating peer. If metrics are reported,
   via the above messages, Resources MUST be reported.

   The Credit Request Sub-TLV Resources TLV contains the following fields:

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV Type =TBD  |Length = 1     |   Resources   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type    -  TBD

   Length      -  1

   Resources   -  A percentage, 0-100, representing the amount of
                  remaining resources, such as battery power. If
                  resources cannot be calculated, a value of 100 MUST be
                  reported.

9.12  Relative Link Quality

   The Relative Link Quality (RLQ) TLV is used in Neighbor Up, Neighbor
   Update, Peer Discovery, Peer Update, and Link Characteristics ACK
   messages to indicate the quality of the link as calculated by the
   originating peer. If metrics are reported via the above messages, RLQ
   MUST be reported.

   The Relative Link Quality TLV contains the following fields:

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV Type =TBD  |TLV Flags=0x10  |Length = 0     | Reserved, MUST|
  | 1     |Relative Link  |
   |               | be set to 0               |Quality (RLQ)  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type              -  TBD

   TLV Flags        - 0x10, Bit 3 (thasvalue) is set, all other bits
                      are not used and MUST be set to '0'.

   Length                - 0

   Reserved  1

   Relative Link Quality - 0 = This field is currently unused and  A non-dimensional number, 0-100,
                          representing relative link quality. A value of
                          100 represents a link of the highest quality.
                          If the RLQ cannot be calculated, a value of
                          100 MUST be
                          set to 0.

11. DLEP Protocol Messages

   DLEP places no additional requirements on reported.

9.13  Status

   The Status TLV is an OPTIONAL TLV. It is sent as part of an
   acknowledgement message, from either the RFC 5444 Packet
   formats, modem or the packet header. DLEP does require that the optional
   'msg-seq-num' in router, to
   indicate the message header exist, and defines a set success or failure of
   values for the 'tlv-type' field in the RFC 5444 TLV block. Therefore, a DLEP message, starting from given request.

   The Status TLV contains the RFC 5444 Message header, would
   appear as follows: 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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Msg
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV Type =TBD  |Length =   |Msg Flg|AddrLen|          Message Size         |
  | DLEP_MESSAGE  | 0x1   | 0x0   |                               |
  | (value TBD)   |       |       |                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      | TLV block length (length of   |
  |                               | DLEP order + Sub-TLVs)        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | DLEP Message  |TLV Flags=0x10 | Length        | Start of DLEP |
  | Block value   |               |               | Sub-TLVs...   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

11.1  Message Block TLV Values

   As mentioned above, all DLEP messages utilize a single RFC 5444
   message type, the DLEP_MESSAGE (TBD). DLEP further identifies
   protocol messages by using the 'tlv-type' field in the RFC 5444
   message 1     |     Code      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV block. DLEP defines the following Message-Type-
   specific Type         - TBD

   Length           - 1

   Termination Code - 0 = Success, Non-zero = Failure. Specific values for
                          of a non-zero termination code depend on the tlv-type field:

          TLV
                          operation requested (e.g. Neighbor Up,
                          Neighbor Down, etc).

9.14  Heartbeat Interval/Threshold

   The Heartbeat Interval/Threshold TLV
          Value    Description
          =========================================
          TBD      Attached Peer Discovery
          TBD      Detached is an OPTIONAL TLV. If
   supported, it MAY be sent during Peer Discovery
          TBD      Peer Offer
          TBD      Peer Update
          TBD      Peer Update ACK
          TBD      Peer Termination
          TBD      Peer Termination ACK
          TBD      Neighbor Up
          TBD      Neighbor Up ACK
          TBD      Neighbor Down
          TBD      Neighbor Down ACK
          TBD      Neighbor Update
          TBD      Neighbor Address Update
          TBD      Neighbor Address Update ACK
          TBD to indicate the
   desired Heartbeat
          TBD      Link Characteristics Request
          TBD      Link Characteristics ACK

   In all of timeout window. If the diagrams following, modem includes the message layouts begin with Heartbeat
   Interval TLV in Peer Discovery, the router MUST either accept the
   timeout interval supplied by the modem, or reject the
   RFC 5444 message header.

12. Peer Discovery Messages

   There are two different types of Discovery.
   Peer Discovery Messages, Attached
   and Detached.  Attached messages that do not include the Heartbeat Interval
   TLV in Peer Discovery indicates a desire to establish the
   router/modem session without an activity timeout (e.g. an infinite
   timeout value). If an activity timeout is supported, implementations
   MAY choose to implement heuristics such that signals sent/received
   reset the timer window.

   The Interval is used to specify a period (in seconds) for Heartbeat
   Messages are sent by (See Section 23). The Threshold value is used to indicate
   the
   client when it desired number of windows, each of time (Heartbeat Interval)
   seconds, to wait before either participant declares the router/modem
   session lost. In this case, the overall amount of time before a
   router/modem is directly attached to declared lost is expressed as (Interval * Threshold).
   Specifying an Interval value of 0 indicates the server (e.g. desire to disable
   Heartbeat messages entirely (e.g., the client
   exists as a card in Interval is set to an infinite
   value). Setting the chassis, or it Threshold value to 0 is connected via Ethernet undefined, and TLVs with
   no intervening devices).
   a Threshold value of 0 MUST be rejected by the recipient.

   The Detached Peer Discovery message, on Heartbeat Interval/Threshold TLV contains the
   other hand, is sent by a "remote" client -- for example, a client at
   a satellite hub system might 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV Type =TBD  |Length = 1     | Interval      |  Threshold    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type         - TBD

   Length           - 1

   Interval         - 0 = Do NOT use a Detached Discovery Message heartbeats on this peer-to-peer
                      session. Non-zero = Interval, in
   order to act as a proxy seconds, for remote ground terminals. To explain in
   another way, a detached client uses the variable link itself (the
   radio or satellite link)
                      heartbeat messages.

   Threshold        - Number of windows, of Heartbeat Interval seconds,
                      to establish wait before declaring a DLEP peer-to-peer session with a remote
   server.

12.1  Attached Peer Discovery Message

   The Attached Peer Discovery Message is sent by an attached client to a server to begin a new DLEP association.
                      be lost.

9.15  Link Characteristics ACK Timer

   The Peer Offer message Link Characteristics ACK Timer TLV is required to complete the discovery process. The client MAY
   implement its own retry heuristics in the event an OPTIONAL TLV. If
   supported, it (the client)
   determines the Attached Peer Discovery Message has timed out. An
   Attached MAY be sent during Peer Discovery Message received from to indicate the
   desired number of seconds to wait for a peer that is already
   in session MUST be processed as if response to a Link
   Characteristics Request. If a router receives this TLV from a modem
   during Peer Termination Message had
   been received. An implementation MAY then process Discovery, the received
   Attached Peer Discovery Message.

   Note that metric Sub-TLVs MAY be supplied with router MUST either accept the timeout
   value, or reject the Peer Discovery
   order. Discovery. If metric Sub-TLVs are supplied, they MUST be used as this TLV is omitted,
   implementations supporting the Link Characteristics Request SHOULD
   choose a default value for all neighbor sessions established via this peer. value.

   The Attached Peer Discovery Message Link Characteristics ACK Timer TLV 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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Msg
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV Type =TBD  |Length =   |Msg Flg|AddrLen|          Message Size         |
  | DLEP_MESSAGE  | 0x1   | 0x0   |        22 + size of opt       |
  | (value TBD)   |       |       |            sub-TLV            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      |TLVs Length =14 + opt sub-TLVs |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | DLEP Attached |TLV Flags=0x10 | Length =11 +  | Sub-TLVs      |
  | Peer Discovery|               | opt sub-TLVs  | as noted below|
  | (Value TDB)   |               | 1     | Interval      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type     - DLEP_MESSAGE (value TBD)

   Message Flags                   - Set to 0x1 (bit 3, mhasseqnum
                                     bit is set).  No other bits are
                                     used and MUST be set to '0'.

   Message Address TBD

   Length       - 0x0

   Message Size                    - 22 + size of optional sub-TLVs

   Message Sequence Number         - A 16-bit unsigned integer field
                                     containing a sequence number
                                     generated by the message
                                     originator.

   TLV Block                       - TLVs Length: 14 + size of optional
                                                  sub-TLVs.

   Sub-TLVs:
                                     Identification (MANDATORY)
                                     Version (OPTIONAL)
                                     Peer Type (OPTIONAL)
                                     Heartbeat 1

   Interval (OPTIONAL)
                                     Heartbeat Threshold (OPTIONAL)
                                     Link Characteristics ACK Timer
                                                 (OPTIONAL)
                                     Maximum Data Rate (OPTIONAL)
                                     Current Data Rate (OPTIONAL)
                                     Latency (OPTIONAL)
                                     Expected Forwarding Time (OPTIONAL)
                                     Resources (OPTIONAL)
                                     Relative     - 0 = Do NOT use timeouts for Link Quality (OPTIONAL)

12.2  Detached Peer Discovery Message

   The Detached Peer Discovery Message is sent by a detached client
   proxy to a server to begin a new DLEP Characteristics
                  requests on this router/modem session. The Peer Offer
   message is required to complete the discovery process. The client
   MAY implement its own retry heuristics Non-zero =
                  Interval, in the event it (the client)
   determines the Detached Peer Discovery Message has timed out. When
   a DLEP implementation responds seconds, to wait before considering a Detached Discovery Message with
   a Peer Offer, the implementation MUST enter
                  Link Characteristics Request has been lost.

9.16  Credit Window Status

   The Credit Window Status TLV is an "in session" state
   with the peer. Any subsequent discovery message received from OPTIONAL TLV. If credits are
   supported by the
   peer MUST be processed as if a Peer Termination Message had been
   received (e.g. DLEP participants (both the existing peer session MUST be terminated). An
   implementation MAY then process router and the received discovery message.

   If metric sub-TLVs (e.g. Maximum Data Rate) are supplied with modem),
   the
   Detached Peer Discovery message, these metrics Credit Window Status TLV MUST be used as sent by the
   initial values participant
   receiving a Credit Grant Request for all far-end sessions (neighbors) established via
   the peer. a given neighbor.

   The Detached Peer Discovery Message Credit Window Status TLV 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Msg
   |TLV Type =TBD  |Length =   |Msg Flg|AddrLen|          Message Size         |
  | DLEP_MESSAGE  | 0x1   | 0x0   |        22 + size of opt       |
  | (value TBD)   |       | 16    |            sub-TLV Modem Receive Window Value    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Message Seq Num      |TLVs Length =14 + opt sub-TLVs                   Modem Receive Window Value                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | DLEP Detached |TLV Flags=0x10 | Length = 11 + | Sub-TLVs as   |
  | Peer Discovery|               | opt sub-TLVs  | noted below  Modem Receive Window Value   | Router Receive Window Value   | (Value TDB)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Router Receive Window Value                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Router Receive Window Value  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Type                  - DLEP_MESSAGE (value TBD)

   Message Flags
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type                    - Set to 0x1 (bit 3,
                                   mhasseqnum bit is set).
                                   All other bits are not used
                                   and MUST be set to '0'.

   Message Address TBD

   Length                      - 0x0

   Message Size 16

   Modem Receive Window Value  - 22 + size A 64-bit unsigned number, indicating
                                 the current (or initial) number of optional
                                   sub-TLVs

   Message Sequence Number
                                 credits available on the Modem Receive
                                 Window.

   Router Receive Window Value - A 16-bit 64-bit unsigned integer
                                   field containing a sequence number, generated by indicating
                                 the
                                   message originator.

   TLV Block                     - TLVs Length: 14 + size current (or initial) number of
                                    optional sub-TLVs.

   Sub-TLVs
                                   Identification (MANDATORY)
                                   Version (OPTIONAL)
                                   Peer Type (OPTIONAL)
                                   Heartbeat Interval (OPTIONAL)
                                   Heartbeat Threshold (OPTIONAL)
                                   Link Char. ACK Timer (OPTIONAL)
                                   Maximum Data Rate (OPTIONAL)
                                   Current Data Rate (OPTIONAL)
                                   Latency (OPTIONAL)
                                   Expected Forwarding Time (OPTIONAL)
                                   Resources (OPTIONAL)
                                   Relative Link Quality (OPTIONAL)

   As in the Attached Peer Discovery,
                                 credits available on the client MAY include metric
   sub-TLVs. Router Receive
                                 Window.

9.17  Credit Grant Request

   The Credit Grant Request TLV is an OPTIONAL TLV. If included, credits are
   supported, the router SHOULD use these values as defaults
   that will apply Credit Grant Request TLV is sent from a DLEP
   participant to all sessions established via this client.

13. Peer Offer Message grant an increment to credits on a window. The Peer Offer Message Credit
   Grant TLV is sent by as a data item in either the Neighbor Up or
   Neighbor Update messages. The value in a Credit Grant TLV represents
   an increment to be added to any existing credits available on the
   window. Upon successful receipt and processing of a Credit Grant TLV,
   the receiver MUST respond with a message containing a server Credit Window
   Status TLV to report the updated aggregate values for synchronization
   purposes.

   In the Neighbor Up message, when credits are desired, the originating
   peer MUST set the initial credit value of the window it controls
   (e.g. the Modem Receive Window, or Router Receive Window) to an
   initial, non-zero value. If the receiver of a client in response
   to Neighbor Up message
   with a Peer Discovery Message. The Peer Offer Message is Credit Grant Request TLV supports credits, the response
   to receiver MUST
   either reject the use of credits, via a Neighbor Up ACK response with
   the Peer Discovery messages (Attached correct Status TLV, or Detached),
   and completes set the DLEP peer session establishment. Upon sending initial value from the
   Peer Offer Message, data
   contained in the server then enters an "in session" state
   with Credit Window Status TLV. If the client. From initialization
   completes successfully, the client perspective, receipt and successful
   parsing of a Peer Offer order receiver MUST cause the client respond to enter the "in
   session" state. Any subsequent Discovery messages sent or received
   on this session MUST be considered an error, and the session MUST be
   terminated as if Neighbor Up
   message with a Peer Termination Message had been received. Neighbor Up ACK message that contains a Credit Window
   Status TLV, initializing its receive window.

   The Peer Offer Message Credit Grant TLV 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Msg
   |TLV Type =TBD  |Length =   |Msg Flg|AddrLen|          Message Size         |
  | DLEP_MESSAGE  | 0x1   | 0x0   |        22 + size of opt       |
  | (value TBD)   |       | 8     |            sub-TLV       Credit Increment        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Message Seq Num      |TLVs Length =14 + opt sub-TLVs                      Credit Increment                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |DLEP Peer Offer|TLV Flags=0x10 | Length = 11 + | Sub-TLVs as   |
  | (Value TBD)   |               | opt sub-TLVs
   | indicated     |
  |               |               |               | below      Credit Increment         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type         - DLEP_MESSAGE (Value TBD)

   Message Flags           - Set to 0x1 (bit 3, mhasseqnum bit
                             is set). All other bits are unused and
                             MUST be set to '0'.

   Message Address TBD

   Length           - 0x0

   Message Size            - 22 + size of optional sub-TLVs

   Message Sequence Number 8

   Reserved         - A 16-bit 64-bit unsigned integer field containing
                             a sequence number, generated by number representing the
                      additional credits to be assigned to the message
                             originator.

   TLV Block               - TLV Length: 14 + size of optional sub-TLVs

   Sub TLVs
                             Identification (MANDATORY)
                             Version (OPTIONAL)
                             Peer Type (OPTIONAL)
                             IPv4 Address (OPTIONAL)
                             IPv6 Address (OPTIONAL)
                             Status (OPTIONAL)
                             Heartbeat Interval (OPTIONAL)
                             Heartbeat Threshold (OPTIONAL)
                             Link Characteristics ACK Timer (OPTIONAL)

14. Peer Update Message

   The Peer Update message is sent credit
                      window. Since credits can only be granted by a DLEP peer to indicate local
   Layer 3 address changes, or for metric changes the
                      receiver on a device-wide
   basis. For example, addition window, the applicable credit window
                      (either the MRW or the RRW) is derived from the
                      sender of an IPv4 address the grant. The Credit Increment MUST NOT
                      cause the window to overflow; if this condition
                      occurs, implementations MUST set the server would
   prompt a Peer Update message credit window
                      to its attached DLEP clients. Also, the maximum value contained in a
   client that changes its Maximum Data Rate for all destinations 64-bit
                      quantity.

9.18  Credit Request

   The Credit Request TLV is an OPTIONAL TLV. If credits are supported,
   the Credit Request TLV MAY
   reflect that change be sent from either DLEP participant, via
   a Peer Neighbor Update Message signal, to its attached server.

   With Layer 3 address changes, if indicate the client is capable of
   understanding and forwarding this information, desire for the address update
   would prompt any remote DLEP clients (DLEP clients that are partner to
   grant additional credits in order for data transfer to proceed on the
   far-end of
   session. If the variable link) to issue a "Neighbor Update" corresponding Neighbor Up message to
   their local servers with the new (or deleted) addresses. Clients for this session
   did NOT contain a Credit Window Status TLV, indicating that
   do not track Layer 3 addresses MUST silently parse and ignore credits
   are to be used on the Peer
   Update Message. Clients that track Layer 3 addresses session, then the Credit Request TLV MUST acknowledge be
   rejected by the Peer Update with receiver via a Peer Neighbor Update ACK message. Servers receiving a
   Peer Update with metric changes MUST apply

   The Credit Request TLV contains the new metric following fields:

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV Type =TBD  |Length = 0     | Reserved, MUST|
   |               |               | be set to all
   neighbor sessions established via the client. Peers MAY employ
   heuristics 0   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type     - TBD

   Length       - 0

   Reserved     - This field is currently unused and MUST be set to retransmit Peer Update messages. The sending of Peer
   Update 0.

10. DLEP Protocol Messages for Layer 3 address changes SHOULD cease when

   DLEP messages are encoded as a server
   implementation determines that string of Type-Length-Value (TLV)
   constructs. The first TLV in a client does NOT support Layer 3
   address tracking.

   If metric Sub-TLVs are supplied with the Peer Update DLEP message (e.g.
   Maximum Data Rate), these metrics MUST be applied to all neighbor
   sessions accessible via the peer. a valid DLEP
   signal, as defined in section 11.1 of this document. The Peer Update Message contains second TLV
   MUST be the following fields: Identification data item, defined in section 10.1
   Following those two TLVs are 0 or more TLVs, representing the data
   items that are appropriate for the signal. The layout of a DLEP
   message is thus:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Msg Type =   |Msg Flg|AddrLen|          Message Size         |
  | DLEP_MESSAGE  | 0x1   | 0x0   |        22 + size of opt       |
  | (value TBD)   |       |       |            sub-TLVs           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      |TLVs Length =14 + opt sub-TLVs |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | DLEP Peer     |TLV Flags=0x10 Signal   |DLEP Message   |Identification |Identification | Length = 11 +
   | Sub-TLVs as Type value    |length (9 +    |TLV Type       |TLV length     |
   | Update (value TBD)   |optional TLVs) |(TBD)          |(8)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | opt sub-TLVs                            Router ID                          | noted below
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Modem ID                           | (Value TDB)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Start of optional DLEP        |
   | TLVs...                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Message Type             - DLEP_MESSAGE (Value TBD)

   Message Flags            - Set to 0x1 (bit 3, mhasseqnum bit
                              is set).
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   All other bits are unused DLEP messages (signals) begin with this structure. Therefore, in
   the following descriptions of specific messages, this header
   structure is assumed, and
                              MUST will not be set to '0'.

   Message Address Length   - 0x0

   Message Size             - 22 + optional Sub-TLVs

   Message Sequence Number  - A 16-bit unsigned integer containing a
                              sequence number (generated by originator).

   TLV Block                - replicated.

10.1  Signal TLV Length:  14 + length Values

   As mentioned above, all DLEP messages begin with the Type value of optional
                                           sub-TLVs.
   Sub TLVs
                              Identification (MANDATORY)
                              IPv4 Address (OPTIONAL)
                              IPv6 Address (OPTIONAL)
                              Maximum Data Rate (OPTIONAL)
                              Current Data Rate (OPTIONAL)
                              Latency (OPTIONAL)
                              Expected Forwarding Time (OPTIONAL)
                              Resources (OPTIONAL)
                              Relative Link Quality (OPTIONAL)

15.
   the appropriate DLEP signal. Valid DLEP signals are:

          TLV      TLV
          Value    Description
          =========================================
          TBD      Peer Discovery
          TBD      Peer Offer
          TBD      Peer Offer ACK
          TBD      Peer Update
          TBD      Peer Update ACK
          TBD      Peer Termination
          TBD      Peer Termination ACK
          TBD      Neighbor Up
          TBD      Neighbor Up ACK
          TBD      Neighbor Down
          TBD      Neighbor Down ACK
          TBD      Neighbor Update
          TBD      Heartbeat
          TBD      Link Characteristics Request
          TBD      Link Characteristics ACK

11. Peer Discovery Message

   The Peer Discovery Message is sent to begin a new DLEP association.
   The Peer Offer message is required to complete the discovery process.
   Implementations MAY implement their own retry heuristics in cases
   where it is determined the Peer Discovery Message has timed out. A peer sends
   Peer Discovery Message received from a participant that is already in
   session MUST be processed as if a Peer Termination Message had been
   received. An implementation MAY then process the received Peer
   Discovery Message.

   Note that metric data items MAY be supplied with the Peer Update ACK Message Discovery,
   in order to populate default metric values, or to indicate whether a static,
   modem-wide environment. If metrics are supplied with the Peer Update Message was successfully processed.

   The Peer Update ACK message contains
   Discovery message, these metrics MUST be used as 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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Msg initial values
   for all neighbors established via the modem.

   Given the packet format described in section 11, the initial TLV Type =   |Msg Flg|AddrLen|          Message Size         |
  | DLEP_MESSAGE  | 0x1   | 0x0   |        22 + size of opt       |
  |
   value is set to DLEP_PEER_DISCOVERY (value TBD)   |       |       |            sub-TLVs           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      |TLVs Length =14 + opt sub-TLVs |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | TBD). Mandatory TLVs are
   then placed into the packet:

   Mandatory Data Item TLVs:
            - Identification

   After the Mandatory data item, implementations MAY place any OPTIONAL
   TLVs they support:

   Optional Data Item TLVs:
            - DLEP Version
            - DLEP Peer     |TLV Flags=0x10 | Length = 11 + | Sub-TLVs as   |
  | Update ACK    |               | opt sub-TLVs  | noted below   |
  | (Value TDB)   |               |               |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Type
            - DLEP_MESSAGE (Value TBD)

   Message Flags Heartbeat Interval
            - Set to 0x1 (bit 3, mhasseqnum bit
                              is set). All other bits are unused and
                              MUST be set to '0'.

   Message Address Length Heartbeat Threshold
            - 0x0
   Message Size Link Characteristics ACK Timer
            - 22 + size of optional sub-TLVs.

   Message Sequence Number Maximum Data Rate
            - A 16-bit unsigned integer field containing
                              the sequence number from the Neighbor Up
                              Message that is being acknowledged.

   TLV Block Current Data Rate
            - TLV Length:  14 + optional sub-TLVs

   Sub TLVs
                              Identification (MANDATORY)
                              Status (OPTIONAL)

16. Latency
            - Expected Forwarding Time
            - Resources
            - Relative Link Quality

12. Peer Termination Offer Message
   The Peer Termination Offer Message is sent by either the client or the
   server when a session needs DLEP participant in response to be terminated. Transmission a
   Peer Discovery Message. Upon receipt, and successful processing, of a
   Peer Termination Offer message, the recipient MUST respond with a Peer Offer ACK message is required to confirm
   message, completing the
   termination process. The sender discovery phase of DLEP. Both DLEP
   participants (router and modem) would then enter an "in session"
   state. Any subsequent Discovery messages sent or received on this
   session MUST be considered an error, and the Peer Termination message
   is free to define its heuristics in event of a timeout. The
   receiver of session MUST be
   terminated as if a Peer Termination Message had been received.

   The Peer Offer message MUST terminate all
   neighbor sessions and release associated resources. State
   machines are returned be sent to the "discovery" state. No Neighbor Down
   messages are sent.

   The Peer Termination Message contains unicast address of 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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Msg Type =   |Msg Flg|AddrLen|          Message Size         |
  | DLEP_MESSAGE  | 0x1   | 0x0   |        22 + size
   originator of opt       |
  | (value TBD)   |       |       |            sub-TLVs           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      |TLVs Length =14 + opt sub-TLVs |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Peer Discovery, regardless of whether the discovery was
   received on the DLEP multicast address (TBD) or on a unicast
   address.

   To construct a Peer Offer message, the initial TLV type value is set
   to DLEP_PEER_OFFER (value TBD). The Identification data item TLV is
   placed in the packet next, followed by any OPTIONAL Data Item TLVs
   the implementation supports:

   Optional Data Item TLVs:

              - DLEP Version
              - Peer     |TLV Flags=0x10 | Length = 11 + | Sub-TLVs as   |
  | Termination   |               | opt sub-TLVs  | noted below   |
  | (Value TDB)   |               |               |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Type
              - DLEP_MESSAGE (Value TBD)

   Message Flags IPv4 Address
              - Set to 0x1 (bit 3, mhasseqnum
                                   bit is set). All other bits are
                                   unused IPv6 Address
              - Status
              - Heartbeat Interval
              - Heartbeat Threshold
              - Link Characteristics ACK Timer

13. Peer Offer ACK Message

   The Peer Offer ACK message acknowledges receipt of a Peer Offer
   message, and completes the router/modem session establishment for
   DLEP. The Peer Offer ACK message MUST be set sent to '0'.

   Message Address Length        - 0x0

   Message Size                  - 22 + size unicast address of
   the originator of optional sub-TLVs.

   Message Sequence Number       - A 16-bit unsigned integer field
                                   containing a sequence number
                                   generated by Peer Offer message. The Peer Offer ACK message
   MAY contain an OPTIONAL Status data item, indicating success or
   failure of the attempt to establish a router/modem session. For
   implementations that do NOT support the Status data item (defined in
   section 10.13 of this document), the Peer Offer ACK message originator. MUST be
   used ONLY to indicate successful session establishment; Peer Offer
   messages that are rejected MUST be silently dropped, allowing the
   Peer Offer to time out.

   To construct a Peer Offer ACK message, the initial TLV Block type value is
   set to DLEP_PEER_OFFER_ACK (value TBD). Mandatory data item TLV's are
   placed into the packet next:

   Mandatory Data Item TLVs:
             - TLV Length = 14 + optional sub-TLVs

   Sub TLVs Identification (MANDATORY)
             - Status (OPTIONAL)

17.

   Note that there are NO OPTIONAL data item TLVs specifed for this
   message.

14. Peer Termination ACK Update Message

   The Peer Termination Update message is an OPTIONAL message, sent by a DLEP peer
   to indicate local Layer 3 address changes, or for metric changes on a
   modem-wide basis. For example, addition of an IPv4 address to the
   router would prompt a Peer Update message to its attached DLEP
   modems. Also, a modem that changes its Maximum Data Rate for all
   destinations MAY reflect that change via a Peer Update Message ACK to its
   attached router(s).

   Concerning Layer 3 addresses, if the modem is sent by a capable of
   understanding and forwarding this information (via proprietary
   mechanisms), the address update would prompt any remote DLEP peer modems
   (DLEP-enabled modems in response a remote node) to issue a received Peer Termination order.

   The Peer Termination ACK Message contains "Neighbor Update"
   message to their local routers with the following fields:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 new (or deleted) addresses.
   Modems that do not track Layer 3 4 5 6 7 8 9 0 1 2 addresses SHOULD silently parse and
   ignore the Peer Update Message. Modems that track Layer 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Msg Type =   |Msg Flg|AddrLen|          Message Size         |
  | DLEP_MESSAGE  | 0x1   | 0x0   |        22 + size of opt       |
  | (value TBD)   |       |       |            sub-TLVs           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      |TLVs Length =14 + opt sub-TLVs |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | DLEP addresses
   MUST acknowledge the Peer Term|TLV Flags=0x10 | Length = 11 + | Sub-TLVs as   |
  | Update with a Peer Update ACK           |               | opt sub-TLVs  | noted below   |
  | (Value TBD)   |               |               |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Type                  - DLEP_MESSAGE (Value TBD)

   Message Flags                 - Set message.
   Routers receiving a Peer Update with metric changes MUST apply the
   new metric to 0x1 (bit 3, mhasseqnum
                                   bit is set). All all neighbors (remote nodes) accessible via the modem.
   Supporting implementations are free to employ heuristics to
   retransmit Peer Update messages. The sending of Peer Update Messages
   for Layer 3 address changes SHOULD cease when a either participant
   (router or modem) determines that the other bits implementation does NOT
   support Layer 3 address tracking.

   If metrics are
                                   unused supplied with the Peer Update message (e.g. Maximum
   Data Rate), these metrics are considered to be modem-wide, and
   therefore MUST be applied to all neighbors in the information base
   associated with the router/modem session.

   To construct a Peer Update message, the initial TLV type value is set
   to '0'.

   Message DLEP_PEER_UPDATE (value TBD). The Identification data item TLV is
   placed in the packet next, followed by any OPTIONAL Data Item TLVs.

   Optional Data Item TLVs:

              - IPv4 Address Length
              - 0x0

   Message Size IPv6 Address
              - 22 + optional sub-TLVs.

   Message Sequence Number Maximum Data Rate
              - A 16-bit unsigned integer field
                                   containing the sequence number in
                                   the corresponding Peer Termination
                                   Message being acknowledged.

   TLV Block Current Data Rate
              - TLV Length = 14 + optional Sub-TLVs

   Sub-TLVs
                                   Identification (MANDATORY)
                                   Status (OPTIONAL)

18. Neighbor Up Latency
              - Expected Forwarding Time
              - Resources
              - Relative Link Quality

15. Peer Update ACK Message

   A peer sends the Neighbor Up

   The Peer Update ACK message is an OPTIONAL message, and is sent by
   implementations supporting Layer 3 address tracking and/or modem-wide
   metrics to report that indicate whether a new
   potential routing neighbor, or Peer Update Message was successfully
   processed.

   To construct a new destination within the
   network, has been detected. A Neighbor Up Peer Update ACK Message message, the initial TLV type value is required
   set to confirm a received Neighbor Up. A Neighbor Up message can be DLEP_PEER_UPDATE_ACK (value TBD). The Identification data item
   TLV is placed in the packet next, followed by any OPTIONAL TLVs the
   implementation supports:

   Optional Data Item TLVs:

             - Status

16. Peer Termination Message

   The Peer Termination Message is sent by a client DLEP participant when the
   router/modem session needs to signal that it (the client) has detected be terminated. Implementations
   receiving a new
   neighbor, or by the server Peer Termination message MUST send a Peer Termination ACK
   message to indicate that new destinations
   (e.g. Multicast groups) exist within confirm the network. termination process. The sender of the Neighbor Up Message a Peer
   Termination message is free to define its
   retry heuristics in event of a
   timeout. When The receiver of a Neighbor Up
   message is received Peer Termination Message MUST release all
   resources allocated for the router/modem session, and successfully parsed, MUST eliminate
   all neighbors in the receiver
   should enter an "in session" state with regard to information base accessible via the router/modem
   pair represented by the far-end
   destination, session. Router and send an acknowledgement modem state machines are
   returned to the originating peer.

   The Neighbor Up Message 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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Msg Type =   |Msg Flg|AddrLen|          Message Size         |
  | DLEP_MESSAGE  | 0x1   | 0x0   |        31 + size of opt       |
  | (value TBD)   |       |       |            sub-TLVs           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      |TLVs Length =23 + opt sub-TLVs |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | DLEP "discovery" state. No Neighbor |TLV Flags=0x10 | Length =20 +  | Sub-TLVs as   |
  | Up (TBD)      |               | opt sub-TLVs  | noted below   |
  |               |               |               |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Type             - DLEP_MESSAGE (Value TBD)

   Message Flags            - Set to 0x1 (bit 3, mhasseqnum bit
                              is set). All other bits Down messages are unused and
                              MUST be set to '0'.

   Message Address Length   - 0x0

   Message Size             - 31 + optional Sub-TLVs

   Message Sequence Number  - A 16-bit unsigned integer field containing
   sent.

   To construct a sequence number generated by Peer Termination message, the message
                              originator.

   TLV Block                - initial TLV Length:  23 + optional Sub-TLVs.

   Sub-TLVs type value
   is set to DLEP_PEER_TERMINATION (value TBD). The Identification (MANDATORY)
                              MAC Address (MANDATORY)
                              IPv4 Address (OPTIONAL)
                              IPv6 Address (OPTIONAL)
                              Maximum Data Rate (OPTIONAL)
                              Current data
   item TLV is placed in the packet next, followed by any OPTIONAL Data Rate (OPTIONAL)
                              Latency (OPTIONAL)
                              Expected Forwarding Time (OPTIONAL)
                              Resources (OPTIONAL)
                              Relative Link Factor (OPTIONAL)
                              Credit Window Status (OPTIONAL)

19. Neighbor Up ACK Message

   A peer sends
   Item TLVs the Neighbor Up implementation supports:

   Optional Data Item TLVs:

             - Status

17. Peer Termination ACK Message to indicate whether a
   Neighbor Up

   The Peer Termination Message was successfully processed. When ACK is sent by a DLEP peer
   receives in response
   to a Neighbor Up received Peer Termination order. Receipt of a Peer Termination
   ACK message containing a Status Sub-TLV
   with a status code of 0, completes the receiving peer should enter an "in
   session" state with respect to teardown of the far-end destination.

   The Neighbor Up router/modem session.

   To construct a Peer Termination ACK message contains message, 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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Msg Type =   |Msg Flg|AddrLen|          Message Size         |
  | DLEP_MESSAGE  | 0x1   | 0x0   |                35             |
  | (value TBD)   |       |       |                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      |TLVs Length = 27               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | DLEP Neighbor |TLV Flags=0x10 | Length = 24   | Sub-TLVs as   |
  | Up ACK (TBD)  |               |               | noted below   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Type             - DLEP_MESSAGE (Value TBD)

   Message Flags            - Set to 0x1 (bit 3, mhasseqnum bit initial TLV type
   value is set). All other bits are unused and
                              MUST be set to '0'.

   Message Address Length   - 0x0

   Message Size             - 35

   Message Sequence Number  - A 16-bit unsigned integer field containing DLEP_PEER_TERMINATION_ACK (value TBD). The
   Identification data item TLV is placed in the sequence number from packet next, followed
   by any OPTIONAL TLVs the Neighbor Down
                              Message that is being acknowledged.

   TLV Block                - TLV Length:  27

   Sub-TLVs implementation supports:

   Optional Data Item TLVs:

             - Identification (MANDATORY)
                              MAC Address Sub-TLV (MANDATORY) Status Sub-TLV (MANDATORY)
                              Credit Window Status (OPTIONAL)

20.

18. Neighbor Down Up Message

   A DLEP peer participant sends the Neighbor Down Up message to report when that a new
   destination (a routing peer or a multicast group) is no longer
   reachable. The Neighbor Down message MUST contain a MAC Address TLV.
   Any other TLVs present MAY be ignored. has been detected. A Neighbor Down Up ACK Message is required
   to confirm the process. The sender of the Neighbor Down
   message is free to define its retry heuristics in event of a timeout.
   Upon successful receipt and parsing of a received Neighbor Down message, the
   receiving peer MUST remove all state information for the destination,
   and send a Up. A Neighbor Down ACK Up message to the originating peer.

   The Neighbor Down Message contains can be sent
   either by 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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Msg Type =   |Msg Flg|AddrLen|          Message Size         |
  | DLEP_MESSAGE  | 0x1   | 0x0   |         31 + optional         |
  | (value TBD)   |       |       |            sub-TLV            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      |  TLVs Length = 23 + optional  |
  |                               |             Sub-TLV           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | TLV Type =    |TLV Flags=0x10 | Length = 20 + | Sub-TLVs as   |
  | DLEP Neighbor |               | optional Sub- | noted below   |
  | Down (TBD)    |               | TLV           |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Type               - DLEP_MESSAGE (Value TBD)

   Message Flags              - Set modem, to 0x1 (bit 3, mhasseqnum bit
                                is set). All other bits are unused and
                                MUST be set indicate that a new remote node has been
   detected, or by the router, to '0'.

   Message Address Length     - 0x0

   Message Size               - 31 + optional TLVs

   Message Sequence Number    - A 16-bit unsigned integer field
                                containing indicate the presence of a sequence number generated
                                by new logical
   destination (e.g., a Multicast group) exists in the message originator.

   TLV Block                  - TLV Length: 23 + optional Sub-TLVs

   Sub TLVs
                                Identification (MANDATORY)
                                MAC Address (MANDATORY)
                                Status (OPTIONAL)

21. Neighbor Down ACK Message

   A peer sends network.

   The sender of the Neighbor Down ACK Up Message is free to indicate whether define its retry
   heuristics in event of a timeout. When a received Neighbor Down Message was successfully processed. If Up message is
   received and successfully processed, parsed, the sending peer MUST remove all state receiver should add knowledge
   of the new destination to its information on base, indicating that the referenced neighbor session.

   The Neighbor Down ACK message contains
   destination is accessible via 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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Msg Type =   |Msg Flg|AddrLen|          Message Size         |
  | DLEP_MESSAGE  | 0x1   | 0x0   |                35             |
  | (value TBD)   |       |       |                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      |TLVs Length = 27               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | DLEP modem/router pair.

   To construct a Neighbor |TLV Flags=0x10 | Length = 24   | Sub-TLVs as   |
  | Down ACK (TBD)|               |               | noted below   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Type             - DLEP_MESSAGE (Value TBD)

   Message Flags            - Set to 0x1 (bit 3, mhasseqnum bit Up message, the initial TLV type value is set). All other bits are unused and
                              MUST be set
   to '0'.

   Message DLEP_NEIGHBOR_UP (value TBD). The Identification data item TLV is
   placed in the packet next, followed by the MAC Address Length TLV,
   indicating the MAC address of the remote node or Multicast group. The
   implementation would then place any supported OPTIONAL Data Item TLVs
   into the packet:

   Optional Data Item TLVs:

              - IPv4 Address
              - IPv6 Address
              - Maximum Data Rate
              - 0x0

   Message Size Current Data Rate
              - 35

   Message Sequence Number Latency
              - A 16-bit unsigned integer field containing
                              the sequence number from the Neighbor Down
                              Message that is being acknowledged.

   TLV Block Expected Forwarding Time
              - TLV Length:  27

   Sub-TLVs Resources
              - Identification (MANDATORY)
                              MAC Address (MANDATORY) Relative Link Factor
              - Credit Window Status (MANDATORY)

22.

19. Neighbor Update Up ACK Message

   The client

   A DLEP participant sends the Neighbor Update message when a change in link
   metric parameters is detected for Up ACK Message to indicate
   whether a destination.

   The Neighbor Update Message 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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Msg Type =   |Msg Flg|AddrLen|          Message Size         |
  | DLEP_MESSAGE  | 0x1   | 0x0   |         31 + optional         |
  | (value TBD)   |       |       |            sub-TLV            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Up Message Seq Num      |  TLVs Length = 23 + optional  |
  |                               |             Sub-TLVs          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Type =     |TLV Flags=0x10 |Length = 20 +  |Sub-TLVs as    |
  |DLEP was successfully processed.

   To construct a Neighbor  |               |optional Sub-  |noted below    |
  |Update (TBD)   |               |TLVs           |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Message Type                 - DLEP_MESSAGE (Value TBD)

   Message Flags                - Set to 0x1 (bit 3, mhasseqnum
                                  bit Up ACK message, the initial TLV type value is set).  All other bits are
                                  unused and MUST be
   set to '0'.

   Message Address Length       - 0x0

   Message Size                 - 31 + optional TLVs

   Message Sequence Number      - A 16-bit unsigned integer field
                                  containing a sequence number,
                                  generated DLEP_NEIGHBOR_UP_ACK (value TBD). The Identification data item
   TLV is placed in the packet next, followed by the message originator.

   TLV Block                    - TLVs Length - 23 + optional Sub-TLVs.

   Sub TLVs
                                  Identification (MANDATORY) MAC Address (MANDATORY)
                                  Maximum TLV,
   containing the MAC address of the DLEP neighbor. The implementation
   would then place any supported OPTIONAL Data Rate (OPTIONAL)
                                  Current Item TLVs into the
   packet:

   Optional Data Rate (OPTIONAL)
                                  Latency (OPTIONAL)
                                  Resources (OPTIONAL)
                                  Relative Link Quality (OPTIONAL) Item TLVs:
              - Credit Window Status (OPTIONAL)
                                  Credit Grant (OPTIONAL)
                                  Credit Request (OPTIONAL)

23.

20. Neighbor Address Update Down Message

   The client

   A DLEP peer sends the Neighbor Address Update Down message to report when a change
   in Layer 3 addressing is detected for
   destination (a remote node or a neighbor session. multicast group) is no longer
   reachable. The Neighbor Down message MUST contain both the
   Identification data item TLV, and a MAC Address Update data item TLV. Other
   TLVs as listed are OPTIONAL, and MAY be present if an implementation
   supports them. A Neighbor Down ACK Message contains MUST be sent by 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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Msg Type =   |Msg Flg|AddrLen|          Message Size         |
  | DLEP_MESSAGE  | 0x1   | 0x0   |        31 + size
   recipient of opt       |
  | (value TBD)   |       |       |            sub-TLVs           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      |TLVs Length =23 + opt sub-TLVs |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | DLEP a Neighbor |TLV Flags=0x10 | Length =20 +  | Sub-TLVs as   |
  | Address Update|               | opt sub-TLVs  | noted below   |
  |(TBD)          |               |               |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Type                 - DLEP_MESSAGE (Value TBD)

   Message Flags                - Set Down message to 0x1 (bit 3, mhasseqnum bit confirm that the relevant
   data has been removed from the information base. The sender of the
   Neighbor Down message is
                                  set).  All other bits are unused and
                                  MUST be set free to '0'.

   Message Address Length       - 0x0

   Message Size                 - 31 + optional TLVs

   Message Sequence Number      - A 16-bit unsigned integer field
                                  containing define its retry heuristics in event
   of a sequence number,
                                  generated timeout.

   To construct a Neighbor Down message, the initial TLV type value is
   set to DLEP_NEIGHBOR_DOWN (value TBD). The signal TLV is followed by
   the message originator.

   TLV Block                    - TLVs Length mandatory data item TLVs:

      - 23 + optional Sub-TLVs.
   Sub TLVs Identification Sub-TLV (MANDATORY)
      - MAC Address Sub-TLV (MANDATORY)
                                  IPv4 Address Sub-TLV (OPTIONAL)
                                  IPv6 Address Sub-TLV (OPTIONAL)

24. Data item
      - Status data item

   Note that there are NO OPTIONAL data item TLVs for this message.

21. Neighbor Address Update Down ACK Message

   The server

   A DLEP participant sends the Neighbor Address Update Down ACK Message to indicate
   whether a received Neighbor Address Update Down Message was successfully processed.

   The
   If successfully processed, the sender of the ACK MUST have removed
   all entries in the information base that pertain to the referenced
   neighbor. As with the Neighbor Address Update Down message, there are NO OPTIONAL
   Data Item TLVs defined for the Neighbor Down ACK message contains message.

   To construct a Neighbor Down message, 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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Msg Type =   |Msg Flg|AddrLen|          Message Size         |
  | DLEP_MESSAGE  | 0x1   | 0x0   |                35             |
  | initial TLV type value is
   set to DLEP_NEIGHBOR_DOWN_ACK (value TBD)   |       |       |                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | TBD). The Identification data
   item TLV is placed in the packet next, followed by:

      - MAC Address Data item
      - Status data item

22. Neighbor Update Message Seq Num      |TLVs Length = 27               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |

   A DLEP participant sends the Neighbor |TLV Flags=0x10 | Length = 24   | Sub-TLVs as   |
  | Address Update|               |               | noted below   |
  | ACK (TBD)     |               |               |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Type Update message when it detects
   some change in the information base for a given neighbor (remote node
   or multicast group). Some examples of changes that would prompt a
   Neighbor Update message are:

       - DLEP_MESSAGE (Value TBD)

   Message Flags Change in link metrics (e.g., Data Rates)
       - Set to 0x1 (bit 3, mhasseqnum bit Layer 3 addressing change (for implementations that support it)

   To construct a Neighbor Update message, the initial TLV type value is set). All other bits are unused and
                              MUST be
   set to '0'.

   Message Address Length   - 0x0

   Message Size             - 35

   Message Sequence Number  - A 16-bit unsigned integer field containing DLEP_NEIGHBOR_UPDATE (value TBD). Following the sequence number from signal TLV are
   the Neighbor Down
                              Message that is being acknowledged. mandatory Data Item TLVs:

   Identification Data Item TLV Block                -
   MAC Address data item TLV Length:  27
   Sub

   After placing the mandatory data item TLVs
                              Identification Sub-TLV (MANDATORY)
                              MAC into the packet, the
   implementation would place any supported OPTIONAL data item TLVs.
   Possible OPTIONAL data item TLVs are:

              - IPv4 Address
              - IPv6 Address Sub-TLV (MANDATORY)
              - Maximum Data Rate
              - Current Data Rate
              - Latency
              - Resources
              - Relative Link Quality
              - Credit Window Status Sub-TLV (MANDATORY)

25.
              - Credit Grant
              - Credit Request

23. Heartbeat Message

   A Heartbeat Message is sent by a peer DLEP participant every N seconds,
   where N is defined in the "Heartbeat Interval" field of the discovery
   message. Note that implementations omitting the Heartbeat Interval
   effectively set the interval to an infinite value, therefore, in
   those cases, this message would NOT be sent.

   The message is used by peers participants to detect when a DLEP session
   partner
   is no longer communicating. Peers SHOULD allow some integral number
   of heartbeat intervals (default 4) to expire with no traffic on the
   session before initiating DLEP session termination procedures.

   The Heartbeat Message contains (either 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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Msg Type =   |Msg Flg|AddrLen|          Message Size         |
  | DLEP_MESSAGE  | 0x1   | 0x0   |               22              |
  | (value TBD)   |       |       |                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      |TLVs Length = 14               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | DLEP Heartbeat|TLV Flags=0x10 | Length = 11   | Sub-TLVs as   |
  | (TBD)         |               |               | noted below   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Type            - DLEP_MESSAGE (Value TBD)

   Message Flags           - Set to 0x1 (bit 3, mhasseqnum bit is
                             set). All other bits are unused and modem or the router) is no longer communicating.
   Participants SHOULD
                             be set allow some integral number of heartbeat intervals
   (default 4) to '0'.

   Message Address Length  - 0x0

   Message Size            - 22

   Message Sequence Number - A 16-bit unsigned integer field containing expire with no traffic on the router/modem session
   before initiating DLEP session termination procedures.

   To construct a sequence number generated by Heartbeat message, the message
                             originator. initial TLV Block - type value is set
   to DLEP_PEER_HEARTBEAT (value TBD). The signal TLV Length = 14

   Sub TLVs is followed by the
   mandatory data item TLVs:

      - Identification Sub-TLV (MANDATORY)

26.

   Note that there are NO OPTIONAL data item TLVs for this message.

24. Link Characteristics Request Message

   The Link Characteristics Request Message is an OPTIONAL message, and
   is sent by the server router to
   the client when the server detects request that a different set of
   transmission characteristics is necessary (or desired) for the
   type modem initiate changes for
   specific characteristics of traffic that is flowing on the link. It is important to
   note that Since the link request specifies a
   neighbor, it can be reference either a real destination (e.g., a remote
   node), or a logical link for destination (e.g., a multicast session
   where more than one remote neighbor participates. destination)
   within the network.

   The request Link Characteristics Request message contains either a Current
   Data Rate (CDR) TLV to request a different amount of bandwidth than
   what is currently allocated, a Latency TLV to request that traffic
   delay on the link not exceed the specified value, or both. A Link
   Characteristics ACK Message is required to complete the request.
   Implementations are free to define their retry heuristics in event of
   a timeout. Issuing a Link Characteristics Request with ONLY the MAC
   Address TLV is a mechanism a peer MAY use to request metrics (via the
   Link Characteristics ACK) from its partner.

   The

   To construct a Link Characteristics Request Message contains message, 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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Msg Type =   |Msg Flg|AddrLen|          Message Size         |
  | DLEP_MESSAGE  | 0x1   | 0x0   |        31 + size of opt       |
  | (value TBD)   |       |       |            sub-TLVs           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      |TLVs Length =23 + opt sub-TLVs |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | DLEP Link Char|TLV Flags=0x10 | Length =20 +  | Sub-TLVs as   |
  | Request (TBD) |               | opt sub-TLVs  | noted below   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Type            - DLEP_MESSAGE (Value TBD)

   Message Flags           - Set to 0x1 (bit 3, mhasseqnum bit initial TLV
   type value is set).  All other bits are unused and
                             MUST be set to '0'.

   Message Address Length  - 0x0

   Message Size            - 31 + length of optional (Current Data
                             Rate and/or Latency) Sub-TLVs

   Message Sequence Number - A 16-bit unsigned integer field containing
                             a sequence number generated by DLEP_NEIGHBOR_LINK_CHAR_REQ (value TBD).
   Following the message
                             originator. signal TLV Block               - Length: 23 + optional Sub-TLVs

   Sub TLVs are the mandatory Data Item TLVs:

   Identification Sub-TLV (MANDATORY) Data Item TLV
   MAC Address Sub-TLV (MANDATORY) data item TLV

   After placing the mandatory data item TLVs into the packet, the
   implementation would place any supported OPTIONAL data item TLVs.
   Possible OPTIONAL data item TLVs are:

   Current Data Rate Sub-TLV  - if  If present, this value represents the requested data
                             rate NEW (or
                         unchanged, if the request is denied) Current
                         Data Rate in bits per second (bps). (OPTIONAL)

   Latency TLV            - if  If present, this value represents the maximum latency, in
                             milliseconds,
                         desired on the link.
                             (OPTIONAL)

27. Link Characteristics ACK Message

   The Link Characteristics ACK Message latency (e.g., it is sent by the client to the
   server letting the server know the success (or failure) of the
   requested change in link characteristics.  The Link Characteristics
   ACK message SHOULD contain a complete set of metric TLVs. It MUST
   contain the same TLV types as the request. The values in the
   metric TLVs not-to-exceed
                         value) in milliseconds on the link.

25. Link Characteristics ACK message MUST reflect
   the link characteristics after the request has been processed.

   The Link Characteristics ACK Message 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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Msg Type =   |Msg Flg|AddrLen|          Message Size         |
  | DLEP_MESSAGE  | 0x1   | 0x0   |        31 + size of opt       |
  | (value TBD)   |       |       |            sub-TLVs           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      |TLVs Length =23 + opt sub-TLVs |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | DLEP Link Char|TLV Flags=0x10 | Length =20 +  | Sub-TLVs as   |
  | Characteristics ACK (TBD)     |               | opt sub-TLVs  | noted below   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Type            - DLEP_MESSAGE (Value TBD) Message Flags           - Set to 0x1 (bit 3, mhasseqnum bit

   The LInk Characteristics ACK message is set).  All other bits are unused an OPTIONAL message, and
                             MUST be set is
   sent by modems supporting it to '0'.

   Message Address Length  - 0x0

   Message Size            - 31 + length the router letting the router know
   the success or failure of optional (Current Data
                             Rate and/or Latency) a requested change in link characteristics.
    The Link Characteristics ACK message SHOULD contain a complete set
   of metric data item TLVs. It MUST contain the same TLV types as the
   request. The values in the metric data item TLVs

   Message Sequence Number - A 16-bit unsigned integer field containing in the sequence number that appeared on Link
   Characteristics ACK message MUST reflect the
                             corresponding link characteristics
   after the request has been processed.

   To construct a Link Characteristics Request
                             message. ACK message, the initial
   TLV Block               - TLVs Length = 23 + Optional TLVs

   Sub TLVs type value is set to DLEP_NEIGHBOR_LINK_CHAR_ACK (value TBD).
   Following the signal TLV are the mandatory Data Item TLVs:

   Identification Sub-TLV (MANDATORY) Data Item TLV
   MAC Address Sub-TLV (MANDATORY)
                             Maximum Data Rate Sub-TLV (OPTIONAL) data item TLV

   After placing the mandatory data item TLVs into the packet, the
   implementation would place any supported OPTIONAL data item TLVs.
   Possible OPTIONAL data item TLVs are:

   Current Data Rate Sub-TLV  - if  If present, this value represents the NEW (or
                             unchanged, if the request is denied)
                             Current Data Rate requested
                         data rate in bits per second (bps).
                             (OPTIONAL)

   Latency Sub-TLV            - if  If present, this value represents the NEW
                         maximum latency (or unchanged, if the request
                         is denied), expressed in milliseconds, on the
                         link.
                             (OPTIONAL)

                             Resources Sub-TLV (OPTIONAL)

                             Relative Link Quality Sub-TLV (OPTIONAL)

28.

26.  Security Considerations

   The protocol does not contain any mechanisms for security (e.g.
   authentication or encryption). The protocol assumes that any security
   would be implemented in the underlying transport (for example, by use
   of DTLS or some other mechanism), and is therefore outside the scope
   of this document.

29.

27.  IANA Considerations

   This section specifies requests to IANA.

29.1  TLV

27.1  Registrations

   This specification defines:

   o  One TLV types which must be allocated from the 0-223 range
      of the "Assigned Message TLV Types" repository of [RFC5444].

   o  A new repository for DLEP orders, signals, with seventeen fifteen values currently
   assigned.

   o  Reservation of numbering space for Experimental DLEP signals.

   o  A new repository for DLEP Sub-TLV assignments Data Items, with nineteen eighteen values
   currently assigned.

29.2

   o  Reservation of numbering space in the Data Items repository for
   experimental data items.

   o  A request for allocation of a well-known port for DLEP
   communication.

   o  A request for allocation of a multicast address for DLEP
   discovery.

27.2  Expert Review: Evaluation Guidelines

   For the registries

   No additional guidelines for TLV type extensions where an Expert Review is
   required, the designated expert SHOULD take the same general
   recommendations into consideration as review are specified by [RFC5444].

29.3  Message anticipated.

27.3  Signal (Message) TLV Type Registration

   The Message TLV specified below must be allocated from the "Message
   TLV Types" namespace of [RFC5444].

       o   DLEP_MESSAGE

29.4  DLEP Order Registration

   A new repository must be created with the values of the DLEP orders. signals.
   Valid orders signals are:

       o   Attached   Peer Discovery Message
       o   Detached   Peer Discovery Message Offer
       o   Peer Offer Message ACK
       o   Peer Update Message
       o   Peer Update ACK Message
       o   Peer Termination Message
       o   Peer Termination ACK Message
       o   Neighbor Up Message
       o   Neighbor Up ACK Message
       o   Neighbor Down Message
       o   Neighbor Down ACK Message
       o   Neighbor Update Message
       o   Neighbor Address Update Message
       o   Neighbor Address Update ACK Message
       o   Heartbeat Message
       o   Link Characteristics Request Message
       o   Link Characteristics ACK Message

   This registry should be created according to

   It is also requested that the guidelines repository contain space for
   'Message-Type-Specific TLV' registration as specified in section
   6.2.1 of [RFC5444].

29.5
   experimental signal types.

27.4  DLEP Sub-TLV Type Data Item Registrations

   A new repository for DLEP Sub-TLVs Data Items must be created. Valid Sub-TLVs Data
   Items are:

       o   Identification Sub-TLV
       o   DLEP Version Sub-TLV
       o   Peer Type Sub-TLV
       o   MAC Address Sub-TLV
       o   IPv4 Address Sub-TLV
       o   IPv6 Address Sub-TLV
       o   Maximum Data Rate Sub-TLV
       o   Current Data Rate Sub-TLV
       o   Latency Sub-TLV
       o   Expected Forwarding Time Sub-TLV
       o   Resources Sub-TLV
       o   Relative Link Quality Sub-TLV
       o   Status Sub-TLV
       o   Heartbeat Interval Sub-TLV
       o   Heartbeat Threshold Sub-TLV Interval/Threshold
       o   Link Characteristics ACK Timer Sub-TLV
       o   Credit Window Status Sub-TLV
       o   Credit Grant Sub-TLV
       o   Credit Request Sub-TLV

   It is also requested that the registry allocation contain space
   reserved for
   experimental sub-TLVs. data items.

27.5  DLEP Well-known Port

   It is requested that IANA allocate a well-known port number for DLEP
   communication.

27.6  DLEP Multicast Address

   It is requested that IANA allocate a multicast address for DLEP
   discovery messages.

30. Appendix A.

30.1  Peer Level Message Flows

*Modem

30.1.1  Modem Device (Client) Restarts Discovery

   Server                    Client

   Router                    Modem   Message Description
   ====================================================================
   <-------Peer Discovery---------    Client    Modem initiates discovery

    ---------Peer Offer----------->   Server   Router detects a problem, sends
      w/ Non-zero Status TLV          Peer Offer w/ Status w/Status TLV indicating
                                      the error.

                                      Client

                                      Modem accepts failure, restarts
                                      discovery process.

   <-------Peer Discovery---------    Client    Modem initiates discovery

    ---------Peer Offer----------->   Server   Router accepts, sends Peer Offer
         w/ Zero Status TLV           w/ Status TLV indicating success.

                                      Discovery completed.

*Modem

30.1.2  Modem Device Detects Peer Offer Timeout

   Server                    Client

   Router                    Modem   Message Description
   ====================================================================

   <-------Peer Discovery---------    Client    Modem initiates discovery, starts
                                      a guard timer.

                                      Client

                                      Modem guard timer expires.
                                      Client Modem
                                      restarts discovery process.

    <-------Peer Discovery---------   Client   Modem initiates discovery, starts
                                      a guard timer.

    ---------Peer Offer----------->   Server   Router accepts, sends Peer Offer
         w/ Zero Status TLV           w/ Status TLV indicating success.

                                      Discovery completed.

*Server

30.1.3  Router Peer Offer Lost

   Server                    Client

   Router                    Modem   Message Description
   ====================================================================

   <-------Peer Discovery---------    Client    Modem initiates discovery, starts
                                      a guard timer.

    ---------Peer Offer-------||      Server      Router offers availability

                                      Client

                                      Modem times out on Peer Offer,
                                      restarts discovery process.

   <-------Peer Discovery---------    Client    Modem initiates discovery

    ---------Peer Offer----------->   Server   Router detects subsequent
                                      discovery, internally terminates
                                      the previous, accepts the new
                                      association, sends Peer Offer w/ Status
                                      w/Status TLV indicating success.

                                      Discovery completed.

*Discovery

30.1.4  Discovery Success

   Server                    Client

   Router                    Modem   Message Description
   ====================================================================

   <-------Peer Discovery---------    Client    Modem initiates discovery

    ---------Peer Offer----------->   Server   Router offers availability

    -------Peer Heartbeat--------->

   <-------Peer Heartbeat---------

    -------Peer Heartbeat--------->

   <==============================>   Neighbor Sessions

   <-------Peer Heartbeat---------

    -------Peer Heartbeat--------->

    --------Peer Term Req--------->   Terminate Request

   <--------Peer Term Res---------    Terminate Response

*Server

30.1.5  Router Detects a Heartbeat timeout

   Server                    Client

   Router                    Modem   Message Description
   ====================================================================

   <-------Peer Heartbeat---------

    -------Peer Heartbeat--------->

      ||---Peer Heartbeat---------

           ~ ~ ~ ~ ~ ~ ~

    -------Peer Heartbeat--------->

      ||---Peer Heartbeat---------
                                      Server
                                      Router Heartbeat Timer expires,
                                      detects missing heartbeats. Server Router
                                      takes down all neighbor sessions
                                      and terminates the Peer
                                      association.

    ------Peer Terminate --------->   Peer Terminate Request

                                      Client

                                      Modem takes down all neighbor
                                      sessions, then acknowledges the
                                      Peer Terminate

   <----Peer Terminate ACK---------   Peer Terminate ACK

*Client

30.1.6  Modem Detects a Heartbeat timeout

   Server                    Client

   Router                    Modem   Message Description
   ====================================================================

   <-------Peer Heartbeat---------

    -------Peer Heartbeat------||

   <-------Peer Heartbeat---------

           ~ ~ ~ ~ ~ ~ ~

    -------Peer Heartbeat------||

   <-------Peer Heartbeat---------
                                      Client
                                      Modem Heartbeat Timer expires,
                                      detects missing heartbeats. Modem
                                      takes down all neighbor sessions
                                      and terminates the Peer association.

    <-------Peer Terminate--------    Peer Terminate Request

                                      Server

                                      Router takes down all neighbor
                                      sessions, then acknowledges the
                                      Peer Terminate

    ------Peer Terminate ACK----->    Peer Terminate ACK

*Peer

30.1.7  Peer Terminate (from Client) Modem) Lost

   Server                    Client

   Router                    Modem   Message Description
   ====================================================================

     ||------Peer Terminate--------   Client   Modem Peer Terminate Request

                                      Server

                                      Router Heartbeat times out,
                                      terminates association.

    --------Peer Terminate------->    Server    Router Peer Terminate

    <-----Peer Terminate ACK------    Client    Modem sends Peer Terminate ACK

*Peer

30.1.8  Peer Terminate (from server) Router) Lost

   Server                    Client

   Router                    Modem   Message Description
   ====================================================================

    -------Peer Terminate-------->    Server    Router Peer Terminate Request

                                      Client

                                      Modem HB times out,
                                      terminates association.

    <------Peer Terminate--------     Client     Modem Peer Terminate

    ------Peer Terminate ACK----->    Peer Terminate ACK

30.2  Neighbor Level Specific Message Flows

*Client
30.2.1  Modem Neighbor Up Lost

   Server                    Client

   Router                    Modem   Message Description
   ====================================================================

    ||-----Neighbor Up ------------   Client   Modem sends Neighbor Up

                                      Client

                                      Modem timesout on ACK

    <------Neighbor Up ------------   Client   Modem sends Neighbor Up

    ------Neighbor Up ACK--------->   Server   Router accepts the neighbor
                                      session

   <------Neighbor Update---------    Client    Modem Neighbor Metrics
          . . . . . . . .
   <------Neighbor Update---------    Client    Modem Neighbor Metrics

*Server

30.2.2  Router Detects Duplicate Neighbor Ups

   Server                    Client

   Router                    Modem   Message Description
   ====================================================================

    <------Neighbor Up ------------   Client   Modem sends Neighbor Up

    ------Neighbor Up ACK-------||    Server    Router accepts the neighbor
                                      session

                                      Client

                                      Modem timesout on ACK

    <------Neighbor Up ------------   Client   Modem resends Neighbor Up

                                      Server

                                      Router detects duplicate Neighbor,
                                      takes down the previous, accepts
                                      the new Neighbor.

    ------Neighbor Up ACK--------->   Server   Router accepts the neighbor
                                      session

   <------Neighbor Update---------    Client    Modem Neighbor Metrics
          . . . . . . . .
   <------Neighbor Update---------    Client    Modem Neighbor Metrics

*Neighbor

30.2.3  Neighbor Up, No Layer 3 Addresses

   Server                    Client

   Router                    Modem    Message Description
   ====================================================================

    <------Neighbor Up ------------   Client   Modem sends Neighbor Up

    ------Neighbor Up ACK--------->   Server   Router accepts the neighbor
                                      session

                                      Server

                                      Router ARPs for IPv4 if defined.
                                      Server
                                      Router drives ND for IPv6 if
                                      defined.

   <------Neighbor Update---------    Client    Modem Neighbor Metrics
          . . . . . . . .
   <------Neighbor Update---------    Client    Modem Neighbor Metrics

*Neighbor

30.2.4  Neighbor Up with IPv4, No IPv6

   Server                    Client

   Router                    Modem   Message Description
   ====================================================================

    <------Neighbor Up ------------   Client   Modem sends Neighbor Up with
                                      the IPv4 TLV

    ------Neighbor Up ACK--------->   Server   Router accepts the neighbor
                                      session

                                      Server

                                      Router drives ND for IPv6 if
                                      defined.

   <------Neighbor Update---------    Client    Modem Neighbor Metrics
          . . . . . . . .
   <------Neighbor Update---------    Client    Modem Neighbor Metrics

*Neighbor

30.2.5  Neighbor Up with IPv4 and IPv6

   Server                    Client

   Router                    Modem   Message Description
   ====================================================================

    <------Neighbor Up ------------   Client   Modem sends Neighbor Up with
                                      the IPv4 and IPv6 TLVs

    ------Neighbor Up ACK--------->   Server   Router accepts the neighbor
                                      session

   <------Neighbor Update---------    Client    Modem Neighbor Metrics
          . . . . . . . .
   <------Neighbor Update---------    Client

30.2.6  Neighbor Metrics

*Neighbor Session Success

   Server                    Client

   Router                    Modem   Message Description
   ====================================================================

    ---------Peer Offer----------->   Server   Router offers availability

    -------Peer Heartbeat--------->

   <------Neighbor Up -----------      Client      Modem

    ------Neighbor Up ACK-------->     Server     Router

   <------Neighbor Update---------     Client     Modem
          . . . . . . . .
   <------Neighbor Update---------     Client

                                       Client     Modem

                                       Modem initiates the terminate

   <------Neighbor Down ----------     Client     Modem

    ------Neighbor Down ACK------->    Server    Router

                                       or

                                       Server

                                       Router initiates the terminate

    ------Neighbor Down ---------->    Server    Router

   <------Neighbor Down ACK-------     Client     Modem

Acknowledgements

   The authors would like to acknowledge the influence and contributions
   of Chris Olsen, Teco Boot, Subir Das, Jaewon Kang, Vikram Kaul, Rick
   Taylor, and John Dowdell. Dowdell, Nelson Powell, Bow-Nan Cheng, and Henning
   Rogge.

Normative References

   [RFC5444] Clausen, T., Ed,. "Generalized Mobile Ad Hoc Network (MANET)
             Packet/Message Format", RFC 5444, Februar, 2009.

   [RFC5578] Berry, B., Ed., "PPPoE with Credit Flow and Metrics",
             RFC 5578, February 2010.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", RFC 2119, March 1997.

Informative References

   [DTLS] Rescorla, E., Ed,. "Datagram Transport Layer Security",
          RFC 4347, April 2006.

Author's Addresses

   Stan Ratliff
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   USA
   EMail: sratliff@cisco.com

   Bo Berry
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   USA
   EMail: boberry@cisco.com

   Greg Harrison
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   USA
   EMail: greharri@cisco.com

   Shawn Jury
   NetApp
   7301 Kit Creek Road, Building 2
   Research Triangle Park, NC 27709
   USA
   Email: shawn.jury@netapp.com

   Darryl Satterwhite
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   USA
   Email: dsatterw@cisco.com