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

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

Abstract

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

Status of this Memo

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

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

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

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

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

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

Copyright Notice

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

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

Table of Contents

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

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

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

   |-----Local Neighbor-----|          |-----Remote Neighbor----| packets.

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

                          Figure 1: DLEP Network

   In Figure 1, when a the local client (Modem device) modem detects the presence of a remote neighbor,
   node, it (the local modem) sends an indication a signal to its
   local router via the DLEP session.
   protocol. Upon receipt of the indication, signal, the local router would may take appropriate
   whatever action (e.g. initiation
   of it deems appropriate, such as initiating discovery or
   protocols, and/or issuing HELLO protocols) messages to converge the network. After
   notification of the new neighbor, On
   a continuing, as-needed basis, the modem device utilizes the devices utilize DLEP session to
   report the any characteristics of the link (bandwidth, latency, etc) to the router on an as-needed basis. that
   have changed. DLEP is independent of the underlying link type and topology. topology
   supported by the modem.

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

            +--------+                     +--------+
       +------+
       +----+ Modem A|                     | Modem A+-----+ A+---+
       |    | Device |  <===== // ======>  | Device |   |
       |    +--------+      P-t-P      P-2-P Link     +--------+   |
       |                       Protocol                      |
   +---+----+                                       +---+----+
   | Router |                                       | Router |
   |        |                                       |        |
   +---+----+                                       +---+----+
       |                                                     +
       |     +--------+                     +--------+  |
       +------+
       +-----+ Modem B|                     | Modem B|  |
             | Device |   o o o o o o o o   | Device +-----+ +--+
             +--------+    o  Shared   o    +--------+
                            o Medium  o
                             o       o
                              o     o
                               o   o
                                 o
                            +--------+
                            | Modem B|
                            | Device |
                            +---+----+
                                |
                                |
                            +---+----+
                            | Router |
                            |        |
                            +--------+

            Figure 2: DLEP Network with Multiple Modem Devices

   DLEP exists as defines a collection set of type-length-value (TLV) based messages
   using [RFC5444] formatting. The protocol can be logical signals used for both Ethernet
   attached by modems (utilizing, and their
   attached routers. The signals are used to communicate events that
   occur on the physical link(s) managed by the modem: for example, a UDP socket for transport
   of
   remote node entering or leaving the RFC 5444 packets), network, or in environments where that the modem link has
   changed. Associated with these signals are a set of data items -
   information that describes the remote node (e.g., address
   information), and/or the characteristics of the link to the remote
   node.

   The protocol is an
   interface card in defined as a chassis (via collection of type-length-value (TLV)
   based messages, specifying the signals that are exchanged between a message passing scheme).
   router and a modem, and the data items associated with the signal.
   This document specifies transport of DLEP
   utilizes signals and data items via
   the UDP transport. Other transports for the protocol are possible,
   but are outside the scope of this document.

   DLEP signals are further defined as mandatory or optional. Signals
   will additionally have mandatory and optional data items.
   Implementations MUST support all mandatory signals and their
   mandatory data items to be considered compliant. Implementations MAY
   also support some, or all, of the optional signals and data items.

   DLEP uses a session session-oriented paradigm between the modem device and
   its associated router. If multiple modem devices are attached to a
   router (as in FIgure Figure 2), a separate DLEP session MUST exist for each
   modem. If a modem device supports multiple connections to a router
   (via multiple logical or physical interfaces), or supports
   connections to multiple routers, a separate DLEP session MUST exist
   for each connection. This router/modem session provides a carrier for
   information exchange concerning neighbors (remote nodes) that are
   accessible via the modem device. As such, all of the neighbor-level
   exchanges in DLEP can be envisioned as building an information base
   concerning the remote nodes, and the link characteristics to those
   nodes.

   Multicast traffic is handled in IP networks by deriving a Layer 2 MAC
   address based on the Layer 3 address. Leveraging on this scheme,
   Multicast traffic is supported in DLEP simply by treating the derived
   MAC address as any other destination in the network. To support these
   logical destinations, one of the DLEP participants (typically, the
   router) informs the other as to the existence of the logical
   neighbor. The modem, once it is aware of the existence of this
   logical neighbor, reports link characteristics just as it would for
   any other destination in the network. The specific algorithms a modem
   would use to report metrics on multicast (or logical) destinations is
   outside the scope of this specification, and is left to specific
   implementations to decide.

1.1  Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 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

   Routers and a
   passive-listener scheme. Borrowing from existing terminology, this
   document refers to the first-speaker modems that exist as part of the 'client', and the passive
   listener as same node (e.g., that
   are locally connected) can utilize a discovery technique to locate
   each other, thus avoiding a-priori configuration. Either entity (the
   router or the 'server', even though there is no client/server
   relationship in modem) can initiate the classic sense. discovery process. In cases
   where both entities initiate discovery, a typical deployment, a race condition can occur.
   When this race condition occurs, the router
   would appear as MUST cease its active
   discovery, and respond to the modem's request.

   DLEP 'server', utilizes a session-oriented paradigm. A router and an attached modem device would
   act as form a
   session by completing the 'client' (e.g. discovery process. This router-modem
   session persists unless or until it either (1) times out, based on
   the initiator for discovery). timeout values supplied, or (2) is explicitly torn down by one of
   the participants. Note that use of timers in DLEP is OPTIONAL; that
   is, implementations can choose to run with no timers (or effectively,
   timers set to an infinite value).

   DLEP assumes that participating clients appear to the server modems, and their physical links, act
   as a transparent bridge - specifically, bridge. Specifically, the assumption is that the
   destination MAC address for data traffic in any frame emitted by the server
   router should be the MAC address of a device in the next-hop router or end-
   device, and not the MAC address of any of the intervening clients. remote node. DLEP
   also 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 MAC addresses are transmitted unique within the context of the peer
   router-modem session.

   The other type of DLEP session is referred

   This document refers to a remote node as a 'neighbor session'.
   Neighbor sessions "Neighbor". Neighbors can
   be instantiated identified by either the DLEP server router or
   client, the modem, and represent an identifiable a
   specific destination (i.e. (e.g., an address)
   within that exists on the network. link(s)
   managed by the modem. Examples of a destination would be include a unicast
   address (for either MAC
   address, a next-hop router, or for an end-station), unicast Layer 3 address, or a multicast Layer 3 address. A
   As "neighbors" are discovered, DLEP routers and modems build an
   information base on destinations accessible via the modem. Changes in
   link characteristics MAY then be reported as being "modem-wide"
   (effecting ALL neighbors accessed via the modem) or MAY be neighbor session MUST exist
   (destination) specific.

   The DLEP signals concerning neighbors thus become the way for every
   destination that exists in routers
   and modems to maintain, and notify each other about, an information
   base representing the network. physical and logical (e.g., multicast)
   destinations accessible via the modem device. The optional [RFC5444] message header Sequence Number MUST be
   included in all information base
   would contain addressing information (e.g., MAC address, and
   OPTIONALLY, Layer 3 addresses), link characteristics (metrics), and
   OPTIONALLY, flow control information (credits).

   DLEP packets. 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 (e.g., by using a transport such
   as DTLS [DTLS]).

   Sequence Numbers for DLEP messages start at 1 0 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. 0. Sequence Numbers are unique
   within the context of a DLEP session. Sequence numbers are used in
   DLEP to correlate a response to a request.

   This document specifies an implementation of the DLEP signals and
   data items running over the UDP transport, utilizing a well-known UDP
   Port number. It is assumed that DLEP running over other transport
   mechanisms would be documented separately.

3. Credits

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

   If credits are used, they MUST be granted by the receiver on a given
   window - that is, on the "Client "Modem Receive Window" (CRW), (MRW), the DLEP client modem is
   responsible for granting credits to the server, router, allowing it (the server)
   router) to send data to the client. modem. Likewise, the DLEP server router is
   responsible for granting credits on the SRW, RRW, which allows the client modem
   to send data to the server. router.

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

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

