idnits 2.17.1 draft-ietf-manet-dlep-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 271 has weird spacing: '... Shared o ...' == Line 272 has weird spacing: '... Medium o...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: As mentioned above, DLEP defines a core set of signals and data items as mandatory. Support for those signals and data items MUST exist in an implementation to guarantee interoperability and therefore make an implementation DLEP compliant. However, a mandatory signal or data item is not necessarily required - as an example, consider the data item entitled "DLEP Optional Signals Supported", defined in section 10.22 of this document. The data item allows a DLEP implementation to list all optional behavior it supports, and is sent as a part of the Peer Initialization signal. Receiving implementations MUST be capable of parsing and understanding the optional signals that are offered. However, if the sending implementation has chosen NOT to implement ANY optional functionality, this data item would NOT be included in the Peer Initialization. Although parsing and understanding the data item is a mandatory function of a compliant DLEP, the data item itself MAY, or MAY NOT, appear in the flow. Absence of the mandatory data item would not be considered a protocol error, but as support for the core DLEP signals ONLY. Therefore, care should be taken to differentiate the notion of a mandatory data item versus one that MUST appear in a given message. -- The document date (October 24, 2014) is 3472 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 5578 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE' -- Obsolete informational reference (is this intentional?): RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networks Working S. Ratliff 3 Group Independent Consultant 4 Internet-Draft B. Berry 5 Intended status: Standards Track G. Harrison 6 Expires: April 2, 2015 S. Jury 7 Cisco Systems 8 D. Satterwhite 9 Broadcom 10 October 24, 2014 12 Dynamic Link Exchange Protocol (DLEP) 13 draft-ietf-manet-dlep-07 15 Abstract 17 When routing devices rely on modems to effect communications over 18 wireless links, they need timely and accurate knowledge of the 19 characteristics of the link (speed, state, etc.) in order to make 20 forwarding decisions. In mobile or other environments where these 21 characteristics change frequently, manual configurations or the 22 inference of state through routing or transport protocols does not 23 allow the router to make the best decisions. A bidirectional, event- 24 driven communication channel between the router and the modem is 25 necessary. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on August 14, 2014. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 8 69 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 3. Mandatory Versus Optional Items . . . . . . . . . . . . . . . . 9 71 4. Credits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 5. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 6. Extensions to DLEP . . . . . . . . . . . . . . . . . . . . . . 11 74 6.1 Protocol Extensions . . . . . . . . . . . . . . . . . . . . 11 75 6.2 Vendor Extensions . . . . . . . . . . . . . . . . . . . . . 11 76 6.3 Experimental Extensions . . . . . . . . . . . . . . . . . . 11 77 7. Normal Session Flow . . . . . . . . . . . . . . . . . . . . . 12 78 7.1 DLEP Router session flow - Discovery case . . . . . . . . . 12 79 7.2 DLEP Router session flow - Configured case . . . . . . . . . 12 80 7.3 DLEP Modem session flow . . . . . . . . . . . . . . . . . . 13 81 7.4 Common Session Flow . . . . . . . . . . . . . . . . . . . . 14 82 8. Mandatory Signals and Data Items . . . . . . . . . . . . . . . 14 83 9. Generic DLEP Signal Definition . . . . . . . . . . . . . . . . 16 84 10. DLEP Data Items . . . . . . . . . . . . . . . . . . . . . . . 16 85 10.1 DLEP Version . . . . . . . . . . . . . . . . . . . . . . . 17 86 10.2 DLEP Port . . . . . . . . . . . . . . . . . . . . . . . . 18 87 10.3 Peer Type . . . . . . . . . . . . . . . . . . . . . . . . 18 88 10.4 MAC Address . . . . . . . . . . . . . . . . . . . . . . . 19 89 10.5 IPv4 Address . . . . . . . . . . . . . . . . . . . . . . . 19 90 10.6 IPv6 Address . . . . . . . . . . . . . . . . . . . . . . . 20 91 10.7 Maximum Data Rate (Receive) . . . . . . . . . . . . . . . 21 92 10.8 Maximum Data Rate (Transmit) . . . . . . . . . . . . . . . 22 93 10.9 Current Data Rate (Receive) . . . . . . . . . . . . . . . 22 94 10.10 Current Data Rate (Transmit) . . . . . . . . . . . . . . 23 95 10.11 Latency . . . . . . . . . . . . . . . . . . . . . . . . . 24 96 10.12 Resources (Receive) . . . . . . . . . . . . . . . . . . . 25 97 10.13 Resources (Transmit) . . . . . . . . . . . . . . . . . . 25 98 10.14 Relative Link Quality (Receive) . . . . . . . . . . . . . 26 99 10.15 Relative Link Quality (Transmit) . . . . . . . . . . . . 27 100 10.16 Status . . . . . . . . . . . . . . . . . . . . . . . . . 27 101 10.17 Heartbeat Interval . . . . . . . . . . . . . . . . . . . 28 102 10.18 Link Characteristics ACK Timer . . . . . . . . . . . . . 28 103 10.19 Credit Window Status . . . . . . . . . . . . . . . . . . 29 104 10.20 Credit Grant Request . . . . . . . . . . . . . . . . . . 30 105 10.21 Credit Request . . . . . . . . . . . . . . . . . . . . . 31 106 10.22 DLEP Optional Signals Supported . . . . . . . . . . . . . 31 107 10.23 DLEP Optional Data Items Supported . . . . . . . . . . . 32 108 10.24 DLEP Vendor Extension . . . . . . . . . . . . . . . . . . 33 109 10.25 IPv4 Attached Subnet . . . . . . . . . . . . . . . . . . 33 110 10.26 IPv6 Attached Subnet . . . . . . . . . . . . . . . . . . 34 111 11. DLEP Protocol Signals . . . . . . . . . . . . . . . . . . . . 35 112 11.1 Signal TLV Values . . . . . . . . . . . . . . . . . . . . 35 113 11.2 Peer Discovery Signal . . . . . . . . . . . . . . . . . . . 36 114 11.3 Peer Offer Signal . . . . . . . . . . . . . . . . . . . . . 36 115 11.4 Peer Initialization Signal . . . . . . . . . . . . . . . . 37 116 11.5 Peer Initialization ACK Signal . . . . . . . . . . . . . . 37 117 11.6 Peer Update Signal . . . . . . . . . . . . . . . . . . . . 38 118 11.7 Peer Update ACK Signal . . . . . . . . . . . . . . . . . . 39 119 11.8 Peer Termination Signal . . . . . . . . . . . . . . . . . . 40 120 11.9 Peer Termination ACK Signal . . . . . . . . . . . . . . . . 40 121 11.10 Destination Up Signal . . . . . . . . . . . . . . . . . . 40 122 11.11 Destination Up ACK Signal . . . . . . . . . . . . . . . . 41 123 11.12 Destination Down Signal . . . . . . . . . . . . . . . . . 41 124 11.13 Destination Down ACK Signal . . . . . . . . . . . . . . . 42 125 11.14 Destination Update Signal . . . . . . . . . . . . . . . . 42 126 11.15 Heartbeat Signal . . . . . . . . . . . . . . . . . . . . . 43 127 11.16 Link Characteristics Request Signal . . . . . . . . . . . 43 128 11.17 Link Characteristics ACK Signal . . . . . . . . . . . . . 44 129 12. Security Considerations . . . . . . . . . . . . . . . . . . . 45 130 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 131 13.1 Registrations . . . . . . . . . . . . . . . . . . . . . . 45 132 13.2 Expert Review: Evaluation Guidelines . . . . . . . . . . . 45 133 13.3 Signal TLV Type Registration . . . . . . . . . . . . . . . 45 134 13.4 DLEP Data Item Registrations . . . . . . . . . . . . . . . 46 135 13.5 DLEP Well-known Port . . . . . . . . . . . . . . . . . . . 47 136 13.6 DLEP Multicast Address . . . . . . . . . . . . . . . . . . 47 137 14. Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . 47 138 14.1 Peer Level Signal Flows . . . . . . . . . . . . . . . . . 47 139 14.1.1 Router Device Restarts Discovery . . . . . . . . . . . 47 140 14.1.2 Router Device Detects Peer Offer Timeout . . . . . . . 48 141 14.1.3 Router Peer Offer Lost . . . . . . . . . . . . . . . . 49 142 14.1.4 Discovery Success . . . . . . . . . . . . . . . . . . 49 143 14.1.5 Router Detects a Heartbeat timeout . . . . . . . . . . 50 144 14.1.6 Modem Detects a Heartbeat timeout . . . . . . . . . . 50 145 14.1.7 Peer Terminate (from Modem) Lost . . . . . . . . . . . 51 146 14.1.8 Peer Terminate (from Router) Lost . . . . . . . . . . 51 147 14.2 Destination Specific Signal Flows . . . . . . . . . . . . 51 148 14.2.1 Modem Destination Up Lost . . . . . . . . . . . . . . 52 149 14.2.2 Router Detects Duplicate Destination Ups . . . . . . . 52 150 14.2.3 Destination Up, No Layer 3 Addresses . . . . . . . . . 53 151 14.2.4 Destination Up with IPv4, No IPv6 . . . . . . . . . . 53 152 14.2.5 Destination Up with IPv4 and IPv6 . . . . . . . . . . 53 153 14.2.6 Destination Session Success . . . . . . . . . . . . . 54 154 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 54 155 Normative References . . . . . . . . . . . . . . . . . . . . . . . 55 156 Informative References . . . . . . . . . . . . . . . . . . . . . . 55 157 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 159 1. Introduction 161 There exist today a collection of modem devices that control links of 162 variable datarate and quality. Examples of these types of links 163 include line-of-sight (LOS) terrestrial radios, satellite terminals, 164 and cable/DSL modems. Fluctuations in speed and quality of these 165 links can occur due to configuration (in the case of cable/DSL 166 modems), or on a moment-to-moment basis, due to physical phenomena 167 like multipath interference, obstructions, rain fade, etc. It is also 168 quite possible that link quality and datarate varies with respect to 169 individual destinations on a link, and with the type of traffic being 170 sent. As an example, consider the case of an 802.11g access point, 171 serving 2 associated laptop computers. In this environment, the 172 answer to the question "What is the datarate on the 802.11g link?" is 173 "It depends on which associated laptop we're talking about, and on 174 what kind of traffic is being sent." While the first laptop, being 175 physically close to the access point, may have a datarate of 54Mbps 176 for unicast traffic, the other laptop, being relatively far away, or 177 obstructed by some object, can simultaneously have a datarate of only 178 32Mbps for unicast. However, for multicast traffic sent from the 179 access point, all traffic is sent at the base transmission rate 180 (which is configurable, but depending on the model of the access 181 point, is usually 24Mbps or less). 183 In addition to utilizing variable datarate links, mobile networks are 184 challenged by the notion that link connectivity will come and go over 185 time, without an effect on a router's interface state (Up or Down). 186 Effectively utilizing a relatively short-lived connection is 187 problematic in IP routed networks, as routing protocols tend to rely 188 on interface state and independent timers at OSI Layer 3 to maintain 189 network convergence (e.g. HELLO messages and/or recognition of DEAD 190 routing adjacencies). These dynamic connections can be better 191 utilized with an event-driven paradigm, where acquisition of a new 192 neighbor (or loss of an existing one) is signaled, as opposed to a 193 paradigm driven by timers and/or interface state. 195 Another complicating factor for mobile networks are the different 196 methods of physically connecting the modem devices to the router. 197 Modems can be deployed as an interface card in a router's chassis, or 198 as a standalone device connected to the router via Ethernet or serial 199 link. In the case of Ethernet or serial attachment, with existing 200 protocols and techniques, routing software cannot be aware of 201 convergence events occurring on the radio link (e.g. acquisition or 202 loss of a potential routing neighbor), nor can the router be aware of 203 the actual capacity of the link. This lack of awareness, along with 204 the variability in datarate, leads to a situation where finding the 205 (current) best route through the network to a given destination is 206 difficult to establish and properly maintain. This is especially true 207 of demand-based access schemes such as Demand Assigned Multiple 208 Access (DAMA) implementations used on some satellite systems. With a 209 DAMA-based system, additional datarate may be available, but will not 210 be used unless the network devices emit traffic at rate higher than 211 the currently established rate. Increasing the traffic rate does not 212 guarantee additional datarate will be allocated; rather, it may 213 result in data loss and additional retransmissions on the link. 215 Addressing the challenges listed above, the authors have developed 216 the Data Link Exchange Protocol, or DLEP. The DLEP protocol runs 217 between a router and its attached modem devices, allowing the modem 218 to communicate link characteristics as they change, and convergence 219 events (acquisition and loss of potential routing destinations). The 220 following diagrams are used to illustrate the scope of DLEP packets. 222 |-------Local Node-------| |-------Remote Node------| 223 | | | | 224 +--------+ +-------+ +-------+ +--------+ 225 | Router |=======| Modem |{~~~~~~~~}| Modem |=======| Router | 226 | | | Device| | Device| | | 227 +--------+ +-------+ +-------+ +--------+ 228 | | | Link | | | 229 |-DLEP--| | Protocol | |-DLEP--| 230 | | | (e.g. | | | 231 | | | 802.11) | | | 233 Figure 1: DLEP Network 235 In Figure 1, when the local modem detects the presence of a remote 236 node, it (the local modem) sends a signal to its router via the DLEP 237 protocol. Upon receipt of the signal, the local router may take 238 whatever action it deems appropriate, such as initiating discovery 239 protocols, and/or issuing HELLO messages to converge the network. On 240 a continuing, as-needed basis, the modem devices utilize DLEP to 241 report any characteristics of the link (datarate, latency, etc) that 242 have changed. DLEP is independent of the link type and topology 243 supported by the modem. Note that the DLEP protocol is specified to 244 run only on the local link between router and modem. Some over the 245 air signaling may be necessary between the local and remote modem in 246 order to provide some parameters in DLEP signals between the local 247 modem and local router, but DLEP does not specify how such over the 248 air signaling is carried out. Over the air signaling is purely a 249 matter for the modem implementer. 251 Figure 2 shows how DLEP can support a configuration where routers are 252 connected with different link types. In this example, Modem A 253 implements a point-to-point link, and Modem B is connected via a 254 shared medium. In both cases, the DLEP protocol is used to report the 255 characteristics of the link (datarate, latency, etc.) to routers. The 256 modem is also able to use the DLEP session to notify the router when 257 the remote node is lost, shortening the time required to re-converge 258 the network. 260 +--------+ +--------+ 261 +----+ Modem A| | Modem A+---+ 262 | | Device | <===== // ======> | Device | | 263 | +--------+ P-2-P Link +--------+ | 264 +---+----+ +---+----+ 265 | Router | | Router | 266 | | | | 267 +---+----+ +---+----+ 268 | +--------+ +--------+ | 269 +-----+ Modem B| | Modem B| | 270 | Device | o o o o o o o o | Device +--+ 271 +--------+ o Shared o +--------+ 272 o Medium o 273 o o 274 o o 275 o o 276 o 277 +--------+ 278 | Modem B| 279 | Device | 280 +---+----+ 281 | 282 | 283 +---+----+ 284 | Router | 285 | | 286 +--------+ 288 Figure 2: DLEP Network with Multiple Modem Devices 290 DLEP defines a set of signals used by modems and their attached 291 routers. The signals are used to communicate events that occur on the 292 physical link(s) managed by the modem: for example, a remote node 293 entering or leaving the network, or that the link has changed. 294 Associated with these signals are a set of data items - information 295 that describes the remote node (e.g., address information), and/or 296 the characteristics of the link to the remote node. 298 The protocol is defined as a collection of type-length-value (TLV) 299 based formats, specifying the signals that are exchanged between a 300 router and a modem, and the data items associated with the signal. 301 This document specifies transport of DLEP signals and data items via 302 the TCP transport, with a UDP-based discovery mechanism. Other 303 transports for the protocol are possible, but are outside the scope 304 of this document. 306 DLEP signals are further defined as mandatory or optional. Signals 307 will additionally have mandatory and optional data items. 308 Implementations MUST support all mandatory signals and their 309 mandatory data items to be considered compliant. Implementations MAY 310 also support some, or all, of the optional signals and data items. 312 DLEP uses a session-oriented paradigm between the modem device and 313 its associated router. If multiple modem devices are attached to a 314 router (as in Figure 2), a separate DLEP session MUST exist for each 315 modem. If a modem device supports multiple connections to a router 316 (via multiple logical or physical interfaces), or supports 317 connections to multiple routers, a separate DLEP session MUST exist 318 for each connection. This router/modem session provides a carrier for 319 information exchange concerning "destinations" that are available via 320 the modem device. A "destination" can be either physical (as in the 321 case of a specific far-end router), or a logical destination (as in a 322 Multicast group). As such, all of the destination-level exchanges in 323 DLEP can be envisioned as building an information base concerning the 324 remote nodes, and the link characteristics to those nodes. 326 Any DLEP signal that is NOT understood by a receiver MUST result in 327 an error indication being sent to the originator, and also MUST 328 result in termination of the session between the DLEP peers. Any data 329 item that is NOT understood by a receiver MUST be ignored. 331 Multicast traffic destined for the variable-quality network (the 332 network accessed via the DLEP modem) is handled in IP networks by 333 deriving a Layer 2 MAC address based on the Layer 3 address. 334 Leveraging on this scheme, Multicast traffic is supported in DLEP 335 simply by treating the derived MAC address as any other "destination" 336 (albeit a logical one) in the network. To support these logical 337 destinations, one of the DLEP participants (typically, the router) 338 informs the other as to the existence of the logical neighbor. The 339 modem, once it is aware of the existence of this logical neighbor, 340 reports link characteristics just as it would for any other 341 destination in the network. The specific algorithms a modem would use 342 to report metrics on multicast (or logical) destinations is outside 343 the scope of this specification, and is left to specific 344 implementations to decide. 346 1.1 Requirements 348 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 349 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 350 document are to be interpreted as described in BCP 14, RFC 2119 351 [RFC2119]. 353 2. Assumptions 355 Routers and modems that exist as part of the same node (e.g., that 356 are locally connected) can utilize a discovery technique to locate 357 each other, thus avoiding a-priori configuration. The router is 358 responsible for initialing the discovery process, using the Peer 359 Discovery signal. 361 DLEP utilizes a session-oriented paradigm. A router and modem form a 362 session by completing the discovery process. This router-modem 363 session persists unless or until it either (1) times out, based on 364 the timeout values supplied, or (2) is explicitly torn down by one of 365 the participants. Note that while use of timers in DLEP is OPTIONAL, 366 it is strongly recommended that implementations choose to run with 367 timers enabled. 369 DLEP assumes that participating modems, and their physical links, act 370 as a transparent IEEE 802.1D bridge. Specifically, the assumption is 371 that the destination MAC address for data traffic (frames destined 372 for the far-end node, as opposed to the DLEP control traffic itself) 373 in any frame emitted by the router should be the MAC address of a 374 device in the remote node. DLEP also assumes that MAC addresses are 375 unique within the context of the router-modem session. 377 DLEP utilizes UDP multicast for single-hop discovery, and TCP for 378 transport of the control signals. Therefore, DLEP assumes that the 379 modem and router have topologically consistent IP addresses assigned. 380 It is recommended that DLEP implementations utilize IPv6 link-local 381 addresses to reduce the administrative burden of address assignment. 383 This document refers to a remote node as a "Destination". 384 Destinations can be identified by either the router or the modem, and 385 represent a specific destination (e.g., an address) that exists on 386 the link(s) managed by the modem. A destination MUST contain a MAC 387 address, it MAY optionally include a Layer 3 address (or addresses). 388 Destinations MAY refer either to physical devices in the network, or 389 to logical destinations, as in a derived multicast MAC address 390 associated with a group. As "destinations" are discovered, DLEP 391 routers and modems build an information base on destinations 392 accessible via the modem. Changes in link characteristics MAY then be 393 reported as being "modem-wide" (effecting ALL destinations accessed 394 via the modem) or MAY be neighbor (destination) specific. 396 The DLEP signals concerning destinations thus become the way for 397 routers and modems to maintain, and notify each other about, an 398 information base representing the physical and logical (e.g., 399 multicast) destinations accessible via the modem device. The 400 information base would contain addressing information (e.g., MAC 401 address, and OPTIONALLY, Layer 3 addresses), link characteristics 402 (metrics), and OPTIONALLY, flow control information (credits). 404 DLEP assumes that security on the session (e.g. authentication of 405 session partners, encryption of traffic, or both) is dealt with by 406 the underlying transport mechanism (e.g., by using a transport such 407 as TLS [TLS]). 409 This document specifies an implementation of the DLEP signals and 410 data items running over the TCP transport. It is assumed that DLEP 411 running over other transport mechanisms would be documented 412 separately. 414 3. Mandatory Versus Optional Items 416 As mentioned above, DLEP defines a core set of signals and data items 417 as mandatory. Support for those signals and data items MUST exist in 418 an implementation to guarantee interoperability and therefore make an 419 implementation DLEP compliant. However, a mandatory signal or data 420 item is not necessarily required - as an example, consider the data 421 item entitled "DLEP Optional Signals Supported", defined in section 422 10.22 of this document. The data item allows a DLEP implementation to 423 list all optional behavior it supports, and is sent as a part of the 424 Peer Initialization signal. Receiving implementations MUST be capable 425 of parsing and understanding the optional signals that are offered. 426 However, if the sending implementation has chosen NOT to implement 427 ANY optional functionality, this data item would NOT be included in 428 the Peer Initialization. Although parsing and understanding the data 429 item is a mandatory function of a compliant DLEP, the data item 430 itself MAY, or MAY NOT, appear in the flow. Absence of the mandatory 431 data item would not be considered a protocol error, but as support 432 for the core DLEP signals ONLY. Therefore, care should be taken to 433 differentiate the notion of a mandatory data item versus one that 434 MUST appear in a given message. 436 4. Credits 438 DLEP includes an OPTIONAL credit-windowing scheme analogous to the 439 one documented in [RFC5578]. In this scheme, traffic between the 440 router and modem is treated as two unidirectional windows. This 441 document identifies these windows as the "Modem Receive Window", or 442 MRW, and the "Router Receive Window", or RRW. 444 If the OPTIONAL credit-windowing scheme is used, credits MUST be 445 granted by the receiver on a given window - that is, on the "Modem 446 Receive Window" (MRW), the modem is responsible for granting credits 447 to the router, allowing it (the router) to send data to the modem. 448 Likewise, the router is responsible for granting credits on the RRW, 449 which allows the modem to send data to the router. 451 DLEP expresses all credit data in number of octets. The total number 452 of credits on a window, and the increment to add to a grant, are 453 always expressed as a 64-bit unsigned quantity. 455 If used, credits are managed on a neighbor-specific basis; that is, 456 separate credit counts are maintained for each neighbor requiring the 457 service. Credits do not apply to the DLEP session that exists between 458 routers and modems. 460 5. Metrics 462 DLEP includes the ability for the router and modem to communicate 463 metrics that reflect the characteristics (e.g. datarate, latency) of 464 the variable-quality link in use. DLEP does NOT specify how a given 465 metric value is to be calculated, rather, the protocol assumes that 466 metrics have been calculated with a "best effort", incorporating all 467 pertinent data that is available to the modem device. 469 As mentioned in the introduction section of this document, metrics 470 have to be used within a context - for example, metrics to a unicast 471 address in the network. DLEP allows for metrics to be sent within two 472 contexts - metrics for a specific destination within the network 473 (e.g., a specific router), and "modem-wide" (those that apply to all 474 destinations accessed via the modem). Metrics can be further 475 subdivided into transmit and receive metrics. Metrics supplied on 476 DLEP Peer signals are, by definition, modem-wide; metrics supplied on 477 Destination signals are, by definition, used for the specific 478 neighbor only. 480 DLEP modem implementations MUST announce all supported metric items, 481 and provide default values for those metrics, in the Peer 482 Initialization signal. In order to introduce a new metric type, DLEP 483 modem implementations MUST terminate the session with the router (via 484 the Peer Terminate signal), and re-establish the session. 486 It is left to implementations to choose sensible default values based 487 on their specific characteristics. Modems having static (non- 488 changing) link metric characteristics MAY report metrics only once 489 for a given neighbor (or once on a modem-wide basis, if all 490 connections via the modem are of this static nature). 492 The approach of allowing for different contexts for metric data 493 increases both the flexibility and the complexity of using metric 494 data. This document details the mechanism whereby the data is 495 transmitted, however, the specific algorithms (precedence, etc) for 496 utilizing the dual-context metrics is out of scope and not addressed 497 by this document. 499 6. Extensions to DLEP 501 While this draft represents the best efforts of the co-authors, and 502 the working group, to be functionally complete, it is recognized that 503 extensions to DLEP will in all likelihood be necessary as more link 504 types are utilized. There are three possible avenues for DLEP 505 extensions: protocol extensions, vendor extensions, and experimental 506 extensions. 508 6.1 Protocol Extensions 510 If/when protocol extensions are required, they should be standardized 511 either as an update to this document, or as an additional stand-alone 512 specification. 514 6.2 Vendor Extensions 516 Vendor extensions to DLEP are accommodated via the "DLEP Vendor 517 Extension" TLV, documented in Section 10.22 of this document. If a 518 perceived extension exceeds the scope of what can be contained in the 519 DLEP Vendor Extension TLV, the proposed extension should be addressed 520 as either an update to this document, or as a stand-alone 521 specification. 523 6.3 Experimental Extensions 525 This document requests numbering space in both the Signal and Data 526 Item registries for experimental items. The intent is to allow for 527 experimentation with new signals and/or data items, while still 528 retaining the documented DLEP behavior. If a given experiment proves 529 successful, it SHOULD be documented as an update to this document, or 530 as a stand-alone specification. Experimental DLEP signals SHOULD be 531 treated as optional signals - e.g., they SHOULD be announced in the 532 "DLEP Optional Signals TLV" in Peer Initialization and/or Peer 533 Initialization ACK. Likewise, experimental data item TLVs SHOULD be 534 announced in the "DLEP Optioinal Data Items" TLV (also in Peer 535 Initialization/Peer Initialization ACK). 537 7. Normal Session Flow 539 Normal session flow for a DLEP router has two sub-cases, depending on 540 whether the implementation supports the discovery process. Since 541 modems MUST support the discovery process, there is only one 542 description necessary for modem implementations. The normal flow by 543 DLEP partner type is: 545 7.1 DLEP Router session flow - Discovery case 547 If the DLEP router implementation is utilizing the optional discovery 548 mechanism, then the implementation will initialize a UDP socket, 549 binding it to an arbitrary port. This UDP socket is used to send the 550 Peer Discovery signal to the DLEP link-local multicast address and 551 port (TBD). The implementation then waits on receipt of a Peer Offer 552 signal, which MUST contain the unicast address and port for TCP-based 553 communication with a DLEP modem. The Peer Offer signal MAY contain 554 multiple address/port combinations. If more than one address/port 555 combination is in the Peer Offer, the DLEP router implementation 556 SHOULD consider the list to be in priority sequence, with the "most 557 desired" address/port combination listed first. However, router 558 implementations MAY use their own heuristics to determine the best 559 address/port combination. At this point, the router implementation 560 MAY either destroy the UDP socket, or continue to issue Peer 561 Discovery signals to the link-local address/port combination. In 562 either case, the TCP session initialization occurs as in the 563 configured case. 565 7.2 DLEP Router session flow - Configured case 567 When a DLEP router implementation has the address and port 568 information for a TCP connection to a modem (obtained either via 569 configuration or via the discovery process described above), the 570 router will initialize and bind a TCP socket. This socket is used to 571 connect to the DLEP modem software. After a successful TCP connect, 572 the modem implementation MUST issue a Peer Initialization signal to 573 the DLEP router. The Peer Initialization signal MUST contain TLVs for 574 ALL supported metrics from this modem (e.g. all mandatory metrics 575 plus all optional metrics supported by the implementation), along 576 with the default values of those metrics. After sending the Peer 577 Initialization, the modem implementation MUST wait for receipt of a 578 Peer Initialization ACK signal from the router. Receipt of the Peer 579 Initialization ACK indicates that the router has received and 580 processed the Peer Initialization, and the session MUST transition to 581 the "in session" state. At this point, signals regarding destinations 582 in the network, and/or Peer Update signals, can flow on the DLEP 583 session between modem and router. The "in session" state is 584 maintained until one of the following conditions occur: 586 o The session is explicitly terminated (using Peer Termination), or 587 o The session times out, based on supplied timeout values. 589 7.3 DLEP Modem session flow 591 DLEP modem implementations MUST support the discovery mechanism. 592 Therefore, the normal flow is as follows: 594 The implementation will initialize a UDP socket, binding that socket 595 to the DLEP link-local multicast address (TBD) and the DLEP well- 596 known port number (also TBD). The implementation will then initialize 597 a TCP socket, on a unicast address and port. This socket is used to 598 listen for incoming TCP connection requests. 600 When the modem implementation receives a Peer Discovery signal on the 601 UDP socket, it responds by issuing a Peer Offer signal to the sender 602 of the Peer Discovery. The Peer Offer signal MUST contain the unicast 603 address and port of the TCP listen socket, described above. A DLEP 604 modem implementation MAY respond with ALL address/port combinations 605 that have an active TCP listen posted. If multiple address/port 606 combinations are listed, the receiver of the Peer Offer MAY connect 607 on any available address/port pair. Anything other than Peer 608 Discovery signals received on the UDP socket MUST be silently 609 dropped. 611 When the DLEP modem implementation accepts a connection via TCP, it 612 MUST send a Peer Initialization signal. The Peer Initialization MUST 613 contain metric TLVs for ALL mandatory metrics, and MUST contain 614 metric TLVs for ANY optional metrics supported by the modem. If a new 615 metric is to be introduced, the DLEP session between router and modem 616 MUST be terminated and restarted, and the new metric described in a 617 Peer Initialization signal. 619 7.4 Common Session Flow 621 In order to maintain the session between router and modem, periodic 622 "Heartbeat" signals MAY be exchanged. These signals are intended to 623 keep the session alive, and to verify bidirectional connectivity 624 between the two participants. DLEP also provides an OPTIONAL Peer 625 Update signal, intended to communicate some change in status (e.g., a 626 change of layer 3 address parameters, or a modem-wide link change). 628 In addition to the local (Peer level) signals above, the participants 629 will transmit DLEP signals concerning destinations in the network. 630 These signals trigger creation/maintenance/deletion of destinations 631 in the information base of the recipient. For example, a modem will 632 inform its attached router of the presence of a new destination via 633 the "Destination Up" signal. Receipt of a Destination Up causes the 634 router to allocate the necessary resources, creating an entry in the 635 information base with the specifics (e.g., MAC Address, Latency, Data 636 Rate, etc) of the neighbor. The loss of a destination is communicated 637 via the "Destination Down" signal, and changes in status to the 638 destination (e.g. varying link quality, or addressing changes) are 639 communicated via the "Destination Update" signal. The information on 640 a given neighbor will persist in the router's information base until 641 (1) a "Destination Down" is received, indicating that the modem has 642 lost contact with the remote node, or (2) the router/modem session 643 terminates, indicating that the router has lost contact with its own 644 local modem. 646 Again, metrics can be expressed within the context of a specific 647 neighbor via the Destination Update signal, or on a modem-wide basis 648 via the Peer Update signal. In cases where metrics are provided on 649 the router/modem session, the receiver MUST propagate the metrics to 650 all destinations in its information base that are accessed via the 651 originator. A DLEP participant MAY send metrics both in a 652 router/modem session context (via the Peer Update signal) and a 653 specific neighbor context (via Destination Update) at any time. The 654 heuristics for applying received metrics is left to implementations. 656 In addition to receiving metrics about the link, DLEP provides an 657 OPTIONAL signal allowing a router to request a different datarate, or 658 latency, from the modem. This signal is referred to as the Link 659 Characteristics Signal, and gives the router the ability to deal with 660 requisite increases (or decreases) of allocated datarate/latency in 661 demand-based schemes in a more deterministic manner. 663 8. Mandatory Signals and Data Items 665 The following DLEP signals are considered core to the specification; 666 implementations MUST support these signals, and the associated data 667 items, in order to be considered compliant: 669 Signal Data Items 670 ====== ========== 671 Peer Discovery (Router Only) None 673 Peer Offer (Modem Only) IPv4 Address 674 IPv6 address 675 DLEP Port 677 Peer Initialization Maximum Data Rate (Receive) 678 Maximum Data Rate (Transmit) 679 Current Data Rate (Receive) 680 Current Data Rate (Transmit) 681 Latency 682 Relative Link Quality (Receive) 683 Relative Link Quality (Transmit) 684 DLEP Optional Signal Support 685 DLEP Optional Data Item Support 687 Peer Initialization ACK Status 689 Peer Termination Status 691 Peer Termination ACK Status 693 Destination Up MAC Address 694 Maximum Data Rate (Receive) 695 Maximum Data Rate (Transmit) 696 Current Data Rate (Receive) 697 Current Data Rate (Transmit) 698 Latency 699 Relative Link Quality (Receive) 700 Relative Link Quality (Transmit) 702 Destination Update MAC Address 703 Maximum Data Rate (Receive) 704 Maximum Data Rate (Transmit) 705 Current Data Rate (Receive) 706 Current Data Rate (Transmit) 707 Latency 708 Relative Link Quality (Receive) 709 Relative Link Quality (Transmit) 711 Destination Down MAC Address 713 All other DLEP signals and data items are OPTIONAL. Implementations 714 MAY choose to provide them. Implementations that do not support 715 optional signals MUST report an error condition and terminate the 716 router/modem session upon receipt of any such signal received. 717 OPTIONAL data items received that are not supported MUST be silently 718 dropped. 720 9. Generic DLEP Signal Definition 722 The Generic DLEP Signal consists of a sequence of TLVs. The first TLV 723 represents the signal being communicated (e.g., a "Destination Up", 724 or a "Peer Offer"). Subsequent TLVs contain the data items pertinent 725 to the signal (e.g., Maximum Data Rate, or Latency, etc). 727 The Generic DLEP Packet Definition contains the following fields: 729 0 1 2 3 730 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 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 |Signal TLV Type | Length | DLEP data items... | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 Signal - One of the DLEP Signal TLV type values 736 defined in this document. 738 Length - The length, expressed as a 16-bit 739 quantity, of all of the DLEP data items 740 associated with this signal. 742 DLEP data items - One or more data items, encoded in TLVs, 743 as defined in this document. 745 10. DLEP Data Items 747 As mentioned earlier, DLEP protocol signals are transported as a 748 collection of TLVs. The first TLV present in a DLEP signal MUST be 749 one of the Signal TLVs, documented in section 10. The signals are 750 followed by one or more data items, indicating the specific changes 751 that need to be instantiated in the receiver's information base. 753 Valid DLEP Data Items are: 755 TLV TLV 756 Value Description 757 ========================================= 758 TBD DLEP Port 759 TBD Peer Type 760 TBD IPv4 Address 761 TBD IPv6 Address 762 TBD Maximum Data Rate (Receive) (MDRR) 763 TBD Maximum Data Rate (Transmit) (MDRT) 764 TBD Current Data Rate (Receive) (CDRR) 765 TBD Current Data Rate (Transmit) (CDRT) 766 TBD Latency 767 TBD Receive Resources 768 TBD Transmit Resources 769 TBD Relative Link Quality (Receive) (RLQR) 770 TBD Relative Link Quality (Transmit) (RLQT) 771 TBD Status 772 TBD Heartbeat Interval/Threshold 773 TBD Neighbor down ACK timer 774 TBD Link Characteristics ACK timer 775 TBD Credit Window Status 776 TBD Credit Grant 777 TBD Credit Request 778 TBD DLEP Optional Signals Supported 779 TBD DLEP Optional Data Items Supported 780 TBD DLEP Vendor Extension 782 DLEP data item TLVs contain the following fields: 784 0 1 2 3 785 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 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | TLV Type | Length | Value... | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 TLV Type - An 8-bit unsigned integer field specifying the data 791 item being sent. 793 Length - An 8-bit length of the value field of the data item 795 Value - A field of length which contains data 796 specific to a particular data item. 798 10.1 DLEP Version 800 The DLEP Version TLV is a mandatory TLV in the Peer Discovery, 801 Peer Initialization, and Peer Initialization ACK signals. The Version 802 TLV is used to indicate the version of the protocol running in the 803 originator. A DLEP implementation MAY use this information to decide 804 if the potential session partner is running at a supported level. 806 The DLEP Version TLV contains the following fields: 808 0 1 2 3 809 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 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 |TLV Type =TBD |Length=4 | Major Version | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | Minor Version | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 TLV Type - TBD 818 Length - Length is 4 820 Major Version - Major version of the modem or router protocol. 822 Minor Version - Minor version of the modem or router protocol. 824 Support of this draft is indicated by setting the Major Version to 825 '0', and the Minor Version to '7' (e.g. Version 0.7). 827 10.2 DLEP Port 829 The DLEP Port TLV is a mandatory TLV in the Peer Offer signal. The 830 DLEP Port TLV is used to indicate the TCP Port number on the DLEP 831 server available for connections. The receiver MUST use this 832 information to perform the TCP connect to the DLEP server. 834 The DLEP Port TLV contains the following fields: 836 0 1 2 3 837 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 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 |TLV Type =TBD |Length=2 | TCP Port Number | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 TLV Type - TBD 844 Length - Length is 2 846 TCP Port Number - TCP Port number on the DLEP server. 848 10.3 Peer Type 850 The Peer Type TLV is an OPTIONAL TLV in both the Peer Discovery and 851 Peer Offer signals. The Peer Type TLV is used by the router and modem 852 to give additional information as to its type. The peer type is a 853 string and is envisioned to be used for informational purposes (e.g. 854 as output in a display command). 856 The Peer Type TLV contains the following fields: 858 0 1 2 3 859 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 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 |TLV Type =TBD |Length= peer |Peer Type String | 862 | |type string len| | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 TLV Type - TBD 867 Length - Length of peer type string. 869 Peer Type String - Non-Null terminated string, using UTF-8 encoding. 870 For example, a satellite modem might set this 871 variable to 'Satellite terminal'. 873 10.4 MAC Address 875 The MAC address TLV MUST appear in all destination-oriented signals 876 (e.g. Destination Up, Destination Up ACK, Destination Down, 877 Destination Down ACK, Destination Update, Link Characteristics 878 Request, and Link Characteristics ACK). The MAC Address TLV contains 879 the address of the destination on the remote node. The MAC address 880 MAY be either a physical or a virtual destination. Examples of a 881 virtual destination would be a multicast MAC address, or the 882 broadcast MAC (0xFFFFFFFFFFFF). 884 0 1 2 3 885 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 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 |TLV Type =TBD |Length = 6 | MAC Address | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 | MAC Address | 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 TLV Type - TBD 894 Length - 6 896 MAC Address - MAC Address of the destination (either physical or 897 virtual). 899 10.5 IPv4 Address 901 The IPv4 Address TLV is an optional TLV. If supported, it MAY appear 902 in Destination Up, Destination Update, Peer Initialization, and Peer 903 Update signals. When included in Destination signals, the IPv4 904 Address TLV contains the IPv4 address of the destination, as well as 905 a subnet mask value. In the Peer Update signal, it contains the IPv4 906 address of the originator of the signal. In either case, the TLV also 907 contains an indication of whether this is a new or existing address, 908 or is a deletion of a previously known address. 910 The IPv4 Address TLV contains the following fields: 912 0 1 2 3 913 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 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 |TLV Type =TBD |Length = 5 | Add/Drop | IPv4 Address | 916 | | | Indicator | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | IPv4 Address | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 TLV Type - TBD 923 Length - 6 925 Add/Drop - Value indicating whether this is a new or existing 926 address (0x01), or a withdrawal of an address (0x02). 928 IPv4 Address - The IPv4 address of the destination or peer. 930 Subnet Mask - A subnet mask (0-32) to be applied to the IPv4 931 address. 933 10.6 IPv6 Address 935 The IPv6 Address TLV is an optional TLV. If supported, it MAY be used 936 in the Destination Up, Destination Update, Peer Initialization, and 937 Peer Update Signals. When included in Destination signals, this data 938 item contains the IPv6 address of the destination. In the Peer 939 Discovery and Peer Update, it contains the IPv6 address of the 940 originating peer. In either case, the data item also contains an 941 indication of whether this is a new or existing address, or is a 942 deletion of a previously known address, as well as a subnet mask. 944 The IPv6 Address TLV contains the following fields: 946 0 1 2 3 947 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 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 |TLV Type =TBD |Length = 17 | Add/Drop | IPv6 Address | 950 | | | Indicator | | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | IPv6 Address | 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 | IPv6 Address | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 | IPv6 Address | 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 | IPv6 Address | 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 TLV Type - TBD 963 Length - 17 965 Add/Drop - Value indicating whether this is a new or existing 966 address (0x01), or a withdrawal of an address (0x02). 968 IPv6 Address - IPv6 Address of the destination or peer. 970 10.7 Maximum Data Rate (Receive) 972 The Maximum Data Rate Receive (MDRR) TLV is a mandatory data item, 973 used in Destination Up, Destination Update, Peer Initialization, Peer 974 Update, and Link Characteristics ACK Signals to indicate the maximum 975 theoretical data rate, in bits per second, that can be achieved while 976 receiving data on the link. When metrics are reported via the signals 977 listed above, the maximum data rate receive MUST be reported. 979 0 1 2 3 980 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 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 |TLV Type =TBD |Length = 8 | MDRR (bps) | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | MDRR (bps) | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | MDRR (bps) | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 TLV Type - TBD 990 Length - 8 992 Maximum Data Rate Receive - A 64-bit unsigned number, representing 993 the maximum theoretical data rate, in bits per 994 second (bps), that can be achieved while 995 receiving on the link. 997 10.8 Maximum Data Rate (Transmit) 999 The Maximum Data Rate Transmit (MDRT) TLV is a mandatory data item, 1000 used in Destination Up, Destination Update, Peer Initialization, Peer 1001 Update, and Link Characteristics ACK Signals to indicate the maximum 1002 theoretical data rate, in bits per second, that can be achieved while 1003 transmitting data on the link. When metrics are reported via the 1004 signals listed above, the maximum data rate transmit MUST be 1005 reported. 1007 0 1 2 3 1008 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 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 |TLV Type =TBD |Length = 8 | MDRT (bps) | 1011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 | MDRT (bps) | 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 | MDRT (bps) | 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 TLV Type - TBD 1019 Length - 8 1021 Maximum Data Rate Transmit - A 64-bit unsigned number, representing 1022 the maximum theoretical data rate, in bits per 1023 second (bps), that can be achieved while 1024 transmitting on the link. 1026 10.9 Current Data Rate (Receive) 1028 The Current Data Rate Receive (CDRR) TLV is a mandatory data item, 1029 used in Destination Up, Destination Update, Peer Initialization, Peer 1030 Update, Link Characteristics Request, and Link Characteristics ACK 1031 signals to indicate the rate at which the link is currently operating 1032 for receiving traffic. In the case of the Link Characteristics 1033 Request, CDRR represents the desired receive data rate for the link. 1034 When metrics are reported via the signals above (e.g. Destination 1035 Update), the current data rate receive MUST be reported. 1037 The Current Data Rate Receive TLV contains the following fields: 1039 0 1 2 3 1040 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 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 |TLV Type =TBD |TLV Flags=0x10 |Length = 8 |CDRR (bps) | 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 | CDRR (bps) | 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 | CDRR (bps) | 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 TLV Type - TBD 1051 Length - 8 1053 Current Data Rate Receive - A 64-bit unsigned number, representing 1054 the current data rate, in bits per second, that 1055 is currently be achieved while receiving traffic 1056 on the link. When used in the Link 1057 Characteristics Request, CDRR represents the 1058 desired receive rate, in bits per second, on the 1059 link. If there is no distinction between current 1060 and maximum receive data rates, current data 1061 rate receive SHOULD be set equal to the maximum 1062 data rate receive. 1064 10.10 Current Data Rate (Transmit) 1066 The Current Data Rate Receive (CDRT) TLV is a mandatory data item, 1067 used in Destination Up, Destination Update, Peer Initialization, Peer 1068 Update, Link Characteristics Request, and Link Characteristics ACK 1069 signals to indicate the rate at which the link is currently operating 1070 for transmitting traffic. In the case of the Link Characteristics 1071 Request, CDRT represents the desired transmit data rate for the link. 1072 When metrics are reported via the signals above (e.g. Destination 1073 Update), the current data rate transmit MUST be reported. 1075 The Current Data Rate Transmit TLV contains the following fields: 1077 0 1 2 3 1078 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 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 |TLV Type =TBD |TLV Flags=0x10 |Length = 8 |CDRT (bps) | 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 | CDRT (bps) | 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 | CDRT (bps) | 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 TLV Type - TBD 1089 Length - 8 1091 Current Data Rate Transmit - A 64-bit unsigned number, representing 1092 the current data rate, in bits per second, that 1093 is currently be achieved while transmitting 1094 traffic on the link. When used in the Link 1095 Characteristics Request, CDRT represents the 1096 desired transmit rate, in bits per second, on 1097 the link. If there is no distinction between 1098 current and maximum transmit data rates, current 1099 data rate transmit MUST be set equal to the 1100 maximum data rate transmit. 1102 10.11 Latency 1104 The Latency TLV is a mandatory data item. It is used in Peer 1105 Initialization, Destination Up, Destination Update, Peer 1106 Initialization, Peer Update, Link Characteristics Request, and Link 1107 Characteristics ACK signals to indicate the amount of latency on the 1108 link, or in the case of the Link Characteristics Request, to indicate 1109 the maximum latency required on the link. 1111 0 1 2 3 1112 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 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 |TLV Type =TBD |Length = 4 | Latency in microseconds | 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 | Latency (Cont.) microsecs | 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 TLV Type - TBD 1121 Length - 4 1122 Latency - A 32-bit unsigned value, representing the transmission 1123 delay that a packet encounters as it is transmitted 1124 over the link. In Destination Up, Destination Update, 1125 and Link Characteristics ACK, this value is reported 1126 as delay, in microseconds. The calculation of latency 1127 is implementation dependent. For example, the latency 1128 may be a running average calculated from the internal 1129 queuing. If a device cannot calculate latency, this 1130 TLV SHOUD NOT be issued. In the Link Characteristics 1131 Request Signal, this value represents the maximum 1132 delay, in microseconds, expected on the link. 1134 10.12 Resources (Receive) 1136 The Receive Resources TLV is an optional data item. If supported, it 1137 is used in Destination Up, Destination Update, Peer Initialization, 1138 Peer Update, and Link Characteristics ACK signals to indicate a 1139 percentage (0-100) amount of resources (e.g. battery power), 1140 committed to receiving data, remaining on the originating peer. 1142 The Resources TLV contains the following fields: 1144 0 1 2 1145 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1147 |TLV Type =TBD |Length = 1 | Rcv Resources| 1148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 TLV Type - TBD 1152 Length - 1 1154 Receive Resources - A percentage, 0-100, representing the amount 1155 of remaining resources, such as battery power, 1156 allocated to receiving data. If a device cannot 1157 calculate receive resources, this TLV SHOULD NOT be 1158 issued. 1160 10.13 Resources (Transmit) 1162 The Transmit Resources TLV is an optional data item. If supported, it 1163 is used in Destination Up, Destination Update, Peer Initialization, 1164 Peer Update, and Link Characteristics ACK signals to indicate a 1165 percentage (0-100) amount of resources (e.g. battery power), 1166 committed to transmitting data, remaining on the originating peer. 1168 The Resources TLV contains the following fields: 1170 0 1 2 1171 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 |TLV Type =TBD |Length = 1 | Xmt Resources| 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1176 TLV Type - TBD 1178 Length - 1 1180 Transmit Resources - A percentage, 0-100, representing the amount 1181 of remaining resources, such as battery power, 1182 allocated to transmitting data. If the transmit 1183 resources cannot be calculated, then the TLV SHOULD 1184 NOT be issued. 1186 10.14 Relative Link Quality (Receive) 1188 The Relative Link Quality Receive (RLQR) TLV is an optional data 1189 item. If supported, it is used in Peer Initialization, Destination 1190 Up, Destination Update, Peer Initialization, Peer Update, and Link 1191 Characteristics ACK signals to indicate the quality of the link for 1192 receiving data as calculated by the originating peer. 1194 The Relative Link Quality (Receive) TLV contains the following 1195 fields: 1197 0 1 2 1198 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1200 |TLV Type =TBD |Length = 1 |RCV Rel. Link | 1201 | | |Quality (RLQR) | 1202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 TLV Type - TBD 1206 Length - 1 1208 Relative Link Quality (Receive) - A non-dimensional number, 1-100, 1209 representing relative link quality. A value of 1210 100 represents a link of the highest quality. 1211 If a device cannot calculate the RLQR, this 1212 TLV SHOULD NOT be issued. 1214 10.15 Relative Link Quality (Transmit) 1216 The Transmit Link Quality Receive (RLQT) TLV is an optional data 1217 item. It is used in Peer Initialization, Destination Up, Destination 1218 Update, Peer Initialization, Peer Update, and Link Characteristics 1219 ACK signals to indicate the quality of the link for transmitting data 1220 as calculated by the originating peer. 1222 The Relative Link Quality (Transmit) TLV contains the following 1223 fields: 1225 0 1 2 1226 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 |TLV Type =TBD |Length = 1 |XMT Rel. Link | 1229 | | |Quality (RLQR) | 1230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 TLV Type - TBD 1234 Length - 1 1236 Relative Link Quality (Transmit) - A non-dimensional number, 1-100, 1237 representing relative link quality. A value of 1238 100 represents a link of the highest quality. 1239 If a device cannot calculate the RLQT, this 1240 TLV SHOULD NOT be issued. 1242 10.16 Status 1244 The Status TLV is sent as part of an acknowledgement signal, from 1245 either the modem or the router, to indicate the success or failure of 1246 a given request. 1248 The Status TLV contains the following fields: 1250 0 1 2 1251 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1253 |TLV Type =TBD |Length = 1 | Code | 1254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 TLV Type - TBD 1258 Length - 1 1260 Termination Code - 0 = Success, Non-zero = Failure. Specific values 1261 of a non-zero termination code depend on the 1262 operation requested (e.g. Destination Up, 1263 Destination Down, etc). 1265 10.17 Heartbeat Interval 1267 The Heartbeat Interval TLV is a mandatory TLV. It MUST be sent during 1268 Peer Initialization to indicate the desired Heartbeat timeout window. 1269 The receiver MUST either accept the timeout interval supplied by the 1270 sender, or reject the Peer Initialization, and close the socket. 1271 Implementations MUST implement heuristics such that DLEP signals 1272 sent/received reset the timer interval. 1274 The Interval is used to specify a period (in seconds) for Heartbeat 1275 Signals (See Section 11.15). By specifying an Interval value of 0, 1276 implementations MAY indicates the desire to disable Heartbeat signals 1277 entirely (e.g., the Interval is set to an infinite value), however, 1278 it is strongly recommended that implementations use non 0 timer 1279 values. 1281 A DLEP session will be considered inactive, and MUST be torn down, by 1282 an implementation detecting that two (2) Heartbeat intervals have 1283 transpired without receipt of any DLEP signals. 1285 The Heartbeat Interval TLV contains the following fields: 1287 0 1 2 3 1288 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 1289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1290 |TLV Type =TBD |Length = 2 | Interval | 1291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 TLV Type - TBD 1295 Length - 2 1297 Interval - 0 = Do NOT use heartbeats on this peer-to-peer 1298 session. Non-zero = Interval, in seconds, for 1299 heartbeat signals. 1301 10.18 Link Characteristics ACK Timer 1303 The Link Characteristics ACK Timer TLV is an optional TLV. If 1304 supported, it MAY be sent during Peer Initialization to indicate the 1305 desired number of seconds to wait for a response to a Link 1306 Characteristics Request. If this TLV is omitted, implementations 1307 supporting the Link Characteristics Request SHOULD choose a default 1308 value. 1310 The Link Characteristics ACK Timer TLV contains the following fields: 1312 0 1 2 1313 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1315 |TLV Type =TBD |Length = 1 | Interval | 1316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 TLV Type - TBD 1320 Length - 1 1322 Interval - 0 = Do NOT use timeouts for Link Characteristics 1323 requests on this router/modem session. Non-zero = 1324 Interval, in seconds, to wait before considering a 1325 Link Characteristics Request has been lost. 1327 10.19 Credit Window Status 1329 The Credit Window Status TLV is an optional TLV. If credits are 1330 supported by the DLEP participants (both the router and the modem), 1331 the Credit Window Status TLV MUST be sent by the participant 1332 receiving a Credit Grant Request for a given destination. 1334 The Credit Window Status TLV contains the following fields: 1336 0 1 2 3 1337 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 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 |TLV Type =TBD |Length = 16 | Modem Receive Window Value | 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 | Modem Receive Window Value | 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 | Modem Receive Window Value | Router Receive Window Value | 1344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1345 | Router Receive Window Value | 1346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1347 | Router Receive Window Value | 1348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1350 TLV Type - TBD 1352 Length - 16 1354 Modem Receive Window Value - A 64-bit unsigned number, indicating 1355 the current (or initial) number of 1356 credits available on the Modem Receive 1357 Window. 1359 Router Receive Window Value - A 64-bit unsigned number, indicating 1360 the current (or initial) number of 1361 credits available on the Router Receive 1362 Window. 1364 10.20 Credit Grant Request 1366 The Credit Grant Request TLV is an optional TLV. If credits are 1367 supported, the Credit Grant Request TLV is sent from a DLEP 1368 participant to grant an increment to credits on a window. The Credit 1369 Grant TLV is sent as a data item in either the Destination Up or 1370 Destination Update signals. The value in a Credit Grant TLV 1371 represents an increment to be added to any existing credits available 1372 on the window. Upon successful receipt and processing of a Credit 1373 Grant TLV, the receiver MUST respond with a signal containing a 1374 Credit Window Status TLV to report the updated aggregate values for 1375 synchronization purposes. 1377 In the Destination Up signal, when credits are desired, the 1378 originating peer MUST set the initial credit value of the window it 1379 controls (e.g. the Modem Receive Window, or Router Receive Window) to 1380 an initial, non-zero value. If the receiver of a Destination Up 1381 signal with a Credit Grant Request TLV supports credits, the receiver 1382 MUST either reject the use of credits, via a Destination Up ACK 1383 response with the correct Status TLV, or set the initial value from 1384 the data contained in the Credit Window Status TLV. If the 1385 initialization completes successfully, the receiver MUST respond to 1386 the Destination Up signal with a Destination Up ACK signal that 1387 contains a Credit Window Status TLV, initializing its receive window. 1389 The Credit Grant TLV contains the following fields: 1391 0 1 2 3 1392 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 1393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 |TLV Type =TBD |Length = 8 | Credit Increment | 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1396 | Credit Increment | 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 | Credit Increment | 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1401 TLV Type - TBD 1402 Length - 8 1404 Reserved - A 64-bit unsigned number representing the 1405 additional credits to be assigned to the credit 1406 window. Since credits can only be granted by the 1407 receiver on a window, the applicable credit window 1408 (either the MRW or the RRW) is derived from the 1409 sender of the grant. The Credit Increment MUST NOT 1410 cause the window to overflow; if this condition 1411 occurs, implementations MUST set the credit window 1412 to the maximum value contained in a 64-bit 1413 quantity. 1415 10.21 Credit Request 1417 The Credit Request TLV is an optional TLV. If credits are supported, 1418 the Credit Request TLV MAY be sent from either DLEP participant, via 1419 a Destination Update signal, to indicate the desire for the partner 1420 to grant additional credits in order for data transfer to proceed on 1421 the session. If the corresponding Destination Up signal for this 1422 session did NOT contain a Credit Window Status TLV, indicating that 1423 credits are to be used on the session, then the Credit Request TLV 1424 MUST be rejected by the receiver via a Destination Update ACK signal. 1426 The Credit Request TLV contains the following fields: 1428 0 1 2 1429 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1431 |TLV Type =TBD |Length = 1 | Reserved, MUST| 1432 | | | be set to 0 | 1433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1435 TLV Type - TBD 1437 Length - 1 1439 Reserved - This field is currently unused and MUST be set to 0. 1441 10.22 DLEP Optional Signals Supported 1443 The DLEP Optional Signals Supported TLV is a mandatory data item. If 1444 optional signals (e.g., the Link Characteristics Request Signal) are 1445 supported, they MUST be enumerated with this data item inserted into 1446 the Peer Initialization and Peer Initialization ACK signals. Failure 1447 to indicate optional signals indicates to a receiving peer that the 1448 sending implementation ONLY supports the core (mandatory) items 1449 listed in this specification. Optional signals that are NOT 1450 enumerated in this data item when issuing Peer Initialization or Peer 1451 Initialization ACK MUST NOT be used during the DLEP session. 1453 The DLEP Optional Signals Supported TLV contains the following 1454 fields: 1456 0 1 2 3 1457 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 1458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 |TLV Type =TBD |Length = 2 + |List of optional signals ... | 1460 | |number of opt. | | 1461 | |signals. | | 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1464 TLV Type - TBD 1466 Length - 2 + the number of optional signals supported 1467 List - An enumeration of the optional signal TLV Types 1468 supported by the implementation. 1470 10.23 DLEP Optional Data Items Supported 1472 The DLEP Optional Data Items Supported TLV is a mandatory data item. 1473 If optional data items (e.g., Resources) are supported, they MUST be 1474 enumerated with this data item inserted into the Peer Initialization 1475 and Peer Initialization ACK signals. Failure to indicate optional 1476 data items indicates to a receiving peer that the sending 1477 implementation ONLY supports the core (mandatory) data items listed 1478 in this specification. Optional data items that are NOT listed in 1479 this data item MUST NOT be used during the DLEP session. 1481 The DLEP Optional Data Items Supported TLV contains the following 1482 fields: 1484 0 1 2 3 1485 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 1486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1487 |TLV Type =TBD |Length = 2 + |List of optional data items ...| 1488 | |number of opt. | | 1489 | |signals. | | 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1492 TLV Type - TBD 1494 Length - 2 + the number of optional data items supported 1495 List - An enumeration of the optional data item TLV Types 1496 supported by the implementation. 1498 10.24 DLEP Vendor Extension 1500 The DLEP Vendor Extension data item is an optional data item, and 1501 allows for vendor-defined information to be passed between DLEP 1502 participants. The precise data carried in the payload portion of the 1503 data item is vendor-specific, however, the payload MUST adhere to a 1504 Type-Length-Value format. This optional data item is ONLY valid on 1505 Peer Initialization ACK, and if present, SHOULD contain device- 1506 specific information geared to optimizing data transmission/reception 1507 over the modem's link. 1509 The DLEP Vendor Extension Data Item TLV contains the following 1510 fields: 1512 0 1 2 3 1513 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 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 |TLV Type = TBD | Length |OUI Length | Vendor OUI... | 1516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 | OUI TLV Subtype | Payload... | 1518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1520 TLV Type - TBD 1522 Length - 3 + length of OUI (in octets) + payload length 1524 Vendor OUI - The vendor OUI, as specified in [IEEE] 1526 OUI TLV Subtype - A 16-bit quantity, intended to indicate the 1527 specific device. 1529 Payload - Vendor-specific payload, formatted as Type, Length, 1530 Value construct(s). 1532 10.25 IPv4 Attached Subnet 1534 The DLEP IPv4 Attached Subnet is an optional data item, and allows a 1535 device to declare that it has an IPv4 subnet (e.g., a stub network) 1536 attached. If supported, the DLEP IPv4 Attached Subnet TLV is allowed 1537 ONLY in the DLEP "Destination Up" signal, and MUST NOT appear more 1538 than once. All other occurrences of the DLEP IPv4 Attached Subnet TLV 1539 MUST be treated as an error. Once an IPv4 Subnet has been declared by 1540 a device, the declaration can NOT be withdrawn without terminating 1541 the destination (via the "Destination Down" signal) and re-issuing 1542 the "Destination Up" signal. 1544 The DLEP IPv4 Attached Subnet data item TLV contains the following 1545 fields: 1547 0 1 2 3 1548 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 1549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1550 |TLV Type =TBD | Length = 5 | IPv4 Attached Subnet | 1551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1552 | IPv4 Attached Subnet | Subnet Mask | 1553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1555 TLV Type - TBD 1557 Length - 5 1559 IPv4 Subnet - The IPv4 subnet reachable at the destination. 1561 Subnet Mask - A subnet mask (0-32) to be applied to the IPv4 1562 subnet. 1564 10.26 IPv6 Attached Subnet 1566 The DLEP IPv6 Attached Subnet is an optional data item, and allows a 1567 device to declare that it has an IPv6 subnet (e.g., a stub network) 1568 attached. If supported, the DLEP IPv6 Attached Subnet TLV is allowed 1569 ONLY in the DLEP "Destination Up" signal, and MUST NOT appear more 1570 than once. All other occurrences of the DLEP IPv6 Attached Subnet TLV 1571 MUST be treated as an error. As in the case of the IPv4 attached 1572 subnet, once an IPv6 attached subnet has been declared, it can NOT be 1573 withdrawn without terminating the destination (via "Destination 1574 Down") and re-issuing the "Destination Up" signal. 1576 The DLEP IPv6 Attached Subnet data item TLV contains the following 1577 fields: 1579 0 1 2 3 1580 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 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 |TLV Type =TBD |Length = 17 | IPv6 Attached Subnet | 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1584 | IPv6 Attached Subnet | 1585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1586 | IPv6 Attached Subnet | 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1588 | IPv6 Attached Subnet | 1589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1590 | IPv6 Attached Subnet | Subnet Mask | 1591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 TLV Type - TBD 1594 Length - 17 1596 IPv4 Subnet - The IPv6 subnet reachable at the destination. 1598 Subnet Mask - A subnet mask (0-128) to be applied to the IPv6 1599 subnet. 1601 11. DLEP Protocol Signals 1603 DLEP signals are encoded as a string of Type-Length-Value (TLV) 1604 constructs. The first TLV in a DLEP signal MUST be a valid DLEP 1605 signal, as defined in section 11.1 of this document. Following the 1606 signal TLV is 0 or more TLVs, representing the data items that are 1607 appropriate for the signal. The layout of a DLEP signal is thus: 1609 0 1 2 3 1610 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 1611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1612 | DLEP Signal |DLEP Signal length (length of |Start of DLEP | 1613 | Type value |all data items) |data item TLVs | 1614 | (value TBD) | | | 1615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1617 All DLEP signals begin with this structure. Therefore, in the 1618 following descriptions of specific signals, this header structure is 1619 assumed, and will not be replicated. 1621 11.1 Signal TLV Values 1623 As mentioned above, all DLEP signals begin with the Type value. Valid 1624 DLEP signals are: 1626 TLV TLV 1627 Value Description 1628 ========================================= 1629 TBD Peer Discovery 1630 TBD Peer Offer 1631 TBD Peer Initialization 1632 TBD Peer Update 1633 TBD Peer Update ACK 1634 TBD Peer Termination 1635 TBD Peer Termination ACK 1636 TBD Destination Up 1637 TBD Destination Up ACK 1638 TBD Destination Down 1639 TBD Destination Down ACK 1640 TBD Destination Update 1641 TBD Heartbeat 1642 TBD Link Characteristics Request 1643 TBD Link Characteristics ACK 1645 11.2 Peer Discovery Signal 1647 The Peer Discovery Signal is sent by a router to discover DLEP 1648 routers in the network. The Peer Offer signal is required to complete 1649 the discovery process. Implementations MAY implement their own retry 1650 heuristics in cases where it is determined the Peer Discovery Signal 1651 has timed out. 1653 To construct a Peer Discovery signal, the initial TLV Type value is 1654 set to DLEP_PEER_DISCOVERY (value TBD). The signal TLV MUST be 1655 followed by the mandatory Data Item TLVs. 1657 Mandatory Data Item TLVs: 1658 - DLEP Version 1659 - Heartbeat Interval 1660 There are NO optional data items for the Peer Discovery signal. 1662 11.3 Peer Offer Signal 1664 The Peer Offer Signal is sent by a DLEP modem in response to a Peer 1665 Discovery Signal. Upon receipt, and processing, of a Peer Offer 1666 signal, the router responds by issuing a TCP connect to the 1667 address/port combination specified in the received Peer Offer. 1669 The Peer Offer signal MUST be sent to the unicast address of the 1670 originator of Peer Discovery. 1672 To construct a Peer Offer signal, the initial TLV type value is set 1673 to DLEP_PEER_OFFER (value TBD). The signal TLV is then followed by 1674 all mandatory Data Item TLVs, then by any optional Data Item TLVs the 1675 implementation supports: 1677 Mandatory Data Item TLVs: 1678 - DLEP Version 1679 - Heartbeat Interval 1680 - At least one (1) IPv4 or IPv6 Address TLV 1681 - DLEP Port 1683 Optional Data Item TLVs: 1684 - Peer Type 1685 - Status 1687 11.4 Peer Initialization Signal 1689 The Peer Initialization signal is sent by a router to start the DLEP 1690 TCP session. It is sent by the router after a TCP connect to an 1691 address/port combination that was obtained either via receipt of a 1692 Peer Offer, or from a-priori configuration. If any optional signals 1693 or data items are supported by the implementation, they MUST be 1694 enumerated in the DLEP Optional Signals Supported and DLEP Optional 1695 Data Items Supported items. 1697 Mandatory Data Item TLVs: 1698 - DLEP Version 1699 - Heartbeat Interval 1700 - Optional Signals Supported 1701 - Optional Data Items Supported 1702 Optional Data Item TLVs: 1703 - Peer Type 1704 If the Optional Signals Supported (or the Optional Data Items 1705 Supported) TLV is absent in Peer Initialization, the receiver of the 1706 signal MUST conclude that there is NO optional support in the 1707 sender. 1709 11.5 Peer Initialization ACK Signal 1711 The Peer Initialization ACK signal is a mandatory signal, sent in 1712 response to a received Peer Initialization signal. The Peer 1713 Initialization ACK signal completes the TCP-level DLEP session 1714 establishment; the sender of the signal should transition to an "in- 1715 session" state when the signal is sent, and the receiver should 1716 transition to the "in-session" state upon receipt (and successful 1717 parsing) of Peer Initialization ACK. 1719 All supported metric data items MUST be included in the Peer 1720 Initialization ACK signal, with default values to be used on a 1721 "modem-wide" basis. This can be viewed as the modem "declaring" all 1722 supported metrics at DLEP session initialization. Receipt of any DLEP 1723 signal containing a metric data item NOT included in Peer 1724 Initialization ACK MUST be treated as an error, resulting in 1725 termination of the DLEP session between router and modem. If optional 1726 signals and/or data items are supported by the modem, they MUST be 1727 enumerated in the DLEP Optional Signals supported and DLEP Optional 1728 data items supported TLVs. 1730 The Peer Initialization ACK signal MAY contain the DLEP Vendor 1731 Extension data item, as documented in section 10.22 1733 After the Peer Initialization/Peer Initialization ACK signals have 1734 been successfully exchanged, implementations SHOULD only utilize 1735 options that are supported in BOTH peers (e.g. router and modem). Any 1736 attempt by a DLEP session peer to send an optional signal to a peer 1737 without support MUST result in an error which terminates the session. 1738 Any optional data item sent to a peer without support will be ignored 1739 and silently dropped. 1741 To construct a Peer Initialization ACK signal, the initial TLV type 1742 value is set to DLEP_PEER_INIT_ACK (value TBD). The signal TLV is 1743 then followed by the required data items: 1745 Mandatory Data Item TLVs: 1746 - DLEP Version 1747 - Heartbeat Interval 1748 - Maximum Data Rate Receive 1749 - Maximum Data Rate Transmit 1750 - Current Data Rate Receive 1751 - Current Data Rate Transmit 1752 - DLEP Optional Signals Supported 1753 - DLEP Optional Data Items Supported 1754 - Status 1755 Optional Data Item TLVs: 1756 - Peer Type 1757 - DLEP Vendor Extension 1758 - Latency 1759 - Relative Link Quality Receive 1760 - Relative Link Quality Transmit 1761 - Resources (Receive) 1762 - Resources (Transmit) 1764 11.6 Peer Update Signal 1766 The Peer Update signal is an optional signal, sent by a DLEP peer to 1767 indicate local Layer 3 address changes, or for metric changes on a 1768 modem-wide basis. For example, addition of an IPv4 address to the 1769 router MAY prompt a Peer Update signal to its attached DLEP modems. 1770 Also, a modem that changes its Maximum Data Rate for all destinations 1771 MAY reflect that change via a Peer Update Signal to its attached 1772 router(s). 1774 Concerning Layer 3 addresses, if the modem is capable of 1775 understanding and forwarding this information (via proprietary 1776 mechanisms), the address update would prompt any remote DLEP modems 1777 (DLEP-enabled modems in a remote node) to issue a "Destination 1778 Update" signal to their local routers with the new (or deleted) 1779 addresses. Modems that do not track Layer 3 addresses SHOULD silently 1780 parse and ignore the Peer Update Signal. Modems that track Layer 3 1781 addresses MUST acknowledge the Peer Update with a Peer Update ACK 1782 signal. Routers receiving a Peer Update with metric changes MUST 1783 apply the new metric to all destinations (remote nodes) accessible 1784 via the modem. Supporting implementations are free to employ 1785 heuristics to retransmit Peer Update signals. The sending of Peer 1786 Update Signals for Layer 3 address changes SHOULD cease when a either 1787 participant (router or modem) determines that the other 1788 implementation does NOT support Layer 3 address tracking. 1790 If metrics are supplied with the Peer Update signal (e.g. Maximum 1791 Data Rate), these metrics are considered to be modem-wide, and 1792 therefore MUST be applied to all destinations in the information base 1793 associated with the router/modem session. 1795 To construct a Peer Update signal, the initial TLV type value is set 1796 to DLEP_PEER_UPDATE (value TBD). The Signal TLV is followed by any 1797 OPTIONAL Data Item TLVs. 1799 Optional Data Item TLVs: 1800 - IPv4 Address 1801 - IPv6 Address 1802 - Maximum Data Rate (Receive) 1803 - Maximum Data Rate (Transmit) 1804 - Current Data Rate (Receive) 1805 - Current Data Rate (Transmit) 1806 - Latency 1807 - Resources (Receive) 1808 - Resources (Transmit) 1809 - Relative Link Quality (Receive) 1810 - Relative Link Quality (Transmit) 1812 11.7 Peer Update ACK Signal 1814 The Peer Update ACK signal is an optional signal, and is sent by 1815 implementations supporting Layer 3 address tracking and/or modem-wide 1816 metrics to indicate whether a Peer Update Signal was successfully 1817 processed. If the Peer Update ACK is issued, it MUST contain a Status 1818 data item, indicating the success or failure of processing the 1819 received Peer Update. 1821 To construct a Peer Update ACK signal, the initial TLV type value is 1822 set to DLEP_PEER_UPDATE_ACK (value TBD). The Status data item TLV is 1823 placed in the packet next, completing the Peer Update ACK. 1825 Mandatory Data Item TLVs: 1827 - Status 1829 Note that there are NO optional data item TLVs specified for this 1830 signal. 1832 11.8 Peer Termination Signal 1834 The Peer Termination Signal is sent by a DLEP participant when the 1835 router/modem session needs to be terminated. Implementations 1836 receiving a Peer Termination signal MUST send a Peer Termination ACK 1837 signal to confirm the termination process. The sender of a Peer 1838 Termination signal is free to define its heuristics in event of a 1839 timeout. The receiver of a Peer Termination Signal MUST release all 1840 resources allocated for the router/modem session, and MUST eliminate 1841 all destinations in the information base accessible via the 1842 router/modem pair represented by the session. Router and modem state 1843 machines are returned to the "discovery" state. No Destination Down 1844 signals are sent. 1846 To construct a Peer Termination signal, the initial TLV type value is 1847 set to DLEP_PEER_TERMINATION (value TBD). The signal TLV is followed 1848 by any OPTIONAL Data Item TLVs the implementation supports: 1850 Optional Data Item TLVs: 1852 - Status 1854 11.9 Peer Termination ACK Signal 1856 The Peer Termination Signal ACK is sent by a DLEP peer in response to 1857 a received Peer Termination order. Receipt of a Peer Termination ACK 1858 signal completes the teardown of the router/modem session. 1860 To construct a Peer Termination ACK signal, the initial TLV type 1861 value is set to DLEP_PEER_TERMINATION_ACK (value TBD). The 1862 Identification data item TLV is placed in the packet next, followed 1863 by any OPTIONAL TLVs the implementation supports: 1865 Optional Data Item TLVs: 1867 - Status 1869 11.10 Destination Up Signal 1871 A DLEP participant sends the Destination Up signal to report that a 1872 new destination has been detected. A Destination Up ACK Signal is 1873 required to confirm a received Destination Up. A Destination Up 1874 signal can be sent either by the modem, to indicate that a new remote 1875 node has been detected, or by the router, to indicate the presence of 1876 a new logical destination (e.g., a Multicast group) exists in the 1877 network. 1879 The sender of the Destination Up Signal is free to define its retry 1880 heuristics in event of a timeout. When a Destination Up signal is 1881 received and successfully parsed, the receiver should add knowledge 1882 of the new destination to its information base, indicating that the 1883 destination is accessible via the modem/router pair. 1885 To construct a Destination Up signal, the initial TLV type value is 1886 set to DLEP_DESTINATION_UP (value TBD). The MAC Address data item TLV 1887 is placed in the packet next, followed by any supported optional Data 1888 Item TLVs into the packet: 1890 Optional Data Item TLVs: 1892 - IPv4 Address 1893 - IPv6 Address 1894 - Maximum Data Rate (Receive) 1895 - Maximum Data Rate (Transmit) 1896 - Current Data Rate (Receive) 1897 - Current Data Rate (Transmit) 1898 - Latency 1899 - Resources (Receive) 1900 - Resources (Transmit) 1901 - Relative Link Factor (Receive) 1902 - Relative Link Factor (Transmit) 1903 - Credit Window Status 1904 - IPv4 Attached Subnet 1905 - IPv6 Attached Subnet 1907 11.11 Destination Up ACK Signal 1909 A DLEP participant sends the Destination Up ACK Signal to indicate 1910 whether a Destination Up Signal was successfully processed. 1912 To construct a Destination Up ACK signal, the initial TLV type value 1913 is set to DLEP_DESTINATION_UP_ACK (value TBD). The MAC Address data 1914 item TLV is placed in the packet next, containing the MAC address of 1915 the DLEP destination. The implementation would then place any 1916 supported optional Data Item TLVs into the packet: 1918 Optional Data Item TLVs: 1919 - Credit Window Status 1921 11.12 Destination Down Signal 1923 A DLEP peer sends the Destination Down signal to report when a 1924 destination (a remote node or a multicast group) is no longer 1925 reachable. The Destination Down signal MUST contain the MAC Address 1926 data item TLV. Other TLVs as listed are OPTIONAL, and MAY be present 1927 if an implementation supports them. A Destination Down ACK Signal 1928 MUST be sent by the recipient of a Destination Down signal to confirm 1929 that the relevant data has been removed from the information base. 1930 The sender of the Destination Down signal is free to define its retry 1931 heuristics in event of a timeout. 1933 To construct a Destination Down signal, the initial TLV type value is 1934 set to DLEP_DESTINATION_DOWN (value TBD). The signal TLV is followed 1935 by the mandatory MAC Address data item TLV. 1937 Note that there are NO OPTIONAL data item TLVs for this signal. 1939 11.13 Destination Down ACK Signal 1941 A DLEP participant sends the Destination Down ACK Signal to indicate 1942 whether a received Destination Down Signal was successfully 1943 processed. If successfully processed, the sender of the ACK MUST have 1944 removed all entries in the information base that pertain to the 1945 referenced destination. As with the Destination Down signal, there 1946 are NO OPTIONAL Data Item TLVs defined for the Destination Down ACK 1947 signal. 1949 To construct a Destination Down signal, the initial TLV type value is 1950 set to DLEP_DESTINATION_DOWN_ACK (value TBD). The mandatory data item 1951 TLVs follow: 1953 - MAC Address Data item 1954 - Status data item 1956 11.14 Destination Update Signal 1958 A DLEP participant sends the Destination Update signal when it 1959 detects some change in the information base for a given destination 1960 (remote node or multicast group). Some examples of changes that would 1961 prompt a Destination Update signal are: 1963 - Change in link metrics (e.g., Data Rates) 1964 - Layer 3 addressing change (for implementations that support it) 1966 To construct a Destination Update signal, the initial TLV type value 1967 is set to DLEP_DESTINATION_UPDATE (value TBD). Following the signal 1968 TLV are the mandatory Data Item TLVs: 1970 MAC Address data item TLV 1972 After placing the mandatory data item TLV into the packet, the 1973 implementation would place any supported OPTIONAL data item TLVs. 1974 Possible OPTIONAL data item TLVs are: 1976 - IPv4 Address 1977 - IPv6 Address 1978 - Maximum Data Rate (Receive) 1979 - Maximum Data Rate (Transmit) 1980 - Current Data Rate (Receive) 1981 - Current Data Rate (Transmit) 1982 - Latency 1983 - Resources (Receive) 1984 - Resources (Transmit) 1985 - Relative Link Quality (Receive) 1986 - Relative Link Quality (Transmit) 1987 - Credit Window Status 1988 - Credit Grant 1989 - Credit Request 1991 11.15 Heartbeat Signal 1993 A Heartbeat Signal is sent by a DLEP participant every N seconds, 1994 where N is defined in the "Heartbeat Interval" field of the Peer 1995 Initialization signal. Note that implementations setting the 1996 Heartbeat Interval to 0 effectively set the interval to an infinite 1997 value, therefore, in those cases, this signal would NOT be sent. 1999 The signal is used by participants to detect when a DLEP session 2000 partner (either the modem or the router) is no longer communicating. 2001 Participants SHOULD allow two (2) heartbeat intervals to expire with 2002 no traffic on the router/modem session before initiating DLEP session 2003 termination procedures. 2005 To construct a Heartbeat signal, the initial TLV type value is set to 2006 DLEP_PEER_HEARTBEAT (value TBD). The signal TLV is followed by the 2007 mandatory Heartbeat Interval/Threshold data item. 2009 Note that there are NO OPTIONAL data item TLVs for this signal. 2011 11.16 Link Characteristics Request Signal 2013 The Link Characteristics Request Signal is an optional signal, and is 2014 sent by the router to request that the modem initiate changes for 2015 specific characteristics of the link. The request can reference 2016 either a real (e.g., a remote node), or a logical (e.g., a multicast 2017 group) destination within the network. 2019 The Link Characteristics Request signal contains either a Current 2020 Data Rate (CDRR or CDRT) TLV to request a different datarate than 2021 what is currently allocated, a Latency TLV to request that traffic 2022 delay on the link not exceed the specified value, or both. A Link 2023 Characteristics ACK Signal is required to complete the request. 2024 Implementations are free to define their retry heuristics in event of 2025 a timeout. Issuing a Link Characteristics Request with ONLY the MAC 2026 Address TLV is a mechanism a peer MAY use to request metrics (via the 2027 Link Characteristics ACK) from its partner. 2029 To construct a Link Characteristics Request signal, the initial TLV 2030 type value is set to DLEP_Destination_LINK_CHAR_REQ (value TBD). 2031 Following the signal TLV is the mandatory Data Item TLV: 2033 MAC Address data item TLV 2035 After placing the mandatory data item TLV into the packet, the 2036 implementation would place any supported OPTIONAL data item TLVs. 2037 Possible optional data item TLVs are: 2039 Current Data Rate - If present, this value represents the NEW (or 2040 unchanged, if the request is denied) Current 2041 Data Rate in bits per second (bps). 2043 Latency - If present, this value represents the maximum 2044 desired latency (e.g., it is a not-to-exceed 2045 value) in microseconds on the link. 2047 11.17 Link Characteristics ACK Signal 2049 The LInk Characteristics ACK signal is an optional signal, and is 2050 sent by modems supporting it to the router letting the router know 2051 the success or failure of a requested change in link characteristics. 2052 The Link Characteristics ACK signal SHOULD contain a complete set of 2053 metric data item TLVs. It MUST contain the same TLV types as the 2054 request. The values in the metric data item TLVs in the Link 2055 Characteristics ACK signal MUST reflect the link characteristics 2056 after the request has been processed. 2058 To construct a Link Characteristics Request ACK signal, the initial 2059 TLV type value is set to DLEP_Destination_LINK_CHAR_ACK (value TBD). 2060 Following the signal TLV is the mandatory Data Item TLV: 2062 MAC Address data item TLV 2064 After placing the mandatory data item TLV into the packet, the 2065 implementation would place any supported OPTIONAL data item TLVs. 2066 Possible OPTIONAL data item TLVs are: 2068 Current Data Rate - If present, this value represents the requested 2069 data rate in bits per second (bps). 2071 Latency - If present, this value represents the NEW 2072 maximum latency (or unchanged, if the request 2073 is denied), expressed in microseconds, on the 2074 link. 2076 12. Security Considerations 2078 The protocol does not contain any mechanisms for security (e.g. 2079 authentication or encryption). The protocol assumes that any security 2080 would be implemented in the underlying transport (for example, by use 2081 of DTLS or some other mechanism), and is therefore outside the scope 2082 of this document. 2084 13. IANA Considerations 2086 This section specifies requests to IANA. 2088 13.1 Registrations 2090 This specification defines: 2092 o A new repository for DLEP signals, with fifteen values currently 2093 assigned. 2095 o Reservation of numbering space for Experimental DLEP signals. 2097 o A new repository for DLEP Data Items, with twenty-one values 2098 currently assigned. 2100 o Reservation of numbering space in the Data Items repository for 2101 experimental data items. 2103 o A request for allocation of a well-known port for DLEP 2104 communication. 2106 o A request for allocation of a multicast address for DLEP 2107 discovery. 2109 13.2 Expert Review: Evaluation Guidelines 2111 No additional guidelines for expert review are anticipated. 2113 13.3 Signal TLV Type Registration 2115 A new repository must be created with the values of the DLEP signals. 2117 Valid signals are: 2119 o Peer Discovery 2120 o Peer Offer 2121 o Peer Initialization 2122 o Peer Initialization ACK 2123 o Peer Update 2124 o Peer Update ACK 2125 o Peer Termination 2126 o Peer Termination ACK 2127 o Destination Up 2128 o Destination Up ACK 2129 o Destination Down 2130 o Destination Down ACK 2131 o Destination Update 2132 o Heartbeat 2133 o Link Characteristics Request 2134 o Link Characteristics ACK 2136 It is also requested that the repository contain space for 2137 experimental signal types. 2139 13.4 DLEP Data Item Registrations 2141 A new repository for DLEP Data Items must be created. Valid Data 2142 Items are: 2144 o DLEP Version 2145 o Peer Type 2146 o MAC Address 2147 o IPv4 Address 2148 o IPv6 Address 2149 o Maximum Data Rate (Receive) 2150 o Maximum Data Rate (Transmit) 2151 o Current Data Rate (Receive) 2152 o Current Data Rate (Transmit) 2153 o Latency 2154 o Resources (Receive) 2155 o Resources (Transmit) 2156 o Relative Link Quality (Receive) 2157 o Relative Link Quality (Transmit) 2158 o Status 2159 o Heartbeat Interval/Threshold 2160 o Link Characteristics ACK Timer 2161 o Credit Window Status 2162 o Credit Grant 2163 o Credit Request 2164 o DLEP Optional Signals Supported 2165 o DLEP Optional Data Items Supported 2166 o DLEP Vendor Extension 2168 It is also requested that the registry allocation contain space for 2169 experimental data items. 2171 13.5 DLEP Well-known Port 2173 It is requested that IANA allocate a well-known port number for DLEP 2174 communication. 2176 13.6 DLEP Multicast Address 2178 It is requested that IANA allocate a multicast address for DLEP 2179 discovery signals. 2181 14. Appendix A. 2183 14.1 Peer Level Signal Flows 2185 14.1.1 Router Device Restarts Discovery 2187 Router Modem Signal Description 2188 ==================================================================== 2190 --------Peer Discovery--------> Router initiates discovery 2192 <--------Peer Offer------------ Modem detects a problem, sends 2193 w/ Non-zero Status TLV Peer Offer w/Status TLV indicating 2194 the error. 2196 Router accepts failure, restarts 2197 discovery process. 2199 --------Peer Discovery--------> Router initiates discovery 2201 <--------Peer Offer------------ Modem accepts, sends Peer Offer 2202 w/Zero Status TLV indicating 2203 success. 2205 Discovery completed. 2207 14.1.2 Router Device Detects Peer Offer Timeout 2209 Router Modem Signal Description 2210 ==================================================================== 2212 --------Peer Discovery--------> Router initiates discovery, starts 2213 a guard timer. 2215 Router guard timer expires. Router 2216 restarts discovery process. 2218 --------Peer Discovery--------> Router initiates discovery, starts 2219 a guard timer. 2221 <--------Peer Offer------------ Modem accepts, sends Peer Offer 2222 w/Zero Status TLV indicating 2223 success. 2225 Discovery completed. 2227 14.1.3 Router Peer Offer Lost 2229 Router Modem Signal Description 2230 ==================================================================== 2232 <-------Peer Discovery--------- Modem initiates discovery, starts 2233 a guard timer. 2235 ---------Peer Offer-------|| Router offers availability 2237 Modem times out on Peer Offer, 2238 restarts discovery process. 2240 <-------Peer Discovery--------- Modem initiates discovery 2242 ---------Peer Offer-----------> Router detects subsequent 2243 discovery, internally terminates 2244 the previous, accepts the new 2245 association, sends Peer Offer 2246 w/Status TLV indicating success. 2248 Discovery completed. 2250 14.1.4 Discovery Success 2252 Router Modem Signal Description 2253 ==================================================================== 2255 <-------Peer Discovery--------- Modem initiates discovery 2257 ---------Peer Offer-----------> Router offers availability 2259 <-----Peer Initialization------ Modem Connects on TCP Port 2261 <------Peer Heartbeat---------- 2263 -------Peer Heartbeat---------> 2265 <==============================> Signal flow about destinations 2266 (i.e. Destination Up, Destination 2267 Down, Destination update) 2269 <-------Peer Heartbeat--------- 2271 -------Peer Heartbeat---------> 2272 --------Peer Term Req---------> Terminate Request 2274 <--------Peer Term Res--------- Terminate Response 2276 14.1.5 Router Detects a Heartbeat timeout 2278 Router Modem Signal Description 2279 ==================================================================== 2281 <-------Peer Heartbeat--------- 2283 -------Peer Heartbeat---------> 2285 ||---Peer Heartbeat--------- 2287 ~ ~ ~ ~ ~ ~ ~ 2289 -------Peer Heartbeat---------> 2291 ||---Peer Heartbeat--------- 2292 Router Heartbeat Timer expires, 2293 detects missing heartbeats. Router 2294 takes down all destination sessions 2295 and terminates the Peer 2296 association. 2298 ------Peer Terminate ---------> Peer Terminate Request 2300 Modem takes down all destination 2301 sessions, then acknowledges the 2302 Peer Terminate 2304 <----Peer Terminate ACK--------- Peer Terminate ACK 2306 14.1.6 Modem Detects a Heartbeat timeout 2308 Router Modem Signal Description 2309 ==================================================================== 2311 <-------Peer Heartbeat--------- 2313 -------Peer Heartbeat------|| 2315 <-------Peer Heartbeat--------- 2317 ~ ~ ~ ~ ~ ~ ~ 2319 -------Peer Heartbeat------|| 2321 <-------Peer Heartbeat--------- 2322 Modem Heartbeat Timer expires, 2323 detects missing heartbeats. Modem 2324 takes down all destination sessions 2326 <-------Peer Terminate-------- Peer Terminate Request 2328 Router takes down all destination 2329 sessions, then acknowledges the 2330 Peer Terminate 2332 ------Peer Terminate ACK-----> Peer Terminate ACK 2334 14.1.7 Peer Terminate (from Modem) Lost 2336 Router Modem Signal Description 2337 ==================================================================== 2339 ||------Peer Terminate-------- Modem Peer Terminate Request 2341 Router Heartbeat times out, 2342 terminates association. 2344 --------Peer Terminate-------> Router Peer Terminate 2346 <-----Peer Terminate ACK------ Modem sends Peer Terminate ACK 2348 14.1.8 Peer Terminate (from Router) Lost 2350 Router Modem Signal Description 2351 ==================================================================== 2353 -------Peer Terminate--------> Router Peer Terminate Request 2355 Modem HB times out, 2356 terminates association. 2358 <------Peer Terminate-------- Modem Peer Terminate 2360 ------Peer Terminate ACK-----> Peer Terminate ACK 2362 14.2 Destination Specific Signal Flows 2363 14.2.1 Modem Destination Up Lost 2365 Router Modem Signal Description 2366 ==================================================================== 2368 ||-----Destination Up ------------ Modem sends Destination Up 2370 Modem timesout on ACK 2372 <------Destination Up ------------ Modem sends Destination Up 2374 ------Destination Up ACK---------> Router accepts the destination 2375 session 2377 <------Destination Update--------- Modem Destination Metrics 2378 . . . . . . . . 2379 <------Destination Update--------- Modem Destination Metrics 2381 14.2.2 Router Detects Duplicate Destination Ups 2383 Router Modem Signal Description 2384 ==================================================================== 2386 <------Destination Up ------------ Modem sends Destination Up 2388 ------Destination Up ACK-------|| Router accepts the destination 2389 session 2391 Modem timesout on ACK 2393 <------Destination Up ------------ Modem resends Destination Up 2395 Router detects duplicate 2396 Destination, takes down the 2397 previous, accepts the new 2398 Destination. 2400 ------Destination Up ACK---------> Router accepts the destination 2401 session 2403 <------Destination Update--------- Modem Destination Metrics 2404 . . . . . . . . 2405 <------Destination Update--------- Modem Destination Metrics 2407 14.2.3 Destination Up, No Layer 3 Addresses 2409 Router Modem Signal Description 2410 ==================================================================== 2412 <------Destination Up ------------ Modem sends Destination Up 2414 ------Destination Up ACK---------> Router accepts the destination 2415 session 2417 Router ARPs for IPv4 if defined. 2418 Router drives ND for IPv6 if 2419 defined. 2421 <------Destination Update--------- Modem Destination Metrics 2422 . . . . . . . . 2423 <------Destination Update--------- Modem Destination Metrics 2425 14.2.4 Destination Up with IPv4, No IPv6 2427 Router Modem Signal Description 2428 ==================================================================== 2430 <------Destination Up ------------ Modem sends Destination Up with 2431 the IPv4 TLV 2433 ------Destination Up ACK---------> Router accepts the destination 2434 session 2436 Router drives ND for IPv6 if 2437 defined. 2439 <------Destination Update--------- Modem Destination Metrics 2440 . . . . . . . . 2441 <------Destination Update--------- Modem Destination Metrics 2443 14.2.5 Destination Up with IPv4 and IPv6 2445 Router Modem Signal Description 2446 ==================================================================== 2448 <------Destination Up ------------ Modem sends Destination Up with 2449 the IPv4 and IPv6 TLVs 2451 ------Destination Up ACK---------> Router accepts the destination 2452 session 2454 <------Destination Update--------- Modem Destination Metrics 2455 . . . . . . . . 2457 14.2.6 Destination Session Success 2459 Router Modem Signal Description 2460 ==================================================================== 2462 ---------Peer Offer-----------> Router offers availability 2464 -------Peer Heartbeat---------> 2466 <------Destination Up ----------- Modem 2468 ------Destination Up ACK--------> Router 2470 <------Destination Update--------- Modem 2471 . . . . . . . . 2472 <------Destination Update--------- Modem 2474 Modem initiates the terminate 2476 <------Destination Down ---------- Modem 2478 ------Destination Down ACK-------> Router 2480 or 2482 Router initiates the terminate 2484 ------Destination Down ----------> Router 2486 <------Destination Down ACK------- Modem 2488 Acknowledgements 2490 The authors would like to acknowledge and thank the members of the 2491 DLEP design team, who have provided invaluable insight. The members 2492 of the design team are: Teco Boot, Bow-Nan Cheng, John Dowdell, 2493 Henning Rogge, and Rick Taylor. 2495 The authors would also like to acknowledge the influence and 2496 contributions of Chris Olsen, Martin Duke, Subir Das, Jaewon Kang, 2497 Vikram Kaul, and Nelson Powell. 2499 Normative References 2501 [RFC5578] Berry, B., Ed., "PPPoE with Credit Flow and Metrics", 2502 RFC 5578, February 2010. 2504 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2506 [IEEE] http://standards.ieee.org/develop/regauth/oui/index.html 2508 Informative References 2510 [TLS] Dierks, T. and Rescorla, E. "The Transport Layer Security 2511 (TLS) Protocol", RFC 5246, August 2008. 2513 Author's Addresses 2515 Stan Ratliff 2516 Independent Consultant 2517 USA 2518 EMail: ratliffstan@gmail.com 2520 Bo Berry 2521 Cisco 2522 170 West Tasman Drive 2523 San Jose, CA 95134 2524 USA 2525 EMail: 2527 Greg Harrison 2528 Cisco 2529 170 West Tasman Drive 2530 San Jose, CA 95134 2531 USA 2532 EMail: greharri@cisco.com 2534 Shawn Jury 2535 Cisco 2536 170 West Tasman Drive 2537 San Jose, CA 95134 2538 USA 2539 Email: sjury@cisco.com 2541 Darryl Satterwhite 2542 Broadcom 2543 USA 2544 Email: dsatterw@broadcom.com