idnits 2.17.00 (12 Aug 2021) /tmp/idnits31636/draft-ietf-manet-dlep-04.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 16 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 250 has weird spacing: '... Shared o ...' == Line 251 has weird spacing: '... Medium o...' -- The document date (March 25, 2013) is 3344 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 -- Obsolete informational reference (is this intentional?): RFC 4347 (ref. 'DTLS') (Obsoleted by RFC 6347) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 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 B. Berry 4 Internet-Draft G. Harrison 5 Intended status: Standards Track Cisco Systems 6 Expires: September 22, 2013 D. Satterwhite 7 Broadcom 8 S. Jury 9 NetApp 10 March 25, 2013 12 Dynamic Link Exchange Protocol (DLEP) 13 draft-ietf-manet-dlep-04 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 February 21, 2013. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 69 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 3. Credits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 4. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 5. Extensions to DLEP . . . . . . . . . . . . . . . . . . . . . . 10 73 6. Normal Session Flow . . . . . . . . . . . . . . . . . . . . . . 10 74 7. Mandatory Signals and Data Items . . . . . . . . . . . . . . . 12 75 8. Generic DLEP Packet Definition . . . . . . . . . . . . . . . . 13 76 9. DLEP Data Items . . . . . . . . . . . . . . . . . . . . . . . . 13 77 9.1 DLEP Version . . . . . . . . . . . . . . . . . . . . . . . 14 78 9.2 Peer Type . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 9.3 MAC Address . . . . . . . . . . . . . . . . . . . . . . . . 15 80 9.4 IPv4 Address . . . . . . . . . . . . . . . . . . . . . . . 16 81 9.5 IPv6 Address . . . . . . . . . . . . . . . . . . . . . . . 17 82 9.6 Maximum Data Rate (Receive) . . . . . . . . . . . . . . . . 17 83 9.7 Maximum Data Rate (Transmit) . . . . . . . . . . . . . . . 18 84 9.8 Current Data Rate (Receive) . . . . . . . . . . . . . . . . 19 85 9.9 Current Data Rate (Transmit) . . . . . . . . . . . . . . . 20 86 9.10 Expected Forwarding Time . . . . . . . . . . . . . . . . . 21 87 9.11 Latency . . . . . . . . . . . . . . . . . . . . . . . . . 21 88 9.12 Resources (Receive) . . . . . . . . . . . . . . . . . . . 22 89 9.13 Resources (Transmit) . . . . . . . . . . . . . . . . . . . 22 90 9.14 Relative Link Quality (Receive) . . . . . . . . . . . . . 23 91 9.15 Relative Link Quality (Transmit) . . . . . . . . . . . . . 24 92 9.16 Status . . . . . . . . . . . . . . . . . . . . . . . . . . 24 93 9.17 Heartbeat Interval/Threshold . . . . . . . . . . . . . . . 25 94 9.18 Link Characteristics ACK Timer . . . . . . . . . . . . . . 26 95 9.19 Credit Window Status . . . . . . . . . . . . . . . . . . . 26 96 9.20 Credit Grant Request . . . . . . . . . . . . . . . . . . . 27 97 9.21 Credit Request . . . . . . . . . . . . . . . . . . . . . . 28 99 10. DLEP Protocol Messages . . . . . . . . . . . . . . . . . . . . 29 100 10.1 Signal TLV Values . . . . . . . . . . . . . . . . . . . . 29 101 11. Peer Discovery Message . . . . . . . . . . . . . . . . . . . . 30 102 12. Peer Offer Message . . . . . . . . . . . . . . . . . . . . . . 31 103 13. Peer Offer ACK Message . . . . . . . . . . . . . . . . . . . . 31 104 14. Peer Update Message . . . . . . . . . . . . . . . . . . . . . 32 105 15. Peer Update ACK Message . . . . . . . . . . . . . . . . . . . 33 106 16. Peer Termination Message . . . . . . . . . . . . . . . . . . . 33 107 17. Peer Termination ACK Message . . . . . . . . . . . . . . . . . 33 108 18. Neighbor Up Message . . . . . . . . . . . . . . . . . . . . . 34 109 19. Neighbor Up ACK Message . . . . . . . . . . . . . . . . . . . 35 110 20. Neighbor Down Message . . . . . . . . . . . . . . . . . . . . 35 111 21. Neighbor Down ACK Message . . . . . . . . . . . . . . . . . . 35 112 22. Neighbor Update Message . . . . . . . . . . . . . . . . . . . 36 113 23. Heartbeat Message . . . . . . . . . . . . . . . . . . . . . . 36 114 24. Link Characteristics Request Message . . . . . . . . . . . . . 37 115 25. Link Characteristics ACK Message . . . . . . . . . . . . . . . 37 116 26. Security Considerations . . . . . . . . . . . . . . . . . . . 38 117 27. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 118 27.1 Registrations . . . . . . . . . . . . . . . . . . . . . . 38 119 27.2 Expert Review: Evaluation Guidelines . . . . . . . . . . . 39 120 27.3 Signal (Message) TLV Type Registration . . . . . . . . . . 39 121 27.4 DLEP Data Item Registrations . . . . . . . . . . . . . . . 39 122 27.5 DLEP Well-known Port . . . . . . . . . . . . . . . . . . . 40 123 27.6 DLEP Multicast Address . . . . . . . . . . . . . . . . . . 40 124 30. Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . 40 125 30.1 Peer Level Message Flows . . . . . . . . . . . . . . . . . 40 126 30.1.1 Modem Device Restarts Discovery . . . . . . . . . . . 40 127 30.1.2 Modem Device Detects Peer Offer Timeout . . . . . . . 41 128 30.1.3 Router Peer Offer Lost . . . . . . . . . . . . . . . . 42 129 30.1.4 Discovery Success . . . . . . . . . . . . . . . . . . 42 130 30.1.5 Router Detects a Heartbeat timeout . . . . . . . . . . 43 131 30.1.6 Modem Detects a Heartbeat timeout . . . . . . . . . . 43 132 30.1.7 Peer Terminate (from Modem) Lost . . . . . . . . . . . 44 133 30.1.8 Peer Terminate (from Router) Lost . . . . . . . . . . 44 134 30.2 Neighbor Specific Message Flows . . . . . . . . . . . . . 44 135 30.2.1 Modem Neighbor Up Lost . . . . . . . . . . . . . . . . 45 136 30.2.2 Router Detects Duplicate Neighbor Ups . . . . . . . . 45 137 30.2.3 Neighbor Up, No Layer 3 Addresses . . . . . . . . . . 46 138 30.2.4 Neighbor Up with IPv4, No IPv6 . . . . . . . . . . . . 46 139 30.2.5 Neighbor Up with IPv4 and IPv6 . . . . . . . . . . . . 46 140 30.2.6 Neighbor Session Success . . . . . . . . . . . . . . . 47 141 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 47 142 Normative References . . . . . . . . . . . . . . . . . . . . . . . 47 143 Informative References . . . . . . . . . . . . . . . . . . . . . . 48 144 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 146 1. Introduction 147 There exist today a collection of modem devices that control links of 148 variable bandwidth and quality. Examples of these types of links 149 include line-of-sight (LOS) radios, satellite terminals, and 150 cable/DSL modems. Fluctuations in speed and quality of these links 151 can occur due to configuration (in the case of cable/DSL modems), or 152 on a moment-to-moment basis, due to physical phenomena like multipath 153 interference, obstructions, rain fade, etc. It is also quite possible 154 that link quality and bandwidth varies with respect to individual 155 neighbors on a link, and with the type of traffic being sent. As an 156 example, consider the case of an 802.11g access point, serving 2 157 associated laptop computers. In this environment, the answer to the 158 question "What is the bandwidth on the 802.11g link?" is "It depends 159 on which associated laptop we're talking about, and on what kind of 160 traffic is being sent." While the first laptop, being physically 161 close to the access point, may have a bandwidth of 54Mbps for unicast 162 traffic, the other laptop, being relatively far away, or obstructed 163 by some object, can simultaneously have a bandwidth of only 32Mbps 164 for unicast. However, for multicast traffic sent from the access 165 point, all traffic is sent at the base transmission rate (which is 166 configurable, but depending on the model of the access point, is 167 usually 24Mbps or less). 169 In addition to utilizing variable bandwidth links, mobile networks 170 are challenged by the notion that link connectivity will come and go 171 over time. Effectively utilizing a relatively short-lived connection 172 is problematic in IP routed networks, as routing protocols tend to 173 rely on independent timers at OSI Layer 3 to maintain network 174 convergence (e.g. HELLO messages and/or recognition of DEAD routing 175 adjacencies). These short-lived connections can be better utilized 176 with an event-driven paradigm, where acquisition of a new neighbor 177 (or loss of an existing one) is signaled, as opposed to a timer- 178 driven paradigm. 180 Another complicating factor for mobile networks are the different 181 methods of physically connecting the modem devices to the router. 182 Modems can be deployed as an interface card in a router's chassis, or 183 as a standalone device connected to the router via Ethernet, USB, or 184 even a serial link. In the case of Ethernet or serial attachment, 185 with existing protocols and techniques, routing software cannot be 186 aware of convergence events occurring on the radio link (e.g. 187 acquisition or loss of a potential routing neighbor), nor can the 188 router be aware of the actual capacity of the link. This lack of 189 awareness, along with the variability in bandwidth, leads to a 190 situation where quality of service (QoS) profiles are extremely 191 difficult to establish and properly maintain. This is especially true 192 of demand-based access schemes such as Demand Assigned Multiple 193 Access (DAMA) implementations used on some satellite systems. With a 194 DAMA-based system, additional bandwidth may be available, but will 195 not be used unless the network devices emit traffic at rate higher 196 than the currently established rate. Increasing the traffic rate does 197 not guarantee additional bandwidth will be allocated; rather, it may 198 result in data loss and additional retransmissions on the link. 200 Addressing the challenges listed above, the authors have developed 201 the Data Link Exchange Protocol, or DLEP. The DLEP protocol runs 202 between a router and its attached modem devices, allowing the modem 203 to communicate link characteristics as they change, and convergence 204 events (acquisition and loss of potential routing neighbors). The 205 following diagrams are used to illustrate the scope of DLEP packets. 207 |-------Local Node-------| |-------Remote Node------| 208 | | | | 209 +--------+ +-------+ +-------+ +--------+ 210 | Router |=======| Modem |{~~~~~~~~}| Modem |=======| Router | 211 | | | Device| | Device| | | 212 +--------+ +-------+ +-------+ +--------+ 213 | | | Link | | | 214 |-DLEP--| | Protocol | |-DLEP--| 215 | | | (e.g. | | | 216 | | | 802.11) | | | 218 Figure 1: DLEP Network 220 In Figure 1, when the local modem detects the presence of a remote 221 node, it (the local modem) sends a signal to its router via the DLEP 222 protocol. Upon receipt of the signal, the local router may take 223 whatever action it deems appropriate, such as initiating discovery 224 protocols, and/or issuing HELLO messages to converge the network. On 225 a continuing, as-needed basis, the modem devices utilize DLEP to 226 report any characteristics of the link (bandwidth, latency, etc) that 227 have changed. DLEP is independent of the link type and topology 228 supported by the modem. 230 Figure 2 shows how DLEP can support a configuration where routers are 231 connected with different link types. In this example, Modem A 232 implements a point-to-point link, and Modem B is connected via a 233 shared medium. In both cases, the DLEP protocol is used to report the 234 characteristics of the link (bandwidth, latency, etc.) to routers. 235 The modem is also able to use the DLEP session to notify the router 236 when the remote node is lost, shortening the time required to re- 237 converge the network. 239 +--------+ +--------+ 240 +----+ Modem A| | Modem A+---+ 241 | | Device | <===== // ======> | Device | | 242 | +--------+ P-2-P Link +--------+ | 243 +---+----+ +---+----+ 244 | Router | | Router | 245 | | | | 246 +---+----+ +---+----+ 247 | +--------+ +--------+ | 248 +-----+ Modem B| | Modem B| | 249 | Device | o o o o o o o o | Device +--+ 250 +--------+ o Shared o +--------+ 251 o Medium o 252 o o 253 o o 254 o o 255 o 256 +--------+ 257 | Modem B| 258 | Device | 259 +---+----+ 260 | 261 | 262 +---+----+ 263 | Router | 264 | | 265 +--------+ 267 Figure 2: DLEP Network with Multiple Modem Devices 269 DLEP defines a set of logical signals used by modems and their 270 attached routers. The signals are used to communicate events that 271 occur on the physical link(s) managed by the modem: for example, a 272 remote node entering or leaving the network, or that the link has 273 changed. Associated with these signals are a set of data items - 274 information that describes the remote node (e.g., address 275 information), and/or the characteristics of the link to the remote 276 node. 278 The protocol is defined as a collection of type-length-value (TLV) 279 based messages, specifying the signals that are exchanged between a 280 router and a modem, and the data items associated with the signal. 281 This document specifies transport of DLEP signals and data items via 282 the UDP transport. Other transports for the protocol are possible, 283 but are outside the scope of this document. 285 DLEP signals are further defined as mandatory or optional. Signals 286 will additionally have mandatory and optional data items. 288 Implementations MUST support all mandatory signals and their 289 mandatory data items to be considered compliant. Implementations MAY 290 also support some, or all, of the optional signals and data items. 292 DLEP uses a session-oriented paradigm between the modem device and 293 its associated router. If multiple modem devices are attached to a 294 router (as in Figure 2), a separate DLEP session MUST exist for each 295 modem. If a modem device supports multiple connections to a router 296 (via multiple logical or physical interfaces), or supports 297 connections to multiple routers, a separate DLEP session MUST exist 298 for each connection. This router/modem session provides a carrier for 299 information exchange concerning neighbors (remote nodes) that are 300 accessible via the modem device. As such, all of the neighbor-level 301 exchanges in DLEP can be envisioned as building an information base 302 concerning the remote nodes, and the link characteristics to those 303 nodes. 305 Multicast traffic is handled in IP networks by deriving a Layer 2 MAC 306 address based on the Layer 3 address. Leveraging on this scheme, 307 Multicast traffic is supported in DLEP simply by treating the derived 308 MAC address as any other destination in the network. To support these 309 logical destinations, one of the DLEP participants (typically, the 310 router) informs the other as to the existence of the logical 311 neighbor. The modem, once it is aware of the existence of this 312 logical neighbor, reports link characteristics just as it would for 313 any other destination in the network. The specific algorithms a modem 314 would use to report metrics on multicast (or logical) destinations is 315 outside the scope of this specification, and is left to specific 316 implementations to decide. 318 1.1 Requirements 320 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 321 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 322 document are to be interpreted as described in BCP 14, RFC 2119 323 [RFC2119]. 325 2. Assumptions 327 Routers and modems that exist as part of the same node (e.g., that 328 are locally connected) can utilize a discovery technique to locate 329 each other, thus avoiding a-priori configuration. The modem is 330 responsible for initialing the discovery process, using the Peer 331 Discovery message. 333 DLEP utilizes a session-oriented paradigm. A router and modem form a 334 session by completing the discovery process. This router-modem 335 session persists unless or until it either (1) times out, based on 336 the timeout values supplied, or (2) is explicitly torn down by one of 337 the participants. Note that use of timers in DLEP is OPTIONAL; that 338 is, implementations can choose to run with no timers (or effectively, 339 timers set to an infinite value). 341 DLEP assumes that participating modems, and their physical links, act 342 as a transparent bridge. Specifically, the assumption is that the 343 destination MAC address for data traffic in any frame emitted by the 344 router should be the MAC address of a device in the remote node. DLEP 345 also assumes that MAC addresses are unique within the context of the 346 router-modem session. 348 This document refers to a remote node as a "Neighbor". Neighbors can 349 be identified by either the router or the modem, and represent a 350 specific destination (e.g., an address) that exists on the link(s) 351 managed by the modem. Examples of a destination include a MAC 352 address, a unicast Layer 3 address, or a multicast Layer 3 address. 353 As "neighbors" are discovered, DLEP routers and modems build an 354 information base on destinations accessible via the modem. Changes in 355 link characteristics MAY then be reported as being "modem-wide" 356 (effecting ALL neighbors accessed via the modem) or MAY be neighbor 357 (destination) specific. 359 The DLEP signals concerning neighbors thus become the way for routers 360 and modems to maintain, and notify each other about, an information 361 base representing the physical and logical (e.g., multicast) 362 destinations accessible via the modem device. The information base 363 would contain addressing information (e.g., MAC address, and 364 OPTIONALLY, Layer 3 addresses), link characteristics (metrics), and 365 OPTIONALLY, flow control information (credits). 367 DLEP assumes that security on the session (e.g. authentication of 368 session partners, encryption of traffic, or both) is dealt with by 369 the underlying transport mechanism (e.g., by using a transport such 370 as DTLS [DTLS]). 372 Sequence Numbers for DLEP messages start at 0 and are incremented by 373 one for each original and retransmitted message. The unsigned 16-bit 374 Sequence Number rolls over at 65535 to 0. Sequence Numbers are unique 375 within the context of a DLEP session. Sequence numbers are used in 376 DLEP to correlate a response to a request. 378 This document specifies an implementation of the DLEP signals and 379 data items running over the UDP transport, utilizing a well-known UDP 380 Port number. It is assumed that DLEP running over other transport 381 mechanisms would be documented separately. 383 3. Credits 385 DLEP includes an OPTIONAL credit-windowing scheme analogous to the 386 one documented in [RFC5578]. In this scheme, traffic between the 387 router and modem is treated as two unidirectional windows. This 388 document identifies these windows as the "Modem Receive Window", or 389 MRW, and the "Router Receive Window", or RRW. 391 If credits are used, they MUST be granted by the receiver on a given 392 window - that is, on the "Modem Receive Window" (MRW), the modem is 393 responsible for granting credits to the router, allowing it (the 394 router) to send data to the modem. Likewise, the router is 395 responsible for granting credits on the RRW, which allows the modem 396 to send data to the router. 398 DLEP expresses all credit data in number of octets. The total number 399 of credits on a window, and the increment to add to a grant, are 400 always expressed as a 64-bit unsigned quantity. 402 If used, credits are managed on a neighbor-specific basis; that is, 403 separate credit counts are maintained for each neighbor requiring the 404 service. Credits do not apply to the DLEP session that exists between 405 routers and modems. 407 4. Metrics 409 DLEP includes the ability for the router and modem to communicate 410 metrics that reflect the characteristics (e.g. bandwidth, latency) of 411 the variable-quality link in use. As mentioned in the introduction 412 section of this document, metrics have to be used within a context - 413 for example, metrics to a unicast address in the network. DLEP allows 414 for metrics to be sent within two contexts - metrics for a specific 415 neighbor (those for a given destination within the network), and 416 "modem-wide" (those that apply to all destinations accessed via the 417 modem). Metrics supplied on DLEP Peer signals are, by definition, 418 modem-wide; metrics supplied on Neighbor signals are, by definition, 419 used for the specific neighbor only. 421 Metrics are further subdivided into transmit and receive metrics. 423 It is left to implementations to choose sensible default values based 424 on their specific characteristics. Additionally, this mechanism 425 (either at a modem-wide or specific neighbor context) MAY be used to 426 report non-changing, or static, metrics. Modems having static link 427 metric characteristics MAY report metrics only once for a given 428 neighbor (or once on a modem-wide basis, if all connections via the 429 modem are of this static nature). 431 The approach of allowing for different contexts for metric data 432 increases both the flexibility and the complexity of using metric 433 data. This document details the mechanism whereby the data is 434 transmitted, however, the specific algorithms (precedence, etc) for 435 utilizing the dual-context metrics is out of scope and not addressed 436 by this document. 438 5. Extensions to DLEP 440 While this draft represents the best efforts of the co-authors, and 441 the working group, to be functionally complete, it is recognized that 442 extensions to DLEP will in all likelihood be necessary as more link 443 types are utilized. To allow for future innovation, the draft 444 allocates numbering space for experimental implementations of both 445 signals and data items. 447 DLEP implementations MUST be capable of parsing and acting on the 448 mandatory signals and data items as documented in this specification. 449 DLEP signals/data items that are optional, or are in the experimental 450 numbering range SHOULD be silently dropped by an implementation if 451 they are not understood. 453 The intent of the optional signals and data items, as well as the 454 experimental numbering space, is to allow for further development of 455 DLEP protocol features and function. Having experimental space 456 reserved for both signals and data items gives maximum flexibility 457 for extending the protocol as conditions warrant. For example, 458 experimental data items could be used by implementations to send 459 additional metrics. A combination of experimental signals, and 460 associated data items, could be used to implement new flow control 461 schemes. If subsequent research and development define new features 462 and function, then it should be standardized either as an update to 463 this document, or as an additional stand-alone specification. 465 6. Normal Session Flow 467 At the start of a run, DLEP implementations (both router and modem) 468 initialize the communications path. In a UDP implementation, this 469 includes opening a socket and binding to the well-known port address 470 (TBD). Once the communications path is established, modem 471 implementations are free to issue a "Peer Discovery" message. The 472 Peer Discovery MAY be sent either to the multicast address allocated 473 for DLEP (TBD), or to a unicast address, obtained via a-priori 474 configuration. 476 Routers receiving a Peer Discovery message respond with a "Peer 477 Offer" signal to indicate readiness to participate in the DLEP 478 session. The receiver of a Peer Offer message responds with a "Peer 479 Offer ACK" message, completing discovery. While the Peer Discovery 480 message MAY be sent to the DLEP multicast address (TBD), the Peer 481 Offer, and all subsequent traffic, is sent to the unicast address 482 that originated the Peer Discovery. Once the Peer Offer signal is 483 acknowledged, both participants (router and modem) transition to the 484 "in session" state, creating a logical, stateful session between the 485 modem and the router. Subsequent DLEP signals are then processed 486 within the context of this router/modem session. In the UDP-based 487 implementation, traffic between DLEP modems and routers is correlated 488 using the UDP 4-tuple (Source Address, Source Port, Destination 489 Address, Destination Port). DLEP partners use these signals to build 490 their respective information bases regarding destinations that are 491 accessible via the modem, and link characteristics associated with 492 those destinations. 494 The "in session" state created by the discovery signals is maintained 495 until one of the following conditions occur: 497 o The session is explicitly terminated (using Peer Termination), or 498 o The session times out, based on supplied timeout values. 500 In order to maintain the session between router and modem, OPTIONAL 501 periodic "Heartbeat" messages MAY be exchanged. These messages are 502 intended to keep the session alive, and to verify bidirectional 503 connectivity between the two participants. DLEP also provides for an 504 OPTIONAL Peer Update message, intended to communicate some change in 505 status (e.g., a change of layer 3 address parameters, or a modem-wide 506 link change). 508 In addition to the messages above, the participants will transmit 509 DLEP messages concerning destinations in the network. These messages 510 trigger creation/maintenance/deletion of "neighbors" in the 511 information base of the recipient. For example, a modem will inform 512 its attached router of the presence of a new destination via the 513 "Neighbor Up" signal. Receipt of a Neighbor Up causes the router to 514 allocate the necessary resources, creating an entry in the 515 information base with the specifics (e.g., MAC Address, Latency, Data 516 Rate, etc) of the neighbor. The loss of a destination is communicated 517 via the "Neighbor Down" signal, and changes in status to the 518 destination (e.g. varying link quality, or addressing changes) are 519 communicated via the "Neighbor Update" signal. The information on a 520 given neighbor will persist in the router's information base until 521 (1) a "Neighbor Down" is received, indicating that the modem has lost 522 contact with the remote node, or (2) the router/modem session 523 terminates, indicating that the router has lost contact with its own 524 local modem. 526 Again, metrics can be expressed within the context of a specific 527 neighbor via the Neighbor Update message, or on a modem-wide basis 528 via the Peer Update message. In cases where metrics are provided on 529 the router/modem session, the receiver MUST propagate the metrics to 530 all neighbors in its information base that are accessed via the 531 originator. A DLEP participant MAY send metrics both in a 532 router/modem session context (via the Peer Update message) and a 533 specific neighbor context (via Neighbor Update) at any time. The 534 heuristics for applying received metrics is left to implementations. 536 In addition to receiving metrics about the link, DLEP provides an 537 OPTIONAL signal allowing a router to request a different amount of 538 bandwidth, or latency, from the modem. This signal is referred to as 539 the Link Characteristics Message, and gives the router the ability to 540 deal with requisite increases (or decreases) of allocated 541 bandwidth/latency in demand-based schemes in a more deterministic 542 manner. 544 7. Mandatory Signals and Data Items 546 The following DLEP signals are considered core to the specification; 547 implementations MUST support these signals, and the associated data 548 items, in order to be considered compliant: 550 Signal Data Items 551 ====== ========== 552 Peer Discovery None 554 Peer Offer None 556 Peer Offer ACK Status 558 Peer Termination None 560 Peer Termination ACK Status 562 Neighbor Up MAC Address 563 Maximum Data Rate 564 Current Data Rate 566 Neighbor Update MAC Address 567 Maximum Data Rate 568 Current Data Rate 570 Neighbor Down MAC Address 572 All other DLEP signals and data items are OPTIONAL. Implementations 573 MAY choose to provide them. Implementations that do not support 574 optional signals and data items SHOULD parse, and silently drop, all 575 unsupported signals and/or data items. 577 8. Generic DLEP Packet Definition 579 The Generic DLEP Packet consists of a sequence of TLVs. The first TLV 580 represents the signal being communicated (e.g., a "Neighbor Up", or a 581 "Peer Offer"). Subsequent TLVs contain the data items pertinent to 582 the signal (e.g., Maximum Data Rate, or Latency, etc). 584 The Generic DLEP Packet Definition contains the following fields: 586 0 1 2 3 587 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 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 |Signal TLV Type | Length | DLEP data items... | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 Signal - One of the DLEP Signal TLV type values 593 defined in this document. 595 Length - The length of all of the DLEP data items 596 associated with this signal. 598 DLEP data items - One or more data items, encoded in TLVs, 599 as defined in this document. 601 9. DLEP Data Items 603 As mentioned earlier, DLEP protocol messages are transported as a 604 collection of TLVs. The first TLV present in a DLEP message MUST be 605 one of the Signal TLVs, documented in section [INSERT REFERENCE 606 HERE]. The signals are followed by one or more data items, indicating 607 the specific changes that need to be instantiated in the receiver's 608 information base. 610 Valid DLEP Data Items are: 612 TLV TLV 613 Value Description 614 ========================================= 615 TBD DLEP Version 616 TBD Peer Type 617 TBD IPv4 Address 618 TBD IPv6 Address 619 TBD Maximum Data Rate (Receive) (MDRR) 620 TBD Maximum Data Rate (Transmit) (MDRT) 621 TBD Current Data Rate (Receive) (CDRR) 622 TBD Current Data Rate (Transmit) (CDRT) 623 TBD Transmit Latency 624 TBD Receive Resources 625 TBD Transmit Resources 626 TBD Expected Forwarding Time (EFT) 627 TBD Relative Link Quality (Receive) (RLQR) 628 TBD Relative Link Quality (Transmit) (RLQT) 629 TBD Status 630 TBD Heartbeat Interval/Threshold 631 TBD Neighbor down ACK timer 632 TBD Link Characteristics ACK timer 633 TBD Credit Window Status 634 TBD Credit Grant 635 TBD Credit Request 637 DLEP data item TLVs contain the following fields: 639 0 1 2 3 640 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 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | TLV Type | Length | Value... | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 TLV Type - An 8-bit unsigned integer field specifying the data 646 item being sent. 648 Length - An 8-bit length of the value field of the data item 650 Value - A field of length which contains data 651 specific to a particular data item. 653 9.1 DLEP Version 655 The DLEP Version TLV is an OPTIONAL TLV in both the Peer Discovery 656 and Peer Offer messages. The Version TLV is used to indicate the 657 version of the protocol running in the originator. A participant MAY 658 use this information to decide if the potential session partner is 659 running at a supported level. 661 The DLEP Version TLV contains the following fields: 663 0 1 2 3 664 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 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 |TLV Type =TBD |Length=4 | Major Version | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | Minor Version | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 TLV Type - TBD 673 Length - Length is 4 675 Major Version - Major version of the modem or router protocol. 677 Minor Version - Minor version of the modem or router protocol. 679 Support of this draft is indicated by setting the Major Version 680 to '1', and the Minor Version to '3' (e.g. Version 1.3). 682 9.2 Peer Type 684 The Peer Type TLV is an OPTIONAL TLV in both the Peer Discovery and 685 Peer Offer messages. The Peer Type TLV is used by the router and 686 modem to give additional information as to its type. The peer type is 687 a string and is envisioned to be used for informational purposes 688 (e.g. as output in a display command). 690 The Peer Type TLV contains the following fields: 692 0 1 2 3 693 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 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 |TLV Type =TBD |Length= peer |Peer Type String | 696 | |type string len|Max Len = 80 | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 TLV Type - TBD 701 Length - Length of peer type string (80 octets maximum). 703 Peer Type String - Non-Null terminated string, maximum length of 80 704 octets. For example, a satellite modem might set 705 this variable to 'Satellite terminal'. 707 9.3 MAC Address 709 The MAC address TLV MUST appear in all neighbor-oriented signals 710 (e.g. Neighbor Up, Neighbor Up ACK, Neighbor Down, Neighbor Down ACK, 711 Neighbor Update, Link Characteristics Request, and Link 712 Characteristics ACK). The MAC Address TLV contains the address of the 713 destination on the remote node. The MAC address MAY be either a 714 physical or a virtual destination. Examples of a virtual destination 715 would be a multicast MAC address, or the broadcast MAC 716 (0xFFFFFFFFFFFF). 718 0 1 2 3 719 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 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 |TLV Type =TBD |Length = 6 | MAC Address | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | MAC Address | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 TLV Type - TBD 728 Length - 6 730 MAC Address - MAC Address of the destination (either physical or 731 virtual). 733 9.4 IPv4 Address 735 The IPv4 Address TLV is an OPTIONAL TLV. If supported, it MAY appear 736 in Neighbor Up, Neighbor Update, and Peer Update messages. When 737 included in Neighbor messages, the IPv4 Address TLV contains the IPv4 738 address of the neighbor, as well as a subnet mask value. In the Peer 739 Update message, it contains the IPv4 address of the originator of the 740 message. In either case, the TLV also contains an indication of 741 whether this is a new or existing address, or is a deletion of a 742 previously known address. 744 The IPv4 Address TLV contains the following fields: 746 0 1 2 3 747 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 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 |TLV Type =TBD |Length = 6 | Add/Drop | IPv4 Address | 750 | | | Indicator | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | IPv4 Address | Subnet Mask | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 TLV Type - TBD 757 Length - 6 759 Add/Drop - Value indicating whether this is a new or existing 760 IPv4 address 762 IPv4 Address - The IPv4 address of the neighbor or peer. 764 Subnet Mask - A subnet mask (0-32) to be applied to the IPv4 765 address. 767 9.5 IPv6 Address 769 The IPv6 Address TLV is an OPTIONAL TLV. If supported, it MAY be used 770 in the Neighbor Up, Neighbor Update, Peer Discovery, and Peer Update 771 Messages. When included in Neighbor messages, this data item contains 772 the IPv6 address of the neighbor. In the Peer Discovery and Peer 773 Update, it contains the IPv6 address of the originating peer. In 774 either case, the data item also contains an indication of whether 775 this is a new or existing address, or is a deletion of a previously 776 known address, as well as a subnet mask. 778 The IPv6 Address TLV contains the following fields: 780 0 1 2 3 781 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 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 |TLV Type =TBD |Length = 18 | Add/Drop | IPv6 Address | 784 | | | Indicator | | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | IPv6 Address | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | IPv6 Address | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | IPv6 Address | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | IPv6 Address | Subnet Mask | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 TLV Type - TBD 797 Length - 18 799 Add/Drop - Value indicating whether this is a new or existing 800 address (0x01), or a withdrawal of an address (0x02). 802 IPv6 Address - IPv6 Address of the neighbor or peer. 804 Subnet Mask - A subnet mask value (0-128) to be applied to the Ipv6 805 address. 807 9.6 Maximum Data Rate (Receive) 808 The Maximum Data Rate Receive (MDRR) TLV is used in Neighbor Up, 809 Neighbor Update, Peer Discovery, Peer Update, and Link 810 Characteristics ACK Messages to indicate the maximum theoretical data 811 rate, in bits per second, that can be achieved while receiving data 812 on the link. When metrics are reported via the messages listed above, 813 the maximum data rate receive MUST be reported. A value of 0 for the 814 MDRR indicates that the Maximum Data Rate Receive is currently 815 'unknown'. 817 0 1 2 3 818 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 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 |TLV Type =TBD |Length = 8 | MDRR (bps) | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | MDRR (bps) | 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 | MDRR (bps) | 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 TLV Type - TBD 829 Length - 8 831 Maximum Data Rate Receive - A 64-bit unsigned number, representing 832 the maximum theoretical data rate, in bits per 833 second (bps), that can be achieved while 834 receiving on the link. An MDRR value of 0 MAY be 835 used to indicate an 'unknown' data rate. 837 9.7 Maximum Data Rate (Transmit) 839 The Maximum Data Rate Transmit (MDRT) TLV is used in Neighbor Up, 840 Neighbor Update, Peer Discovery, Peer Update, and Link 841 Characteristics ACK Messages to indicate the maximum theoretical data 842 rate, in bits per second, that can be achieved while transmitting 843 data on the link. When metrics are reported via the messages listed 844 above, the maximum data rate transmit MUST be reported. A value of 0 845 for the MDRT MAY be used to indicate that the Maximum Data Rate 846 Transmit is currently unknown, or cannot be calculated. 848 0 1 2 3 849 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 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 |TLV Type =TBD |Length = 8 | MDRT (bps) | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | MDRT (bps) | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | MDRT (bps) | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 TLV Type - TBD 860 Length - 8 862 Maximum Data Rate Transmit - A 64-bit unsigned number, representing 863 the maximum theoretical data rate, in bits per 864 second (bps), that can be achieved while 865 transmitting on the link. An MDRT value of 0 866 indicates an 'unknown' data rate. 868 9.8 Current Data Rate (Receive) 870 The Current Data Rate Receive (CDRR) TLV is used in Neighbor Up, 871 Neighbor Update, Peer Discovery, Peer Update, Link Characteristics 872 Request, and Link Characteristics ACK messages to indicate the rate 873 at which the link is currently operating for receiving traffic. In 874 the case of the Link Characteristics Request, CDRR represents the 875 desired receive data rate for the link. When metrics are reported via 876 the messages above (e.g. Neighbor Update), the current data rate 877 receive MUST be reported. 879 The Current Data Rate Receive TLV contains the following fields: 881 0 1 2 3 882 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 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 |TLV Type =TBD |TLV Flags=0x10 |Length = 8 |CDRR (bps) | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | CDRR (bps) | 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | CDRR (bps) | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 TLV Type - TBD 893 Length - 8 895 Current Data Rate Receive - A 64-bit unsigned number, representing 896 the current data rate, in bits per second, that 897 is currently be achieved while receiving traffic 898 on the link. When used in the Link 899 Characteristics Request, CDRR represents the 900 desired receive rate, in bits per second, on the 901 link. If there is no distinction between current 902 and maximum receive data rates, current data 903 rate receive SHOULD be set equal to the maximum 904 data rate receive. A CDRR value of 0 MAY be used 905 to indicate the CDRT is unknown, or cannot be 906 calculated. 908 9.9 Current Data Rate (Transmit) 910 The Current Data Rate Receive (CDRT) TLV is used in Neighbor Up, 911 Neighbor Update, Peer Discovery, Peer Update, Link Characteristics 912 Request, and Link Characteristics ACK messages to indicate the rate 913 at which the link is currently operating for transmitting traffic. In 914 the case of the Link Characteristics Request, CDRT represents the 915 desired transmit data rate for the link. When metrics are reported 916 via the messages above (e.g. Neighbor Update), the current data rate 917 transmit MUST be reported. 919 The Current Data Rate Transmit TLV contains the following fields: 921 0 1 2 3 922 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 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 |TLV Type =TBD |TLV Flags=0x10 |Length = 8 |CDRT (bps) | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | CDRT (bps) | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | CDRT (bps) | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 TLV Type - TBD 933 Length - 8 935 Current Data Rate Transmit - A 64-bit unsigned number, representing 936 the current data rate, in bits per second, that 937 is currently be achieved while transmitting 938 traffic on the link. When used in the Link 939 Characteristics Request, CDRT represents the 940 desired transmit rate, in bits per second, on 941 the link. If there is no distinction between 942 current and maximum transmit data rates, current 943 data rate transmit MUST be set equal to the 944 maximum data rate transmit. A CDRT value of 0 945 MAY be used to indicate the CDRT is 'unknown', 946 or cannot be calculated. 948 9.10 Expected Forwarding Time 950 The Expected Forwarding Time (EFT) TLV is is an OPTIONAL data item. 951 If supported, it MAY be used in Neighbor Up, Neighbor Update, Peer 952 Discovery, and Peer Update messages to indicate the typical latency 953 between the arrival of a given packet at the transmitting device and 954 the reception of the packet at the other end of the link. EFT 955 combines transmission time, idle time, waiting time, freezing time, 956 and queuing time to the degree that those values are meaningful to a 957 given transmission medium. 959 The Expected Forwarding Time TLV contains the following fields: 961 0 1 2 3 962 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 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 |TLV Type =TBD |Length = 4 | EFT (ms) | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 | EFT (ms) | 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 TLV Type - TBD 971 Length - 4 973 EFT - A 32-bit unsigned number, representing the expected 974 forwarding time, in milliseconds, on the link. 976 9.11 Latency 978 The Latency TLV is an OPTIONAL data item. If supported, it is used in 979 Neighbor Up, Neighbor Update, Peer Discovery, Peer Update, Link 980 Characteristics Request, and Link Characteristics ACK messages to 981 indicate the amount of latency on the link, or in the case of the 982 Link Characteristics Request, to indicate the maximum latency 983 required on the link. 985 0 1 2 3 986 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 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 |TLV Type =TBD |Length = 2 | Latency (ms) | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 TLV Type - TBD 993 Length - 2 994 Latency - A 16-bit unsigned value, representing the transmission 995 delay that a packet encounters as it is transmitted 996 over the link. In Neighbor Up, Neighbor Update, and 997 Link Characteristics ACK, this value is reported as 998 delay, in milliseconds. The calculation of latency is 999 implementation dependent. For example, the latency may 1000 be a running average calculated from the internal 1001 queuing. If a device cannot calculate latency, this 1002 TLV SHOUD NOT be issued. In the Link Characteristics 1003 Request Message, this value represents the maximum 1004 delay, in milliseconds, expected on the link. 1006 9.12 Resources (Receive) 1008 The Receive Resources TLV is an OPTIONAL data item. If supported, it 1009 is used in Neighbor Up, Neighbor Update, Peer Discovery, Peer Update, 1010 and Link Characteristics ACK messages to indicate a percentage (0- 1011 100) amount of resources (e.g. battery power), committed to receiving 1012 data, remaining on the originating peer. 1014 The Resources TLV contains the following fields: 1016 0 1 2 1017 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 |TLV Type =TBD |Length = 1 | Rcv Resources| 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 TLV Type - TBD 1024 Length - 1 1026 Receive Resources - A percentage, 0-100, representing the amount 1027 of remaining resources, such as battery power, 1028 allocated to receiving data. A value of '0' MAY be 1029 used to indicate the receive resources are unknown or 1030 cannot be calculated. 1032 9.13 Resources (Transmit) 1034 The Transmit Resources TLV is an OPTIONAL data item. If supported, it 1035 is used in Neighbor Up, Neighbor Update, Peer Discovery, Peer Update, 1036 and Link Characteristics ACK messages to indicate a percentage (0- 1037 100) amount of resources (e.g. battery power), committed to 1038 transmitting data, remaining on the originating peer. 1040 The Resources TLV contains the following fields: 1042 0 1 2 1043 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 |TLV Type =TBD |Length = 1 | Xmt Resources| 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 TLV Type - TBD 1050 Length - 1 1052 Transmit Resources - A percentage, 0-100, representing the amount 1053 of remaining resources, such as battery power, 1054 allocated to transmitting data. A value of '0' MAY be 1055 used to indicate the transmit resources are unknown or 1056 cannot be calculated. 1058 9.14 Relative Link Quality (Receive) 1060 The Relative Link Quality Receive (RLQR) TLV is an OPTIONAL data 1061 item. If supported, it is used in Neighbor Up, Neighbor Update, Peer 1062 Discovery, Peer Update, and Link Characteristics ACK messages to 1063 indicate the quality of the link for receiving data as calculated by 1064 the originating peer. 1066 The Relative Link Quality (Receive) TLV contains the following 1067 fields: 1069 0 1 2 1070 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 |TLV Type =TBD |Length = 1 |RCV Rel. Link | 1073 | | |Quality (RLQR) | 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 TLV Type - TBD 1078 Length - 1 1080 Relative Link Quality (Receive) - A non-dimensional number, 1-100, 1081 representing relative link quality. A value of 1082 100 represents a link of the highest quality. 1083 A value of '0' indicated the RLQR is 1084 'unknown', or cannot be calculated. 1086 9.15 Relative Link Quality (Transmit) 1088 The Transmit Link Quality Receive (RLQT) TLV is an OPTIONAL data 1089 item. If supported, it is used in Neighbor Up, Neighbor Update, Peer 1090 Discovery, Peer Update, and Link Characteristics ACK messages to 1091 indicate the quality of the link for transmitting data as calculated 1092 by the originating peer. 1094 The Relative Link Quality (Transmit) TLV contains the following 1095 fields: 1097 0 1 2 1098 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 |TLV Type =TBD |Length = 1 |XMT Rel. Link | 1101 | | |Quality (RLQR) | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 TLV Type - TBD 1106 Length - 1 1108 Relative Link Quality (Transmit) - A non-dimensional number, 1-100, 1109 representing relative link quality. A value of 1110 100 represents a link of the highest quality. 1111 A value of '0' indicated the RLQT is 1112 'unknown', or cannot be calculated. 1114 9.16 Status 1116 The Status TLV is sent as part of an acknowledgement message, from 1117 either the modem or the router, to indicate the success or failure of 1118 a given request. 1120 The Status TLV contains the following fields: 1122 0 1 2 1123 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 |TLV Type =TBD |Length = 1 | Code | 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 TLV Type - TBD 1130 Length - 1 1132 Termination Code - 0 = Success, Non-zero = Failure. Specific values 1133 of a non-zero termination code depend on the 1134 operation requested (e.g. Neighbor Up, 1135 Neighbor Down, etc). 1137 9.17 Heartbeat Interval/Threshold 1139 The Heartbeat Interval/Threshold TLV is an OPTIONAL TLV. If 1140 supported, it MAY be sent during Peer Discovery to indicate the 1141 desired Heartbeat timeout window. If the modem includes the Heartbeat 1142 Interval TLV in Peer Discovery, the router MUST either accept the 1143 timeout interval supplied by the modem, or reject the Peer Discovery. 1144 Peer Discovery messages that do not include the Heartbeat Interval 1145 TLV in Peer Discovery indicates a desire to establish the 1146 router/modem session without an activity timeout (e.g. an infinite 1147 timeout value). If an activity timeout is supported, implementations 1148 MAY choose to implement heuristics such that signals sent/received 1149 reset the timer window. 1151 The Interval is used to specify a period (in seconds) for Heartbeat 1152 Messages (See Section 23). The Threshold value is used to indicate 1153 the desired number of windows, each of time (Heartbeat Interval) 1154 seconds, to wait before either participant declares the router/modem 1155 session lost. In this case, the overall amount of time before a 1156 router/modem is declared lost is expressed as (Interval * Threshold). 1157 Specifying an Interval value of 0 indicates the desire to disable 1158 Heartbeat messages entirely (e.g., the Interval is set to an infinite 1159 value). Setting the Threshold value to 0 is undefined, and TLVs with 1160 a Threshold value of 0 MUST be rejected by the recipient. 1162 The Heartbeat Interval/Threshold TLV contains the following fields: 1164 0 1 2 3 1165 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 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 |TLV Type =TBD |Length = 1 | Interval | Threshold | 1168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1170 TLV Type - TBD 1172 Length - 1 1174 Interval - 0 = Do NOT use heartbeats on this peer-to-peer 1175 session. Non-zero = Interval, in seconds, for 1176 heartbeat messages. 1178 Threshold - Number of windows, of Heartbeat Interval seconds, 1179 to wait before declaring a peer-to-peer session to 1180 be lost. 1182 9.18 Link Characteristics ACK Timer 1184 The Link Characteristics ACK Timer TLV is an OPTIONAL TLV. If 1185 supported, it MAY be sent during Peer Discovery to indicate the 1186 desired number of seconds to wait for a response to a Link 1187 Characteristics Request. If a router receives this TLV from a modem 1188 during Peer Discovery, the router MUST either accept the timeout 1189 value, or reject the Peer Discovery. If this TLV is omitted, 1190 implementations supporting the Link Characteristics Request SHOULD 1191 choose a default value. 1193 The Link Characteristics ACK Timer TLV contains the following fields: 1195 0 1 2 1196 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 |TLV Type =TBD |Length = 1 | Interval | 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 TLV Type - TBD 1203 Length - 1 1205 Interval - 0 = Do NOT use timeouts for Link Characteristics 1206 requests on this router/modem session. Non-zero = 1207 Interval, in seconds, to wait before considering a 1208 Link Characteristics Request has been lost. 1210 9.19 Credit Window Status 1212 The Credit Window Status TLV is an OPTIONAL TLV. If credits are 1213 supported by the DLEP participants (both the router and the modem), 1214 the Credit Window Status TLV MUST be sent by the participant 1215 receiving a Credit Grant Request for a given neighbor. 1217 The Credit Window Status TLV contains the following fields: 1219 0 1 2 3 1220 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 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 |TLV Type =TBD |Length = 16 | Modem Receive Window Value | 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 | Modem Receive Window Value | 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 | Modem Receive Window Value | Router Receive Window Value | 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 | Router Receive Window Value | 1229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 | Router Receive Window Value | 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 TLV Type - TBD 1235 Length - 16 1237 Modem Receive Window Value - A 64-bit unsigned number, indicating 1238 the current (or initial) number of 1239 credits available on the Modem Receive 1240 Window. 1242 Router Receive Window Value - A 64-bit unsigned number, indicating 1243 the current (or initial) number of 1244 credits available on the Router Receive 1245 Window. 1247 9.20 Credit Grant Request 1249 The Credit Grant Request TLV is an OPTIONAL TLV. If credits are 1250 supported, the Credit Grant Request TLV is sent from a DLEP 1251 participant to grant an increment to credits on a window. The Credit 1252 Grant TLV is sent as a data item in either the Neighbor Up or 1253 Neighbor Update messages. The value in a Credit Grant TLV represents 1254 an increment to be added to any existing credits available on the 1255 window. Upon successful receipt and processing of a Credit Grant TLV, 1256 the receiver MUST respond with a message containing a Credit Window 1257 Status TLV to report the updated aggregate values for synchronization 1258 purposes. 1260 In the Neighbor Up message, when credits are desired, the originating 1261 peer MUST set the initial credit value of the window it controls 1262 (e.g. the Modem Receive Window, or Router Receive Window) to an 1263 initial, non-zero value. If the receiver of a Neighbor Up message 1264 with a Credit Grant Request TLV supports credits, the receiver MUST 1265 either reject the use of credits, via a Neighbor Up ACK response with 1266 the correct Status TLV, or set the initial value from the data 1267 contained in the Credit Window Status TLV. If the initialization 1268 completes successfully, the receiver MUST respond to the Neighbor Up 1269 message with a Neighbor Up ACK message that contains a Credit Window 1270 Status TLV, initializing its receive window. 1272 The Credit Grant TLV contains the following fields: 1274 0 1 2 3 1275 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 1276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 |TLV Type =TBD |Length = 8 | Credit Increment | 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 | Credit Increment | 1280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1281 | Credit Increment | 1282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1284 TLV Type - TBD 1286 Length - 8 1288 Reserved - A 64-bit unsigned number representing the 1289 additional credits to be assigned to the credit 1290 window. Since credits can only be granted by the 1291 receiver on a window, the applicable credit window 1292 (either the MRW or the RRW) is derived from the 1293 sender of the grant. The Credit Increment MUST NOT 1294 cause the window to overflow; if this condition 1295 occurs, implementations MUST set the credit window 1296 to the maximum value contained in a 64-bit 1297 quantity. 1299 9.21 Credit Request 1301 The Credit Request TLV is an OPTIONAL TLV. If credits are supported, 1302 the Credit Request TLV MAY be sent from either DLEP participant, via 1303 a Neighbor Update signal, to indicate the desire for the partner to 1304 grant additional credits in order for data transfer to proceed on the 1305 session. If the corresponding Neighbor Up message for this session 1306 did NOT contain a Credit Window Status TLV, indicating that credits 1307 are to be used on the session, then the Credit Request TLV MUST be 1308 rejected by the receiver via a Neighbor Update ACK message. 1310 The Credit Request 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 = 0 | Reserved, MUST| 1316 | | | be set to 0 | 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1319 TLV Type - TBD 1320 Length - 0 1322 Reserved - This field is currently unused and MUST be set to 0. 1324 10. DLEP Protocol Messages 1326 DLEP messages are encoded as a string of Type-Length-Value (TLV) 1327 constructs. The first TLV in a DLEP message MUST be a valid DLEP 1328 signal, as defined in section 11.1 of this document. The second TLV 1329 MUST be the Identification data item, defined in section 10.1 1330 Following those two TLVs are 0 or more TLVs, representing the data 1331 items that are appropriate for the signal. The layout of a DLEP 1332 message is thus: 1334 0 1 2 3 1335 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 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 | DLEP Signal |DLEP Message |Identification |Identification | 1338 | Type value |length (9 + |TLV Type |TLV length | 1339 | (value TBD) |optional TLVs) |(TBD) |(8) | 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 | Router ID | 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 | Modem ID | 1344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1345 | Start of optional DLEP | 1346 | TLVs... | 1347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1349 All DLEP messages (signals) begin with this structure. Therefore, in 1350 the following descriptions of specific messages, this header 1351 structure is assumed, and will not be replicated. 1353 10.1 Signal TLV Values 1355 As mentioned above, all DLEP messages begin with the Type value of 1356 the appropriate DLEP signal. Valid DLEP signals are: 1358 TLV TLV 1359 Value Description 1360 ========================================= 1361 TBD Peer Discovery 1362 TBD Peer Offer 1363 TBD Peer Offer ACK 1364 TBD Peer Update 1365 TBD Peer Update ACK 1366 TBD Peer Termination 1367 TBD Peer Termination ACK 1368 TBD Neighbor Up 1369 TBD Neighbor Up ACK 1370 TBD Neighbor Down 1371 TBD Neighbor Down ACK 1372 TBD Neighbor Update 1373 TBD Heartbeat 1374 TBD Link Characteristics Request 1375 TBD Link Characteristics ACK 1377 11. Peer Discovery Message 1379 The Peer Discovery Message is sent by a modem to begin a new DLEP 1380 association. The Peer Offer message is required to complete the 1381 discovery process. Implementations MAY implement their own retry 1382 heuristics in cases where it is determined the Peer Discovery Message 1383 has timed out. A Peer Discovery Message received from a modem that is 1384 already in session MUST be processed as if a Peer Termination Message 1385 had been received. A router implementation MAY then process the 1386 received Peer Discovery Message. 1388 Note that metric data items MAY be supplied with the Peer Discovery, 1389 in order to populate default metric values, or to indicate a static, 1390 modem-wide environment. If metrics are supplied with the Peer 1391 Discovery message, these metrics MUST be used as the initial values 1392 for all neighbors (remote nodes) established via the modem. 1394 Given the packet format described in section 11, the initial TLV Type 1395 value is set to DLEP_PEER_DISCOVERY (value TBD). OPTIONAL TLVs are 1396 then placed into the packet: 1398 Optional Data Item TLVs: 1399 - DLEP Version 1400 - DLEP Peer Type 1401 - Heartbeat Interval 1402 - Heartbeat Threshold 1403 - Link Characteristics ACK Timer 1404 - Maximum Data Rate (Receive) 1405 - Maximum Data Rate (Transmit) 1406 - Current Data Rate (Receive) 1407 - Current Data Rate (Transmit) 1408 - Latency 1409 - Expected Forwarding Time 1410 - Resources (Receive) 1411 - Resources (Transmit) 1412 - Relative Link Quality (Receive) 1413 - Relative Link Quality (Transmit) 1415 12. Peer Offer Message 1417 The Peer Offer Message is sent by a DLEP router in response to a Peer 1418 Discovery Message. Upon receipt, and processing, of a Peer Offer 1419 message, the modem MUST respond with a Peer Offer ACK message, 1420 completing the discovery phase of DLEP. Both DLEP participants 1421 (router and modem) would then enter an "in session" state. Any 1422 subsequent Discovery messages sent or received on this session MUST 1423 be considered an error, and the session MUST be terminated as if a 1424 Peer Termination Message had been received. 1426 The Peer Offer message MUST be sent to the unicast address of the 1427 originator of Peer Discovery, regardless of whether the discovery was 1428 received on the DLEP multicast address (TBD) or on a unicast 1429 address. 1431 To construct a Peer Offer message, the initial TLV type value is set 1432 to DLEP_PEER_OFFER (value TBD). The signal TLV is then followed by 1433 any OPTIONAL Data Item TLVs the implementation supports: 1435 Optional Data Item TLVs: 1437 - DLEP Version 1438 - Peer Type 1439 - IPv4 Address 1440 - IPv6 Address 1441 - Status 1442 - Heartbeat Interval 1443 - Heartbeat Threshold 1444 - Link Characteristics ACK Timer 1446 13. Peer Offer ACK Message 1448 The Peer Offer ACK message acknowledges receipt of a Peer Offer 1449 message, and completes the router/modem session establishment for 1450 DLEP. The Peer Offer ACK message MUST be sent to unicast address of 1451 the originator of a Peer Offer message. The Peer Offer ACK message 1452 MUST contain an OPTIONAL Status data item, indicating success or 1453 failure of the attempt to establish a router/modem session. 1455 To construct a Peer Offer ACK message, the initial TLV type value is 1456 set to DLEP_PEER_OFFER_ACK (value TBD). Mandatory data item TLV's are 1457 placed into the packet next: 1459 Mandatory Data Item TLVs: 1460 - Status 1462 Note that there are NO OPTIONAL data item TLVs specified for this 1463 message. 1465 14. Peer Update Message 1467 The Peer Update message is an OPTIONAL message, sent by a DLEP peer 1468 to indicate local Layer 3 address changes, or for metric changes on a 1469 modem-wide basis. For example, addition of an IPv4 address to the 1470 router would prompt a Peer Update message to its attached DLEP 1471 modems. Also, a modem that changes its Maximum Data Rate for all 1472 destinations MAY reflect that change via a Peer Update Message to its 1473 attached router(s). 1475 Concerning Layer 3 addresses, if the modem is capable of 1476 understanding and forwarding this information (via proprietary 1477 mechanisms), the address update would prompt any remote DLEP modems 1478 (DLEP-enabled modems in a remote node) to issue a "Neighbor Update" 1479 message to their local routers with the new (or deleted) addresses. 1480 Modems that do not track Layer 3 addresses SHOULD silently parse and 1481 ignore the Peer Update Message. Modems that track Layer 3 addresses 1482 MUST acknowledge the Peer Update with a Peer Update ACK message. 1483 Routers receiving a Peer Update with metric changes MUST apply the 1484 new metric to all neighbors (remote nodes) accessible via the modem. 1485 Supporting implementations are free to employ heuristics to 1486 retransmit Peer Update messages. The sending of Peer Update Messages 1487 for Layer 3 address changes SHOULD cease when a either participant 1488 (router or modem) determines that the other implementation does NOT 1489 support Layer 3 address tracking. 1491 If metrics are supplied with the Peer Update message (e.g. Maximum 1492 Data Rate), these metrics are considered to be modem-wide, and 1493 therefore MUST be applied to all neighbors in the information base 1494 associated with the router/modem session. 1496 To construct a Peer Update message, the initial TLV type value is set 1497 to DLEP_PEER_UPDATE (value TBD). The Signal TLV is followed by any 1498 OPTIONAL Data Item TLVs. 1500 Optional Data Item TLVs: 1501 - IPv4 Address 1502 - IPv6 Address 1503 - Maximum Data Rate (Receive) 1504 - Maximum Data Rate (Transmit) 1505 - Current Data Rate (Receive) 1506 - Current Data Rate (Transmit) 1507 - Latency 1508 - Expected Forwarding Time 1509 - Resources (Receive) 1510 - Resources (Transmit) 1511 - Relative Link Quality (Receive) 1512 - Relative Link Quality (Transmit) 1514 15. Peer Update ACK Message 1516 The Peer Update ACK message is an OPTIONAL message, and is sent by 1517 implementations supporting Layer 3 address tracking and/or modem-wide 1518 metrics to indicate whether a Peer Update Message was successfully 1519 processed. If the Peer Update ACK is issued, it MUST contain a Status 1520 data item, indicating the success or failure of processing the 1521 received Peer Update. 1523 To construct a Peer Update ACK message, the initial TLV type value is 1524 set to DLEP_PEER_UPDATE_ACK (value TBD). The Status data item TLV is 1525 placed in the packet next, completing the Peer Update ACK. 1527 Optional Data Item TLVs: 1529 - Status 1531 Note that there are NO OPTIONAL data item TLVs specified for this 1532 message. 1534 16. Peer Termination Message 1536 The Peer Termination Message is sent by a DLEP participant when the 1537 router/modem session needs to be terminated. Implementations 1538 receiving a Peer Termination message MUST send a Peer Termination ACK 1539 message to confirm the termination process. The sender of a Peer 1540 Termination message is free to define its heuristics in event of a 1541 timeout. The receiver of a Peer Termination Message MUST release all 1542 resources allocated for the router/modem session, and MUST eliminate 1543 all neighbors in the information base accessible via the router/modem 1544 pair represented by the session. Router and modem state machines are 1545 returned to the "discovery" state. No Neighbor Down messages are 1546 sent. 1548 To construct a Peer Termination message, the initial TLV type value 1549 is set to DLEP_PEER_TERMINATION (value TBD). The Signal TLV is 1550 followed by any OPTIONAL Data Item TLVs the implementation supports: 1552 Optional Data Item TLVs: 1554 - Status 1556 17. Peer Termination ACK Message 1558 The Peer Termination Message ACK is sent by a DLEP peer in response 1559 to a received Peer Termination order. Receipt of a Peer Termination 1560 ACK message completes the teardown of the router/modem session. 1562 To construct a Peer Termination ACK message, the initial TLV type 1563 value is set to DLEP_PEER_TERMINATION_ACK (value TBD). The 1564 Identification data item TLV is placed in the packet next, followed 1565 by any OPTIONAL TLVs the implementation supports: 1567 Optional Data Item TLVs: 1569 - Status 1571 18. Neighbor Up Message 1573 A DLEP participant sends the Neighbor Up message to report that a new 1574 destination has been detected. A Neighbor Up ACK Message is required 1575 to confirm a received Neighbor Up. A Neighbor Up message can be sent 1576 either by the modem, to indicate that a new remote node has been 1577 detected, or by the router, to indicate the presence of a new logical 1578 destination (e.g., a Multicast group) exists in the network. 1580 The sender of the Neighbor Up Message is free to define its retry 1581 heuristics in event of a timeout. When a Neighbor Up message is 1582 received and successfully parsed, the receiver should add knowledge 1583 of the new destination to its information base, indicating that the 1584 destination is accessible via the modem/router pair. 1586 To construct a Neighbor Up message, the initial TLV type value is set 1587 to DLEP_NEIGHBOR_UP (value TBD). The MAC Address data item TLV is 1588 placed in the packet next, followed by any supported OPTIONAL Data 1589 Item TLVs into the packet: 1591 Optional Data Item TLVs: 1593 - IPv4 Address 1594 - IPv6 Address 1595 - Maximum Data Rate (Receive) 1596 - Maximum Data Rate (Transmit) 1597 - Current Data Rate (Receive) 1598 - Current Data Rate (Transmit) 1599 - Latency 1600 - Expected Forwarding Time 1601 - Resources (Receive) 1602 - Resources (Transmit) 1603 - Relative Link Factor (Receive) 1604 - Relative Link Factor (Transmit) 1605 - Credit Window Status 1607 19. Neighbor Up ACK Message 1609 A DLEP participant sends the Neighbor Up ACK Message to indicate 1610 whether a Neighbor Up Message was successfully processed. 1612 To construct a Neighbor Up ACK message, the initial TLV type value is 1613 set to DLEP_NEIGHBOR_UP_ACK (value TBD). The MAC Address data item 1614 TLV is placed in the packet next, containing the MAC address of the 1615 DLEP neighbor. The implementation would then place any supported 1616 OPTIONAL Data Item TLVs into the packet: 1618 Optional Data Item TLVs: 1619 - Credit Window Status 1621 20. Neighbor Down Message 1623 A DLEP peer sends the Neighbor Down message to report when a 1624 destination (a remote node or a multicast group) is no longer 1625 reachable. The Neighbor Down message MUST contain the MAC Address 1626 data item TLV. Other TLVs as listed are OPTIONAL, and MAY be present 1627 if an implementation supports them. A Neighbor Down ACK Message MUST 1628 be sent by the recipient of a Neighbor Down message to confirm that 1629 the relevant data has been removed from the information base. The 1630 sender of the Neighbor Down message is free to define its retry 1631 heuristics in event of a timeout. 1633 To construct a Neighbor Down message, the initial TLV type value is 1634 set to DLEP_NEIGHBOR_DOWN (value TBD). The signal TLV is followed by 1635 the mandatory MAC Address data item TLV. 1637 Note that there are NO OPTIONAL data item TLVs for this message. 1639 21. Neighbor Down ACK Message 1641 A DLEP participant sends the Neighbor Down ACK Message to indicate 1642 whether a received Neighbor Down Message was successfully processed. 1643 If successfully processed, the sender of the ACK MUST have removed 1644 all entries in the information base that pertain to the referenced 1645 neighbor. As with the Neighbor Down message, there are NO OPTIONAL 1646 Data Item TLVs defined for the Neighbor Down ACK message. 1648 To construct a Neighbor Down message, the initial TLV type value is 1649 set to DLEP_NEIGHBOR_DOWN_ACK (value TBD). The mandatory data item 1650 TLVs follow: 1652 - MAC Address Data item 1653 - Status data item 1655 22. Neighbor Update Message 1657 A DLEP participant sends the Neighbor Update message when it detects 1658 some change in the information base for a given neighbor (remote node 1659 or multicast group). Some examples of changes that would prompt a 1660 Neighbor Update message are: 1662 - Change in link metrics (e.g., Data Rates) 1663 - Layer 3 addressing change (for implementations that support it) 1665 To construct a Neighbor Update message, the initial TLV type value is 1666 set to DLEP_NEIGHBOR_UPDATE (value TBD). Following the signal TLV are 1667 the mandatory Data Item TLVs: 1669 MAC Address data item TLV 1671 After placing the mandatory data item TLV into the packet, the 1672 implementation would place any supported OPTIONAL data item TLVs. 1673 Possible OPTIONAL data item TLVs are: 1675 - IPv4 Address 1676 - IPv6 Address 1677 - Maximum Data Rate (Receive) 1678 - Maximum Data Rate (Transmit) 1679 - Current Data Rate (Receive) 1680 - Current Data Rate (Transmit) 1681 - Latency 1682 - Resources (Receive) 1683 - Resources (Transmit) 1684 - Relative Link Quality (Receive) 1685 - Relative Link Quality (Transmit) 1686 - Credit Window Status 1687 - Credit Grant 1688 - Credit Request 1690 23. Heartbeat Message 1692 A Heartbeat Message is sent by a DLEP participant every N seconds, 1693 where N is defined in the "Heartbeat Interval" field of the discovery 1694 message. Note that implementations omitting the Heartbeat Interval 1695 effectively set the interval to an infinite value, therefore, in 1696 those cases, this message would NOT be sent. 1698 The message is used by participants to detect when a DLEP session 1699 partner (either the modem or the router) is no longer communicating. 1700 Participants SHOULD allow some integral number of heartbeat intervals 1701 (default 4) to expire with no traffic on the router/modem session 1702 before initiating DLEP session termination procedures. 1704 To construct a Heartbeat message, the initial TLV type value is set 1705 to DLEP_PEER_HEARTBEAT (value TBD). The signal TLV is followed by the 1706 mandatory Heartbeat Interval/Threshold data item. 1708 Note that there are NO OPTIONAL data item TLVs for this message. 1710 24. Link Characteristics Request Message 1712 The Link Characteristics Request Message is an OPTIONAL message, and 1713 is sent by the router to request that the modem initiate changes for 1714 specific characteristics of the link. Since the request specifies a 1715 neighbor, it can reference either a real destination (e.g., a remote 1716 node), or a logical destination (e.g., a multicast destination) 1717 within the network. 1719 The Link Characteristics Request message contains either a Current 1720 Data Rate (CDRR or CDRT) TLV to request a different amount of 1721 bandwidth than what is currently allocated, a Latency TLV to request 1722 that traffic delay on the link not exceed the specified value, or 1723 both. A Link Characteristics ACK Message is required to complete the 1724 request. Implementations are free to define their retry heuristics in 1725 event of a timeout. Issuing a Link Characteristics Request with ONLY 1726 the MAC Address TLV is a mechanism a peer MAY use to request metrics 1727 (via the Link Characteristics ACK) from its partner. 1729 To construct a Link Characteristics Request message, the initial TLV 1730 type value is set to DLEP_NEIGHBOR_LINK_CHAR_REQ (value TBD). 1731 Following the signal TLV is the mandatory Data Item TLV: 1733 MAC Address data item TLV 1735 After placing the mandatory data item TLV into the packet, the 1736 implementation would place any supported OPTIONAL data item TLVs. 1737 Possible OPTIONAL data item TLVs are: 1739 Current Data Rate - If present, this value represents the NEW (or 1740 unchanged, if the request is denied) Current 1741 Data Rate in bits per second (bps). 1743 Latency - If present, this value represents the maximum 1744 desired latency (e.g., it is a not-to-exceed 1745 value) in milliseconds on the link. 1747 25. Link Characteristics ACK Message 1748 The LInk Characteristics ACK message is an OPTIONAL message, and is 1749 sent by modems supporting it to the router letting the router know 1750 the success or failure of a requested change in link characteristics. 1751 The Link Characteristics ACK message SHOULD contain a complete set 1752 of metric data item TLVs. It MUST contain the same TLV types as the 1753 request. The values in the metric data item TLVs in the Link 1754 Characteristics ACK message MUST reflect the link characteristics 1755 after the request has been processed. 1757 To construct a Link Characteristics Request ACK message, the initial 1758 TLV type value is set to DLEP_NEIGHBOR_LINK_CHAR_ACK (value TBD). 1759 Following the signal TLV is the mandatory Data Item TLV: 1761 MAC Address data item TLV 1763 After placing the mandatory data item TLV into the packet, the 1764 implementation would place any supported OPTIONAL data item TLVs. 1765 Possible OPTIONAL data item TLVs are: 1767 Current Data Rate - If present, this value represents the requested 1768 data rate in bits per second (bps). 1770 Latency - If present, this value represents the NEW 1771 maximum latency (or unchanged, if the request 1772 is denied), expressed in milliseconds, on the 1773 link. 1775 26. Security Considerations 1777 The protocol does not contain any mechanisms for security (e.g. 1778 authentication or encryption). The protocol assumes that any security 1779 would be implemented in the underlying transport (for example, by use 1780 of DTLS or some other mechanism), and is therefore outside the scope 1781 of this document. 1783 27. IANA Considerations 1785 This section specifies requests to IANA. 1787 27.1 Registrations 1789 This specification defines: 1791 o A new repository for DLEP signals, with fifteen values currently 1792 assigned. 1794 o Reservation of numbering space for Experimental DLEP signals. 1796 o A new repository for DLEP Data Items, with twenty-one values 1797 currently assigned. 1799 o Reservation of numbering space in the Data Items repository for 1800 experimental data items. 1802 o A request for allocation of a well-known port for DLEP 1803 communication. 1805 o A request for allocation of a multicast address for DLEP 1806 discovery. 1808 27.2 Expert Review: Evaluation Guidelines 1810 No additional guidelines for expert review are anticipated. 1812 27.3 Signal (Message) TLV Type Registration 1814 A new repository must be created with the values of the DLEP signals. 1815 Valid signals are: 1817 o Peer Discovery 1818 o Peer Offer 1819 o Peer Offer ACK 1820 o Peer Update 1821 o Peer Update ACK 1822 o Peer Termination 1823 o Peer Termination ACK 1824 o Neighbor Up 1825 o Neighbor Up ACK 1826 o Neighbor Down 1827 o Neighbor Down ACK 1828 o Neighbor Update 1829 o Heartbeat 1830 o Link Characteristics Request 1831 o Link Characteristics ACK 1833 It is also requested that the repository contain space for 1834 experimental signal types. 1836 27.4 DLEP Data Item Registrations 1838 A new repository for DLEP Data Items must be created. Valid Data 1839 Items are: 1841 o DLEP Version 1842 o Peer Type 1843 o MAC Address 1844 o IPv4 Address 1845 o IPv6 Address 1846 o Maximum Data Rate (Receive) 1847 o Maximum Data Rate (Transmit) 1848 o Current Data Rate (Receive) 1849 o Current Data Rate (Transmit) 1850 o Latency 1851 o Expected Forwarding Time 1852 o Resources (Receive) 1853 o Resources (Transmit) 1854 o Relative Link Quality (Receive) 1855 o Relative Link Quality (Transmit) 1856 o Status 1857 o Heartbeat Interval/Threshold 1858 o Link Characteristics ACK Timer 1859 o Credit Window Status 1860 o Credit Grant 1861 o Credit Request 1863 It is also requested that the registry allocation contain space for 1864 experimental data items. 1866 27.5 DLEP Well-known Port 1868 It is requested that IANA allocate a well-known port number for DLEP 1869 communication. 1871 27.6 DLEP Multicast Address 1873 It is requested that IANA allocate a multicast address for DLEP 1874 discovery messages. 1876 30. Appendix A. 1878 30.1 Peer Level Message Flows 1880 30.1.1 Modem Device Restarts Discovery 1882 Router Modem Message Description 1883 ==================================================================== 1885 <-------Peer Discovery--------- Modem initiates discovery 1886 ---------Peer Offer-----------> Router detects a problem, sends 1887 w/ Non-zero Status TLV Peer Offer w/Status TLV indicating 1888 the error. 1890 Modem accepts failure, restarts 1891 discovery process. 1893 <-------Peer Discovery--------- Modem initiates discovery 1895 ---------Peer Offer-----------> Router accepts, sends Peer Offer 1896 w/ Zero Status TLV w/ Status TLV indicating success. 1898 Discovery completed. 1900 30.1.2 Modem Device Detects Peer Offer Timeout 1902 Router Modem Message Description 1903 ==================================================================== 1905 <-------Peer Discovery--------- Modem initiates discovery, starts 1906 a guard timer. 1908 Modem guard timer expires. Modem 1909 restarts discovery process. 1911 <-------Peer Discovery--------- Modem initiates discovery, starts 1912 a guard timer. 1914 ---------Peer Offer-----------> Router accepts, sends Peer Offer 1915 w/ Zero Status TLV w/ Status TLV indicating success. 1917 Discovery completed. 1919 30.1.3 Router Peer Offer Lost 1921 Router Modem Message Description 1922 ==================================================================== 1924 <-------Peer Discovery--------- Modem initiates discovery, starts 1925 a guard timer. 1927 ---------Peer Offer-------|| Router offers availability 1929 Modem times out on Peer Offer, 1930 restarts discovery process. 1932 <-------Peer Discovery--------- Modem initiates discovery 1934 ---------Peer Offer-----------> Router detects subsequent 1935 discovery, internally terminates 1936 the previous, accepts the new 1937 association, sends Peer Offer 1938 w/Status TLV indicating success. 1940 Discovery completed. 1942 30.1.4 Discovery Success 1944 Router Modem Message Description 1945 ==================================================================== 1947 <-------Peer Discovery--------- Modem initiates discovery 1949 ---------Peer Offer-----------> Router offers availability 1951 -------Peer Heartbeat---------> 1953 <-------Peer Heartbeat--------- 1955 -------Peer Heartbeat---------> 1957 <==============================> Neighbor Sessions 1959 <-------Peer Heartbeat--------- 1961 -------Peer Heartbeat---------> 1963 --------Peer Term Req---------> Terminate Request 1965 <--------Peer Term Res--------- Terminate Response 1967 30.1.5 Router Detects a Heartbeat timeout 1969 Router Modem Message Description 1970 ==================================================================== 1972 <-------Peer Heartbeat--------- 1974 -------Peer Heartbeat---------> 1976 ||---Peer Heartbeat--------- 1978 ~ ~ ~ ~ ~ ~ ~ 1980 -------Peer Heartbeat---------> 1982 ||---Peer Heartbeat--------- 1983 Router Heartbeat Timer expires, 1984 detects missing heartbeats. Router 1985 takes down all neighbor sessions 1986 and terminates the Peer 1987 association. 1989 ------Peer Terminate ---------> Peer Terminate Request 1991 Modem takes down all neighbor 1992 sessions, then acknowledges the 1993 Peer Terminate 1995 <----Peer Terminate ACK--------- Peer Terminate ACK 1997 30.1.6 Modem Detects a Heartbeat timeout 1999 Router Modem Message Description 2000 ==================================================================== 2002 <-------Peer Heartbeat--------- 2004 -------Peer Heartbeat------|| 2006 <-------Peer Heartbeat--------- 2008 ~ ~ ~ ~ ~ ~ ~ 2010 -------Peer Heartbeat------|| 2012 <-------Peer Heartbeat--------- 2013 Modem Heartbeat Timer expires, 2014 detects missing heartbeats. Modem 2015 takes down all neighbor sessions 2017 <-------Peer Terminate-------- Peer Terminate Request 2019 Router takes down all neighbor 2020 sessions, then acknowledges the 2021 Peer Terminate 2023 ------Peer Terminate ACK-----> Peer Terminate ACK 2025 30.1.7 Peer Terminate (from Modem) Lost 2027 Router Modem Message Description 2028 ==================================================================== 2030 ||------Peer Terminate-------- Modem Peer Terminate Request 2032 Router Heartbeat times out, 2033 terminates association. 2035 --------Peer Terminate-------> Router Peer Terminate 2037 <-----Peer Terminate ACK------ Modem sends Peer Terminate ACK 2039 30.1.8 Peer Terminate (from Router) Lost 2041 Router Modem Message Description 2042 ==================================================================== 2044 -------Peer Terminate--------> Router Peer Terminate Request 2046 Modem HB times out, 2047 terminates association. 2049 <------Peer Terminate-------- Modem Peer Terminate 2051 ------Peer Terminate ACK-----> Peer Terminate ACK 2053 30.2 Neighbor Specific Message Flows 2054 30.2.1 Modem Neighbor Up Lost 2056 Router Modem Message Description 2057 ==================================================================== 2059 ||-----Neighbor Up ------------ Modem sends Neighbor Up 2061 Modem timesout on ACK 2063 <------Neighbor Up ------------ Modem sends Neighbor Up 2065 ------Neighbor Up ACK---------> Router accepts the neighbor 2066 session 2068 <------Neighbor Update--------- Modem Neighbor Metrics 2069 . . . . . . . . 2070 <------Neighbor Update--------- Modem Neighbor Metrics 2072 30.2.2 Router Detects Duplicate Neighbor Ups 2074 Router Modem Message Description 2075 ==================================================================== 2077 <------Neighbor Up ------------ Modem sends Neighbor Up 2079 ------Neighbor Up ACK-------|| Router accepts the neighbor 2080 session 2082 Modem timesout on ACK 2084 <------Neighbor Up ------------ Modem resends Neighbor Up 2086 Router detects duplicate Neighbor, 2087 takes down the previous, accepts 2088 the new Neighbor. 2090 ------Neighbor Up ACK---------> Router accepts the neighbor 2091 session 2093 <------Neighbor Update--------- Modem Neighbor Metrics 2094 . . . . . . . . 2095 <------Neighbor Update--------- Modem Neighbor Metrics 2097 30.2.3 Neighbor Up, No Layer 3 Addresses 2099 Router Modem Message Description 2100 ==================================================================== 2102 <------Neighbor Up ------------ Modem sends Neighbor Up 2104 ------Neighbor Up ACK---------> Router accepts the neighbor 2105 session 2107 Router ARPs for IPv4 if defined. 2108 Router drives ND for IPv6 if 2109 defined. 2111 <------Neighbor Update--------- Modem Neighbor Metrics 2112 . . . . . . . . 2113 <------Neighbor Update--------- Modem Neighbor Metrics 2115 30.2.4 Neighbor Up with IPv4, No IPv6 2117 Router Modem Message Description 2118 ==================================================================== 2120 <------Neighbor Up ------------ Modem sends Neighbor Up with 2121 the IPv4 TLV 2123 ------Neighbor Up ACK---------> Router accepts the neighbor 2124 session 2126 Router drives ND for IPv6 if 2127 defined. 2129 <------Neighbor Update--------- Modem Neighbor Metrics 2130 . . . . . . . . 2131 <------Neighbor Update--------- Modem Neighbor Metrics 2133 30.2.5 Neighbor Up with IPv4 and IPv6 2135 Router Modem Message Description 2136 ==================================================================== 2138 <------Neighbor Up ------------ Modem sends Neighbor Up with 2139 the IPv4 and IPv6 TLVs 2141 ------Neighbor Up ACK---------> Router accepts the neighbor 2142 session 2144 <------Neighbor Update--------- Modem Neighbor Metrics 2145 . . . . . . . . 2147 30.2.6 Neighbor Session Success 2149 Router Modem Message Description 2150 ==================================================================== 2152 ---------Peer Offer-----------> Router offers availability 2154 -------Peer Heartbeat---------> 2156 <------Neighbor Up ----------- Modem 2158 ------Neighbor Up ACK--------> Router 2160 <------Neighbor Update--------- Modem 2161 . . . . . . . . 2162 <------Neighbor Update--------- Modem 2164 Modem initiates the terminate 2166 <------Neighbor Down ---------- Modem 2168 ------Neighbor Down ACK-------> Router 2170 or 2172 Router initiates the terminate 2174 ------Neighbor Down ----------> Router 2176 <------Neighbor Down ACK------- Modem 2178 Acknowledgements 2180 The authors would like to acknowledge the influence and contributions 2181 of Chris Olsen, Teco Boot, Subir Das, Jaewon Kang, Vikram Kaul, Rick 2182 Taylor, John Dowdell, Nelson Powell, Bow-Nan Cheng, and Henning 2183 Rogge. 2185 Normative References 2187 [RFC5578] Berry, B., Ed., "PPPoE with Credit Flow and Metrics", 2188 RFC 5578, February 2010. 2190 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2192 Informative References 2194 [DTLS] Rescorla, E., Ed,. "Datagram Transport Layer Security", 2195 RFC 4347, April 2006. 2197 Author's Addresses 2199 Stan Ratliff 2200 Cisco 2201 170 West Tasman Drive 2202 San Jose, CA 95134 2203 USA 2204 EMail: sratliff@cisco.com 2206 Bo Berry 2207 Cisco 2208 170 West Tasman Drive 2209 San Jose, CA 95134 2210 USA 2211 EMail: boberry@cisco.com 2213 Greg Harrison 2214 Cisco 2215 170 West Tasman Drive 2216 San Jose, CA 95134 2217 USA 2218 EMail: greharri@cisco.com 2220 Shawn Jury 2221 NetApp 2222 7301 Kit Creek Road, Building 2 2223 Research Triangle Park, NC 27709 2224 USA 2225 Email: shawn.jury@netapp.com 2227 Darryl Satterwhite 2228 Broadcom 2229 USA 2230 Email: dsatterw@broadcom.com