4. Metrics

   DLEP includes the ability for the client router and server modem to communicate
   metrics that reflect the characteristics (e.g. bandwidth, latency) of
   the variable-quality link in use. As mentioned in the introduction
   section of this document, metrics have to be used within a context -
   for example, metrics to a unicast address in the network. DLEP allows
   for metrics to be sent within two contexts - metrics for a specific
   neighbor session context (those for a given destination within the network), and peer session context
   "modem-wide" (those that apply to all destinations accessed via the DLEP client).
   modem). Metrics supplied on DLEP Peer messages signals are, by definition, in the context
   of a peer session;
   modem-wide; metrics supplied on Neighbor messages signals are, by definition,
   used in for the context of a specific neighbor session.

   Supplying metrics in a peer session context gives clients the
   ability to supply default metrics on a 'device-wide' basis. only.

   It is left to implementations to choose sensible default values based
   on their specific characteristics. Additionally, the metrics this mechanism
   (either at a peer modem-wide or specific neighbor session context) MAY be used to
   report non-
   changing, non-changing, or static, metrics. Clients Modems having static link
   metric characteristics SHOULD MAY report metrics only once for a given
   neighbor session (or peer session, once on a modem-wide basis, if all connections via the client
   modem 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 (precedence, etc) 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 implementations of both
   signals and sub-TLVs. data items.

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

   The intent of the optional signals and data items, as well as the
   experimental numbering space space, is to allow for further development of
   DLEP protocol features and function. Having experimental space
   reserved for both signals and data items gives maximum flexibility
   for extending the protocol as conditions warrant. For example,
   experimental data items could be used by implementations to send
   additional metrics. A combination of experimental signals, and
   associated data items, could be used to implement new flow control
   schemes. If subsequent research and development yields define new features with sufficient applicability, those features
   and function, then it should be standardized either included in as an update of to
   this specification, document, or documented in
   a standalone as an additional stand-alone specification.

6. Normal Session Flow

   A session between

   At the start of a client run, DLEP implementations (both router and modem)
   initialize the communications path. In a server is established by exchanging UDP implementation, this
   includes opening a socket and binding to the well-known port address
   (TBD). Once the communications path is established, an implementation
   would either, depending on configuration, proceed to periodically
   issue a "Peer Discovery" and "Peer Offer" messages described below. message. The flows described in this document create Peer Discovery MAY be sent
   either via the multicast address allocated for DLEP (TBD), or via a state-full protocol
   between client and server.
   unicast address, or drop into a "passive receive" mode, waiting on
   receipt of a Peer Discovery.

   Both client modem and server router initialize in a "discovery" state, and state. Either the
   modem, the client issues router, or both, will then issue a "Peer Discovery" message.
   When
   signal. The Peer Discovery signal MAY be issued to a unicast address
   (if a-priori knowledge of the server receives address exists), or to the multicast
   address TBD.

   The receiver of a Peer Discovery, it Discovery message responds with a "Peer Offer" message, and enters an "in session" state with
   signal to indicate readiness to participate in the client.
   Receipt DLEP session. The
   receiver of the a Peer Offer at message responds with a "Peer Offer ACK"
   message, completing discovery. While the client causes it (the client) Peer Discovery message MAY
   be sent to the DLEP multicast address (TBD), the Peer Offer, and all
   subsequent traffic, is sent to the unicast address that originated
   the Peer Discovery. Once the Peer Offer signal is acknowledged, both
   participants (router and modem) transition into to the "in session" state.

   Once that exchange has successfully occurred, messages transferred
   in state,
   creating a logical, stateful session between the modem and the
   router. Subsequent DLEP signals are then processed within the context
   of this router/modem session. DLEP partners use these signals to
   build their respective information bases regarding destinations that
   are accessible via the modem, and link characteristics associated
   with those destinations.

   The "in session" state created by the discovery signals is maintained
   until one of the peer following conditions occur:

   o  The session will consist of is explicitly terminated (using Peer Termination), or
   o  Periodic 'Heartbeat' messages,  The session times out, based on supplied timeout values.

   In order to maintain the session between router and modem, OPTIONAL
   periodic "Heartbeat" messages MAY be exchanged. These messages are
   intended to keep the peer session alive, and to verify bidirectional connectivity, and/or
   o
   connectivity between the two participants. DLEP also provides for an
   OPTIONAL Peer Update messages, indicating message, intended to communicate some change in
   status that one (e.g., a change of the peers needs to communicate to the other. layer 3 address parameters, or a modem-wide
   link change).

   In addition to the messages above, the peers participants will transmit
   DLEP messages concerning destinations in the network. These messages
   trigger creation/maintenance/termination creation/maintenance/deletion of "neighbors" in the
   information base of 'neighbor sessions'. the recipient. For example, a peer modem will inform
   its DLEP partner attached router of the presence of a new destination via the
   "Neighbor Up" message. signal. Receipt of a Neighbor Up causes the receiving peer router to
   allocate the necessary resources, creating a neighbor session, and transition to an "in session" state
   on entry in the newly created neighbor session. The in-session state persists
   until notification
   information base with the specifics (e.g., MAC Address, Latency, Data
   Rate, etc) of neighbor loss is received, or by optional
   timeout due to inactivity. the neighbor. The loss of a destination is communicated
   via the "Neighbor Down"
   message, signal, and changes in status to the
   destination (e.g. varying link quality, or addressing changes) are
   communicated via a the "Neighbor Update" message. signal. The information on a
   given neighbor will persist in the router's information base until
   (1) a "Neighbor Down" is received, indicating that the modem has lost
   contact with the remote node, or (2) the router/modem session
   terminates, indicating that the router has lost contact with its own
   local modem.

   Again, metrics can be expressed within the context of a specific
   neighbor
   session via the Neighbor Update message, or within the context of
   a peer session (reflecting the link as on a whole) modem-wide basis
   via the Peer Update message. In cases where metrics are provided on
   the peer router/modem session, the
   receiving peer receiver MUST propagate the metrics to
   all neighbor sessions neighbors in its information base that are accessed via the peer.
   originator. A DLEP peer participant MAY send metrics both in a peer
   router/modem session context (via the Peer Update message) and a
   specific 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 an
   OPTIONAL signal allowing a server router to request a different amount of
   bandwidth, or latency, from the client via modem. This signal is referred to as
   the Link Characteristics Message.
   This allows Message, and gives the router the server ability 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]. Mandatory Signals and Data Items

   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 signals are
                            constructed.

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

   Packet Sequence Number - If present, considered core to 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 specification;
   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 support these signals, and the message. For DLEP, this field
                            contains DLEP_MESSAGE (value TBD)

   Message Flags          - Set associated data
   items, in order to 0x1 (bit 3, mhasseqnum bit is
                            set). be considered compliant:

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

         Peer Offer                    Identification

         Peer Offer ACK                Status

         Peer Termination              Identification

         Peer Termination ACK          Status

         Neighbor Up                   Identification
                                       MAC Address
                                       Maximum Data Rate
                                       Current Data Rate
                                       Latency
                                       Resources
                                       Relative Link Quality

         Neighbor Update               Identification
                                       MAC Address
                                       Maximum Data Rate
                                       Current Data Rate
                                       Latency
                                       Resources
                                       Relative Link Quality

         Neighbor Down                 Identification
                                       MAC Address

   All other bits are unused DLEP signals and MUST
                            be set data items are OPTIONAL. Implementations
   MAY choose to '0'.

   Message Address Length - A 4-bit unsigned integer field encoding the
                            length of all addresses included in this
                            message. DLEP implementations provide them. Implementations that do not use
                            this field; contents support
   optional signals and data items 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 parse, and silently drop, all
   unsupported signals and/or data items.

