Mobile Ad hoc Networks Working S. Ratliff Group B. Berry Internet-Draft G. Harrison Intended status: Standards Track S. Jury Expires: November 2, 2011 D. Satterwhite Cisco Systems May 2, 2011 Dynamic Link Exchange Protocol (DLEP) draft-ietf-manet-dlep-01 Abstract When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make forwarding decisions. In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. A bidirectional, event- driven communication channel between the router and the modem is necessary. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 2, 2011 . Copyright Notice Copyright (c) 2010 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 Ratliff et al. Expires November 2, 2011 [Page 1] Internet-Draft DLEP May 2011 (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 BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Normal Session Flow . . . . . . . . . . . . . . . . . . . . . 5 4. Generic DLEP Packet Definition . . . . . . . . . . . . . . . . 6 5. Message Header Format . . . . . . . . . . . . . . . . . . . . 7 6. Message TLV Block Format . . . . . . . . . . . . . . . . . . . 7 7. DLEP Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Identification Sub-TLV . . . . . . . . . . . . . . . . . . 9 7.2. DLEP Version Sub-TLV . . . . . . . . . . . . . . . . . . . 10 7.3. Peer Type Sub-TLV . . . . . . . . . . . . . . . . . . . . 11 7.4. MAC Address Sub-TLV . . . . . . . . . . . . . . . . . . . 11 7.5. IPv4 Address Sub-TLV . . . . . . . . . . . . . . . . . . . 12 7.6. IPv6 Address Sub-TLV . . . . . . . . . . . . . . . . . . . 12 7.7. Maximum Data Rate Sub-TLV. . . . . . . . . . . . . . . . . 13 7.8. Current Data Rate Sub-TLV. . . . . . . . . . . . . . . . . 14 7.9. Latency Sub-TLV. . . . . . . . . . . . . . . . . . . . . . 14 7.10. Resources Sub-TLV. . . . . . . . . . . . . . . . . . . . . 15 7.11. Relative Link Quality Sub-TLV. . . . . . . . . . . . . . . 16 7.12. Peer Termination Sub-TLV . . . . . . . . . . . . . . . . . 16 7.13 Heartbeat Interval Sub-TLV . . . . . . . . . . . . . . . . 17 7.14 Heartbeat Threshold Sub-TLV. . . . . . . . . . . . . . . . 17 7.15 Link Characteristics ACK Timer Sub-TLV . . . . . . . . . . 18 8. DLEP Protocol Messages . . . . . . . . . . . . . . . . . . . . 19 8.1. Message Block TLV Values . . . . . . . . . . . . . . . . . 19 9. Peer Discovery Messages . . . . . . . . . . . . . . . . . . . 20 9.1. Attached Peer Discovery Message . . . . . . . . . . . . . 20 9.2. Detached Peer Discovery Message . . . . . . . . . . . . . 22 10. Peer Offer Message . . . . . . . . . . . . . . . . . . . . . . 23 11. Peer Update Message. . . . . . . . . . . . . . . . . . . . . . 25 12. Peer Update ACK Message. . . . . . . . . . . . . . . . . . . . 27 13. Peer Termination Message . . . . . . . . . . . . . . . . . . . 27 14. Peer Termination ACK Message . . . . . . . . . . . . . . . . . 28 15. Neighbor Up Message . . . . . . . . . . . . . . . . . . . . . 29 16. Neighbor Up ACK Message. . . . . . . . . . . . . . . . . . . . 31 17. Neighbor Down Message . . . . . . . . . . . . . . . . . . . . 32 18. Neighbor Down ACK Message. . . . . . . . . . . . . . . . . . . 33 19. Neighbor Update Message . . . . . . . . . . . . . . . . . . . 35 20. Neighbor Address Update Message. . . . . . . . . . . . . . . . 36 21. Neighbor Address Update ACK Message. . . . . . . . . . . . . . 38 22. Heartbeat Message . . . . . . . . . . . . . . . . . . . . . . 39 23. Link Characteristics Message . . . . . . . . . . . . . . . . . 39 24. Link Characteristics ACK Message . . . . . . . . . . . . . . . 41 25. Security Considerations. . . . . . . . . . . . . . . . . . . . 42 Ratliff et al. Expires November 2, 2011 [Page 2] Internet-Draft DLEP May 2011 26. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 42 26.1 TLV Registrations. . . . . . . . . . . . . . . . . . . . . 43 26.2 Expert Review: Evaluation Guidelines . . . . . . . . . . . 43 26.3 Message TLV Type Registrations . . . . . . . . . . . . . . 43 26.4 DLEP Order Registrations . . . . . . . . . . . . . . . . . 43 26.5 DLEP Sub-TLV Type Registrations. . . . . . . . . . . . . . 44 27. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 45 1. Introduction There exist today a collection of modem devices that control links of variable bandwidth and quality. Examples of these types of links include line-of-sight (LOS) radios, satellite terminals, and cable/ DSL modems. Fluctuations in speed and quality of these links can occur due to configuration (in the case of cable/DSL modems), or on a moment-to-moment basis, due to physical phenomena like multipath interference, obstructions, rain fade, etc. It is also quite possible that link quality and bandwidth varies with respect to individual neighbors on a link, and with the type of traffic being sent. As an example, consider the case of an 802.11g access point, serving 2 associated laptop computers. In this environment, the answer to the question "What is the bandwidth on the 802.11g link?" is "It depends on which associated laptop we're talking about, and on what kind of traffic is being sent." While the first laptop, being physically close to the access point, may have a bandwidth of 54Mbps for unicast traffic, the other laptop, being relatively far away, or obstructed by some object, can simultaneously have a bandwidth of only 32Mbps for unicast. However, for multicast traffic sent from the access point, all traffic is sent at the base transmission rate (which is configurable, but depending on the model of the access point, is usually 24Mbps or less). In addition to utilizing variable bandwidth links, mobile networks are challenged by the notion that link connectivity will come and go over time. Effectively utilizing a relatively short-lived connection is problematic in IP routed networks, as routing protocols tend to rely on independent timers at OSI Layer 3 to maintain network convergence (e.g. HELLO messages and/or recognition of DEAD routing adjacencies). These short-lived connections can be better utilized with an event-driven paradigm, where acquisition of a new neighbor (or loss of an existing one) is somehow signaled, as opposed to a timer-driven paradigm. Another complicating factor for mobile networks are the different methods of physically connecting the modem devices to the router. Modems can be deployed as an interface card in a router's chassis, or as a standalone device connected to the router via Ethernet, USB, or even a serial link. In the case of Ethernet or serial attachment, with existing protocols and techniques, routing software cannot be aware of convergence events occurring on the radio link (e.g. acquisition or loss of a potential routing neighbor), nor can the router be aware of the actual capacity of the link. This lack of awareness, along with the variability in bandwidth, leads to a situation where quality of service (QoS) Ratliff et al. Expires November 2, 2011 [Page 3] Internet-Draft DLEP May 2011 profiles are extremely difficult to establish and properly maintain. This is especially true of demand-based access schemes such as Demand Assigned Multiple Access (DAMA) implementations used on some satellite systems. With a DAMA-based system, additional bandwidth may be available, but will not be used unless the network devices emit traffic at rate higher than the currently established rate. Increasing the traffic rate does not guarantee additional bandwidth will be allocated; rather, it may result in data loss and additional retransmissions on the link. In attempting to address the challenges listed above, the authors have developed the Data Link Exchange Protocol, or DLEP. The DLEP protocol runs between a router and its attached modem devices, allowing the modem to communicate link characteristics as they change, and convergence events (acquisition and loss of potential routing neighbors). The diagram below is used to illustrate the scope of DLEP sessions. When a local client (Modem device) detects the presence of a remote neighbor, it sends an indication to its local router via the DLEP session. Upon receipt of the indication, the local router would take appropriate action (e.g. initiation of discovery or HELLO protocols) to converge the network. After notification of the new neighbor, the modem device utilizes the DLEP session to report the characteristics of the link (bandwidth, latency, etc) to the router on an as-needed basis. Finally, the Modem is able to use the DLEP session to notify the router when the remote neighbor is lost, shortening the time required to re-converge the network. |-----Local Neighbor-----| |-----Remote Neighbor----| | | | (far-end device) | +--------+ +-------+ +-------+ +--------+ | Router |=======| Modem |{~~~~~~~~}| Modem |=======| Router | | | | Device| | Device| | | +--------+ +-------+ +-------+ +--------+ | | | Link | | | |-DLEP--| | Protocol | |-DLEP--| | | | (e.g. | | | | | | 802.11) | | | Figure 1: DLEP Network DLEP exists as a collection of type-length-value (TLV) based messages using [RFC5444] formatting. The protocol can be used for both Ethernet attached modems (utilizing, for example, a UDP socket for transport of the RFC 5444 packets), or in environments where the modem is an interface card in a chassis (via a message passing scheme). DLEP utilizes a session paradigm between the modem device and its associated router. If multiple modem devices are attached to a router, a separate DLEP session MUST exist for each modem. If a modem device supports multiple connections to a router (via multiple Ratliff et al. Expires November 2, 2011 [Page 4] Internet-Draft DLEP May 2011 interfaces), or supports connections to multiple routers, a separate DLEP session MUST exist for each connection. 1.1 Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 2. Assumptions In order to implement discovery in the DLEP protocol (thereby avoiding some configuration), we have defined a first-speaker and a passive-listener scheme. Specifically, the router is defined as the passive-listener, and the modem device defined as the first-speaker (e.g. the initiator for discovery). Borrowing from existing terminology, this document refers to the first-speaker as the 'client', even though there is no client/server relationship in the classic sense. DLEP assumes that participating modem devices appear to the router as a transparent bridge - specifically, the assumption is that the destination MAC address for data traffic in any frame emitted by the router should be the MAC address of the next-hop router or end- device, and not the MAC address of any of the intervening modem devices. DLEP assumes that security on the session (e.g. authentication of session partners, encryption of traffic, or both) is dealt with by the underlying transport mechanism for the RFC 5444 packets (e.g. by using a transport such as DTLS [DTLS]). The optional [RFC5444] message header Sequence Number MUST be included in all DLEP packets. Sequence Numbers start at 1 and are incremented by one for each original and retransmitted message. The unsigned 16-bit Sequence Number rolls over at 65535 to 1. A Sequence Number of 0 is not valid. Peer level Sequence Numbers are unique within the context of a DLEP session. Sequence numbers are used in DLEP to correlate a response to a request. 3. Normal Session Flow A session between a router and a client is established by exchanging the "Peer Discovery" and "Peer Offer" messages described below. Once that exchange has successfully occurred, the client informs the router of the presence of a new potential routing partner via the "Neighbor Up" message. The loss of a neighbor is communicated via the "Neighbor Down" message, and link quality is communicated via the "Neighbor Update" message. Note that, due to the issue of metrics varying depending on neighbor (discussed above), DLEP link metrics are expressed within the context of a neighbor relationship, instead of on the link as a whole. Ratliff et al. Expires November 2, 2011 [Page 5] Internet-Draft DLEP May 2011 Once the DLEP session has started, the session partners exchange heartbeat messages based on a negotiated time interval. The heartbeat messages are used to assure the session partners are in an appropriate state, and that bidirectional connectivity still exists. In addition to receiving metrics about the link, DLEP provides for the ability for the router to request a different amount of bandwidth, or latency, for its client via the Link Characteristics Message. This allows the router to deal with requisite increases (or decreases) of allocated bandwidth/latency in demand-based schemes in a more deterministic manner. 4. Generic DLEP Packet Definition The Generic DLEP Packet Definition follows the format for packets defined in [RFC5444]. The Generic DLEP Packet Definition contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Flags | Packet Sequence Number | Packet TLV | | | | | Block... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message (Contains DLEP message)... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version - Version of RFC 5444 specification on which the packet/messages/TLVs are constructed. Flags - 4 bit field. All bits MUST be ignored by DLEP implementations. Packet Sequence Number - If present, the packet sequence number is parsed and ignored. DLEP does NOT use or generate packet sequence numbers. Packet TLV block - a TLV block which contains packet level TLV information. DLEP implementations MUST NOT use this TLV block. Message - the packet MAY contain zero or more messages, however, DLEP messages are encoded within an RFC 5444 Message TLV Block. Ratliff et al. Expires November 2, 2011 [Page 6] Internet-Draft DLEP May 2011 5. Message Header Format DLEP utilizes the following format for the RFC 5444 message header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type |Msg Flg|AddrLen| Message Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num | TLV Block... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Type - an 8-bit field which specifies the type of the message. For DLEP, this field contains DLEP_MESSAGE (value TBD) Message Flags - Set to 0x1 (bit 3, mhasseqnum bit is set). All other bits are unused and MUST be set to '0'. Message Address Length - a 4-bit unsigned integer field encoding the length of all addresses included in this message. DLEP implementations do not use this field; contents SHOULD be ignored. Message Size - a 16-bit unsigned integer field which specifies the number of octets that make up the message including the message header. Message Sequence Number - a 16-bit unsigned integer field that contains a sequence number, generated by the originator of the message. Sequence numbers range from 1 to 65535. Sequence numbers roll over at 65535 to 1; 0 is invalid. TLV Block - TLV Block included in the message. 6. Message TLV Block Format The DLEP protocol is organized as a set of orders, each with a collection of Sub-TLVs. The Sub-TLVs carry information needed to process and/or establish context (e.g. the MAC address of a far-end router), and the 'tlv-type' field in the message TLV block carries the DLEP order itself. The DLEP orders are enumerated in section 8.1 of this document, and the messages created using these orders are documented in sections 9 through 24. Ratliff et al. Expires November 2, 2011 [Page 7] Internet-Draft DLEP May 2011 DLEP uses the following settings for an RFC 5444 Message TLV block: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLVs Length | TLV Type | TLV Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLVs Length - a 16-bit unsigned integer field that contains the total number of octets in all of the immediately following TLV elements (tlvs-length not included). TLV Type - an 8-bit unsigned integer field specifying the type of the TLV. DLEP uses this field to specify the DLEP order. Valid DLEP orders are defined in section 8.1 of this document. TLV Flags - an 8-bit flags bit field. Bit 3 (thasvalue) MUST be set; all other bits are not used and MUST be set to '0'. Length - Length of the 'Value' field of the TLV Value - A field of length which contains data specific to a particular TLV type. In the DLEP case, this field will consist of a collection of DLEP sub-TLVs appropriate for the DLEP action specified in the TLV type field. 7. DLEP sub-TLVs DLEP protocol messages are transported in an RFC 5444 message TLV. All DLEP messages use the RFC 5444 DLEP_MESSAGE value (TBD). The protocol messages consist of a DLEP order, encoded in the 'tlv-type' field in the message TLV block, with the 'value' field of the TLV block containing a collection (1 or more) DLEP sub-TLVs. The format of DLEP Sub-TLVs is consistent with RFC 5444 in that the Sub-TLVs contain a flag field in addition to the type, length, and value fields. Valid DLEP Sub-TLVs are: TLV TLV Value Description ========================================= TBD Identification sub-TLV TBD DLEP Version sub-TLV TBD Peer Type sub-TLV TBD MAC Address sub-TLV TBD IPv4 Address sub-TLV TBD IPv6 Address sub-TLV Ratliff et al. Expires November 2, 2011 [Page 8] Internet-Draft DLEP May 2011 TBD Maximum Data Rate (MDR) sub-TLV TBD Current Data Rate (CDR) sub-TLV TBD Latency sub-TLV TBD Resources sub-TLV TBD Relative Link Quality (RLQ) sub-TLV TBD Status sub-TLV TBD Heartbeat Interval sub-TLV TBD Heartbeat Threshold sub-TLV TBD Neighbor down ACK timer sub-TLV TBD Link Characteristics ACK timer sub-TLV DLEP sub-TLVs contain the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type |TLV Flags=0x10 | Length | Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type - an 8-bit unsigned integer field specifying the type of the sub-TLV. TLV Flags - an 8-bit flags bit field. Bit 3 (thasvalue) MUST be set, all other bits are not used and MUST be set to '0'. Length - an 8-bit length of the value field of the sub-TLV Value - A field of length which contains data specific to a particular sub-TLV. 7.1 Identification Sub-TLV This Sub-TLV MUST exist in the TLV Block for all DLEP messages, and MUST be the first Sub-TLV of the message. Further, there MUST be ONLY one Identification Sub-TLV in an RFC 5444 message TLV block. The Identification sub-TLV contains client and router identification information used to establish the proper context for processing DLEP protocol messages. The Identification sub-TLV contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type = TBD |TLV Flags=0x10 |Length = 8 | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | Client ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ratliff et al. Expires November 2, 2011 [Page 9] Internet-Draft DLEP May 2011 TLV Type - Value TBD TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other bits are unused and MUST be set to '0'. Length - 8 Router ID - indicates the router ID of the DLEP session. Client ID - indicates the client ID of the DLEP session. When the client initiates discovery (via the Peer Discovery message), it MUST set the Client ID to a 32-bit quantity that will be used to uniquely identify this session from the client-side. The client MUST set the Router ID to '0'. When responding to the Peer Discovery message, the router MUST echo the Client ID, and MUST supply its own unique 32-bit quantity to identify the session from the router's perspective. After the Peer Discovery/Peer Offer exchange, both the Client ID and the Router ID MUST be set to the values obtained from the Peer DIscovery/Peer Offer sequence. 7.2 DLEP Version Sub-TLV The DLEP Version Sub-TLV is an OPTIONAL TLV in both the Peer Discovery and Peer Offer messages. The Version Sub-TLV is used to indicate the client or router version of the protocol. The client and router MAY use this information to decide if the peer is running at a supported level. The DLEP Version Sub-TLV contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |TLV Flags=0x10 |Length=4 | 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 or router protocol. Minor Version - Minor version of the client or router protocol. Support of this draft is indicated by setting the Major Version to '1', and the Minor Version to '1' (e.g. Version 1.1). Ratliff et al. Expires November 2, 2011 [Page 10] Internet-Draft DLEP May 2011 7.3 Peer Type Sub-TLV The Peer Type Sub-TLV is used by the router and client to give additional information as to its type. It is an OPTIONAL sub-TLV in both the 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. display command). The Peer Type sub-TLV contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |TLV Flags=0x10 |Length= peer |Peer Type Str | | | |type string len|Max Len = 80 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type - TBD TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other bits are not used and MUST be set to '0'. Length - length of peer type string (80 bytes maximum) Peer Type String - Non-Null terminated peer type string, maximum length of 80 bytes. For example, a satellite modem might set this variable to 'Satellite terminal'. 7.4 MAC Address Sub-TLV The MAC address Sub-TLV MUST appear in all neighbor-oriented messages (e.g. Neighbor Up, Neighbor Up ACK, Neighbor Down, Neighbor Down ACK, Neighbor Update, Link Characteristics Request, and Link Characteristics ACK). The MAC Address sub-TLV contains the address of the far-end (neighbor) router. 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'. Ratliff et al. Expires November 2, 2011 [Page 11] Internet-Draft DLEP May 2011 Length - 6 MAC Address - MAC Address of the far-end router. 7.5 IPv4 Address Sub-TLV The IPv4 Address Sub-TLV MAY be used in Neighbor Up, Neighbor Update, and Peer Update Messages, if the client is aware of the Layer 3 address. When included in Neighbor messages, the IPv4 Address sub-TLV contains the IPv4 address of the far-end router (neighbor). In the Peer Update message, it contains the IPv4 address of the local router. In either case, the sub-TLV also contains an indication of whether this is a new or existing address, or is a deletion of a previously known address. The IPv4 Address Sub-TLV contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |TLV Flags=0x10 |Length = 5 | Add/Drop | | | | | Indicator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 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 - 5 Add/Drop - Value indicating whether this is a new or existing Indicator address (0x01), or a withdrawal of an address (0x02). IPv4 Address - IPv4 Address of the far-end router. 7.6 IPv6 Address Sub-TLV The IPv6 Address Sub-TLV MAY be used in Neighbor Up, Neighbor Update, and Peer Update Messages, if the client is aware of the Layer 3 address. When included in Neighbor messages, the IPv6 Address sub-TLV contains the IPv6 address of the far-end router (neighbor). In the Peer Update, it contains the IPv6 address of the local router. In either case, the sub-TLV also contains an indication of whether this is a new or existing address, or is a deletion of a previously known address. Ratliff et al. Expires November 2, 2011 [Page 12] Internet-Draft DLEP May 2011 The IPv6 Address sub-TLV contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |TLV Flags=0x10 |Length = 17 | Add/Drop | | | | | Indicator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type - TBD TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other bits are not used and MUST be set to '0'. Length - 17 Add/Drop - Value indicating whether this is a new or Indicator existing address (0x01), or a withdrawal of an address (0x02). IPv6 Address - IPv6 Address of the far-end router. 7.7 Maximum Data Rate Sub-TLV The Maximum Data Rate (MDR) Sub-TLV is used in Neighbor Up, Neighbor 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 Ratliff et al. Expires November 2, 2011 [Page 13] Internet-Draft DLEP May 2011 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. 7.8 Current Data Rate Sub-TLV The Current Data Rate (CDR) Sub-TLV is used in Neighbor Up, Neighbor 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. The Current Data Rate sub-TLV contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |TLV Flags=0x10 |Length = 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), on the link. When reporting metrics (e.g, in Neighbor Up, Neighbor Down, or Link Characteristics ACK), if there is no distinction between current and maximum data rates, current data rate SHOULD be set equal to the maximum data rate. 7.9 Latency Sub-TLV The Latency Sub-TLV is used in Neighbor Up, Neighbor 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. Ratliff et al. Expires November 2, 2011 [Page 14] Internet-Draft DLEP May 2011 The Latency Sub-TLV contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |TLV Flags=0x10 |Length = 2 |Latency (ms) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |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 transmission delay that a packet encounters as it is transmitted over the link. In Neighbor Up, Neighbor Update, and Link Characteristics ACK, this value is reported in absolute delay, in milliseconds. The calculation of latency is modem-device dependent. For example, the latency may be a running average calculated from the internal queuing. If the modem device cannot calculate latency, it SHOULD be reported as 0. In the Link Characteristics Request Message, this value represents the maximum delay, in milliseconds, expected on the link. 7.10 Resources Sub-TLV The Resources Sub-TLV is used in Neighbor Up, Neighbor Update, and Link Characteristics ACK messages to indicate a percentage (0-100) amount of resources (e.g. battery power) remaining on the modem device. 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 Ratliff et al. Expires November 2, 2011 [Page 15] Internet-Draft DLEP May 2011 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 be reported. 7.11 Relative Link Quality Sub-TLV The Relative Link Quality (RLQ) Sub-TLV is used in Neighbor Up, Neighbor Update, and Link Characteristics ACK messages to indicate the quality of the link as calculated by the modem device. The Relative Link Quality sub-TLV contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |TLV Flags=0x10 |Length = 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 the relative link quality. A value of 100 represents a link of the highest quality. If the RLQ cannot be calculated, a value of 100 SHOULD be reported. 7.12 Status Sub-TLV The Status Sub-TLV is sent from either the client or router to indicate the success or failure of a given request The Status Sub-TLV contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |TLV Flags=0x10 |Length = 1 | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type - TBD TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other bits are not used and MUST be set to '0'. Ratliff et al. Expires November 2, 2011 [Page 16] Internet-Draft DLEP May 2011 Length - 1 Termination Code - 0 = Success Non-zero = Failure. Specific values of a non- zero termination code depend on the operation requested (e.g. Neighbor Up, Neighbor Down, etc). 7.13 Heartbeat Interval Sub-TLV The Heartbeat Interval Sub-TLV MAY be sent from the client during Peer Discovery to indicate the desired Heartbeat timeout window. If included in the Peer Discovery, the router MUST either accept the timeout interval, or reject the Peer Discovery. The Heartbeat Interval Sub-TLV contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |TLV Flags=0x10 |Length = 1 | 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, for heartbeat messages. 7.14 Heartbeat Threshold Sub-TLV The Heartbeat Threshold Sub-TLV MAY be sent from the client during Peer Discovery to indicate the desired number of windows, of time (Heartbeat Interval) seconds, to wait before either peer declares the peer-to-peer session lost. In this case, the overall amount of time before a peer-to-peer session is declared lost is expressed as (Interval * Threshold), where 'Interval' is the value in the Heartbeat Interval sub-TLV, documented above. If this sub-TLV is included by the client in the Peer Discovery, the client MUST also specify the Heartbeat Interval sub-TLV with a non-zero interval. If this sub-TLV is received during Peer Discovery, the router MUST either accept the threshold, or reject the Peer Discovery. Ratliff et al. Expires November 2, 2011 [Page 17] Internet-Draft DLEP May 2011 The Heartbeat Threshold Sub-TLV contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |TLV Flags=0x10 |Length = 1 | 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 - 0 = Do NOT use heartbeats on this peer-to-peer session. Non-zero = Number of windows, of Heartbeat Interval seconds, to wait before declaring a peer-to-peer session to be lost. 7.15 Link Characteristics ACK Timer Sub-TLV The Link Characteristic ACK Timer Sub-TLV MAY be sent from the client during Peer Discovery to indicate the desired number of seconds the router should wait for a response to a Link Characteristics Request. If this sub-TLV is received during Peer Discovery, the router MUST either accept the timeout value, or reject the Peer Discovery. The Link Characteristics ACK Timer Sub-TLV contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |TLV Flags=0x10 |Length = 1 | 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 session. Non-zero = Interval, in seconds, to wait before considering a Link Characteristics Request has been lost. Ratliff et al. Expires November 2, 2011 [Page 18] Internet-Draft DLEP May 2011 8. DLEP Protocol Messages DLEP places no additional requirements on the RFC 5444 Packet formats, or the packet header. DLEP does require that the optional 'msg-seq-num' in the message header exist, and defines a set of values for the 'tlv-type' field in the RFC 5444 TLV block. Therefore, a DLEP message, starting from the RFC 5444 Message header, would appear as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type = |Msg Flg|AddrLen| Message Size | | DLEP_MESSAGE | 0x1 | 0x0 | | | (value TBD) | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num | TLV block length (length of | | | DLEP order + Sub-TLVs) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DLEP Message |TLV Flags=0x10 | Length | Start of DLEP | | Block value | | | Sub-TLVs... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8.1 Message Block TLV Values As mentioned above, all DLEP messages utilize a single RFC 5444 message type, the DLEP_MESSAGE (TBD). DLEP further identifies protocol messages by using the 'tlv-type' field in the RFC 5444 message TLV block. DLEP defines the following Message-Type- specific values for the tlv-type field: TLV TLV Value Description ========================================= TBD Attached Peer Discovery TBD Detached Peer Discovery TBD Peer Offer TBD Peer Update TBD Peer Update ACK TBD Peer Termination TBD Peer Termination ACK TBD Neighbor Up TBD Neighbor Up ACK TBD Neighbor Down TBD Neighbor Down ACK TBD Neighbor Update TBD Neighbor Address Update TBD Neighbor Address Update ACK TBD Heartbeat TBD Link Characteristics Request TBD Link Characteristics ACK Ratliff et al. Expires November 2, 2011 [Page 19] Internet-Draft DLEP May 2011 In all of the diagrams following, the message layouts begin with the RFC 5444 message header. 9. Peer Discovery Messages There are two different types of Peer Discovery Messages, Attached and Detached. Attached Peer Discovery Messages are sent by the client when it is directly attached to the router (e.g. the client exists as a card in the chassis, or it is connected via Ethernet with no intervening devices). The Detached Peer Discovery message, on the other hand, is sent by a "remote" client -- for example, a client at a satellite hub system might use a Detached Discovery Message in order to act as a proxy for remote ground terminals. To explain in another way, a detached client uses the variable link itself (the radio or satellite link) to establish a DLEP session with a remote router. 9.1 Attached Peer Discovery Message The Attached Peer Discovery Message is sent by an attached client to a router to begin a new DLEP association. The Peer Offer message is required to complete the discovery process. The client MAY implement its own retry heuristics in the event it (the client) determines the Attached Peer Discovery Message has timed out. The Attached Peer Discovery Message contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type = |Msg Flg|AddrLen| Message Size | | DLEP_MESSAGE | 0x1 | 0x0 | 22 + size of opt | | (value TBD) | | | sub-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num |TLVs Length =14 + opt sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DLEP Attached |TLV Flags=0x10 | Length =11 + | Sub-TLV type= | | Peer Discovery| | opt sub-TLVs | Identification| | (Value TDB) | | | sub-TLV (TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x10 |Length = 8 | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | Client ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client ID |Sub-TLV type= |TLV Flags=0x10 | | |DLEP Version | | | |sub-TLV (TBD) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Length = 4 | Major Version | Minor Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minor Version |Sub-TLV type= |TLV Flags=0x10 | Length = Len | | |Peer Type (TBD)| |of peer string | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Continued on next page) | Ratliff et al. Expires November 2, 2011 [Page 20] Internet-Draft DLEP May 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Continued from previous page) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer Type Str |Sub-TLV Type= |TLV Flags=0x10 | Length = 1 | |MaxLen=80 bytes|Heartbeat Int. | | | | |(TBD) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Heartbeat |Sub-TLV Type= |TLV Flags=0x10 | Length = 1 | | Interval |HB Thresh. | | | | (seconds) |(TBD) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Heartbeat |Sub-TLV Type= |TLV FLags=0x10 | Length = 1 | | Threshold |Link Char. ACK | | | |(# of windows) |Timer (TBD) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Link Char ACK | |Timer (sec) | +-+-+-+-+-+-+-+-+ Message Type - DLEP_MESSAGE (value TBD) Message Flags - Set to 0x1 (bit 3, mhasseqnum bit is set). No other bits are used and MUST be set to '0'. Message Address Length - 0x0 Message Size - 22 + size of optional sub-TLVs Message Sequence Number - a 16-bit unsigned integer field containing a sequence number generated by the message originator. TLV Block - TLVs Length: 14 + size of optional sub-TLVs. DLEP Attached Peer Disc. order Identification TLV (MANDATORY) Version Sub-TLV (OPTIONAL) Peer Type Sub-TLV (OPTIONAL) Heartbeat Int. Sub-TLV (OPTIONAL) Heartbeat Threshold Sub-TLV (OPT.) Link Characteristics ACK Timer Sub-TLV (OPTIONAL) Ratliff et al. Expires November 2, 2011 [Page 21] Internet-Draft DLEP May 2011 9.2 Detached Peer Discovery Message The Detached Peer Discovery Message is sent by a detached client proxy to a router to begin a new DLEP session. The Peer Offer message is required to complete the discovery process. The client MAY implement its own retry heuristics in the event it (the client) determines the Detached Peer Discovery Message has timed out. The Detached Peer Discovery Message contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type = |Msg Flg|AddrLen| Message Size | | DLEP_MESSAGE | 0x1 | 0x0 | 22 + size of opt | | (value TBD) | | | sub-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num |TLVs Length =14 + opt sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DLEP Detached |TLV Flags=0x10 | Length = 11 + | Sub-TLV type= | | Peer Discovery| | opt sub-TLVs | Identification| | (Value TDB) | | | sub-TLV (TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x10 |Length = 8 | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | Client ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client ID |Sub-TLV type= |TLV Flags=0x10 | | |DLEP Version | | | |sub-TLV (TBD) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Length = 4 | Major Version | Minor Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minor Version |Sub-TLV type= |TLV Flags=0x10 | Length = Len | | |Peer Type (TBD)| |of peer string | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer Type Str |Sub-TLV Type= |TLV Flags=0x10 | Length = 1 | |MaxLen=80 bytes|Heartbeat Int. | | | | |(TBD) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Heartbeat |Sub-TLV Type= |TLV Flags=0x10 | Length = 1 | | Interval |HB Thresh. | | | | (seconds) |(TBD) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Heartbeat |Sub-TLV Type= |TLV FLags=0x10 | Length = 1 | | Threshold |Link Char. ACK | | | |(# of windows) |Timer (TBD) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Link Char ACK | |Timer (sec) | +-+-+-+-+-+-+-+-+ Message Type - DLEP_MESSAGE (value TBD) Ratliff et al. Expires November 2, 2011 [Page 22] Internet-Draft DLEP May 2011 Message Flags - Set to 0x1 (bit 3, mhasseqnum bit is set). All other bits are not used and MUST be set to '0'. Message Address Length - 0x0 Message Size - 22 + size of optional sub-TLVs Message Sequence Number - A 16-bit unsigned integer field containing a sequence number, generated by the message originator. TLV Block - TLVs Length: 14 + size of optional sub-TLVs. DLEP Detached Peer Discovery order Identification sub-TLV (MANDATORY) Version sub-TLV (OPTIONAL) Peer Type Sub-TLV (OPTIONAL) Heartbeat Interval Sub-TLV (OPTIONAL) Heartbeat Threshold Sub-TLV (OPTIONAL) Link Char. ACK Timer Sub-TLV(OPTIONAL) 10. Peer Offer Message The Peer Offer Message is sent by a router to a client or client proxy in response to a Peer Discovery Message. The Peer Offer Message is the response to either of the Peer Discovery messages (either Attached or Detached), and completes the DLEP session establishment. The Peer Offer Message contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type = |Msg Flg|AddrLen| Message Size | | DLEP_MESSAGE | 0x1 | 0x0 | 22 + size of opt | | (value TBD) | | | sub-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num |TLVs Length =14 + opt sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |DLEP Peer Offer|TLV Flags=0x10 | Length = 11 + | Sub-TLV type= | | (Value TBD) | | opt sub-TLVs | Identification| | | | | sub-TLV (TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x10 |Length = 8 | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Continued on next page) | Ratliff et al. Expires November 2, 2011 [Page 23] Internet-Draft DLEP May 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Continued from above) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | Client ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client ID |Sub-TLV type= |TLV Flags=0x10 | | |DLEP Version | | | |sub-TLV (TBD) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length = 4 | Major Version | Minor Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minor Version |Peer Type sub- |TLV Flags=0x10 | Length = Len | | |TLV = TDB | |of peer string | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer Type Str |DLEP IPv4 sub- |TLV Flags=0x10 | Length = 5 | |MaxLen=80 bytes|TLV (TBD) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Add/Drop Ind. | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address |DLEP IPv6 sub- |TLV Flags=0x10 | Length = 17 | | |TLV Type = TBD | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Add/Drop Ind. | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |IPv6 Address |Sub-TLV type= |TLV Flags=0x10 | Length = 1 | | |Heartbeat Int. | | | | |(TBD) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Heartbeat |Sub-TLV Type= |TLV Flags=0x10 | Length = 1 | | Interval |Heartbeat | | | | (seconds) |Threshold (TBD)| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Heartbeat |Sub-TLV Type= |TLV FLags=0x10 | Length = 1 | | Threshold |Link Char. ACK | | | | (# of windows)|Timer (TBD) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Link Char ACK |Sub-TLV Type= |TLV Flags=0x10 | Length = 1 | |Timer (sec) |DLEP Status | | | | |(TBD) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | +-+-+-+-+-+-+-+-+ Message Type - DLEP_MESSAGE (Value TBD) Ratliff et al. Expires November 2, 2011 [Page 24] Internet-Draft DLEP May 2011 Message Flags - Set to 0x1 (bit 3, mhasseqnum bit is set). All other bits are unused and MUST be set to '0'. Message Address Length - 0x0 Message Size - 22 + size of optional sub-TLVs Message Sequence Number - A 16-bit unsigned integer field containing a sequence number, generated by the message originator. TLV Block - TLV Length: 14 + size of optional sub-TLVs DLEP Peer Offer order Identification sub-TLV (MANDATORY) DLEP Version sub-TLV (OPTIONAL) Peer Type sub-TLV (OPTIONAL) IPv4 Address sub-TLV (OPTIONAL) IPv6 Address sub-TLV (OPTIONAL) Status sub-TLV (OPTIONAL) Heartbeat Interval Sub-TLV (OPTIONAL) Heartbeat Threshold Sub-TLV (OPTIONAL) Link Char. ACK Timer Sub-TLV (OPTIONAL) 11. Peer Update Message The Peer Update message is sent by the router to indicate local Layer 3 address changes. For example, addition of an IPv4 address to the router would prompt a Peer Update message to its attached DLEP clients. If the modem device is capable of understanding and forwarding this information, the address update would prompt any remote DLEP clients (DLEP clients that are on the far-end of the variable link) to issue a "Neighbor Update" message to their local routers, with the address change information. Clients that do not track Layer 3 addresses MUST silently ignore the Peer Update Message. Clients that track Layer 3 addresses MUST acknowledge the Peer Update with a Peer Update ACK message. Routers MAY employ heuristics to retransmit Peer Update messages. Sending of Peer Update Messages SHOULD cease when a router implementation determines that a partner modem device does NOT support Layer 3 address tracking. Ratliff et al. Expires November 2, 2011 [Page 25] Internet-Draft DLEP May 2011 The Peer Update Message contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type = |Msg Flg|AddrLen| Message Size | | DLEP_MESSAGE | 0x1 | 0x0 | 22 + size of opt | | (value TBD) | | | sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num |TLVs Length =14 + opt sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DLEP Peer |TLV Flags=0x10 | Length = 11 + | Sub-TLV type= | | Update | | opt sub-TLVs | Identification| | (Value TDB) | | | sub-TLV (TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x10 |Length = 8 | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | Client ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client ID |Sub-TLV type= |TLV Flags=0x10 | | |DLEP IPv4 | | | |sub-TLV (TBD) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Length = 5 | Add/Drop Ind. | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | Sub-TLV type= |TLV Flags=0x10 | | | DLEP IPv6 | | | | sub-TLV (TBD) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Length = 17 | Add/Drop Ind. | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Type - DLEP_MESSAGE (Value TBD) Message Flags - Set to 0x1 (bit 3, mhasseqnum bit is set). All other bits are unused and MUST be set to '0'. Message Address Length - 0x0 Message Size - 22 + optional Sub-TLVs Message Sequence Number - A 16-bit unsigned integer field containing a sequence number generated by the message originator. Ratliff et al. Expires November 2, 2011 [Page 26] Internet-Draft DLEP May 2011 TLV Block - TLV Length: 14 + length of optional sub-TLVs. DLEP Peer Update order Identification sub-TLV (MANDATORY) IPv4 Address Sub-TLV (OPTIONAL) IPv6 Address Sub-TLV (OPTIONAL) 12. Peer Update ACK Message The client sends the Peer Update ACK Message to indicate whether a Peer Update Message was successfully processed. The Peer Update ACK message contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type = |Msg Flg|AddrLen| Message Size | | DLEP_MESSAGE | 0x1 | 0x0 | 22 + size of opt | | (value TBD) | | | sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num |TLVs Length =14 + opt sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DLEP Peer |TLV Flags=0x10 | Length = 11 + | Sub-TLV type= | | Update ACK | | opt sub-TLVs | Identification| | (Value TDB) | | | sub-TLV (TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x10 |Length = 8 | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | Client ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client ID |Sub-TLV type= |TLV Flags=0x10 | | |DLEP Status | | | |sub-TLV (TBD) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Length = 1 | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Type - DLEP_MESSAGE (Value TBD) Message Flags - Set to 0x1 (bit 3, mhasseqnum bit is set). All other bits are unused and MUST be set to '0'. Message Address Length - 0x0 Message Size - 22 + size of optional sub-TLVs. Message Sequence Number - A 16-bit unsigned integer field containing the sequence number from the Neighbor Up Message that is being acknowledged. Ratliff et al. Expires November 2, 2011 [Page 27] Internet-Draft DLEP May 2011 TLV Block - TLV Length: 14 + optional sub-TLVs DLEP Peer Update ACK order Identification Sub-TLV (MANDATORY) Status Sub-TLV (OPTIONAL) 13. Peer Termination Message The Peer Termination Message is sent by either the client or the router when a session needs to be terminated. Transmission of a Peer Termination ACK message is required to confirm the termination process. The sender of the Peer Termination message is free to define its heuristics in event of a timeout. The receiver of a Peer Termination Message MUST terminate all neighbor relationships and release associated resources. No Neighbor Down messages are sent. The Peer Termination Message contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type = |Msg Flg|AddrLen| Message Size | | DLEP_MESSAGE | 0x1 | 0x0 | 22 + size of opt | | (value TBD) | | | sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num |TLVs Length =14 + opt sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DLEP Peer |TLV Flags=0x10 | Length = 11 + | Sub-TLV type= | | Termination | | opt sub-TLVs | Identification| | (Value TDB) | | | sub-TLV (TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x10 |Length = 8 | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | Client ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client ID |Sub-TLV type= |TLV Flags=0x10 | | |DLEP Status | | | |sub-TLV (TBD) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length = 1 | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Type - DLEP_MESSAGE (Value TBD) Message Flags - Set to 0x1 (bit 3, mhasseqnum bit is set). All other bits are unused and MUST be set to '0'. Message Address Length - 0x0 Message Size - 22 + size of optional sub-TLVs. Ratliff et al. Expires November 2, 2011 [Page 28] Internet-Draft DLEP May 2011 Message Sequence Number - A 16-bit unsigned integer field containing a sequence number generated by the message originator. TLV Block - TLV Length = 14 + optional sub-TLVs DLEP Peer Termination order Identification Sub-TLV (MANDATORY) Status Sub-TLV (OPTIONAL) 14. Peer Termination ACK Message The Peer Termination Message ACK is sent by either the client or the router when a session needs to be terminated. The Peer Termination ACK Message contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type = |Msg Flg|AddrLen| Message Size | | DLEP_MESSAGE | 0x1 | 0x0 | 22 + size of opt | | (value TBD) | | | sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num |TLVs Length =14 + opt sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DLEP Peer Term|TLV Flags=0x10 | Length = 11 + | Sub-TLV type= | | ACK | | opt sub-TLVs | Identification| | (Value TBD) | | | sub-TLV (TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x10 |Length = 8 | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | Client ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client ID |Sub-TLV type= |TLV Flags=0x10 | | |DLEP Status | | | |sub-TLV (TBD) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length = 1 | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Type - DLEP_MESSAGE (Value TBD) Message Flags - Set to 0x1 (bit 3, mhasseqnum bit is set). All other bits are unused and MUST be set to '0'. Message Address Length - 0x0 Message Size - 22 + optional sub-TLVs. Ratliff et al. Expires November 2, 2011 [Page 29] Internet-Draft DLEP May 2011 Message Sequence Number - A 16-bit unsigned integer field containing the sequence number in the corresponding Peer Termination Message being acknowledged. TLV Block - TLV Length = 14 + optional Sub-TLVs DLEP Peer Termination ACK order Identification Sub-TLV (MANDATORY) Status Sub-TLV (OPTIONAL) 15. Neighbor Up Message The client sends the Neighbor Up message to report that a new potential routing neighbor has been detected. A Neighbor Up ACK Message is required to confirm a received Neighbor Up. The sender of the Neighbor Up Message is free to define its retry heuristics in event of a timeout. The Neighbor Up Message contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type = |Msg Flg|AddrLen| Message Size | | DLEP_MESSAGE | 0x1 | 0x0 | 31 + size of opt | | (value TBD) | | | sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num |TLVs Length =23 + opt sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DLEP Neighbor |TLV Flags=0x10 | Length =20 + | Sub-TLV type= | | Up (TBD) | | opt sub-TLVs | Identification| | | | | sub-TLV (TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x10 |Length = 8 | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | Client ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client ID |Sub-TLV type= |TLV Flags=0x10 | | |DLEP MAC | | | |sub-TLV (TBD) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Length = 6 | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address |Sub-TLV type= | | |DLEP IPv4 (TBD)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x10 |Length = 5 | Add/Drop Ind. | IPv4 Address | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address |Sub-TLV type= | | |DLEP IPv6 (TBD)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Continued on next page) | Ratliff et al. Expires November 2, 2011 [Page 30] Internet-Draft DLEP May 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Continued from above) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x10 |Length = 17 | Add/Drop Ind. | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address |Sub-TLV type= | | |DLEP MDR (TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x10 |Length = 8 | MDR (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MDR (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MDR (bps) |sub-TLV Type = |TLV Flags=0x10 | | |DLEP CDR (TBD) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Length = 8 | CDR (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CDR (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CDR (bps) |sub-TLV Type = |TLV Flags=0x10 | Length = 2 | | |Latency (TBD) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Latency (ms) |sub-TLV Type = |TLV Flags=0x10 | | |Resources(TBD) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length = 1 | Resources |sub-TLV Type = |TLV Flags=0x10 | | | |DLEP RLQ (TBD) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length = 1 | RLQ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Type - DLEP_MESSAGE (Value TBD) Message Flags - Set to 0x1 (bit 3, mhasseqnum bit is set). All other bits are unused and MUST be set to '0'. Message Address Length - 0x0 Message Size - 31 + optional Sub-TLVs Message Sequence Number - A 16-bit unsigned integer field containing a sequence number generated by the message originator. Ratliff et al. Expires November 2, 2011 [Page 31] Internet-Draft DLEP May 2011 TLV Block - TLV Length: 23 + optional Sub-TLVs. DLEP Neighbor Up order Identification Sub-TLV (MANDATORY) MAC Address Sub-TLV (MANDATORY) IPv4 Address Sub-TLV (OPTIONAL) IPv6 Address Sub-TLV (OPTIONAL) Maximum Data Rate Sub-TLV (OPTIONAL) Current Data Rate Sub-TLV (OPTIONAL) Latency Sub-TLV (OPTIONAL) Resources Sub-TLV (OPTIONAL) Relative Link Factor Sub-TLV (OPTIONAL) 16. Neighbor Up ACK Message The router sends the Neighbor Up ACK Message to indicate whether a Neighbor Up Message was successfully processed. The Neighbor Up ACK message contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type = |Msg Flg|AddrLen| Message Size | | DLEP_MESSAGE | 0x1 | 0x0 | 35 | | (value TBD) | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num |TLVs Length = 27 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DLEP Neighbor |TLV Flags=0x10 | Length = 24 | Sub-TLV type= | | Up ACK (TBD) | | | Identification| | | | | sub-TLV (TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x10 |Length = 8 | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | Client ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client ID |Sub-TLV type= |TLV Flags=0x10 | | |DLEP MAC | | | |sub-TLV (TBD) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Length = 6 | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address |Sub-TLV type= | | |DLEP Status | |(TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x10 | Length = 1 | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Type - DLEP_MESSAGE (Value TBD) Ratliff et al. Expires November 2, 2011 [Page 32] Internet-Draft DLEP May 2011 Message Flags - Set to 0x1 (bit 3, mhasseqnum bit is set). All other bits are unused and MUST be set to '0'. Message Address Length - 0x0 Message Size - 35 Message Sequence Number - A 16-bit unsigned integer field containing the sequence number from the Neighbor Down Message that is being acknowledged. TLV Block - TLV Length: 27 DLEP Neighbor Up ACK order Identification Sub-TLV (MANDATORY) MAC Address Sub-TLV (MANDATORY) Status Sub-TLV (MANDATORY) 17. Neighbor Down Message The client sends the Neighbor Down message to report when a neighbor is no longer reachable from the client. The Neighbor Down message MUST contain a MAC Address TLV. Any other TLVs present MAY be ignored. A Neighbor Down ACK Message is required to confirm the process. The sender of the Neighbor Down message is free to define its retry heuristics in event of a timeout. The Neighbor Down Message contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type = |Msg Flg|AddrLen| Message Size | | DLEP_MESSAGE | 0x1 | 0x0 | 31 + optional | | (value TBD) | | | sub-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num | TLVs Length = 23 + optional | | | Sub-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Type = |TLV Flags=0x10 | Length = 20 + | Sub-TLV type= | | DLEP Neighbor | | optional Sub- | Identification| | Down (TBD) | | TLV | sub-TLV (TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x10 |Length = 8 | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | Client ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client ID |Sub-TLV type= |TLV Flags=0x10 | | |DLEP MAC | | | |sub-TLV (TBD) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Continued on next page) | Ratliff et al. Expires November 2, 2011 [Page 33] Internet-Draft DLEP May 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Continued from above) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Length = 6 | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address |Sub-TLV type= | | |DLEP Status | |(TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x10 | Length = 1 | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Type - DLEP_MESSAGE (Value TBD) Message Flags - Set to 0x1 (bit 3, mhasseqnum bit is set). All other bits are unused and MUST be set to '0'. Message Address Length - 0x0 Message Size - 31 + optional TLVs Message Sequence Number - A 16-bit unsigned integer field containing a sequence number generated by the message originator. TLV Block - TLV Length: 23 + optional Sub-TLVs DLEP Neighbor Down order Identification Sub-TLV (MANDATORY) MAC Address Sub-TLV (MANDATORY) Status Sub-TLV (OPTIONAL) 18. Neighbor Down ACK Message The router sends the Neighbor Down ACK Message to indicate whether a Neighbor Down Message was successfully processed. Ratliff et al. Expires November 2, 2011 [Page 34] Internet-Draft DLEP May 2011 The Neighbor Down ACK message contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type = |Msg Flg|AddrLen| Message Size | | DLEP_MESSAGE | 0x1 | 0x0 | 35 | | (value TBD) | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num |TLVs Length = 27 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DLEP Neighbor |TLV Flags=0x10 | Length = 24 | Sub-TLV type= | | Down ACK (TBD)| | | Identification| | | | | sub-TLV (TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x10 |Length = 8 | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | Client ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client ID |Sub-TLV type= |TLV Flags=0x10 | | |DLEP MAC | | | |sub-TLV (TBD) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Length = 6 | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address |Sub-TLV type= | | |DLEP Status | |(TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x10 | Length = 1 | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Type - DLEP_MESSAGE (Value TBD) Message Flags - Set to 0x1 (bit 3, mhasseqnum bit is set). All other bits are unused and MUST be set to '0'. Message Address Length - 0x0 Message Size - 35 Message Sequence Number - A 16-bit unsigned integer field containing the sequence number from the Neighbor Down Message that is being acknowledged. TLV Block - TLV Length: 27 DLEP Neighbor Down ACK order Identification Sub-TLV (MANDATORY) MAC Address Sub-TLV (MANDATORY) Status Sub-TLV (MANDATORY) Ratliff et al. Expires November 2, 2011 [Page 35] Internet-Draft DLEP May 2011 19. Neighbor Update Message The client sends the Neighbor Update message when a change in link metric parameters is detected for a routing neighbor. The Neighbor Update Message contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type = |Msg Flg|AddrLen| Message Size | | DLEP_MESSAGE | 0x1 | 0x0 | 31 + optional | | (value TBD) | | | sub-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num | TLVs Length = 23 + optional | | | Sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type = |TLV Flags=0x10 |Length = 20 + |Sub-TLV type = | |DLEP Neighbor | |optional Sub- |Identification | |Update (TBD) | |TLVs |Sub-TLV (TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x10 |Length = 8 | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | Client ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client ID |Sub-TLV type= |TLV Flags=0x10 | | |DLEP MAC | | | |sub-TLV (TBD) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Length = 6 | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address |Sub-TLV type= | | |DLEP MDR (TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x10 |Length = 8 | MDR (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MDR (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MDR (bps) |Sub-TLV Type = |TLV Flags=0x10 | | |DLEP CDR (TBD) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Length = 8 | CDR (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CDR (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CDR (bps) |Sub-TLV Type = |TLV Flags=0x10 | Length = 2 | | |DLEP Latency | | | | |(TBD) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Latency (ms) |Sub-TLV Type= |TLV Flags=0x10 | | |DLEP Resources | | | |(TBD) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Continued on next page) | Ratliff et al. Expires November 2, 2011 [Page 36] Internet-Draft DLEP May 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Continued from above) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length = 1 | Resources |Sub-TLV Type= |TLV FLags=0x10 | | | |DLEP RLQ (TBD) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length = 1 | RLQ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Type - DLEP_MESSAGE (Value TBD) Message Flags - Set to 0x1 (bit 3, mhasseqnum bit is set). All other bits are unused and MUST be set to '0'. Message Address Length - 0x0 Message Size - 31 + optional TLVs Message Sequence Number - A 16-bit unsigned integer field containing a sequence number, generated by the message originator. TLV Block - TLVs Length - 23 + optional Sub-TLVs. DLEP Neighbor Update order Identification Sub-TLV (MANDATORY) MAC Address Sub-TLV (MANDATORY) Maximum Data Rate Sub-TLV (OPTIONAL) Current Data Rate Sub-TLV (OPTIONAL) Latency Sub-TLV (OPTIONAL) Resources Sub-TLV (OPTIONAL) Relative Link Quality Sub-TLV (OPTIONAL) 20. Neighbor Address Update Message The client sends the Neighbor Address Update message when a change in Layer 3 addressing is detected for a routing neighbor. The Neighbor Address Update Message contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type = |Msg Flg|AddrLen| Message Size | | DLEP_MESSAGE | 0x1 | 0x0 | 31 + size of opt | | (value TBD) | | | sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num |TLVs Length =23 + opt sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Continued on next page) | Ratliff et al. Expires November 2, 2011 [Page 37] Internet-Draft DLEP May 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Continued from above) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DLEP Neighbor |TLV Flags=0x10 | Length =20 + | Sub-TLV type= | | Address Update| | opt sub-TLVs | Identification| |(TBD) | | | Sub-TLV (TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x10 |Length = 8 | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | Client ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client ID |Sub-TLV type= |TLV Flags=0x10 | | |DLEP MAC | | | |sub-TLV (TBD) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Length = 6 | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address |Sub-TLV type= | | |DLEP IPv4 (TBD)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x10 |Length = 5 | Add/Drop Ind. | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address |Sub-TLV type= | | |DLEP IPv6 (TBD)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x10 |Length = 17 | Add/Drop Ind. | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Type - DLEP_MESSAGE (Value TBD) Message Flags - Set to 0x1 (bit 3, mhasseqnum bit is set). All other bits are unused and MUST be set to '0'. Message Address Length - 0x0 Message Size - 31 + optional TLVs Message Sequence Number - A 16-bit unsigned integer field containing a sequence number, generated by the message originator. Ratliff et al. Expires November 2, 2011 [Page 38] Internet-Draft DLEP May 2011 TLV Block - TLVs Length - 23 + optional Sub-TLVs. DLEP Neighbor Address Update order Identification Sub-TLV (MANDATORY) MAC Address Sub-TLV (MANDATORY) IPv4 Address Sub-TLV (OPTIONAL) IPv6 Address Sub-TLV (OPTIONAL) 21. Neighbor Address Update ACK Message The router sends the Neighbor Address Update ACK Message to indicate whether a Neighbor Address Update Message was successfully processed. The Neighbor Address Update ACK message contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type = |Msg Flg|AddrLen| Message Size | | DLEP_MESSAGE | 0x1 | 0x0 | 35 | | (value TBD) | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num |TLVs Length = 27 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DLEP Neighbor |TLV Flags=0x10 | Length = 24 | Sub-TLV type= | | Address Update| | | Identification| | ACK (TBD) | | | sub-TLV (TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x10 |Length = 8 | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | Client ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client ID |Sub-TLV type= |TLV Flags=0x10 | | |DLEP MAC | | | |sub-TLV (TBD) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Length = 6 | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address |Sub-TLV type= | | |DLEP Status | |(TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x10 | Length = 1 | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Type - DLEP_MESSAGE (Value TBD) Message Flags - Set to 0x1 (bit 3, mhasseqnum bit is set). All other bits are unused and MUST be set to '0'. Message Address Length - 0x0 Ratliff et al. Expires November 2, 2011 [Page 39] Internet-Draft DLEP May 2011 Message Size - 35 Message Sequence Number - A 16-bit unsigned integer field containing the sequence number from the Neighbor Down Message that is being acknowledged. TLV Block - TLV Length: 27 DLEP Neighbor Address Update ACK order Identification Sub-TLV (MANDATORY) MAC Address Sub-TLV (MANDATORY) Status Sub-TLV (MANDATORY) 22. Heartbeat Message A Heartbeat Message is sent by a peer every N seconds, where N is defined in the "Heartbeat Interval" field of the discovery message. The message is used by peers to detect when a DLEP session partner is no longer communicating. Peers SHOULD allow some integral number of heartbeat intervals (default 4) to expire with no traffic on the session before initiating DLEP session termination procedures. The Heartbeat Message contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type = |Msg Flg|AddrLen| Message Size | | DLEP_MESSAGE | 0x1 | 0x0 | 22 | | (value TBD) | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num |TLVs Length = 14 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DLEP Heartbeat|TLV Flags=0x10 | Length = 11 | Sub-TLV type= | | (TBD) | | | Identification| | | | | sub-TLV (TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x10 |Length = 8 | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | Client ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Type - DLEP_MESSAGE (Value TBD) Message Flags - Set to 0x1 (bit 3, mhasseqnum bit is set). All other bits are unused and SHOULD be set to '0'. Message Address Length - 0x0 Message Size - 22 Ratliff et al. Expires November 2, 2011 [Page 40] Internet-Draft DLEP May 2011 Message Sequence Number - A 16-bit unsigned integer field containing a sequence number generated by the message originator. TLV Block - TLV Length = 14 DLEP Heartbeat order Identification Sub-TLV (MANDATORY) 23. Link Characteristics Request Message The Link Characteristics Request Message is sent by the router to the modem device when the router detects that a different set of transmission characteristics is necessary (or desired) for the type of traffic that is flowing on the link. The request contains either a Current Data Rate (CDR) TLV to request a different amount of bandwidth than what is currently allocated, a Latency TLV to request that traffic delay on the link not exceed the specified value, or both. A Link Characteristics ACK Message is required to complete the request. Implementations are free to define their retry heuristics in event of a timeout. Issuing a Link Characteristics Request with ONLY the MAC Address TLV is a mechanism a peer MAY use to request metrics (via the Link Characteristics ACK) from its partner. The Link Characteristics Request Message contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type = |Msg Flg|AddrLen| Message Size | | DLEP_MESSAGE | 0x1 | 0x0 | 31 + size of opt | | (value TBD) | | | sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num |TLVs Length =23 + opt sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DLEP Link Char|TLV Flags=0x10 | Length =20 + | Sub-TLV type= | | Request (TBD) | | opt sub-TLVs | Identification| | | | | Sub-TLV (TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x10 |Length = 8 | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | Client ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client ID |Sub-TLV type= |TLV Flags=0x10 | | |DLEP MAC | | | |sub-TLV (TBD) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Length = 6 | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Continued on next page) | Ratliff et al. Expires November 2, 2011 [Page 41] Internet-Draft DLEP May 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Continued from above) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address |Sub-TLV type= | | |DLEP CDR (TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x10 |Length = 8 | CDR (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CDR (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CDR (bps) |Sub-TLV Type= |TLV Flags=0x10 | | |Latency (TBD) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Length = 2 | Latency (ms) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Type - DLEP_MESSAGE (Value TBD) Message Flags - Set to 0x1 (bit 3, mhasseqnum bit is set). All other bits are unused and MUST be set to '0'. Message Address Length - 0x0 Message Size - 31 + length of optional (Current Data Rate and/or Latency) Sub-TLVs Message Sequence Number - A 16-bit unsigned integer field containing a sequence number generated by the message originator. TLV Block - Length: 23 + optional Sub-TLVs DLEP Link Characteristics Request order Identification Sub-TLV (MANDATORY) MAC Address Sub-TLV (MANDATORY) Current Data Rate Sub-TLV - if present, this value represents the requested data rate in bits per second (bps). (OPTIONAL) Latency TLV - if present, this value represents the maximum latency, in milliseconds, desired on the link. (OPTIONAL) 24. Link Characteristics ACK Message The Link Characteristics ACK Message is sent by the client to the router letting the router know the success (or failure) of the requested change in link characteristics. The Link Characteristics ACK message SHOULD contain a complete set of metric TLVs. It MUST Ratliff et al. Expires November 2, 2011 [Page 42] Internet-Draft DLEP May 2011 contain the same TLV types as the request. The values in the metric TLVs in the Link Characteristics ACK message MUST reflect the link characteristics after the request has been processed. The Link Characteristics ACK Message contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type = |Msg Flg|AddrLen| Message Size | | DLEP_MESSAGE | 0x1 | 0x0 | 31 + size of opt | | (value TBD) | | | sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num |TLVs Length =23 + opt sub-TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DLEP Link Char|TLV Flags=0x10 | Length =20 + | Sub-TLV type= | | ACK (TBD) | | opt sub-TLVs | Identification| | | | | Sub-TLV (TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x10 |Length = 8 | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | Client ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client ID |Sub-TLV type= |TLV Flags=0x10 | | |DLEP MAC | | | |sub-TLV (TBD) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Length = 6 | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address |Sub-TLV type= | | |DLEP MDR (TBD) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x10 |Length = 8 | MDR (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MDR (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MDR (bps) |Sub-TLV Type= |TLV Flags=0x10 | | |DLEP CDR (TBD) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Length = 8 | CDR (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CDR (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CDR (bps) |Sub-TLV Type = |TLV Flags=0x10 | Length = 2 | | |Latency (TBD) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Latency (ms) |Sub-TLV Type= |TLV Flags=0x10 | | |Resources (TBD)| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length = 1 | Resources |Sub-TLV Type= |TLV Flags=0x10 | | | |RLQ (TBD) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length = 1 | RLQ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ratliff et al. Expires November 2, 2011 [Page 43] Internet-Draft DLEP May 2011 Message Type - DLEP_MESSAGE (Value TBD) Message Flags - Set to 0x1 (bit 3, mhasseqnum bit is set). All other bits are unused and MUST be set to '0'. Message Address Length - 0x0 Message Size - 31 + length of optional (Current Data Rate and/or Latency) TLVs Message Sequence Number - A 16-bit unsigned integer field containing the sequence number that appeared on the corresponding Link Characteristics Request message. TLV Block - TLVs Length = 23 + Optional TLVs DLEP Link Characteristics ACK order Identification Sub-TLV (MANDATORY) MAC Address Sub-TLV (MANDATORY) Maximum Data Rate Sub-TLV (OPTIONAL) Current Data Rate Sub-TLV - if present, this value represents the NEW (or unchanged, if the request is denied) Current Data Rate in bits per second (bps). (OPTIONAL) Latency Sub-TLV - if present, this value represents the NEW maximum latency (or unchanged, if the request is denied), expressed in milliseconds, on the link. (OPTIONAL) Resources Sub-TLV (OPTIONAL) Relative Link Quality Sub-TLV (OPTIONAL) 25. Security Considerations The protocol does not contain any mechanisms for security (e.g. authentication or encryption). The protocol assumes that any security would be implemented in the underlying transport (for example, by use of DTLS or some other mechanism), and is therefore outside the scope of this document. 26. IANA Considerations This section specifies requests to IANA. Ratliff et al. Expires November 2, 2011 [Page 44] Internet-Draft DLEP May 2011 26.1 TLV Registrations This specification defines: o One TLV types which must be allocated from the 0-223 range of the "Assigned Message TLV Types" repository of [RFC5444]. o A new repository for DLEP orders, with seventeen values currently assigned. o A new repository for DLEP Sub-TLV assignments with fifteen values currently assigned. 26.2 Expert Review: Evaluation Guidelines For the registries for TLV type extensions where an Expert Review is required, the designated expert SHOULD take the same general recommendations into consideration as are specified by [RFC5444]. 26.3 Message TLV Type Registration The Message TLV specified below must be allocated from the "Message TLV Types" namespace of [RFC5444]. o DLEP_MESSAGE 26.4 DLEP Order Registration A new repository must be created with the values of the DLEP orders. Valid orders are: o Attached Peer Discovery Message o Detached Peer Discovery Message o Peer Offer Message o Peer Update Message o Peer Update ACK Message o Peer Termination Message o Peer Termination ACK Message o Neighbor Up Message o Neighbor Up ACK Message o Neighbor Down Message o Neighbor Down ACK Message o Neighbor Update Message o Neighbor Address Update Message o Neighbor Address Update ACK Message o Heartbeat Message o Link Characteristics Request Message o Link Characteristics ACK Message Ratliff et al. Expires November 2, 2011 [Page 45] Internet-Draft DLEP May 2011 This registry should be created according to the guidelines for 'Message-Type-Specific TLV' registration as specified in section 6.2.1 of [RFC5444]. 26.5 DLEP Sub-TLV Type Registrations A new repository for DLEP Sub-TLVs must be created. Valid Sub-TLVs are: o Identification Sub-TLV o DLEP Version Sub-TLV o Peer Type Sub-TLV o MAC Address Sub-TLV o IPv4 Address Sub-TLV o IPv6 Address Sub-TLV o Maximum Data Rate Sub-TLV o Current Data Rate Sub-TLV o Latency Sub-TLV o Resources Sub-TLV o Relative Link Quality Sub-TLV o Status Sub-TLV o Heartbeat Interval Sub-TLV o Heartbeat Threshold Sub-TLV o Link Characteristics ACK Timer Sub-TLV It is also requested that the registry allocation contain space reserved for experimental sub-TLVs. Ratliff et al. Expires November 2, 2011 [Page 46] Internet-Draft DLEP May 2011 27. Appendix A. Peer Level Message Flows *Modem Device (Client) Restarts Discovery Router Client Message Description ==================================================================== <-------Peer Discovery--------- Modem initiates discovery ---------Peer Offer-----------> Router detects a problem, sends w/ Non-zero Status TLV Peer Offer w/ Status TLV indicating the error. Modem accepts failure, restarts discovery process. <-------Peer Discovery--------- Modem initiates discovery ---------Peer Offer-----------> Router accepts, sends Peer Offer w/ Zero Status TLV w/ Status TLV indicating success. Discovery completed. *Modem Device Detects Peer Offer Timeout Router Client Message Description ==================================================================== <-------Peer Discovery--------- Modem initiates discovery, starts a guard timer. Modem guard timer expires. Modem restarts discovery process. <-------Peer Discovery--------- Modem initiates discovery, starts a guard timer. ---------Peer Offer-----------> Router accepts, sends Peer Offer w/ Zero Status TLV w/ Status TLV indicating success. Discovery completed. Ratliff et al. Expires November 2, 2011 [Page 47] Internet-Draft DLEP May 2011 *Router Peer Offer Lost Router Client Message Description ==================================================================== <-------Peer Discovery--------- Modem initiates discovery, starts a guard timer. ---------Peer Offer-------|| Router offers availability Modem times out on Peer Offer, restarts discovery process. <-------Peer Discovery--------- Modem initiates discovery ---------Peer Offer-----------> Router detects subsequent discovery, internally terminates the previous, accepts the new association, sends Peer Offer w/ Status TLV indicating success. Discovery completed. *Discovery Success Router Client Message Description ==================================================================== <-------Peer Discovery--------- Modem initiates discovery ---------Peer Offer-----------> 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 Ratliff et al. Expires November 2, 2011 [Page 48] Internet-Draft DLEP May 2011 *Router Detects a Heartbeat timeout Router Client Message Description ==================================================================== <-------Peer Heartbeat--------- -------Peer Heartbeat---------> ||---Peer Heartbeat--------- ~ ~ ~ ~ ~ ~ ~ -------Peer Heartbeat---------> ||---Peer Heartbeat--------- Router Heartbeat Timer expires, detects missing heartbeats. Router takes down all neighbor sessions and terminates the Peer association. ------Peer Terminate ---------> Peer Terminate Request Modem takes down all neighbor sessions, then acknowledges the Peer Terminate <----Peer Terminate ACK--------- Peer Terminate ACK *Modem Detects a Heartbeat timeout Router Client Message Description ==================================================================== <-------Peer Heartbeat--------- -------Peer Heartbeat------|| <-------Peer Heartbeat--------- ~ ~ ~ ~ ~ ~ ~ -------Peer Heartbeat------|| <-------Peer Heartbeat--------- Modem Heartbeat Timer expires, detects missing heartbeats. Modem takes down all neighbor sessions and terminates the Peer association. Ratliff et al. Expires November 2, 2011 [Page 49] Internet-Draft DLEP May 2011 <-------Peer Terminate-------- Peer Terminate Request Router takes down all neighbor sessions, then acknowledges the Peer Terminate ------Peer Terminate ACK-----> Peer Terminate ACK *Peer Terminate (from Modem) Lost Router Client Message Description ==================================================================== ||------Peer Terminate-------- Modem Peer Terminate Request Router Heartbeat times out, terminates association. --------Peer Terminate-------> Router Peer Terminate <-----Peer Terminate ACK------ Modem sends Peer Terminate ACK *Peer Terminate (from router) Lost Router Client Message Description ==================================================================== -------Peer Terminate--------> Router Peer Terminate Request Modem HB times out, terminates association. <------Peer Terminate-------- Modem Peer Terminate ------Peer Terminate ACK-----> Peer Terminate ACK Ratliff et al. Expires November 2, 2011 [Page 50] Internet-Draft DLEP May 2011 Neighbor Level Message Flows *Modem Neighbor Up Lost Router Client Message Description ==================================================================== ||-----Neighbor Up ------------ Modem sends Neighbor Up Modem timesout on ACK <------Neighbor Up ------------ Modem sends Neighbor Up ------Neighbor Up ACK---------> Router accepts the neighbor session <------Neighbor Update--------- Modem Neighbor Metrics . . . . . . . . <------Neighbor Update--------- Modem Neighbor Metrics *Router Detects Duplicate Neighbor Ups Router Client Message Description ==================================================================== <------Neighbor Up ------------ Modem sends Neighbor Up ------Neighbor Up ACK-------|| Router accepts the neighbor session Modem timesout on ACK <------Neighbor Up ------------ Modem resends Neighbor Up Router detects duplicate Neighbor, takes down the previous, accepts the new Neighbor. ------Neighbor Up ACK---------> Router accepts the neighbor session <------Neighbor Update--------- Modem Neighbor Metrics . . . . . . . . <------Neighbor Update--------- Modem Neighbor Metrics Ratliff et al. Expires November 2, 2011 [Page 51] Internet-Draft DLEP May 2011 *Neighbor Up, No Layer 3 Addresses Router Client Message Description ==================================================================== <------Neighbor Up ------------ Modem sends Neighbor Up ------Neighbor Up ACK---------> Router accepts the neighbor session Router ARPs for IPv4 if defined. Router drives ND for IPv6 if defined. <------Neighbor Update--------- Modem Neighbor Metrics . . . . . . . . <------Neighbor Update--------- Modem Neighbor Metrics *Neighbor Up with IPv4, No IPv6 Router Client Message Description ==================================================================== <------Neighbor Up ------------ Modem sends Neighbor Up with the IPv4 TLV ------Neighbor Up ACK---------> Router accepts the neighbor session Router drives ND for IPv6 if defined. <------Neighbor Update--------- Modem Neighbor Metrics . . . . . . . . <------Neighbor Update--------- Modem Neighbor Metrics *Neighbor Up with IPv4 and IPv6 Router Client Message Description ==================================================================== <------Neighbor Up ------------ Modem sends Neighbor Up with the IPv4 and IPv6 TLVs ------Neighbor Up ACK---------> Router accepts the neighbor session <------Neighbor Update--------- Modem Neighbor Metrics . . . . . . . . <------Neighbor Update--------- Modem Neighbor Metrics Ratliff et al. Expires November 2, 2011 [Page 52] Internet-Draft DLEP May 2011 *Neighbor Session Success Router Client Message Description ==================================================================== ---------Peer Offer-----------> Router offers availability -------Peer Heartbeat---------> <------Neighbor Up ----------- Modem ------Neighbor Up ACK--------> Router <------Neighbor Update--------- Modem . . . . . . . . <------Neighbor Update--------- Modem Modem initiates the terminate <------Neighbor Down ---------- Modem ------Neighbor Down ACK-------> Router or Router initiates the terminate ------Neighbor Down ----------> Router <------Neighbor Down ACK------- Modem Acknowledgements The authors would like to acknowledge the influence and contributions of Chris Olsen and Teco Boot. 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. Ratliff et al. Expires November 2, 2011 [Page 53] Internet-Draft DLEP May 2011 Informative References [DTLS] Rescorla, E., Ed,. "Datagram Transport Layer Security", RFC 4347, April 2006. Author's Addresses Stan Ratliff Cisco 170 West Tasman Drive San Jose, CA 95134 USA EMail: sratliff@cisco.com Bo Berry Cisco 170 West Tasman Drive San Jose, CA 95134 USA EMail: boberry@cisco.com Greg Harrison Cisco 170 West Tasman Drive San Jose, CA 95134 USA EMail: greharri@cisco.com Shawn Jury Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: sjury@cisco.com Darryl Satterwhite Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: dsatterw@cisco.com Ratliff et al. Expires November 2, 2011 [Page 54]