idnits 2.17.1 draft-ietf-manet-dlep-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 246 has weird spacing: '... Shared o ...' == Line 247 has weird spacing: '... Medium o...' -- The document date (August 30, 2012) is 4255 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: 1 error (**), 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 D. Satterwhite 6 Expires: March 3, 2013 Cisco Systems 7 S. Jury 8 NetApp 9 August 30, 2012 11 Dynamic Link Exchange Protocol (DLEP) 12 draft-ietf-manet-dlep-03 14 Abstract 16 When routing devices rely on modems to effect communications over 17 wireless links, they need timely and accurate knowledge of the 18 characteristics of the link (speed, state, etc.) in order to make 19 forwarding decisions. In mobile or other environments where these 20 characteristics change frequently, manual configurations or the 21 inference of state through routing or transport protocols does not 22 allow the router to make the best decisions. A bidirectional, event- 23 driven communication channel between the router and the modem is 24 necessary. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on February 21, 2013. 49 Copyright Notice 51 Copyright (c) 2012 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 68 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 3. Credits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 4. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 5. Extensions to DLEP . . . . . . . . . . . . . . . . . . . . . . 10 72 6. Normal Session Flow . . . . . . . . . . . . . . . . . . . . . . 10 73 7. Mandatory Signals and Data Items . . . . . . . . . . . . . . . 12 74 8. Generic DLEP Packet Definition . . . . . . . . . . . . . . . . 13 75 9. DLEP Data Items . . . . . . . . . . . . . . . . . . . . . . . . 13 76 9.1 Identification . . . . . . . . . . . . . . . . . . . . . . 14 77 9.2 DLEP Version . . . . . . . . . . . . . . . . . . . . . . . 15 78 9.3 Peer Type . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 9.4 MAC Address . . . . . . . . . . . . . . . . . . . . . . . . 16 80 9.5 IPv4 Address . . . . . . . . . . . . . . . . . . . . . . . 17 81 9.6 IPv6 Address . . . . . . . . . . . . . . . . . . . . . . . 18 82 9.7 Maximum Data Rate . . . . . . . . . . . . . . . . . . . . . 18 83 9.8 Current Data Rate . . . . . . . . . . . . . . . . . . . . . 19 84 9.9 Expected Forwarding Time . . . . . . . . . . . . . . . . . 20 85 9.10 Latency . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 9.11 Resources . . . . . . . . . . . . . . . . . . . . . . . . 21 87 9.12 Relative Link Quality . . . . . . . . . . . . . . . . . . 22 88 9.13 Status . . . . . . . . . . . . . . . . . . . . . . . . . . 22 89 9.14 Heartbeat Interval/Threshold . . . . . . . . . . . . . . . 23 90 9.15 Link Characteristics ACK Timer . . . . . . . . . . . . . . 24 91 9.16 Credit Window Status . . . . . . . . . . . . . . . . . . . 24 92 9.17 Credit Grant Request . . . . . . . . . . . . . . . . . . . 25 93 9.18 Credit Request . . . . . . . . . . . . . . . . . . . . . . 26 94 10. DLEP Protocol Messages . . . . . . . . . . . . . . . . . . . . 27 95 10.1 Signal TLV Values . . . . . . . . . . . . . . . . . . . . 27 96 11. Peer Discovery Message . . . . . . . . . . . . . . . . . . . . 28 97 12. Peer Offer Message . . . . . . . . . . . . . . . . . . . . . . 28 98 13. Peer Offer ACK Message . . . . . . . . . . . . . . . . . . . . 29 99 14. Peer Update Message . . . . . . . . . . . . . . . . . . . . . 30 100 15. Peer Update ACK Message . . . . . . . . . . . . . . . . . . . 31 101 16. Peer Termination Message . . . . . . . . . . . . . . . . . . . 31 102 17. Peer Termination ACK Message . . . . . . . . . . . . . . . . . 31 103 18. Neighbor Up Message . . . . . . . . . . . . . . . . . . . . . 32 104 19. Neighbor Up ACK Message . . . . . . . . . . . . . . . . . . . 32 105 20. Neighbor Down Message . . . . . . . . . . . . . . . . . . . . 33 106 21. Neighbor Down ACK Message . . . . . . . . . . . . . . . . . . 33 107 22. Neighbor Update Message . . . . . . . . . . . . . . . . . . . 34 108 23. Heartbeat Message . . . . . . . . . . . . . . . . . . . . . . 34 109 24. Link Characteristics Request Message . . . . . . . . . . . . . 35 110 25. Link Characteristics ACK Message . . . . . . . . . . . . . . . 36 111 26. Security Considerations . . . . . . . . . . . . . . . . . . . 36 112 27. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 113 27.1 Registrations . . . . . . . . . . . . . . . . . . . . . . 36 114 27.2 Expert Review: Evaluation Guidelines . . . . . . . . . . . 37 115 27.3 Signal (Message) TLV Type Registration . . . . . . . . . . 37 116 27.4 DLEP Data Item Registrations . . . . . . . . . . . . . . . 38 117 27.5 DLEP Well-known Port . . . . . . . . . . . . . . . . . . . 38 118 27.6 DLEP Multicast Address . . . . . . . . . . . . . . . . . . 38 119 30. Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . 38 120 30.1 Peer Level Message Flows . . . . . . . . . . . . . . . . . 38 121 30.1.1 Modem Device Restarts Discovery . . . . . . . . . . . 38 122 30.1.2 Modem Device Detects Peer Offer Timeout . . . . . . . 39 123 30.1.3 Router Peer Offer Lost . . . . . . . . . . . . . . . . 40 124 30.1.4 Discovery Success . . . . . . . . . . . . . . . . . . 40 125 30.1.5 Router Detects a Heartbeat timeout . . . . . . . . . . 41 126 30.1.6 Modem Detects a Heartbeat timeout . . . . . . . . . . 41 127 30.1.7 Peer Terminate (from Modem) Lost . . . . . . . . . . . 42 128 30.1.8 Peer Terminate (from Router) Lost . . . . . . . . . . 42 129 30.2 Neighbor Specific Message Flows . . . . . . . . . . . . . 42 130 30.2.1 Modem Neighbor Up Lost . . . . . . . . . . . . . . . . 43 131 30.2.2 Router Detects Duplicate Neighbor Ups . . . . . . . . 43 132 30.2.3 Neighbor Up, No Layer 3 Addresses . . . . . . . . . . 44 133 30.2.4 Neighbor Up with IPv4, No IPv6 . . . . . . . . . . . . 44 134 30.2.5 Neighbor Up with IPv4 and IPv6 . . . . . . . . . . . . 44 135 30.2.6 Neighbor Session Success . . . . . . . . . . . . . . . 45 136 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 45 137 Normative References . . . . . . . . . . . . . . . . . . . . . . . 45 138 Informative References . . . . . . . . . . . . . . . . . . . . . . 46 139 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 141 1. Introduction 143 There exist today a collection of modem devices that control links of 144 variable bandwidth and quality. Examples of these types of links 145 include line-of-sight (LOS) radios, satellite terminals, and 146 cable/DSL modems. Fluctuations in speed and quality of these links 147 can occur due to configuration (in the case of cable/DSL modems), or 148 on a moment-to-moment basis, due to physical phenomena like multipath 149 interference, obstructions, rain fade, etc. It is also quite possible 150 that link quality and bandwidth varies with respect to individual 151 neighbors on a link, and with the type of traffic being sent. As an 152 example, consider the case of an 802.11g access point, serving 2 153 associated laptop computers. In this environment, the answer to the 154 question "What is the bandwidth on the 802.11g link?" is "It depends 155 on which associated laptop we're talking about, and on what kind of 156 traffic is being sent." While the first laptop, being physically 157 close to the access point, may have a bandwidth of 54Mbps for unicast 158 traffic, the other laptop, being relatively far away, or obstructed 159 by some object, can simultaneously have a bandwidth of only 32Mbps 160 for unicast. However, for multicast traffic sent from the access 161 point, all traffic is sent at the base transmission rate (which is 162 configurable, but depending on the model of the access point, is 163 usually 24Mbps or less). 165 In addition to utilizing variable bandwidth links, mobile networks 166 are challenged by the notion that link connectivity will come and go 167 over time. Effectively utilizing a relatively short-lived connection 168 is problematic in IP routed networks, as routing protocols tend to 169 rely on independent timers at OSI Layer 3 to maintain network 170 convergence (e.g. HELLO messages and/or recognition of DEAD routing 171 adjacencies). These short-lived connections can be better utilized 172 with an event-driven paradigm, where acquisition of a new neighbor 173 (or loss of an existing one) is signaled, as opposed to a timer- 174 driven paradigm. 176 Another complicating factor for mobile networks are the different 177 methods of physically connecting the modem devices to the router. 178 Modems can be deployed as an interface card in a router's chassis, or 179 as a standalone device connected to the router via Ethernet, USB, or 180 even a serial link. In the case of Ethernet or serial attachment, 181 with existing protocols and techniques, routing software cannot be 182 aware of convergence events occurring on the radio link (e.g. 183 acquisition or loss of a potential routing neighbor), nor can the 184 router be aware of the actual capacity of the link. This lack of 185 awareness, along with the variability in bandwidth, leads to a 186 situation where quality of service (QoS) profiles are extremely 187 difficult to establish and properly maintain. This is especially true 188 of demand-based access schemes such as Demand Assigned Multiple 189 Access (DAMA) implementations used on some satellite systems. With a 190 DAMA-based system, additional bandwidth may be available, but will 191 not be used unless the network devices emit traffic at rate higher 192 than the currently established rate. Increasing the traffic rate does 193 not guarantee additional bandwidth will be allocated; rather, it may 194 result in data loss and additional retransmissions on the link. 196 Addressing the challenges listed above, the authors have developed 197 the Data Link Exchange Protocol, or DLEP. The DLEP protocol runs 198 between a router and its attached modem devices, allowing the modem 199 to communicate link characteristics as they change, and convergence 200 events (acquisition and loss of potential routing neighbors). The 201 following diagrams are used to illustrate the scope of DLEP packets. 203 |-------Local Node-------| |-------Remote Node------| 204 | | | | 205 +--------+ +-------+ +-------+ +--------+ 206 | Router |=======| Modem |{~~~~~~~~}| Modem |=======| Router | 207 | | | Device| | Device| | | 208 +--------+ +-------+ +-------+ +--------+ 209 | | | Link | | | 210 |-DLEP--| | Protocol | |-DLEP--| 211 | | | (e.g. | | | 212 | | | 802.11) | | | 214 Figure 1: DLEP Network 216 In Figure 1, when the local modem detects the presence of a remote 217 node, it (the local modem) sends a signal to its router via the DLEP 218 protocol. Upon receipt of the signal, the local router may take 219 whatever action it deems appropriate, such as initiating discovery 220 protocols, and/or issuing HELLO messages to converge the network. On 221 a continuing, as-needed basis, the modem devices utilize DLEP to 222 report any characteristics of the link (bandwidth, latency, etc) that 223 have changed. DLEP is independent of the link type and topology 224 supported by the modem. 226 Figure 2 shows how DLEP can support a configuration where routers are 227 connected with different link types. In this example, Modem A 228 implements a point-to-point link, and Modem B is connected via a 229 shared medium. In both cases, the DLEP protocol is used to report the 230 characteristics of the link (bandwidth, latency, etc.) to routers. 231 The modem is also able to use the DLEP session to notify the router 232 when the remote node is lost, shortening the time required to re- 233 converge the network. 235 +--------+ +--------+ 236 +----+ Modem A| | Modem A+---+ 237 | | Device | <===== // ======> | Device | | 238 | +--------+ P-2-P Link +--------+ | 239 +---+----+ +---+----+ 240 | Router | | Router | 241 | | | | 242 +---+----+ +---+----+ 243 | +--------+ +--------+ | 244 +-----+ Modem B| | Modem B| | 245 | Device | o o o o o o o o | Device +--+ 246 +--------+ o Shared o +--------+ 247 o Medium o 248 o o 249 o o 250 o o 251 o 252 +--------+ 253 | Modem B| 254 | Device | 255 +---+----+ 256 | 257 | 258 +---+----+ 259 | Router | 260 | | 261 +--------+ 263 Figure 2: DLEP Network with Multiple Modem Devices 265 DLEP defines a set of logical signals used by modems and their 266 attached routers. The signals are used to communicate events that 267 occur on the physical link(s) managed by the modem: for example, a 268 remote node entering or leaving the network, or that the link has 269 changed. Associated with these signals are a set of data items - 270 information that describes the remote node (e.g., address 271 information), and/or the characteristics of the link to the remote 272 node. 274 The protocol is defined as a collection of type-length-value (TLV) 275 based messages, specifying the signals that are exchanged between a 276 router and a modem, and the data items associated with the signal. 277 This document specifies transport of DLEP signals and data items via 278 the UDP transport. Other transports for the protocol are possible, 279 but are outside the scope of this document. 281 DLEP signals are further defined as mandatory or optional. Signals 282 will additionally have mandatory and optional data items. 283 Implementations MUST support all mandatory signals and their 284 mandatory data items to be considered compliant. Implementations MAY 285 also support some, or all, of the optional signals and data items. 287 DLEP uses a session-oriented paradigm between the modem device and 288 its associated router. If multiple modem devices are attached to a 289 router (as in Figure 2), a separate DLEP session MUST exist for each 290 modem. If a modem device supports multiple connections to a router 291 (via multiple logical or physical interfaces), or supports 292 connections to multiple routers, a separate DLEP session MUST exist 293 for each connection. This router/modem session provides a carrier for 294 information exchange concerning neighbors (remote nodes) that are 295 accessible via the modem device. As such, all of the neighbor-level 296 exchanges in DLEP can be envisioned as building an information base 297 concerning the remote nodes, and the link characteristics to those 298 nodes. 300 Multicast traffic is handled in IP networks by deriving a Layer 2 MAC 301 address based on the Layer 3 address. Leveraging on this scheme, 302 Multicast traffic is supported in DLEP simply by treating the derived 303 MAC address as any other destination in the network. To support these 304 logical destinations, one of the DLEP participants (typically, the 305 router) informs the other as to the existence of the logical 306 neighbor. The modem, once it is aware of the existence of this 307 logical neighbor, reports link characteristics just as it would for 308 any other destination in the network. The specific algorithms a modem 309 would use to report metrics on multicast (or logical) destinations is 310 outside the scope of this specification, and is left to specific 311 implementations to decide. 313 1.1 Requirements 315 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 316 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 317 document are to be interpreted as described in BCP 14, RFC 2119 318 [RFC2119]. 320 2. Assumptions 322 Routers and modems that exist as part of the same node (e.g., that 323 are locally connected) can utilize a discovery technique to locate 324 each other, thus avoiding a-priori configuration. Either entity (the 325 router or the modem) can initiate the discovery process. In cases 326 where both entities initiate discovery, a race condition can occur. 327 When this race condition occurs, the router MUST cease its active 328 discovery, and respond to the modem's request. 330 DLEP utilizes a session-oriented paradigm. A router and modem form a 331 session by completing the discovery process. This router-modem 332 session persists unless or until it either (1) times out, based on 333 the timeout values supplied, or (2) is explicitly torn down by one of 334 the participants. Note that use of timers in DLEP is OPTIONAL; that 335 is, implementations can choose to run with no timers (or effectively, 336 timers set to an infinite value). 338 DLEP assumes that participating modems, and their physical links, act 339 as a transparent bridge. Specifically, the assumption is that the 340 destination MAC address for data traffic in any frame emitted by the 341 router should be the MAC address of a device in the remote node. DLEP 342 also assumes that MAC addresses are unique within the context of the 343 router-modem session. 345 This document refers to a remote node as a "Neighbor". Neighbors can 346 be identified by either the router or the modem, and represent a 347 specific destination (e.g., an address) that exists on the link(s) 348 managed by the modem. Examples of a destination include a MAC 349 address, a unicast Layer 3 address, or a multicast Layer 3 address. 350 As "neighbors" are discovered, DLEP routers and modems build an 351 information base on destinations accessible via the modem. Changes in 352 link characteristics MAY then be reported as being "modem-wide" 353 (effecting ALL neighbors accessed via the modem) or MAY be neighbor 354 (destination) specific. 356 The DLEP signals concerning neighbors thus become the way for routers 357 and modems to maintain, and notify each other about, an information 358 base representing the physical and logical (e.g., multicast) 359 destinations accessible via the modem device. The information base 360 would contain addressing information (e.g., MAC address, and 361 OPTIONALLY, Layer 3 addresses), link characteristics (metrics), and 362 OPTIONALLY, flow control information (credits). 364 DLEP assumes that security on the session (e.g. authentication of 365 session partners, encryption of traffic, or both) is dealt with by 366 the underlying transport mechanism (e.g., by using a transport such 367 as DTLS [DTLS]). 369 Sequence Numbers for DLEP messages start at 0 and are incremented by 370 one for each original and retransmitted message. The unsigned 16-bit 371 Sequence Number rolls over at 65535 to 0. Sequence Numbers are unique 372 within the context of a DLEP session. Sequence numbers are used in 373 DLEP to correlate a response to a request. 375 This document specifies an implementation of the DLEP signals and 376 data items running over the UDP transport, utilizing a well-known UDP 377 Port number. It is assumed that DLEP running over other transport 378 mechanisms would be documented separately. 380 3. Credits 382 DLEP includes an OPTIONAL credit-windowing scheme analogous to the 383 one documented in [RFC5578]. In this scheme, traffic between the 384 router and modem is treated as two unidirectional windows. This 385 document identifies these windows as the "Modem Receive Window", or 386 MRW, and the "Router Receive Window", or RRW. 388 If credits are used, they MUST be granted by the receiver on a given 389 window - that is, on the "Modem Receive Window" (MRW), the modem is 390 responsible for granting credits to the router, allowing it (the 391 router) to send data to the modem. Likewise, the router is 392 responsible for granting credits on the RRW, which allows the modem 393 to send data to the router. 395 DLEP expresses all credit data in number of octets. The total number 396 of credits on a window, and the increment to add to a grant, are 397 always expressed as a 64-bit unsigned quantity. 399 If used, credits are managed on a neighbor-specific basis; that is, 400 separate credit counts are maintained for each neighbor requiring the 401 service. Credits do not apply to the DLEP session that exists between 402 routers and modems. 404 4. Metrics 406 DLEP includes the ability for the router and modem to communicate 407 metrics that reflect the characteristics (e.g. bandwidth, latency) of 408 the variable-quality link in use. As mentioned in the introduction 409 section of this document, metrics have to be used within a context - 410 for example, metrics to a unicast address in the network. DLEP allows 411 for metrics to be sent within two contexts - metrics for a specific 412 neighbor (those for a given destination within the network), and 413 "modem-wide" (those that apply to all destinations accessed via the 414 modem). Metrics supplied on DLEP Peer signals are, by definition, 415 modem-wide; metrics supplied on Neighbor signals are, by definition, 416 used for the specific neighbor only. 418 It is left to implementations to choose sensible default values based 419 on their specific characteristics. Additionally, this mechanism 420 (either at a modem-wide or specific neighbor context) MAY be used to 421 report non-changing, or static, metrics. Modems having static link 422 metric characteristics MAY report metrics only once for a given 423 neighbor (or once on a modem-wide basis, if all connections via the 424 modem are of this static nature). 426 The approach of allowing for different contexts for metric data 427 increases both the flexibility and the complexity of using metric 428 data. This document details the mechanism whereby the data is 429 transmitted, however, the specific algorithms (precedence, etc) for 430 utilizing the dual-context metrics is out of scope and not addressed 431 by this document. 433 5. Extensions to DLEP 435 While this draft represents the best efforts of the co-authors, and 436 the working group, to be functionally complete, it is recognized that 437 extensions to DLEP will in all likelihood be necessary as more link 438 types are utilized. To allow for future innovation, the draft 439 allocates numbering space for experimental implementations of both 440 signals and data items. 442 DLEP implementations MUST be capable of parsing and acting on the 443 mandatory signals and data items as documented in this specification. 444 DLEP signals/data items that are optional, or are in the experimental 445 numbering range SHOULD be silently dropped by an implementation if 446 they are not understood. 448 The intent of the optional signals and data items, as well as the 449 experimental numbering space, is to allow for further development of 450 DLEP protocol features and function. Having experimental space 451 reserved for both signals and data items gives maximum flexibility 452 for extending the protocol as conditions warrant. For example, 453 experimental data items could be used by implementations to send 454 additional metrics. A combination of experimental signals, and 455 associated data items, could be used to implement new flow control 456 schemes. If subsequent research and development define new features 457 and function, then it should be standardized either as an update to 458 this document, or as an additional stand-alone specification. 460 6. Normal Session Flow 462 At the start of a run, DLEP implementations (both router and modem) 463 initialize the communications path. In a UDP implementation, this 464 includes opening a socket and binding to the well-known port address 465 (TBD). Once the communications path is established, an implementation 466 would either, depending on configuration, proceed to periodically 467 issue a "Peer Discovery" message. The Peer Discovery MAY be sent 468 either via the multicast address allocated for DLEP (TBD), or via a 469 unicast address, or drop into a "passive receive" mode, waiting on 470 receipt of a Peer Discovery. 472 Both modem and router initialize in a "discovery" state. Either the 473 modem, the router, or both, will then issue a "Peer Discovery" 474 signal. The Peer Discovery signal MAY be issued to a unicast address 475 (if a-priori knowledge of the address exists), or to the multicast 476 address TBD. 478 The receiver of a Peer Discovery message responds with a "Peer Offer" 479 signal to indicate readiness to participate in the DLEP session. The 480 receiver of a Peer Offer message responds with a "Peer Offer ACK" 481 message, completing discovery. While the Peer Discovery message MAY 482 be sent to the DLEP multicast address (TBD), the Peer Offer, and all 483 subsequent traffic, is sent to the unicast address that originated 484 the Peer Discovery. Once the Peer Offer signal is acknowledged, both 485 participants (router and modem) transition to the "in session" state, 486 creating a logical, stateful session between the modem and the 487 router. Subsequent DLEP signals are then processed within the context 488 of this router/modem session. DLEP partners use these signals to 489 build their respective information bases regarding destinations that 490 are accessible via the modem, and link characteristics associated 491 with those destinations. 493 The "in session" state created by the discovery signals is maintained 494 until one of the following conditions occur: 496 o The session is explicitly terminated (using Peer Termination), or 497 o The session times out, based on supplied timeout values. 499 In order to maintain the session between router and modem, OPTIONAL 500 periodic "Heartbeat" messages MAY be exchanged. These messages are 501 intended to keep the session alive, and to verify bidirectional 502 connectivity between the two participants. DLEP also provides for an 503 OPTIONAL Peer Update message, intended to communicate some change in 504 status (e.g., a change of layer 3 address parameters, or a modem-wide 505 link change). 507 In addition to the messages above, the participants will transmit 508 DLEP messages concerning destinations in the network. These messages 509 trigger creation/maintenance/deletion of "neighbors" in the 510 information base of the recipient. For example, a modem will inform 511 its attached router of the presence of a new destination via the 512 "Neighbor Up" signal. Receipt of a Neighbor Up causes the router to 513 allocate the necessary resources, creating an entry in the 514 information base with the specifics (e.g., MAC Address, Latency, Data 515 Rate, etc) of the neighbor. The loss of a destination is communicated 516 via the "Neighbor Down" signal, and changes in status to the 517 destination (e.g. varying link quality, or addressing changes) are 518 communicated via the "Neighbor Update" signal. The information on a 519 given neighbor will persist in the router's information base until 520 (1) a "Neighbor Down" is received, indicating that the modem has lost 521 contact with the remote node, or (2) the router/modem session 522 terminates, indicating that the router has lost contact with its own 523 local modem. 525 Again, metrics can be expressed within the context of a specific 526 neighbor via the Neighbor Update message, or on a modem-wide basis 527 via the Peer Update message. In cases where metrics are provided on 528 the router/modem session, the receiver MUST propagate the metrics to 529 all neighbors in its information base that are accessed via the 530 originator. A DLEP participant MAY send metrics both in a 531 router/modem session context (via the Peer Update message) and a 532 specific neighbor context (via Neighbor Update) at any time. The 533 heuristics for applying received metrics is left to implementations. 535 In addition to receiving metrics about the link, DLEP provides an 536 OPTIONAL signal allowing a router to request a different amount of 537 bandwidth, or latency, from the modem. This signal is referred to as 538 the Link Characteristics Message, and gives the router the ability to 539 deal with requisite increases (or decreases) of allocated 540 bandwidth/latency in demand-based schemes in a more deterministic 541 manner. 543 7. Mandatory Signals and Data Items 545 The following DLEP signals are considered core to the specification; 546 implementations MUST support these signals, and the associated data 547 items, in order to be considered compliant: 549 Signal Data Items 550 ====== ========== 551 Attached Peer Discovery Identification 553 Peer Offer Identification 555 Peer Offer ACK Status 557 Peer Termination Identification 559 Peer Termination ACK Status 561 Neighbor Up Identification 562 MAC Address 563 Maximum Data Rate 564 Current Data Rate 565 Latency 566 Resources 567 Relative Link Quality 569 Neighbor Update Identification 570 MAC Address 571 Maximum Data Rate 572 Current Data Rate 573 Latency 574 Resources 575 Relative Link Quality 577 Neighbor Down Identification 578 MAC Address 580 All other DLEP signals and data items are OPTIONAL. Implementations 581 MAY choose to provide them. Implementations that do not support 582 optional signals and data items SHOULD parse, and silently drop, all 583 unsupported signals and/or data items. 585 8. Generic DLEP Packet Definition 587 The Generic DLEP Packet consists of a sequence of TLVs. The first TLV 588 represents the signal being communicated (e.g., a "Neighbor Up", or a 589 "Peer Offer"). Subsequent TLVs contain the data items pertinent to 590 the signal (e.g., Maximum Data Rate, or Latency, etc). 592 The Generic DLEP Packet Definition contains the following fields: 594 0 1 2 3 595 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 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 |Signal TLV Type | Length | DLEP data items... | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 Signal - One of the DLEP Signal TLV type values 601 defined in this document. 603 Length - The length of all of the DLEP data items 604 associated with this signal. 606 DLEP data items - One or more data items, encoded in TLVs, 607 as defined in this document. 609 9. DLEP Data Items 611 As mentioned earlier, DLEP protocol messages are transported as a 612 collection of TLVs. The first TLV present in a DLEP message MUST be 613 one of the Signal TLVs, documented in section [INSERT REFERENCE 614 HERE]. The signals are followed by one or more data items, indicating 615 the specific changes that need to be instantiated in the receiver's 616 information base. 618 Valid DLEP Data Items are: 620 TLV TLV 621 Value Description 622 ========================================= 623 TBD Identification 624 TBD DLEP Version 625 TBD Peer Type 626 TBD IPv4 Address 627 TBD IPv6 Address 628 TBD Maximum Data Rate (MDR) 629 TBD Current Data Rate (CDR) 630 TBD Latency 631 TBD Resources 632 TBD Expected Forwarding Time (EFT) 633 TBD Relative Link Quality (RLQ) 634 TBD Status 635 TBD Heartbeat Interval/Threshold 636 TBD Neighbor down ACK timer 637 TBD Link Characteristics ACK timer 638 TBD Credit Window Status 639 TBD Credit Grant 640 TBD Credit Request 642 DLEP data item TLVs contain the following fields: 644 0 1 2 3 645 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 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | TLV Type | Length | Value... | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 TLV Type - An 8-bit unsigned integer field specifying the data 651 item being sent. 653 Length - An 8-bit length of the value field of the data item 655 Value - A field of length which contains data 656 specific to a particular data item. 658 9.1 Identification 660 This data item MUST exist in all DLEP messages, and MUST be the first 661 data item of the message (e.g., it MUST immediately follow the signal 662 TLV). Further, there MUST be ONLY one Identification data item in a 663 DLEP message. The data item contains identification information used 664 to establish the proper context (e.g., the router/modem session) for 665 processing DLEP protocol messages. 667 The format of the Identification Data Item is: 669 0 1 2 3 670 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 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 |TLV Type = TBD | Length = 8 | Router ID | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | Router ID | Modem ID | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | Modem ID | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 TLV Type - Value TBD 681 Length - 8 683 Router ID - Indicates the Router ID of the DLEP session. 685 Modem ID - indicates the Modem ID of the DLEP session. 687 During transmission of a DLEP Peer Discovery signal, the transmitter 688 MUST set its ID to a 32-bit quantity that will be used to uniquely 689 identify this session from the transmitter's perspective. The other 690 ID value MUST be set the to '0'. When responding to the Peer 691 Discovery signal (via the Peer Offer signal), the transmitter MUST 692 echo any received ID value, and MUST supply its own unique 32-bit 693 quantity to identify the session from its perspective. After the Peer 694 Discovery/Peer Offer exchange, subsequent signals on this DLEP 695 session MUST contain the ID values obtained from the Peer 696 Discovery/Peer Offer sequence. 698 9.2 DLEP Version 700 The DLEP Version TLV is an OPTIONAL TLV in both the Peer Discovery 701 and Peer Offer messages. The Version TLV is used to indicate the 702 version of the protocol running in the originator. A participant MAY 703 use this information to decide if the potential session partner is 704 running at a supported level. 706 The DLEP Version TLV contains the following fields: 708 0 1 2 3 709 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 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 |TLV Type =TBD |Length=4 | Major Version | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | Minor Version | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 TLV Type - TBD 717 Length - Length is 4 719 Major Version - Major version of the modem or router protocol. 721 Minor Version - Minor version of the modem or router protocol. 723 Support of this draft is indicated by setting the Major Version 724 to '1', and the Minor Version to '3' (e.g. Version 1.3). 726 9.3 Peer Type 728 The Peer Type TLV is an OPTIONAL TLV in both the Peer Discovery and 729 Peer Offer messages. The Peer Type TLV is used by the router and 730 modem to give additional information as to its type. The peer type is 731 a string and is envisioned to be used for informational purposes 732 (e.g. as output in a display command). 734 The Peer Type TLV contains the following fields: 736 0 1 2 3 737 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 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 |TLV Type =TBD |Length= peer |Peer Type String | 740 | |type string len|Max Len = 80 | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 TLV Type - TBD 745 Length - Length of peer type string (80 octets maximum). 747 Peer Type String - Non-Null terminated string, maximum length of 80 748 octets. For example, a satellite modem might set 749 this variable to 'Satellite terminal'. 751 9.4 MAC Address 753 The MAC address TLV MUST appear in all neighbor-oriented signals 754 (e.g. Neighbor Up, Neighbor Up ACK, Neighbor Down, Neighbor Down ACK, 755 Neighbor Update, Link Characteristics Request, and Link 756 Characteristics ACK). The MAC Address TLV contains the address of the 757 destination on the remote node. The MAC address MAY be either a 758 physical or a virtual destination. Examples of a virtual destination 759 would be a multicast MAC address, or the broadcast MAC 760 (0xFFFFFFFFFFFF). 762 0 1 2 3 763 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 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 |TLV Type =TBD |Length = 6 | MAC Address | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | MAC Address | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 TLV Type - TBD 773 Length - 6 775 MAC Address - MAC Address of the destination (either physical or 776 virtual). 778 9.5 IPv4 Address 780 The IPv4 Address TLV is an OPTIONAL TLV. If supported, it MAY appear 781 in Neighbor Up, Neighbor Update, and Peer Update messages. When 782 included in Neighbor messages, the IPv4 Address TLV contains the IPv4 783 address of the neighbor, as well as a subnet mask value. In the Peer 784 Update message, it contains the IPv4 address of the originator of the 785 message. In either case, the TLV also contains an indication of 786 whether this is a new or existing address, or is a deletion of a 787 previously known address. 789 The IPv4 Address TLV contains the following fields: 791 0 1 2 3 792 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 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 |TLV Type =TBD |Length = 6 | Add/Drop | IPv4 Address | 795 | | | Indicator | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | IPv4 Address | Subnet Mask | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 TLV Type - TBD 802 Length - 6 804 Add/Drop - Value indicating whether this is a new or existing 805 IPv4 address 807 IPv4 Address - The IPv4 address of the neighbor or peer. 809 Subnet Mask - A subnet mask (0-32) to be applied to the IPv4 810 address. 812 9.6 IPv6 Address 814 The IPv6 Address TLV is an OPTIONAL TLV. If supported, it MAY be used 815 in the Neighbor Up, Neighbor Update, Peer Discovery, and Peer Update 816 Messages. When included in Neighbor messages, this data item contains 817 the IPv6 address of the neighbor. In the Peer Discovery and Peer 818 Update, it contains the IPv6 address of the originating peer. In 819 either case, the data item also contains an indication of whether 820 this is a new or existing address, or is a deletion of a previously 821 known address, as well as a subnet mask. 823 The IPv6 Address TLV contains the following fields: 825 0 1 2 3 826 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 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 |TLV Type =TBD |Length = 18 | Add/Drop | IPv6 Address | 829 | | | Indicator | | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | IPv6 Address | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | IPv6 Address | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | IPv6 Address | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | IPv6 Address | Subnet Mask | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 TLV Type - TBD 842 Length - 18 844 Add/Drop - Value indicating whether this is a new or existing 845 address (0x01), or a withdrawal of an address (0x02). 847 IPv6 Address - IPv6 Address of the neighbor or peer. 849 Subnet Mask - A subnet mask value (0-128) to be applied to the Ipv6 850 address. 852 9.7 Maximum Data Rate 854 The Maximum Data Rate (MDR) TLV is used in Neighbor Up, Neighbor 855 Update, Peer Discovery, Peer Update, and Link Characteristics ACK 856 Messages to indicate the maximum theoretical data rate, in bits per 857 second, that can be achieved on the link. When metrics are reported 858 via the messages listed above, the maximum data rate MUST be 859 reported. 861 0 1 2 3 862 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 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 |TLV Type =TBD |Length = 8 | MDR (bps) | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | MDR (bps) | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | MDR (bps) | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 TLV Type - TBD 873 Length - 8 875 Maximum Data Rate - A 64-bit unsigned number, representing the 876 maximum theoretical data rate, in bits per 877 second (bps), that can be achieved on the link. 879 9.8 Current Data Rate 881 The Current Data Rate (CDR) TLV is used in Neighbor Up, Neighbor 882 Update, Peer Discovery, Peer Update, Link Characteristics Request, 883 and Link Characteristics ACK messages to indicate the rate at which 884 the link is currently operating, or in the case of the Link 885 Characteristics Request, the desired data rate for the link. When 886 metrics are reported via the messages above, the current data rate 887 MUST be reported. 889 The Current Data Rate TLV contains the following fields: 891 0 1 2 3 892 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 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 |TLV Type =TBD |TLV Flags=0x10 |Length = 8 |CDR (bps) | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | CDR (bps) | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | CDR (bps) | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 TLV Type - TBD 903 Length - 8 905 Current Data Rate - A 64-bit unsigned number, representing the 906 current data rate, in bits per second, that is 907 currently be achieved on the link, or the 908 desired data rate in bits per second in the Link 909 Characteristics Request message. If there is no 910 distinction between current and maximum data 911 rates, current data rate MUST be set equal to 912 the maximum data rate. 914 9.9 Expected Forwarding Time 916 The Expected Forwarding Time (EFT) TLV is is an OPTIONAL data item. 917 If supported, it MAY be used in Neighbor Up, Neighbor Update, Peer 918 Discovery, and Peer Update messages to indicate the typical latency 919 between the arrival of a given packet at the transmitting device and 920 the reception of the packet at the other end of the link. EFT 921 combines transmission time, idle time, waiting time, freezing time, 922 and queuing time to the degree that those values are meaningful to a 923 given transmission medium. 925 The Expected Forwarding Time TLV contains the following fields: 927 0 1 2 3 928 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 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 |TLV Type =TBD |Length = 4 | EFT (ms) | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | EFT (ms) | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 TLV Type - TBD 937 Length - 4 939 EFT - A 32-bit unsigned number, representing the expected 940 forwarding time, in milliseconds, on the link. 942 9.10 Latency 944 The Latency TLV is used in Neighbor Up, Neighbor Update, Peer 945 Discovery, Peer Update, Link Characteristics Request, and Link 946 Characteristics ACK messages to indicate the amount of latency on the 947 link, or in the case of the Link Characteristics Request, to indicate 948 the maximum latency required on the link. When metrics are reported 949 via the messages above, Latency MUST be reported. 951 0 1 2 3 952 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 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 |TLV Type =TBD |Length = 2 | Latency (ms) | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 TLV Type - TBD 959 Length - 2 961 Latency - A 16-bit unsigned value, representing the transmission 962 delay that a packet encounters as it is transmitted 963 over the link. In Neighbor Up, Neighbor Update, and 964 Link Characteristics ACK, this value is reported as 965 delay, in milliseconds. The calculation of latency is 966 implementation dependent. For example, the latency may 967 be a running average calculated from the internal 968 queuing. If a device cannot calculate latency, it MUST 969 be reported as 0. In the Link Characteristics Request 970 Message, this value represents the maximum delay, in 971 milliseconds, expected on the link. 973 9.11 Resources 975 The Resources TLV is used in Neighbor Up, Neighbor Update, Peer 976 Discovery, Peer Update, and Link Characteristics ACK messages to 977 indicate a percentage (0-100) amount of resources (e.g. battery 978 power) remaining on the originating peer. If metrics are reported, 979 via the above messages, Resources MUST be reported. 981 The Resources TLV contains the following fields: 983 0 1 2 984 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 |TLV Type =TBD |Length = 1 | Resources | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 TLV Type - TBD 991 Length - 1 993 Resources - A percentage, 0-100, representing the amount of 994 remaining resources, such as battery power. If 995 resources cannot be calculated, a value of 100 MUST be 996 reported. 998 9.12 Relative Link Quality 1000 The Relative Link Quality (RLQ) TLV is used in Neighbor Up, Neighbor 1001 Update, Peer Discovery, Peer Update, and Link Characteristics ACK 1002 messages to indicate the quality of the link as calculated by the 1003 originating peer. If metrics are reported via the above messages, RLQ 1004 MUST be reported. 1006 The Relative Link Quality TLV contains the following fields: 1008 0 1 2 1009 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 |TLV Type =TBD |Length = 1 |Relative Link | 1012 | | |Quality (RLQ) | 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 TLV Type - TBD 1017 Length - 1 1019 Relative Link Quality - A non-dimensional number, 0-100, 1020 representing relative link quality. A value of 1021 100 represents a link of the highest quality. 1022 If the RLQ cannot be calculated, a value of 1023 100 MUST be reported. 1025 9.13 Status 1027 The Status TLV is an OPTIONAL TLV. It is sent as part of an 1028 acknowledgement message, from either the modem or the router, to 1029 indicate the success or failure of a given request. 1031 The Status TLV contains the following fields: 1033 0 1 2 1034 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 |TLV Type =TBD |Length = 1 | Code | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 TLV Type - TBD 1041 Length - 1 1043 Termination Code - 0 = Success, Non-zero = Failure. Specific values 1044 of a non-zero termination code depend on the 1045 operation requested (e.g. Neighbor Up, 1046 Neighbor Down, etc). 1048 9.14 Heartbeat Interval/Threshold 1050 The Heartbeat Interval/Threshold TLV is an OPTIONAL TLV. If 1051 supported, it MAY be sent during Peer Discovery to indicate the 1052 desired Heartbeat timeout window. If the modem includes the Heartbeat 1053 Interval TLV in Peer Discovery, the router MUST either accept the 1054 timeout interval supplied by the modem, or reject the Peer Discovery. 1055 Peer Discovery messages that do not include the Heartbeat Interval 1056 TLV in Peer Discovery indicates a desire to establish the 1057 router/modem session without an activity timeout (e.g. an infinite 1058 timeout value). If an activity timeout is supported, implementations 1059 MAY choose to implement heuristics such that signals sent/received 1060 reset the timer window. 1062 The Interval is used to specify a period (in seconds) for Heartbeat 1063 Messages (See Section 23). The Threshold value is used to indicate 1064 the desired number of windows, each of time (Heartbeat Interval) 1065 seconds, to wait before either participant declares the router/modem 1066 session lost. In this case, the overall amount of time before a 1067 router/modem is declared lost is expressed as (Interval * Threshold). 1068 Specifying an Interval value of 0 indicates the desire to disable 1069 Heartbeat messages entirely (e.g., the Interval is set to an infinite 1070 value). Setting the Threshold value to 0 is undefined, and TLVs with 1071 a Threshold value of 0 MUST be rejected by the recipient. 1073 The Heartbeat Interval/Threshold TLV contains the following fields: 1075 0 1 2 3 1076 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 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 |TLV Type =TBD |Length = 1 | Interval | Threshold | 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 TLV Type - TBD 1083 Length - 1 1085 Interval - 0 = Do NOT use heartbeats on this peer-to-peer 1086 session. Non-zero = Interval, in seconds, for 1087 heartbeat messages. 1089 Threshold - Number of windows, of Heartbeat Interval seconds, 1090 to wait before declaring a peer-to-peer session to 1091 be lost. 1093 9.15 Link Characteristics ACK Timer 1095 The Link Characteristics ACK Timer TLV is an OPTIONAL TLV. If 1096 supported, it MAY be sent during Peer Discovery to indicate the 1097 desired number of seconds to wait for a response to a Link 1098 Characteristics Request. If a router receives this TLV from a modem 1099 during Peer Discovery, the router MUST either accept the timeout 1100 value, or reject the Peer Discovery. If this TLV is omitted, 1101 implementations supporting the Link Characteristics Request SHOULD 1102 choose a default value. 1104 The Link Characteristics ACK Timer TLV contains the following fields: 1106 0 1 2 1107 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 |TLV Type =TBD |Length = 1 | Interval | 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 TLV Type - TBD 1114 Length - 1 1116 Interval - 0 = Do NOT use timeouts for Link Characteristics 1117 requests on this router/modem session. Non-zero = 1118 Interval, in seconds, to wait before considering a 1119 Link Characteristics Request has been lost. 1121 9.16 Credit Window Status 1123 The Credit Window Status TLV is an OPTIONAL TLV. If credits are 1124 supported by the DLEP participants (both the router and the modem), 1125 the Credit Window Status TLV MUST be sent by the participant 1126 receiving a Credit Grant Request for a given neighbor. 1128 The Credit Window Status TLV contains the following fields: 1130 0 1 2 3 1131 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 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 |TLV Type =TBD |Length = 16 | Modem Receive Window Value | 1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 | Modem Receive Window Value | 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 | Modem Receive Window Value | Router Receive Window Value | 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1139 | Router Receive Window Value | 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 | Router Receive Window Value | 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 TLV Type - TBD 1146 Length - 16 1148 Modem Receive Window Value - A 64-bit unsigned number, indicating 1149 the current (or initial) number of 1150 credits available on the Modem Receive 1151 Window. 1153 Router Receive Window Value - A 64-bit unsigned number, indicating 1154 the current (or initial) number of 1155 credits available on the Router Receive 1156 Window. 1158 9.17 Credit Grant Request 1160 The Credit Grant Request TLV is an OPTIONAL TLV. If credits are 1161 supported, the Credit Grant Request TLV is sent from a DLEP 1162 participant to grant an increment to credits on a window. The Credit 1163 Grant TLV is sent as a data item in either the Neighbor Up or 1164 Neighbor Update messages. The value in a Credit Grant TLV represents 1165 an increment to be added to any existing credits available on the 1166 window. Upon successful receipt and processing of a Credit Grant TLV, 1167 the receiver MUST respond with a message containing a Credit Window 1168 Status TLV to report the updated aggregate values for synchronization 1169 purposes. 1171 In the Neighbor Up message, when credits are desired, the originating 1172 peer MUST set the initial credit value of the window it controls 1173 (e.g. the Modem Receive Window, or Router Receive Window) to an 1174 initial, non-zero value. If the receiver of a Neighbor Up message 1175 with a Credit Grant Request TLV supports credits, the receiver MUST 1176 either reject the use of credits, via a Neighbor Up ACK response with 1177 the correct Status TLV, or set the initial value from the data 1178 contained in the Credit Window Status TLV. If the initialization 1179 completes successfully, the receiver MUST respond to the Neighbor Up 1180 message with a Neighbor Up ACK message that contains a Credit Window 1181 Status TLV, initializing its receive window. 1183 The Credit Grant TLV contains the following fields: 1185 0 1 2 3 1186 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 1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 |TLV Type =TBD |Length = 8 | Credit Increment | 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 | Credit Increment | 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 | Credit Increment | 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 TLV Type - TBD 1197 Length - 8 1199 Reserved - A 64-bit unsigned number representing the 1200 additional credits to be assigned to the credit 1201 window. Since credits can only be granted by the 1202 receiver on a window, the applicable credit window 1203 (either the MRW or the RRW) is derived from the 1204 sender of the grant. The Credit Increment MUST NOT 1205 cause the window to overflow; if this condition 1206 occurs, implementations MUST set the credit window 1207 to the maximum value contained in a 64-bit 1208 quantity. 1210 9.18 Credit Request 1212 The Credit Request TLV is an OPTIONAL TLV. If credits are supported, 1213 the Credit Request TLV MAY be sent from either DLEP participant, via 1214 a Neighbor Update signal, to indicate the desire for the partner to 1215 grant additional credits in order for data transfer to proceed on the 1216 session. If the corresponding Neighbor Up message for this session 1217 did NOT contain a Credit Window Status TLV, indicating that credits 1218 are to be used on the session, then the Credit Request TLV MUST be 1219 rejected by the receiver via a Neighbor Update ACK message. 1221 The Credit Request TLV contains the following fields: 1223 0 1 2 1224 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 |TLV Type =TBD |Length = 0 | Reserved, MUST| 1227 | | | be set to 0 | 1228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 TLV Type - TBD 1232 Length - 0 1234 Reserved - This field is currently unused and MUST be set to 0. 1236 10. DLEP Protocol Messages 1238 DLEP messages are encoded as a string of Type-Length-Value (TLV) 1239 constructs. The first TLV in a DLEP message MUST be a valid DLEP 1240 signal, as defined in section 11.1 of this document. The second TLV 1241 MUST be the Identification data item, defined in section 10.1 1242 Following those two TLVs are 0 or more TLVs, representing the data 1243 items that are appropriate for the signal. The layout of a DLEP 1244 message is thus: 1246 0 1 2 3 1247 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 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 | DLEP Signal |DLEP Message |Identification |Identification | 1250 | Type value |length (9 + |TLV Type |TLV length | 1251 | (value TBD) |optional TLVs) |(TBD) |(8) | 1252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1253 | Router ID | 1254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1255 | Modem ID | 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1257 | Start of optional DLEP | 1258 | TLVs... | 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 All DLEP messages (signals) begin with this structure. Therefore, in 1262 the following descriptions of specific messages, this header 1263 structure is assumed, and will not be replicated. 1265 10.1 Signal TLV Values 1267 As mentioned above, all DLEP messages begin with the Type value of 1268 the appropriate DLEP signal. Valid DLEP signals are: 1270 TLV TLV 1271 Value Description 1272 ========================================= 1273 TBD Peer Discovery 1274 TBD Peer Offer 1275 TBD Peer Offer ACK 1276 TBD Peer Update 1277 TBD Peer Update ACK 1278 TBD Peer Termination 1279 TBD Peer Termination ACK 1280 TBD Neighbor Up 1281 TBD Neighbor Up ACK 1282 TBD Neighbor Down 1283 TBD Neighbor Down ACK 1284 TBD Neighbor Update 1285 TBD Heartbeat 1286 TBD Link Characteristics Request 1287 TBD Link Characteristics ACK 1289 11. Peer Discovery Message 1291 The Peer Discovery Message is sent to begin a new DLEP association. 1292 The Peer Offer message is required to complete the discovery process. 1293 Implementations MAY implement their own retry heuristics in cases 1294 where it is determined the Peer Discovery Message has timed out. A 1295 Peer Discovery Message received from a participant that is already in 1296 session MUST be processed as if a Peer Termination Message had been 1297 received. An implementation MAY then process the received Peer 1298 Discovery Message. 1300 Note that metric data items MAY be supplied with the Peer Discovery, 1301 in order to populate default metric values, or to indicate a static, 1302 modem-wide environment. If metrics are supplied with the Peer 1303 Discovery message, these metrics MUST be used as the initial values 1304 for all neighbors established via the modem. 1306 Given the packet format described in section 11, the initial TLV Type 1307 value is set to DLEP_PEER_DISCOVERY (value TBD). Mandatory TLVs are 1308 then placed into the packet: 1310 Mandatory Data Item TLVs: 1311 - Identification 1313 After the Mandatory data item, implementations MAY place any OPTIONAL 1314 TLVs they support: 1316 Optional Data Item TLVs: 1317 - DLEP Version 1318 - DLEP Peer Type 1319 - Heartbeat Interval 1320 - Heartbeat Threshold 1321 - Link Characteristics ACK Timer 1322 - Maximum Data Rate 1323 - Current Data Rate 1324 - Latency 1325 - Expected Forwarding Time 1326 - Resources 1327 - Relative Link Quality 1329 12. Peer Offer Message 1330 The Peer Offer Message is sent by a DLEP participant in response to a 1331 Peer Discovery Message. Upon receipt, and successful processing, of a 1332 Peer Offer message, the recipient MUST respond with a Peer Offer ACK 1333 message, completing the discovery phase of DLEP. Both DLEP 1334 participants (router and modem) would then enter an "in session" 1335 state. Any subsequent Discovery messages sent or received on this 1336 session MUST be considered an error, and the session MUST be 1337 terminated as if a Peer Termination Message had been received. 1339 The Peer Offer message MUST be sent to the unicast address of the 1340 originator of Peer Discovery, regardless of whether the discovery was 1341 received on the DLEP multicast address (TBD) or on a unicast 1342 address. 1344 To construct a Peer Offer message, the initial TLV type value is set 1345 to DLEP_PEER_OFFER (value TBD). The Identification data item TLV is 1346 placed in the packet next, followed by any OPTIONAL Data Item TLVs 1347 the implementation supports: 1349 Optional Data Item TLVs: 1351 - DLEP Version 1352 - Peer Type 1353 - IPv4 Address 1354 - IPv6 Address 1355 - Status 1356 - Heartbeat Interval 1357 - Heartbeat Threshold 1358 - Link Characteristics ACK Timer 1360 13. Peer Offer ACK Message 1362 The Peer Offer ACK message acknowledges receipt of a Peer Offer 1363 message, and completes the router/modem session establishment for 1364 DLEP. The Peer Offer ACK message MUST be sent to unicast address of 1365 the originator of a Peer Offer message. The Peer Offer ACK message 1366 MAY contain an OPTIONAL Status data item, indicating success or 1367 failure of the attempt to establish a router/modem session. For 1368 implementations that do NOT support the Status data item (defined in 1369 section 10.13 of this document), the Peer Offer ACK message MUST be 1370 used ONLY to indicate successful session establishment; Peer Offer 1371 messages that are rejected MUST be silently dropped, allowing the 1372 Peer Offer to time out. 1374 To construct a Peer Offer ACK message, the initial TLV type value is 1375 set to DLEP_PEER_OFFER_ACK (value TBD). Mandatory data item TLV's are 1376 placed into the packet next: 1378 Mandatory Data Item TLVs: 1379 - Identification 1380 - Status 1382 Note that there are NO OPTIONAL data item TLVs specifed for this 1383 message. 1385 14. Peer Update Message 1387 The Peer Update message is an OPTIONAL message, sent by a DLEP peer 1388 to indicate local Layer 3 address changes, or for metric changes on a 1389 modem-wide basis. For example, addition of an IPv4 address to the 1390 router would prompt a Peer Update message to its attached DLEP 1391 modems. Also, a modem that changes its Maximum Data Rate for all 1392 destinations MAY reflect that change via a Peer Update Message to its 1393 attached router(s). 1395 Concerning Layer 3 addresses, if the modem is capable of 1396 understanding and forwarding this information (via proprietary 1397 mechanisms), the address update would prompt any remote DLEP modems 1398 (DLEP-enabled modems in a remote node) to issue a "Neighbor Update" 1399 message to their local routers with the new (or deleted) addresses. 1400 Modems that do not track Layer 3 addresses SHOULD silently parse and 1401 ignore the Peer Update Message. Modems that track Layer 3 addresses 1402 MUST acknowledge the Peer Update with a Peer Update ACK message. 1403 Routers receiving a Peer Update with metric changes MUST apply the 1404 new metric to all neighbors (remote nodes) accessible via the modem. 1405 Supporting implementations are free to employ heuristics to 1406 retransmit Peer Update messages. The sending of Peer Update Messages 1407 for Layer 3 address changes SHOULD cease when a either participant 1408 (router or modem) determines that the other implementation does NOT 1409 support Layer 3 address tracking. 1411 If metrics are supplied with the Peer Update message (e.g. Maximum 1412 Data Rate), these metrics are considered to be modem-wide, and 1413 therefore MUST be applied to all neighbors in the information base 1414 associated with the router/modem session. 1416 To construct a Peer Update message, the initial TLV type value is set 1417 to DLEP_PEER_UPDATE (value TBD). The Identification data item TLV is 1418 placed in the packet next, followed by any OPTIONAL Data Item TLVs. 1420 Optional Data Item TLVs: 1422 - IPv4 Address 1423 - IPv6 Address 1424 - Maximum Data Rate 1425 - Current Data Rate 1426 - Latency 1427 - Expected Forwarding Time 1428 - Resources 1429 - Relative Link Quality 1431 15. Peer Update ACK Message 1433 The Peer Update ACK message is an OPTIONAL message, and is sent by 1434 implementations supporting Layer 3 address tracking and/or modem-wide 1435 metrics to indicate whether a Peer Update Message was successfully 1436 processed. 1438 To construct a Peer Update ACK message, the initial TLV type value is 1439 set to DLEP_PEER_UPDATE_ACK (value TBD). The Identification data item 1440 TLV is placed in the packet next, followed by any OPTIONAL TLVs the 1441 implementation supports: 1443 Optional Data Item TLVs: 1445 - Status 1447 16. Peer Termination Message 1449 The Peer Termination Message is sent by a DLEP participant when the 1450 router/modem session needs to be terminated. Implementations 1451 receiving a Peer Termination message MUST send a Peer Termination ACK 1452 message to confirm the termination process. The sender of a Peer 1453 Termination message is free to define its heuristics in event of a 1454 timeout. The receiver of a Peer Termination Message MUST release all 1455 resources allocated for the router/modem session, and MUST eliminate 1456 all neighbors in the information base accessible via the router/modem 1457 pair represented by the session. Router and modem state machines are 1458 returned to the "discovery" state. No Neighbor Down messages are 1459 sent. 1461 To construct a Peer Termination message, the initial TLV type value 1462 is set to DLEP_PEER_TERMINATION (value TBD). The Identification data 1463 item TLV is placed in the packet next, followed by any OPTIONAL Data 1464 Item TLVs the implementation supports: 1466 Optional Data Item TLVs: 1468 - Status 1470 17. Peer Termination ACK Message 1472 The Peer Termination Message ACK is sent by a DLEP peer in response 1473 to a received Peer Termination order. Receipt of a Peer Termination 1474 ACK message completes the teardown of the router/modem session. 1476 To construct a Peer Termination ACK message, the initial TLV type 1477 value is set to DLEP_PEER_TERMINATION_ACK (value TBD). The 1478 Identification data item TLV is placed in the packet next, followed 1479 by any OPTIONAL TLVs the implementation supports: 1481 Optional Data Item TLVs: 1483 - Status 1485 18. Neighbor Up Message 1487 A DLEP participant sends the Neighbor Up message to report that a new 1488 destination has been detected. A Neighbor Up ACK Message is required 1489 to confirm a received Neighbor Up. A Neighbor Up message can be sent 1490 either by the modem, to indicate that a new remote node has been 1491 detected, or by the router, to indicate the presence of a new logical 1492 destination (e.g., a Multicast group) exists in the network. 1494 The sender of the Neighbor Up Message is free to define its retry 1495 heuristics in event of a timeout. When a Neighbor Up message is 1496 received and successfully parsed, the receiver should add knowledge 1497 of the new destination to its information base, indicating that the 1498 destination is accessible via the modem/router pair. 1500 To construct a Neighbor Up message, the initial TLV type value is set 1501 to DLEP_NEIGHBOR_UP (value TBD). The Identification data item TLV is 1502 placed in the packet next, followed by the MAC Address TLV, 1503 indicating the MAC address of the remote node or Multicast group. The 1504 implementation would then place any supported OPTIONAL Data Item TLVs 1505 into the packet: 1507 Optional Data Item TLVs: 1509 - IPv4 Address 1510 - IPv6 Address 1511 - Maximum Data Rate 1512 - Current Data Rate 1513 - Latency 1514 - Expected Forwarding Time 1515 - Resources 1516 - Relative Link Factor 1517 - Credit Window Status 1519 19. Neighbor Up ACK Message 1521 A DLEP participant sends the Neighbor Up ACK Message to indicate 1522 whether a Neighbor Up Message was successfully processed. 1524 To construct a Neighbor Up ACK message, the initial TLV type value is 1525 set to DLEP_NEIGHBOR_UP_ACK (value TBD). The Identification data item 1526 TLV is placed in the packet next, followed by the MAC Address TLV, 1527 containing the MAC address of the DLEP neighbor. The implementation 1528 would then place any supported OPTIONAL Data Item TLVs into the 1529 packet: 1531 Optional Data Item TLVs: 1532 - Credit Window Status 1534 20. Neighbor Down Message 1536 A DLEP peer sends the Neighbor Down message to report when a 1537 destination (a remote node or a multicast group) is no longer 1538 reachable. The Neighbor Down message MUST contain both the 1539 Identification data item TLV, and a MAC Address data item TLV. Other 1540 TLVs as listed are OPTIONAL, and MAY be present if an implementation 1541 supports them. A Neighbor Down ACK Message MUST be sent by the 1542 recipient of a Neighbor Down message to confirm that the relevant 1543 data has been removed from the information base. The sender of the 1544 Neighbor Down message is free to define its retry heuristics in event 1545 of a timeout. 1547 To construct a Neighbor Down message, the initial TLV type value is 1548 set to DLEP_NEIGHBOR_DOWN (value TBD). The signal TLV is followed by 1549 the mandatory data item TLVs: 1551 - Identification 1552 - MAC Address Data item 1553 - Status data item 1555 Note that there are NO OPTIONAL data item TLVs for this message. 1557 21. Neighbor Down ACK Message 1559 A DLEP participant sends the Neighbor Down ACK Message to indicate 1560 whether a received Neighbor Down Message was successfully processed. 1561 If successfully processed, the sender of the ACK MUST have removed 1562 all entries in the information base that pertain to the referenced 1563 neighbor. As with the Neighbor Down message, there are NO OPTIONAL 1564 Data Item TLVs defined for the Neighbor Down ACK message. 1566 To construct a Neighbor Down message, the initial TLV type value is 1567 set to DLEP_NEIGHBOR_DOWN_ACK (value TBD). The Identification data 1568 item TLV is placed in the packet next, followed by: 1570 - MAC Address Data item 1571 - Status data item 1573 22. Neighbor Update Message 1575 A DLEP participant sends the Neighbor Update message when it detects 1576 some change in the information base for a given neighbor (remote node 1577 or multicast group). Some examples of changes that would prompt a 1578 Neighbor Update message are: 1580 - Change in link metrics (e.g., Data Rates) 1581 - Layer 3 addressing change (for implementations that support it) 1583 To construct a Neighbor Update message, the initial TLV type value is 1584 set to DLEP_NEIGHBOR_UPDATE (value TBD). Following the signal TLV are 1585 the mandatory Data Item TLVs: 1587 Identification Data Item TLV 1588 MAC Address data item TLV 1590 After placing the mandatory data item TLVs into the packet, the 1591 implementation would place any supported OPTIONAL data item TLVs. 1592 Possible OPTIONAL data item TLVs are: 1594 - IPv4 Address 1595 - IPv6 Address 1596 - Maximum Data Rate 1597 - Current Data Rate 1598 - Latency 1599 - Resources 1600 - Relative Link Quality 1601 - Credit Window Status 1602 - Credit Grant 1603 - Credit Request 1605 23. Heartbeat Message 1607 A Heartbeat Message is sent by a DLEP participant every N seconds, 1608 where N is defined in the "Heartbeat Interval" field of the discovery 1609 message. Note that implementations omitting the Heartbeat Interval 1610 effectively set the interval to an infinite value, therefore, in 1611 those cases, this message would NOT be sent. 1613 The message is used by participants to detect when a DLEP session 1614 partner (either the modem or the router) is no longer communicating. 1615 Participants SHOULD allow some integral number of heartbeat intervals 1616 (default 4) to expire with no traffic on the router/modem session 1617 before initiating DLEP session termination procedures. 1619 To construct a Heartbeat message, the initial TLV type value is set 1620 to DLEP_PEER_HEARTBEAT (value TBD). The signal TLV is followed by the 1621 mandatory data item TLVs: 1623 - Identification 1625 Note that there are NO OPTIONAL data item TLVs for this message. 1627 24. Link Characteristics Request Message 1629 The Link Characteristics Request Message is an OPTIONAL message, and 1630 is sent by the router to request that the modem initiate changes for 1631 specific characteristics of the link. Since the request specifies a 1632 neighbor, it can reference either a real destination (e.g., a remote 1633 node), or a logical destination (e.g., a multicast destination) 1634 within the network. 1636 The Link Characteristics Request message contains either a Current 1637 Data Rate (CDR) TLV to request a different amount of bandwidth than 1638 what is currently allocated, a Latency TLV to request that traffic 1639 delay on the link not exceed the specified value, or both. A Link 1640 Characteristics ACK Message is required to complete the request. 1641 Implementations are free to define their retry heuristics in event of 1642 a timeout. Issuing a Link Characteristics Request with ONLY the MAC 1643 Address TLV is a mechanism a peer MAY use to request metrics (via the 1644 Link Characteristics ACK) from its partner. 1646 To construct a Link Characteristics Request message, the initial TLV 1647 type value is set to DLEP_NEIGHBOR_LINK_CHAR_REQ (value TBD). 1648 Following the signal TLV are the mandatory Data Item TLVs: 1650 Identification Data Item TLV 1651 MAC Address data item TLV 1653 After placing the mandatory data item TLVs into the packet, the 1654 implementation would place any supported OPTIONAL data item TLVs. 1655 Possible OPTIONAL data item TLVs are: 1657 Current Data Rate - If present, this value represents the NEW (or 1658 unchanged, if the request is denied) Current 1659 Data Rate in bits per second (bps). 1661 Latency - If present, this value represents the maximum 1662 desired latency (e.g., it is a not-to-exceed 1663 value) in milliseconds on the link. 1665 25. Link Characteristics ACK Message 1667 The LInk Characteristics ACK message is an OPTIONAL message, and is 1668 sent by modems supporting it to the router letting the router know 1669 the success or failure of a requested change in link characteristics. 1670 The Link Characteristics ACK message SHOULD contain a complete set 1671 of metric data item TLVs. It MUST contain the same TLV types as the 1672 request. The values in the metric data item TLVs in the Link 1673 Characteristics ACK message MUST reflect the link characteristics 1674 after the request has been processed. 1676 To construct a Link Characteristics Request ACK message, the initial 1677 TLV type value is set to DLEP_NEIGHBOR_LINK_CHAR_ACK (value TBD). 1678 Following the signal TLV are the mandatory Data Item TLVs: 1680 Identification Data Item TLV 1681 MAC Address data item TLV 1683 After placing the mandatory data item TLVs into the packet, the 1684 implementation would place any supported OPTIONAL data item TLVs. 1685 Possible OPTIONAL data item TLVs are: 1687 Current Data Rate - If present, this value represents the requested 1688 data rate in bits per second (bps). 1690 Latency - If present, this value represents the NEW 1691 maximum latency (or unchanged, if the request 1692 is denied), expressed in milliseconds, on the 1693 link. 1695 26. Security Considerations 1697 The protocol does not contain any mechanisms for security (e.g. 1698 authentication or encryption). The protocol assumes that any security 1699 would be implemented in the underlying transport (for example, by use 1700 of DTLS or some other mechanism), and is therefore outside the scope 1701 of this document. 1703 27. IANA Considerations 1705 This section specifies requests to IANA. 1707 27.1 Registrations 1709 This specification defines: 1711 o A new repository for DLEP signals, with fifteen values currently 1712 assigned. 1714 o Reservation of numbering space for Experimental DLEP signals. 1716 o A new repository for DLEP Data Items, with eighteen values 1717 currently assigned. 1719 o Reservation of numbering space in the Data Items repository for 1720 experimental data items. 1722 o A request for allocation of a well-known port for DLEP 1723 communication. 1725 o A request for allocation of a multicast address for DLEP 1726 discovery. 1728 27.2 Expert Review: Evaluation Guidelines 1730 No additional guidelines for expert review are anticipated. 1732 27.3 Signal (Message) TLV Type Registration 1734 A new repository must be created with the values of the DLEP signals. 1735 Valid signals are: 1737 o Peer Discovery 1738 o Peer Offer 1739 o Peer Offer ACK 1740 o Peer Update 1741 o Peer Update ACK 1742 o Peer Termination 1743 o Peer Termination ACK 1744 o Neighbor Up 1745 o Neighbor Up ACK 1746 o Neighbor Down 1747 o Neighbor Down ACK 1748 o Neighbor Update 1749 o Heartbeat 1750 o Link Characteristics Request 1751 o Link Characteristics ACK 1753 It is also requested that the repository contain space for 1754 experimental signal types. 1756 27.4 DLEP Data Item Registrations 1758 A new repository for DLEP Data Items must be created. Valid Data 1759 Items are: 1761 o Identification 1762 o DLEP Version 1763 o Peer Type 1764 o MAC Address 1765 o IPv4 Address 1766 o IPv6 Address 1767 o Maximum Data Rate 1768 o Current Data Rate 1769 o Latency 1770 o Expected Forwarding Time 1771 o Resources 1772 o Relative Link Quality 1773 o Status 1774 o Heartbeat Interval/Threshold 1775 o Link Characteristics ACK Timer 1776 o Credit Window Status 1777 o Credit Grant 1778 o Credit Request 1780 It is also requested that the registry allocation contain space for 1781 experimental data items. 1783 27.5 DLEP Well-known Port 1785 It is requested that IANA allocate a well-known port number for DLEP 1786 communication. 1788 27.6 DLEP Multicast Address 1790 It is requested that IANA allocate a multicast address for DLEP 1791 discovery messages. 1793 30. Appendix A. 1795 30.1 Peer Level Message Flows 1797 30.1.1 Modem Device Restarts Discovery 1799 Router Modem Message Description 1800 ==================================================================== 1801 <-------Peer Discovery--------- Modem initiates discovery 1803 ---------Peer Offer-----------> Router detects a problem, sends 1804 w/ Non-zero Status TLV Peer Offer w/Status TLV indicating 1805 the error. 1807 Modem accepts failure, restarts 1808 discovery process. 1810 <-------Peer Discovery--------- Modem initiates discovery 1812 ---------Peer Offer-----------> Router accepts, sends Peer Offer 1813 w/ Zero Status TLV w/ Status TLV indicating success. 1815 Discovery completed. 1817 30.1.2 Modem Device Detects Peer Offer Timeout 1819 Router Modem Message Description 1820 ==================================================================== 1822 <-------Peer Discovery--------- Modem initiates discovery, starts 1823 a guard timer. 1825 Modem guard timer expires. Modem 1826 restarts discovery process. 1828 <-------Peer Discovery--------- Modem initiates discovery, starts 1829 a guard timer. 1831 ---------Peer Offer-----------> Router accepts, sends Peer Offer 1832 w/ Zero Status TLV w/ Status TLV indicating success. 1834 Discovery completed. 1836 30.1.3 Router Peer Offer Lost 1838 Router Modem Message Description 1839 ==================================================================== 1841 <-------Peer Discovery--------- Modem initiates discovery, starts 1842 a guard timer. 1844 ---------Peer Offer-------|| Router offers availability 1846 Modem times out on Peer Offer, 1847 restarts discovery process. 1849 <-------Peer Discovery--------- Modem initiates discovery 1851 ---------Peer Offer-----------> Router detects subsequent 1852 discovery, internally terminates 1853 the previous, accepts the new 1854 association, sends Peer Offer 1855 w/Status TLV indicating success. 1857 Discovery completed. 1859 30.1.4 Discovery Success 1861 Router Modem Message Description 1862 ==================================================================== 1864 <-------Peer Discovery--------- Modem initiates discovery 1866 ---------Peer Offer-----------> Router offers availability 1868 -------Peer Heartbeat---------> 1870 <-------Peer Heartbeat--------- 1872 -------Peer Heartbeat---------> 1874 <==============================> Neighbor Sessions 1876 <-------Peer Heartbeat--------- 1878 -------Peer Heartbeat---------> 1880 --------Peer Term Req---------> Terminate Request 1882 <--------Peer Term Res--------- Terminate Response 1884 30.1.5 Router Detects a Heartbeat timeout 1886 Router Modem Message Description 1887 ==================================================================== 1889 <-------Peer Heartbeat--------- 1891 -------Peer Heartbeat---------> 1893 ||---Peer Heartbeat--------- 1895 ~ ~ ~ ~ ~ ~ ~ 1897 -------Peer Heartbeat---------> 1899 ||---Peer Heartbeat--------- 1900 Router Heartbeat Timer expires, 1901 detects missing heartbeats. Router 1902 takes down all neighbor sessions 1903 and terminates the Peer 1904 association. 1906 ------Peer Terminate ---------> Peer Terminate Request 1908 Modem takes down all neighbor 1909 sessions, then acknowledges the 1910 Peer Terminate 1912 <----Peer Terminate ACK--------- Peer Terminate ACK 1914 30.1.6 Modem Detects a Heartbeat timeout 1916 Router Modem Message Description 1917 ==================================================================== 1919 <-------Peer Heartbeat--------- 1921 -------Peer Heartbeat------|| 1923 <-------Peer Heartbeat--------- 1925 ~ ~ ~ ~ ~ ~ ~ 1927 -------Peer Heartbeat------|| 1929 <-------Peer Heartbeat--------- 1930 Modem Heartbeat Timer expires, 1931 detects missing heartbeats. Modem 1932 takes down all neighbor sessions 1934 <-------Peer Terminate-------- Peer Terminate Request 1936 Router takes down all neighbor 1937 sessions, then acknowledges the 1938 Peer Terminate 1940 ------Peer Terminate ACK-----> Peer Terminate ACK 1942 30.1.7 Peer Terminate (from Modem) Lost 1944 Router Modem Message Description 1945 ==================================================================== 1947 ||------Peer Terminate-------- Modem Peer Terminate Request 1949 Router Heartbeat times out, 1950 terminates association. 1952 --------Peer Terminate-------> Router Peer Terminate 1954 <-----Peer Terminate ACK------ Modem sends Peer Terminate ACK 1956 30.1.8 Peer Terminate (from Router) Lost 1958 Router Modem Message Description 1959 ==================================================================== 1961 -------Peer Terminate--------> Router Peer Terminate Request 1963 Modem HB times out, 1964 terminates association. 1966 <------Peer Terminate-------- Modem Peer Terminate 1968 ------Peer Terminate ACK-----> Peer Terminate ACK 1970 30.2 Neighbor Specific Message Flows 1971 30.2.1 Modem Neighbor Up Lost 1973 Router Modem Message Description 1974 ==================================================================== 1976 ||-----Neighbor Up ------------ Modem sends Neighbor Up 1978 Modem timesout on ACK 1980 <------Neighbor Up ------------ Modem sends Neighbor Up 1982 ------Neighbor Up ACK---------> Router accepts the neighbor 1983 session 1985 <------Neighbor Update--------- Modem Neighbor Metrics 1986 . . . . . . . . 1987 <------Neighbor Update--------- Modem Neighbor Metrics 1989 30.2.2 Router Detects Duplicate Neighbor Ups 1991 Router Modem Message Description 1992 ==================================================================== 1994 <------Neighbor Up ------------ Modem sends Neighbor Up 1996 ------Neighbor Up ACK-------|| Router accepts the neighbor 1997 session 1999 Modem timesout on ACK 2001 <------Neighbor Up ------------ Modem resends Neighbor Up 2003 Router detects duplicate Neighbor, 2004 takes down the previous, accepts 2005 the new Neighbor. 2007 ------Neighbor Up ACK---------> Router accepts the neighbor 2008 session 2010 <------Neighbor Update--------- Modem Neighbor Metrics 2011 . . . . . . . . 2012 <------Neighbor Update--------- Modem Neighbor Metrics 2014 30.2.3 Neighbor Up, No Layer 3 Addresses 2016 Router Modem Message Description 2017 ==================================================================== 2019 <------Neighbor Up ------------ Modem sends Neighbor Up 2021 ------Neighbor Up ACK---------> Router accepts the neighbor 2022 session 2024 Router ARPs for IPv4 if defined. 2025 Router drives ND for IPv6 if 2026 defined. 2028 <------Neighbor Update--------- Modem Neighbor Metrics 2029 . . . . . . . . 2030 <------Neighbor Update--------- Modem Neighbor Metrics 2032 30.2.4 Neighbor Up with IPv4, No IPv6 2034 Router Modem Message Description 2035 ==================================================================== 2037 <------Neighbor Up ------------ Modem sends Neighbor Up with 2038 the IPv4 TLV 2040 ------Neighbor Up ACK---------> Router accepts the neighbor 2041 session 2043 Router drives ND for IPv6 if 2044 defined. 2046 <------Neighbor Update--------- Modem Neighbor Metrics 2047 . . . . . . . . 2048 <------Neighbor Update--------- Modem Neighbor Metrics 2050 30.2.5 Neighbor Up with IPv4 and IPv6 2052 Router Modem Message Description 2053 ==================================================================== 2055 <------Neighbor Up ------------ Modem sends Neighbor Up with 2056 the IPv4 and IPv6 TLVs 2058 ------Neighbor Up ACK---------> Router accepts the neighbor 2059 session 2061 <------Neighbor Update--------- Modem Neighbor Metrics 2062 . . . . . . . . 2064 30.2.6 Neighbor Session Success 2066 Router Modem Message Description 2067 ==================================================================== 2069 ---------Peer Offer-----------> Router offers availability 2071 -------Peer Heartbeat---------> 2073 <------Neighbor Up ----------- Modem 2075 ------Neighbor Up ACK--------> Router 2077 <------Neighbor Update--------- Modem 2078 . . . . . . . . 2079 <------Neighbor Update--------- Modem 2081 Modem initiates the terminate 2083 <------Neighbor Down ---------- Modem 2085 ------Neighbor Down ACK-------> Router 2087 or 2089 Router initiates the terminate 2091 ------Neighbor Down ----------> Router 2093 <------Neighbor Down ACK------- Modem 2095 Acknowledgements 2097 The authors would like to acknowledge the influence and contributions 2098 of Chris Olsen, Teco Boot, Subir Das, Jaewon Kang, Vikram Kaul, Rick 2099 Taylor, John Dowdell, Nelson Powell, Bow-Nan Cheng, and Henning 2100 Rogge. 2102 Normative References 2104 [RFC5578] Berry, B., Ed., "PPPoE with Credit Flow and Metrics", 2105 RFC 5578, February 2010. 2107 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2109 Informative References 2111 [DTLS] Rescorla, E., Ed,. "Datagram Transport Layer Security", 2112 RFC 4347, April 2006. 2114 Author's Addresses 2116 Stan Ratliff 2117 Cisco 2118 170 West Tasman Drive 2119 San Jose, CA 95134 2120 USA 2121 EMail: sratliff@cisco.com 2123 Bo Berry 2124 Cisco 2125 170 West Tasman Drive 2126 San Jose, CA 95134 2127 USA 2128 EMail: boberry@cisco.com 2130 Greg Harrison 2131 Cisco 2132 170 West Tasman Drive 2133 San Jose, CA 95134 2134 USA 2135 EMail: greharri@cisco.com 2137 Shawn Jury 2138 NetApp 2139 7301 Kit Creek Road, Building 2 2140 Research Triangle Park, NC 27709 2141 USA 2142 Email: shawn.jury@netapp.com 2144 Darryl Satterwhite 2145 Cisco 2146 170 West Tasman Drive 2147 San Jose, CA 95134 2148 USA 2149 Email: dsatterw@cisco.com