8. Generic DLEP Packet Definition

   The Generic DLEP protocol is organized as a set Packet consists of orders, each with a
   collection sequence of Sub-TLVs. TLVs. The Sub-TLVs carry information needed
   to process and/or establish context (e.g. first TLV
   represents the MAC address of signal being communicated (e.g., a
   far-end router), and the 'tlv-type' field in "Neighbor Up", or a
   "Peer Offer"). Subsequent TLVs contain the message TLV
   block carries data items pertinent to
   the DLEP order itself. signal (e.g., Maximum Data Rate, or Latency, etc).

   The Generic 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 Packet Definition 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             |
   |Signal TLV Type | TLV Flags     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Length        |       Value... DLEP data items...           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLVs Length

      Signal               - A 16-bit unsigned integer field that contains the total
                 number of octets in all One of the immediately following
                 TLV elements (tlvs-length not included). DLEP Signal 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 values
                             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 The length of the TLV

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

      DLEP action
                 specified data items      - One or more data items, encoded in the TLV type field.

10. TLVs,
                             as defined in this document.

9. DLEP sub-TLVs Data Items

   As mentioned earlier, 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 as a DLEP order, encoded in the 'tlv-type'
   field in the message TLV block, with the 'value' field
   collection of the TLVs. The first TLV
   block containing present in a collection (1 or more) DLEP sub-TLVs.

   The format message MUST be
   one of DLEP Sub-TLVs is consistent with RFC 5444 in that the
   Sub-TLVs contain a flag field Signal TLVs, documented in addition section [INSERT REFERENCE
   HERE]. The signals are followed by one or more data items, indicating
   the specific changes that need to be instantiated in the type, length, and
   value fields. receiver's
   information base.

   Valid DLEP Sub-TLVs Data Items 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 (EFT)
          TBD      Relative Link Quality (RLQ) sub-TLV
          TBD      Status sub-TLV
          TBD      Heartbeat Interval sub-TLV
          TBD      Heartbeat Threshold sub-TLV Interval/Threshold
          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 data item TLVs contain the following fields:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  TLV 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'. data
                 item being sent.

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

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

10.1 data item.

9.1  Identification Sub-TLV

   This Sub-TLV data item MUST exist in the TLV Block for all DLEP messages, and MUST be the first Sub-TLV
   data item of the message. message (e.g., it MUST immediately follow the signal
   TLV). Further, there MUST be ONLY one Identification Sub-TLV data item in an RFC 5444 message TLV block. a
   DLEP message. The
   Identification sub-TLV data item contains client and server identification information used
   to establish the proper context (e.g., the router/modem session) for
   processing DLEP protocol messages.

   The Identification sub-TLV contains format of the following fields: Identification Data Item is:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV Type = TBD |TLV Flags=0x10 |Length  | Length = 8     | Server         Router ID           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Server            Router ID            | Client         Modem ID            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Client            Modem 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

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

   Client

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

   When the client initiates discovery (via the

   During transmission of a DLEP Peer Discovery message),
   it signal, the transmitter
   MUST set the Client its ID to a 32-bit quantity that will be used to uniquely
   identify this session from the client-side. transmitter's perspective. The client other
   ID value MUST be set the Server ID to '0'. When responding to the Peer
   Discovery
   message, signal (via the Peer Offer signal), the server transmitter MUST
   echo the Client ID, any received ID value, and MUST supply its own unique 32-bit
   quantity to identify the session from the server's its perspective. After the Peer
   Discovery/Peer Offer exchange, both the
   Client ID and the Server ID subsequent signals on this DLEP
   session MUST be set to contain the ID values obtained from the Peer DIscovery/Peer
   Discovery/Peer Offer sequence.

10.2

9.2  DLEP Version Sub-TLV

   The DLEP Version Sub-TLV TLV is an OPTIONAL TLV in both the Peer Discovery
   and Peer Offer messages. The Version Sub-TLV TLV is used to indicate the client or server
   version of the protocol. The client
   and server protocol running in the originator. A participant MAY
   use this information to decide if the peer potential session partner is
   running at a supported level.

   The DLEP Version Sub-TLV 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       |         Major Version         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Major Version |       Minor Version           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   Major Version - Major version of the client modem or router protocol.

   Minor Version - Minor version of the client modem or router protocol.

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

10.3 1.3).

9.3  Peer Type

   The Peer Type Sub-TLV TLV is an OPTIONAL TLV in both the Peer Discovery and
   Peer Offer messages. The Peer Type Sub-TLV TLV is used by the server router and client
   modem to give additional information as to its type. It is an OPTIONAL sub-TLV in
   both the Peer Discovery Message and the Peer Offer message. The peer type is
   a string and is envisioned to be used for informational purposes
   (e.g. as output in a display command).

   The Peer Type sub-TLV 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  | String               |
  |               |type string len|Max Len = 80                   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type         - TBD

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

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

   Peer Type String - Non-Null terminated peer type string, maximum length of 80 bytes.
                      octets. For example, a satellite modem might set
                      this variable to 'Satellite terminal'.

10.4

9.4  MAC Address Sub-TLV

   The MAC address Sub-TLV TLV MUST appear in all neighbor-oriented
   messages signals
   (e.g. Neighbor Up, Neighbor Up ACK, Neighbor Down, Neighbor Down ACK,
   Neighbor Update, Link Characteristics Request, and Link
   Characteristics ACK). The MAC Address sub-TLV TLV contains the address of the far-end (neighbor) destination, and may
   destination on the remote node. The MAC address MAY be either a
   physical or a virtual destination. Examples of a virtual destination
   would be a multicast MAC address, or the broadcast MAC
   (0xFFFFFFFFFFFF).

   The MAC 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 = 6     |MAC Address    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |          MAC Address          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      MAC Address                              |
  +-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type    - TBD

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

   Length      - 6

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

10.5

9.5  IPv4 Address Sub-TLV

   The IPv4 Address Sub-TLV TLV is an OPTIONAL TLV. If supported, it MAY be used appear
   in Neighbor Up, Neighbor Update, and Peer Update Messages, if the client is aware of the
   Layer 3 address. messages. When
   included in Neighbor messages, the IPv4 Address sub-TLV TLV contains the IPv4
   address of the far-end neighbor. neighbor, as well as a subnet mask value. In the Peer
   Update message, it contains the IPv4 address of the
   sending peer. originator of the
   message. In either case, the sub-TLV 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 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 6     |   Add/Drop    | IPv4 Address  |
  |               |               |   Indicator   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            IPv4 Address                       |  Subnet Mask  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type     - TBD

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

   Length       - 5 6

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

   IPv4 Address - The IPv4 Address address of the far-end neighbor or peer.

10.6

   Subnet Mask  - A subnet mask (0-32) to be applied to the IPv4
                  address.

9.6  IPv6 Address Sub-TLV

   The IPv6 Address Sub-TLV TLV is an OPTIONAL TLV. If supported, it MAY be used
   in the Neighbor Up, Neighbor Update, Peer Discovery, and Peer Update Messages, if the client is aware of the
   Layer 3 address.
   Messages. When included in Neighbor messages, the IPv6
   Address sub-TLV this data item contains
   the IPv6 address of the far-end neighbor. In the Peer Discovery and Peer
   Update, it contains the IPv6 address of the originating peer. In
   either case, the sub-TLV data item also contains an indication of whether
   this is a new or existing address, or is a deletion of a previously
   known address. address, as well as a subnet mask.

   The IPv6 Address sub-TLV 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 18    |   Add/Drop    | IPv6 Address  |
   |               |               |   Indicator   |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        IPv6 Address                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        IPv6 Address                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        IPv6 Address                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                IPv6 Address                   | Subnet Mask   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type     - TBD

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

   Length       - 17 18

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

   IPv6 Address - IPv6 Address of the far-end neighbor or peer.

