Mobile Ad hoc Networks Working Group S. RatliffGroup Independent ConsultantInternet-DraftB. BerryVT iDirect Intended status: Standards TrackG. HarrisonB. Berry Expires:April 2,August 31, 2015 S. Jury Cisco Systems D. Satterwhite BroadcomOctober 24, 2014R. Taylor Airbus Defence & Space February 27, 2015 Dynamic Link Exchange Protocol (DLEP)draft-ietf-manet-dlep-07draft-ietf-manet-dlep-08 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 ofthisThis Memo This Internet-Draft is submittedto IETFin 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.(IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts.Drafts is at http://datatracker.ietf.org/drafts/current/. 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 August14, 2014.31, 2015. Copyright Notice Copyright (c)20122015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . ..41.11.1. Requirements . . . . . . . . . . . . . . . . . . . . . ..8 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . ..8 3.Mandatory VersusCore Features and OptionalItemsExtensions . . . . . . . . . . . . 10 3.1. Negotiation of Optional Extensions . . . .9 4. Credits. . . . . . . 10 3.2. Protocol Extensions . . . . . . . . . . . . . . . . . . . 10 3.3. Experimental Signals and Data Items . .10 5. Metrics. . . . . . . . . 11 4. Metrics . . . . . . . . . . . . . . . . . . .10 6. Extensions to DLEP. . . . . . . . 11 4.1. Mandatory Metrics . . . . . . . . . . . . . .11 6.1 Protocol Extensions. . . . . . 12 5. Normal Session Flow . . . . . . . . . . . . . .11 6.2 Vendor Extensions. . . . . . . 12 5.1. DLEP Router session flow - Discovery case . . . . . . . . 13 5.2. DLEP Router session flow - Configured case . . . . . .11 6.3 Experimental Extensions. 13 5.3. DLEP Modem session flow . . . . . . . . . . . . . . . . .11 7. Normal14 5.4. Common Session Flow . . . . . . . . . . . . . . . . . . . 14 6. DLEP Message Processing . .12 7.1 DLEP Router session flow - Discovery case. . . . . . . . .12 7.2. . . . . . . . 15 6.1. DLEPRouter session flow - Configured caseSignal Header . . . . . . . . .12 7.3. . . . . . . . . . 16 6.2. DLEPModem session flowGeneric Data Item . . . . . . . . . . . . . . . . . 16 7. DLEP Signals .13 7.4 Common Session Flow. . . . . . . . . . . . . . . . . . . .14 8. Mandatory Signals and Data Items. . . 17 7.1. Peer Discovery Signal . . . . . . . . . . . .14 9. Generic DLEP Signal Definition. . . . . . 17 7.2. Peer Offer Signal . . . . . . . . . .16 10. DLEP Data Items. . . . . . . . . . 18 7.3. Peer Initialization Signal . . . . . . . . . . . . .16 10.1 DLEP Version. . 19 7.4. Peer Initialization ACK Signal . . . . . . . . . . . . . 20 7.5. Peer Update Signal . . . . . . . . . . . .17 10.2 DLEP Port. . . . . . . 21 7.6. Peer Update ACK Signal . . . . . . . . . . . . . . . . .18 10.322 7.7. PeerTypeTermination Signal . . . . . . . . . . . . . . . . . 23 7.8. Peer Termination ACK Signal . . . . . . .18 10.4 MAC Address. . . . . . . . 23 7.9. Destination Up Signal . . . . . . . . . . . . . . . .19 10.5 IPv4 Address. . 24 7.10. Destination Up ACK Signal . . . . . . . . . . . . . . . . 25 7.11. Destination Down Signal . . . . . .19 10.6 IPv6 Address. . . . . . . . . . . 26 7.12. Destination Down ACK Signal . . . . . . . . . . . .20 10.7 Maximum Data Rate (Receive). . . 26 7.13. Destination Update Signal . . . . . . . . . . . .21 10.8 Maximum Data Rate (Transmit). . . . 26 7.14. Heartbeat Signal . . . . . . . . . . .22 10.9 Current Data Rate (Receive). . . . . . . . . 28 7.15. Link Characteristics Request Signal . . . . . .22 10.10 Current Data Rate (Transmit). . . . . 28 7.16. Link Characteristics ACK Signal . . . . . . . . .23 10.11 Latency. . . . 29 8. DLEP Data Items . . . . . . . . . . . . . . . . . . . . .24 10.12 Resources (Receive). . 30 8.1. DLEP Version . . . . . . . . . . . . . . . . .25 10.13 Resources (Transmit). . . . . 31 8.2. Status . . . . . . . . . . . . .25 10.14 Relative Link Quality (Receive). . . . . . . . . . . . 32 8.3. DLEP Port .26 10.15 Relative Link Quality (Transmit). . . . . . . . . . . .27 10.16 Status. . . . . . . . . . . 33 8.4. Peer Type . . . . . . . . . . . . . .27 10.17 Heartbeat Interval. . . . . . . . . . 33 8.5. Heartbeat Interval . . . . . . . . .28 10.18 Link Characteristics ACK Timer. . . . . . . . . . 34 8.6. Extensions Supported . . .28 10.19 Credit Window Status. . . . . . . . . . . . . . . 35 8.7. Experimental Definition . . .29 10.20 Credit Grant Request. . . . . . . . . . . . . . 35 8.8. MAC Address . . . .30 10.21 Credit Request. . . . . . . . . . . . . . . . . . . 36 8.9. IPv4 Address . .31 10.22 DLEP Optional Signals Supported. . . . . . . . . . . . .31 10.23 DLEP Optional Data Items Supported. . . . . . . 37 8.10. IPv6 Address . . . .32 10.24 DLEP Vendor Extension. . . . . . . . . . . . . . . . . .33 10.2537 8.11. IPv4 Attached Subnet . . . . . . . . . . . . . . . . . .33 10.2638 8.12. IPv6 Attached Subnet . . . . . . . . . . . . . . . . . .34 11. DLEP Protocol Signals . . . .39 8.13. Maximum Data Rate (Receive) . . . . . . . . . . . . . . . 39 8.14. Maximum Data Rate (Transmit) .35 11.1 Signal TLV Values. . . . . . . . . . . . . 40 8.15. Current Data Rate (Receive) . . . . . . .35 11.2 Peer Discovery Signal. . . . . . . . 41 8.16. Current Data Rate (Transmit) . . . . . . . . . . .36 11.3 Peer Offer Signal. . . 41 8.17. Latency . . . . . . . . . . . . . . . . . .36 11.4 Peer Initialization Signal. . . . . . . 42 8.18. Resources (Receive) . . . . . . . . .37 11.5 Peer Initialization ACK Signal. . . . . . . . . . 43 8.19. Resources (Transmit) . . . .37 11.6 Peer Update Signal. . . . . . . . . . . . . . 43 8.20. Relative Link Quality (Receive) . . . . . .38 11.7 Peer Update ACK Signal. . . . . . . 44 8.21. Relative Link Quality (Transmit) . . . . . . . . . . .39 11.8 Peer Termination Signal. 45 8.22. Link Characteristics ACK Timer . . . . . . . . . . . . . 45 9. Credit-Windowing . . . .40 11.9 Peer Termination ACK Signal. . . . . . . . . . . . . . . .40 11.10 Destination Up Signal. . 46 9.1. Credit-Windowing Signals . . . . . . . . . . . . . . . .40 11.1146 9.1.1. Destination UpACKSignal . . . . . . . . . . . . . . . .41 11.1246 9.1.2. DestinationDownUp ACK Signal . . . . . . . . . . . . . . 47 9.1.3. Destination Update Signal . . . . . .41 11.13 Destination Down ACK Signal. . . . . . . . 47 9.2. Credit-Windowing Data Items . . . . . . .42 11.14 Destination Update Signal. . . . . . . . 47 9.2.1. Credit Window Status . . . . . . . .42 11.15 Heartbeat Signal. . . . . . . . 47 9.2.2. Credit Grant . . . . . . . . . . . . .43 11.16 Link Characteristics Request Signal. . . . . . . 48 9.2.3. Credit Request . . . .43 11.17 Link Characteristics ACK Signal. . . . . . . . . . . . .44 12.. . 49 10. Security Considerations . . . . . . . . . . . . . . . . . . .45 13.50 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .45 13.150 11.1. Registrations . . . . . . . . . . . . . . . . . . . . .. 45 13.250 11.2. Expert Review: Evaluation Guidelines . . . . . . . . . .. 45 13.351 11.3. SignalTLVType Registration . . . . . . . . . . . . . . .45 13.4. 51 11.4. DLEP Data Item Registrations . . . . . . . . . . . . . . 52 11.5. DLEP Status Code Registrations . . . . .46 13.5. . . . . . . . 53 11.6. DLEP Extensions Registrations . . . . . . . . . . . . . 53 11.7. DLEP Well-known Port . . . . . . . . . . . . . . . . . .. 47 13.654 11.8. DLEP Multicast Address . . . . . . . . . . . . . . . . . 54 12. Acknowledgements .47 14. Appendix A.. . . . . . . . . . . . . . . . . . . . . 54 13. References . . . .47 14.1 Peer Level Signal Flows. . . . . . . . . . . . . . . . .47 14.1.1 Router Device Restarts Discovery. . . . 54 13.1. Normative References . . . . . . . .47 14.1.2 Router Device Detects Peer Offer Timeout. . . . . . .48 14.1.3 Router Peer Offer Lost. . . 54 13.2. Informative References . . . . . . . . . . . . .49 14.1.4 Discovery Success. . . . 54 Appendix A. Peer Level Signal Flows . . . . . . . . . . . . . .49 14.1.554 A.1. RouterDetects a Heartbeat timeoutDevice Restarts Discovery . . . . . . . . . .50 14.1.6 Modem Detects a Heartbeat timeout. . 54 A.2. Router Device Detects Peer Offer Timeout . . . . . . . .50 14.1.755 A.3. Router PeerTerminate (from Modem)Offer Lost . . . . . . . . . . .51 14.1.8 Peer Terminate (from Router) Lost. . . . . . 55 A.4. Discovery Success . . . . .51 14.2 Destination Specific Signal Flows. . . . . . . . . . . .51 14.2.1 Modem Destination Up Lost. . . 56 A.5. Router Detects a Heartbeat timeout . . . . . . . . . . .52 14.2.2 Router57 A.6. Modem DetectsDuplicate Destination Upsa Heartbeat timeout . . . . . . .52 14.2.3 Destination Up, No Layer 3 Addresses. . . . . 57 A.7. Peer Terminate (from Modem) Lost . . . .53 14.2.4 Destination Up with IPv4, No IPv6. . . . . . . . 58 A.8. Peer Terminate (from Router) Lost . .53 14.2.5 Destination Up with IPv4 and IPv6. . . . . . . . . .53 14.2.658 Appendix B. DestinationSession Success .Specific Signal Flows . . . . . . . . . 59 B.1. Modem Destination Up Lost . . .54 Acknowledgements. . . . . . . . . . . . . 59 B.2. Router Detects Duplicate Destination Ups . . . . . . . . 59 B.3. Destination Up, No Layer 3 Addresses . . . .54 Normative References. . . . . . 60 B.4. Destination Up with IPv4, No IPv6 . . . . . . . . . . . . 60 B.5. Destination Up with IPv4 and IPv6 . . . . .55 Informative References. . . . . . . 61 B.6. Destination Session Success . . . . . . . . . . . . . . .55 Author's61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .. 5562 1. Introduction There exist today a collection of modem devices that control links of variable datarate and quality. Examples of these types of links include line-of-sight (LOS) terrestrial 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 datarate varies with respect to individual destinations 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 datarate 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 datarate of 54Mbps for unicast traffic, the other laptop, being relatively far away, or obstructed by some object, can simultaneously have a datarate 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 datarate links, mobile networks are challenged by the notion that link connectivity will come and go over time, without an effect on a router's interface state (Up or Down). Effectively utilizing a relatively short-lived connection is problematic in IP routed networks, as routing protocols tend to rely on interface state and independent timers at OSI Layer 3 to maintain network convergence(e.g.(e.g., HELLO messages and/or recognition of DEAD routing adjacencies). These dynamic connections can be better utilized with an event-driven paradigm, where acquisition of a new neighbor (or loss of an existing one) is signaled, as opposed to a paradigm driven by timers and/or interface state. 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 or 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.(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 datarate, leads to a situation where finding the (current) best route through the network to a given destination is 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 datarate may be available, but will not be used unless the network devices emit traffic at a rate higher than the currently established rate. Increasing the traffic rate does not guarantee additional datarate will be allocated; rather, it may result in data loss and additional retransmissions on the link. Addressing the challenges listed above, the authors have developed the Data Link Exchange Protocol, or DLEP. The DLEP protocol runs between a router and its attached modem devices, allowing the modem to communicate link characteristics as they change, and convergence events (acquisition and loss of potential routing destinations). The following diagrams are used to illustrate the scope of DLEP packets. |-------Local Node-------| |-------Remote Node------| | | | | +--------+ +-------+ +-------+ +--------+ | Router |=======| Modem |{~~~~~~~~}| Modem |=======| Router | | | | Device| | Device| | | +--------+ +-------+ +-------+ +--------+ | | | Link | | | |-DLEP--| | Protocol | |-DLEP--| | | | (e.g. | | | | | | 802.11) | | | Figure 1: DLEP Network In Figure 1, when the local modem detects the presence of a remote node, it (the local modem) sends a signal to its router via the DLEP protocol. Upon receipt of the signal, the local router may take whatever action it deems appropriate, such as initiating discovery protocols, and/or issuing HELLO messages to converge the network. On a continuing, as-needed basis, the modem devices utilize DLEP to report any characteristics of the link (datarate, latency, etc) that have changed. DLEP is independent of the link type and topology supported by the modem. Note that the DLEP protocol is specified to run only on the local link between router and modem. Some over the air signaling may be necessary between the local and remote modem in order to provide some parameters in DLEP signals between the local modem and local router, but DLEP does not specify how such over the air signaling is carried out. Over the air signaling is purely a matter for the modem implementer. Figure 2 shows how DLEP can support a configuration where routers are connected with different link types. In this example, Modem A implements a point-to-point link, and Modem B is connected via a shared medium. In both cases, the DLEP protocol is used to report the characteristics of the link (datarate, latency, etc.) to routers. The modem is also able to use the DLEP session to notify the router when the remote node is lost, shortening the time required tore-convergere- converge the network. +--------+ +--------+ +----+ Modem A| | Modem A+---+ | | Device | <===== // ======> | Device | | | +--------+ P-2-P Link +--------+ | +---+----+ +---+----+ | Router | | Router | | | | | +---+----+ +---+----+ | +--------+ +--------+ | +-----+ Modem B| | Modem B| | | Device | o o o o o o o o | Device +--+ +--------+ o Shared o +--------+ o Medium o o o o o o o o +--------+ | Modem B| | Device | +---+----+ | | +---+----+ | Router | | | +--------+ Figure 2: DLEP Network with Multiple Modem Devices DLEP defines a set of signals used by modems and their attached routers. The signals are used to communicate events that occur on the physical link(s) managed by the modem: for example, a remote node entering or leaving the network, or that the link has changed. Associated with these signals are a set of data items - information that describes the remote node (e.g., address information), and/or the characteristics of the link to the remote node. The protocol is defined as a collection of type-length-value (TLV) based formats, specifying the signals that are exchanged between a router and a modem, and the data items associated with the signal. This document specifies transport of DLEP signals and data items via the TCP transport, with a UDP-based discovery mechanism. Other transports for the protocol are possible, but are outside the scope of this document. DLEPsignals are further defined as mandatory or optional. Signals will additionally have mandatory and optional data items. Implementations MUST support all mandatory signals and their mandatory data items to be considered compliant. Implementations MAY also support some, or all, of the optional signals and data items. DLEPuses a session-oriented paradigm between the modem device and its associated router. If multiple modem devices are attached to a router (as in Figure 2), a separate DLEP session MUST exist for each modem. If a modem device supports multiple connections to a router (via multiple logical or physical interfaces), or supports connections to multiple routers, a separate DLEP session MUST exist for each connection. This router/modem session provides a carrier for information exchange concerning"destinations"'destinations' that are available via the modem device. A"destination"'destination' can be either physical (as in the case of a specific far-end router), or a logical destination (as in a Multicast group). As such, all of the destination-level exchanges in DLEP can be envisioned as building an information base concerning the remote nodes, and the link characteristics to those nodes. Any DLEP signal that is NOT understood by a receiver MUST result in an error indication being sent to the originator, and also MUST result in termination of the session between the DLEP peers. Any data item that is NOT understood by a receiver MUST be ignored. Multicast traffic destined for the variable-quality network (the network accessed via the DLEP modem) is handled in IP networks by deriving a Layer 2 MAC address based on the Layer 3 address. Leveraging on this scheme, Multicast traffic is supported in DLEP simply by treating the derived MAC address as any other"destination"'destination' (albeit a logical one) in the network. To support these logical destinations, one of the DLEP participants (typically, the router) informs the other as to the existence of the logical neighbor. The modem, once it is aware of the existence of this logical neighbor, reports link characteristics just as it would for any other destination in the network. The specific algorithms a modem would use to report metrics on multicast (or logical) destinations is outside the scope of this specification, and is left to specific implementations to decide.1.11.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 Routers and modems that exist as part of the same node (e.g., that are locally connected) can utilize a discovery technique to locate each other, thus avoiding a-priori configuration. The router is responsible forinitialinginitializing the discovery process, using the Peer Discoverysignal.signal (Section 7.1). DLEP utilizes a session-oriented paradigm. A router and modem form a session by completing the discovery process. This router-modem session persists unless or until it either (1) times out, based on the timeout values supplied, or (2) is explicitly torn down by one of the participants. Note that while use of timers in DLEP is OPTIONAL, it is strongly recommended that implementations choose to run with timers enabled. DLEP assumes thatparticipating modems, and their physical links, act as a transparent IEEE 802.1D bridge. Specifically, the assumption is thatthedestinationMAC address for delivering data traffic(frames destined for the far-end node, as opposed tois theDLEP control traffic itself)MAC specified inany frame emitted bytherouter should beDestination Up signal (Section 7.9). No manipulation or or substitution is performed; the MAC addressof a devicesupplied in Destination Up is used as theremote node.OSI Layer 2 Destination MAC address. DLEP also assumes that MAC addressesareMUST be unique within the context ofthea router-modem session. DLEP utilizes UDP multicast for single-hop discovery, and TCP for transport of the control signals. Therefore, DLEP assumes that the modem and router have topologically consistent IP addresses assigned. It is recommended that DLEP implementations utilize IPv6 link-local addresses to reduce the administrative burden of address assignment. This document refers to a remote node as a"Destination".'Destination'. Destinations can be identified by either the router or the modem, and represent a specific destination (e.g., an address) that exists on the link(s) managed by the modem. A destination MUST contain a MAC address, it MAY optionally include a Layer 3 address (or addresses).Destinations MAY refer either to physical devices inNote that since a destination is a MAC address, thenetwork, or toMAC could reference a logicaldestinations,destination, as in a derived multicast MACaddress associated withaddress, as well as to agroup.physical device. As"destinations"destinations are discovered, DLEP routers and modems build an information base on destinations accessible via the modem. Changes in link characteristicsMAYare thenbereported as being"modem-wide"'modem-wide' (effecting ALL destinations accessed via themodem)modem, reported via the Peer Update signal, Section 7.5) orMAY bereported for a specific neighbor(destination) specific.(via the Destination Update signal, Section 7.13). The DLEP signals concerning destinations thus become the way for routers and modems to maintain, and notify each other about, an information base representing the physical and logical (e.g., multicast) destinations accessible via the modem device. The information base would contain addressing information(e.g.,(i.e., MAC address, and OPTIONALLY, Layer 3 addresses), link characteristics (metrics), and OPTIONALLY, flow control information (credits). DLEP assumes that security on the session(e.g.(e.g., authentication of session partners, encryption of traffic, or both) is dealt with by the underlying transport mechanism (e.g., by using a transport such as TLS[TLS]).[RFC5246]). This document specifies an implementation of the DLEP signals and data items running over the TCP transport. It is assumed that DLEP running over other transport mechanisms would be documented separately. 3.Mandatory VersusCore Features and OptionalItems As mentioned above,Extensions DLEPdefineshas a core set of signals and data itemsas mandatory. Support for those signals and data itemsthat MUSTexist inbe processed without error by an implementation in order to guarantee interoperability and therefore makeanthe implementation DLEP compliant.However, a mandatory signal orThis document defines the core set of signals and dataitem is not necessarily required -items, listing them asan example, consider the'mandatory'. It should be noted that some core signals and dataitem entitled "DLEP Optional Signals Supported", defined in section 10.22items might not be used during the lifetime ofthis document. The data item allowsa single DLEP session, but a compliant implementation MUST support them. While this document represents the best efforts of the co-authors, and the working group, tolist all optional behaviorbe functionally complete, itsupports, andissentrecognized that extensions to DLEP will in all likelihood be necessary asa partmore link types are utilized. To support future extension ofthe Peer Initialization signal. Receiving implementations MUSTDLEP, this document describes an extension negotiation capability to becapable of parsing and understandingused during session initialization via theoptional signals thatExtensions Supported data item, documented in Section 8.6 of this document. All extensions areoffered. However, ifconsidered OPTIONAL. Only thesendingDLEP functionality listed as 'mandatory' is required by implementationhas chosen NOTin order toimplement ANY optional functionality, this data item would NOTbeincluded in the Peer Initialization. Although parsing and understandingDLEP compliant. This specification defines one extension, Credit processing, exposed via thedata item is a mandatory functionExtensions Supported mechanism that implementations MAY chose to implement, or to omit. 3.1. Negotiation ofa compliant DLEP,Optional Extensions Optional extensions supported by an implementation MUST be declared to potential DLEP peers using the Extensions Supported data itemitself MAY, or MAY NOT, appear in the flow. Absence of(Section 8.6) during themandatorysession initialization sequence. Once both peers have exchanged initialization signals, an implementation MUST NOT emit any signal or data itemwouldassociated with an optional extension that was notbe considered a protocol error, but as support forspecified in thecore DLEP signals ONLY. Therefore, carereceived initialization signal from its peer. 3.2. Protocol Extensions If/when protocol extensions are required, they should betakenstandardized either as an update todifferentiate the notion of a mandatory data item versus one that MUST appearthis document, or as an additional stand-alone specification. The requests for IANA-controlled registries ina given message. 4. Creditsthis document contain sufficient reserved space, both in terms of DLEPincludes an OPTIONAL credit-windowing scheme analogoussignals and DLEP data items, to accomodate future extensions to theone documented in [RFC5578]. In this scheme, traffic betweenprotocol and therouterdata transferred. 3.3. Experimental Signals andmodem is treated as two unidirectional windows.Data Items This documentidentifies these windows asrequests numbering space in both the"Modem Receive Window", or MRW,DLEP signal and data item registries for experimental items. The intent is to allow for experimentation with new signals and/or data items, while still retaining the"Router Receive Window", or RRW.documented DLEP behavior. If a given experiment proves successful, it SHOULD be documented as an update to this document, or as a stand-alone specification. Use of theOPTIONAL credit-windowing scheme is used, creditsexperimental signals or data items MUST begrantedannounced bythe receiver oninclusion of an Experimental Definition data item (Section 8.7) with agiven window - that is, on the "Modem Receive Window" (MRW),value agreed upon (a-priori) between themodem is responsibleparticipating peers. The exact mechanism forgranting credits to the router, allowing it (the router) to send data to the modem. Likewise,a-priori communication of therouterexperimental definition formats isresponsible for granting credits on the RRW, which allowsbeyond themodem to send data to the router. DLEP expresses all creditscope of this document. Multiple Experimental Definition data items MAY appear innumber of octets. The total numberthe Peer Initialization/Peer Initialization ACK sequence. However, use ofcredits onmultiple experiments in awindow,single peer session could lead to interoperability issues or unexpected results (e.g., redefinition of experimental signals and/or data items), andthe incrementis therefore discouraged. It is left toaddimplementations to determine the correct processing path (e.g., agrant, are always expressed as a 64-bit unsigned quantity. If used, credits are manageddecision ona neighbor-specific basis; that is, separate credit counts are maintained for each neighbor requiringwhether to terminate theservice. Credits do not applypeer session, or to establish a precedence of theDLEP session that exists between routers and modems. 5.conflicting definitions) if such conflicts arise. 4. Metrics DLEP includes the ability for the router and modem to communicate metrics that reflect the characteristics(e.g.(e.g., datarate, latency) of the variable-quality link in use. DLEP does NOT specify how a given metric value is to be calculated, rather, the protocol assumes that metrics have been calculated with a"best effort",'best effort', incorporating all pertinent data that is available to the modem device. As mentioned in the introduction section of this document, metrics have to be used within a context - for example, metrics to a unicast address in the network. DLEP allows for metrics to be sent within two contexts - metrics for a specific destination within the network (e.g., a specific router), and"modem-wide"'modem-wide' (those that apply to all destinations accessed via the modem). Metrics can be further subdivided into transmit and receive metrics. Metrics supplied on DLEP Peer signals are, by definition, modem-wide; metrics supplied on Destination signals are, by definition, used for the specific neighbor only. DLEP modem implementations MUST announce all supported metric items, and provide default values for those metrics, in the Peer Initializationsignal.signal (Section 7.3). In order to introduce a new metric type, DLEP modem implementations MUST terminate the session with the router (via the Peer Terminatesignal),signal, Section 7.7), andre-establishre- establish the session. It is left to implementations to choose sensible default values based on their specific characteristics. Modems having static (non- changing) link metric characteristics MAY report metrics only once for a given neighbor (or once on a modem-wide basis, if all connections via the modem are of this static nature). The approach of allowing for different contexts for metric data increases both the flexibility and the complexity of using metric data. This document details the mechanism whereby the data is transmitted, however, the specific algorithms (precedence, etc) for utilizing the dual-context metrics is out of scope and not addressed by this document.6. Extensions to DLEP While this draft represents the best efforts of the co-authors, and the working group, to be functionally complete, it is recognized that extensions to4.1. Mandatory Metrics As mentioned above, DLEPwill inmodem implementations MUST announce alllikelihood be necessary as more link types are utilized. There are three possible avenues for DLEP extensions: protocol extensions, vendor extensions, and experimental extensions. 6.1 Protocol Extensions If/when protocol extensions are required, they should be standardized either as an update to this document, or assupported metric items during session initialization. However, anadditional stand-alone specification. 6.2 Vendor Extensions Vendor extensions to DLEP are accommodated via the "DLEP Vendor Extension" TLV, documented in Section 10.22 of this document. If a perceived extension exceedsimplementation MUST include thescopefollowing list ofwhat can be contained in the DLEP Vendor Extension TLV, the proposed extension should be addressed as either an update to this document, or as a stand-alone specification. 6.3 Experimental Extensions This document requests numbering space in both the Signal andmetrics: o Maximum DataItem registries for experimental items. The intent is to allow for experimentation with new signals and/or data items, while still retaining the documented DLEP behavior. If a given experiment proves successful, it SHOULD be documented as an update to this document, or as a stand-alone specification. Experimental DLEP signals SHOULD be treated as optional signals - e.g., they SHOULD be announced in the "DLEP Optional Signals TLV" in Peer Initialization and/or Peer Initialization ACK. Likewise, experimental data item TLVs SHOULD be announced in the "DLEP OptioinalRate (Receive) (Section 8.13) o Maximum DataItems" TLV (also in Peer Initialization/Peer Initialization ACK). 7.Rate (Transmit) (Section 8.14) o Current Data Rate (Receive) (Section 8.15) o Current Data Rate (Transmit) (Section 8.16) o Latency (Section 8.17) 5. Normal Session Flow Normal session flow for a DLEP router has two sub-cases, depending on whether the implementation supports the discovery process.Since modemsModem implementations MUST support thediscovery process, there is only one description necessary for modem implementations. The normal flow by DLEP partner type is: 7.1Discovery case; router implementations MAY support discovery, or rely on a-priori configuration to define the address(es) of attached modems. 5.1. DLEP Router session flow - Discovery case If the DLEP router implementation is utilizing the optional discovery mechanism, then the implementation will initialize a UDP socket, binding it to an arbitrary port. This UDP socket is used to send the Peer Discovery signal (Section 7.1) to the DLEP link-local multicast address and port (TBD). The implementation then waits on receipt of a Peer Offersignal,signal (Section 7.2), which MUST contain the unicast address and port for TCP-based communication with a DLEP modem. The Peer Offer signal MAY contain multiple address/port combinations. If more than one address/port combination is in the Peer Offer, the DLEP router implementation SHOULD consider the list to be in priority sequence, with the"most desired"'most desired' address/port combination listed first. However, router implementations MAY use their own heuristics to determine the best address/port combination. At this point, the router implementation MAY either destroy the UDP socket, or continue to issue Peer Discovery signals to the link-local address/port combination. In either case, the TCP session initialization occurs as in the configured case.7.25.2. DLEP Router session flow - Configured case When a DLEP router implementation has the address and port information for a TCP connection to a modem (obtained either via configuration or via the discovery process described above), the router will initialize and bind a TCP socket. This socket is used to connect to the DLEP modem software. After a successful TCP connect, the modem implementation MUST issue a Peer Initialization signal (Section 7.3) to the DLEP router. The Peer Initialization signal MUST containTLVsdata items for ALL supported metrics from thismodem (e.g. all mandatory metrics plus all optional metrics supported by the implementation),modem, along with the default values of those metrics. After sending the Peer Initialization, the modem implementation MUST wait for receipt of a Peer Initialization ACK signal (Section 7.4) from the router. Receipt of the Peer Initialization ACK signal indicates that the router has received and processed the Peer Initialization, and the session MUST transition to the"in session"'in session' state. At this point, signals regarding destinations in the network, and/or Peer Updatesignals,signals (Section 7.5), can flow on the DLEP session between modem and router. The"in session"'in session' state is maintained until one of the following conditions occur: o The session is explicitly terminated (using Peer Termination), or o The session times out, based on supplied timeout values.7.35.3. DLEP Modem session flow DLEP modem implementations MUST support the discovery mechanism. Therefore, the normal flow is as follows: The implementation will initialize a UDP socket, binding that socket to the DLEP link-local multicast address (TBD) and the DLEP well- known port number (also TBD). The implementation will then initialize a TCP socket, on a unicast address and port. This socket is used to listen for incoming TCP connection requests. When the modem implementation receives a Peer Discovery signal (Section 7.1) on the UDP socket, it responds by issuing a Peer Offer signal (Section 7.2) to the sender of the PeerDiscovery.Discovery signal. The Peer Offer signal MUST contain the unicast address and port of the TCP listen socket, described above. A DLEP modem implementation MAY respond with ALL address/port combinations that have an active TCP listen posted. If multiple address/port combinations are listed, the receiver of the Peer Offer signal MAY connect on any available address/port pair. Anything other than Peer Discovery signals received on the UDP socket MUST be silently dropped. When the DLEP modem implementation accepts a connection via TCP, it MUST send a Peer Initializationsignal.signal (Section 7.3). The Peer Initialization signal MUST contain metricTLVsdata items for ALLmandatory metrics, and MUST contain metric TLVs for ANY optional metricssupportedby the modem.metrics. Ifa newan additional metric is to be introduced, the DLEP session between router and modem MUST be terminated and restarted, and the new metric described in a Peer Initialization signal.7.45.4. Common Session Flow In order to maintain the session between router and modem, periodic"Heartbeat"Heartbeat signals (Section 7.14) MAY be exchanged. These signals are intended to keep the session alive, and to verify bidirectional connectivity between the two participants. DLEP also providesan OPTIONALa Peer Updatesignal,signal (Section 7.5), intended to communicate some change in status (e.g., a change of layer 3 address parameters, or a modem-wide link change). In addition to the local (Peer level) signals above, the participants will transmit DLEP signals concerning destinations in the network. These signals trigger creation/maintenance/deletion of destinations in the information base of the recipient. For example, a modem will inform its attached router of the presence of a new destination via the"Destination Up" signal.Destination Up signal (Section 7.9). Receipt of a Destination Up causes the router to allocate the necessary resources, creating an entry in the information base with the specifics(e.g.,(i.e., MAC Address, Latency, Data Rate, etc) of the neighbor. The loss of a destination is communicated via the"Destination Down" signal,Destination Down signal (Section 7.11), and changes in status to the destination(e.g.(e.g., varying link quality, or addressing changes) are communicated via the"Destination Update" signal.Destination Update signal (Section 7.13). The information on a given neighbor will persist in the router's information base until (1) a"Destination Down"Destination Down signal is received, indicating that the modem has lost contact with the remote node, or (2) the router/modem session terminates, indicating that the router has lost contact with its own local modem.Again, metricsMetrics can be expressed within the context of a specific neighbor via the Destination Update signal, or on a modem-wide basis via the Peer Update signal. In cases where metrics are provided on the router/modem session, the receiver MUST propagate the metrics to all destinations in its information base that are accessed via the originator. A DLEP participant MAY send metrics both in arouter/modemrouter/ modem session context (via the Peer Update signal) and a specific neighbor context (via Destination Update) at any time. The heuristics for applying received metrics is left to implementations. In addition to receiving metrics about the link, DLEP providesan OPTIONALa signal allowing a router to request a different datarate, or latency, from the modem. This signal is referred to as the Link CharacteristicsSignal,Request signal (Section 7.15), and gives the router the ability to deal with requisite increases (or decreases) of allocated datarate/latency in demand-based schemes in a more deterministic manner.8. Mandatory Signals and Data Items The following6. DLEPsignals are considered core to the specification; implementations MUST support theseMessage Processing Communication between DLEP peers consists of a bidirectional stream of signals, each signal consisting of a signal header andthe associatedan unordered list of dataitems, in order to be considered compliant: Signal Data Items ====== ========== Peer Discovery (Router Only) None Peer Offer (Modem Only) IPv4 Address IPv6 address DLEP Port Peer Initialization Maximum Data Rate (Receive) Maximum Data Rate (Transmit) Current Data Rate (Receive) Current Data Rate (Transmit) Latency Relative Link Quality (Receive) Relative Link Quality (Transmit) DLEP Optional Signal Support DLEP Optional Data Item Support Peer Initialization ACK Status Peer Termination Status Peer Termination ACK Status Destination Up MAC Address Maximum Data Rate (Receive) Maximum Data Rate (Transmit) Current Data Rate (Receive) Current Data Rate (Transmit) Latency Relative Link Quality (Receive) Relative Link Quality (Transmit) Destination Update MAC Address Maximum Data Rate (Receive) Maximum Data Rate (Transmit) Current Data Rate (Receive) Current Data Rate (Transmit) Latency Relative Link Quality (Receive) Relative Link Quality (Transmit) Destination Down MAC Address All other DLEP signalsitems. Both signal headers and data items areOPTIONAL. Implementations MAY choose to provide them. Implementations that do not support optional signals MUST report an error condition and terminateencoded as TLV (Type-Length-Value) structures. In this document, therouter/modem session upon receipt of any such signal received. OPTIONALdata itemsreceived thatfollowing the signal header arenot supporteddescribed as being 'contained in' the signal. All integer values in all TLV structures MUST besilently dropped. 9. Generic DLEP Signal Definition The Generic DLEP Signal consistsin network byte- order. There is no restriction on the order of data items following asequencesignal, and the multiplicity of duplicate data items is defined by the definition ofTLVs. The first TLV representsthe signalbeing communicated (e.g., a "Destination Up",declared by the type in the signal header. If an unrecognized, or unexpected signal is received, or a"Peer Offer"). Subsequent TLVs contain thereceived signal contains unrecognized, invalid or disallowed duplicate dataitems pertinent toitems, the receiving peer MUST terminate the session by issuing a Peer Termination signal(e.g., Maximum Data Rate, or Latency, etc).(Section 7.7) with a Status data item (Section 8.2) containing the most relevant status code, and then close the TCP connection: 6.1. DLEP Signal Header TheGenericDLEPPacket Definitionsignal header 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Signal TLV| Signal Type | Length |DLEP data items... |Data Items... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: DLEP Signal-Header Signal Type: One of the DLEP SignalTLV typeType values defined in this document.Length -Length: The length, expressed as a 16-bitquantity,unsigned integer, of all of the DLEP data items associated with this signal.DLEP data items -This length does not include the length of the header itself Data Items: One or more DLEP data items, encoded in TLVs, as defined in this document.10. DLEP Data Items As mentioned earlier, DLEP protocol signals are transported as a collection of TLVs. The first TLV present in a DLEP signal MUST be one of the Signal TLVs, documented in section 10. The signals are followed by one or more data items, indicating the specific changes that need to be instantiated in the receiver's information base. Valid DLEP Data Items are: TLV TLV Value Description ========================================= TBD DLEP Port TBD Peer Type TBD IPv4 Address TBD IPv6 Address TBD Maximum Data Rate (Receive) (MDRR) TBD Maximum Data Rate (Transmit) (MDRT) TBD Current Data Rate (Receive) (CDRR) TBD Current Data Rate (Transmit) (CDRT) TBD Latency TBD Receive Resources TBD Transmit Resources TBD Relative Link Quality (Receive) (RLQR) TBD Relative Link Quality (Transmit) (RLQT) TBD Status TBD Heartbeat Interval/Threshold TBD Neighbor down ACK timer TBD Link Characteristics ACK timer TBD Credit Window Status TBD Credit Grant TBD Credit Request TBD DLEP Optional Signals Supported TBD6.2. DLEPOptionalGeneric DataItems Supported TBD DLEP Vendor ExtensionItem All DLEP dataitem TLVsitems 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 |Data Item Type| Length | Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+TLV Type -Figure 4: DLEP Generic Data Item Data Item Type: An 8-bit unsigned integer field specifying the data item being sent.Length -Length: An 8-bit length of the value field of the dataitem Value -item. Value: A field of length <Length> which contains data specific to a particular data item.10.17. DLEPVersion TheSignals As mentioned above, all DLEPVersion TLVsignals begin with the DLEP signal header structure. Therefore, in the following descriptions of specific signals, this header structure is assumed, and will not be replicated. Following is the set of MANDATORY signals that must be recognized by a DLEP compliant implementation. As mentioned before, not all signals may be used during a session, but an implementation MUST correctly process these signals when received. The mandatoryTLV in theDLEP signals are: +---------+-------------------------------+---------------+ | Signal | Description | Section | +---------+-------------------------------+---------------+ | TBD | Peer Discovery | Section 7.1 | | TBD | PeerDiscovery,Offer | Section 7.2 | | TBD | PeerInitialization, andInitialization | Section 7.3 | | TBD | Peer Initialization ACKsignals. The Version TLV is used| Section 7.4 | | TBD | Peer Update | Section 7.5 | | TBD | Peer Update ACK | Section 7.6 | | TBD | Peer Termination | Section 7.7 | | TBD | Peer Termination ACK | Section 7.8 | | TBD | Destination Up | Section 7.9 | | TBD | Destination Up ACK | Section 7.10 | | TBD | Destination Down | Section 7.11 | | TBD | Destination Down ACK | Section 7.12 | | TBD | Destination Update | Section 7.13 | | TBD | Heartbeat | Section 7.14 | | TBD | Link Characteristics Request | Section 7.15 | | TBD | Link Characteristics ACK | Section 7.16 | +---------+-------------------------------+---------------+ 7.1. Peer Discovery Signal A Peer Discovery signal SHOULD be sent by a router toindicate the version of the protocol runningdiscover DLEP routers in theoriginator. A DLEP implementation MAY use this informationnetwork. The Peer Offer signal (Section 7.2) is required todecide ifcomplete thepotential session partnerdiscovery process. Implementations MAY implement their own retry heuristics in cases where it isrunning atdetermined the Peer Discovery signal has timed out. To construct asupported level. The DLEP Version TLV containsPeer Discovery signal, thefollowing fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |Length=4 | Major Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minor Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLVSignal Type- TBD Length - Lengthvalue in the signal header is4 Major Version - Major versionset to DLEP_PEER_DISCOVERY (value TBD). The Peer Discovery signal MUST contain one of each of themodem or router protocol. Minorfollowing data items: o DLEP Version- Minor version(Section 8.1) o Heartbeat Interval (Section 8.5) 7.2. Peer Offer Signal A Peer Offer signal MUST be sent by a DLEP modem in response to a Peer Discovery signal (Section 7.1). Upon receipt, and processing, of a Peer Offer signal, themodem orrouterprotocol. Support of this draft is indicatedresponds bysettingissuing a TCP connect to theMajor Versionaddress/port combination specified in the received Peer Offer. The Peer Offer signal MUST be sent to'0', andtheMinor Versionunicast address of the originator of Peer Discovery. To construct a Peer Offer signal, the Signal Type value in the signal header is set to'7' (e.g. Version 0.7). 10.2DLEP_PEER_OFFER (value TBD). The Peer Offer signal MUST contain one of each of the following data items: o DLEPPortVersion (Section 8.1) o Heartbeat Interval (Section 8.5) The Peer Offer signal MAY contain one of each of the following data items: o Peer Type (Section 8.4) o DLEP PortTLV is a mandatory TLV in(Section 8.3) The Peer Offer signal MAY contain one or more of any of the following data items, with different values: o IPv4 Address (Section 8.9), with Add/Drop indicator = 1 o IPv6 Address (Section 8.10), with Add/Drop indicator = 1 If the Peer Offersignal. Thesignal includes a DLEP PortTLV isdata item, the port number specified MUST be used toindicateestablish the TCP session. If the DLEP Port numberonis omitted, theDLEP server available for connections. Thereceiver MUST usethis information to performtheTCP connectDLEP well- known port number (Section 11.7) to establish theDLEP server.TCP connection. TheDLEP Port TLV containsIP Address data items indicate thefollowing fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |Length=2 | TCP Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type - TBD Length - Length is 2 TCP Port Number - TCP Port number onunicast address theDLEP server. 10.3 Peer Type Thereceiver of PeerType TLV is an OPTIONAL TLVOffer MUST use when connecting the DLEP TCP session. If multiple IP Address items are present inboththe PeerDiscovery and PeerOffersignals. The Peer Type TLV is used by the router and modem to give additional information assignal, implementations MAY use their own heuristics toits type. The peer type is a string and is envisionedselect the address tobe used for informational purposes (e.g. as outputconnect to. If no IP Address data items are included ina display command). The Peer Type TLV containsthefollowing fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |Length= peer |Peer Type String | | |type string len| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type - TBD Length - Length of peer type string.PeerType String - Non-Null terminated string, using UTF-8 encoding. For example, a satellite modem might set this variable to 'Satellite terminal'. 10.4 MAC Address The MAC address TLVOffer signal, the receiver MUSTappear in all destination-oriented signals (e.g. Destination Up, Destination Up ACK, Destination Down, Destination Down ACK, Destination Update, Link Characteristics Request, and Link Characteristics ACK). The MAC Address TLV containsuse the origin address of thedestination onsignal as theremote node. The MACIP addressMAYto establish the TCP connection. 7.3. Peer Initialization Signal A Peer Initialization signal MUST beeithersent by aphysical orrouter as the first signal of the DLEP TCP session. It is sent by the router after avirtual destination. ExamplesTCP connect to an address/port combination that was obtained either via receipt of avirtual destination wouldPeer Offer, or from a-priori configuration. If any optional extensions are supported by the implementation, they MUST be enumerated in the Extensions Supported data item. If an Extensions Supported data item does NOT exist in amulticast MAC address, orPeer Initialization signal, thebroadcast MAC (0xFFFFFFFFFFFF). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |Length = 6 | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type - TBD Length - 6 MAC Address - MAC Addressreceiver of thedestination (either physical or virtual). 10.5 IPv4 Address The IPv4 Address TLVsignal MUST conclude that there isan optional TLV.NO support for extensions in the sender. Ifsupported, it MAY appearany experimental signals or data items are used by the implementation, they MUST be enumerated inDestination Up, Destination Update, Peer Initialization, and Peer Update signals. When includedone or more Experimental Definition data items. If there are no Experimental Definition data items inDestination signals, the IPv4 Address TLV containsa Peer Initialization signal, theIPv4 addressreceiver of thedestination, as well as a subnet mask value. Insignal MUST conclude that NO experimental definitions are in use by the sender. To construct a PeerUpdateInitialization signal,it containstheIPv4 address ofSignal Type value in theoriginatorsignal header is set to DLEP_PEER_INITIALIZATION (value TBD). The Peer Initialization signal MUST contain one of each of thesignal. In either case, the TLV also contains an indicationfollowing data items: o DLEP Version (Section 8.1) o Heartbeat Interval (Section 8.5) The Peer Initialization signal MAY contain one ofwhether this is a new or existing address, or is a deletioneach ofa previously known address. The IPv4 Address TLV containsthe followingfields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |Length = 5 | Add/Drop | IPv4 Address | | | | Indicator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLVdata items: o Peer Type- TBD Length - 6 Add/Drop - Value indicating whether this is a new or existing address (0x01),(Section 8.4) o Extensions Supported (Section 8.6) The Peer Initialization signal MAY contain one ora withdrawalmore ofan address (0x02). IPv4 Address - The IPv4 addressany of thedestination or peer. Subnet Mask -following data items, with different values: o Experimental Definition (Section 8.7) 7.4. Peer Initialization ACK Signal Asubnet mask (0-32) toPeer Initialization ACK signal MUST beappliedsent in response tothe IPv4 address. 10.6 IPv6 Addressa received Peer Initialization signal (Section 7.3). TheIPv6 Address TLV isPeer Initialization ACK signal completes the TCP-level DLEP session establishment; the sender of the signal should transition to anoptional TLV. If supported, it MAY be used in'in- session' state when theDestination Up, Destination Update, Peer Initialization,signal is sent, and the receiver should transition to the 'in-session' state upon receipt (and successful parsing) of a PeerUpdate Signals. WhenInitialization ACK signal. All supported metric data items MUST be included inDestination signals, this data item containstheIPv6 address ofPeer Initialization ACK signal, with default values to be used on a 'modem-wide' basis. This can be viewed as thedestination. Inmodem 'declaring' all supported metrics at DLEP session initialization. Receipt of any DLEP signal containing a metric data item NOT included in the PeerDiscovery and Peer Update, it containsInitialization ACK signal MUST be treated as an error, resulting in theIPv6 addresstermination of theoriginating peer. In either case,DLEP session between router and modem. If any optional extensions are supported by the modem, they MUST be enumerated in the Extensions Supported dataitem also containsitem. If anindication of whether this isExtensions Supported data item does NOT exist in anewPeer Initialization ACK signal, the receiver of the signal MUST conclude that there is NO support for extensions in the sender. If any experimental signals orexisting address,data items are used by the implementation, they MUST be enumerated in one orismore Experimental Definition data items. If there are no Experimental Definition data items in adeletionPeer Initialization ACK signal, the receiver of the signal MUST conclude that NO experimental definitions are in use by the sender. After the Peer Initialization/Peer Initialization ACK signals have been successfully exchanged, implementations MUST only utilize extensions and experimental definitions that are supported by BOTH peers. To construct apreviously known address, as well as a subnet mask. The IPv6 Address TLV containsPeer Initialization ACK signal, thefollowing fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |Length = 17 | Add/Drop | IPv6 Address | | | | Indicator | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLVSignal Type- TBD Length - 17 Add/Drop - Value indicating whether thisvalue in the signal header isa new or existing address (0x01), or a withdrawalset to DLEP_PEER_INIT_ACK (value TBD). The Peer Initialization ACK signal MUST contain one ofan address (0x02). IPv6 Address - IPv6 Addresseach of thedestination or peer. 10.7following data items: o DLEP Version (Section 8.1) o Heartbeat Interval (Section 8.5) o Maximum Data Rate (Receive)The(Section 8.13) o Maximum Data RateReceive (MDRR) TLV is a mandatory data item, used in Destination Up, Destination Update,(Transmit) (Section 8.14) o Current Data Rate (Receive) (Section 8.15) o Current Data Rate (Transmit) (Section 8.16) o Latency (Section 8.17) The PeerInitialization,Initialization ACK signal MAY contain one of each of the following data items: o Status (Section 8.2) o PeerUpdate, andType (Section 8.4) o Resources (Receive) (Section 8.18) o Resources (Transmit) (Section 8.19) o Relative LinkCharacteristicsQuality (Receive) (Section 8.20) o Relative Link Quality (Transmit) (Section 8.21) o Extensions Supported (Section 8.6) The Peer Initialization ACKSignals to indicatesignal MAY contain one or more of any of themaximum theoreticalfollowing datarate, in bits per second, that canitems, with different values: o Experimental Definition (Section 8.7) 7.5. Peer Update Signal A Peer Update signal MAY beachieved while receiving datasent by a DLEP peer to indicate local Layer 3 address changes, or for metric changes on a modem-wide basis. For example, addition of an IPv4 address to thelink. When metrics are reportedrouter MAY prompt a Peer Update signal to its attached DLEP modems. Also, a modem that changes its Maximum Data Rate for all destinations MAY reflect that change via a Peer Update signal to its attached router(s). Concerning Layer 3 addresses, if thesignals listed above,modem is capable of understanding and forwarding this information (via proprietary mechanisms), themaximum data rate receive MUST be reported. 0 1 2address update would prompt any remote DLEP modems (DLEP-enabled modems in a remote node) to issue a Destination Update signal (Section 7.13) to their local routers with the new (or deleted) addresses. Modems that do not track Layer 30 1 2addresses SHOULD silently parse and ignore the Peer Update signal. Modems that track Layer 34 5 6 7 8 9 0 1 2addresses MUST acknowledge the Peer Update with a Peer Update ACK signal (Section 7.6). Routers receiving a Peer Update with metric changes MUST apply the new metric to all destinations (remote nodes) accessible via the modem. Supporting implementations are free to employ heuristics to retransmit Peer Update signals. The sending of Peer Update signals for Layer 34 5 6 7 8 9 0 1 2address changes SHOULD cease when a either participant (router or modem) determines that the other implementation does NOT support Layer 34 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |Length = 8 | MDRR (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MDRR (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MDRR (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type - TBD Length - 8address tracking. If metrics are supplied with the Peer Update signal (e.g., Maximum DataRate Receive - A 64-bit unsigned number, representingRate), these metrics are considered to be modem-wide, and therefore MUST be applied to all destinations in themaximum theoretical data rate,information base associated with the router/modem session. To construct a Peer Update signal, the Signal Type value inbits per second (bps), that can be achieved while receiving onthelink. 10.8signal header is set to DLEP_PEER_UPDATE (value TBD). The Peer Update signal MAY contain one of each of the following data items: o Maximum Data Rate(Transmit) The(Receive) (Section 8.13) o Maximum Data RateTransmit (MDRT) TLV(Transmit) (Section 8.14) o Current Data Rate (Receive) (Section 8.15) o Current Data Rate (Transmit) (Section 8.16) o Latency (Section 8.17) o Resources (Receive) (Section 8.18) o Resources (Transmit) (Section 8.19) o Relative Link Quality (Receive) (Section 8.20) o Relative Link Quality (Transmit) (Section 8.21) The Peer Update signal MAY contain one or more of the following data items, with different values: o IPv4 Address (Section 8.9) o IPv6 Address (Section 8.10) 7.6. Peer Update ACK Signal A Peer Update ACK signal MUST be sent by implementations supporting Layer 3 address tracking and/or modem-wide metrics to indicate whether a Peer Update signal (Section 7.5) was successfully processed. If the Peer Update ACK is issued, it MUST contain amandatoryStatus data item,used in Destination Up, Destination Update,indicating the success or failure of processing the received PeerInitialization,Update. To construct a PeerUpdate, and Link CharacteristicsUpdate ACKSignalssignal, the Signal Type value in the signal header is set toindicateDLEP_PEER_UPDATE_ACK (value TBD). The Peer Update ACK signal MAY contain one of each of themaximum theoreticalfollowing datarate, in bits per second, that can be achieved while transmittingitems: o Status (Section 8.2) A receiver of a Peer Update ACK signal without a Status dataonitem MUST behave as if a Status data item with code 'Success' had been received. 7.7. Peer Termination Signal A Peer Termination signal MUST be sent by a DLEP participant when thelink. When metrics are reportedrouter/modem session needs to be terminated. Implementations receiving a Peer Termination signal MUST send a Peer Termination ACK signal (Section 7.8) to confirm the termination process. The sender of a Peer Termination signal is free to define its heuristics in event of a timeout. The receiver of a Peer Termination signal MUST release all resources allocated for the router/modem session, and MUST eliminate all destinations in the information base accessible via the router/modem pair represented by the session. Router and modem state machines are returned to the 'discovery' state. No Destination Down signalslisted above,(Section 7.11) are sent. To construct a Peer Termination signal, themaximumSignal Type value in the signal header is set to DLEP_PEER_TERMINATION (value TBD). The Peer Termination signal MAY contain one of each of the following datarate transmititems: o Status (Section 8.2) A receiver of a Peer Termination signal without a Status data item MUST behave as if a Status data item with status code 'Success' had been received. 7.8. Peer Termination ACK Signal A Peer Termination ACK signal MUST bereported. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |Length = 8 | MDRT (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MDRT (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MDRT (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLVsent by a DLEP peer in response to a received Peer Termination signal (Section 7.7). Receipt of a Peer Termination ACK signal completes the teardown of the router/ modem session. To construct a Peer Termination ACK signal, the Signal Type- TBD Length - 8 Maximum Data Rate Transmit - A 64-bit unsigned number, representingvalue in themaximum theoreticalsignal header is set to DLEP_PEER_TERMINATION_ACK (value TBD). The Peer Termination ACK signal MAY contain one of each of the following datarate, in bits per second (bps),items: o Status (Section 8.2) A receiver of a Peer Termination ACK signal without a Status data item MUST behave as if a Status data item with status code 'Success' had been received. 7.9. Destination Up Signal A DLEP participant MUST send a Destination Up signal to report that a new destination has been detected. A Destination Up ACK signal (Section 7.10) is required to confirm a received Destination Up. A Destination Up signal can beachieved while transmitting onsent either by thelink. 10.9modem, to indicate that a new remote node has been detected, or by the router, to indicate the presence of a new logical destination (e.g., a Multicast group) exists in the network. The sender of the Destination Up signal is free to define its retry heuristics in event of a timeout. When a Destination Up signal is received and successfully processed, the receiver should add knowledge of the new destination to its information base, indicating that the destination is accessible via the modem/router pair. To construct a Destination Up signal, the Signal Type value in the signal header is set to DLEP_DESTINATION_UP (value TBD). The Destination Up signal MUST contain one of each of the following data items: o MAC Address (Section 8.8) The Destination Up signal MAY contain one of each of the following data items: o Maximum Data Rate (Receive) (Section 8.13) o Maximum Data Rate (Transmit) (Section 8.14) o Current Data Rate (Receive)The(Section 8.15) o Current Data RateReceive (CDRR) TLV is(Transmit) (Section 8.16) o Latency (Section 8.17) o Resources (Receive) (Section 8.18) o Resources (Transmit) (Section 8.19) o Relative Link Quality (Receive) (Section 8.20) o Relative Link Quality (Transmit) (Section 8.21) The Destination Up signal MAY contain one or more of the following data items, with different values: o IPv4 Address (Section 8.9) o IPv6 Address (Section 8.10) o IPv4 Attached Subnet (Section 8.11) o IPv6 Attached Subnet (Section 8.12) If the sender has IPv4 and/or IPv6 address information for amandatorydestination it SHOULD include the relevant dataitem, useditems in the DestinationUp,Up signal, reducing the need for the receiver to probe for any address. 7.10. DestinationUpdate, Peer Initialization, Peer Update, Link Characteristics Request, and Link CharacteristicsUp ACKsignalsSignal A DLEP participant MUST send a Destination Up ACK signal to indicate whether a Destination Up signal (Section 7.9) was successfully processed. To construct a Destination Up ACK signal, therate at whichSignal Type value in thelinksignal header iscurrently operating for receiving traffic. Inset to DLEP_DESTINATION_UP_ACK (value TBD). The Destination Up ACK signal MUST contain one of each of thecasefollowing data items: o MAC Address (Section 8.8) The Destination Up ACK signal MAY contain one of each of theLink Characteristics Request, CDRR representsfollowing data items: o Status (Section 8.2) A receiver of a Destination Up ACK signal without a Status data item MUST behave as if a Status data item with status code 'Success' had been received. 7.11. Destination Down Signal A DLEP peer MUST send a Destination Down signal to report when a destination (a remote node or a multicast group) is no longer reachable. A Destination Down ACK signal (Section 7.12) MUST be sent by thedesired receiverecipient of a Destination Down signal to confirm that the relevant datarate forhas been removed from thelink. When metrics are reported viainformation base. The sender of thesignals above (e.g.DestinationUpdate),Down signal is free to define its retry heuristics in event of a timeout. To construct a Destination Down signal, thecurrent data rate receive MUST be reported.Signal Type value in the signal header is set to DLEP_DESTINATION_DOWN (value TBD). TheCurrent Data Rate Receive TLV containsDestination Down signal MUST contain one of each of the followingfields: 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 |CDRR (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CDRR (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CDRR (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type - TBD Length - 8 Current Data Rate Receive -data items: o MAC Address (Section 8.8) 7.12. Destination Down ACK Signal A64-bit unsigned number, representingDLEP participant MUST send a Destination Down ACK signal to indicate whether a received Destination Down signal (Section 7.11) was successfully processed. If successfully processed, thecurrent data rate, in bits per second, that is currently be achieved while receiving traffic onsender of thelink. When usedACK MUST have removed all entries in theLink Characteristics Request, CDRR representsinformation base that pertain to thedesired receive rate,referenced destination. To construct a Destination Down ACK signal, the Signal Type value inbits per second, onthelink. If theresignal header isno distinction between current and maximum receiveset to DLEP_DESTINATION_DOWN_ACK (value TBD). The Destination Down ACK signal MUST contain one of each of the following datarates, currentitems: o MAC Address (Section 8.8) The Destination Down ACK signal MAY contain one of each of the following datarate receiveitems: o Status (Section 8.2) A receiver of a Destination Down ACK signal without a Status data item MUST behave as if a Status data item with status code 'Success' had been received. 7.13. Destination Update Signal A DLEP participant SHOULDbesend the Destination Update signal when it detects some change in the information base for a given destination (remote node or multicast group). Some examples of changes that would prompt a Destination Update signal are: o Change in link metrics (e.g., Data Rates) o Layer 3 addressing change (for implementations that support it) To construct a Destination Update signal, the Signal Type value in the signal header is setequalto DLEP_DESTINATION_UPDATE (value TBD). The Destination Update signal MUST contain one of each of themaximumfollowing datarate receive. 10.10 Currentitems: o MAC Address (Section 8.8) The Destination Update signal MAY contain one of each of the following data items: o Maximum Data Rate (Receive) (Section 8.13) o Maximum Data Rate (Transmit)The(Section 8.14) o Current Data RateReceive (CDRT) TLV is a mandatory(Receive) (Section 8.15) o Current Data Rate (Transmit) (Section 8.16) o Latency (Section 8.17) o Resources (Receive) (Section 8.18) o Resources (Transmit) (Section 8.19) o Relative Link Quality (Receive) (Section 8.20) o Relative Link Quality (Transmit) (Section 8.21) The Destination Update signal MAY contain one or more of the following dataitem, useditems, with different values: o IPv4 Address (Section 8.9) o IPv6 Address (Section 8.10) o IPv4 Attached Subnet (Section 8.11) o IPv6 Attached Subnet (Section 8.12) 7.14. Heartbeat Signal A Heartbeat signal SHOULD be sent by a DLEP participant every N seconds, where N is defined inDestination Up, Destination Update,the Heartbeat Interval field of the PeerInitialization,Initialization signal (Section 7.3) or PeerUpdate, Link Characteristics Request, and Link CharacteristicsInitialization ACKsignalssignal (Section 7.4). Note that implementations setting the Heartbeat Interval toindicate0 effectively set therate at whichinterval to an infinite value, therefore, in those cases, this signal SHOULD NOT be sent. The signal is used by participants to detect when a DLEP session partner (either thelinkmodem or the router) iscurrently operating for transmitting traffic. Inno longer communicating. Participants SHOULD allow two (2) heartbeat intervals to expire with no traffic on thecase ofrouter/modem session before initiating DLEP session termination procedures. To construct a Heartbeat signal, the Signal Type value in the signal header is set to DLEP_PEER_HEARTBEAT (value TBD). There are no valid data items for the Heartbeat signal. 7.15. Link CharacteristicsRequest, CDRT representsRequest Signal The Link Characteristics Request signal MAY be sent by thedesired transmit data raterouter to request that the modem initiate changes for specific characteristics of the link.When metrics are reported via the signals above (e.g. Destination Update),The request can reference either a real (e.g., a remote node), or a logical (e.g., a multicast group) destination within thecurrent data rate transmit MUST be reported.network. TheCurrent Data Rate Transmit TLVLink Characteristics Request signal containsthe 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 |CDRT (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CDRT (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CDRT (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type - TBD Length - 8either a Current Data RateTransmit - A 64-bit unsigned number, representing the current(CDRR or CDRT) datarate, in bits per second, thatitem to request a different datarate than what is currentlybe achieved while transmittingallocated, a Latency data item to request that traffic delay on thelink. When used inlink not exceed the specified value, or both. A Link CharacteristicsRequest, CDRT representsACK signal (Section 7.16) is required to complete thedesired transmit rate, in bits per second, onrequest. Issuing a Link Characteristics Request with ONLY thelink. If there is no distinction between current and maximum transmit data rates, currentMAC Address datarate transmit MUST be set equalitem is a mechanism a peer MAY use to request metrics (via themaximum data rate transmit. 10.11 LatencyLink Characteristics ACK) from its partner. TheLatency TLV issender of amandatory data item. It is used in Peer Initialization, Destination Up, Destination Update, Peer Initialization, Peer Update,Link CharacteristicsRequest, andRequest signal MAY attach a timer to the request using the Link Characteristics ACKsignals to indicateTimer data item. If a Link Characteristics ACK signal is received after theamounttimer expires, the sender MUST assume that the request failed. Implementations are free to define their retry heuristics in event oflatency ona timeout. To construct a Link Characteristics Request signal, thelink, orSignal Type value in thecasesignal header is set to DLEP_LINK_CHAR_REQ (value TBD). The Link Characteristics Request signal MUST contain one of each of the following data items: o MAC Address (Section 8.8) The Link CharacteristicsRequest,Request signal MAY contain one of each of the following data items: o Link Characteristics ACK Timer (Section 8.22) o Current Data Rate (Receive) (Section 8.15) o Current Data Rate (Transmit) (Section 8.16) o Latency (Section 8.17) 7.16. Link Characteristics ACK Signal A DLEP participant MUST send a Link Characteristics ACK signal to indicate whether a received Link Characteristics Request signal (Section 7.15) was successfully processed. The Link Characteristics ACK signal SHOULD contain a complete set of metric data items. It MUST contain themaximum latency required onsame metric types as thelink. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |Length = 4 | Latencyrequest. The values inmicroseconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Latency (Cont.) microsecs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type - TBD Length - 4 Latency - A 32-bit unsigned value, representingthetransmission delay that a packet encounters as it is transmitted overmetric data items in thelink. In Destination Up, Destination Update, andLink CharacteristicsACK, this valueACK signal MUST reflect the link characteristics after the request has been processed. If an implementation isreported as delay, in microseconds. The calculationnot able to alter the characteristics oflatency is implementation dependent. For example,thelatency may be a running average calculated fromlink in theinternal queuing. Ifmanner requested, then adevice cannot calculate latency, this TLV SHOUD NOTStatus data item with status code 'Request Denied' MUST beissued. Inadded to the signal. To construct a Link Characteristics RequestSignal, this value representsACK signal, themaximum delay,Signal Type value inmicroseconds, expected onthelink. 10.12 Resources (Receive) The Receive Resources TLV is an optional data item. If supported, itsignal header isused in Destination Up, Destination Update, Peer Initialization, Peer Update, andset to DLEP_LINK_CHAR_ACK (value TBD). The Link Characteristics ACKsignals to indicate a percentage (0-100) amountsignal MUST contain one of each ofresources (e.g. battery power), committed to receiving data, remaining ontheoriginating peer.following data items: o MAC Address (Section 8.8) TheResources TLV containsLink Characteristics ACK signal MAY contain one of each of the followingfields: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |Length = 1 | Rcv Resources| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type - TBD Length - 1 Receivedata items: o Current Data Rate (Receive) (Section 8.15) o Current Data Rate (Transmit) (Section 8.16) o Latency (Section 8.17) o Resources-(Receive) (Section 8.18) o Resources (Transmit) (Section 8.19) o Relative Link Quality (Receive) (Section 8.20) o Relative Link Quality (Transmit) (Section 8.21) o Status (Section 8.2) Apercentage, 0-100, representing the amountreceiver ofremaining resources, sucha Link Characteristics ACK signal without a Status data item MUST behave asbattery power, allocated to receiving data. Ifif adevice cannot calculate receive resources, this TLV SHOULD NOTStatus data item with status code 'Success' had been received. 8. DLEP Data Items Following is the list of MANDATORY data items that must beissued. 10.13recognized by a DLEP compliant implementation. As mentioned before, not all data items need be used during a session, but an implementation MUST correctly process these data items when correctly associated with a signal. The mandatory DLEP data items are: +------------+--------------------------------------+---------------+ | Data Item | Description | Section | +------------+--------------------------------------+---------------+ | TBD | DLEP Version | Section 8.1 | | TBD | Status | Section 8.2 | | TBD | DLEP Port | Section 8.3 | | TBD | Peer Type | Section 8.4 | | TBD | Heartbeat Interval | Section 8.5 | | TBD | Extensions Supported | Section 8.6 | | TBD | Experimental Definition | Section 8.7 | | TBD | MAC Address | Section 8.8 | | TBD | IPv4 Address | Section 8.9 | | TBD | IPv6 Address | Section 8.10 | | TBD | IPv4 Attached Subnet | Section 8.11 | | TBD | IPv6 Attached Subnet | Section 8.12 | | TBD | Maximum Data Rate (Receive) MDRR) | Section 8.13 | | TBD | Maximum Data Rate (Transmit) (MDRT) | Section 8.14 | | TBD | Current Data Rate (Receive) (CDRR) | Section 8.15 | | TBD | Current Data Rate (Transmit) (CDRT) | Section 8.16 | | TBD | Latency | Section 8.17 | | TBD | Resources (Receive) (RESR) | Section 8.18 | | TBD | Resources (Transmit) (REST) | Section 8.19 | | TBD | Relative Link Quality (Receive) | Section 8.20 | | | (RLQR) | | | TBD | Relative Link Quality (Transmit) | Section 8.21 | | | (RLQT) | | | TBD | Link Characteristics ACK Timer | Section 8.22 | +------------+--------------------------------------+---------------+ 8.1. DLEP Version TheTransmit Resources TLV is an optionalDLEP Version dataitem. If supported, it is useditem MUST appear inDestination Up, Destination Update,the PeerInitialization,Discovery (Section 7.1), Peer Offer (Section 7.2), PeerUpdate,Initialization (Section 7.3) andLink CharacteristicsPeer Initialization ACK (Section 7.4) signals The Version data item is used to indicatea percentage (0-100) amountthe version ofresources (e.g. battery power), committedthe protocol running in the originator. A DLEP implementation MAY use this information totransmitting data, remaining ondecide if theoriginating peer.potential session partner is running at a supported level. TheResources TLVDLEP Version data item 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |Length =4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Xmt Resources| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type - TBDData Item Type| Length- 1 Transmit Resources - A percentage, 0-100, representing= 4 | Major Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minor Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: TBD Length: 4 Major Version: Major version of theamountDLEP protocol. Minor Version: Minor version ofremaining resources, such as battery power, allocated to transmitting data. Ifthetransmit resources cannot be calculated, thenDLEP protocol. Support of this draft is indicated by setting theTLV SHOULD NOT be issued. 10.14 Relative Link Quality (Receive)Major Version to '0', and the Minor Version to '8' (i.e., Version 0.8). 8.2. Status TheRelative Link Quality Receive (RLQR) TLV is an optionalStatus dataitem. If supported, ititem isusedMAY appear in the PeerInitialization, Destination Up, Destination Update,Initialization ACK (Section 7.4), PeerInitialization,Termination (Section 7.7), PeerUpdate,Termination ACK (Section 7.8), Peer Update ACK (Section 7.6), Destination Up ACK (Section 7.10), Destination Down ACK (Section 7.12) and Link Characteristics ACK (Section 7.16) signals as part of an acknowledgement from either the modem or the router, to indicate thequalitysuccess or failure of thelink for receiving data as calculated by the originating peer.previously received signal. TheRelative Link Quality (Receive) TLVStatus data item contains the following fields: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|TLV Type =TBD |Length| Data Item Type| Length = 1|RCV Rel. Link ||| |Quality (RLQR)Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+TLV Type -Data Item Type: TBDLength -Length: 1Relative Link Quality (Receive) - A non-dimensional number, 1-100, representing relative link quality. A value of 100 represents a linkStatus Code: One of thehighest quality. If a device cannot calculatecodes defined below. +-------------------+-----------------------------------------------+ | Status Code | Reason | +-------------------+-----------------------------------------------+ | Success | The signal was processed successfully. | | Unknown Signal | The signal was not recognized by theRLQR,| | | implementation. | | Invalid Signal | One or more data items in the signal are | | | invalid, unexpected or duplicated. | | Unexpected Signal | The signal was not expected while the machine | | | was in thisTLV SHOULD NOTstate, e.g., a Peer | | | Initialization signal after session | | | establishment. | | Request Denied | The receiver has not completed the request. | | Timed Out | The request could not beissued. 10.15 Relative Link Quality (Transmit)completed in the | | | time allowed. | +-------------------+-----------------------------------------------+ 8.3. DLEP Port TheTransmit Link Quality Receive (RLQT) TLV is an optionalDLEP Port dataitem. It is useditem MAY appear in the PeerInitialization, Destination Up, Destination Update, Peer Initialization, Peer Update, and Link Characteristics ACK signals to indicateOffer signal (Section 7.2). The DLEP Port data item indicates thequality ofTCP Port number on thelinkDLEP server available fortransmitting data as calculated byconnections. If provided, theoriginating peer.receiver MUST use this information to perform the TCP connect to the DLEP server. TheRelative Link Quality (Transmit) TLVDLEP Port data item 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |Length =4 5 6 7 8 9 0 1|XMT Rel. Link |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Item Type| Length = 2 ||Quality (RLQR)TCP Port Number |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: TBDLength - 1 Relative Link Quality (Transmit) - A non-dimensional number, 1-100, representing relative link quality. A value of 100 represents a link ofLength: 2 TCP Port Number: TCP Port number on thehighest quality. If a device cannot calculateDLEP server. 8.4. Peer Type The Peer Type data item MAY appear in both theRLQT, this TLV SHOULD NOT be issued. 10.16 StatusPeer Discovery (Section 7.1) and Peer Offer (Section 7.2) signals. TheStatus TLVPeer Type data item issent as part of an acknowledgement signal, from eitherused by the router and modemor the router,toindicate the success or failure ofgive additional information as to its type. The peer type is agiven request.string and is envisioned to be used for informational purposes (e.g., as output in a display command). TheStatus TLVPeer Type data item 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |Length =4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |CodeData Item Type| Length = peer |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLVPeer Type-| | | type len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: TBD Length: Length- 1 Termination Code - 0 = Success, Non-zero = Failure. Specific valuesof peer type string. Peer Type: UTF-8 encoded string. For example, anon-zero termination code depend onsatellite modem might set this variable to "Satellite terminal". An implementation MUST NOT assume theoperation requested (e.g. Destination Up, Destination Down, etc). 10.17Peer Type is NUL-terminated. 8.5. Heartbeat Interval The Heartbeat IntervalTLV is a mandatory TLV. Itdata item MUSTbe sent duringappear in the Peer Discovery (Section 7.1), Peer Offer (Section 7.2), Peer Initialization (Section 7.3) and Peer Initialization ACK (Section 7.4) signals to indicate the desired Heartbeat timeout window. The receiver MUST either accept the timeout interval supplied by the sender, or reject the Peer Initialization, and close the socket. Implementations MUST implement heuristics such that DLEP signals sent/received reset the timer interval. The Interval is used to specify a period (in seconds) for HeartbeatSignals (See Section 11.15).signals (Section 7.14). By specifying an Interval value of 0, implementations MAY indicates the desire to disable Heartbeat signals entirely(e.g.,(i.e., the Interval is set to an infinite value), however, it is strongly recommended that implementations use non 0 timer values. A DLEP session will be considered inactive, and MUST be torn down, by an implementation detecting that two (2) Heartbeat intervals have transpired without receipt of any DLEP signals. The Heartbeat IntervalTLVdata item 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 |Length| Data Item Type| Length = 2 | Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+TLV Type -Data Item Type: TBDLength -Length: 2Interval -Interval: 0 = Do NOT use heartbeats on this peer-to-peer session. Non-zero = Interval, in seconds, for heartbeat signals.10.18 Link Characteristics ACK Timer8.6. Extensions Supported TheLink Characteristics ACK Timer TLV is an optional TLV. If supported, itExtensions Supported data item MAY besent duringused in both the Peer Initializationto indicateand Peer Initialization ACK signals. The Extensions Supported data item is used by thedesired number of secondsrouter and modem towait for a responsenegotiate additional optional functionality they are willing toa Link Characteristics Request. If this TLVsupport. The Extensions List isomitted, implementations supporting the Link Characteristics Request SHOULD chooseadefault value.concatenation of the types of each supported extension, found in the IANA DLEP Extensions repository. TheLink Characteristics ACK Timer TLVExtensions Supported data item 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |Length =4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type - TBDData Item Type| Length- 1 Interval - 0=Do NOT use timeouts for Link Characteristics requests on this router/modem session. Non-zero = Interval,No. | Extensions List | | | of values | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: TBD Length: Number of Extensions supported. Extension List: A list of extensions supported, identified by their 1-octet value as listed inseconds, to wait before considering a Link Characteristics Request has been lost. 10.19 Credit Window Statusthe extensions registry. 8.7. Experimental Definition TheCredit Window Status TLVExperimental Definition data item MAY be used in both the Peer Initialization and Peer Initialization ACK signals. The Experimental Definition data item isan optional TLV. If credits are supportedused by theDLEP participants (both therouter and modem to indicate themodem), the Credit Window Status TLV MUSTformats to besent by the participant receiving a Credit Grant Requestused for experimental signals and data items for the given peer session. The formats are identified by using a string that matches the 'name' givendestination.to the experiment. TheCredit Window Status TLVExperimental Definition item 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 |Length = 16|Modem Receive Window ValueData Item Type| Length = len. |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Experiment Name |Modem Receive Window Value|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Modem Receive Window Valueof Experiment |Router Receive Window Value|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|Router Receive Window Value|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+name |Router Receive Window Value|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: TBD Length: Length- 16 Modem Receive Window Value - A 64-bit unsigned number, indicating the current (or initial) numberofcredits available ontheModem Receive Window. Router Receive Window Value - A 64-bit unsigned number, indicatingname string for thecurrent (or initial) numberExperiment. Experiment Name: UTF-8 encoded string, containing the name ofcredits available ontheRouter Receive Window. 10.20 Credit Grant Request The Credit Grant Request TLV is an optional TLV. If credits are supported,experiment being utilized. An implementation receiving this data item MUST compare theCredit Grant Request TLV is sent from a DLEP participant to grant an incrementreceived string tocredits onawindow. The Credit Grant TLVlist of experiments that it supports. An implementation MUST NOT assume the Experiment Name issent as aNUL-terminated. 8.8. MAC Address The MAC address data item MUST appear ineither theall destination-oriented signals (i.e., Destination Upor(Section 7.9), Destination Up ACK (Section 7.10), Destination Down (Section 7.11), Destination Down ACK (Section 7.12), Destination Updatesignals.(Section 7.13), Link Characteristics Request (Section 7.15), and Link Characteristics ACK (Section 7.16)). Thevalue in a Credit Grant TLV represents an increment to be added to any existing credits availableMAC Address data item contains the address of the destination on thewindow. Upon successful receipt and processingremote node. The MAC address MAY be either a physical or a virtual destination. Examples of aCredit Grant TLV,virtual destination would be a multicast MAC address, or thereceiverbroadcast MAC (FF:FF:FF:FF:FF:FF). 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Item Type| Length = 6 | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: TBD Length: 6 MAC Address: MAC Address of the destination (either physical or virtual). 8.9. IPv4 Address The IPv4 Address data item MUSTrespond with a signal containing a Credit Window Status TLV to reportappear in theupdated aggregate values for synchronization purposes. InPeer Offer signal (Section 7.2), and MAY appear in the Peer Update (Section 7.5), Destination Upsignal, when credits are desired, the originating peer MUST set(Section 7.9) and Destination Update (Section 7.13) signals. When included in Destination signals, this data item contains theinitial credit valueIPv4 address of thewindowdestination. In the Peer Offer signal, itcontrols (e.g.contains theModem Receive Window, or Router Receive Window)IPv4 address of the originating peer toan initial, non-zero value. Ifbe used to establish a DLEP session. In either case, thereceiverdata item also contains an indication of whether this is aDestination Up signal withnew or existing address, or is aCredit Grant Request TLV supports credits,deletion of a previously known address. When used in a Peer Offer signal thereceiverAdd/Drop Indicator MUSTeither rejectbe 1 (i.e. Add). The IPv4 Address data item contains theuse of credits, viafollowing 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Item Type| Length = 5 | Add/Drop | IPv4 Address | | | | Indicator | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: TBD Length: 5 Add/Drop: Value indicating whether this is aDestination Up ACK response withnew or existing address (1), or a withdrawal of an address (0). IPv4 Address: The IPv4 address of thecorrect Status TLV,destination orsetpeer. 8.10. IPv6 Address The IPv6 Address data item MUST appear in theinitial value fromPeer Offer signal (Section 7.2), and MAY appear in thedata containedPeer Update (Section 7.5), Destination Up (Section 7.9) and Destination Update (Section 7.13) signals. When included in Destination signals, this data item contains theCredit Window Status TLV. IfIPv6 address of theinitialization completes successfully,destination. In thereceiver MUST respond toPeer Offer signal, it contains theDestination Up signal withIPv6 address of the originating peer to be used to establish aDestination Up ACK signal thatDLEP session. In either case, the data item also contains an indication of whether this is aCredit Window Status TLV, initializing its receive window.new or existing address, or is a deletion of a previously known address. When used in a Peer Offer signal the Add/Drop Indicator MUST be 1 (i.e. Add). TheCredit Grant TLVIPv6 Address data item 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 |Length| Data Item Type| Length =817 | Add/Drop | IPv6 Address | | | | Indicator |Credit Increment| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Credit IncrementIPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Credit IncrementIPv6 Address |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: TBDLength - 8 Reserved - A 64-bit unsigned number representingLength: 17 Add/Drop: Value indicating whether this is a new or existing address (1), or a withdrawal of an address (0). IPv6 Address: IPv6 Address of theadditional credits to be assigneddestination or peer. 8.11. IPv4 Attached Subnet The DLEP IPv4 Attached Subnet allows a device tothe credit window. Since credits can only be granted by the receiverdeclare that it has an IPv4 subnet (e.g., a stub network) attached. Once an IPv4 Subnet has been declared on awindow,device, theapplicable credit window (eitherdeclaration can NOT be withdrawn without terminating theMRW ordestination (via theRRW) is derived fromDestination Down signal) and re-issuing thesender ofDestination Up signal. The DLEP IPv4 Attached Subnet data item data item contains thegrant.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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Data Item Type | Length = 5 | IPv4 Attached Subnet | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Attached Subnet | Subnet Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: TBD Length: 5 IPv4 Subnet: TheCredit Increment MUST NOT causeIPv4 subnet reachable at thewindowdestination. Subnet Mask: A subnet mask (0-32) tooverflow; if this condition occurs, implementations MUST set the credit windowbe applied to themaximum value contained in a 64-bit quantity. 10.21 Credit RequestIPv4 subnet. 8.12. IPv6 Attached Subnet TheCredit Request TLV is an optional TLV. If credits are supported, the Credit Request TLV MAY be sent from eitherDLEPparticipant, viaIPv6 Attached Subnet allows aDestination Update signal, to indicate the desire for the partnerdevice togrant additional creditsdeclare that it has an IPv6 subnet (e.g., a stub network) attached. As inorder for data transfer to proceed onthesession. Ifcase of thecorresponding Destination Up signal for this session didIPv4 attached Subnet data item above, once an IPv6 attached subnet has been declared, it can NOTcontain a Credit Window Status TLV, indicating that credits are tobeused on the session, thenwithdrawn without terminating theCredit Request TLV MUST be rejected bydestination (via Destination Down) and re-issuing thereceiver via aDestinationUpdate ACKUp signal. TheCredit Request TLVDLEP IPv6 Attached Subnet data item data item 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |Length =4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Reserved, MUST|Data Item Type| Length = 17 | IPv6 Attached Subnet | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |be set to 0IPv6 Attached Subnet | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Attached Subnet | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Attached Subnet | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Attached Subnet | Subnet Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+TLV Type -Data Item Type: TBDLength - 1 Reserved - This field is currently unused and MUST be set to 0. 10.22 DLEP Optional Signals SupportedLength: 17 IPv4 Subnet: TheDLEP Optional Signals Supported TLV is a mandatory data item. If optional signals (e.g.,IPv6 subnet reachable at theLink Characteristics Request Signal) are supported, they MUSTdestination. Subnet Mask: A subnet mask (0-128) to beenumerated with thisapplied to the IPv6 subnet. 8.13. Maximum Data Rate (Receive) The Maximum Data Rate (Receive) (MDRR) data iteminserted intoMUST appear in the Peer Initialization ACK signal (Section 7.4), and MAY appear in the PeerInitialization ACK signals. Failure to indicate optionalUpdate (Section 7.5), Destination Up (Section 7.9) and Destination Update (Section 7.13) signalsindicatestoa receiving peer that the sending implementation ONLY supportsindicate thecore (mandatory) items listedmaximum theoretical data rate, inthis specification. Optional signalsbits per second, thatare NOT enumerated in this data item when issuing Peer Initialization or Peer Initialization ACK MUST NOTcan beused duringachieved while receiving data on theDLEP session.link. TheDLEP Optional Signals Supported TLVMaximum Data Rate (Receive) data item 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 |Length = 2 + |List of optional signals ...| Data Item Type| Length = 8 ||number of opt.MDRR (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MDRR (bps) ||signals.+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MDRR (bps) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: TBDLength - 2 + the number of optional signals supported List - An enumeration ofLength: 8 Maximum Data Rate (Receive): A 64-bit unsigned integer, representing theoptional signal TLV Types supported bymaximum theoretical data rate, in bits per second (bps), that can be achieved while receiving on theimplementation. 10.23 DLEP Optionallink. 8.14. Maximum DataItems SupportedRate (Transmit) TheDLEP OptionalMaximum DataItems Supported TLV is a mandatory data item. If optional data items (e.g., Resources) are supported, they MUST be enumerated with thisRate (Transmit) (MDRT) data iteminserted intoMUST appear in the Peer Initialization ACK signal (Section 7.4), and MAY appear in the PeerInitialization ACK signals. FailureUpdate (Section 7.5), Destination Up (Section 7.9) and Destination Update (Section 7.13) signals to indicateoptional data items indicates to a receiving peer thatthesending implementation ONLY supports the core (mandatory)maximum theoretical dataitems listedrate, inthis specification. Optional data itemsbits per second, thatare NOT listed in this data item MUST NOTcan beused duringachieved while transmitting data on theDLEP session.link. TheDLEP OptionalMaximum DataItems Supported TLVRate (Transmit) data item 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 |Length| Data Item Type| Length =2 + |List of optional data items ...|8 ||number of opt.MDRT (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MDRT (bps) ||signals.+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MDRT (bps) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: TBDLength - 2 + the number of optional data items supported List - An enumeration ofLength: 8 Maximum Data Rate (Transmit): A 64-bit unsigned integer, representing theoptionalmaximum theoretical dataitem TLV Types supported byrate, in bits per second (bps), that can be achieved while transmitting on theimplementation. 10.24 DLEP Vendor Extensionlink. 8.15. Current Data Rate (Receive) TheDLEP Vendor ExtensionCurrent Data Rate (Receive) (CDRR) data itemis an optional data item,MUST appear in the Peer Initialization ACK signal (Section 7.4), andallows for vendor-defined informationMAY appear in the Peer Update (Section 7.5), Destination Up (Section 7.9), Destination Update (Section 7.13), Link Characteristics Request (Section 7.15) and Link Characteristics ACK (Section 7.16) signals tobe passed between DLEP participants. The precise data carriedindicate the rate at which the link is currently operating for receiving traffic. When used in thepayload portion ofLink Characteristics Request signal, CDRR represents the desired receive rate, in bits per second, on the link. The Current Data Rate (Receive) data item 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Item Type| Length = 8 | CDRR (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CDRR (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CDRR (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: TBD Length: 8 Current Data Rate (Receive): A 64-bit unsigned integer, representing the current data rate, in bits per second, that isvendor-specific, however,currently be achieved while receiving traffic on thepayloadlink. If there is no distinction between current and maximum receive data rates, current data rate receive MUSTadherebe set equal toa Type-Length-Value format. This optionalthe maximum data rate receive. 8.16. Current Data Rate (Transmit) The Current Data Rate Receive (CDRT) data itemis ONLY valid onMUST appear in the Peer InitializationACK,ACK signal (Section 7.4), andif present, SHOULD contain device- specific information gearedMAY appear in the Peer Update (Section 7.5), Destination Up (Section 7.9), Destination Update (Section 7.13), Link Characteristics Request (Section 7.15) and Link Characteristics ACK (Section 7.16) signals tooptimizing data transmission/reception overindicate the rate at which the link is currently operating for transmitting traffic. When used in the Link Characteristics Request signal, CDRT represents the desired transmit rate, in bits per second, on themodem'slink. TheDLEP Vendor ExtensionCurrent DataItem TLVRate (Transmit) data item 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| Data Item Type| Length|OUI Length= 8 |Vendor OUI...CDRT (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |OUI TLV Subtype | Payload...CDRT (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+TLV Type -| CDRT (bps) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: TBDLength - 3 + length of OUI (in octets) + payload length Vendor OUI - The vendor OUI, as specified in [IEEE] OUI TLV Subtype -Length: 8 Current Data Rate (Transmit): A16-bit quantity, intended to indicate64-bit unsigned integer, representing thespecific device. Payload - Vendor-specific payload, formatted as Type, Length, Value construct(s). 10.25 IPv4 Attached Subnet The DLEP IPv4 Attached Subnet is an optionalcurrent dataitem, and allows a device to declarerate, in bits per second, thatit has an IPv4 subnet (e.g., a stub network) attached. If supported,is currently be achieved while transmitting traffic on theDLEP IPv4 Attached Subnet TLVlink. If there isallowed ONLYno distinction between current and maximum transmit data rates, current data rate transmit MUST be set equal to the maximum data rate transmit. 8.17. Latency The Latency data item data item MUST appear in theDLEP "Destination Up" signal,Peer Initialization ACK signal (Section 7.4), andMUST NOTMAY appearmore than once. All other occurrencesin the Peer Update (Section 7.5), Destination Up (Section 7.9), Destination Update (Section 7.13), Link Characteristics Request (Section 7.15) and Link Characteristics ACK (Section 7.16) signals to indicate the amount of latency, in microseconds, on theDLEP IPv4 Attached Subnet TLV MUST be treated as an error. Once an IPv4 Subnet has been declared by a device,link, or in thedeclaration can NOT be withdrawn without terminatingcase of thedestination (viaLink Characteristics Request, to indicate the"Destination Down" signal) and re-issuingmaximum latency required on the"Destination Up" signal.link. TheDLEP IPv4 Attached Subnet data item TLV containsLatency value is reported as delay. The calculation of latency is implementation dependent. For example, thefollowing fields:latency may be a running average calculated from the internal queuing. 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| Data Item Type| Length =54 |IPv4 Attached SubnetLatency in microseconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |IPv4 Attached Subnet | Subnet MaskLatency (cont.) microsecs |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: TBDLength - 5 IPv4 Subnet -Length: 4 Latency: A 32-bit unsigned value, representing the transmission delay that a packet encounters as it is transmitted over the link. 8.18. Resources (Receive) TheIPv4 subnet reachableResources (Receive) (RESR) data item MAY appear in the Peer Initialization ACK signal (Section 7.4), Peer Update (Section 7.5), Destination Up (Section 7.9), Destination Update (Section 7.13) and Link Characteristics ACK (Section 7.16) signals to indicate the amount of recources for reception (with 0 meaning 'no resources available', and 100 meaning 'all resources available') at the destination.Subnet Mask - A subnet mask (0-32) toThe list of resources that might beapplied toconsidered is beyond theIPv4 subnet. 10.26 IPv6 Attached Subnet The DLEP IPv6 Attached Subnetscope of this document, and isan optionalleft to implementations to decide. The Resources (Receive) dataitem, and allows a deviceitem contains the following fields: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Item Type| Length = 1 | RESR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: TBD Length: 1 Resources (Receive): A percentage, 0-100, representing the amount of resources allocated todeclare that it has an IPv6 subnet (e.g., a stub network) attached.receiving data. Ifsupported, the DLEP IPv6 Attached Subnet TLV is allowed ONLYa device cannot calculate RESR, this data item SHOULD NOT be issued. 8.19. Resources (Transmit) The Resources (Receive) (RESR) data item MAY appear in theDLEP "Destination Up" signal,Peer Initialization ACK signal (Section 7.4), Peer Update (Section 7.5), Destination Up (Section 7.9), Destination Update (Section 7.13) andMUST NOT appear more than once. All other occurrencesLink Characteristics ACK (Section 7.16) signals to indicate the amount of recources for transmission (with 0 meaning 'no resources available', and 100 meaning 'all resources available') at theDLEP IPv6 Attached Subnet TLV MUSTdestination. The list of resources that might betreated as an error. As inconsidered is beyond thecasescope of this document, and is left to implementations to decide. The Resources (Transmit) data item contains theIPv4 attached subnet, once an IPv6 attached subnet has been declared, it canfollowing fields: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Item Type| Length = 1 | REST | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: TBD Length: 1 Resources (Transmit): A percentage, 0-100, representing the amount of resources allocated to transmitting data. If a device cannot calculate REST, this data item SHOULD NOT bewithdrawn without terminatingissued. 8.20. Relative Link Quality (Receive) The Relative Link Quality (Receive) (RLQR) data item MAY appear in thedestination (via "Destination Down")Peer Initialization ACK signal (Section 7.4), Peer Update (Section 7.5), Destination Up (Section 7.9), Destination Update (Section 7.13) andre-issuingLink Characteristics ACK (Section 7.16) signals to indicate the"Destination Up" signal.quality of the link for receiving data as calculated by the originating peer. TheDLEP IPv6 Attached SubnetRelative Link Quality (Receive) data itemTLVcontains the following fields: 0 1 230 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 34 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |Length = 17 | IPv6 Attached Subnet | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Attached Subnet | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Attached Subnet | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Attached Subnet | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |IPv6 Attached SubnetData Item Type| Length = 1 |Subnet MaskRLQR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+TLV Type -Data Item Type: TBDLength - 17 IPv4 Subnet - The IPv6 subnet reachable at the destination. Subnet Mask -Length: 1 Relative Link Quality (Receive): Asubnet mask (0-128) to be applied to the IPv6 subnet. 11. DLEP Protocol Signals DLEP signals are encoded asnon-dimensional integer, 1-100, representing relative link quality. A value of 100 represents astringlink ofType-Length-Value (TLV) constructs. The first TLV inthe highest quality. If aDLEP signal MUSTdevice cannot calculate the RLQR, this data item SHOULD NOT bea valid DLEP signal, as definedissued. 8.21. Relative Link Quality (Transmit) The Relative Link Quality (Transmit) (RLQT) data item MAY appear insection 11.1 of this document. Followingthe Peer Initialization ACK signalTLV is 0 or more TLVs, representing(Section 7.4), Peer Update (Section 7.5), Destination Up (Section 7.9), Destination Update (Section 7.13) and Link Characteristics ACK (Section 7.16) signals to indicate thedata items that are appropriatequality of the link for transmitting data as calculated by thesignal.originating peer. Thelayout of a DLEP signal is thus:Relative Link Quality (Transmit) data item contains the following fields: 0 1 230 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 34 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |DLEP Signal |DLEP Signal length (length of |Start of DLEPData Item Type| Length = 1 | RLQT |Type+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: TBD Length: 1 Relative Link Quality (Transmit): A non-dimensional integer, 1-100, representing relative link quality. A value|all data items) |data item TLVs | | (value TBD) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ All DLEP signals begin with this structure. Therefore, in the following descriptionsofspecific signals,100 represents a link of the highest quality. If a device cannot calculate the RLQT, thisheader structure is assumed, and will notdata item SHOULD NOT bereplicated. 11.1 Signal TLV Values As mentioned above, all DLEP signals begin with the Type value. Valid DLEP signals are: TLV TLV Value Description ========================================= TBD Peer Discovery TBD Peer Offer TBD Peer Initialization TBD Peer Update TBD Peer Update ACK TBD Peer Termination TBD Peer Termination ACK TBD Destination Up TBD Destination Up ACK TBD Destination Down TBD Destination Down ACK TBD Destination Update TBD Heartbeat TBDissued. 8.22. Link CharacteristicsRequest TBDACK Timer The Link Characteristics ACK11.2 Peer Discovery Signal The Peer Discovery Signal is sent by a router to discover DLEP routersTimer data item MAY appear in thenetwork. The Peer OfferLink Characterisitics Request signalis required(Section 7.15) tocompleteindicate thediscovery process. Implementations MAY implement their own retry heuristics in cases where it is determineddesired number of seconds to thePeer Discovery Signal has timed out. To constructsender will wait for aPeer Discovery signal,response to theinitial TLV Type valuerequest. If this data item isset to DLEP_PEER_DISCOVERY (value TBD).omitted, implementations supporting the Link Characteristics Request SHOULD choose a default value. Thesignal TLV MUST be followed byLink Characteristics ACK Timer data item contains themandatoryfollowing fields: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ItemTLVs. MandatoryType| Length = 1 | Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data ItemTLVs: - DLEP Version - Heartbeat Interval There are NO optional data itemsType: TBD Length: 1 Interval: 0 = Do NOT use timeouts forthe Peer Discovery signal. 11.3 Peer Offer Signal The Peer Offer Signal is sent by a DLEP modemLink Characteristics requests on this router/modem session. Non-zero = Interval, inresponseseconds, to wait before considering aPeer Discovery Signal. Upon receipt, and processing, of a Peer Offer signal, the router responds by issuing a TCP connectLink Characteristics Request has been lost. 9. Credit-Windowing DLEP includes an OPTIONAL credit-windowing scheme analogous to theaddress/port combination specifiedone documented in [RFC5578]. In this scheme, traffic between thereceived Peer Offer. The Peer Offer signal MUST be sent to the unicast address of the originator of Peer Discovery. To construct a Peer Offer signal, the initial TLV type value is set to DLEP_PEER_OFFER (value TBD). The signal TLVrouter and modem isthen followed by all mandatory Data Item TLVs, then by any optional Data Item TLVstreated as two unidirectional windows. This document identifies these windows as theimplementation supports: Mandatory Data Item TLVs: - DLEP Version - Heartbeat Interval - At least one (1) IPv4'Modem Receive Window', orIPv6 Address TLV - DLEP Port Optional Data Item TLVs: - Peer Type - Status 11.4 Peer Initialization Signal The Peer Initialization signal is sent by a router to start the DLEP TCP session. It is sent byMRW, and therouter after a TCP connect to an address/port combination that was obtained either via receipt of a Peer Offer,'Router Receive Window', orfrom a-priori configuration.RRW. Ifany optional signals or data items are supported bytheimplementation, theyOPTIONAL credit-windowing scheme is used, credits MUST beenumerated ingranted by theDLEP Optional Signals Supported and DLEP Optional Data Items Supported items. Mandatory Data Item TLVs: - DLEP Version - Heartbeat Interval - Optional Signals Supported - Optional Data Items Supported Optional Data Item TLVs:receiver on a given window -Peer Type Ifthat is, on theOptional Signals Supported (or'Modem Receive Window' (MRW), theOptional Data Items Supported) TLVmodem isabsent in Peer Initialization,responsible for granting credits to thereceiver ofrouter, allowing it (the router) to send data to thesignal MUST conclude that there is NO optional support inmodem. Likewise, thesender. 11.5 Peer Initialization ACK Signal The Peer Initialization ACK signalrouter isa mandatory signal, sent in response to a received Peer Initialization signal. The Peer Initialization ACK signal completes the TCP-level DLEP session establishment;responsible for granting credits on thesender ofRRW, which allows thesignal should transitionmodem toan "in- session" state when the signal is sent, and the receiver should transitionsend data to the"in-session" state upon receipt (and successful parsing) of Peer Initialization ACK. All supported metricrouter. DLEP expresses all credit dataitems MUST be includedin number of octets. The total number of credits on a window, and thePeer Initialization ACK signal, with default valuesincrement to add tobe used ona"modem-wide" basis. This can be viewedgrant, are always expressed as a 64-bit unsigned integer quantity. If used, credits are managed on a neighbor-specific basis; that is, separate credit counts are maintained for each neighbor requiring the service. Credits do not apply to themodem "declaring" all supported metrics atDLEP sessioninitialization. Receipt of any DLEP signal containingthat exists between routers and modems. If ametricpeer is able to support the OPTIONAL credit-windowing scheme then it MUST include a Extensions Supported data itemNOT included(Section 8.6) including the value DLEP_EXT_CREDITS (value TBD) in the appropriate Peer Initialization or Peer Initialization ACKMUST be treated as an error, resulting in termination of thesignal. 9.1. Credit-Windowing Signals The credit-windowing scheme introduces no additional DLEP signals. However, if a peer has advertised during sessionbetween router and modem. If optional signals and/or data items are supported byinitialization that it supports themodem, they MUST be enumerated incredit-windowing scheme then the following DLEPOptional Signals supported and DLEP Optionalsignals may contain additional credit-windowing dataitems supported TLVs.items: 9.1.1. Destination Up Signal ThePeer Initialization ACKDestination Up signal MAY contain one of each of theDLEP Vendor Extension data item, as documented in section 10.22 After the Peer Initialization/Peer Initialization ACK signals have been successfully exchanged, implementations SHOULD only utilize options that are supported in BOTH peers (e.g. router and modem). Any attempt by a DLEP session peer to send an optional signal to a peer without support MUST result in an error which terminates the session. Any optionalfollowing dataitem sent to a peer without support will be ignored and silently dropped. To construct a Peer Initializationitems: o Credit Grant (Section 9.2.2) 9.1.2. Destination Up ACKsignal, the initial TLV type value is set to DLEP_PEER_INIT_ACK (value TBD).Signal The Destination Up ACK signalTLV is then followed byMAY contain one of each of therequiredfollowing data items:Mandatory Data Item TLVs: - DLEP Version - Heartbeat Interval - Maximum Data Rate Receive - Maximum Data Rate Transmit - Current Data Rate Receive - Current Data Rate Transmit - DLEP Optional Signals Supported - DLEP Optional Data Items Supported -o Credit Window StatusOptional Data Item TLVs: - Peer Type - DLEP Vendor Extension - Latency - Relative Link Quality Receive - Relative Link Quality Transmit - Resources (Receive) - Resources (Transmit) 11.6 Peer(Section 9.2.1) 9.1.3. Destination Update Signal ThePeer Update signal is an optional signal, sent by a DLEP peer to indicate local Layer 3 address changes, or for metric changes on a modem-wide basis. For example, addition of an IPv4 address to the router MAY prompt a PeerDestination Update signalto its attached DLEP modems. Also, a modem that changes its Maximum Data Rate for all destinationsMAYreflect that change via a Peer Update Signal to its attached router(s). Concerning Layer 3 addresses, if the modem is capablecontain one of each ofunderstanding and forwarding this information (via proprietary mechanisms), the address update would prompt any remote DLEP modems (DLEP-enabled modems in a remote node) to issue a "Destination Update" signal to their local routers with the new (or deleted) addresses. Modems that do not track Layer 3 addresses SHOULD silently parse and ignore the Peer Update Signal. Modems that track Layer 3 addresses MUST acknowledge the Peer Update with a Peer Update ACK signal. Routers receiving a Peer Update with metric changes MUST apply the new metric to all destinations (remote nodes) accessible viathemodem. Supporting implementations are free to employ heuristics to retransmit Peer Update signals.following data items: o Credit Window Status (Section 9.2.1) o Credit Grant (Section 9.2.2) o Credit Request (Section 9.2.3) 9.2. Credit-Windowing Data Items Thesending of Peer Update Signals for Layercredit-windowing scheme introduces 3address changes SHOULD cease whenadditional data items. If aeither participant (router or modem) determinespeer has advertised during session initialization that it supports theother implementation does NOT support Layer 3 address tracking. If metrics are supplied with the Peer Update signal (e.g. Maximum Data Rate), these metrics are considered to be modem-wide, and thereforecredit-windowing scheme then it MUSTbe applied to all destinations in the information base associated with the router/modem session. To construct a Peer Update signal,correctly process theinitial TLV type value is set to DLEP_PEER_UPDATE (value TBD). The Signal TLV is followed by any OPTIONAL Data Item TLVs. Optionalfollowing data items without error. +------------+-----------------------+----------------+ | Data ItemTLVs: - IPv4 Address - IPv6 Address - Maximum Data Rate (Receive) - Maximum Data Rate (Transmit) - Current Data Rate (Receive) - Current Data Rate (Transmit) - Latency - Resources (Receive) - Resources (Transmit) - Relative Link Quality (Receive) - Relative Link Quality (Transmit) 11.7 Peer Update ACK Signal The Peer Update ACK signal is an optional signal, and is sent by implementations supporting Layer 3 address tracking and/or modem-wide metrics to indicate whether a Peer Update Signal was successfully processed.| Description | Section | +------------+-----------------------+----------------+ | TBD | Credit Window Status | Section 9.2.1 | | TBD | Credit Grant | Section 9.2.2 | | TBD | Credit Request | Section 9.2.3 | +------------+-----------------------+----------------+ 9.2.1. Credit Window Status If thePeer Update ACKcredit-window scheme isissued, it MUST contain a Status data item, indicating the success or failure of processingsupported by thereceived Peer Update. To construct a Peer Update ACK signal,DLEP participants (both theinitial TLV type value is set to DLEP_PEER_UPDATE_ACK (value TBD). The Status data item TLV is placed inrouter and thepacket next, completingmodem), thePeer Update ACK. Mandatory Data Item TLVs: -Credit Window StatusNote that there are NO optionaldata itemTLVs specified for this signal. 11.8 Peer Termination Signal The Peer Termination Signal isMUST be sent bya DLEP participant whentherouter/modem session needs to be terminated. Implementationsparticipant receiving aPeer Termination signal MUST send a Peer Termination ACK signal to confirm the termination process. The sender of a Peer Termination signal is free to define its heuristics in event ofCredit Grant for atimeout.given destination. Thereceiver of a Peer Termination Signal MUST release all resources allocated for the router/modem session, and MUST eliminate all destinations inCredit Window Status data item contains theinformation base accessible viafollowing 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Item Type| Length = 16 | Modem Receive Window Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Modem Receive Window Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Modem Receive Window Value | Router Receive Window Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router Receive Window Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router Receive Window Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: TBD Length: 16 Modem Receive Window Value: A 64-bit unsigned integer, indicating therouter/modem pair represented bycurrent (or initial) number of credits available on thesession.Modem Receive Window. Routerand modem state machines are returned to the "discovery" state. No Destination Down signals are sent. To construct a Peer Termination signal,Receive Window Value: A 64-bit unsigned integer, indicating theinitial TLV type value is set to DLEP_PEER_TERMINATION (value TBD). The signal TLV is followed by any OPTIONAL Data Item TLVscurrent (or initial) number of credits available on theimplementation supports: Optional Data Item TLVs: - Status 11.9 Peer Termination ACK SignalRouter Receive Window. 9.2.2. Credit Grant ThePeer Termination Signal ACKCredit Grant data item is sentbyfrom a DLEPpeer in responseparticipant toa received Peer Termination order. Receipt of a Peer Termination ACK signal completes the teardown of the router/modem session. To construct a Peer Termination ACK signal, the initial TLV type value is setgrant an increment toDLEP_PEER_TERMINATION_ACK (value TBD).credits on a window. TheIdentificationCredit Grant data itemTLV is placedMAY appear in thepacket next, followed by any OPTIONAL TLVs the implementation supports: Optional Data Item TLVs: - Status 11.10Destination UpSignal A DLEP participant sends the(Section 7.9) or DestinationUp signal to report thatUpdate (Section 7.13) signals. The value in anew destination has been detected. A Destination Up ACK Signal is requiredCredit Grant data item represents an increment toconfirm a received Destination Up. A Destination Up signal canbesent either by the modem, to indicate that a new remote node has been detected, or by the router,added toindicateany existing credits available on thepresencewindow. Upon successful receipt and processing of anew logical destination (e.g., a Multicast group) exists in the network. The sender ofCredit Grant data item, theDestination Up Signal is free to define its retry heuristics in event of a timeout. Whenreceiver MUST respond with aDestination Upsignalis received and successfully parsed, the receiver should add knowledge of the new destination to its information base, indicating that the destination is accessible via the modem/router pair. To constructcontaining aDestination Up signal, the initial TLV type value is set to DLEP_DESTINATION_UP (value TBD). The MAC Address data item TLV is placed in the packet next, followed by any supported optional Data Item TLVs into the packet: Optional Data Item TLVs: - IPv4 Address - IPv6 Address - Maximum Data Rate (Receive) - Maximum Data Rate (Transmit) - Current Data Rate (Receive) - Current Data Rate (Transmit) - Latency - Resources (Receive) - Resources (Transmit) - Relative Link Factor (Receive) - Relative Link Factor (Transmit) -Credit Window Status- IPv4 Attached Subnet - IPv6 Attached Subnet 11.11 Destination Up ACK Signal A DLEP participant sends the Destination Up ACK Signaldata item toindicate whether a Destination Up Signal was successfully processed. To construct areport the updated aggregate values for synchronization purposes. In the Destination UpACKsignal, when credits are desired, theinitial TLV type value isoriginating peer MUST setto DLEP_DESTINATION_UP_ACK (value TBD). The MAC Address data item TLV is placed in the packet next, containingtheMAC addressinitial credit value of theDLEP destination. The implementation would then place any supported optional Data Item TLVs into the packet: Optional Data Item TLVs: - Credit Window Status 11.12 Destination Down Signal A DLEP peer sendswindow it controls (i.e., theDestination Down signal to report when a destination (a remote nodeModem Receive Window, or Router Receive Window) to an initial, non-zero value. If the receiver of amulticast group) is no longer reachable. TheDestinationDownUp signalMUST contain the MAC Addresswith a Credit Grant data itemTLV. Other TLVs as listed are OPTIONAL, and MAY be present if an implementationsupportsthem. A Destination Down ACK Signalcredits, the receiver MUSTbe sent byeither reject therecipientuse of credits, via a DestinationDown signal to confirm that the relevant data has been removed from the information base. The sender of the Destination Down signal is free to define its retry heuristics in event ofUp ACK response containing atimeout. To constructStatus data item (Section 8.2) with aDestination Down signal,status code of 'Request Denied', or set the initialTLV typevalueis set to DLEP_DESTINATION_DOWN (value TBD). The signal TLV is followed byfrom themandatory MAC Address data item TLV. Note that there are NO OPTIONALdataitem TLVs for this signal. 11.13 Destination Down ACK Signal A DLEP participant sendscontained in theDestination Down ACK Signal to indicate whether a received Destination Down Signal was successfully processed.Credit Window Status data item. Ifsuccessfully processed,thesender ofinitialization completes successfully, theACKreceiver MUSThave removed all entries in the information base that pertain to the referenced destination. As with the Destination Down signal, there are NO OPTIONAL Data Item TLVs defined for the Destination Down ACK signal. To construct a Destination Down signal, the initial TLV type value is setrespond toDLEP_DESTINATION_DOWN_ACK (value TBD). The mandatory data item TLVs follow: - MAC Address Data item - Status data item 11.14 Destination Update Signal A DLEP participant sendsthe DestinationUpdateUp signalwhen it detects some change in the information base for a given destination (remote node or multicast group). Some examples of changes that would promptwith a DestinationUpdateUp ACK signalare: - Change in link metrics (e.g., Data Rates) - Layer 3 addressing change (for implementationsthatsupport it) To constructcontains aDestination Update signal, the initial TLV type value is set to DLEP_DESTINATION_UPDATE (value TBD). Following the signal TLV are the mandatory Data Item TLVs: MAC AddressCredit Window Status dataitem TLV After placing the mandatoryitem, initializing its receive window. The Credit Grant data itemTLV into the packet,contains theimplementation would place any supported OPTIONAL data item TLVs. Possible OPTIONAL data item TLVs are: - IPv4 Address - IPv6 Address - Maximum Data Rate (Receive) - Maximum Data Rate (Transmit) - Current Data Rate (Receive) - Currentfollowing 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DataRate (Transmit) - Latency - Resources (Receive) - Resources (Transmit) - Relative Link Quality (Receive) - Relative Link Quality (Transmit) -Item Type| Length = 8 | CreditWindow Status -Increment | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CreditGrant -Increment | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CreditRequest 11.15 Heartbeat SignalIncrement | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: TBD Length: 8 Reserved: AHeartbeat Signal is sent by a DLEP participant every N seconds, where N is defined in the "Heartbeat Interval" field of the Peer Initialization signal. Note that implementations setting the Heartbeat Interval to 0 effectively set64-bit unsigned integer representing theintervaladditional credits toan infinite value, therefore, in those cases, this signal would NOTbesent. The signal is used by participantsassigned todetect when a DLEP session partner (eitherthemodem orcredit window. Since credits can only be granted by therouter) is no longer communicating. Participants SHOULD allow two (2) heartbeat intervals to expire with no trafficreceiver onthe router/modem session before initiating DLEP session termination procedures. To constructaHeartbeat signal,window, theinitial TLV type value is set to DLEP_PEER_HEARTBEAT (value TBD). The signal TLV is followed byapplicable credit window (either themandatory Heartbeat Interval/Threshold data item. Note that there are NO OPTIONAL data item TLVs for this signal. 11.16 Link Characteristics Request Signal The Link Characteristics Request Signal is an optional signal, and is sent byMRW or therouter to request thatRRW) is derived from themodem initiate changes for specific characteristicssender of thelink.grant. Therequest can reference either a real (e.g., a remote node), or a logical (e.g., a multicast group) destination withinCredit Increment MUST NOT cause thenetwork. The Link Characteristics Request signal contains either a Current Data Rate (CDRR or CDRT) TLV to request a different datarate than what is currently allocated, a Latency TLVwindow torequest that traffic delay on the link not exceedoverflow; if this condition occurs, implementations MUST set thespecified value, or both. A Link Characteristics ACK Signal is requiredcredit window tocompletetherequest. Implementations are free to define their retry heuristicsmaximum value contained inevent of a timeout. IssuingaLink Characteristics64-bit quantity. 9.2.3. Credit Requestwith ONLY the MAC Address TLV is a mechanism a peerThe Credit Request data item MAYuse to request metrics (via the Link Characteristics ACK)be sent fromits partner. To construct a Link Characteristics Request signal, the initial TLV type value is set to DLEP_Destination_LINK_CHAR_REQ (value TBD). Followingeither DLEP participant, via the Destination Update signalTLV is(Section 7.13), to indicate themandatory Data Item TLV: MAC Address data item TLV After placingdesire for themandatorypartner to grant additional credits in order for dataitem TLV into the packet,transfer to proceed on theimplementation would place any supported OPTIONAL data item TLVs. Possible optional data item TLVs are: Current Data Rate -session. Ifpresent, this value represents the NEW (or unchanged, iftherequest is denied) Current Data Rate in bits per second (bps). Latency - If present,corresponding Destination Up signal (Section 7.9) for thisvalue represents the maximum desired latency (e.g., it issession did NOT contain anot-to-exceed value) in microseconds on the link. 11.17 Link Characteristics ACK Signal The LInk Characteristics ACK signal is an optional signal, and is sent by modems supporting itCredit Window Status data item, indicating that credits are to be used on therouter lettingsession, then therouter knowCredit Request data item MUST be rejected by thesuccess or failure ofreceiver via arequested change in link characteristics. The Link CharacteristicsDestination Update ACK signalSHOULD containcontaining acomplete set of metricStatus data itemTLVs. It MUST contain the same TLV types as the request.(Section 8.2) with status code 'Request Denied'. Thevalues in the metricCredit Request data itemTLVs in the Link Characteristics ACK signal MUST reflect the link characteristics after the request has been processed. To construct a Link Characteristics Request ACK signal,contains theinitial TLV type value isfollowing fields: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Item Type| Length = 1 | Reserved, MUST| | | | be set toDLEP_Destination_LINK_CHAR_ACK (value TBD). Following the signal TLV is the mandatory0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data ItemTLV: MAC Address data item TLV After placing the mandatory data item TLV into the packet, the implementation would place any supported OPTIONAL data item TLVs. Possible OPTIONAL data item TLVs are: Current Data Rate - If present, this value represents the requested data rate in bits per second (bps). Latency - If present, this value represents the NEW maximum latency (or unchanged, if the requestType: TBD Length: 1 Reserved: This field isdenied), expressed in microseconds, on the link. 12.currently unused and MUST be set to 0. 10. Security Considerations The protocol does not contain any mechanisms for security(e.g.(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.13.11. IANA Considerations This section specifies requests to IANA.13.111.1. Registrations This specification defines: o A new repository for DLEP signals, withfifteensixteen values currently assigned. o Reservation of numbering space for Experimental DLEP signals. o A new repository for DLEPData Items,data items, withtwenty-onetwenty-three values currently assigned. o Reservation of numbering space in theData Itemsdata items repository for experimental data items. o A new repository for DLEP status codes. o A new repository for DLEP extensions, with one value currently assigned. o A request for allocation of a well-known port for DLEP communication. o A request for allocation of a multicast address for DLEP discovery.13.211.2. Expert Review: Evaluation Guidelines No additional guidelines for expert review are anticipated.13.311.3. SignalTLVType Registration A new repository must be created with the values of the DLEP signals. All signal values are in the range [0..255]. Valid signals are: o Peer Discovery o Peer Offer o Peer Initialization o Peer Initialization ACK o Peer Update o Peer Update ACK o Peer Termination o Peer Termination ACK o Destination Up o Destination Up ACK o Destination Down o Destination Down ACK o Destination Update o Heartbeat o Link Characteristics Request o Link Characteristics ACK It is also requested that the repository contain space for experimental signal types.13.411.4. DLEP Data Item Registrations A new repository for DLEPData Itemsdata items must be created. All data item values are in the range [0..255]. ValidData Itemsdata items are: o DLEP Version o Status o DLEP Port o Peer Type o Heartbeat Interval o Extensions Supported o Experimental Definition o MAC Address o IPv4 Address o IPv6 Address o IPv4 Attached Subnet o IPv6 Attached Subnet o Maximum Data Rate (Receive) o Maximum Data Rate (Transmit) o Current Data Rate (Receive) o Current Data Rate (Transmit) o Latency o Resources (Receive) o Resources (Transmit) o Relative Link Quality (Receive) o Relative Link Quality (Transmit) oStatus o Heartbeat Interval/Threshold oLink Characteristics ACK Timer o Credit Window Status o Credit Grant o Credit Requesto DLEP Optional Signals Supported o DLEP Optional Data Items Supported o DLEP Vendor ExtensionIt is also requested that the registry allocation contain space for experimental data items.13.511.5. DLEP Status Code Registrations A new repository for DLEP status codes must be created. All status codes are in the range [0..255]. Valid status codes are: o Success (value 0) o Unknown Signal o Invalid Signal o Unexpected Signal o Request Denied o Timed Out 11.6. DLEP Extensions Registrations A new repository for DLEP extensions must be created. All extension values are in the range [0..255]. Valid extensions are: o DLEP_EXT_CREDITS - Credit windowing 11.7. DLEP Well-known Port It is requested that IANA allocate a well-known port number for DLEP communication.13.611.8. DLEP Multicast Address It is requested that IANA allocate a multicast address for DLEP discovery signals.14.12. Acknowledgements The authors would like to acknowledge and thank the members of the DLEP design team, who have provided invaluable insight. The members of the design team are: Teco Boot, Bow-Nan Cheng, John Dowdell, and Henning Rogge. The authors would also like to acknowledge the influence and contributions of Greg Harrison, Chris Olsen, Martin Duke, Subir Das, Jaewon Kang, Vikram Kaul, and Nelson Powell. 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5578] Berry, B., Ratliff, S., Paradise, E., Kaiser, T., and M. Adams, "PPP over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics", RFC 5578, February 2010. 13.2. Informative References [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. Appendix A.14.1Peer Level Signal Flows14.1.1_NB_ The following diagrams are possibly out of date. If there is a discepancy with the text, then the text is correct. A.1. Router Device Restarts Discovery Router Modem Signal Description ==================================================================== --------Peer Discovery--------> Router initiates discovery <--------Peer Offer------------ Modem detects a problem, sends w/ Non-zero Status TLV Peer Offer w/Status TLV indicating the error. Router accepts failure, restarts discovery process. --------Peer Discovery--------> Router initiates discovery <--------Peer Offer------------ Modem accepts, sends Peer Offer w/Zero Status TLV indicating success. Discovery completed.14.1.2A.2. Router Device Detects Peer Offer Timeout Router Modem Signal Description ==================================================================== --------Peer Discovery--------> Router initiates discovery, starts a guard timer. Router guard timer expires. Router restarts discovery process. --------Peer Discovery--------> Router initiates discovery, starts a guard timer. <--------Peer Offer------------ Modem accepts, sends Peer Offer w/Zero Status TLV indicating success. Discovery completed.14.1.3A.3. Router Peer Offer Lost Router Modem Signal 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.14.1.4A.4. Discovery Success Router Modem Signal Description ==================================================================== <-------Peer Discovery--------- Modem initiates discovery ---------Peer Offer-----------> Router offers availability <-----Peer Initialization------ Modem Connects on TCP Port <------Peer Heartbeat---------- -------Peer Heartbeat---------> <==============================> Signal flow about destinations (i.e. Destination Up, Destination Down, Destination update) <-------Peer Heartbeat--------- -------Peer Heartbeat---------> --------Peer Term Req---------> Terminate Request <--------Peer Term Res--------- Terminate Response14.1.5A.5. Router Detects a Heartbeat timeout Router Modem Signal Description ==================================================================== <-------Peer Heartbeat--------- -------Peer Heartbeat---------> ||---Peer Heartbeat--------- ~ ~ ~ ~ ~ ~ ~ -------Peer Heartbeat---------> ||---Peer Heartbeat--------- Router Heartbeat Timer expires, detects missing heartbeats. Router takes down all destination sessions and terminates the Peer association. ------Peer Terminate ---------> Peer Terminate Request Modem takes down all destination sessions, then acknowledges the Peer Terminate <----Peer Terminate ACK--------- Peer Terminate ACK14.1.6A.6. Modem Detects a Heartbeat timeout Router Modem Signal Description ==================================================================== <-------Peer Heartbeat--------- -------Peer Heartbeat------|| <-------Peer Heartbeat--------- ~ ~ ~ ~ ~ ~ ~ -------Peer Heartbeat------|| <-------Peer Heartbeat--------- Modem Heartbeat Timer expires, detects missing heartbeats. Modem takes down all destination sessions <-------Peer Terminate-------- Peer Terminate Request Router takes down all destination sessions, then acknowledges the Peer Terminate ------Peer Terminate ACK-----> Peer Terminate ACK14.1.7A.7. Peer Terminate (from Modem) Lost Router Modem Signal 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 ACK14.1.8A.8. Peer Terminate (from Router) Lost Router Modem Signal Description ==================================================================== -------Peer Terminate--------> Router Peer Terminate Request Modem HB times out, terminates association. <------Peer Terminate-------- Modem Peer Terminate ------Peer Terminate ACK-----> Peer Terminate ACK14.2Appendix B. Destination Specific Signal Flows14.2.1B.1. Modem Destination Up Lost Router Modem Signal Description ==================================================================== ||-----Destination Up ------------ Modem sends Destination Up Modem timesout on ACK <------Destination Up ------------ Modem sends Destination Up ------Destination Up ACK---------> Router accepts the destination session <------Destination Update--------- Modem Destination Metrics . . . . . . . . <------Destination Update--------- Modem Destination Metrics14.2.2B.2. Router Detects Duplicate Destination Ups Router Modem Signal Description ==================================================================== <------Destination Up ------------ Modem sends Destination Up ------Destination Up ACK-------|| Router accepts the destination session Modem timesout on ACK <------Destination Up ------------ Modem resends Destination Up Router detects duplicate Destination, takes down the previous, accepts the new Destination. ------Destination Up ACK---------> Router accepts the destination session <------Destination Update--------- Modem Destination Metrics . . . . . . . . <------Destination Update--------- Modem Destination Metrics14.2.3B.3. Destination Up, No Layer 3 Addresses Router Modem Signal Description ==================================================================== <------Destination Up ------------ Modem sends Destination Up ------Destination Up ACK---------> Router accepts the destination session Router ARPs for IPv4 if defined. Router drives ND for IPv6 if defined. <------Destination Update--------- Modem Destination Metrics . . . . . . . . <------Destination Update--------- Modem Destination Metrics14.2.4B.4. Destination Up with IPv4, No IPv6 Router Modem Signal Description ==================================================================== <------Destination Up ------------ Modem sends Destination Up with the IPv4 TLV ------Destination Up ACK---------> Router accepts the destination session Router drives ND for IPv6 if defined. <------Destination Update--------- Modem Destination Metrics . . . . . . . . <------Destination Update--------- Modem Destination Metrics14.2.5B.5. Destination Up with IPv4 and IPv6 Router Modem Signal Description ==================================================================== <------Destination Up ------------ Modem sends Destination Up with the IPv4 and IPv6 TLVs ------Destination Up ACK---------> Router accepts the destination session <------Destination Update--------- Modem Destination Metrics . . . . . . . .14.2.6B.6. Destination Session Success Router Modem Signal Description ==================================================================== ---------Peer Offer-----------> Router offers availability -------Peer Heartbeat---------> <------Destination Up ----------- Modem ------Destination Up ACK--------> Router <------Destination Update--------- Modem . . . . . . . . <------Destination Update--------- Modem Modem initiates the terminate <------Destination Down ---------- Modem ------Destination Down ACK-------> Router or Router initiates the terminate ------Destination Down ----------> Router <------Destination Down ACK------- ModemAcknowledgements The authors would like to acknowledge and thank the members of the DLEP design team, who have provided invaluable insight. The members of the design team are: Teco Boot, Bow-Nan Cheng, John Dowdell, Henning Rogge, and Rick Taylor. The authors would also like to acknowledge the influence and contributions of Chris Olsen, Martin Duke, Subir Das, Jaewon Kang, Vikram Kaul, and Nelson Powell. Normative References [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 [IEEE] http://standards.ieee.org/develop/regauth/oui/index.html Informative References [TLS] Dierks, T. and Rescorla, E. "The Transport Layer Security (TLS) Protocol", RFC 5246, August 2008. Author'sAuthors' Addresses Stan RatliffIndependent ConsultantVT iDirect 13861 Sunrise Valley Drive, Suite 300 Herndon, VA 20171 USAEMail: ratliffstan@gmail.comEmail: sratliff@idirect.net Bo BerryCisco 170 West Tasman Drive San Jose, CA 95134 USA EMail: Greg Harrison Cisco 170 West Tasman Drive San Jose, CA 95134 USA EMail: greharri@cisco.comShawn Jury Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA Email: sjury@cisco.com Darryl Satterwhite BroadcomUSAEmail: dsatterw@broadcom.com Rick Taylor Airbus Defence & Space Quadrant House Celtic Springs Coedkernew Newport NP10 8FZ UK Email: rick.taylor@airbus.com