Mobile Ad hoc Networks Working S. Ratliff Group B. Berry Internet-Draft G. Harrison Intended status: Standards Track S. Jury Expires: January 12, 2011 D. Satterwhite Cisco Systems July 12, 2010 Dynamic Link Exchange Protocol (DLEP) draft-sratliff-dlep-00 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 January 11, 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 January 12, 2011 [Page 1] Internet-Draft DLEP July 2010 (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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Normal Session Flow . . . . . . . . . . . . . . . . . . . . . 4 4. Generic DLEP Packet Definition . . . . . . . . . . . . . . . . 5 5. Generic DLEP Message Format . . . . . . . . . . . . . . . . . 5 6. Generic DLEP TLV Block Format . . . . . . . . . . . . . . . . 6 7. DLEP TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Identification TLV . . . . . . . . . . . . . . . . . . . . 7 7.2. Authentication TLV . . . . . . . . . . . . . . . . . . . . 8 7.3. DLEP Version TLV . . . . . . . . . . . . . . . . . . . . . 9 7.4. Peer Type TLV . . . . . . . . . . . . . . . . . . . . . . 10 7.5. MAC Address TLV . . . . . . . . . . . . . . . . . . . . . 10 7.6. IPv4 Address TLV . . . . . . . . . . . . . . . . . . . . . 11 7.7. IPv6 Address TLV . . . . . . . . . . . . . . . . . . . . . 11 7.8. Link Metric TLV . . . . . . . . . . . . . . . . . . . . . 12 7.9. Peer Termination TLV . . . . . . . . . . . . . . . . . . . 13 7.10. Bandwidth Request TLV . . . . . . . . . . . . . . . . . . 13 7.11. Bandwidth Request ACK TLV . . . . . . . . . . . . . . . . 14 8. DLEP Packet Definition . . . . . . . . . . . . . . . . . . . . 15 9. Peer Discovery Messages . . . . . . . . . . . . . . . . . . . 15 9.1. Attached Peer Discovery Message . . . . . . . . . . . . . 16 9.2. Detached Peer Discovery Message . . . . . . . . . . . . . 16 10. Peer Offer Message . . . . . . . . . . . . . . . . . . . . . . 17 11. Peer Termination . . . . . . . . . . . . . . . . . . . . . . . 18 12. Neighbor Up Message . . . . . . . . . . . . . . . . . . . . . 20 13. Neighbor Down Message . . . . . . . . . . . . . . . . . . . . 21 14. Neighbor Update Message . . . . . . . . . . . . . . . . . . . 22 15. Heartbeat Message . . . . . . . . . . . . . . . . . . . . . . 23 16. Bandwidth Request Message . . . . . . . . . . . . . . . . . . 24 17. Bandwidth Request ACK Message . . . . . . . . . . . . . . . . 24 18. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Ratliff et al. Expires January 12, 2011 [Page 2] Internet-Draft DLEP July 2010 1. Overview There exist today a collection of modem devices that control links of variable bandwidth and quality. Examples of these types of links include line-of-sight (LOS) radios, satellite terminals, and cable/ DSL modems. Fluctuations in speed and quality of these links can occur due to configuration (in the case of cable/DSL modems), or on a moment-to-moment basis, due to physical phenomena like multipath interference, obstructions, rain fade, etc. It is also quite possible that link quality and bandwidth varies with respect to individual neighbors on a link, and with the type of traffic being sent. As an example, consider the case of an 802.11g access point, serving 2 associated laptop computers. In this environment, the answer to the question "What is the bandwidth on the 802.11g link?" is "It depends on which associated laptop we're talking about, and on what kind of traffic is being sent." While the first laptop, being physically close to the access point, may have a bandwidth of 54Mbps for unicast traffic, the other laptop, being relatively far away, or obstructed by some object, can simultaneously have a bandwidth of only 32Mbps for unicast. However, for multicast traffic sent from the access point, all traffic is sent at the base transmission rate (which is configurable, but depending on the model of the access point, is usually 24Mbps or less). In addition to utilizing variable bandwidth links, mobile networks are challenged by the notion that link connectivity will come and go over time. Effectively utilizing a relatively short-lived connection is problematic in IP routed networks, as routing protocols tend to rely on independent timers at OSI Layer 3 to maintain network convergence (e.g. HELLO messages and/or recognition of DEAD routing adjacencies). These short-lived connections can be better utilized with an event-driven paradigm, where acquisition of a new neighbor (or loss of an existing one) is somehow signaled, as opposed to a timer-driven paradigm. Another complicating factor for mobile networks are the different methods of physically connecting the modem devices to the router. Modems can be deployed as an interface card in a router's chassis, or as a standalone device connected to the router via Ethernet, USB, or even a serial link. In the case of Ethernet or serial attachment, with existing protocols and techniques, routing software cannot be aware of convergence events occurring on the radio link (e.g. acquisition or loss of a potential routing neighbor), nor can the router be aware of the actual capacity of the link. This lack of awareness, along with the variability in bandwidth, leads to a situation where quality of service (QoS) profiles are extremely difficult to establish and properly maintain. This is especially true of demand-based access schemes such as Demand Assigned Multiple Access (DAMA) implementations used on some satellite systems. With a DAMA-based system, additional bandwidth may be available, but will not be used unless the network devices emit traffic at rate higher than the currently established rate. Increasing the traffic rate does not guarantee additional bandwidth will be allocated; rather, it may result in data loss and additional retransmissions on the link. Ratliff et al. Expires January 12, 2011 [Page 3] Internet-Draft DLEP July 2010 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). DLEP exists as a collection of type-length-value (TLV) based messages formatted using RFC 5444. 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 interfaces), or supports connections to multiple routers, a separate DLEP session MUST exist for each connection. 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. 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 provides the ability for authentication between session partners, using a shared secret approach and an Authentication TLV. Authentication is OPTIONAL. DLEP assumes that if encryption of its traffic is required, the encryption/decryption would be dealt with by the underlying transport mechanism for the RFC 5444 packets (e.g. by using a transport such as DTLS). The RFC 5444 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. Ratliff et al. Expires January 12, 2011 [Page 4] Internet-Draft DLEP July 2010 During this exchange, the session partners negotiate whether or not authentication is required. 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. 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 from its client, via the "Bandwidth Request" TLV in a "Neighbor Update" message. This allows the router to request an increase (or decrease) of allocated bandwidth 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 RFC 5444. 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 TLV Block | Messages... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version - Version of RFC5444 specification on which the packet/ messages/TLVs are constructed. Flags - 4 bit field. Only bit 1 (phastlv) is set/used, all other bits SHOULD be set to '0'. Packet TLV block - a TLV block which contains packet level TLV information. Message - the packet MAY contain zero or more messages. 5. Generic DLEP Message Format The Generic DLEP Message Format follows the format for MANET messages defined in RFC 5444. The field, which is OPTIONAL in RFC 5444, MUST exist in all DLEP messages. Ratliff et al. Expires January 12, 2011 [Page 5] Internet-Draft DLEP July 2010 The Generic DLEP Message Format 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num | TLV Block... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Type - an 8-bit field which specifies the type of the message Message Flags - Set to 0x8 (bit 3, msg-has-seqnum bit is set). No other bits are used and SHOULD be set to '0'. Message Address Length - a 4-bit unsigned integer field encoding the length of all addresses included in this message. Set to length of address - 1 (e.g. 3 for IPv4, 15 for IPv6) 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. Generic DLEP TLV Block Format The Generic DLEP TLV Block Format follows the format for MANET message TLVs defined in RFC 5444. The Generic DLEP TLV Block Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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. Ratliff et al. Expires January 12, 2011 [Page 6] Internet-Draft DLEP July 2010 TLV Flags - an 8-bit flags bit field. Only bit 3 (thasvalue) is set, all other bits are not used and SHOULD 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. 7. DLEP TLVs TLV TLV Value Description ========================================= TBD Identification TLV TBD SHA-2 256 Authentication TLV TBD SHA-2 384 Authentication TLV TBD SHA-2 512 Authentication TLV TBD DLEP Version TLV TBD Peer Type TLV TBD MAC Address TLV TBD IPv4 Address TLV TBD IPv6 Address TLV TBD Link Metric TLV TBD Session Termination TLV TBD Bandwidth Request TLV TBD Bandwidth Reqeust ACK TLV 7.1 Identification TLV This TLV MUST be the in the Packet Header TLV Block for all DLEP messages. It contains client and router identification information used for all messages contained within the packet. The Identification 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=0x08 |Length = 9 | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | Client ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client ID | Dead Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type - Value TBD TLV Flags - 0x08, Bit 3 (thasvalue) is set, all other bits are not used and SHOULD be set to '0'. Length - length of this TLV is 9 Ratliff et al. Expires January 12, 2011 [Page 7] Internet-Draft DLEP July 2010 Router ID - indicates the router ID of the DLEP session, set to '0' when unknown. Client ID - indicates the client ID of the DLEP session, set to '0' when unknown. 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. Dead Interval - An 8-bit, unsigned value containing the maximum number of seconds during which no messages can be received before determining that the session is dead. A value of '0' indicates that the field is ignored. This value is used during the Peer Discovery/Peer Offer exchange. In other packets, the value is ignored. 7.2 Authentication TLV The Authentication TLV is used in all DLEP messages when authentication is mutually agreed upon between the router and client. When authentication is used, the TLV MUST be present in the Packet Header so that the authentication of the sender is checked as early as possible. The authentication TLV MUST be the first TLV of the TLV block, and the authentication MUST start at the Identification TLV and be run over the remaining contents of the packet. The hashed result is checked at the receiver to authenticate the sender. If the authentication fails, the message MUST be dropped. The Authentication 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type(256)=TBD |TLV Flags=0x08 |Length=35 (256)| Key Index | |Type(384)=TBD | |Length=51 (384)| | |Type(512)=TBD | |Length=67 (512)| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Length | Digest (32 bytes for 256) | | | (48 bytes for 384) | | | (64 bytes for 512) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ratliff et al. Expires January 12, 2011 [Page 8] Internet-Draft DLEP July 2010 The TLV contains the following fields: TLV Type - TBD for SHA-2 256 authentication TBD for SHA-2 384 authentication TBD for SHA-2 512 authentication TLV Flags - 0x08 Bit 3 (thasvalue) is set, all other bits are not used and SHOULD be set to '0'. Length - Length is 35 for SHA-2 256 authentication Length is 51 for SHA-2 384 authentication Length is 67 for SHA-2 512 authentication Key Index - The index value for implementations that have multiple keys. A value of zero ('0') means first or only key. Message Length - Length of the data starting with the Identification TLV and including this TLV and all messages in the packet that follow, that the authentication hash is run across. Digest - Before the hash is run, the digest field contains the shared secret. After the hash is run, the result is placed in the digest field. 7.3 DLEP Version TLV The DLEP Version TLV is OPTIONAL, and 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 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=0x08 |Length=4 | Major Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Major Version | Minor Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type - TBD TLV Flags - 0x08, Bit 3 (thasvalue) is set, all other bits are not used and SHOULD 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. Ratliff et al. Expires January 12, 2011 [Page 9] Internet-Draft DLEP July 2010 Support of this draft is indicated by setting the Major Version to '1', and the Minor Version to '0' (e.g. Version 1.0). 7.4 Peer Type TLV The Peer Type TLV is used by the router and client to give additional information as to its type. It is an OPTIONAL 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 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=0x08 |Length= peer |Peer Type Str | | | |type string len|Max Len = 80 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type - TBD TLV Flags - 0x08, Bit 3 (thasvalue) is set, all other bits are not used and SHOULD 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.5 MAC Address TLV The MAC address TLV MUST appear in Neighbor Up, Neighbor Down, and Neighbor Update Messages. The MAC Address TLV contains the address of the far-end (partner) router. The MAC Address TLV contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |TLV Flags=0x08 |Length = 6 |MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | +-+-+-+-+-+-+-+-+ TLV Type - TBD TLV Flags - 0x08, Bit 3 (thasvalue) is set, all other bits are not used and SHOULD be set to '0'. Ratliff et al. Expires January 12, 2011 [Page 10] Internet-Draft DLEP July 2010 Length - 6 MAC Address - MAC Address of the far-end router. 7.6 IPv4 Address TLV The IPv4 Address TLV MAY be used in client Neighbor Up, Neighbor Down, and Neighbor Update Messages, if the client is aware of the address. When included, the IPv4 Address TLV contains the IPv4 address of the far-end router (neighbor). The IPv4 Address TLV contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |TLV Flags=0x08 |Length = 4 |IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type - TBD TLV Flags - 0x08, Bit 3 (thasvalue) is set, all other bits are not used and SHOULD be set to '0'. Length - 4 IPv4 Address - IPv4 Address of the far-end router. 7.7 IPv6 Address TLV The IPv6 Address TLV MAY be used in client Neighbor Up, Neighbor Down, and Neighbor Update Messages, if the client is aware of the address. When included, the IPv6 Address TLV contains the IPv6 address of the far-end router (neighbor). The IPv6 Address TLV contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |TLV Flags=0x08 |Length = 4 |IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ratliff et al. Expires January 12, 2011 [Page 11] Internet-Draft DLEP July 2010 TLV Type - TBD TLV Flags - 0x08, Bit 3 (thasvalue) is set, all other bits are not used and SHOULD be set to '0'. Length - 16 IPv6 Address - IPv6 Address of the far-end router. 7.8 Link Metric TLV The Link Metric TLV is used in client Neighbor Up and Neighbor Update Messages to indicate the link metrics associated with the link between the radio and a neighbor. The Link Metric 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=0x08 |Length = 4 |MDR (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MDR (bps) |CDR (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CDR (bps) | Latency (ms) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Latency (ms) | Resources | Relative Link | | | | Quality | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type - TBD TLV Flags - 0x08, Bit 3 (thasvalue) is set, all other bits are not be used and SHOULD be set to '0'. Length - 12 Maximum Data Rate - the maximum theoretical data rate, in bits per second (bps), achieved on the link. When metrics are reported, the maximum data rate MUST be reported. Current Data Rate - the current data rate, in bits per second (bps), achieved on the link. If there is no distinction between maximum and current data rate, current data rate SHOULD be set equal to the maximum data rate. Latency - the transmission delay that a packet encounters as it is transmitted over the link. This is reported in absolute delay, in milliseconds. If latency cannot be calculated, a value of 0 should be reported. Ratliff et al. Expires January 12, 2011 [Page 12] Internet-Draft DLEP July 2010 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. 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. The above metrics are consistent with RFC 5578 [2]. 7.9 Peer Termination TLV The Peer Termination TLV is sent from either the client or router to tear down a DLEP session. The Peer Termination 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=0x08 |Length = 1 | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type - TBD TLV Flags - 0x08, Bit 3 (thasvalue) is set, all other bits are not used and SHOULD be set to '0'. Length - 1 Termination Code - values are decimal 0 = Normal Termination 1 = Message Timeout 2 = State Mismatch 3 = Authentication Error 4 = Resource Error 5 = Unsupported Version 6 = Unknown TLV Type 7 = TLV Length Error 8 = Message Format Error 9 = NACK During Resend 10 = Invalid TLV Type 7.10 Bandwidth Request TLV The Bandwidth Request TLV is sent by the router to request from the client a specific amount of bandwidth. Ratliff et al. Expires January 12, 2011 [Page 13] Internet-Draft DLEP July 2010 The Bandwidth Request 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=0x08 |Length = 4 |Request DR(bps)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request DR(bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type - TBD TLV Flags - 0x08, Bit 3 (thasvalue) is set, all other bits are not used and SHOULD be set to '0'. Length - 4 Data Rate Requested - Requested bandwidth (data rate) in bps. The requested rate may be either an increase or decrease of the current bandwidth on the link. 7.11 Bandwidth Request ACK TLV The Bandwidth Request ACK TLV is sent by the client to the router in response to a bandwidth request. The Bandwidth Request ACK 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=0x08 |Length = 4 |Request DR(bps)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request DR(bps) |Granted DR(bps)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Granted DR(bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type - TBD TLV Flags - 0x08, Bit 3 (thasvalue) is set, all other bits are not used and SHOULD be set to '0'. Length - 4 Data Rate Requested - Requested bandwidth (data rate) in bps. Data Rate Granted - Granted bandwidth (data rate) in bps. Ratliff et al. Expires January 12, 2011 [Page 14] Internet-Draft DLEP July 2010 8. DLEP Packet Definition The DLEP Packet 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 | TLVs Length = 12 + | Identification| | 0x0 | 0x2 | opt Authentication TLV | TLV Type = TBD| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x08 | Length = 9 | Server (Router) ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Server (Router) ID | Client (Radio) ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client (Radio) ID | Dead Interval |Auth. Type=TBD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x08 |Length is based| Key Index | Message | | |on auth type | | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message | Digest (32 bytes for SHA-2 256, 48 bytes for | | Length | SHA-2 384, 64 bytes for SHA-2 512) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message (DLEP Packet can contain one or more messages) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version - Version of RFC5444 specification on which the packet/ messages/TLVs are constructed. Flags - 0x2 Only bit 1 (phastlv) is set/used, all other bits are not used and SHOULD be set to '0'. Packet Header TLV Block which contains: Identification TLV Authentication TLV (optional) Message - the packet may contain zero or more messages. 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. Ratliff et al. Expires January 12, 2011 [Page 15] Internet-Draft DLEP July 2010 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 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 | | = TBD | 0x8 | 0x3 |15 + size of opt Peer Type TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num | TLVs Length = 7 + opt TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DLEP Version |TLV Flags=0x08 | Length = 4 | Major Version | | TLV Type = TBD| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Major Version | Minor Version | Peer Type TLV | | | | Type = TBD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x08 | Length = Len | Peer Type Str | | |of peer string |MaxLen=80 bytes| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attached Peer Discovery Message - TBD Message Flags - Set to 0x8 (bit 3, msg-has-seqnum bit is set). No other bits are not used and SHOULD be set to '0'. Message Address Length - 0x3 Message Size - 15 + size of optional Peer Type TLV Message Sequence Number - a 16-bit unsigned integer field containing a sequence number generated by the message’ originator. TLV Block - TLVs Length: 7 + size of OPTIONAL Peer Type TLV. DLEP Version TLV Peer Type TLV (OPTIONAL) 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. Ratliff et al. Expires January 12, 2011 [Page 16] Internet-Draft DLEP July 2010 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 | | = TBD | 0x8 | 0x3 |15 + size of opt Peer Type TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num | TLVs Length = 7 + opt TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DLEP Version |TLV Flags=0x08 | Length = 4 | Major Version | | TLV Type = TBD| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Major Version | Minor Version | Peer Type TLV | | | | Type = TBD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x08 | Length = Len | Peer Type Str | | |of peer string |MaxLen=80 bytes| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Detached Peer Discovery Message Type - TBD Message Flags - Set to 0x8 (bit 3, msg-has-seqnum bit is set). All other bits are not used and SHOULD be set to '0'. Message Address Length - 0x3 Message Size - 15 + size of optional Peer Type TLV Message Sequence Number - A 16-bit unsigned integer field containing a sequence number, generated by the message’ originator. TLV Block - TLVs Length: 7 + size of optional Peer Type TLV. DLEP Version TLV Peer Type 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. Ratliff et al. Expires January 12, 2011 [Page 17] Internet-Draft DLEP July 2010 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 | | = TBD | 0x8 | 0x3 |15 + size of opt Peer Type TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num | TLVs Length = 7 + opt TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DLEP Version |TLV Flags=0x08 | Length = 4 | Major Version | | TLV Type = TBD| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Major Version | Minor Version | Peer Type TLV | | | | Type = TBD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x08 | Length = Len | Peer Type Str | | |of peer string |MaxLen=80 bytes| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Peer Offer Message Type - TBD Message Flags - Set to 0x8 (bit 3, msg-has-seqnum bit is set). All other bits are unused and SHOULD be set to '0'. Message Address Length - 0x3 Message Size - 15 + size of optional Peer Type TLV Message Sequence Number - A 16-bit unsigned integer field containing a sequence number, generated by the message’ originator. TLV Block - TLV Length: 7 + size of optional Peer Type TLV. DLEP Version TLV Peer Type TLV (OPTIONAL) 11. Peer Termination Message The Peer Termination Message is sent by either the client or the router when a session needs to be terminated. Ratliff et al. Expires January 12, 2011 [Page 18] Internet-Draft DLEP July 2010 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 | | = TBD | 0x8 | 0x3 | 12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num | TLVs Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer Terminate|TLV Flags=0x08 | Length = 1 | Code | | TLV Type = TBD| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Peer Termination Message Type - TBD Message Flags - Set to 0x8 (bit 3, msg-has-seqnum bit is set). All other bits are unused and SHOULD be set to '0'. Message Address Length - 0x3 Message Size - 12 Message Sequence Number - A 16-bit unsigned integer field containing a sequence number generated by the message’ originator. TLV Block - TLV Length: 4. Peer Termination TLV Ratliff et al. Expires January 12, 2011 [Page 19] Internet-Draft DLEP July 2010 12. Neighbor Up Message The client sends the Neighbor Up message to report that a new potential routing neighbor has been detected. 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 | | = TBD | 0x8 | 0x3 | 32 + opt TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num | TLVs Length = 24 + opt TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |TLV Flags=0x08 |Length = 6 |MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address |TLV Type =TBD |TLV Flags=0x08 |Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |TLV Flags=0x08 |Length = 4 |IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address |TLV Type =TBD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x08 |Length = 4 | MDR (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MDR (bps) | CDR (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CDR (bps) | Latency (in milliseconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resources | Relative Link | | | Factor | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Neighbor Up Message Type - TBD Message Flags - Set to 0x8 (bit 3, msg-has-seqnum bit is set). All other bits are unused and SHOULD be set to '0'. Message Address Length - 0x3 Message Size - 32 + optional TLVs Ratliff et al. Expires January 12, 2011 [Page 20] Internet-Draft DLEP July 2010 Message Sequence Number - A 16-bit unsigned integer field containing a sequence number generated by the message’ originator. TLV Block - TLV Length: 24 + optional TLVs. MAC Address TLV IPv4 Address TLV (OPTIONAL) IPv6 Address TLV (OPTIONAL) Link Metrics TLV 13. 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 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 | | = TBD | 0x8 | 0x3 | 17 + opt TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num | TLVs Length = 9 + opt TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |TLV Flags=0x08 |Length = 6 |MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address |TLV Type =TBD |TLV Flags=0x08 |Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |TLV Flags=0x08 |Length = 4 |IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Neighbor Down Message Type - TBD Message Flags - Set to 0x8 (bit 3, msg-has-seqnum bit is set). All other bits are unused and SHOULD be set to '0'. Message Address Length - 0x3 Message Size - 17 + optional TLVs Ratliff et al. Expires January 12, 2011 [Page 21] Internet-Draft DLEP July 2010 Message Sequence Number - A 16-bit unsigned integer field containing a sequence number generated by the message’ originator. TLV Block - TLV Length: 9 + optional TLVs. MAC Address TLV IPv4 Address TLV (optional) IPv6 Address TLV (optional) 14. 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 | | = TBD | 0x8 | 0x3 | 32 + opt TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num | TLVs Length = 24 + opt TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |TLV Flags=0x08 |Length = 6 |MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address |TLV Type =TBD |TLV Flags=0x08 |Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |TLV Flags=0x08 |Length = 4 |IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address |TLV Type =TBD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Flags=0x08 |Length = 4 | MDR (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MDR (bps) | CDR (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CDR (bps) | Latency (in milliseconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resources | Relative Link | | | Factor | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ratliff et al. Expires January 12, 2011 [Page 22] Internet-Draft DLEP July 2010 Neighbor Update Message Type - TBD Message Flags - Set to 0x8 (bit 3, msg-has-seqnum bit is set). All other bits are unused and SHOULD be set to '0'. Message Address Length - 0x3 Message Size - 32 + optional TLVs Message Sequence Number - A 16-bit unsigned integer field containing a sequence number, generated by the message’ originator. TLV Block - TLVs Length - 24 + optional TLVs. MAC Address TLV IPv4 Address TLV (optional) IPv6 Address TLV (optional) Link Metrics TLV 15. Heartbeat Message A Heartbeat Message is sent by the client every N seconds where a Neighbor Update message is not sent. The message is used by the router to detect when the client is no longer communicating. When the router's (N * 2) timeout expires indicating no client message received in that timeframe, the router initiates 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 = 8 | | = TBD | 0x8 | 0x3 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num | TLVs Length = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Type - TBD Heartbeat Message Flags - Set to 0x8 (bit 3, msg-has-seqnum bit is set). All other bits are unused and SHOULD be set to '0'. Message Address Length - 0x3 Message Size - 8 Message Sequence Number - A 16-bit unsigned integer field containing a sequence number generated by the message’ originator. Ratliff et al. Expires January 12, 2011 [Page 23] Internet-Draft DLEP July 2010 TLV Block - TLVs Length - 0 16. Bandwidth Request Message The Bandwidth Request Message is sent by the server to the client when the router detects that a different amount of bandwidth is necessary for the type of traffic that is flowing thorugh the router than what is currently allocated to the server. The request contains the desired amount of bandwidth in bps. The Bandwidth 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 = 15 | | = TBD | 0x8 | 0x3 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num | TLVs Length = 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |TLV Flags=0x08 |Length = 4 |Request DR(bps)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request DR(bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Type = TBD Heartbeat Message Flags - Set to 0x8 (bit 3, msg-has-seqnum bit is set). All other bits are unused and SHOULD be set to '0'. Message Address Length - 0x3 Message Size - 15 Message Sequence Number - A 16-bit unsigned integer field containing a sequence number generated by the message’ originator. TLV Block - TLVs Length - 7 Bandwidth Request TLV 17. Bandwidth Request ACK Message The Bandwidth Request ACK Message is sent by the client to the router letting the router know the success (or failure) of the requested bandwidth allocation. The response contains the amount of bandwidth that was originally requested along with the the current bandwidth setting (which may or may not be what was requested). Ratliff et al. Expires January 12, 2011 [Page 24] Internet-Draft DLEP July 2010 The Bandwidth Request 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 = 19 | | = TBD | 0x8 | 0x3 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Seq Num | TLVs Length = 11 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |TLV Flags=0x08 |Length = 4 |Request DR(bps)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request DR(bps) |Granted DR(bps)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Granted DR(bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Message Type - TBD Heartbeat Message Flags - Set to 0x8 (bit 3, msg-has-seqnum bit is set). All other bits are unused and SHOULD be set to '0'. Message Address Length - 0x3 Message Size - 19 Message Sequence Number - The 16-bit sequence number from the corresponding Bandwidth Request message. TLV Block - TLVs Length - 11 Bandwidth Request ACK TLV Ratliff et al. Expires January 12, 2011 [Page 25] Internet-Draft DLEP July 2010 18. Appendix A. Peer Level Message Flows Router Client Message Description ==================================================================== <-------Peer Discovery--------- Radio initiates discovery ---------Peer Offer-----------> Router offers availability <-------Peer Heartbeat--------- -------Peer Heartbeat---------> <==============================> Neighbor Sessions <-------Peer Heartbeat--------- -------Peer Heartbeat---------> --------Peer Term Req---------> Terminate Request <--------Peer Term Res--------- Terminate Response Neighbor Level Message Flows Router Client Message Description ==================================================================== <------Neighbor Up Req-------- Radio ------Neighbor Up Res--------> Router <------Neighbor Update--------- Radio . . . . . . . . <------Neighbor Update--------- Radio Radio initiates the terminate <------Neighbor Down Req------- Radio ------Neighbor Down Res-------> Router or Router initiates the terminate ------Neighbor Down Req-------> Router <------Neighbor Down Res------- Radio Ratliff et al. Expires January 12, 2011 [Page 26] Internet-Draft DLEP July 2010 Acknowledgements The authors would like to acknowledge the influence and contributions of Chris Olsen and Teco Boot. Normative References [1] Clausen, T., Ed,. "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format", RFC 5444, Februar, 2009. [2] Berry, B., Ed., "PPPoE with Credit Flow and Metrics", RFC 5578, February 2010. 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