10.7

   Subnet Mask  - A subnet mask value (0-128) to be applied to the Ipv6
                  address.

9.7  Maximum Data Rate Sub-TLV

   The Maximum Data Rate (MDR) Sub-TLV TLV is used in Neighbor Up, Neighbor
   Update, Peer Discovery, Peer Update, and Link Characteristics ACK
   Messages to indicate the maximum theoretical data rate, in bits per
   second, that can be achieved on the link. When metrics are reported
   via the messages listed above, the maximum data rate MUST be
   reported.

   The 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 = 8     |          MDR (bps)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        MDR (bps)                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           MDR (bps)           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type          -  TBD

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

   Length            -  8

   Maximum Data Rate -  A 64-bit unsigned number, representing the
                        maximum theoretical data rate, in bits per
                        second (bps), that can be achieved on the link.

10.8

9.8  Current Data Rate Sub-TLV

   The Current Data Rate (CDR) Sub-TLV TLV is used in Neighbor Up, 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, the desired data rate for the link. When
   metrics are reported via the messages above, the current data rate
   MUST be reported.

   The Current Data Rate sub-TLV 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)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        CDR (bps)                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        CDR (bps)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type          -  TBD

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

   Length            -  8

   Current Data Rate -  A 64-bit unsigned number, representing the
                        current data rate, in bits per second (bps), second, that is
                        currently be achieved on the link. When reporting metrics (e.g,
                            in Neighbor Up, Neighbor Down, Peer
                            Discovery, Peer Update, link, or the
                        desired data rate in bits per second in the Link
                        Characteristics ACK), if Request message. If there is no
                        distinction between current and maximum data
                        rates, current data rate SHOULD MUST be set equal to
                        the maximum data rate.

10.9

9.9  Expected Forwarding Time Sub-TLV

   The Expected Forwarding Time (EFT) Sub-TLV TLV is is an OPTIONAL data item.
   If supported, it MAY be used in Neighbor Up, Neighbor Update, Peer
   Discovery, and Peer Update messages to indicate the typical latency
   between the arrival of a given packet at the transmitting device and
   the reception of the packet at the other end of the link. EFT
   combines transmission time, idle time, waiting time, freezing time,
   and queuing time to the degree that those values are meaningful to a
   given transmission medium.

   The Expected Forwarding Time sub-TLV 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     |           EFT (ms)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            EFT (ms)           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type    -  TBD

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

   Length      -  4

   Current Data Rate

   EFT         -  A 32-bit unsigned number, representing the expected
                  forwarding time, in milliseconds, on the link.

10.10

9.10  Latency Sub-TLV

   The Latency Sub-TLV TLV is used in Neighbor Up, Neighbor Update, Peer
   Discovery, Peer Update, Link Characteristics Request, and Link
   Characteristics ACK messages to indicate the amount of latency on the
   link, or in the case of the Link Characteristics Request, to indicate
   the maximum latency required (e.g. a should-not-exeed value) on the link.

   The Latency Sub-TLV contains When metrics are reported
   via the following fields: messages above, Latency MUST be reported.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV Type =TBD  |TLV Flags=0x10  |Length = 2     |Latency (ms)     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Latency        Latency (ms)           |
  +-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   TLV Type    -  TBD

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

   Length      -  2

   Latency     -  The  A 16-bit unsigned value, representing 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 as
                  delay, in milliseconds. The calculation of latency is
                  implementation dependent. For example, the latency may
                  be a running average calculated from the internal
                  queuing. If a device cannot calculate latency, it
                            SHOULD MUST
                  be reported as 0. In the Link Characteristics Request
                  Message, this value represents the maximum delay, in
                  milliseconds, expected on the link.

10.11

9.11  Resources Sub-TLV

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

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

   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   -  A percentage, 0-100, representing the amount of
                  remaining resources, such as battery power. If
                  resources cannot be calculated, a value of 100 SHOULD MUST be
                  reported.

10.12

9.12  Relative Link Quality Sub-TLV

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

   The Relative Link Quality sub-TLV 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)  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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 -  A non-dimensional number, 0-100,
                          representing relative link quality. A value of
                          100 represents a link of the highest quality.
                          If the RLQ cannot be calculated, a value of
                          100 SHOULD MUST be reported.

10.13

9.13  Status Sub-TLV

   The Status Sub-TLV TLV is an OPTIONAL TLV. It is sent as part of an
   acknowledgement message, from either the client modem or server the router, to
   indicate the success or failure of a given request request.

   The Status Sub-TLV 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      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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 - 0 = Success Success, Non-zero = Failure. Specific values
                          of a non-
                      zero non-zero termination code depend on the
                          operation requested (e.g. Neighbor Up,
                          Neighbor Down, etc).

10.14

9.14  Heartbeat Interval Sub-TLV Interval/Threshold

   The Heartbeat Interval Sub-TLV Interval/Threshold TLV is an OPTIONAL TLV. If
   supported, it MAY be sent from the client during Peer Discovery to indicate the
   desired Heartbeat timeout window. If included in the modem includes the Heartbeat
   Interval TLV in Peer Discovery, the server router MUST either accept the
   timeout interval, interval supplied by the modem, or reject the Peer Discovery. Failing to
   Peer Discovery messages that do not include the Heartbeat Interval Sub-TLV
   TLV in Peer Discovery indicates a desire to establish the peer-to-peer DLEP
   router/modem session without an activity timeout (e.g. an infinite
   timeout value).

   The Heartbeat Interval Sub-TLV contains If an activity timeout is supported, implementations
   MAY choose to implement heuristics such that signals sent/received
   reset 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     | timer window.

   The 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

   Interval         - 0 = Do NOT use heartbeats on this peer-to-peer
                      session. Non-zero = Interval, in seconds, specify a period (in seconds) for
                      heartbeat messages.

10.15 Heartbeat Threshold Sub-TLV
   Messages (See Section 23). The Heartbeat Threshold Sub-TLV MAY be sent from the client during
   Peer Discovery value is used to indicate
   the desired number of windows, each of time (Heartbeat Interval)
   seconds, to wait before either peer participant declares the peer router/modem
   session lost. In this case, the overall amount of time before a peer session
   router/modem is declared lost is expressed as (Interval * Threshold), where 'Interval' is the Threshold).
   Specifying an Interval value in of 0 indicates the desire to disable
   Heartbeat Interval sub-TLV, documented above. If this sub-TLV is
   included by the client in the Peer Discovery, the client MUST also
   specify messages entirely (e.g., 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 set to an infinite
   value). Setting the
   Heartbeat Interval Sub-TLV is included, but this Sub-TLV Threshold value to 0 is
   omitted, then undefined, and TLVs with
   a threshold Threshold value of '1' is assumed. 0 MUST be rejected by the recipient.

   The Heartbeat Threshold Sub-TLV Interval/Threshold 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     | Interval      |  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

   Threshold

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

   Threshold        - Number of windows, of Heartbeat Interval seconds,
                      to wait before declaring a peer-to-peer session to
                      be lost.

10.16

9.15  Link Characteristics ACK Timer Sub-TLV

   The Link Characteristic Characteristics ACK Timer Sub-TLV TLV is an OPTIONAL TLV. If
   supported, it MAY be sent from the
   client during Peer Discovery to indicate the
   desired number of seconds the server should to wait for a response to a Link
   Characteristics Request. If a router receives this sub-TLV is received TLV from a modem
   during Peer Discovery, the server router MUST either accept the timeout
   value, or reject the Peer Discovery. If this Sub-TLV TLV is omitted,
   implementations supporting the Link Characteristics Request SHOULD
   choose a default value.

   The Link Characteristics ACK Timer Sub-TLV 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     | 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

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

