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

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

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 November 2, 2011 August 10, 2012    .

Copyright Notice

   Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . . . . . . .  5  6
   2.  Assumptions  . . . . . . . . . . . . . . . . . . . . . . . . .  5  6
   3.  Normal Session Flow  Credits  . . . . . . . . . . . . . . . . . . . . .  5
   4.  Generic DLEP Packet Definition . . . . . .  7
   4.  Metrics  . . . . . . . . . .  6
   5.  Message Header Format . . . . . . . . . . . . . . . . .  7
   5.  Extensions to DLEP . . .  7
   6.  Message TLV Block Format . . . . . . . . . . . . . . . . . . .  7
   7.  DLEP Sub-TLVs  8
   6.  Normal Session Flow  . . . . . . . . . . . . . . . . . . . . .  8
   7.  Generic DLEP Packet Definition . . .  8
     7.1.  Identification Sub-TLV . . . . . . . . . . . . .  9
   8.  Message Header Format  . . . . .  9
     7.2.  DLEP Version Sub-TLV . . . . . . . . . . . . . . . 10
   9.  Message TLV Block Format . . . . 10
     7.3.  Peer Type Sub-TLV . . . . . . . . . . . . . . . 10
   10. DLEP Sub-TLVs  . . . . . 11
     7.4.  MAC Address Sub-TLV . . . . . . . . . . . . . . . . . . . 11
     7.5.  IPv4 Address Sub-TLV
     10.1.  Identification Sub-TLV. . . . . . . . . . . . . . . . . . 12
     10.2.  DLEP Version Sub-TLV. . . 12
     7.6.  IPv6 Address Sub-TLV . . . . . . . . . . . . . . . . 13
     10.3.  Peer Type Sub-TLV . . . 12
     7.7.  Maximum Data Rate Sub-TLV. . . . . . . . . . . . . . . . . 13
     7.8.  Current Data Rate Sub-TLV. . 14
     10.4.  MAC Address Sub-TLV . . . . . . . . . . . . . . . . 14
     7.9.  Latency Sub-TLV. . . . 14
     10.5.  IPv4 Address Sub-TLV. . . . . . . . . . . . . . . . . . . 14
     7.10. Resources 15
     10.6.  IPv6 Address Sub-TLV. . . . . . . . . . . . . . . . . . . 16
     10.7.  Maximum Data Rate Sub-TLV . . 15
     7.11. Relative Link Quality Sub-TLV. . . . . . . . . . . . . . . 16
     7.12. Peer Termination
     10.8.  Current Data Rate Sub-TLV . . . . . . . . . . . . . . . . . 16
     7.13  Heartbeat Interval 17
     10.9.  Latency Sub-TLV . . . . . . . . . . . . . . . . 17
     7.14  Heartbeat Threshold Sub-TLV. . . . . . 18
     10.10. Resources Sub-TLV . . . . . . . . . . 17
     7.15  Link Characteristics ACK Timer Sub-TLV . . . . . . . . . . 18
   8.  DLEP Protocol Messages .
     10.11. Expected Forwarding Time Sub-TLV. . . . . . . . . . . . . 19
     10.12. Relative Link Quality Sub-TLV . . . . . . . 19
     8.1.  Message Block TLV Values . . . . . . . 20
     10.13. Peer Termination Sub-TLV. . . . . . . . . . . 19
   9.  Peer Discovery Messages . . . . . . 20
     10.14. Heartbeat Interval Sub-TLV. . . . . . . . . . . . . . 20
     9.1.  Attached Peer Discovery Message . . 21
     10.15. Heartbeat Threshold Sub-TLV . . . . . . . . . . . 20
     9.2.  Detached Peer Discovery Message . . . . 21
     10.16. Link Characteristics ACK Timer Sub-TLV. . . . . . . . . . 22
   10. Peer Offer Message .
     10.17. Credit Window Status Sub-TLV. . . . . . . . . . . . . . . 23
     10.18. Credit Grant Sub-TLV. . . . . . . . 23
   11. Peer Update Message. . . . . . . . . . . . 24
     10.19. Credit Request Sub-TLV. . . . . . . . . . . 25
   12. Peer Update ACK Message. . . . . . . . 24
   11.  DLEP Protocol Messages  . . . . . . . . . . . . 27
   13. Peer Termination Message . . . . . . . 25
     11.1.  Message Block TLV Values  . . . . . . . . . . . . 27
   14. Peer Termination ACK Message . . . . 25
   12.  Peer Discovery Messages . . . . . . . . . . . . . . . . . . . 26
     12.1.  Attached Peer Discovery Message . . . . . . . . . . . . . 26
     12.2.  Detached Peer Discovery Message . . . . . . . . . . . . . 27
   13. Peer Offer Message . . . . . . . . . . . . . . 28 . . . . . . . . 29
   14. Peer Update Message. . . . . . . . . . . . . . . . . . . . . . 30
   15. Peer Update ACK Message. . . . . . . . . . . . . . . . . . . . 31
   16. Peer Termination Message . . . . . . . . . . . . . . . . . . . 32
   17. Peer Termination ACK Message . . . . . . . . . . . . . . . . . 33
   18. Neighbor Up Message  . . . . . . . . . . . . . . . . . . . . . 29
   16. 33
   19. Neighbor Up ACK Message. . . . . . . . . . . . . . . . . . . . 31
   17. 35
   20. Neighbor Down Message  . . . . . . . . . . . . . . . . . . . . 32
   18. 35
   21. Neighbor Down ACK Message. . . . . . . . . . . . . . . . . . . 33
   19. 36
   22. Neighbor Update Message  . . . . . . . . . . . . . . . . . . . 35
   20. 37
   23. Neighbor Address Update Message. . . . . . . . . . . . . . . . 36
   21. 38
   24. Neighbor Address Update ACK Message. . . . . . . . . . . . . . 38
   22. 39
   25. Heartbeat Message  . . . . . . . . . . . . . . . . . . . . . . 39
   23. 40
   26. Link Characteristics Message . . . . . . . . . . . . . . . . . 39
   24. 40
   27. Link Characteristics ACK Message . . . . . . . . . . . . . . . 41
   25. 42
   28. Security Considerations. . . . . . . . . . . . . . . . . . . . 42
   26. 43
   29. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 42
     26.1 43
     29.1  TLV Registrations. . . . . . . . . . . . . . . . . . . . . 43
     26.2
     29.2  Expert Review: Evaluation Guidelines . . . . . . . . . . . 43
     26.3
     29.3  Message TLV Type Registrations . . . . . . . . . . . . . . 43
     26.4
     29.4  DLEP Order Registrations . . . . . . . . . . . . . . . . . 43
     26.5 44
     29.5  DLEP Sub-TLV Type Registrations. . . . . . . . . . . . . . 44
   27.
   30. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 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 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 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 diagram below is following diagrams are used to illustrate
   the scope of DLEP sessions. When a local client (Modem

   |-----Local Neighbor-----|          |-----Remote Neighbor----|
   |                        |          |     (far-end 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   |

   +--------+       +-------+          +-------+       +--------+
   | 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. Finally,

   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.

   |-----Local Neighbor-----|          |-----Remote Neighbor----|

              +--------+                      +--------+       +------+ Modem A|                      | Modem A+-----+       |      | Device |  <===== // ======>   | Device |     |     (far-end device)       |      +--------+       +-------+          +-------+      P-t-P Link      +--------+     | Router |=======| Modem |{~~~~~~~~}| Modem |=======| Router       |                       Protocol                      |   +---+----+                                            +---+----+   | Router | Device|                                            | Device| Router |   |
   +--------+       +-------+          +-------+       +--------+        |                                            |        | Link   +---+----+                                            +---+----+       |                                                     +       |      +--------+                      +--------+     |
            |-DLEP--|       +------+ Modem B|                      | Protocol Modem B|     |       |-DLEP--|              | Device |   o o o o o o o o    | (e.g. Device +-----+              +--------+    o  Shared   o     +--------+                             o Medium  o                              o       o                               o     o                                o   o                                  o                             +--------+                             | Modem B|                             | Device |                             +---+----+                                 |                                 |                             +---+----+                             | 802.11) Router |                             |        |                             +--------+                Figure 1: 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,
   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. Specifically, the router is defined as the
   passive-listener, and the modem device defined as the first-speaker
   (e.g. the initiator for discovery). 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 modem devices clients appear to the router server as a
   transparent bridge - specifically, the assumption is that the
   destination MAC address for data traffic in any frame emitted by
   the router server should be the MAC address of the next-hop router or end-
   device, and not the MAC address of any of the intervening modem
   devices. 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'.
   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 and retransmitted message.  The
   unsigned 16-bit Sequence Number rolls over at 65535 to 1.  A
   Sequence Number of 0 is not valid. Peer level Sequence Numbers are unique
   within the context of a DLEP session. Sequence numbers are used in
   DLEP to correlate a response to a request.

3. Normal Session Flow

   A session Credits

   DLEP includes an OPTIONAL credit-windowing scheme analogous to the
   one documented in [RFC5578]. In this scheme, traffic between a router and a the
   DLEP client and the DLEP server is established by exchanging treated as two unidirectional
   windows. This document identifies these windows as the "Peer Discovery" "Client
   Receive Window", or CRW, and "Peer Offer" messages described below.

   Once that exchange has successfully occurred, the client informs the
   router of "Server Receive Window", or SRW.

   If credits are used, they MUST be granted by the presence of receiver on a new potential routing partner via
   given window - that is, on the
   "Neighbor Up" message. The loss of a neighbor is communicated via "Client Receive Window" (CRW),
   the
   "Neighbor Down" message, and link quality DLEP client is communicated via the
   "Neighbor Update" message. Note that, due responsible for granting credits to the issue of metrics
   varying depending on neighbor (discussed above), server,
   allowing it (the server) to send data to the client. Likewise,
   the DLEP link metrics
   are expressed within server is responsible for granting credits on the context SRW,
   which allows the client to send data to the server.

   DLEP expresses all credit data in number of a neighbor relationship, instead octets. The total number
   of credits on a window, and the link increment to add to a grant, are
   always expressed as a whole.

   Once the DLEP session has started, the session partners exchange
   heartbeat messages based 64-bit unsigned quantity.

   If used, credits are managed on a negotiated time interval. The heartbeat
   messages neighbor session basis; that is,
   separate credit counts are used maintained for each neighbor session
   requiring the service. Credits do not apply to assure DLEP peer sessions.

4. Metrics

   DLEP includes the session partners are in an
   appropriate state, ability for the client and that bidirectional connectivity still exists.

   In addition server to receiving communicate
   metrics about that reflect the link, DLEP provides for characteristics (e.g. bandwidth, latency)
   of the ability for variable-quality link in use. As mentioned in the router
   introduction section of this document, metrics have to request be used
   within a different amount of
   bandwidth, or latency, context - for its client via example, metrics to a unicast address in
   the Link Characteristics
   Message. This network. DLEP allows for metrics to be sent within two
   contexts - neighbor session context (those for a given destination
   within the router network), and peer session context (those that apply
   to deal with requisite increases
   (or decreases) all destinations accessed via the DLEP client). Metrics
   supplied on DLEP Peer messages are, by definition, in the context
   of allocated bandwidth/latency a peer session; metrics supplied on Neighbor messages are, by
   definition, used in demand-based
   schemes the context of a neighbor session.

   Supplying metrics in a more deterministic manner.

4. Generic peer session context gives clients the
   ability to supply default metrics on a 'device-wide' basis. It is
   left to implementations to choose sensible default values based on
   their specific characteristics. Additionally, the metrics (either
   at 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 for a given
   neighbor session (or peer session, if all connections via the client
   are of this static nature).

   The approach of allowing for different contexts 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, the specific algorithms for utilizing the
   dual-context metrics is out of scope and not addressed by this
   document.

5. Extensions to DLEP

   While this draft represents the best efforts of the co-authors, and
   the working group, to be functionally complete, it is recognized
   that extensions to DLEP will in all likelihood be necessary as more
   link types 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 by an
   implementation if they are not understood. The intent of the
   experimental numbering space is to allow for further development of
   DLEP protocol features and function. If subsequent development yields
   new features with sufficient applicability, those features should be
   either included in an update of this specification, or documented in
   a standalone specification.

6. Normal Session Flow

   A session between a client and a server is established by exchanging
   the "Peer Discovery" and "Peer Offer" messages described below.

   The flows described in this document create a state-full protocol
   between client and server. Both client and server initialize in a
   "discovery" state, and the client issues a "Peer Discovery" message.
   When the server receives a Peer Discovery, it responds with a "Peer
   Offer" message, and enters an "in session" state with the client.
   Receipt of the Peer Offer at the client causes it (the client) to
   transition into the "in session" state.

   Once that exchange has successfully occurred, messages transferred
   in the context of the peer session will consist of
   o  Periodic 'Heartbeat' messages, intended to keep the peer session
      alive, and to verify bidirectional connectivity, and/or
   o  Peer Update messages, indicating some change in status that one
      of the peers needs to communicate to the other.

   In addition to the messages above, the peers will transmit DLEP
   messages concerning destinations in the network. These messages
   trigger creation/maintenance/termination of 'neighbor sessions'. For
   example, a peer will inform its DLEP partner of the presence of a
   new destination via the "Neighbor Up" message. Receipt of a Neighbor
   Up causes the receiving peer to allocate the necessary resources,
   creating a neighbor session, and transition to an "in session" state
   on 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 of a destination is communicated via the "Neighbor Down"
   message, and changes in status to the destination (e.g. varying
   link quality, or addressing changes) are communicated via a
   "Neighbor Update" message.

   Again, metrics can be expressed within the context of a neighbor
   session via the Neighbor Update message, or within the context of
   a peer session (reflecting the link as a whole) via the Peer Update
   message. In cases where metrics are provided on the peer session, the
   receiving peer MUST propagate the metrics to all neighbor sessions
   accessed via the peer. A DLEP peer MAY send metrics both in a peer
   session context (via the Peer Update message) and a neighbor session
   context (via Neighbor Update) at any time. The heuristics for
   applying received peer session and neighbor session metrics is left
   to implementations.

   In addition to receiving metrics about the link, DLEP provides for
   the ability for a server to request a different amount of bandwidth,
   or latency, from the client via the Link Characteristics Message.
   This allows the server 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

   The Generic DLEP Packet Definition follows 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 | Packet Sequence Number        | Packet TLV    |
   |       |       |                               | Block...      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Msg Type   |Msg Flg|AddrLen|          Message Size         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Message Seq Num      |           TLV Block...        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Type           - An 8-bit field which specifies the type
                            of the message. For DLEP, this field
                            contains 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 Length - A 4-bit unsigned integer field encoding the
                            length of all addresses included in this
                            message. DLEP implementations do not use
                            this field; contents SHOULD be ignored.

   Message Size           - A 16-bit unsigned integer field which
                            specifies the number of octets that make up
                            the message including the message header.

   Message Sequence Number - A 16-bit unsigned integer field that
                             contains a sequence number, generated by
                             the originator 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 in the message.

9. Message TLV Block Format

   The DLEP protocol is organized as a set of orders, each with a
   collection of Sub-TLVs. The Sub-TLVs carry information needed
   to process and/or establish context (e.g. the MAC address of a
   far-end router), and the 'tlv-type' field in the message TLV
   block carries the DLEP order itself. The DLEP orders are
   enumerated in section 11.1 of this document, and the messages
   created using these orders are documented in sections 12 through
   27.

   DLEP uses 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 the total
                 number of octets in all of the immediately following
                 TLV elements (tlvs-length not included).

   TLV Type    - An 8-bit unsigned integer field specifying the type
                 of the TLV. DLEP uses this field to specify the DLEP
                 order. Valid DLEP orders are defined in section 11.1
                 of this document.

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

   Length      - Length of the 'Value' field of the TLV

   Value       - A field of length <Length> which contains data
                 specific to a particular TLV type. In the DLEP
                 case, this field will consist of a collection of
                 DLEP sub-TLVs appropriate for the DLEP action
                 specified in the TLV type field.

10. DLEP sub-TLVs

   DLEP protocol messages are transported in an RFC 5444 message TLV.
   All DLEP messages use the RFC 5444 DLEP_MESSAGE value (TBD). The
   protocol messages consist of a DLEP order, encoded in the 'tlv-type'
   field in the message TLV block, with the 'value' field of the TLV
   block containing a collection (1 or more) DLEP sub-TLVs.

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

          TLV      TLV
          Value    Description
          =========================================
          TBD      Identification sub-TLV
          TBD      DLEP Version sub-TLV
          TBD      Peer Type sub-TLV
          TBD      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 the type
                 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 to
                 '0'.

   Length      - An 8-bit length of the value field of the sub-TLV

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

10.1  Identification Sub-TLV

   This Sub-TLV MUST exist in the TLV Block for all DLEP messages, and
   MUST be the first Sub-TLV of the message. Further, there MUST be ONLY
   one Identification Sub-TLV in an RFC 5444 message TLV block. The
   Identification sub-TLV contains client and server identification
   information used to establish the proper context 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 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 are
                   unused and MUST be set to '0'.

   Length        - 8

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

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

   When the client initiates discovery (via the Peer Discovery message),
   it MUST set the Client ID to a 32-bit quantity that will be used to
   uniquely identify this session from the client-side. The client MUST
   set the Server ID to '0'. When responding to the Peer Discovery
   message, the server MUST echo the Client ID, and MUST supply its own
   unique 32-bit quantity to identify the session from the server's
   perspective. After the Peer Discovery/Peer Offer exchange, both the
   Client ID and the Server ID MUST be set to the values obtained from
   the Peer DIscovery/Peer Offer sequence.

10.2  DLEP Packet Definition Version Sub-TLV

   The Generic DLEP Packet Definition follows the format for packets
   defined Version Sub-TLV is an OPTIONAL TLV in [RFC5444].

   The Generic DLEP Packet Definition contains both 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 | Packet Sequence Number        | Packet TLV    |
   |       |       |                               | Block...      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Message (Contains DLEP message)...                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Version                - Peer
   Discovery and Peer Offer messages. The Version of RFC 5444 specification on
                            which Sub-TLV is used to
   indicate the packet/messages/TLVs are
                            constructed.

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

   Packet Sequence Number - If present, client or server version of the packet sequence number
                            is parsed protocol. The client
   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 server MAY use this TLV block.

   Message                - information to decide if the packet MAY contain zero or more
                            messages, however, DLEP messages are
                            encoded within an RFC 5444 Message
                            TLV Block.

5. Message Header Format peer is running
   at a supported level.

   The DLEP utilizes Version Sub-TLV contains the following format for the RFC 5444 message header 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   |Msg Flg|AddrLen|          Message Size =TBD  |TLV Flags=0x10 |Length=4       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Major Version |          Message Seq Num
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           TLV Block... Major Version |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message       Minor Version           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type      - an 8-bit field which specifies the type
                            of the message. For DLEP, this field
                            contains DLEP_MESSAGE (value TBD)

   Message TBD
   TLV Flags     - Set to 0x1 (bit 3, mhasseqnum bit 0x10, Bit 3 (thasvalue) is
                            set).  All set, all other bits are unused
                   not used and MUST be set to '0'.

   Message Address

   Length        - a 4-bit unsigned integer field encoding the
                            length of all addresses included in this
                            message. DLEP implementations do not use
                            this field; contents SHOULD be ignored.

   Message Size Length is 4

   Major Version - a 16-bit unsigned integer field which
                            specifies the number Major version of octets that make up the message including the message header.

   Message Sequence Number client or router protocol.

   Minor Version - a 16-bit unsigned integer field that
                             contains a sequence number, generated by Minor version of the originator client or router protocol.

   Support of this draft is indicated by setting the message. Sequence
                             numbers range from 1 to 65535. Sequence
                             numbers roll over at 65535 Major Version
   to 1; 0 is
                             invalid.

   TLV Block               - TLV Block included in '1', and the message.

6. Message TLV Block Format

   The DLEP protocol is organized as a set of orders, each with a
   collection of Sub-TLVs. The Sub-TLVs carry information needed Minor Version to process and/or establish context '2' (e.g. Version 1.2).

10.3  Peer Type Sub-TLV

   The Peer Type Sub-TLV is used by the MAC address of a
   far-end router), server and the 'tlv-type' field client to give
   additional information as to its type. It is an OPTIONAL sub-TLV in
   both the message TLV
   block carries Peer Discovery Message and the DLEP order itself. Peer Offer message. The DLEP orders are
   enumerated in section 8.1 of this document, peer
   type is a string and the messages
   created using these orders are documented is envisioned to be used for informational
   purposes (e.g. as output in sections 9 through
   24.

   DLEP uses a display command).

   The Peer Type sub-TLV contains the following settings for an RFC 5444 Message TLV
   block: 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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |       TLVs Length             |  TLV
  |TLV Type =TBD  |TLV Flags=0x10 |Length= peer   |Peer Type Str  | TLV Flags     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    Length               |       Value...               |type string len|Max Len = 80   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLVs Length - a 16-bit unsigned integer field that contains the total
                 number of octets in all of the immediately following
                 TLV elements (tlvs-length not included).

   TLV Type         - an 8-bit unsigned integer field specifying the type
                 of the TLV. DLEP uses this field to specify the DLEP
                 order. Valid DLEP orders are defined in section 8.1 of
                 this document. TBD

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

   Length           - Length of the 'Value' field of the TLV

   Value peer type string (80 bytes maximum).

   Peer Type String - A field of Non-Null terminated peer type string, maximum
                      length <Length> which contains data
                 specific to a particular TLV type. In the DLEP
                 case, this field will consist of 80 bytes. For example, a collection of
                 DLEP sub-TLVs appropriate for the DLEP action
                 specified in the TLV type field.

7. DLEP sub-TLVs

   DLEP protocol messages are transported satellite
                      modem might set this variable to 'Satellite
                      terminal'.

10.4  MAC Address Sub-TLV

   The MAC address Sub-TLV MUST appear in an RFC 5444 message TLV.
   All DLEP all neighbor-oriented
   messages use the RFC 5444 DLEP_MESSAGE value (TBD). (e.g. Neighbor Up, Neighbor Up ACK, Neighbor Down, Neighbor
   Down ACK, Neighbor Update, Link Characteristics Request, and Link
   Characteristics ACK). The
   protocol messages consist of a DLEP order, encoded in the 'tlv-type'
   field in the message TLV block, with MAC Address sub-TLV contains the 'value' field address
   of the TLV
   block containing far-end (neighbor) destination, and may be either a collection (1 physical
   or more) DLEP sub-TLVs.

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

          TLV      TLV
          Value    Description
          =========================================
          TBD      Identification sub-TLV
          TBD      DLEP Version sub-TLV
          TBD      Peer Type sub-TLV
          TBD broadcast MAC (0xFFFFFFFFFFFF).

   The 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      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

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

   TLV Type    - an 8-bit unsigned integer field specifying the type
                 of the sub-TLV. TBD

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

   Length      - an 8-bit length of the value field of the sub-TLV

   Value 6

   MAC Address - A field MAC Address of length <Length> which contains data
                 specific to a particular sub-TLV.

7.1  Identification the destination (either physical or
                 virtual).

10.5  IPv4 Address Sub-TLV

   This

   The IPv4 Address Sub-TLV MUST exist MAY be used in the TLV Block for all DLEP messages, Neighbor Up, Neighbor
   Update, and
   MUST be Peer Update Messages, if the first Sub-TLV client is aware of the message. Further, there MUST be ONLY
   one Identification Sub-TLV
   Layer 3 address. When included in an RFC 5444 message TLV block. The
   Identification Neighbor messages, the IPv4
   Address sub-TLV contains client and router identification
   information used to establish the proper context for processing DLEP
   protocol messages.

   The Identification IPv4 address of the far-end neighbor.
   In the Peer Update message, it contains the IPv4 address of the
   sending peer. In either case, the sub-TLV also contains an
   indication of whether this is a new or existing address, or is a
   deletion 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 =TBD  |TLV Flags=0x10 |Length = 8 5     | Router ID   Add/Drop    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    Router ID               | Client ID               |               |   Indicator   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    Client ID                    IPv4 Address                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   TLV Type      - Value TBD

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

   Length        - 8

   Router ID     - indicates the router ID of the DLEP session.

   Client ID     - indicates the client ID of the DLEP session.

   When the client initiates discovery (via the Peer Discovery message),
   it MUST set the Client ID to a 32-bit quantity that will be used to
   uniquely identify this session from the client-side. The client MUST
   set the Router ID to '0'. When responding to the Peer Discovery
   message, the router MUST echo the Client ID, and MUST supply its own
   unique 32-bit quantity to identify the session from the router's
   perspective. After the Peer Discovery/Peer Offer exchange, both the
   Client ID
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type     - TBD

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

   Length       - 5

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

   IPv4 Address - IPv4 Address of the values obtained from
   the Peer DIscovery/Peer Offer sequence.

7.2  DLEP Version far-end neighbor or peer.

10.6  IPv6 Address Sub-TLV

   The DLEP Version IPv6 Address Sub-TLV is an OPTIONAL TLV MAY be used in both the Peer
   Discovery Neighbor Up, Neighbor
   Update, and Peer Offer messages. The Version Sub-TLV is used to
   indicate Update Messages, if the client or router version is aware of the protocol. The client
   and router MAY use this information to decide if
   Layer 3 address. When included in Neighbor messages, the peer IPv6
   Address sub-TLV contains the IPv6 address of the far-end neighbor.
   In the Peer Update, it contains the IPv6 address of the
   originating peer. In either case, the sub-TLV also contains an
   indication of whether this is running
   at a supported level. new or existing address, or is a
   deletion of a previously known address.

   The DLEP Version Sub-TLV 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=4 |Length = 17    |   Add/Drop    |
  |               | Major Version               |               |   Indicator   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Major Version                        IPv6 Address                           |       Minor Version
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                        IPv6 Address                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        IPv6 Address                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        IPv6 Address                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type     - TBD

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

   Length       - Length is 4

   Major Version 17

   Add/Drop     - Major version of the client Value indicating whether this is a new or router protocol.

   Minor Version
   Indicator      existing address (0x01), or a withdrawal of
                  an address (0x02).

   IPv6 Address - Minor version IPv6 Address of the client far-end neighbor or router protocol.

   Support of this draft is indicated by setting the Major Version
   to '1', and the Minor Version to '1' (e.g. Version 1.1).

7.3  Peer Type peer.

10.7  Maximum Data Rate Sub-TLV

   The Peer Type Maximum Data Rate (MDR) Sub-TLV is used by the router and client to give
   additional information as to its type. It is an OPTIONAL sub-TLV in
   both the Neighbor Up, Neighbor
   Update, Peer Discovery Message and the Discovery, Peer Offer message. The peer
   type is a string Update, and is envisioned Link Characteristics ACK
   Messages to indicate the maximum theoretical data rate, in bits per
   second, that can be used for informational
   purposes (e.g. display command). achieved on the link. When metrics are reported
   via the messages listed above, the maximum data rate MUST be reported.

   The Peer Type Maximum Data Rate 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 |Length = 8     |  MDR (bps)    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |               |type string len|Max Len = 80                        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                - length of peer type string (80 bytes maximum)
   Peer Type String  8

   Maximum Data Rate     - Non-Null terminated peer type string,  A 64-bit unsigned number, representing the
                            maximum
                      length of 80 bytes. For example, a satellite
                      modem might set this variable to 'Satellite
                      terminal'.

7.4  MAC Address theoretical data rate, in bits per
                            second (bps), that can be achieved on the
                            link.

10.8  Current Data Rate Sub-TLV

   The MAC address Current Data Rate (CDR) Sub-TLV MUST appear is used in all neighbor-oriented
   messages (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 the rate at which
   the link is currently operating, or in the case of the Link
   Characteristics Request, and Link
   Characteristics ACK). The MAC Address sub-TLV contains the address
   of desired data rate for the far-end (neighbor) router. link.

   The MAC Address Current Data Rate 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 = 6     |MAC Address 8     |CDR (bps)      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      MAC Address                        CDR (bps)                              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | MAC Address                        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                - 6

   MAC Address  8

   Current Data Rate     - MAC Address of  A 64-bit unsigned number, representing the far-end router.

7.5  IPv4 Address
                            current rate, in bits per second (bps),
                            on 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 data rate.

10.9  Expected Forwarding Time Sub-TLV

   The IPv4 Address Expected Forwarding Time (EFT) Sub-TLV MAY be is used in Neighbor Up,
   Neighbor Update, Peer Discovery, and Peer Update Messages, if messages to indicate
   the client is aware of typical latency between the Layer 3
   address. When included in Neighbor messages, arrival of a given packet at the IPv4 Address sub-TLV
   contains
   transmitting device and the IPv4 address reception of the far-end router (neighbor). In
   the Peer Update message, it contains packet at the IPv4 address other end
   of the local
   router. In either case, link. EFT combines transmission time, idle time, waiting time,
   freezing time, and queuing time to the sub-TLV also contains an indication of
   whether this is a new or existing address, or is a deletion of degree that those values are
   meaningful to a previously known address. given transmission medium.

   The IPv4 Address Sub-TLV Expected Forwarding Time 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    |
  |               |               | 4     |   Indicator   EFT (ms)    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    IPv4 Address                        EFT                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type              -  TBD

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

   Length                - 5

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

   IPv4 Address  4

   Current Data Rate     - IPv4 Address of  A 32-bit unsigned number, representing the far-end router.

7.6  IPv6 Address
                            expected forwarding time, in milliseconds,
                            on the link.

10.10  Latency Sub-TLV

   The IPv6 Address Latency Sub-TLV MAY be is used in Neighbor Up, Neighbor Update,
   and Peer Update Messages, if
   Discovery, Peer Update, Link Characteristics Request, and Link
   Characteristics ACK messages to indicate the client is aware amount of latency on
   the Layer 3
   address. When included link, or in Neighbor messages, the IPv6 Address sub-TLV
   contains the IPv6 address of the far-end router (neighbor). In
   the Peer Update, it contains the IPv6 address case of the local router.
   In either case, Link Characteristics Request, to
   indicate the sub-TLV also contains an indication of whether
   this is a new or existing address, or is a deletion of maximum latency required (e.g. a
   previously known address. should-not-exeed value)
   on the link.

   The IPv6 Address sub-TLV Latency 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 2     |Latency (ms)   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Latency (ms)   |                        IPv6 Address                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  +-+-+-+-+-+-+-+-+

   TLV Type              -  TBD

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

   Length                - 17

   Add/Drop  2

   Latency               - Value indicating whether  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
                            is reported in absolute delay, in
                            milliseconds. The calculation of latency
                            is implementation dependent. For example,
                            the latency may be a new or
   Indicator      existing address (0x01), or running average
                            calculated from the internal queuing. If
                            a withdrawal of
                  an address (0x02).

   IPv6 Address - IPv6 Address of device cannot calculate latency, it
                            SHOULD be reported as 0. In the Link
                            Characteristics Request Message, this value
                            represents the maximum delay, in
                            milliseconds, expected on the far-end router.

7.7  Maximum Data Rate link.

10.11  Resources Sub-TLV

   The Maximum Data Rate (MDR) Resources Sub-TLV is used in Neighbor Up, Neighbor Update, Peer
   Discovery, Peer Update, and Link Characteristics ACK Messages messages to
   indicate the
   maximum theoretical data rate, in bits per second, that can be
   achieved a percentage (0-100) amount of resources (e.g. battery
   power) remaining on the link. When metrics are reported via the messages
   listed above, the maximum data rate MUST be reported. originating peer.

   The Maximum Data Rate sub-TLV Resources 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 = 8     |  MDR (bps)    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1     |                        MDR (bps)   Resources   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        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                -  8

   Maximum Data Rate  1
   Resources             -  A 64-bit unsigned number, percentage, 0-100, representing the
                            maximum theoretical data rate, in bits per
                            second (bps), that can
                            amount of remaining resources, such as
                            battery power. If resources cannot be achieved on the
                            link.

7.8  Current Data Rate
                            calculated, a value of 100 SHOULD be
                            reported.

10.12  Relative Link Quality Sub-TLV

   The Current Data Rate (CDR) Relative Link Quality (RLQ) Sub-TLV is used in Neighbor Up,
   Neighbor Update, Link Characteristics Request, Peer Discovery, Peer Update, and Link
   Characteristics ACK messages to indicate the rate at which the link is currently
   operating, or in the case quality of the Link Characteristics Request,
   the desired data rate for link
   as calculated by the link. originating peer.

   The Current Data Rate Relative Link Quality 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 = 8     |CDR (bps) 1     |Relative Link  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        CDR (bps)               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |                        CDR (bps)               |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                -  8

   Current Data Rate  1

   Relative Link Quality -  A 64-bit unsigned non-dimensional number, 0-100,
                            representing the
                            current data rate, in bits per second (bps),
                            on the link. When reporting metrics (e.g,
                            in Neighbor Up, Neighbor Down, or Link
                            Characteristics ACK), if there is no
                            distinction between current and maximum
                            data rates, current data rate relative link quality. A value
                            of 100 represents a link of the highest
                            quality. If the RLQ cannot be calculated, a
                            value of 100 SHOULD be
                            set equal to the maximum data rate.

7.9  Latency reported.

10.13  Status Sub-TLV

   The Latency Status Sub-TLV is used in Neighbor Up, Neighbor Update, Link
   Characteristics Request, and Link Characteristics ACK messages to
   indicate the amount of latency on sent from either the link, client or in the case of the
   Link Characteristics Request, server to
   indicate the maximum latency
   required (e.g. success or failure of a should-not-exeed value) on the link. given request

   The Latency Status 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 = 2     |Latency (ms) 1     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Latency (ms)     Code      |
  +-+-+-+-+-+-+-+-+
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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 1

   Termination Code -  the transmission delay that 0 = Success
                      Non-zero = Failure. Specific values of a packet
                            encounters as it is transmitted over non-
                      zero termination code depend on the
                            link. In operation
                      requested (e.g. Neighbor Up, Neighbor Update,
                            and Link Characteristics ACK, this value
                            is reported in absolute delay, in
                            milliseconds. Down, etc).

10.14  Heartbeat Interval Sub-TLV

   The calculation of latency
                            is modem-device dependent. For example,
                            the latency may Heartbeat Interval Sub-TLV MAY be a running average
                            calculated sent from the internal queuing. client during
   Peer Discovery to indicate the desired Heartbeat timeout window.
   If included in the modem device cannot calculate latency,
                            it SHOULD be reported as 0. In Peer Discovery, the Link
                            Characteristics Request Message, this value
                            represents server MUST either accept the maximum delay, in milliseconds,
                            expected on
   timeout interval, or reject the link.

7.10  Resources Sub-TLV

   The Resources Peer Discovery. Failing to include
   the Heartbeat Interval Sub-TLV is used in Neighbor Up, Neighbor Update, and Link
   Characteristics ACK messages to indicate Peer Discovery indicates a percentage (0-100) amount
   of resources (e.g. battery power) remaining on
   desire to establish the modem device. peer-to-peer DLEP session without an
   activity timeout (e.g. an infinite timeout value).

   The Resources TLV Heartbeat Interval 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 = 1     |   Resources Interval      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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

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

7.11  Relative Link Quality 0 = Do NOT use heartbeats on this peer-to-peer
                      session. Non-zero = Interval, in seconds, for
                      heartbeat messages.

10.15  Heartbeat Threshold Sub-TLV

   The Relative Link Quality (RLQ) Heartbeat Threshold Sub-TLV is used in Neighbor Up,
   Neighbor Update, and Link Characteristics ACK messages MAY be sent from the client during
   Peer Discovery to indicate the quality desired number of windows, of time
   (Heartbeat Interval) seconds, to wait before either peer declares
   the link peer session lost. In this case, the overall amount of time
   before a peer session is declared lost is expressed as calculated
   (Interval * Threshold), where 'Interval' is the value in the
   Heartbeat Interval sub-TLV, documented above. If this sub-TLV is
   included by the modem device.

   The Relative Link Quality client in the 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 the threshold, or reject the Peer Discovery. If 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 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     |Relative Link  |
  |     |               |               |Quality (RLQ) Threshold     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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

   Relative Link Quality

   Threshold        -  a non-dimensional number, 0-100,
                            representing the relative link quality.
                            A value of 100 represents a link 0 = Do NOT use heartbeats on this peer-to-peer
                      session. Non-zero = Number of the
                            highest quality. If the RLQ cannot be
                            calculated, a value windows, of 100 SHOULD
                      Heartbeat Interval seconds, to wait before
                      declaring a peer-to-peer session to be
                            reported.

7.12  Status lost.

10.16  Link Characteristics ACK Timer Sub-TLV

   The Status Link Characteristic ACK Timer Sub-TLV is MAY be sent from either the
   client or router during Peer Discovery to indicate the success or failure desired number of
   seconds the server should wait for a given request 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 the Peer Discovery. If this Sub-TLV is omitted,
   implementations SHOULD choose a default value.

   The Status Link Characteristics ACK Timer 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 = 1     |     Code Interval      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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

   Interval         - 0 = Success Do NOT use timeouts for Link Characteristics
                      requests on this peer-to-peer session.
                      Non-zero = Failure. Specific values of Interval, in seconds, to wait before
                      considering a non-
                      zero termination code depend on the operation
                      requested (e.g. Neighbor Up, Neighbor Down, etc).

7.13  Heartbeat Interval Link Characteristics Request has
                      been lost.

10.17  Credit Window Status Sub-TLV

   The Heartbeat Interval Credit Window Status Sub-TLV MAY MUST be sent from the client during
   Peer Discovery to indicate by the DLEP peer
   originating a Neighbor Up message when use of credits is desired Heartbeat timeout window.
   If included in
   for a given session. In the Peer Discovery, Neighbor Up message, when credits
   are desired, the router originating peer MUST either accept set the
   timeout interval, value of the
   window it controls (e.g. the Client Receive Window, or Server
   Receive Window) to an initial, non-zero value. The peer receiving
   a Neighbor Up message with a Credit Window Status Sub-TLV MUST
   either reject the Peer Discovery. use of credits, via a Neighbor Up ACK response
   with the correct Status Sub-TLV, or set the initial value from
   the data contained in the Credit Window Status Sub-TLV. If the
   initialization completes successfully, the receiving peer MUST
   respond to the Neighbor Up message with a Neighbor Up ACK message
   that contains a Credit Window Status Sub-TLV, initializing its
   receive window.

   The Heartbeat Interval Credit Window Status 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 = 1 16    | Client Receive|
  |               |               |               | Window value  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                Client Receive Window Value                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        Client Receive Window Value            | Server Receive|
  | Interval                                               | Window Value  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                Server Receive Window Value                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        Server Receive Window Value            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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 16

   Client Receive   - 0 = Do NOT use heartbeats A 64-bit unsigned number, indicating the
   Window value       current (or initial) number of credits
                      available on this peer-to-peer
                      session. Non-zero = Interval, in seconds, for
                      heartbeat messages.

7.14  Heartbeat Threshold the Client Receive Window.

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

10.18  Credit Grant Sub-TLV

   The Heartbeat Threshold Credit Grant Request Sub-TLV MAY be sent from the client during
   Peer Discovery to indicate the desired number of windows, of time
   (Heartbeat Interval) seconds, to wait before either DLEP
   peer declares
   the peer-to-peer session lost. In this case, the overall amount of
   time before to grant an increment to credits on a peer-to-peer session is declared lost window. The Credit
   Grant Sub-TLV is expressed sent as
   (Interval * Threshold), where 'Interval' is the part of a Neighbor Update message. The
   value in a Credit Grant Sub-TLV represents an increment to be
   added to any existing credits available on the
   Heartbeat Interval sub-TLV, documented above. If this sub-TLV is
   included by the client in the Peer Discovery, the client MUST also
   specify window. Upon
   successful receipt and processing of a Credit Grant Sub-TLV, the Heartbeat Interval sub-TLV
   receiving peer SHOULD respond with a non-zero interval. If
   this sub-TLV is received during Peer Discovery, the router MUST
   either accept the threshold, or reject DLEP Neighbor Update message
   containing a Credit Window Status Sub-TLV to report the Peer Discovery. updated
   aggregate values for synchronization purposes.

   The Heartbeat Threshold Credit Grant 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 = 1 8     | Threshold Credit        |
  |               |               |               | Increment     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      Credit Increment                         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            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           - 1

   Threshold        - 0 = Do NOT use heartbeats

   Reserved         - A 64-bit unsigned number representing the
                      additional credits to be assigned to the
                      credit window. Since credits can only be
                      granted by the receiver on this peer-to-peer
                      session. Non-zero = Number of windows, a window, the
                      applicable credit window (either the CRW or
                      the SRW) is derived from the sender of
                      Heartbeat Interval seconds, the
                      grant. The Credit Increment MUST NOT cause
                      the window to wait before
                      declaring a peer-to-peer session overflow; if this condition
                      occurs, implementations MUST set the credit
                      window to be lost.

7.15  Link Characteristics ACK Timer the maximum value contained in a
                      64-bit quantity.

10.19  Credit Request Sub-TLV

   The Link Characteristic ACK Timer Credit Request Sub-TLV MAY be sent from the
   client during Peer Discovery either DLEP peer, via
   a Neighbor Update order, to indicate the desired number of
   seconds desire for the router should wait partner to
   grant additional credits in order for a response data transfer to a Link
   Characteristics Request. proceed on
   the session. If the corresponding Neighbor Up message for this sub-TLV is received during Peer
   Discovery,
   session did NOT contain a Credit Window Status Sub-TLV, indicating
   that credits are to be used on the router session, then the Credit Request
   Sub-TLV MUST either accept be rejected, by sending a Neighbor Update ACK containing
   a Status Sub-TLV, by the timeout value, or
   reject receiving peer. If credits are in use on
   the Peer Discovery. session, then the receiving peer MAY respond with a DLEP
   Neighbor Update message containing a Credit Grant Sub-TLV with
   an increment of credits for the session.

   The Link Characteristics ACK Timer Credit Request 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 = 1 0     | Interval Reserved, MUST|
  |               |               |               | be set to 0   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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 0

   Reserved         - 0 = Do NOT use timeouts for Link Characteristics
                      requests on this peer-to-peer session.
                      Non-zero = Interval, in seconds, to wait before
                      considering a Link Characteristics Request has
                      been lost.

8. This field is currently unused and MUST be
                          set to 0.

11. DLEP Protocol Messages

   DLEP places no additional requirements on the RFC 5444 Packet
   formats, or the packet header. DLEP does require that the optional
   'msg-seq-num' in the message header exist, and defines a set of
   values for the 'tlv-type' field in the RFC 5444 TLV block. Therefore,
   a DLEP message, starting from the RFC 5444 Message header, would
   appear as follows:

   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   |                               |
  | (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...   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8.1

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 TLV block. DLEP defines the following Message-Type-
   specific values for the tlv-type field:

          TLV      TLV
          Value    Description
          =========================================
          TBD      Attached Peer Discovery
          TBD      Detached 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      Heartbeat
          TBD      Link Characteristics Request
          TBD      Link Characteristics ACK

   In all of the diagrams following, the message layouts begin with the
   RFC 5444 message header.

9.

12. Peer Discovery Messages

   There are two different types of Peer Discovery Messages, Attached
   and Detached.  Attached Peer Discovery Messages are sent by the
   client when it is directly attached to the router server (e.g. the client
   exists as a card in the chassis, or it is connected via Ethernet with
   no intervening devices). The Detached Peer Discovery message, on the
   other hand, is sent by a "remote" client -- for example, a client at
   a satellite hub system might use a Detached Discovery Message in
   order to act as a proxy for remote ground terminals. To explain in
   another way, a detached client uses the variable link itself (the
   radio or satellite link) to establish a DLEP session with a remote
   router.

9.1
   server.

12.1  Attached Peer Discovery Message

   The Attached Peer Discovery Message is sent by an attached client
   to a router server to begin a new DLEP association. The Peer Offer message
   is required to complete the discovery process. The client MAY
   implement its own retry heuristics in the event it (the client)
   determines the Attached Peer Discovery Message has timed out. An
   Attached Peer Discovery Message received from a peer that is already
   in session MUST be processed as if a Peer Termination Message had
   been received. An implementation MAY then process the received
   Attached Peer Discovery Message.

   Note that metric Sub-TLVs MAY be supplied with the Peer Discovery
   order. If metric Sub-TLVs are supplied, they MUST be used as a
   default value for all neighbor sessions established via this peer.

   The Attached Peer Discovery 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   |        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-TLV type= Sub-TLVs      |
  | Peer Discovery|               | opt sub-TLVs  | Identification| as noted below|
  | (Value TDB)   |               |               | sub-TLV (TBD) |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Flags=0x10 |Length = 8     |          Router ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Router ID          |          Client ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Client ID          |Sub-TLV type=  |TLV Flags=0x10 |
  |                               |DLEP Version   |               |
  |                               |sub-TLV (TBD)  |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Length = 4     |         Major Version         | Minor Version |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Minor Version |Sub-TLV type=  |TLV Flags=0x10 | Length = Len  |
  |               |Peer Type (TBD)|               |of peer string |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |               (Continued on next page)                        |
   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |               (Continued from previous page)                  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Peer Type Str |Sub-TLV Type=  |TLV Flags=0x10 | Length = 1    |
  |MaxLen=80 bytes|Heartbeat Int. |               |               |
  |               |(TBD)          |               |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Heartbeat     |Sub-TLV Type=  |TLV Flags=0x10 | Length = 1    |
  | Interval      |HB Thresh.     |               |               |
  | (seconds)     |(TBD)          |               |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Heartbeat     |Sub-TLV Type=  |TLV FLags=0x10 | Length = 1    |
  | Threshold     |Link Char. ACK |               |               |
  |(# of windows) |Timer (TBD)    |               |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Link Char ACK  |
  |Timer (sec)    |
  +-+-+-+-+-+-+-+-+

   Message 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 Length          - 0x0

   Message Size                    - 22 + size of optional sub-TLVs

   Message Sequence Number         - a 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.

                                     DLEP Attached Peer Disc. order

   Sub-TLVs:
                                     Identification TLV (MANDATORY)
                                     Version Sub-TLV (OPTIONAL)
                                     Peer Type Sub-TLV (OPTIONAL)
                                     Heartbeat Int. Sub-TLV Interval (OPTIONAL)
                                     Heartbeat Threshold Sub-TLV (OPT.) (OPTIONAL)
                                     Link Characteristics ACK Timer
                                     Sub-TLV
                                                 (OPTIONAL)

9.2
                                     Maximum Data Rate (OPTIONAL)
                                     Current Data Rate (OPTIONAL)
                                     Latency (OPTIONAL)
                                     Expected Forwarding Time (OPTIONAL)
                                     Resources (OPTIONAL)
                                     Relative Link Quality (OPTIONAL)

12.2  Detached Peer Discovery Message

   The Detached Peer Discovery Message is sent by a detached client
   proxy to a router server to begin a new DLEP session. The Peer Offer
   message is required to complete the discovery process. The client
   MAY implement its own retry heuristics in the event it (the client)
   determines the Detached Peer Discovery Message has timed out. When
   a DLEP implementation responds to a Detached Discovery Message with
   a Peer Offer, the implementation MUST enter an "in session" state
   with the peer. Any subsequent discovery message received from the
   peer MUST be processed as if a Peer Termination Message had been
   received (e.g. the existing peer session MUST be terminated). An
   implementation MAY then process the received discovery message.

   If metric sub-TLVs (e.g. Maximum Data Rate) are supplied with the
   Detached Peer Discovery message, these metrics MUST be used as the
   initial values for all far-end sessions (neighbors) established via
   the peer.

   The Detached Peer Discovery 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   |        22 + size of opt       |
  | (value TBD)   |       |       |            sub-TLV            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      |TLVs Length =14 + opt sub-TLVs |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | DLEP Detached |TLV Flags=0x10 | Length = 11 + | Sub-TLV type= |
  | Peer Discovery|               | opt sub-TLVs  | Identification|
  | (Value TDB)   |               |               | sub-TLV (TBD) |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Flags=0x10 |Length = 8     |          Router ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Router ID          |          Client ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Client ID          |Sub-TLV type=  |TLV Flags=0x10 |
  |                               |DLEP Version   |               |
  |                               |sub-TLV (TBD)  |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Length = 4     |         Major Version         | Minor Version |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Minor Version |Sub-TLV type=  |TLV Flags=0x10 | Length = Len  |
  |               |Peer Type (TBD)|               |of peer string |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Peer Type Str |Sub-TLV Type=  |TLV Flags=0x10 | Length = 1    |
  |MaxLen=80 bytes|Heartbeat Int. |               |               |
  |               |(TBD)          | =   |Msg Flg|AddrLen|          Message Size         |
  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DLEP_MESSAGE  | Heartbeat     |Sub-TLV Type=  |TLV Flags=0x10 0x1   | Length = 1 0x0   |        22 + size of opt       | Interval      |HB Thresh.
  | (value TBD)   |       |       | (seconds)     |(TBD)            sub-TLV            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      |TLVs Length =14 + opt sub-TLVs |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Heartbeat     |Sub-TLV Type= DLEP Detached |TLV FLags=0x10 Flags=0x10 | Length = 1 11 + | Sub-TLVs as   |
  | Threshold     |Link Char. ACK Peer Discovery|               | opt sub-TLVs  | noted below   |
  |(# of windows) |Timer (TBD)
  | (Value TDB)   |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Link Char ACK               |
  |Timer (sec)               |
  +-+-+-+-+-+-+-+-+
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Type                  - DLEP_MESSAGE (value TBD)

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

   Message Address 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.

                                   DLEP Detached Peer Discovery order

   Sub-TLVs
                                   Identification sub-TLV (MANDATORY)
                                   Version sub-TLV (OPTIONAL)
                                   Peer Type Sub-TLV (OPTIONAL)
                                   Heartbeat Interval Sub-TLV (OPTIONAL)
                                   Heartbeat Threshold Sub-TLV (OPTIONAL)
                                   Link Char. ACK Timer Sub-TLV(OPTIONAL)

10. (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, the client MAY include metric
   sub-TLVs. If included, the router SHOULD use these values as defaults
   that will apply to all sessions established via this client.

13. Peer Offer Message

   The Peer Offer Message is sent by a router server to a client or client
   proxy in response
   to a Peer Discovery Message. The Peer Offer Message is the response
   to either of the Peer Discovery messages
   (either Attached (Attached or Detached),
   and completes the DLEP peer session establishment.

   The Peer Offer Message contains Upon sending 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 of opt       |
  | (value TBD)   |       |       |            sub-TLV            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      |TLVs Length =14 + opt sub-TLVs |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |DLEP
   Peer Offer|TLV Flags=0x10 | Length = 11 + | Sub-TLV type= |
  | (Value TBD)   |               | opt sub-TLVs  | Identification|
  |               |               |               | sub-TLV (TBD) |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Flags=0x10 |Length = 8     |          Router ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                  (Continued Offer Message, the server then enters an "in session" state
   with the client. From the client perspective, receipt and successful
   parsing of a Peer Offer order MUST cause the client to enter the "in
   session" state. Any subsequent Discovery messages sent or received
   on next page)                     | this session MUST be considered an error, and the session MUST be
   terminated as if a Peer Termination Message had been received.

   The Peer Offer 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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                  (Continued from above)                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Router ID          |          Client ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Client ID          |Sub-TLV type=  |TLV Flags=0x10 |
  |                               |DLEP Version   |               |
  |                               |sub-TLV (TBD)  |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Length = 4    |         Major Version         | Minor Version |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Minor Version |Peer Type sub- |TLV Flags=0x10 | Length = Len  |
  |               |TLV = TDB      |               |of peer string |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Peer Type Str |DLEP IPv4 sub- |TLV Flags=0x10 | Length = 5    |
  |MaxLen=80 bytes|TLV (TBD)      |               |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Add/Drop Ind. |                 IPv4 Address                  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | IPv4 Address  |DLEP IPv6 sub- |TLV Flags=0x10 | Length = 17   |
  |               |TLV  Msg Type = TBD |   |Msg Flg|AddrLen|          Message Size         |
  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DLEP_MESSAGE  | Add/Drop Ind. 0x1   |                 IPv6 Address 0x0   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        22 + size of opt       |                        IPv6 Address
  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (value TBD)   |                        IPv6 Address       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       |                        IPv6 Address            sub-TLV            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |IPv6 Address   |Sub-TLV type=  |TLV Flags=0x10
  |          Message Seq Num      |TLVs Length = 1    |
  |               |Heartbeat Int. |               |               |
  |               |(TBD)          |               | =14 + opt sub-TLVs |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Heartbeat    |Sub-TLV Type=  |TLV
  |DLEP Peer Offer|TLV Flags=0x10 | Length = 1    |
  |  Interval     |Heartbeat      |               |               |
  |  (seconds)    |Threshold (TBD)|               |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Heartbeat    |Sub-TLV Type=  |TLV FLags=0x10 | Length = 1    |
  |  Threshold    |Link Char. ACK |               |               |
  | (# of windows)|Timer (TBD)    |               |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Link Char ACK  |Sub-TLV Type=  |TLV Flags=0x10 11 + | Length = 1 Sub-TLVs as   |
  |Timer (sec)    |DLEP Status
  | (Value TBD)   |               | opt sub-TLVs  |               |(TBD) indicated     |
  |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               | Code               |
  +-+-+-+-+-+-+-+-+ below         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message 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 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               - TLV Length: 14 + size of optional sub-TLVs
                             DLEP Peer Offer order

   Sub TLVs
                             Identification sub-TLV (MANDATORY)
                             DLEP
                             Version sub-TLV (OPTIONAL)
                             Peer Type sub-TLV (OPTIONAL)
                             IPv4 Address sub-TLV (OPTIONAL)
                             IPv6 Address sub-TLV (OPTIONAL)
                             Status sub-TLV (OPTIONAL)
                             Heartbeat Interval Sub-TLV (OPTIONAL)
                             Heartbeat Threshold Sub-TLV (OPTIONAL)
                             Link Char. Characteristics ACK Timer Sub-TLV (OPTIONAL)

11.

14. Peer Update Message

   The Peer Update message is sent by the router a DLEP peer to indicate local
   Layer 3 address changes. changes, or for metric changes on a device-wide
   basis. For example, addition of an IPv4 address to the router server would
   prompt a Peer Update message to its attached DLEP clients. If Also, a
   client that changes its Maximum Data Rate for all destinations MAY
   reflect that change via a Peer Update Message to its attached server.

   With Layer 3 address changes, if the modem device client is capable of
   understanding and forwarding this information, the address update
   would prompt any remote DLEP clients (DLEP clients that are on the
   far-end of the variable link) to issue a "Neighbor Update" message to
   their local
   routers, servers with the address change information. new (or deleted) addresses. Clients that
   do not track Layer 3 addresses MUST silently parse and ignore the Peer
   Update Message. Clients that track Layer 3 addresses MUST acknowledge
   the Peer Update with a Peer Update ACK message. Routers Servers receiving a
   Peer Update with metric changes MUST apply the new metric to all
   neighbor sessions established via the client. Peers MAY employ
   heuristics to retransmit Peer Update messages. Sending The sending of Peer
   Update Messages for Layer 3 address changes SHOULD cease when a router server
   implementation determines that a partner modem device client does NOT support Layer 3
   address tracking.

   If metric Sub-TLVs are supplied with the Peer Update message (e.g.
   Maximum Data Rate), these metrics MUST be applied to all neighbor
   sessions accessible via the peer.

   The Peer 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   |        22 + size of opt       |
  | (value TBD)   |       |       |            sub-TLVs           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      |TLVs Length =14 + opt sub-TLVs |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | DLEP Peer     |TLV Flags=0x10 | Length = 11 + | Sub-TLV type= Sub-TLVs as   |
  | Update        |               | opt sub-TLVs  | Identification| noted below   |
  | (Value TDB)   |               |               | sub-TLV (TBD) |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Flags=0x10 |Length = 8     |          Router ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Router ID          |          Client ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Client ID          |Sub-TLV type=  |TLV Flags=0x10 |
  |                               |DLEP IPv4      |               |
  |                               |sub-TLV (TBD)  |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Length = 5     | Add/Drop Ind. |         IPv4 Address          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |         IPv4 Address          | Sub-TLV type= |TLV Flags=0x10 |
  |                               | DLEP IPv6     |               |
  |                               | sub-TLV (TBD) |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Length = 17    | Add/Drop Ind. |         IPv6 Address          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        IPv6 Address                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        IPv6 Address                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        IPv6 Address               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        IPv6 Address           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Message 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 Length   - 0x0

   Message Size             - 22 + optional Sub-TLVs

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

   TLV Block                - TLV Length:  14 + length of optional
                                           sub-TLVs.
                              DLEP Peer Update order
   Sub TLVs
                              Identification sub-TLV (MANDATORY)
                              IPv4 Address Sub-TLV (OPTIONAL)
                              IPv6 Address Sub-TLV
                              IPv6 Address (OPTIONAL)
                              Maximum Data Rate (OPTIONAL)
                              Current Data Rate (OPTIONAL)
                              Latency (OPTIONAL)

12.
                              Expected Forwarding Time (OPTIONAL)
                              Resources (OPTIONAL)
                              Relative Link Quality (OPTIONAL)

15. Peer Update ACK Message

   The client

   A peer sends the Peer Update ACK Message to indicate whether a
   Peer Update Message was successfully processed.

   The Peer Update 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   |        22 + size of opt       |
  | (value TBD)   |       |       |            sub-TLVs           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      |TLVs Length =14 + opt sub-TLVs |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | DLEP Peer     |TLV Flags=0x10 | Length = 11 + | Sub-TLV type= Sub-TLVs as   |
  | Update ACK    |               | opt sub-TLVs  | Identification| noted below   |
  | (Value TDB)   |               |               | sub-TLV (TBD) |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Flags=0x10 |Length = 8     |          Router ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Router ID          |          Client ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Client ID          |Sub-TLV type=  |TLV Flags=0x10 |
  |                               |DLEP Status    |               |
  |                               |sub-TLV (TBD)  |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Length = 1     |      Code     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message 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 Length   - 0x0
   Message Size             - 22 + size of optional sub-TLVs.

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

   TLV Block                - TLV Length:  14 + optional sub-TLVs
                              DLEP Peer Update ACK order

   Sub TLVs
                              Identification Sub-TLV (MANDATORY)
                              Status Sub-TLV (OPTIONAL)

13.

16. Peer Termination Message

   The Peer Termination Message is sent by either the client or the
   router
   server when a session needs to be terminated. Transmission of a
   Peer Termination ACK message is required to confirm the
   termination process. The sender of the Peer Termination message
   is free to define its heuristics in event of a timeout. The
   receiver of a Peer Termination Message MUST terminate all
   neighbor relationships sessions and release associated resources. State
   machines are returned to the "discovery" state. No Neighbor Down
   messages are sent.

   The Peer Termination 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   |        22 + size of opt       |
  | (value TBD)   |       |       |            sub-TLVs           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      |TLVs Length =14 + opt sub-TLVs |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | DLEP Peer     |TLV Flags=0x10 | Length = 11 + | Sub-TLV type= Sub-TLVs as   |
  | Termination   |               | opt sub-TLVs  | Identification| noted below   |
  | (Value TDB)   |               |               | sub-TLV (TBD) |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Flags=0x10 |Length = 8     |          Router ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Router ID          |          Client ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Client ID          |Sub-TLV type=  |TLV Flags=0x10 |
  |                               |DLEP Status    |               |
  |                               |sub-TLV (TBD)  |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Length = 1    | Code          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message 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 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                     - TLV Length = 14 + optional sub-TLVs
                                   DLEP Peer Termination order

   Sub TLVs
                                   Identification Sub-TLV (MANDATORY)
                                   Status Sub-TLV (OPTIONAL)

14.

17. Peer Termination ACK Message

   The Peer Termination Message ACK is sent by either the client or
   the router when a session needs DLEP peer in response
   to be terminated. a received Peer Termination order.

   The Peer Termination 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   |        22 + size of opt       |
  | (value TBD)   |       |       |            sub-TLVs           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      |TLVs Length =14 + opt sub-TLVs |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | DLEP Peer Term|TLV Flags=0x10 | Length = 11 + | Sub-TLV type= Sub-TLVs as   |
  | ACK           |               | opt sub-TLVs  | Identification| noted below   |
  | (Value TBD)   |               |               | sub-TLV (TBD) |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Flags=0x10 |Length = 8     |          Router ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Router ID          |          Client ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Client ID          |Sub-TLV type=  |TLV Flags=0x10 |
  |                               |DLEP Status    |               |
  |                               |sub-TLV (TBD)  |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Length = 1    | Code          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message 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 Length        - 0x0

   Message Size                  - 22 + optional sub-TLVs.

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

   TLV Block                     - TLV Length = 14 + optional Sub-TLVs
                                   DLEP Peer Termination ACK order

   Sub-TLVs
                                   Identification Sub-TLV (MANDATORY)
                                   Status Sub-TLV (OPTIONAL)

15.

18. Neighbor Up Message

   The client

   A peer sends the Neighbor Up message to report that a new
   potential routing neighbor neighbor, or a new destination within the
   network, has been detected. A Neighbor Up ACK Message is required

   to confirm a received Neighbor Up. confirm a received Neighbor Up. A Neighbor Up message can be
   sent by a client to signal that it (the client) has detected a new
   neighbor, or by the server to indicate that new destinations
   (e.g. Multicast groups) exist within the network.

   The sender of the Neighbor Up Message is free to define its
   retry heuristics in event of a timeout. When a Neighbor Up
   message is received and successfully parsed, the receiver
   should enter an "in session" state with regard to the far-end
   destination, and send an acknowledgement 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 Neighbor |TLV Flags=0x10 | Length =20 +  | Sub-TLV type= |
  | Up (TBD)      |               | opt sub-TLVs  | Identification|
  |               |               |               | sub-TLV (TBD) |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Flags=0x10 |Length = 8     |          Router ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Router ID          |          Client ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Client ID          |Sub-TLV type=  |TLV Flags=0x10 |
  |                               |DLEP MAC       |               |
  |                               |sub-TLV (TBD)  |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Length = 6     |                MAC Address                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              MAC Address                      |Sub-TLV type=  |
  |                                               |DLEP IPv4 (TBD)|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Flags=0x10 |Length = 5     | Add/Drop Ind. | IPv4 Address  |
  |               |               |               |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                IPv4 Address                   |Sub-TLV type=  |
  |                                               |DLEP IPv6 (TBD)|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                   (Continued on next page)                    |
   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                  (Continued from above)                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Flags=0x10 |Length = 17    | Add/Drop Ind. | IPv6 Address  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        IPv6 Address                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        IPv6 Address                           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        IPv6 Address                           | 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                IPv6 Address                   |Sub-TLV type=  |
  |                                               |DLEP MDR (TBD) |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Flags=0x10 |Length  Msg Type = 8   |Msg Flg|AddrLen|          Message Size         |         MDR (bps)
  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DLEP_MESSAGE  |                        MDR (bps) 0x1   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0x0   |        MDR (bps)              |sub-TLV Type = |TLV Flags=0x10        31 + size of opt       |
  |                               |DLEP CDR (TBD) (value TBD)   |       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Length = 8       |                 CDR (bps)            sub-TLVs           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        CDR (bps)          Message Seq Num      |TLVs Length =23 + opt sub-TLVs |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  CDR (bps)    |sub-TLV Type = DLEP Neighbor |TLV Flags=0x10 | Length = 2    |
  |               |Latency (TBD)  |               | =20 +  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Latency (ms)           |sub-TLV Type = |TLV Flags=0x10 Sub-TLVs as   |
  |                               |Resources(TBD) Up (TBD)      |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ opt sub-TLVs  | Length = 1 noted below   |   Resources   |sub-TLV Type = |TLV Flags=0x10
  |               |               |               |DLEP RLQ (TBD)               |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Length = 1    |      RLQ      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message 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 Length   - 0x0

   Message Size             - 31 + optional Sub-TLVs

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

   TLV Block                - TLV Length:  23 + optional Sub-TLVs.
                              DLEP Neighbor Up order

   Sub-TLVs
                              Identification Sub-TLV (MANDATORY)
                              MAC Address Sub-TLV (MANDATORY)
                              IPv4 Address Sub-TLV (OPTIONAL)
                              IPv6 Address Sub-TLV (OPTIONAL)
                              Maximum Data Rate Sub-TLV (OPTIONAL)
                              Current Data Rate Sub-TLV (OPTIONAL)
                              Latency Sub-TLV (OPTIONAL)
                              Expected Forwarding Time (OPTIONAL)
                              Resources Sub-TLV (OPTIONAL)
                              Relative Link Factor Sub-TLV (OPTIONAL)

16.
                              Credit Window Status (OPTIONAL)

19. Neighbor Up ACK Message

   The router

   A peer sends the Neighbor Up ACK Message to indicate whether a
   Neighbor Up Message was successfully processed. When a peer
   receives a Neighbor Up ACK message containing a Status Sub-TLV
   with a status code of 0, the receiving peer should enter an "in
   session" state with respect to the far-end destination.

   The Neighbor Up 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   |                35             |
  | (value TBD)   |       |       |                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      |TLVs Length = 27               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | DLEP Neighbor |TLV Flags=0x10 | Length = 24   | Sub-TLV type= Sub-TLVs as   |
  | Up ACK (TBD)  |               |               | Identification|
  |               |               |               | sub-TLV (TBD) |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Flags=0x10 |Length = 8     |          Router ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Router ID          |          Client ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Client ID          |Sub-TLV type=  |TLV Flags=0x10 |
  |                               |DLEP MAC       |               |
  |                               |sub-TLV (TBD)  |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Length = 6     |                MAC Address                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              MAC Address                      |Sub-TLV type=  |
  |                                               |DLEP Status
  |                                               |(TBD) noted below   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Flags=0x10 | Length = 1    |  Code         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message 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 Length   - 0x0

   Message Size             - 35

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

   TLV Block                - TLV Length:  27

                              DLEP Neighbor Up ACK order

   Sub-TLVs                 - Identification Sub-TLV (MANDATORY)
                              MAC Address Sub-TLV (MANDATORY)
                              Status Sub-TLV (MANDATORY)

17.
                              Credit Window Status (OPTIONAL)

20. Neighbor Down Message

   The client

   A DLEP peer sends the Neighbor Down message to report when a neighbor
   destination (a routing peer or a multicast group) is no longer reachable from the client.
   reachable. The Neighbor Down message MUST contain a MAC Address TLV.
   Any other TLVs present MAY be ignored. A Neighbor Down 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 Neighbor Down message, the
   receiving peer MUST remove all state information for the destination,
   and send a Neighbor Down ACK message to the originating peer.

   The Neighbor Down 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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      |  TLVs Length = 23 + optional  |
  |                               |             Sub-TLV           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | TLV Type =    |TLV Flags=0x10 | Length = 20 + | Sub-TLV type= Sub-TLVs as   |
  | DLEP Neighbor |               | optional Sub- | Identification| noted below   |
  | Down (TBD)    |               | TLV           | sub-TLV (TBD) |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Flags=0x10 |Length = 8     |          Router ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Router ID          |          Client ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Client ID          |Sub-TLV type=  |TLV Flags=0x10 |
  |                               |DLEP MAC       |               |
  |                               |sub-TLV (TBD)  |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                  (Continued on next page)                     |
   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                   (Continued from above)                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Length = 6     |                MAC Address                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              MAC Address                      |Sub-TLV type=  |
  |                                               |DLEP Status
  |                                               |(TBD)               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Flags=0x10 | Length = 1    |  Code         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message 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 Length     - 0x0

   Message Size               - 31 + optional TLVs

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

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

                                DLEP Neighbor Down order

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

18.

21. Neighbor Down ACK Message

   The router

   A peer sends the Neighbor Down ACK Message to indicate whether
   a received Neighbor Down Message was successfully processed. If
   successfully processed, the sending peer MUST remove all state
   information on the referenced neighbor session.

   The Neighbor Down 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   |                35             |
  | (value TBD)   |       |       |                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      |TLVs Length = 27               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | DLEP Neighbor |TLV Flags=0x10 | Length = 24   | Sub-TLV type= |
  | Down ACK (TBD)|               |               | Identification|
  |               |               |               | sub-TLV (TBD) |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Flags=0x10 |Length = 8     |          Router ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Router ID          |          Client ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Client ID          |Sub-TLV type=  |TLV Flags=0x10 |
  |                               |DLEP MAC       |               |
  |                               |sub-TLV (TBD)  |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Length = 6     |                MAC Address                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              MAC Address                      |Sub-TLV type=  |
  |                                               |DLEP Status
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                               |(TBD)          Message Seq Num      |TLVs Length = 27               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | DLEP Neighbor |TLV Flags=0x10 | Length = 1 24   |  Code Sub-TLVs as   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Down ACK (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
                              MUST be set to '0'.

   Message Address Length   - 0x0

   Message Size             - 35

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

   TLV Block                - TLV Length:  27

                              DLEP Neighbor Down ACK order

   Sub-TLVs                 - Identification Sub-TLV (MANDATORY)
                              MAC Address Sub-TLV (MANDATORY)
                              Status Sub-TLV (MANDATORY)

19.

22. Neighbor Update Message

   The client sends the Neighbor Update message when a change in link
   metric parameters is detected for a routing neighbor. 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            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      |  TLVs Length = 23 + optional  |
  |                               |             Sub-TLVs          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Type =     |TLV Flags=0x10 |Length = 20 +  |Sub-TLV type =  |Sub-TLVs as    |
  |DLEP Neighbor  |               |optional Sub-  |Identification  |noted below    |
  |Update (TBD)   |               |TLVs           |Sub-TLV (TBD)  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Flags=0x10 |Length = 8     |          Router ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Router ID          |          Client ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Client ID          |Sub-TLV type=  |TLV Flags=0x10 |
  |                               |DLEP MAC       |               |
  |                               |sub-TLV (TBD)  |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Length = 6     |                MAC Address                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              MAC Address                      |Sub-TLV type=  |
  |                                               |DLEP MDR (TBD) |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Flags=0x10 |Length = 8     |           MDR (bps)           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        MDR (bps)                              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        MDR (bps)              |Sub-TLV Type = |TLV Flags=0x10 |
  |                               |DLEP CDR (TBD) |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Length = 8     |                 CDR (bps)                     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        CDR (bps)                              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   CDR (bps)   |Sub-TLV Type = |TLV Flags=0x10 | Length = 2    |
  |               |DLEP Latency   |               |               |
  |               |(TBD)          |               |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        Latency (ms)           |Sub-TLV Type=  |TLV Flags=0x10 |
  |                               |DLEP Resources |               |
  |                               |(TBD)          |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                   (Continued on next page)                    |
   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    (Continued from above)                     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Length = 1    |   Resources   |Sub-TLV Type=  |TLV FLags=0x10 |
  |               |               |DLEP RLQ (TBD)           |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Length = 1    |      RLQ      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Message 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 Length       - 0x0

   Message Size                 - 31 + optional TLVs

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

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

                                  DLEP Neighbor Update order

   Sub TLVs
                                  Identification Sub-TLV (MANDATORY)
                                  MAC Address Sub-TLV (MANDATORY)
                                  Maximum Data Rate Sub-TLV (OPTIONAL)
                                  Current Data Rate Sub-TLV (OPTIONAL)
                                  Latency Sub-TLV (OPTIONAL)
                                  Resources Sub-TLV (OPTIONAL)
                                  Relative Link Quality Sub-TLV (OPTIONAL)

20.
                                  Credit Window Status (OPTIONAL)
                                  Credit Grant (OPTIONAL)
                                  Credit Request (OPTIONAL)

23. Neighbor Address Update Message

   The client sends the Neighbor Address Update message when a change
   in Layer 3 addressing is detected for a routing neighbor. neighbor session.

   The Neighbor Address 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 + size of opt       |
  | (value TBD)   |       |       |            sub-TLVs           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      |TLVs Length =23 + opt sub-TLVs |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                 (Continued on next page)                      |
   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                  (Continued from above)                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | DLEP Neighbor |TLV Flags=0x10 | Length =20 +  | Sub-TLV type= Sub-TLVs as   |
  | Address Update|               | opt sub-TLVs  | Identification|
  |(TBD)          |               |               | Sub-TLV (TBD) |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Flags=0x10 |Length = 8     |          Router ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Router ID          |          Client ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Client ID          |Sub-TLV type=  |TLV Flags=0x10 |
  |                               |DLEP MAC       |               |
  |                               |sub-TLV (TBD)  |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Length = 6     |                MAC Address                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              MAC Address                      |Sub-TLV type=  |
  |                                               |DLEP IPv4 (TBD)|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Flags=0x10 |Length = 5     | Add/Drop Ind. | IPv4 Address  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                IPv4 Address                   |Sub-TLV type=  |
  |                                               |DLEP IPv6 (TBD)|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Flags=0x10 |Length = 17    | Add/Drop Ind. | IPv6 Address  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        IPv6 Address noted below   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |(TBD)          |                        IPv6 Address               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |                        IPv6 Address               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                IPv6 Address                   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message 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 Length       - 0x0

   Message Size                 - 31 + optional TLVs

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

   TLV Block                    - TLVs Length - 23 + optional Sub-TLVs.
                                  DLEP Neighbor Address Update order
   Sub TLVs
                                  Identification Sub-TLV (MANDATORY)
                                  MAC Address Sub-TLV (MANDATORY)
                                  IPv4 Address Sub-TLV (OPTIONAL)
                                  IPv6 Address Sub-TLV (OPTIONAL)

21.

24. Neighbor Address Update ACK Message

   The router server sends the Neighbor Address Update ACK Message to
   indicate whether a Neighbor Address Update Message was
   successfully processed.

   The Neighbor Address Update 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   |                35             |
  | (value TBD)   |       |       |                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      |TLVs Length = 27               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | DLEP Neighbor |TLV Flags=0x10 | Length = 24   | Sub-TLV type= Sub-TLVs as   |
  | Address Update|               |               | Identification|
  | ACK (TBD)     |               |               | sub-TLV (TBD) |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Flags=0x10 |Length = 8     |          Router ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Router ID          |          Client ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Client ID          |Sub-TLV type=  |TLV Flags=0x10 |
  |                               |DLEP MAC       | noted below   |
  |                               |sub-TLV ACK (TBD)     |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Length = 6     |                MAC Address                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              MAC Address                      |Sub-TLV type=  |
  |                                               |DLEP Status
  |                                               |(TBD)          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Flags=0x10 | Length = 1    |  Code               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message 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 Length   - 0x0

   Message Size             - 35

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

   TLV Block                - TLV Length:  27

                              DLEP Neighbor Address Update ACK order
   Sub TLVs
                              Identification Sub-TLV (MANDATORY)
                              MAC Address Sub-TLV (MANDATORY)
                              Status Sub-TLV (MANDATORY)

22.

25. Heartbeat Message

   A Heartbeat Message is sent by a peer every N seconds, where N is
   defined in the "Heartbeat Interval" field of the discovery message.
   The message is used by peers 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 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-TLV type= |
  | (TBD)         |               |               | Identification|
  |               | Sub-TLVs as   |
  | sub-TLV (TBD)         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Flags=0x10 |Length = 8     |          Router ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |            Router ID               |          Client ID noted below   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Client ID          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Type            - DLEP_MESSAGE (Value TBD)

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

   Message Address Length  - 0x0

   Message Size            - 22

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

   TLV Block -               TLV Length = 14

                             DLEP Heartbeat order

   Sub TLVs  -
                             Identification Sub-TLV (MANDATORY)

23.

26. Link Characteristics Request Message

   The Link Characteristics Request Message is sent by the router server to
   the modem device client when the router server detects that a different set of
   transmission characteristics is necessary (or desired) for the
   type of traffic that is flowing on the link. It is important to
   note that the link can be a logical link for a multicast session
   where more than one remote neighbor participates. The request
   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 Link Characteristics Request 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-TLV type= |
  | Request (TBD) |               | opt sub-TLVs  | Identification|
  |               |               |               | Sub-TLV (TBD) |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Flags=0x10 |Length = 8     |          Router ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Router ID          |          Client ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Client ID          |Sub-TLV type=  |TLV Flags=0x10 |
  |                               |DLEP MAC       |               |
  |                               |sub-TLV (TBD)  |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Length = 6     | with ONLY the MAC Address                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                (Continued on next page)                       | TLV is a
   mechanism a peer MAY use to request metrics (via the Link
   Characteristics ACK) from its partner.

   The Link Characteristics Request 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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                (Continued from above)  Msg Type =   |Msg Flg|AddrLen|          Message Size         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              MAC Address                      |Sub-TLV type= DLEP_MESSAGE  | 0x1   |                                               |DLEP CDR (TBD) 0x0   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Flags=0x10 |Length = 8        31 + size of opt       |           CDR (bps)
  | (value TBD)   |       |       |            sub-TLVs           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        CDR (bps)          Message Seq Num      |TLVs Length =23 + opt sub-TLVs |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        CDR (bps)              |Sub-TLV Type=  |TLV DLEP Link Char|TLV Flags=0x10 | Length =20 +  |                               |Latency Sub-TLVs as   |
  | Request (TBD) |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Length = 2 opt sub-TLVs  |         Latency (ms) 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
                             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 the message
                             originator.

   TLV Block               - Length: 23 + optional Sub-TLVs

                             DLEP Link Characteristics Request order

   Sub TLVs
                             Identification Sub-TLV (MANDATORY)
                             MAC Address Sub-TLV (MANDATORY)
                             Current Data Rate Sub-TLV - if present,
                             this value represents the requested data
                             rate in bits per second (bps). (OPTIONAL)
                             Latency TLV - if present, this value
                             represents the maximum latency, in
                             milliseconds, desired on the link.
                             (OPTIONAL)

24.

27. Link Characteristics ACK Message

   The Link Characteristics ACK Message is sent by the client to the
   router
   server letting the router 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 in the 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-TLV type= |
  | ACK (TBD)     |               | opt sub-TLVs  | Identification|
  |               |               |               | Sub-TLV (TBD) |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Flags=0x10 |Length = 8     |          Router ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Router ID          |          Client ID            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Client ID          |Sub-TLV type=  |TLV Flags=0x10 |
  |                               |DLEP MAC       |               |
  |                               |sub-TLV (TBD)  |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Length = 6     |                MAC Address                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              MAC Address                      |Sub-TLV type=  |
  |                                               |DLEP MDR (TBD) |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |TLV Flags=0x10 |Length = 8     |           MDR (bps)           | 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                        MDR (bps)  Msg Type =   |Msg Flg|AddrLen|          Message Size         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        MDR (bps)              |Sub-TLV Type=  |TLV Flags=0x10 DLEP_MESSAGE  | 0x1   |                               |DLEP CDR (TBD) 0x0   |        31 + size of opt       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Length = 8
  |                  CDR (bps) (value TBD)   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+       |                           CDR (bps)       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+            sub-TLVs           |  CDR (bps)    |Sub-TLV Type = |TLV Flags=0x10
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      |TLVs Length = 2    |
  |               |Latency (TBD)  |               | =23 + opt sub-TLVs |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |        Latency (ms)           |Sub-TLV Type=  |TLV DLEP Link Char|TLV Flags=0x10 |
  |                               |Resources (TBD)|               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Length = 1    |   Resources   |Sub-TLV Type=  |TLV Flags=0x10 =20 +  | Sub-TLVs as   |
  |               |RLQ ACK (TBD)     |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Length = 1 opt sub-TLVs  |      RLQ 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
                             MUST be set to '0'.

   Message Address Length  - 0x0

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

   Message Sequence Number - A 16-bit unsigned integer field containing
                             the sequence number that appeared on the
                             corresponding Link Characteristics Request
                             message.

   TLV Block               - TLVs Length = 23 + Optional TLVs

                             DLEP Link Characteristics ACK order

   Sub TLVs
                             Identification Sub-TLV (MANDATORY)
                             MAC Address Sub-TLV (MANDATORY)
                             Maximum Data Rate Sub-TLV (OPTIONAL)

                             Current Data Rate Sub-TLV - if present,
                             this value represents the NEW (or
                             unchanged, if the request is denied)
                             Current Data Rate in bits per second (bps).
                             (OPTIONAL)
                             Latency Sub-TLV - 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)

25.

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

26.

29.  IANA Considerations

   This section specifies requests to IANA.

26.1

29.1  TLV 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, with seventeen values currently
      assigned.

   o  A new repository for DLEP Sub-TLV assignments with fifteen nineteen values
      currently assigned.

26.2

29.2  Expert Review: Evaluation Guidelines

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

26.3

29.3  Message TLV Type Registration

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

       o   DLEP_MESSAGE

26.4

29.4  DLEP Order Registration

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

       o   Attached Peer Discovery Message
       o   Detached Peer Discovery Message
       o   Peer Offer Message
       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 the guidelines for
   'Message-Type-Specific TLV' registration as specified in section
   6.2.1 of [RFC5444].

26.5

29.5  DLEP Sub-TLV Type Registrations

   A new repository for DLEP Sub-TLVs must be created. Valid Sub-TLVs 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
       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.

27.

30. Appendix A.

Peer Level Message Flows

*Modem Device (Client) Restarts Discovery

   Router

   Server                    Client   Message Description
   ====================================================================

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

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

                                      Modem

                                      Client accepts failure, restarts
                                      discovery process.

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

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

                                      Discovery completed.

*Modem Device Detects Peer Offer Timeout

   Router

   Server                    Client   Message Description
   ====================================================================

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

                                      Modem

                                      Client guard timer expires.
                                      Modem
                                      Client restarts discovery process.

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

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

                                      Discovery completed.

*Router

*Server Peer Offer Lost

   Router

   Server                    Client   Message Description
   ====================================================================

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

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

                                      Modem

                                      Client times out on Peer Offer,
                                      restarts discovery process.

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

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

                                      Discovery completed.

*Discovery Success

   Router

   Server                    Client   Message Description
   ====================================================================

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

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

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

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

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

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

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

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

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

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

*Router

*Server Detects a Heartbeat timeout

   Router

   Server                    Client   Message Description
   ====================================================================

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

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

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

           ~ ~ ~ ~ ~ ~ ~

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

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

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

                                      Modem

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

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

*Modem

*Client Detects a Heartbeat timeout

   Router

   Server                    Client   Message Description
   ====================================================================

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

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

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

           ~ ~ ~ ~ ~ ~ ~

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

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

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

                                      Router

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

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

*Peer Terminate (from Modem) Client) Lost

   Router

   Server                    Client   Message Description
   ====================================================================

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

                                      Router

                                      Server Heartbeat times out,
                                      terminates association.

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

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

*Peer Terminate (from router) server) Lost

   Router

   Server                    Client   Message Description
   ====================================================================

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

                                      Modem

                                      Client HB times out,
                                      terminates association.

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

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

Neighbor Level Message Flows

*Modem

*Client Neighbor Up Lost

   Router

   Server                    Client   Message Description
   ====================================================================

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

                                      Modem

                                      Client timesout on ACK

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

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

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

*Router

*Server Detects Duplicate Neighbor Ups

   Router

   Server                    Client   Message Description
   ====================================================================

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

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

                                      Modem

                                      Client timesout on ACK

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

                                      Router

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

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

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

*Neighbor Up, No Layer 3 Addresses

   Router

   Server                    Client    Message Description
   ====================================================================

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

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

                                      Router

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

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

*Neighbor Up with IPv4, No IPv6

   Router

   Server                    Client   Message Description
   ====================================================================

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

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

                                      Router

                                      Server drives ND for IPv6 if
                                      defined.

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

*Neighbor Up with IPv4 and IPv6

   Router

   Server                    Client   Message Description
   ====================================================================

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

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

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

*Neighbor Session Success

   Router

   Server                    Client   Message Description
   ====================================================================

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

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

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

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

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

                                       Modem     Client

                                       Client initiates the terminate

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

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

                                       or

                                       Router

                                       Server initiates the terminate

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

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

Acknowledgements

   The authors would like to acknowledge the influence and contributions
   of Chris Olsen and Olsen, Teco Boot. Boot, Subir Das, Jaewon Kang, Vikram Kaul, Rick
   Taylor, and John Dowdell.

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
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   NetApp
   7301 Kit Creek Road, Building 2
   Research Triangle Park, NC 27709
   USA
   Email: sjury@cisco.com shawn.jury@netapp.com

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