10.17

9.16  Credit Window Status Sub-TLV

   The Credit Window Status Sub-TLV MUST be sent by the DLEP peer
   originating a Neighbor Up message when use of credits TLV is desired
   for a given session. In the Neighbor Up message, when an OPTIONAL TLV. If credits are desired,
   supported by the originating peer MUST set DLEP participants (both the value of router and the
   window it controls (e.g. modem),
   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 TLV MUST
   either reject be sent by the use of credits, via participant
   receiving a Neighbor Up ACK response
   with the correct Credit Grant Request for a given neighbor.

   The Credit Window 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 Credit Window Status Sub-TLV TLV contains the following fields:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |TLV Type =TBD  |TLV Flags=0x10  |Length = 16    | Client Receive|
  |               |               |               | Modem Receive Window value Value    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Client                   Modem Receive Window Value                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Client  Modem Receive Window Value   | Server Receive|
  |                                               | Router Receive Window Value   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Server                Router Receive Window Value                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Server  Router 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                      - 16

   Client

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

   Server

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

10.18

9.17  Credit Grant Sub-TLV Request

   The Credit Grant Request Sub-TLV MAY be TLV is an OPTIONAL TLV. If credits are
   supported, the Credit Grant Request TLV is sent from either a DLEP
   peer
   participant to grant an increment to credits on a window. The Credit
   Grant Sub-TLV TLV is sent as part of a data item in either the Neighbor Up or
   Neighbor Update message. messages. The value in a Credit Grant Sub-TLV TLV represents
   an increment to be added to any existing credits available on the
   window. Upon successful receipt and processing of a Credit Grant Sub-TLV, TLV,
   the
   receiving peer SHOULD receiver MUST respond with a DLEP Neighbor Update message containing a Credit Window
   Status Sub-TLV TLV to report the updated aggregate values for synchronization
   purposes.

   In the Neighbor Up message, when credits are desired, the originating
   peer MUST set the initial credit value of the window it controls
   (e.g. the Modem Receive Window, or Router Receive Window) to an
   initial, non-zero value. If the receiver of a Neighbor Up message
   with a Credit Grant Request TLV supports credits, the receiver MUST
   either reject the use of credits, via a Neighbor Up ACK response with
   the correct Status TLV, or set the initial value from the data
   contained in the Credit Window Status TLV. If the initialization
   completes successfully, the receiver MUST respond to the Neighbor Up
   message with a Neighbor Up ACK message that contains a Credit Window
   Status TLV, initializing its receive window.

   The Credit Grant Sub-TLV 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     |       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           - 0 8

   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 a window, the applicable credit window
                      (either the CRW MRW or the SRW) RRW) is derived from the
                      sender of the grant. The Credit Increment MUST NOT
                      cause the window to overflow; if this condition
                      occurs, implementations MUST set the credit window
                      to the maximum value contained in a 64-bit
                      quantity.

10.19

9.18  Credit Request Sub-TLV

   The Credit Request Sub-TLV TLV is an OPTIONAL TLV. If credits are supported,
   the Credit Request TLV MAY be sent from either DLEP peer, participant, via
   a Neighbor Update order, signal, to indicate the desire for the partner to
   grant additional credits in order for data transfer to proceed on the
   session. If the corresponding Neighbor Up message for this session
   did NOT contain a Credit Window Status Sub-TLV, TLV, indicating that credits
   are to be used on the session, then the Credit Request
   Sub-TLV TLV MUST be rejected, by sending a Neighbor Update ACK containing
   a Status Sub-TLV,
   rejected by the receiving peer. If credits are in use on
   the session, then the receiving peer MAY respond with receiver via a DLEP Neighbor Update message containing a Credit Grant Sub-TLV with
   an increment of credits for the session. ACK message.

   The Credit Request Sub-TLV 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 = 0     | 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       - 0

   Reserved     - 0 = This field is currently unused and MUST be set to 0.

11.

10. 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' messages are encoded as a string of Type-Length-Value (TLV)
   constructs. The first TLV in the a DLEP message header exist, and defines MUST be a set valid DLEP
   signal, as defined in section 11.1 of
   values for this document. The second TLV
   MUST be the 'tlv-type' field Identification data item, defined in section 10.1
   Following those two TLVs are 0 or more TLVs, representing the RFC 5444 TLV block. Therefore, data
   items that are appropriate for the signal. The layout of a DLEP message, starting from the RFC 5444 Message header, would
   appear as follows:
   message is thus:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Msg Type =   |Msg Flg|AddrLen| DLEP Signal   |DLEP Message Size   |Identification |Identification |
   | DLEP_MESSAGE  | 0x1   | 0x0   | Type value    |length (9 +    |TLV Type       |TLV length     |
   | (value TBD)   |       |       |   |optional TLVs) |(TBD)          |(8)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Message Seq Num      | TLV block length (length of   |
  |                               | DLEP order + Sub-TLVs)                            Router ID                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | DLEP Message  |TLV Flags=0x10                            Modem ID                           | Length
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Start of optional DLEP        |
   | Block value   | TLVs...                       |               | Sub-TLVs...   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

11.1  Message Block
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   All DLEP messages (signals) begin with this structure. Therefore, in
   the following descriptions of specific messages, this header
   structure is assumed, and will not be replicated.

10.1  Signal 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 begin with the 'tlv-type' field in Type value of
   the RFC 5444
   message TLV block. appropriate DLEP defines the following Message-Type-
   specific values for the tlv-type field: signal. Valid DLEP signals are:

          TLV      TLV
          Value    Description
          =========================================
          TBD      Attached      Peer Discovery
          TBD      Detached      Peer Discovery Offer
          TBD      Peer Offer ACK
          TBD      Peer Update
          TBD      Peer Update ACK
          TBD      Peer Termination
          TBD      Peer Termination ACK
          TBD      Neighbor Up
          TBD      Neighbor Up ACK
          TBD      Neighbor Down
          TBD      Neighbor Down ACK
          TBD      Neighbor Update
          TBD      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.

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

12.1  Attached

11. Peer Discovery Message

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

   Note that metric Sub-TLVs data items MAY be supplied with the Peer Discovery
   order. If Discovery,
   in order to populate default metric Sub-TLVs values, or to indicate a static,
   modem-wide environment. If metrics are supplied, they supplied with the Peer
   Discovery message, these metrics MUST be used as a
   default value the initial values
   for all neighbor sessions neighbors 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-TLVs      |
  | Peer Discovery|               | opt sub-TLVs  | as noted below|
  | (Value TDB)   |               |               |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message modem.

   Given the packet format described in section 11, the initial TLV Type                    - DLEP_MESSAGE (value TBD)

   Message Flags                   - Set to 0x1 (bit 3, mhasseqnum
                                     bit
   value 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 16-bit unsigned integer field
                                     containing a sequence number
                                     generated by DLEP_PEER_DISCOVERY (value TBD). Mandatory TLVs are
   then placed into the message
                                     originator.

   TLV Block packet:

   Mandatory Data Item TLVs:
            - TLVs Length: 14 + size of optional
                                                  sub-TLVs.

   Sub-TLVs: Identification (MANDATORY)

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

   Optional Data Item TLVs:
            - DLEP Version (OPTIONAL)
            - DLEP Peer Type (OPTIONAL)
            - Heartbeat Interval (OPTIONAL)
            - Heartbeat Threshold (OPTIONAL)
            - Link Characteristics ACK Timer
                                                 (OPTIONAL)
            - Maximum Data Rate (OPTIONAL)
            - Current Data Rate (OPTIONAL)
            - Latency (OPTIONAL)
            - Expected Forwarding Time (OPTIONAL)
            - Resources (OPTIONAL)
            - Relative Link Quality (OPTIONAL)

12.2  Detached

12. Peer Discovery Offer Message
   The Detached Peer Discovery Offer Message is sent by a detached client
   proxy DLEP participant in response to a server to begin
   Peer Discovery Message. Upon receipt, and successful processing, of 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 message, the Detached Peer Discovery Message has timed out. When
   a DLEP implementation responds to a Detached Discovery Message recipient MUST respond with a Peer Offer, Offer ACK
   message, completing the implementation MUST discovery phase of DLEP. Both DLEP
   participants (router and modem) would then enter an "in session" state
   with the peer.
   state. Any subsequent discovery message Discovery messages sent or received from on this
   session MUST be considered an error, and the
   peer session MUST be processed
   terminated as if a Peer Termination Message had been
   received (e.g. the existing peer session received.

   The Peer Offer message MUST be terminated). An
   implementation MAY then process sent to the unicast address of the
   originator of Peer Discovery, regardless of whether the received discovery message.

   If metric sub-TLVs (e.g. Maximum Data Rate) are supplied with was
   received on the
   Detached DLEP multicast address (TBD) or on a unicast
   address.

   To construct a Peer Discovery Offer message, these metrics MUST be used as the initial values for all far-end sessions (neighbors) established via
   the peer. TLV type value is set
   to DLEP_PEER_OFFER (value TBD). The Detached Peer Discovery Message contains Identification data item TLV is
   placed in 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 |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | packet next, followed by any OPTIONAL Data Item TLVs
   the implementation supports:

   Optional Data Item TLVs:

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

   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 IPv4 Address Length        - 0x0

   Message Size
              - 22 + size of optional
                                   sub-TLVs

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

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

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

   As in the Attached Peer Discovery, 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 ACK Message

   The Peer Offer Message is sent by a server to a client in response
   to ACK message acknowledges receipt of a Peer Discovery Message. The Peer Offer Message is the response
   to either of the Peer Discovery messages (Attached or Detached),
   message, and completes the DLEP peer router/modem session establishment. Upon sending the establishment for
   DLEP. The Peer Offer Message, the server then enters an "in session" state
   with the client. From ACK message MUST be sent to unicast address of
   the client perspective, receipt and successful
   parsing originator of a Peer Offer order MUST cause message. The Peer Offer ACK message
   MAY contain an OPTIONAL Status data item, indicating success or
   failure of the client attempt to enter establish a router/modem session. For
   implementations that do NOT support the "in
   session" state. Any subsequent Discovery messages sent or received
   on Status data item (defined in
   section 10.13 of this session document), the Peer Offer ACK message MUST be considered an error, and the
   used ONLY to indicate successful session establishment; Peer Offer
   messages that are rejected MUST be
   terminated as if a silently dropped, allowing the
   Peer Termination Message had been received.

   The Offer to time out.

   To construct a Peer Offer Message contains ACK message, the following fields:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Msg Type =   |Msg Flg|AddrLen|          Message Size         |
  | DLEP_MESSAGE  | 0x1   | 0x0   |        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-TLVs as   |
  | (Value TBD)   |               | opt sub-TLVs  | indicated     |
  |               |               |               | below         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Type            - DLEP_MESSAGE (Value TBD)

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

   Message Address Length  - 0x0

   Message Size            - 22 + size of optional sub-TLVs

   Message Sequence Number - A 16-bit unsigned integer field containing
                             a sequence number, generated by DLEP_PEER_OFFER_ACK (value TBD). Mandatory data item TLV's are
   placed into the message
                             originator.

   TLV Block packet next:

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

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

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

14. Peer Update Message

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

   With router(s).

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

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

   The Peer Update Message contains information base
   associated with 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 router/modem session.

   To construct a Peer     |TLV Flags=0x10 | Length = 11 + | Sub-TLVs as   |
  | Update        |               | opt sub-TLVs  | noted below   |
  | (Value TDB)   |               |               |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Message Type             - DLEP_MESSAGE (Value TBD)

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

   Message Address Length   - 0x0

   Message Size             - 22 + optional Sub-TLVs

   Message Sequence Number  - A 16-bit unsigned integer containing a
                              sequence number (generated by originator). DLEP_PEER_UPDATE (value TBD). The Identification data item TLV Block is
   placed in the packet next, followed by any OPTIONAL Data Item TLVs.

   Optional Data Item TLVs:

              - TLV Length:  14 + length of optional
                                           sub-TLVs.
   Sub TLVs
                              Identification (MANDATORY) IPv4 Address (OPTIONAL)
              - IPv6 Address (OPTIONAL)
              - Maximum Data Rate (OPTIONAL)
              - Current Data Rate (OPTIONAL)
              - Latency (OPTIONAL)
              - Expected Forwarding Time (OPTIONAL)
              - Resources (OPTIONAL)
              - Relative Link Quality (OPTIONAL)

15. Peer Update ACK Message

   A peer sends the

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

   The

   To construct a Peer Update ACK message contains message, the following fields:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Msg Type =   |Msg Flg|AddrLen|          Message Size         |
  | DLEP_MESSAGE  | 0x1   | 0x0   |        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-TLVs as   |
  | Update ACK    |               | opt sub-TLVs  | noted below   |
  | (Value TDB)   |               |               |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Type             - DLEP_MESSAGE (Value TBD)

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

   Message Address Length   - 0x0
   Message Size             - 22 + size of optional sub-TLVs.

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

   TLV Block
   implementation supports:

   Optional Data Item TLVs:

             - TLV Length:  14 + optional sub-TLVs

   Sub TLVs
                              Identification (MANDATORY) Status (OPTIONAL)

16. Peer Termination Message

   The Peer Termination Message is sent by either the client or the
   server when a DLEP participant when the
   router/modem session needs to be terminated. Transmission of Implementations
   receiving a Peer Termination message MUST send a Peer Termination ACK
   message is required to confirm the termination process. The sender of the a Peer
   Termination message is free to define its heuristics in event of a
   timeout. The receiver of a Peer Termination Message MUST terminate release all
   neighbor sessions
   resources allocated for the router/modem session, and release associated resources. State MUST eliminate
   all neighbors in the information base accessible via the router/modem
   pair represented by the session. Router and modem state machines are
   returned to the "discovery" state. No Neighbor Down messages are
   sent.

   The

   To construct a Peer Termination Message contains message, the following fields:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Msg Type =   |Msg Flg|AddrLen|          Message Size         |
  | DLEP_MESSAGE  | 0x1   | 0x0   |        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-TLVs as   |
  | Termination   |               | opt sub-TLVs  | noted below   |
  | (Value TDB)   |               |               |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Type                  - DLEP_MESSAGE (Value TBD)

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

   Message Address Length        - 0x0

   Message Size                  - 22 + size of optional sub-TLVs.

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

   TLV Block implementation supports:

   Optional Data Item TLVs:

             - TLV Length = 14 + optional sub-TLVs

   Sub TLVs
                                   Identification (MANDATORY) Status (OPTIONAL)

17. Peer Termination ACK Message

   The Peer Termination Message ACK is sent by a DLEP peer in response
   to a received Peer Termination order.

   The Receipt of a Peer Termination
   ACK Message contains message completes 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 teardown of opt       |
  | (value TBD)   |       |       |            sub-TLVs           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      |TLVs Length =14 + opt sub-TLVs |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | DLEP the router/modem session.

   To construct a Peer Term|TLV Flags=0x10 | Length = 11 + | Sub-TLVs as   |
  | Termination ACK           |               | opt sub-TLVs  | noted below   |
  | (Value TBD)   |               |               |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Type                  - DLEP_MESSAGE (Value TBD)

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

   Message Address Length        - 0x0

   Message Size                  - 22 + optional sub-TLVs.

   Message Sequence Number       - A 16-bit unsigned integer field
                                   containing the sequence number DLEP_PEER_TERMINATION_ACK (value TBD). The
   Identification data item TLV is placed in the corresponding Peer Termination
                                   Message being acknowledged.

   TLV Block packet next, followed
   by any OPTIONAL TLVs the implementation supports:

   Optional Data Item TLVs:

             - TLV Length = 14 + optional Sub-TLVs

   Sub-TLVs
                                   Identification (MANDATORY) Status (OPTIONAL)

18. Neighbor Up Message

   A peer DLEP participant sends the Neighbor Up message to report that a new
   potential routing neighbor, or a new
   destination within the
   network, has been detected. A Neighbor Up ACK Message is required
   to confirm a received Neighbor Up. A Neighbor Up message can be sent
   either by a client the modem, to signal indicate that it (the client) has detected a new
   neighbor, remote node has been
   detected, or by the server router, to indicate that the presence of a new destinations
   (e.g. logical
   destination (e.g., a Multicast groups) exist within group) exists in 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 add knowledge
   of the far-end
   destination, and send an acknowledgement new destination to its information base, indicating that the originating peer.

   The Neighbor Up Message contains
   destination is accessible via the following fields:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Msg Type =   |Msg Flg|AddrLen|          Message Size         |
  | DLEP_MESSAGE  | 0x1   | 0x0   |        31 + size of opt       |
  | (value TBD)   |       |       |            sub-TLVs           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      |TLVs Length =23 + opt sub-TLVs |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | DLEP modem/router pair.

   To construct a Neighbor |TLV Flags=0x10 | Length =20 +  | Sub-TLVs as   |
  | Up (TBD)      |               | opt sub-TLVs  | noted below   |
  |               |               |               |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Type             - DLEP_MESSAGE (Value TBD)

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

   Message Address Length   - 0x0

   Message Size             - 31 + optional Sub-TLVs

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

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

   Sub-TLVs
                              Identification (MANDATORY) MAC Address (MANDATORY) TLV,
   indicating the MAC address of the remote node or Multicast group. The
   implementation would then place any supported OPTIONAL Data Item TLVs
   into the packet:

   Optional Data Item TLVs:

              - IPv4 Address (OPTIONAL)
              - IPv6 Address (OPTIONAL)
              - Maximum Data Rate (OPTIONAL)
              - Current Data Rate (OPTIONAL)
              - Latency (OPTIONAL)
              - Expected Forwarding Time (OPTIONAL)
              - Resources (OPTIONAL)
              - Relative Link Factor (OPTIONAL)
              - Credit Window Status (OPTIONAL)

19. Neighbor Up ACK Message

   A peer DLEP participant sends the Neighbor Up ACK Message to indicate
   whether a Neighbor Up Message was successfully processed. When a peer
   receives

   To construct 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 message, the following fields:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Msg Type =   |Msg Flg|AddrLen|          Message Size         |
  | DLEP_MESSAGE  | 0x1   | 0x0   |                35             |
  | (value TBD)   |       |       |                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      |TLVs Length = 27               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | DLEP Neighbor |TLV Flags=0x10 | Length = 24   | Sub-TLVs as   |
  | Up ACK (TBD)  |               |               | noted below   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Type             - DLEP_MESSAGE (Value TBD)

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

   Message DLEP_NEIGHBOR_UP_ACK (value TBD). The Identification data item
   TLV is placed in the packet next, followed by the MAC Address Length   - 0x0

   Message Size             - 35

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

   TLV Block                - TLV Length:  27

   Sub-TLVs DLEP neighbor. The implementation
   would then place any supported OPTIONAL Data Item TLVs into the
   packet:

   Optional Data Item TLVs:
              - Identification (MANDATORY)
                              MAC Address Sub-TLV (MANDATORY)
                              Status Sub-TLV (MANDATORY) Credit Window Status (OPTIONAL)

20. Neighbor Down Message

   A DLEP peer sends the Neighbor Down message to report when a
   destination (a routing peer remote node or a multicast group) is no longer
   reachable. The Neighbor Down message MUST contain both the
   Identification data item TLV, and a MAC Address data item TLV.
   Any other Other
   TLVs present as listed are OPTIONAL, and MAY be ignored. present if an implementation
   supports them. A Neighbor Down ACK Message is
   required MUST be sent by the
   recipient of a Neighbor Down message to confirm that the process. relevant
   data has been removed from the information base. 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

   To construct 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-TLVs as   |
  | DLEP Neighbor |               | optional Sub- | noted below   |
  | Down (TBD)    |               | initial TLV           |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Type               - DLEP_MESSAGE (Value TBD)

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

   Message Address Length     - 0x0

   Message Size               - 31 + optional TLVs

   Message Sequence Number    - A 16-bit unsigned integer field
                                containing a sequence number generated DLEP_NEIGHBOR_DOWN (value TBD). The signal TLV is followed by
   the message originator.

   TLV Block mandatory data item TLVs:

      - TLV Length: 23 + optional Sub-TLVs

   Sub TLVs Identification (MANDATORY)
      - MAC Address (MANDATORY) Data item
      - Status (OPTIONAL) data item

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

21. Neighbor Down ACK Message

   A peer DLEP participant sends the Neighbor Down ACK Message to indicate
   whether a received Neighbor Down Message was successfully processed.
   If successfully processed, the sending peer sender of the ACK MUST remove have removed
   all state entries in the information on base that pertain to the referenced neighbor session.

   The
   neighbor. As with the Neighbor Down ACK message contains message, there are NO OPTIONAL
   Data Item TLVs defined for the following fields:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Msg Type =   |Msg Flg|AddrLen|          Message Size         |
  | DLEP_MESSAGE  | 0x1   | 0x0   |                35             |
  | (value TBD)   |       |       |                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      |TLVs Length = 27               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | DLEP Neighbor |TLV Flags=0x10 | Length = 24   | Sub-TLVs as   |
  | 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 message.

   To construct a Neighbor Down
                              Message that is being acknowledged. message, the initial TLV Block                - type value is
   set to DLEP_NEIGHBOR_DOWN_ACK (value TBD). The Identification data
   item TLV Length:  27

   Sub-TLVs is placed in the packet next, followed by:

      - Identification (MANDATORY) MAC Address (MANDATORY) Data item
      - Status (MANDATORY) data item

22. Neighbor Update Message

   The client

   A DLEP participant sends the Neighbor Update message when a it detects
   some change in link
   metric parameters is detected the information base for a destination.

   The given neighbor (remote node
   or multicast group). Some examples of changes that would prompt a
   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-TLVs as    |
  |DLEP Neighbor  |               |optional Sub-  |noted below    |
  |Update (TBD)   |               |TLVs           |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Message Type message are:

       - DLEP_MESSAGE (Value TBD)

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

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

   Message DLEP_NEIGHBOR_UPDATE (value TBD). Following the signal TLV are
   the mandatory Data Item TLVs:

   Identification Data Item TLV
   MAC Address Length       - 0x0

   Message Size                 - 31 + optional data item TLV

   After placing the mandatory data item TLVs

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

   TLV Block                    - packet, the
   implementation would place any supported OPTIONAL data item TLVs.
   Possible OPTIONAL data item TLVs Length are:

              - 23 + optional Sub-TLVs.

   Sub TLVs
                                  Identification (MANDATORY)
                                  MAC IPv4 Address
              - IPv6 Address (MANDATORY)
              - Maximum Data Rate (OPTIONAL)
              - Current Data Rate (OPTIONAL)
              - Latency (OPTIONAL)
              - Resources (OPTIONAL)
              - Relative Link Quality (OPTIONAL)
              - 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 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 |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | DLEP Neighbor |TLV Flags=0x10 | Length =20 +  | Sub-TLVs as   |
  | Address Update|               | opt sub-TLVs  | noted below   |
  |(TBD)          |               |               |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Type                 - DLEP_MESSAGE (Value TBD)

   Message Flags                - Set 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.
   Sub TLVs
                                  Identification Sub-TLV (MANDATORY)
                                  MAC Address Sub-TLV (MANDATORY)
                                  IPv4 Address Sub-TLV (OPTIONAL)
                                  IPv6 Address Sub-TLV (OPTIONAL)

24. Neighbor Address Update ACK Message

   The 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-TLVs as   |
  | Address Update|               |               | noted below   |
  | ACK (TBD)     |               |               |               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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
   Sub TLVs
                              Identification Sub-TLV (MANDATORY)
                              MAC Address Sub-TLV (MANDATORY)
                              Status Sub-TLV (MANDATORY)

25. Heartbeat Message

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

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

   The

   To construct a Heartbeat Message contains message, the following fields:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Msg Type =   |Msg Flg|AddrLen|          Message Size         |
  | DLEP_MESSAGE  | 0x1   | 0x0   |               22              |
  | (value TBD)   |       |       |                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      |TLVs Length = 14               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | DLEP Heartbeat|TLV Flags=0x10 | Length = 11   | Sub-TLVs as   |
  | (TBD)         |               |               | noted below   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Type            - DLEP_MESSAGE (Value TBD)

   Message Flags           - Set to 0x1 (bit 3, mhasseqnum bit initial TLV type value 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 DLEP_PEER_HEARTBEAT (value TBD). The signal TLV is followed by the message
                             originator.

   TLV Block -               TLV Length = 14

   Sub TLVs
   mandatory data item TLVs:

      - Identification Sub-TLV (MANDATORY)

26.

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

24. Link Characteristics Request Message

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

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

   The

   To construct a Link Characteristics Request Message contains message, the following
   fields:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Msg Type =   |Msg Flg|AddrLen|          Message Size         |
  | DLEP_MESSAGE  | 0x1   | 0x0   |        31 + size of opt       |
  | (value TBD)   |       |       |            sub-TLVs           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      |TLVs Length =23 + opt sub-TLVs |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | DLEP Link Char|TLV Flags=0x10 | Length =20 +  | Sub-TLVs as   |
  | Request (TBD) |               | opt sub-TLVs  | noted below   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Type            - DLEP_MESSAGE (Value TBD)

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

   Message Address Length  - 0x0

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

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

   Sub TLVs are the mandatory Data Item TLVs:

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

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

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

   Latency TLV            - if  If present, this value represents the maximum latency, in
                             milliseconds,
                         desired latency (e.g., it is a not-to-exceed
                         value) in milliseconds on the link.
                             (OPTIONAL)

27.

25. Link Characteristics ACK Message

   The Link LInk Characteristics ACK Message message is an OPTIONAL message, and is
   sent by the client modems supporting it to the
   server router letting the server router know
   the success (or failure) or failure of the a requested change in link characteristics.
    The Link Characteristics ACK message SHOULD contain a complete set
   of metric data item TLVs. It MUST contain the same TLV types as the
   request. The values in the metric data item TLVs in the Link
   Characteristics ACK message MUST reflect the link characteristics
   after the request has been processed.

   The

   To construct a Link Characteristics Request ACK Message contains message, the following fields:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Msg Type =   |Msg Flg|AddrLen|          Message Size         |
  | DLEP_MESSAGE  | 0x1   | 0x0   |        31 + size of opt       |
  | (value TBD)   |       |       |            sub-TLVs           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Message Seq Num      |TLVs Length =23 + opt sub-TLVs |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | DLEP Link Char|TLV Flags=0x10 | Length =20 +  | Sub-TLVs as   |
  | ACK (TBD)     |               | opt sub-TLVs  | noted below   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Message Type            - DLEP_MESSAGE (Value TBD)

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

   Message Address Length  - 0x0

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

   Message Sequence Number - A 16-bit unsigned integer field containing
                             the sequence number that appeared on DLEP_NEIGHBOR_LINK_CHAR_ACK (value TBD).
   Following the
                             corresponding Link Characteristics Request
                             message. signal TLV Block               - TLVs Length = 23 + Optional TLVs

   Sub TLVs are the mandatory Data Item TLVs:

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

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

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

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

                             Resources Sub-TLV (OPTIONAL)

                             Relative Link Quality Sub-TLV (OPTIONAL)

28.

26.  Security Considerations

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

29.

27.  IANA Considerations

   This section specifies requests to IANA.

29.1  TLV

27.1  Registrations

   This specification defines:

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

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

   o  Reservation of numbering space for Experimental DLEP signals.

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

29.2

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

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

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

27.2  Expert Review: Evaluation Guidelines

   For the registries

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

29.3  Message anticipated.

27.3  Signal (Message) TLV Type Registration

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

       o   DLEP_MESSAGE

29.4  DLEP Order Registration

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

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

   This registry should be created according to

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

29.5
   experimental signal types.

27.4  DLEP Sub-TLV Type Data Item Registrations

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

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

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

27.5  DLEP Well-known Port

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

27.6  DLEP Multicast Address

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

30. Appendix A.

30.1  Peer Level Message Flows

*Modem

30.1.1  Modem Device (Client) Restarts Discovery

   Server                    Client

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

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

                                      Client

                                      Modem accepts failure, restarts
                                      discovery process.

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

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

                                      Discovery completed.

*Modem

30.1.2  Modem Device Detects Peer Offer Timeout

   Server                    Client

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

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

                                      Client

                                      Modem guard timer expires.
                                      Client Modem
                                      restarts discovery process.

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

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

                                      Discovery completed.

*Server

30.1.3  Router Peer Offer Lost

   Server                    Client

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

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

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

                                      Client

                                      Modem times out on Peer Offer,
                                      restarts discovery process.

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

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

                                      Discovery completed.

*Discovery

30.1.4  Discovery Success

   Server                    Client

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

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

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

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

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

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

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

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

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

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

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

*Server

30.1.5  Router Detects a Heartbeat timeout

   Server                    Client

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

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

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

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

           ~ ~ ~ ~ ~ ~ ~

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

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

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

                                      Client

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

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

*Client

30.1.6  Modem Detects a Heartbeat timeout

   Server                    Client

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

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

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

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

           ~ ~ ~ ~ ~ ~ ~

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

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

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

                                      Server

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

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

*Peer

30.1.7  Peer Terminate (from Client) Modem) Lost

   Server                    Client

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

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

                                      Server

                                      Router Heartbeat times out,
                                      terminates association.

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

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

*Peer

30.1.8  Peer Terminate (from server) Router) Lost

   Server                    Client

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

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

                                      Client

                                      Modem HB times out,
                                      terminates association.

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

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

30.2  Neighbor Level Specific Message Flows

*Client
30.2.1  Modem Neighbor Up Lost

   Server                    Client

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

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

                                      Client

                                      Modem timesout on ACK

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

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

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

*Server

30.2.2  Router Detects Duplicate Neighbor Ups

   Server                    Client

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

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

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

                                      Client

                                      Modem timesout on ACK

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

                                      Server

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

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

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

*Neighbor

30.2.3  Neighbor Up, No Layer 3 Addresses

   Server                    Client

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

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

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

                                      Server

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

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

*Neighbor

30.2.4  Neighbor Up with IPv4, No IPv6

   Server                    Client

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

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

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

                                      Server

                                      Router drives ND for IPv6 if
                                      defined.

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

*Neighbor

30.2.5  Neighbor Up with IPv4 and IPv6

   Server                    Client

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

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

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

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

30.2.6  Neighbor Metrics

*Neighbor Session Success

   Server                    Client

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

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

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

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

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

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

                                       Client     Modem

                                       Modem initiates the terminate

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

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

                                       or

                                       Server

                                       Router initiates the terminate

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

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

Acknowledgements

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

Normative References

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

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

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

Informative References

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

Author's Addresses

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

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

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

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

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