idnits 2.17.1 draft-ietf-manet-dlep-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There is 1 instance 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 261 has weird spacing: '... Shared o ...' == Line 262 has weird spacing: '... Medium o...' -- The document date (Febuary 10, 2014) is 3783 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 5246 (ref. 'TLS') (Obsoleted by RFC 8446) Summary: 3 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 S. Jury 6 Expires: August 14, 2014 Cisco Systems 7 D. Satterwhite 8 Broadcom 9 Febuary 10, 2014 11 Dynamic Link Exchange Protocol (DLEP) 12 draft-ietf-manet-dlep-05 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 August 14, 2014. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 8 68 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 3. Credits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 4. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 5. Extensions to DLEP . . . . . . . . . . . . . . . . . . . . . . 10 72 6. Normal Session Flow . . . . . . . . . . . . . . . . . . . . . 11 73 6.1 DLEP Modem session flow - Discovery case . . . . . . . . . . 11 74 6.2 DLEP Modem session flow - Configured case . . . . . . . . . 11 75 6.3 DLEP Router session flow . . . . . . . . . . . . . . . . . 12 76 6.4 Common Session Flow . . . . . . . . . . . . . . . . . . . . 12 77 7. Mandatory Signals and Data Items . . . . . . . . . . . . . . . 13 78 8. Generic DLEP Message Definition . . . . . . . . . . . . . . . . 14 79 9. DLEP Data Items . . . . . . . . . . . . . . . . . . . . . . . . 15 80 9.1 DLEP Version . . . . . . . . . . . . . . . . . . . . . . . 16 81 9.2 DLEP Port . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 9.3 Peer Type . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 9.4 MAC Address . . . . . . . . . . . . . . . . . . . . . . . . 18 84 9.5 IPv4 Address . . . . . . . . . . . . . . . . . . . . . . . 18 85 9.6 IPv6 Address . . . . . . . . . . . . . . . . . . . . . . . 19 86 9.7 Maximum Data Rate (Receive) . . . . . . . . . . . . . . . . 20 87 9.8 Maximum Data Rate (Transmit) . . . . . . . . . . . . . . . 20 88 9.9 Current Data Rate (Receive) . . . . . . . . . . . . . . . . 21 89 9.10 Current Data Rate (Transmit) . . . . . . . . . . . . . . . 22 90 9.11 Expected Forwarding Time . . . . . . . . . . . . . . . . . 23 91 9.12 Latency . . . . . . . . . . . . . . . . . . . . . . . . . 23 92 9.13 Resources (Receive) . . . . . . . . . . . . . . . . . . . 24 93 9.14 Resources (Transmit) . . . . . . . . . . . . . . . . . . . 25 94 9.15 Relative Link Quality (Receive) . . . . . . . . . . . . . 25 95 9.16 Relative Link Quality (Transmit) . . . . . . . . . . . . . 26 96 9.17 Status . . . . . . . . . . . . . . . . . . . . . . . . . . 26 97 9.18 Heartbeat Interval . . . . . . . . . . . . . . . . . . . . 27 98 9.19 Link Characteristics ACK Timer . . . . . . . . . . . . . . 28 99 9.20 Credit Window Status . . . . . . . . . . . . . . . . . . . 28 100 9.21 Credit Grant Request . . . . . . . . . . . . . . . . . . . 29 101 9.22 Credit Request . . . . . . . . . . . . . . . . . . . . . . 30 102 10. DLEP Protocol Messages . . . . . . . . . . . . . . . . . . . . 31 103 10.1 Signal TLV Values . . . . . . . . . . . . . . . . . . . . 31 104 10.2 Peer Discovery Message . . . . . . . . . . . . . . . . . . 32 105 10.3 Peer Offer Message . . . . . . . . . . . . . . . . . . . . 32 106 10.4 Peer Initialization Message . . . . . . . . . . . . . . . . 33 107 10.5 Peer Initialization ACK Message . . . . . . . . . . . . . . 33 108 10.6 Peer Update Message . . . . . . . . . . . . . . . . . . . . 34 109 10.7 Peer Update ACK Message . . . . . . . . . . . . . . . . . . 35 110 10.8 Peer Termination Message . . . . . . . . . . . . . . . . . 35 111 10.9 Peer Termination ACK Message . . . . . . . . . . . . . . . 36 112 10.10 Destination Up Message . . . . . . . . . . . . . . . . . . 36 113 10.11 Destination Up ACK Message . . . . . . . . . . . . . . . . 37 114 10.12 Destination Down Message . . . . . . . . . . . . . . . . . 37 115 10.13 Destination Down ACK Message . . . . . . . . . . . . . . . 37 116 10.14 Destination Update Message . . . . . . . . . . . . . . . . 38 117 10.15 Heartbeat Message . . . . . . . . . . . . . . . . . . . . 38 118 10.16 Link Characteristics Request Message . . . . . . . . . . . 39 119 10.17 Link Characteristics ACK Message . . . . . . . . . . . . . 40 120 11. Security Considerations . . . . . . . . . . . . . . . . . . . 40 121 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 122 12.1 Registrations . . . . . . . . . . . . . . . . . . . . . . 41 123 12.2 Expert Review: Evaluation Guidelines . . . . . . . . . . . 41 124 12.3 Message (Signal) TLV Type Registration . . . . . . . . . . 41 125 12.4 DLEP Data Item Registrations . . . . . . . . . . . . . . . 42 126 12.5 DLEP Well-known Port . . . . . . . . . . . . . . . . . . . 42 127 12.6 DLEP Multicast Address . . . . . . . . . . . . . . . . . . 42 128 13. Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . 42 129 13.1 Peer Level Message Flows . . . . . . . . . . . . . . . . . 42 130 13.1.1 Modem Device Restarts Discovery . . . . . . . . . . . 43 131 13.1.2 Modem Device Detects Peer Offer Timeout . . . . . . . 43 132 13.1.3 Router Peer Offer Lost . . . . . . . . . . . . . . . . 44 133 13.1.4 Discovery Success . . . . . . . . . . . . . . . . . . 44 134 29.1.5 Router Detects a Heartbeat timeout . . . . . . . . . . 45 135 29.1.6 Modem Detects a Heartbeat timeout . . . . . . . . . . 45 136 29.1.7 Peer Terminate (from Modem) Lost . . . . . . . . . . . 46 137 29.1.8 Peer Terminate (from Router) Lost . . . . . . . . . . 46 138 29.2 Destination Specific Message Flows . . . . . . . . . . . . 46 139 29.2.1 Modem Destination Up Lost . . . . . . . . . . . . . . 47 140 29.2.2 Router Detects Duplicate Destination Ups . . . . . . . 47 141 29.2.3 Destination Up, No Layer 3 Addresses . . . . . . . . . 48 142 29.2.4 Destination Up with IPv4, No IPv6 . . . . . . . . . . 48 143 29.2.5 Destination Up with IPv4 and IPv6 . . . . . . . . . . 48 144 29.2.6 Destination Session Success . . . . . . . . . . . . . 49 146 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 49 147 Normative References . . . . . . . . . . . . . . . . . . . . . . . 50 148 Informative References . . . . . . . . . . . . . . . . . . . . . . 50 149 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 151 1. Introduction 153 There exist today a collection of modem devices that control links of 154 variable datarate and quality. Examples of these types of links 155 include line-of-sight (LOS) radios, satellite terminals, and 156 cable/DSL modems. Fluctuations in speed and quality of these links 157 can occur due to configuration (in the case of cable/DSL modems), or 158 on a moment-to-moment basis, due to physical phenomena like multipath 159 interference, obstructions, rain fade, etc. It is also quite possible 160 that link quality and datarate varies with respect to individual 161 destinations on a link, and with the type of traffic being sent. As 162 an example, consider the case of an 802.11g access point, serving 2 163 associated laptop computers. In this environment, the answer to the 164 question "What is the datarate on the 802.11g link?" is "It depends 165 on which associated laptop we're talking about, and on what kind of 166 traffic is being sent." While the first laptop, being physically 167 close to the access point, may have a datarate of 54Mbps for unicast 168 traffic, the other laptop, being relatively far away, or obstructed 169 by some object, can simultaneously have a datarate of only 32Mbps for 170 unicast. However, for multicast traffic sent from the access point, 171 all traffic is sent at the base transmission rate (which is 172 configurable, but depending on the model of the access point, is 173 usually 24Mbps or less). 175 In addition to utilizing variable datarate links, mobile networks are 176 challenged by the notion that link connectivity will come and go over 177 time. Effectively utilizing a relatively short-lived connection is 178 problematic in IP routed networks, as routing protocols tend to rely 179 on independent timers at OSI Layer 3 to maintain network convergence 180 (e.g. HELLO messages and/or recognition of DEAD routing adjacencies). 181 These short-lived connections can be better utilized with an event- 182 driven paradigm, where acquisition of a new neighbor (or loss of an 183 existing one) is signaled, as opposed to a timer-driven paradigm. 185 Another complicating factor for mobile networks are the different 186 methods of physically connecting the modem devices to the router. 187 Modems can be deployed as an interface card in a router's chassis, or 188 as a standalone device connected to the router via Ethernet, USB, or 189 even a serial link. In the case of Ethernet or serial attachment, 190 with existing protocols and techniques, routing software cannot be 191 aware of convergence events occurring on the radio link (e.g. 192 acquisition or loss of a potential routing neighbor), nor can the 193 router be aware of the actual capacity of the link. This lack of 194 awareness, along with the variability in datarate, leads to a 195 situation where quality of service (QoS) profiles are extremely 196 difficult to establish and properly maintain. This is especially true 197 of demand-based access schemes such as Demand Assigned Multiple 198 Access (DAMA) implementations used on some satellite systems. With a 199 DAMA-based system, additional datarate may be available, but will not 200 be used unless the network devices emit traffic at rate higher than 201 the currently established rate. Increasing the traffic rate does not 202 guarantee additional datarate will be allocated; rather, it may 203 result in data loss and additional retransmissions on the link. 205 Addressing the challenges listed above, the authors have developed 206 the Data Link Exchange Protocol, or DLEP. The DLEP protocol runs 207 between a router and its attached modem devices, allowing the modem 208 to communicate link characteristics as they change, and convergence 209 events (acquisition and loss of potential routing destinations). The 210 following diagrams are used to illustrate the scope of DLEP packets. 212 |-------Local Node-------| |-------Remote Node------| 213 | | | | 214 +--------+ +-------+ +-------+ +--------+ 215 | Router |=======| Modem |{~~~~~~~~}| Modem |=======| Router | 216 | | | Device| | Device| | | 217 +--------+ +-------+ +-------+ +--------+ 218 | | | Link | | | 219 |-DLEP--| | Protocol | |-DLEP--| 220 | | | (e.g. | | | 221 | | | 802.11) | | | 223 Figure 1: DLEP Network 225 In Figure 1, when the local modem detects the presence of a remote 226 node, it (the local modem) sends a signal to its router via the DLEP 227 protocol. Upon receipt of the signal, the local router may take 228 whatever action it deems appropriate, such as initiating discovery 229 protocols, and/or issuing HELLO messages to converge the network. On 230 a continuing, as-needed basis, the modem devices utilize DLEP to 231 report any characteristics of the link (datarate, latency, etc) that 232 have changed. DLEP is independent of the link type and topology 233 supported by the modem. Note that the DLEP protocol is specified to 234 run only on the local link between router and modem. Some over the 235 air signaling may be necessary between the local and remote modem in 236 order to provide some parameters in DLEP messages between the local 237 modem and local router, but DLEP does not specify how such over the 238 air signaling is carried out. Over the air signaling is purely a 239 matter for the modem implementer. 241 Figure 2 shows how DLEP can support a configuration where routers are 242 connected with different link types. In this example, Modem A 243 implements a point-to-point link, and Modem B is connected via a 244 shared medium. In both cases, the DLEP protocol is used to report the 245 characteristics of the link (datarate, latency, etc.) to routers. The 246 modem is also able to use the DLEP session to notify the router when 247 the remote node is lost, shortening the time required to re-converge 248 the network. 250 +--------+ +--------+ 251 +----+ Modem A| | Modem A+---+ 252 | | Device | <===== // ======> | Device | | 253 | +--------+ P-2-P Link +--------+ | 254 +---+----+ +---+----+ 255 | Router | | Router | 256 | | | | 257 +---+----+ +---+----+ 258 | +--------+ +--------+ | 259 +-----+ Modem B| | Modem B| | 260 | Device | o o o o o o o o | Device +--+ 261 +--------+ o Shared o +--------+ 262 o Medium o 263 o o 264 o o 265 o o 266 o 267 +--------+ 268 | Modem B| 269 | Device | 270 +---+----+ 271 | 272 | 273 +---+----+ 274 | Router | 275 | | 276 +--------+ 278 Figure 2: DLEP Network with Multiple Modem Devices 280 DLEP defines a set of messages used by modems and their attached 281 routers. The messages are used to communicate events that occur on 282 the physical link(s) managed by the modem: for example, a remote node 283 entering or leaving the network, or that the link has changed. 284 Associated with these messages are a set of data items - information 285 that describes the remote node (e.g., address information), and/or 286 the characteristics of the link to the remote node. 288 The protocol is defined as a collection of type-length-value (TLV) 289 based messages, specifying the signals that are exchanged between a 290 router and a modem, and the data items associated with the signal. 291 This document specifies transport of DLEP signals and data items via 292 the TCP transport, with a UDP-based discovery mechanism. Other 293 transports for the protocol are possible, but are outside the scope 294 of this document. 296 DLEP signals are further defined as mandatory or optional. Signals 297 will additionally have mandatory and optional data items. 298 Implementations MUST support all mandatory messages and their 299 mandatory data items to be considered compliant. Implementations MAY 300 also support some, or all, of the optional messages and data items. 302 DLEP uses a session-oriented paradigm between the modem device and 303 its associated router. If multiple modem devices are attached to a 304 router (as in Figure 2), a separate DLEP session MUST exist for each 305 modem. If a modem device supports multiple connections to a router 306 (via multiple logical or physical interfaces), or supports 307 connections to multiple routers, a separate DLEP session MUST exist 308 for each connection. This router/modem session provides a carrier for 309 information exchange concerning "destinations" that are available via 310 the modem device. A "destination" can be either physical (as in the 311 case of a specific far-end router), or a logical destination (as in a 312 Multicast group). As such, all of the destination-level exchanges in 313 DLEP can be envisioned as building an information base concerning the 314 remote nodes, and the link characteristics to those nodes. 316 Multicast traffic destined for the variable-quality network (the 317 network accessed via the DLEP modem) is handled in IP networks by 318 deriving a Layer 2 MAC address based on the Layer 3 address. 319 Leveraging on this scheme, Multicast traffic is supported in DLEP 320 simply by treating the derived MAC address as any other "destination" 321 (albeit a logical one) in the network. To support these logical 322 destinations, one of the DLEP participants (typically, the router) 323 informs the other as to the existence of the logical neighbor. The 324 modem, once it is aware of the existence of this logical neighbor, 325 reports link characteristics just as it would for any other 326 destination in the network. The specific algorithms a modem would use 327 to report metrics on multicast (or logical) destinations is outside 328 the scope of this specification, and is left to specific 329 implementations to decide. 331 1.1 Requirements 333 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 334 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 335 document are to be interpreted as described in BCP 14, RFC 2119 336 [RFC2119]. 338 2. Assumptions 340 Routers and modems that exist as part of the same node (e.g., that 341 are locally connected) can utilize a discovery technique to locate 342 each other, thus avoiding a-priori configuration. The modem is 343 responsible for initialing the discovery process, using the Peer 344 Discovery message. 346 DLEP utilizes a session-oriented paradigm. A router and modem form a 347 session by completing the discovery process. This router-modem 348 session persists unless or until it either (1) times out, based on 349 the timeout values supplied, or (2) is explicitly torn down by one of 350 the participants. Note that while use of timers in DLEP is OPTIONAL, 351 it is strongly recommended that implementations choose to run with 352 timers enabled. 354 DLEP assumes that participating modems, and their physical links, act 355 as a transparent bridge. Specifically, the assumption is that the 356 destination MAC address for data traffic in any frame emitted by the 357 router should be the MAC address of a device in the remote node. DLEP 358 also assumes that MAC addresses are unique within the context of the 359 router-modem session. 361 This document refers to a remote node as a "Destination". 362 Destinations can be identified by either the router or the modem, and 363 represent a specific destination (e.g., an address) that exists on 364 the link(s) managed by the modem. A destination MUST contain a MAC 365 address, it MAY optionally include a Layer 3 address (or addresses). 366 Destinations MAY refer either to physical devices in the network, or 367 to logical destinations, as in a multicast group. As "destinations" 368 are discovered, DLEP routers and modems build an information base on 369 destinations accessible via the modem. Changes in link 370 characteristics MAY then be reported as being "modem-wide" (effecting 371 ALL destinations accessed via the modem) or MAY be neighbor 372 (destination) specific. 374 The DLEP messages concerning destinations thus become the way for 375 routers and modems to maintain, and notify each other about, an 376 information base representing the physical and logical (e.g., 377 multicast) destinations accessible via the modem device. The 378 information base would contain addressing information (e.g., MAC 379 address, and OPTIONALLY, Layer 3 addresses), link characteristics 380 (metrics), and OPTIONALLY, flow control information (credits). 382 DLEP assumes that security on the session (e.g. authentication of 383 session partners, encryption of traffic, or both) is dealt with by 384 the underlying transport mechanism (e.g., by using a transport such 385 as TLS [TLS]). 387 This document specifies an implementation of the DLEP messages and 388 data items running over the TCP transport, utilizing a well-known TCP 389 Port number. It is assumed that DLEP running over other transport 390 mechanisms would be documented separately. 392 3. Credits 394 DLEP includes an OPTIONAL credit-windowing scheme analogous to the 395 one documented in [RFC5578]. In this scheme, traffic between the 396 router and modem is treated as two unidirectional windows. This 397 document identifies these windows as the "Modem Receive Window", or 398 MRW, and the "Router Receive Window", or RRW. 400 If credits are used, they MUST be granted by the receiver on a given 401 window - that is, on the "Modem Receive Window" (MRW), the modem is 402 responsible for granting credits to the router, allowing it (the 403 router) to send data to the modem. Likewise, the router is 404 responsible for granting credits on the RRW, which allows the modem 405 to send data to the router. 407 DLEP expresses all credit data in number of octets. The total number 408 of credits on a window, and the increment to add to a grant, are 409 always expressed as a 64-bit unsigned quantity. 411 If used, credits are managed on a neighbor-specific basis; that is, 412 separate credit counts are maintained for each neighbor requiring the 413 service. Credits do not apply to the DLEP session that exists between 414 routers and modems. 416 4. Metrics 418 DLEP includes the ability for the router and modem to communicate 419 metrics that reflect the characteristics (e.g. datarate, latency) of 420 the variable-quality link in use. DLEP does NOT specify how a given 421 metric value is to be calculated, rather, the protocol assumes that 422 metrics have been calculated with a "best effort", incorporating all 423 pertinent data that is available to the modem device. 425 As mentioned in the introduction section of this document, metrics 426 have to be used within a context - for example, metrics to a unicast 427 address in the network. DLEP allows for metrics to be sent within two 428 contexts - metrics for a specific destination within the network 429 (e.g., a specific router), and "modem-wide" (those that apply to all 430 destinations accessed via the modem). Metrics are further subdivided 431 into transmit and receive metrics. Metrics supplied on DLEP Peer 432 signals are, by definition, modem-wide; metrics supplied on 433 Destination messages signals are, by definition, used for the 434 specific neighbor only. 436 DLEP modem implementations MUST announce all supported metric items, 437 and provide default values for those metrics, in the Peer 438 Initialization message. In order to introduce a new metric type, DLEP 439 modem implementations MUST terminate the session with the router (via 440 the Peer Terminate message), and re-establish the session. 442 It is left to implementations to choose sensible default values based 443 on their specific characteristics. Modems having static (non- 444 changing) link metric characteristics MAY report metrics only once 445 for a given neighbor (or once on a modem-wide basis, if all 446 connections via the modem are of this static nature). 448 The approach of allowing for different contexts for metric data 449 increases both the flexibility and the complexity of using metric 450 data. This document details the mechanism whereby the data is 451 transmitted, however, the specific algorithms (precedence, etc) for 452 utilizing the dual-context metrics is out of scope and not addressed 453 by this document. 455 5. Extensions to DLEP 457 While this draft represents the best efforts of the co-authors, and 458 the working group, to be functionally complete, it is recognized that 459 extensions to DLEP will in all likelihood be necessary as more link 460 types are utilized. To allow for future innovation, the draft 461 allocates numbering space for experimental implementations of both 462 signals and data items. 464 DLEP implementations MUST be capable of parsing and acting on the 465 mandatory messages and data items as documented in this 466 specification. DLEP messages/data items that are optional, or are in 467 the experimental numbering range SHOULD be silently dropped by an 468 implementation if they are not understood. 470 The intent of the optional messages and data items, as well as the 471 experimental numbering space, is to allow for further development of 472 DLEP protocol features and function. Having experimental space 473 reserved for both signals and data items gives maximum flexibility 474 for extending the protocol as conditions warrant. For example, 475 experimental data items could be used by implementations to send 476 additional metrics. A combination of experimental messages, and 477 associated data items, could be used to implement new flow control 478 schemes. If subsequent research and development define new features 479 and function, then it should be standardized either as an update to 480 this document, or as an additional stand-alone specification. 482 6. Normal Session Flow 484 Normal session flow is slightly different, depending on whether the 485 implementation represents a modem or a router, and whether discovery 486 techniques are used. The normal flow by DLEP partner type is: 488 6.1 DLEP Modem session flow - Discovery case 490 If the DLEP modem implementation is utilizing the optional discovery 491 mechanism, then the implementation will initialize a UDP socket, 492 binding it to an arbitrary port. This UDP socket is used to send the 493 Peer Discovery message to the DLEP link-local multicast address and 494 port (TBD). The implementation then waits on receipt of a Peer Offer 495 message, which MUST contain the unicast address and port for TCP- 496 based communication with a DLEP router. The Peer Offer message MAY 497 contain multiple address/port combinations. If more than one 498 address/port combination is in the Peer Offer, the DLEP modem 499 implementation SHOULD consider the list to be in priority sequence, 500 with the "most desired" address/port combination listed first. 501 However, modem implementations MAY use their own heuristics to 502 determine the best address/port combination. At this point, the modem 503 implementation MAY either destroy the UDP socket, or continue to 504 issue Peer Discovery messages to the link-local address/port 505 combination. In either case, the TCP session initialization occurs as 506 in the configured case. 508 6.2 DLEP Modem session flow - Configured case 510 When a DLEP modem implementation has the address and port information 511 for a TCP connection to the router (obtained either via configuration 512 or via the discovery process described above), the modem will 513 initialize and bind a TCP socket. This socket is used to connect to 514 the DLEP router software. After a successful TCP connect, the modem 515 implementation MUST issue a Peer Initialization message to the DLEP 516 router. The Peer Initialization message MUST contain TLVs for ALL 517 supported metrics from this modem (e.g. all MANDATORY metrics plus 518 all OPTIONAL metrics supported by the implementation), along with the 519 default values of those metrics. After sending the Peer 520 Initialization, the modem implementation should wait for receipt of a 521 Peer Initialization ACK message from the router. Receipt of the Peer 522 Initialization ACK indicates that the router has received and 523 processed the Peer Initialization, and the session MUST transition to 524 the "in session" state. At this point, messages regarding 525 destinations in the network, and/or Peer Update messages, can flow on 526 the DLEP session between modem and router. The "in session" state is 527 maintained until one of the following conditions occur: 529 o The session is explicitly terminated (using Peer Termination), or 530 o The session times out, based on supplied timeout values. 532 6.3 DLEP Router session flow 534 DLEP router implementations MUST support the discovery mechanism. 535 Therefore, the normal flow is as follows: 537 The implementation will initialize a UDP socket, binding that socket 538 to the DLEP link-local multicast address (TBD) and the DLEP well- 539 known port number (also TBD). The implementation will then initialize 540 a TCP socket, on a unicast address and port. This socket is used to 541 listen for incoming TCP connection requests. 543 When the router implementation receives a Peer Discovery message on 544 the UDP socket, it responds by issuing a Peer Offer message to the 545 sender of the Peer Discovery. The Peer Offer message MUST contain the 546 unicast address and port of the TCP listen socket, described above. A 547 DLEP router implementation MAY respond with ALL address/port 548 combinations that have an active TCP listen posted. If multiple 549 address/port combinations are listed, the receiver of the Peer Offer 550 MAY connect on any available address/port pair. Anything other than 551 Peer Discovery messages received on the UDP socket MUST be silently 552 dropped. 554 When the DLEP router implementation accepts a connection via TCP, it 555 will wait for receipt of a Peer Initialization message. The received 556 Peer Initialization MUST contain metric TLVs for ALL mandatory 557 metrics, and MUST contain metric TLVs for ANY optional metrics 558 supported by the modem. If a new metric is to be introduced, the DLEP 559 session between router and modem MUST be terminated and restarted, 560 and the new metric described in a Peer Initialization message. 562 6.4 Common Session Flow 564 In order to maintain the session between router and modem, periodic 565 "Heartbeat" messages SHOULD be exchanged. These messages are intended 566 to keep the session alive, and to verify bidirectional connectivity 567 between the two participants. DLEP also provides for an OPTIONAL Peer 568 Update message, intended to communicate some change in status (e.g., 569 a change of layer 3 address parameters, or a modem-wide link change). 571 In addition to the messages above, the participants will transmit 572 DLEP messages concerning destinations in the network. These messages 573 trigger creation/maintenance/deletion of destinations in the 574 information base of the recipient. For example, a modem will inform 575 its attached router of the presence of a new destination via the 576 "Destination Up" signal. Receipt of a Destination Up causes the 577 router to allocate the necessary resources, creating an entry in the 578 information base with the specifics (e.g., MAC Address, Latency, Data 579 Rate, etc) of the neighbor. The loss of a destination is communicated 580 via the "Neighbor Down" signal, and changes in status to the 581 destination (e.g. varying link quality, or addressing changes) are 582 communicated via the "Neighbor Update" signal. The information on a 583 given neighbor will persist in the router's information base until 584 (1) a "Neighbor Down" is received, indicating that the modem has lost 585 contact with the remote node, or (2) the router/modem session 586 terminates, indicating that the router has lost contact with its own 587 local modem. 589 Again, metrics can be expressed within the context of a specific 590 neighbor via the Neighbor Update message, or on a modem-wide basis 591 via the Peer Update message. In cases where metrics are provided on 592 the router/modem session, the receiver MUST propagate the metrics to 593 all destinations in its information base that are accessed via the 594 originator. A DLEP participant MAY send metrics both in a 595 router/modem session context (via the Peer Update message) and a 596 specific neighbor context (via Neighbor Update) at any time. The 597 heuristics for applying received metrics is left to implementations. 599 In addition to receiving metrics about the link, DLEP provides an 600 OPTIONAL signal allowing a router to request a different datarate, or 601 latency, from the modem. This signal is referred to as the Link 602 Characteristics Message, and gives the router the ability to deal 603 with requisite increases (or decreases) of allocated datarate/latency 604 in demand-based schemes in a more deterministic manner. 606 7. Mandatory Signals and Data Items 608 The following DLEP signals are considered core to the specification; 609 implementations MUST support these signals, and the associated data 610 items, in order to be considered compliant: 612 Signal Data Items 613 ====== ========== 614 Peer Discovery (Modem Only) DLEP Version 615 Peer Offer (Router Only) DLEP Version 616 IPv4 or IPv6 address(es) 617 DLEP Port 619 Peer Initialization DLEP Version 620 Maximum Data Rate (Receive) 621 Maximum Data Rate (Transmit) 622 Current Data Rate (Receive) 623 Current Data Rate (Transmit) 624 Latency 625 Relative Link Quality (Receive) 626 Relative Link Quality (Transmit) 628 Peer Initialization ACK Status 630 Peer Termination None 632 Peer Termination ACK Status 634 Destination Up MAC Address 635 Maximum Data Rate (Receive) 636 Maximum Data Rate (Transmit) 637 Current Data Rate (Receive) 638 Current Data Rate (Transmit) 639 Latency 640 Relative Link Quality (Receive) 641 Relative Link Quality (Transmit) 643 Destination Update MAC Address 644 Maximum Data Rate (Receive) 645 Maximum Data Rate (Transmit) 646 Current Data Rate (Receive) 647 Current Data Rate (Transmit) 648 Latency 649 Relative Link Quality (Receive) 650 Relative Link Quality (Transmit) 652 Destination Down MAC Address 654 All other DLEP signals and data items are OPTIONAL. Implementations 655 MAY choose to provide them. Implementations that do not support 656 optional signals and data items SHOULD parse, and silently drop, all 657 unsupported messages and/or data items. 659 8. Generic DLEP Message Definition 661 The Generic DLEP Message consists of a sequence of TLVs. The first 662 TLV represents the signal being communicated (e.g., a "Destination 663 Up", or a "Peer Offer"). Subsequent TLVs contain the data items 664 pertinent to the signal (e.g., Maximum Data Rate, or Latency, etc). 666 The Generic DLEP Packet Definition contains the following fields: 668 0 1 2 3 669 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 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 |Signal TLV Type | Length | DLEP data items... | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 Signal - One of the DLEP Message TLV type values 675 defined in this document. 677 Length - The length, expressed as a 16-bit 678 quantity, of all of the DLEP data items 679 associated with this signal. 681 DLEP data items - One or more data items, encoded in TLVs, 682 as defined in this document. 684 9. DLEP Data Items 686 As mentioned earlier, DLEP protocol messages are transported as a 687 collection of TLVs. The first TLV present in a DLEP message MUST be 688 one of the Signal TLVs, documented in section 10. The signals are 689 followed by one or more data items, indicating the specific changes 690 that need to be instantiated in the receiver's information base. 692 Valid DLEP Data Items are: 694 TLV TLV 695 Value Description 696 ========================================= 697 TBD DLEP Version 698 TBD DLEP Port 699 TBD Peer Type 700 TBD IPv4 Address 701 TBD IPv6 Address 702 TBD Maximum Data Rate (Receive) (MDRR) 703 TBD Maximum Data Rate (Transmit) (MDRT) 704 TBD Current Data Rate (Receive) (CDRR) 705 TBD Current Data Rate (Transmit) (CDRT) 706 TBD Latency 707 TBD Receive Resources 708 TBD Transmit Resources 709 TBD Expected Forwarding Time (EFT) 710 TBD Relative Link Quality (Receive) (RLQR) 711 TBD Relative Link Quality (Transmit) (RLQT) 712 TBD Status 713 TBD Heartbeat Interval/Threshold 714 TBD Neighbor down ACK timer 715 TBD Link Characteristics ACK timer 716 TBD Credit Window Status 717 TBD Credit Grant 718 TBD Credit Request 720 DLEP data item TLVs contain the following fields: 722 0 1 2 3 723 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 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | TLV Type | Length | Value... | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 TLV Type - An 8-bit unsigned integer field specifying the data 729 item being sent. 731 Length - An 8-bit length of the value field of the data item 733 Value - A field of length which contains data 734 specific to a particular data item. 736 9.1 DLEP Version 738 The DLEP Version TLV is a MANDATORY TLV in Peer Discovery, Peer 739 Offer, and Peer Initialization messages. The Version TLV is used to 740 indicate the version of the protocol running in the sender. The 741 receiver SHOULD use this information to decide if the potential 742 session partner is running at a supported level. 744 The DLEP Version 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=4 | Major Version | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | Minor Version | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 TLV Type - TBD 755 Length - Length is 4 757 Major Version - Major version of the modem or router protocol. 759 Minor Version - Minor version of the modem or router protocol. 761 Support of this draft is indicated by setting the Major Version 762 to '1', and the Minor Version to '5' (i.e. Version 1.5). 764 9.2 DLEP Port 766 The DLEP Port TLV is a MANDATORY TLV in the Peer Offer message. The 767 DLEP Port TLV is used to indicate the TCP Port number on the DLEP 768 server available for connections. The receiver MUST use this 769 information to perform the TCP connect to the DLEP server. 771 The DLEP Port TLV contains the following fields: 773 0 1 2 3 774 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 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 |TLV Type =TBD |Length=2 | TCP Port Number | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 TLV Type - TBD 781 Length - Length is 2 783 TCP Port Number - TCP Port number on the DLEP server. 785 Minor Version - Minor version of the modem or router protocol. 787 9.3 Peer Type 789 The Peer Type TLV is an OPTIONAL TLV in both the Peer Discovery and 790 Peer Offer messages. The Peer Type TLV is used by the router and 791 modem to give additional information as to its type. The peer type is 792 a string and is envisioned to be used for informational purposes 793 (e.g. as output in a display command). 795 The Peer Type TLV contains the following fields: 797 0 1 2 3 798 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 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 |TLV Type =TBD |Length= peer |Peer Type String | 801 | |type string len| | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 TLV Type - TBD 806 Length - Length of peer type string. 808 Peer Type String - Non-Null terminated string, using UTF-8 encoding. 809 For example, a satellite modem might set this 810 variable to 'Satellite terminal'. 812 9.4 MAC Address 814 The MAC address TLV MUST appear in all destination-oriented signals 815 (e.g. Destination Up, Destination Up ACK, Destination Down, 816 Destination Down ACK, Destination Update, Link Characteristics 817 Request, and Link Characteristics ACK). The MAC Address TLV contains 818 the address of the destination on the remote node. The MAC address 819 MAY be either a physical or a virtual destination. Examples of a 820 virtual destination would be a multicast MAC address, or the 821 broadcast MAC (0xFFFFFFFFFFFF). 823 0 1 2 3 824 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 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 |TLV Type =TBD |Length = 6 | MAC Address | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | MAC Address | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 TLV Type - TBD 833 Length - 6 835 MAC Address - MAC Address of the destination (either physical or 836 virtual). 838 9.5 IPv4 Address 840 The IPv4 Address TLV is an OPTIONAL TLV. If supported, it MAY appear 841 in Destination Up, Destination Update, and Peer Update messages. When 842 included in Destination messages, the IPv4 Address TLV contains the 843 IPv4 address of the destination, as well as a subnet mask value. In 844 the Peer Update message, it contains the IPv4 address of the 845 originator of the message. In either case, the TLV also contains an 846 indication of whether this is a new or existing address, or is a 847 deletion of a previously known address. 849 The IPv4 Address TLV contains the following fields: 851 0 1 2 3 852 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 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 |TLV Type =TBD |Length = 6 | Add/Drop | IPv4 Address | 855 | | | Indicator | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | IPv4 Address | Subnet Mask | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 TLV Type - TBD 862 Length - 6 864 Add/Drop - Value indicating whether this is a new or existing 865 address (0x01), or a withdrawal of an address (0x02). 867 IPv4 Address - The IPv4 address of the destination or peer. 869 Subnet Mask - A subnet mask (0-32) to be applied to the IPv4 870 address. 872 9.6 IPv6 Address 874 The IPv6 Address TLV is an OPTIONAL TLV. If supported, it MAY be used 875 in the Destination Up, Destination Update, Peer Discovery, and Peer 876 Update Messages. When included in Destination messages, this data 877 item contains the IPv6 address of the destination. In the Peer 878 Discovery and Peer Update, it contains the IPv6 address of the 879 originating peer. In either case, the data item also contains an 880 indication of whether this is a new or existing address, or is a 881 deletion of a previously known address, as well as a subnet mask. 883 The IPv6 Address TLV contains the following fields: 885 0 1 2 3 886 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 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 |TLV Type =TBD |Length = 18 | Add/Drop | IPv6 Address | 889 | | | Indicator | | 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | IPv6 Address | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | IPv6 Address | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | IPv6 Address | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | IPv6 Address | Subnet Mask | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 TLV Type - TBD 902 Length - 18 904 Add/Drop - Value indicating whether this is a new or existing 905 address (0x01), or a withdrawal of an address (0x02). 907 IPv6 Address - IPv6 Address of the destination or peer. 909 Subnet Mask - A subnet mask value (0-128) to be applied to the Ipv6 910 address. 912 9.7 Maximum Data Rate (Receive) 914 The Maximum Data Rate Receive (MDRR) TLV is used in Destination Up, 915 Destination Update, Peer Discovery, Peer Update, and Link 916 Characteristics ACK Messages to indicate the maximum theoretical data 917 rate, in bits per second, that can be achieved while receiving data 918 on the link. When metrics are reported via the messages listed above, 919 the maximum data rate receive MUST be reported. 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 |Length = 8 | MDRR (bps) | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | MDRR (bps) | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | MDRR (bps) | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 TLV Type - TBD 933 Length - 8 935 Maximum Data Rate Receive - A 64-bit unsigned number, representing 936 the maximum theoretical data rate, in bits per 937 second (bps), that can be achieved while 938 receiving on the link. 940 9.8 Maximum Data Rate (Transmit) 941 The Maximum Data Rate Transmit (MDRT) TLV is used in Destination Up, 942 Destination Update, Peer Discovery, Peer Update, and Link 943 Characteristics ACK Messages to indicate the maximum theoretical data 944 rate, in bits per second, that can be achieved while transmitting 945 data on the link. When metrics are reported via the messages listed 946 above, the maximum data rate transmit MUST be reported. 948 0 1 2 3 949 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 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 |TLV Type =TBD |Length = 8 | MDRT (bps) | 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 | MDRT (bps) | 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 | MDRT (bps) | 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 TLV Type - TBD 960 Length - 8 962 Maximum Data Rate Transmit - A 64-bit unsigned number, representing 963 the maximum theoretical data rate, in bits per 964 second (bps), that can be achieved while 965 transmitting on the link. 967 9.9 Current Data Rate (Receive) 969 The Current Data Rate Receive (CDRR) TLV is used in Destination Up, 970 Destination Update, Peer Discovery, Peer Update, Link Characteristics 971 Request, and Link Characteristics ACK messages to indicate the rate 972 at which the link is currently operating for receiving traffic. The 973 Current Data Rate Receive is a MANDATORY data item. In the case of 974 the Link Characteristics Request, CDRR represents the desired receive 975 data rate for the link. When metrics are reported via the messages 976 above (e.g. Destination Update), the current data rate receive MUST 977 be reported. 979 The Current Data Rate Receive TLV contains the following fields: 981 0 1 2 3 982 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 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 |TLV Type =TBD |TLV Flags=0x10 |Length = 8 |CDRR (bps) | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | CDRR (bps) | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | CDRR (bps) | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 TLV Type - TBD 993 Length - 8 995 Current Data Rate Receive - A 64-bit unsigned number, representing 996 the current data rate, in bits per second, that 997 is currently be achieved while receiving traffic 998 on the link. When used in the Link 999 Characteristics Request, CDRR represents the 1000 desired receive rate, in bits per second, on the 1001 link. If there is no distinction between current 1002 and maximum receive data rates, current data 1003 rate receive SHOULD be set equal to the maximum 1004 data rate receive. 1006 9.10 Current Data Rate (Transmit) 1008 The Current Data Rate Receive (CDRT) TLV is used in Destination Up, 1009 Destination Update, Peer Discovery, Peer Update, Link Characteristics 1010 Request, and Link Characteristics ACK messages to indicate the rate 1011 at which the link is currently operating for transmitting traffic. 1012 Current Data Rate Transmit is a MANDATORY data item. In the case of 1013 the Link Characteristics Request, CDRT represents the desired 1014 transmit data rate for the link. When metrics are reported via the 1015 messages above (e.g. Destination Update), the current data rate 1016 transmit MUST be reported. 1018 The Current Data Rate Transmit TLV contains the following fields: 1020 0 1 2 3 1021 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 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 |TLV Type =TBD |TLV Flags=0x10 |Length = 8 |CDRT (bps) | 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 | CDRT (bps) | 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 | CDRT (bps) | 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 TLV Type - TBD 1032 Length - 8 1034 Current Data Rate Transmit - A 64-bit unsigned number, representing 1035 the current data rate, in bits per second, that 1036 is currently be achieved while transmitting 1037 traffic on the link. When used in the Link 1038 Characteristics Request, CDRT represents the 1039 desired transmit rate, in bits per second, on 1040 the link. If there is no distinction between 1041 current and maximum transmit data rates, current 1042 data rate transmit MUST be set equal to the 1043 maximum data rate transmit. 1045 9.11 Expected Forwarding Time 1047 The Expected Forwarding Time (EFT) TLV is is an OPTIONAL data item. 1048 If supported, it MAY be used in Destination Up, Destination Update, 1049 Peer Discovery, and Peer Update messages to indicate the typical 1050 latency between the arrival of a given packet at the transmitting 1051 device and the reception of the packet at the other end of the link. 1052 EFT combines transmission time, idle time, waiting time, freezing 1053 time, and queuing time to the degree that those values are meaningful 1054 to a given transmission medium. 1056 The Expected Forwarding Time TLV contains the following fields: 1058 0 1 2 3 1059 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 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 |TLV Type =TBD |Length = 4 | EFT (ms) | 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 | EFT (ms) | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 TLV Type - TBD 1068 Length - 4 1070 EFT - A 32-bit unsigned number, representing the expected 1071 forwarding time, in milliseconds, on the link. 1073 9.12 Latency 1075 The Latency TLV is an MANDATORY data item. It is used in Peer 1076 Initialization, Destination Up, Destination Update, Peer Discovery, 1077 Peer Update, Link Characteristics Request, and Link Characteristics 1078 ACK messages to indicate the amount of latency on the link, or in the 1079 case of the Link Characteristics Request, to indicate the maximum 1080 latency required on the link. 1082 0 1 2 3 1083 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 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 |TLV Type =TBD |Length = 2 | Latency (ms) | 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 TLV Type - TBD 1090 Length - 2 1092 Latency - A 16-bit unsigned value, representing the transmission 1093 delay that a packet encounters as it is transmitted 1094 over the link. In Destination Up, Destination Update, 1095 and Link Characteristics ACK, this value is reported 1096 as delay, in milliseconds. The calculation of latency 1097 is implementation dependent. For example, the latency 1098 may be a running average calculated from the internal 1099 queuing. If a device cannot calculate latency, this 1100 TLV SHOUD NOT be issued. In the Link Characteristics 1101 Request Message, this value represents the maximum 1102 delay, in milliseconds, expected on the link. 1104 9.13 Resources (Receive) 1106 The Receive Resources TLV is an OPTIONAL data item. If supported, it 1107 is used in Destination Up, Destination Update, Peer Discovery, Peer 1108 Update, and Link Characteristics ACK messages to indicate a 1109 percentage (0-100) amount of resources (e.g. battery power), 1110 committed to receiving data, remaining on the originating peer. 1112 The Resources TLV contains the following fields: 1114 0 1 2 1115 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 |TLV Type =TBD |Length = 1 | Rcv Resources| 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 TLV Type - TBD 1122 Length - 1 1124 Receive Resources - A percentage, 0-100, representing the amount 1125 of remaining resources, such as battery power, 1126 allocated to receiving data. If a device cannot 1127 calculate receive resources, this TLV SHOULD NOT be 1128 issued. 1130 9.14 Resources (Transmit) 1132 The Transmit Resources TLV is an OPTIONAL data item. If supported, it 1133 is used in Destination Up, Destination Update, Peer Discovery, Peer 1134 Update, and Link Characteristics ACK messages to indicate a 1135 percentage (0-100) amount of resources (e.g. battery power), 1136 committed to transmitting data, remaining on the originating peer. 1138 The Resources TLV contains the following fields: 1140 0 1 2 1141 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 |TLV Type =TBD |Length = 1 | Xmt Resources| 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 TLV Type - TBD 1148 Length - 1 1150 Transmit Resources - A percentage, 0-100, representing the amount 1151 of remaining resources, such as battery power, 1152 allocated to transmitting data. If the transmit 1153 resources cannot be calculated, then the TLV SHOULD 1154 NOT be issued. 1156 9.15 Relative Link Quality (Receive) 1158 The Relative Link Quality Receive (RLQR) TLV is a MANDATORY data 1159 item. If supported, it is used in Peer Initialization, Destination 1160 Up, Destination Update, Peer Discovery, Peer Update, and Link 1161 Characteristics ACK messages to indicate the quality of the link for 1162 receiving data as calculated by the originating peer. 1164 The Relative Link Quality (Receive) TLV contains the following 1165 fields: 1167 0 1 2 1168 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1170 |TLV Type =TBD |Length = 1 |RCV Rel. Link | 1171 | | |Quality (RLQR) | 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1174 TLV Type - TBD 1175 Length - 1 1177 Relative Link Quality (Receive) - A non-dimensional number, 1-100, 1178 representing relative link quality. A value of 1179 100 represents a link of the highest quality. 1180 If a device cannot calculate the RLQR, this 1181 TLV SHOULD NOT be issued. 1183 9.16 Relative Link Quality (Transmit) 1185 The Transmit Link Quality Receive (RLQT) TLV is a MANDATORY data 1186 item. It is used in Peer Initialization, Destination Up, Destination 1187 Update, Peer Discovery, Peer Update, and Link Characteristics ACK 1188 messages to indicate the quality of the link for transmitting data as 1189 calculated by the originating peer. 1191 The Relative Link Quality (Transmit) TLV contains the following 1192 fields: 1194 0 1 2 1195 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 |TLV Type =TBD |Length = 1 |XMT Rel. Link | 1198 | | |Quality (RLQR) | 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 TLV Type - TBD 1203 Length - 1 1205 Relative Link Quality (Transmit) - A non-dimensional number, 1-100, 1206 representing relative link quality. A value of 1207 100 represents a link of the highest quality. 1208 If a device cannot calculate the RLQT, this 1209 TLV SHOULD NOT be issued. 1211 9.17 Status 1213 The Status TLV is sent as part of an acknowledgement message, from 1214 either the modem or the router, to indicate the success or failure of 1215 a given request. 1217 The Status TLV contains the following fields: 1219 0 1 2 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 1222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1223 |TLV Type =TBD |Length = 1 | Code | 1224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 TLV Type - TBD 1228 Length - 1 1230 Termination Code - 0 = Success, Non-zero = Failure. Specific values 1231 of a non-zero termination code depend on the 1232 operation requested (e.g. Destination Up, 1233 Destination Down, etc). 1235 9.18 Heartbeat Interval 1237 The Heartbeat Interval TLV is a MANDATORY TLV. It MUST be sent during 1238 Peer Initialization to indicate the desired Heartbeat timeout window. 1239 The router MUST either accept the timeout interval supplied by the 1240 modem, or reject the Peer Initialization, and close the socket. 1241 Implementations MUST implement heuristics such that DLEP signals 1242 sent/received reset the timer interval. 1244 The Interval is used to specify a period (in seconds) for Heartbeat 1245 Messages (See Section 23). By specifying an Interval value of 0, 1246 implementations MAY indicates the desire to disable Heartbeat 1247 messages entirely (e.g., the Interval is set to an infinite value), 1248 however, it is strongly recommended that implementations use non 0 1249 timer values. 1251 A DLEP session will be considered inactive, and MUST be torn down, by 1252 an implementation detecting that two (2) Heartbeat intervals have 1253 transpired without receipt of any DLEP messages. 1255 The Heartbeat Interval TLV contains the following fields: 1257 0 1 2 3 1258 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 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 |TLV Type =TBD |Length = 2 | Interval | 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 TLV Type - TBD 1265 Length - 2 1267 Interval - 0 = Do NOT use heartbeats on this peer-to-peer 1268 session. Non-zero = Interval, in seconds, for 1269 heartbeat messages. 1271 9.19 Link Characteristics ACK Timer 1273 The Link Characteristics ACK Timer TLV is an OPTIONAL TLV. If 1274 supported, it MAY be sent during Peer Initialization to indicate the 1275 desired number of seconds to wait for a response to a Link 1276 Characteristics Request. If a router receives this TLV from a modem 1277 during Peer Discovery, the router MUST either accept the timeout 1278 value, or reject the Peer Discovery. If this TLV is omitted, 1279 implementations supporting the Link Characteristics Request SHOULD 1280 choose a default value. 1282 The Link Characteristics ACK Timer TLV contains the following fields: 1284 0 1 2 1285 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 |TLV Type =TBD |Length = 1 | Interval | 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1290 TLV Type - TBD 1292 Length - 1 1294 Interval - 0 = Do NOT use timeouts for Link Characteristics 1295 requests on this router/modem session. Non-zero = 1296 Interval, in seconds, to wait before considering a 1297 Link Characteristics Request has been lost. 1299 9.20 Credit Window Status 1301 The Credit Window Status TLV is an OPTIONAL TLV. If credits are 1302 supported by the DLEP participants (both the router and the modem), 1303 the Credit Window Status TLV MUST be sent by the participant 1304 receiving a Credit Grant Request for a given destination. 1306 The Credit Window Status TLV contains the following fields: 1308 0 1 2 3 1309 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 1310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1311 |TLV Type =TBD |Length = 16 | Modem Receive Window Value | 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1313 | Modem Receive Window Value | 1314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1315 | Modem Receive Window Value | Router Receive Window Value | 1316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1317 | Router Receive Window Value | 1318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1319 | Router Receive Window Value | 1320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1322 TLV Type - TBD 1324 Length - 16 1326 Modem Receive Window Value - A 64-bit unsigned number, indicating 1327 the current (or initial) number of 1328 credits available on the Modem Receive 1329 Window. 1331 Router Receive Window Value - A 64-bit unsigned number, indicating 1332 the current (or initial) number of 1333 credits available on the Router Receive 1334 Window. 1336 9.21 Credit Grant Request 1338 The Credit Grant Request TLV is an OPTIONAL TLV. If credits are 1339 supported, the Credit Grant Request TLV is sent from a DLEP 1340 participant to grant an increment to credits on a window. The Credit 1341 Grant TLV is sent as a data item in either the Destination Up or 1342 Destination Update messages. The value in a Credit Grant TLV 1343 represents an increment to be added to any existing credits available 1344 on the window. Upon successful receipt and processing of a Credit 1345 Grant TLV, the receiver MUST respond with a message containing a 1346 Credit Window Status TLV to report the updated aggregate values for 1347 synchronization purposes. 1349 In the Destination Up message, when credits are desired, the 1350 originating peer MUST set the initial credit value of the window it 1351 controls (e.g. the Modem Receive Window, or Router Receive Window) to 1352 an initial, non-zero value. If the receiver of a Destination Up 1353 message with a Credit Grant Request TLV supports credits, the 1354 receiver MUST either reject the use of credits, via a Destination Up 1355 ACK response with the correct Status TLV, or set the initial value 1356 from the data contained in the Credit Window Status TLV. If the 1357 initialization completes successfully, the receiver MUST respond to 1358 the Destination Up message with a Destination Up ACK message that 1359 contains a Credit Window Status TLV, initializing its receive window. 1361 The Credit Grant TLV contains the following fields: 1363 0 1 2 3 1364 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 1365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1366 |TLV Type =TBD |Length = 8 | Credit Increment | 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 | Credit Increment | 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 | Credit Increment | 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 TLV Type - TBD 1375 Length - 8 1377 Reserved - A 64-bit unsigned number representing the 1378 additional credits to be assigned to the credit 1379 window. Since credits can only be granted by the 1380 receiver on a window, the applicable credit window 1381 (either the MRW or the RRW) is derived from the 1382 sender of the grant. The Credit Increment MUST NOT 1383 cause the window to overflow; if this condition 1384 occurs, implementations MUST set the credit window 1385 to the maximum value contained in a 64-bit 1386 quantity. 1388 9.22 Credit Request 1390 The Credit Request TLV is an OPTIONAL TLV. If credits are supported, 1391 the Credit Request TLV MAY be sent from either DLEP participant, via 1392 a Destination Update signal, to indicate the desire for the partner 1393 to grant additional credits in order for data transfer to proceed on 1394 the session. If the corresponding Destination Up message for this 1395 session did NOT contain a Credit Window Status TLV, indicating that 1396 credits are to be used on the session, then the Credit Request TLV 1397 MUST be rejected by the receiver via a Destination Update ACK 1398 message. 1400 The Credit Request TLV contains the following fields: 1402 0 1 2 1403 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1405 |TLV Type =TBD |Length = 0 | Reserved, MUST| 1406 | | | be set to 0 | 1407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 TLV Type - TBD 1410 Length - 0 1412 Reserved - This field is currently unused and MUST be set to 0. 1414 10. DLEP Protocol Messages 1416 DLEP messages are encoded as a string of Type-Length-Value (TLV) 1417 constructs. The first TLV in a DLEP message MUST be a valid DLEP 1418 signal, as defined in section 11.1 of this document. The second TLV 1419 MUST be the Identification data item, defined in section 10.1 1420 Following those two TLVs are 0 or more TLVs, representing the data 1421 items that are appropriate for the signal. The layout of a DLEP 1422 message is thus: 1424 0 1 2 3 1425 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 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 | DLEP Signal |DLEP Message |Identification |Identification | 1428 | Type value |length (9 + |TLV Type |TLV length | 1429 | (value TBD) |optional TLVs) |(TBD) |(8) | 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1431 | Router ID | 1432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1433 | Modem ID | 1434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1435 | Start of optional DLEP | 1436 | TLVs... | 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1439 All DLEP messages (signals) begin with this structure. Therefore, in 1440 the following descriptions of specific messages, this header 1441 structure is assumed, and will not be replicated. 1443 10.1 Signal TLV Values 1445 As mentioned above, all DLEP messages begin with the Type value of 1446 the appropriate DLEP signal. Valid DLEP signals are: 1448 TLV TLV 1449 Value Description 1450 ========================================= 1451 TBD Peer Discovery 1452 TBD Peer Offer 1453 TBD Peer Initialization 1454 TBD Peer Update 1455 TBD Peer Update ACK 1456 TBD Peer Termination 1457 TBD Peer Termination ACK 1458 TBD Destination Up 1459 TBD Destination Up ACK 1460 TBD Destination Down 1461 TBD Destination Down ACK 1462 TBD Destination Update 1463 TBD Heartbeat 1464 TBD Link Characteristics Request 1465 TBD Link Characteristics ACK 1467 10.2 Peer Discovery Message 1469 The Peer Discovery Message is sent by a modem to discover DLEP 1470 routers in the network. The Peer Offer message is required to 1471 complete the discovery process. Implementations MAY implement their 1472 own retry heuristics in cases where it is determined the Peer 1473 Discovery Message has timed out. 1475 Given the packet format described in section 11, the initial TLV Type 1476 value is set to DLEP_PEER_DISCOVERY (value TBD). 1478 There are NO Data Item TLVs associated with the Peer Discovery 1479 message. 1481 10.3 Peer Offer Message 1483 The Peer Offer Message is sent by a DLEP router in response to a Peer 1484 Discovery Message. Upon receipt, and processing, of a Peer Offer 1485 message, the modem responds by issuing a TCP connect to the 1486 address/port combination specified in the received Peer Offer. 1488 The Peer Offer message MUST be sent to the unicast address of the 1489 originator of Peer Discovery. 1491 To construct a Peer Offer message, the initial TLV type value is set 1492 to DLEP_PEER_OFFER (value TBD). The signal TLV is then followed by 1493 all MANDATORY Data Item TLVs, then by any OPTIONAL Data Item TLVs the 1494 implementation supports: 1496 Mandatory Data Item TLVs: 1497 - DLEP Version 1498 - Heartbeat Interval 1499 - At least one (1) IPv4 or IPv6 Address TLV 1500 - DLEP Port 1502 Optional Data Item TLVs: 1503 - Peer Type 1504 - Status 1506 10.4 Peer Initialization Message 1508 The Peer Initialization message is sent by a modem to start the DLEP 1509 TCP session. It is sent by the modem after a TCP connect to the 1510 address/port combination in a received Peer Offer, or to an 1511 address/port obtained from a-priori configuration. 1513 All supported metric data items MUST be included in the Peer 1514 Initialization message, with default values to be used on a "modem- 1515 wide" basis. This can be viewed as the modem "declaring" all 1516 supported metrics at DLEP session initialization. Receipt of any DLEP 1517 message containing a metric data item NOT included in Peer 1518 Initialization MUST be treated as an error, resulting in termination 1519 of the DLEP session between router and modem. 1521 To construct a Peer Initialization message, the initial TLV type 1522 value is set to DLEP_PEER_INIT (value TBD). The signal TLV is then 1523 followed by the required data items: 1525 Mandatory Data Item TLVs: 1526 - DLEP Version 1527 - Heartbeat Interval 1528 - Maximum Data Rate Receive 1529 - Maximum Data Rate Transmit 1530 - Current Data Rate Receive 1531 - Current Data Rate Transmit 1532 - Latency 1533 - Relative Link Quality Receive 1534 - Relative Link Quality Transmit 1535 Optional Data Item TLVs: 1536 - Peer Type 1537 Note that metric data items MUST be supplied with the Peer 1538 Initialization, in order to populate default metric values. If, at 1539 any time, metrics are reported that were NOT in Peer Initialization, 1540 the receiving DLEP peer MUST treat this as a fatal error requiring 1541 termination of the DLEP session. 1543 10.5 Peer Initialization ACK Message 1545 The Peer Initialization ACK message is a MANDATORY message, sent in 1546 response to a received Peer Initialization message. The Peer 1547 Initialization ACK message completes the TCP-level DLEP session 1548 establishment; the sender of the message should transition to an "in- 1549 session" state when the message is sent, and the receiver should 1550 transition to the "in-session" state upon receipt (and successful 1551 parsing) of Peer Initialization ACK. 1553 To construct a Peer Initialization ACK message, the initial TLV type 1554 value is set to DLEP_PEER_INIT_ACK (value TBD). The signal TLV is 1555 then followed by the required data items: 1557 Mandatory Data Item TLVs: 1558 - Status 1559 Optional Data Item TLVs: 1560 - Peer Type 1562 10.6 Peer Update Message 1564 The Peer Update message is an OPTIONAL message, sent by a DLEP peer 1565 to indicate local Layer 3 address changes, or for metric changes on a 1566 modem-wide basis. For example, addition of an IPv4 address to the 1567 router MAY prompt a Peer Update message to its attached DLEP modems. 1568 Also, a modem that changes its Maximum Data Rate for all destinations 1569 MAY reflect that change via a Peer Update Message to its attached 1570 router(s). 1572 Concerning Layer 3 addresses, if the modem is capable of 1573 understanding and forwarding this information (via proprietary 1574 mechanisms), the address update would prompt any remote DLEP modems 1575 (DLEP-enabled modems in a remote node) to issue a "Destination 1576 Update" message to their local routers with the new (or deleted) 1577 addresses. Modems that do not track Layer 3 addresses SHOULD silently 1578 parse and ignore the Peer Update Message. Modems that track Layer 3 1579 addresses MUST acknowledge the Peer Update with a Peer Update ACK 1580 message. Routers receiving a Peer Update with metric changes MUST 1581 apply the new metric to all destinations (remote nodes) accessible 1582 via the modem. Supporting implementations are free to employ 1583 heuristics to retransmit Peer Update messages. The sending of Peer 1584 Update Messages for Layer 3 address changes SHOULD cease when a 1585 either participant (router or modem) determines that the other 1586 implementation does NOT support Layer 3 address tracking. 1588 If metrics are supplied with the Peer Update message (e.g. Maximum 1589 Data Rate), these metrics are considered to be modem-wide, and 1590 therefore MUST be applied to all destinations in the information base 1591 associated with the router/modem session. 1593 To construct a Peer Update message, the initial TLV type value is set 1594 to DLEP_PEER_UPDATE (value TBD). The Signal TLV is followed by any 1595 OPTIONAL Data Item TLVs. 1597 Optional Data Item TLVs: 1598 - IPv4 Address 1599 - IPv6 Address 1600 - Maximum Data Rate (Receive) 1601 - Maximum Data Rate (Transmit) 1602 - Current Data Rate (Receive) 1603 - Current Data Rate (Transmit) 1604 - Latency 1605 - Expected Forwarding Time 1606 - Resources (Receive) 1607 - Resources (Transmit) 1608 - Relative Link Quality (Receive) 1609 - Relative Link Quality (Transmit) 1611 10.7 Peer Update ACK Message 1613 The Peer Update ACK message is an OPTIONAL message, and is sent by 1614 implementations supporting Layer 3 address tracking and/or modem-wide 1615 metrics to indicate whether a Peer Update Message was successfully 1616 processed. If the Peer Update ACK is issued, it MUST contain a Status 1617 data item, indicating the success or failure of processing the 1618 received Peer Update. 1620 To construct a Peer Update ACK message, the initial TLV type value is 1621 set to DLEP_PEER_UPDATE_ACK (value TBD). The Status data item TLV is 1622 placed in the packet next, completing the Peer Update ACK. 1624 Mandatory Data Item TLVs: 1626 - Status 1628 Note that there are NO OPTIONAL data item TLVs specified for this 1629 message. 1631 10.8 Peer Termination Message 1633 The Peer Termination Message is sent by a DLEP participant when the 1634 router/modem session needs to be terminated. Implementations 1635 receiving a Peer Termination message MUST send a Peer Termination ACK 1636 message to confirm the termination process. The sender of a Peer 1637 Termination message is free to define its heuristics in event of a 1638 timeout. The receiver of a Peer Termination Message MUST release all 1639 resources allocated for the router/modem session, and MUST eliminate 1640 all destinations in the information base accessible via the 1641 router/modem pair represented by the session. Router and modem state 1642 machines are returned to the "discovery" state. No Destination Down 1643 messages are sent. 1645 To construct a Peer Termination message, the initial TLV type value 1646 is set to DLEP_PEER_TERMINATION (value TBD). The Signal TLV is 1647 followed by any OPTIONAL Data Item TLVs the implementation supports: 1649 Optional Data Item TLVs: 1651 - Status 1653 10.9 Peer Termination ACK Message 1655 The Peer Termination Message ACK is sent by a DLEP peer in response 1656 to a received Peer Termination order. Receipt of a Peer Termination 1657 ACK message completes the teardown of the router/modem session. 1659 To construct a Peer Termination ACK message, the initial TLV type 1660 value is set to DLEP_PEER_TERMINATION_ACK (value TBD). The 1661 Identification data item TLV is placed in the packet next, followed 1662 by any OPTIONAL TLVs the implementation supports: 1664 Optional Data Item TLVs: 1666 - Status 1668 10.10 Destination Up Message 1670 A DLEP participant sends the Destination Up message to report that a 1671 new destination has been detected. A Destination Up ACK Message is 1672 required to confirm a received Destination Up. A Destination Up 1673 message can be sent either by the modem, to indicate that a new 1674 remote node has been detected, or by the router, to indicate the 1675 presence of a new logical destination (e.g., a Multicast group) 1676 exists in the network. 1678 The sender of the Destination Up Message is free to define its retry 1679 heuristics in event of a timeout. When a Destination Up message is 1680 received and successfully parsed, the receiver should add knowledge 1681 of the new destination to its information base, indicating that the 1682 destination is accessible via the modem/router pair. 1684 To construct a Destination Up message, the initial TLV type value is 1685 set to DLEP_Destination_UP (value TBD). The MAC Address data item TLV 1686 is placed in the packet next, followed by any supported OPTIONAL Data 1687 Item TLVs into the packet: 1689 Optional Data Item TLVs: 1691 - IPv4 Address 1692 - IPv6 Address 1693 - Maximum Data Rate (Receive) 1694 - Maximum Data Rate (Transmit) 1695 - Current Data Rate (Receive) 1696 - Current Data Rate (Transmit) 1697 - Latency 1698 - Expected Forwarding Time 1699 - Resources (Receive) 1700 - Resources (Transmit) 1701 - Relative Link Factor (Receive) 1702 - Relative Link Factor (Transmit) 1703 - Credit Window Status 1705 10.11 Destination Up ACK Message 1707 A DLEP participant sends the Destination Up ACK Message to indicate 1708 whether a Destination Up Message was successfully processed. 1710 To construct a Destination Up ACK message, the initial TLV type value 1711 is set to DLEP_Destination_UP_ACK (value TBD). The MAC Address data 1712 item TLV is placed in the packet next, containing the MAC address of 1713 the DLEP destination. The implementation would then place any 1714 supported OPTIONAL Data Item TLVs into the packet: 1716 Optional Data Item TLVs: 1717 - Credit Window Status 1719 10.12 Destination Down Message 1721 A DLEP peer sends the Destination Down message to report when a 1722 destination (a remote node or a multicast group) is no longer 1723 reachable. The Destination Down message MUST contain the MAC Address 1724 data item TLV. Other TLVs as listed are OPTIONAL, and MAY be present 1725 if an implementation supports them. A Destination Down ACK Message 1726 MUST be sent by the recipient of a Destination Down message to 1727 confirm that the relevant data has been removed from the information 1728 base. The sender of the Destination Down message is free to define 1729 its retry heuristics in event of a timeout. 1731 To construct a Destination Down message, the initial TLV type value 1732 is set to DLEP_Destination_DOWN (value TBD). The signal TLV is 1733 followed by the mandatory MAC Address data item TLV. 1735 Note that there are NO OPTIONAL data item TLVs for this message. 1737 10.13 Destination Down ACK Message 1739 A DLEP participant sends the Destination Down ACK Message to indicate 1740 whether a received Destination Down Message was successfully 1741 processed. If successfully processed, the sender of the ACK MUST have 1742 removed all entries in the information base that pertain to the 1743 referenced destination. As with the Destination Down message, there 1744 are NO OPTIONAL Data Item TLVs defined for the Destination Down ACK 1745 message. 1747 To construct a Destination Down message, the initial TLV type value 1748 is set to DLEP_Destination_DOWN_ACK (value TBD). The mandatory data 1749 item TLVs follow: 1751 - MAC Address Data item 1752 - Status data item 1754 10.14 Destination Update Message 1756 A DLEP participant sends the Destination Update message when it 1757 detects some change in the information base for a given destination 1758 (remote node or multicast group). Some examples of changes that would 1759 prompt a Destination Update message are: 1761 - Change in link metrics (e.g., Data Rates) 1762 - Layer 3 addressing change (for implementations that support it) 1764 To construct a Destination Update message, the initial TLV type value 1765 is set to DLEP_Destination_UPDATE (value TBD). Following the signal 1766 TLV are the mandatory Data Item TLVs: 1768 MAC Address data item TLV 1770 After placing the mandatory data item TLV into the packet, the 1771 implementation would place any supported OPTIONAL data item TLVs. 1772 Possible OPTIONAL data item TLVs are: 1774 - IPv4 Address 1775 - IPv6 Address 1776 - Maximum Data Rate (Receive) 1777 - Maximum Data Rate (Transmit) 1778 - Current Data Rate (Receive) 1779 - Current Data Rate (Transmit) 1780 - Latency 1781 - Resources (Receive) 1782 - Resources (Transmit) 1783 - Relative Link Quality (Receive) 1784 - Relative Link Quality (Transmit) 1785 - Credit Window Status 1786 - Credit Grant 1787 - Credit Request 1789 10.15 Heartbeat Message 1790 A Heartbeat Message is sent by a DLEP participant every N seconds, 1791 where N is defined in the "Heartbeat Interval" field of the discovery 1792 message. Note that implementations setting the Heartbeat Interval to 1793 0 effectively set the interval to an infinite value, therefore, in 1794 those cases, this message would NOT be sent. 1796 The message is used by participants to detect when a DLEP session 1797 partner (either the modem or the router) is no longer communicating. 1798 Participants SHOULD allow two (2) heartbeat intervals to expire with 1799 no traffic on the router/modem session before initiating DLEP session 1800 termination procedures. 1802 To construct a Heartbeat message, the initial TLV type value is set 1803 to DLEP_PEER_HEARTBEAT (value TBD). The signal TLV is followed by the 1804 mandatory Heartbeat Interval/Threshold data item. 1806 Note that there are NO OPTIONAL data item TLVs for this message. 1808 10.16 Link Characteristics Request Message 1810 The Link Characteristics Request Message is an OPTIONAL message, and 1811 is sent by the router to request that the modem initiate changes for 1812 specific characteristics of the link. The request can reference 1813 either a real (e.g., a remote node), or a logical (e.g., a multicast 1814 group) destination within the network. 1816 The Link Characteristics Request message contains either a Current 1817 Data Rate (CDRR or CDRT) TLV to request a different datarate than 1818 what is currently allocated, a Latency TLV to request that traffic 1819 delay on the link not exceed the specified value, or both. A Link 1820 Characteristics ACK Message is required to complete the request. 1821 Implementations are free to define their retry heuristics in event of 1822 a timeout. Issuing a Link Characteristics Request with ONLY the MAC 1823 Address TLV is a mechanism a peer MAY use to request metrics (via the 1824 Link Characteristics ACK) from its partner. 1826 To construct a Link Characteristics Request message, the initial TLV 1827 type value is set to DLEP_Destination_LINK_CHAR_REQ (value TBD). 1828 Following the signal TLV is the mandatory Data Item TLV: 1830 MAC Address data item TLV 1832 After placing the mandatory data item TLV into the packet, the 1833 implementation would place any supported OPTIONAL data item TLVs. 1834 Possible OPTIONAL data item TLVs are: 1836 Current Data Rate - If present, this value represents the NEW (or 1837 unchanged, if the request is denied) Current 1838 Data Rate in bits per second (bps). 1840 Latency - If present, this value represents the maximum 1841 desired latency (e.g., it is a not-to-exceed 1842 value) in milliseconds on the link. 1844 10.17 Link Characteristics ACK Message 1846 The LInk Characteristics ACK message is an OPTIONAL message, and is 1847 sent by modems supporting it to the router letting the router know 1848 the success or failure of a requested change in link characteristics. 1849 The Link Characteristics ACK message SHOULD contain a complete set 1850 of metric data item TLVs. It MUST contain the same TLV types as the 1851 request. The values in the metric data item TLVs in the Link 1852 Characteristics ACK message MUST reflect the link characteristics 1853 after the request has been processed. 1855 To construct a Link Characteristics Request ACK message, the initial 1856 TLV type value is set to DLEP_Destination_LINK_CHAR_ACK (value TBD). 1857 Following the signal TLV is the mandatory Data Item TLV: 1859 MAC Address data item TLV 1861 After placing the mandatory data item TLV into the packet, the 1862 implementation would place any supported OPTIONAL data item TLVs. 1863 Possible OPTIONAL data item TLVs are: 1865 Current Data Rate - If present, this value represents the requested 1866 data rate in bits per second (bps). 1868 Latency - If present, this value represents the NEW 1869 maximum latency (or unchanged, if the request 1870 is denied), expressed in milliseconds, on the 1871 link. 1873 11. Security Considerations 1875 The protocol does not contain any mechanisms for security (e.g. 1876 authentication or encryption). The protocol assumes that any security 1877 would be implemented in the underlying transport (for example, by use 1878 of DTLS or some other mechanism), and is therefore outside the scope 1879 of this document. 1881 12. IANA Considerations 1883 This section specifies requests to IANA. 1885 12.1 Registrations 1887 This specification defines: 1889 o A new repository for DLEP signals, with fifteen values currently 1890 assigned. 1892 o Reservation of numbering space for Experimental DLEP signals. 1894 o A new repository for DLEP Data Items, with twenty-one values 1895 currently assigned. 1897 o Reservation of numbering space in the Data Items repository for 1898 experimental data items. 1900 o A request for allocation of a well-known port for DLEP 1901 communication. 1903 o A request for allocation of a multicast address for DLEP 1904 discovery. 1906 12.2 Expert Review: Evaluation Guidelines 1908 No additional guidelines for expert review are anticipated. 1910 12.3 Message (Signal) TLV Type Registration 1912 A new repository must be created with the values of the DLEP 1913 messages. Valid signals are: 1915 o Peer Discovery 1916 o Peer Offer 1917 o Peer Initialization 1918 o Peer Initialization ACK 1919 o Peer Update 1920 o Peer Update ACK 1921 o Peer Termination 1922 o Peer Termination ACK 1923 o Destination Up 1924 o Destination Up ACK 1925 o Destination Down 1926 o Destination Down ACK 1927 o Destination Update 1928 o Heartbeat 1929 o Link Characteristics Request 1930 o Link Characteristics ACK 1932 It is also requested that the repository contain space for 1933 experimental signal types. 1935 12.4 DLEP Data Item Registrations 1937 A new repository for DLEP Data Items must be created. Valid Data 1938 Items are: 1940 o DLEP Version 1941 o Peer Type 1942 o MAC Address 1943 o IPv4 Address 1944 o IPv6 Address 1945 o Maximum Data Rate (Receive) 1946 o Maximum Data Rate (Transmit) 1947 o Current Data Rate (Receive) 1948 o Current Data Rate (Transmit) 1949 o Latency 1950 o Expected Forwarding Time 1951 o Resources (Receive) 1952 o Resources (Transmit) 1953 o Relative Link Quality (Receive) 1954 o Relative Link Quality (Transmit) 1955 o Status 1956 o Heartbeat Interval/Threshold 1957 o Link Characteristics ACK Timer 1958 o Credit Window Status 1959 o Credit Grant 1960 o Credit Request 1962 It is also requested that the registry allocation contain space for 1963 experimental data items. 1965 12.5 DLEP Well-known Port 1967 It is requested that IANA allocate a well-known port number for DLEP 1968 communication. 1970 12.6 DLEP Multicast Address 1972 It is requested that IANA allocate a multicast address for DLEP 1973 discovery messages. 1975 13. Appendix A. 1977 13.1 Peer Level Message Flows 1978 13.1.1 Modem Device Restarts Discovery 1980 Router Modem Message Description 1981 ==================================================================== 1983 <-------Peer Discovery--------- Modem initiates discovery 1985 ---------Peer Offer-----------> Router detects a problem, sends 1986 w/ Non-zero Status TLV Peer Offer w/Status TLV indicating 1987 the error. 1989 Modem accepts failure, restarts 1990 discovery process. 1992 <-------Peer Discovery--------- Modem initiates discovery 1994 ---------Peer Offer-----------> Router accepts, sends Peer Offer 1995 w/ Zero Status TLV w/ Status TLV indicating success. 1997 Discovery completed. 1999 13.1.2 Modem Device Detects Peer Offer Timeout 2001 Router Modem Message Description 2002 ==================================================================== 2004 <-------Peer Discovery--------- Modem initiates discovery, starts 2005 a guard timer. 2007 Modem guard timer expires. Modem 2008 restarts discovery process. 2010 <-------Peer Discovery--------- Modem initiates discovery, starts 2011 a guard timer. 2013 ---------Peer Offer-----------> Router accepts, sends Peer Offer 2014 w/ Zero Status TLV w/ Status TLV indicating success. 2016 Discovery completed. 2018 13.1.3 Router Peer Offer Lost 2020 Router Modem Message Description 2021 ==================================================================== 2023 <-------Peer Discovery--------- Modem initiates discovery, starts 2024 a guard timer. 2026 ---------Peer Offer-------|| Router offers availability 2028 Modem times out on Peer Offer, 2029 restarts discovery process. 2031 <-------Peer Discovery--------- Modem initiates discovery 2033 ---------Peer Offer-----------> Router detects subsequent 2034 discovery, internally terminates 2035 the previous, accepts the new 2036 association, sends Peer Offer 2037 w/Status TLV indicating success. 2039 Discovery completed. 2041 13.1.4 Discovery Success 2043 Router Modem Message Description 2044 ==================================================================== 2046 <-------Peer Discovery--------- Modem initiates discovery 2048 ---------Peer Offer-----------> Router offers availability 2050 <-----Peer Initialization------ Modem Connects on TCP Port 2052 <------Peer Heartbeat---------- 2054 -------Peer Heartbeat---------> 2056 <==============================> Message flow about destinations 2057 (i.e. Destination Up, Destination 2058 Down, Destination update) 2060 <-------Peer Heartbeat--------- 2062 -------Peer Heartbeat---------> 2063 --------Peer Term Req---------> Terminate Request 2065 <--------Peer Term Res--------- Terminate Response 2067 29.1.5 Router Detects a Heartbeat timeout 2069 Router Modem Message Description 2070 ==================================================================== 2072 <-------Peer Heartbeat--------- 2074 -------Peer Heartbeat---------> 2076 ||---Peer Heartbeat--------- 2078 ~ ~ ~ ~ ~ ~ ~ 2080 -------Peer Heartbeat---------> 2082 ||---Peer Heartbeat--------- 2083 Router Heartbeat Timer expires, 2084 detects missing heartbeats. Router 2085 takes down all destination sessions 2086 and terminates the Peer 2087 association. 2089 ------Peer Terminate ---------> Peer Terminate Request 2091 Modem takes down all destination 2092 sessions, then acknowledges the 2093 Peer Terminate 2095 <----Peer Terminate ACK--------- Peer Terminate ACK 2097 29.1.6 Modem Detects a Heartbeat timeout 2099 Router Modem Message Description 2100 ==================================================================== 2102 <-------Peer Heartbeat--------- 2104 -------Peer Heartbeat------|| 2106 <-------Peer Heartbeat--------- 2108 ~ ~ ~ ~ ~ ~ ~ 2110 -------Peer Heartbeat------|| 2112 <-------Peer Heartbeat--------- 2113 Modem Heartbeat Timer expires, 2114 detects missing heartbeats. Modem 2115 takes down all destination sessions 2117 <-------Peer Terminate-------- Peer Terminate Request 2119 Router takes down all destination 2120 sessions, then acknowledges the 2121 Peer Terminate 2123 ------Peer Terminate ACK-----> Peer Terminate ACK 2125 29.1.7 Peer Terminate (from Modem) Lost 2127 Router Modem Message Description 2128 ==================================================================== 2130 ||------Peer Terminate-------- Modem Peer Terminate Request 2132 Router Heartbeat times out, 2133 terminates association. 2135 --------Peer Terminate-------> Router Peer Terminate 2137 <-----Peer Terminate ACK------ Modem sends Peer Terminate ACK 2139 29.1.8 Peer Terminate (from Router) Lost 2141 Router Modem Message Description 2142 ==================================================================== 2144 -------Peer Terminate--------> Router Peer Terminate Request 2146 Modem HB times out, 2147 terminates association. 2149 <------Peer Terminate-------- Modem Peer Terminate 2151 ------Peer Terminate ACK-----> Peer Terminate ACK 2153 29.2 Destination Specific Message Flows 2154 29.2.1 Modem Destination Up Lost 2156 Router Modem Message Description 2157 ==================================================================== 2159 ||-----Destination Up ------------ Modem sends Destination Up 2161 Modem timesout on ACK 2163 <------Destination Up ------------ Modem sends Destination Up 2165 ------Destination Up ACK---------> Router accepts the destination 2166 session 2168 <------Destination Update--------- Modem Destination Metrics 2169 . . . . . . . . 2170 <------Destination Update--------- Modem Destination Metrics 2172 29.2.2 Router Detects Duplicate Destination Ups 2174 Router Modem Message Description 2175 ==================================================================== 2177 <------Destination Up ------------ Modem sends Destination Up 2179 ------Destination Up ACK-------|| Router accepts the destination 2180 session 2182 Modem timesout on ACK 2184 <------Destination Up ------------ Modem resends Destination Up 2186 Router detects duplicate 2187 Destination, takes down the 2188 previous, accepts the new 2189 Destination. 2191 ------Destination Up ACK---------> Router accepts the destination 2192 session 2194 <------Destination Update--------- Modem Destination Metrics 2195 . . . . . . . . 2196 <------Destination Update--------- Modem Destination Metrics 2198 29.2.3 Destination Up, No Layer 3 Addresses 2200 Router Modem Message Description 2201 ==================================================================== 2203 <------Destination Up ------------ Modem sends Destination Up 2205 ------Destination Up ACK---------> Router accepts the destination 2206 session 2208 Router ARPs for IPv4 if defined. 2209 Router drives ND for IPv6 if 2210 defined. 2212 <------Destination Update--------- Modem Destination Metrics 2213 . . . . . . . . 2214 <------Destination Update--------- Modem Destination Metrics 2216 29.2.4 Destination Up with IPv4, No IPv6 2218 Router Modem Message Description 2219 ==================================================================== 2221 <------Destination Up ------------ Modem sends Destination Up with 2222 the IPv4 TLV 2224 ------Destination Up ACK---------> Router accepts the destination 2225 session 2227 Router drives ND for IPv6 if 2228 defined. 2230 <------Destination Update--------- Modem Destination Metrics 2231 . . . . . . . . 2232 <------Destination Update--------- Modem Destination Metrics 2234 29.2.5 Destination Up with IPv4 and IPv6 2236 Router Modem Message Description 2237 ==================================================================== 2239 <------Destination Up ------------ Modem sends Destination Up with 2240 the IPv4 and IPv6 TLVs 2242 ------Destination Up ACK---------> Router accepts the destination 2243 session 2245 <------Destination Update--------- Modem Destination Metrics 2246 . . . . . . . . 2248 29.2.6 Destination Session Success 2250 Router Modem Message Description 2251 ==================================================================== 2253 ---------Peer Offer-----------> Router offers availability 2255 -------Peer Heartbeat---------> 2257 <------Destination Up ----------- Modem 2259 ------Destination Up ACK--------> Router 2261 <------Destination Update--------- Modem 2262 . . . . . . . . 2263 <------Destination Update--------- Modem 2265 Modem initiates the terminate 2267 <------Destination Down ---------- Modem 2269 ------Destination Down ACK-------> Router 2271 or 2273 Router initiates the terminate 2275 ------Destination Down ----------> Router 2277 <------Destination Down ACK------- Modem 2279 Acknowledgements 2281 The authors would like to acknowledge and thank the members of the 2282 DLEP design team, who have provided invaluable insight. The members 2283 of the design team are: Teco Boot, Bow-Nan Cheng, John Dowdell, 2284 Henning Rogge, and Rick Taylor. 2286 The authors would also like to acknowledge the influence and 2287 contributions of Chris Olsen, Martin Duke, Subir Das, Jaewon Kang, 2288 Vikram Kaul, and Nelson Powell. 2290 Normative References 2292 [RFC5578] Berry, B., Ed., "PPPoE with Credit Flow and Metrics", 2293 RFC 5578, February 2010. 2295 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2297 Informative References 2299 [TLS] Dierks, T. and Rescorla, E. "The Transport Layer Security 2300 (TLS) Protocol", RFC 5246, August 2008. 2302 Author's Addresses 2304 Stan Ratliff 2305 Cisco 2306 170 West Tasman Drive 2307 San Jose, CA 95134 2308 USA 2309 EMail: sratliff@cisco.com 2311 Bo Berry 2312 Cisco 2313 170 West Tasman Drive 2314 San Jose, CA 95134 2315 USA 2316 EMail: boberry@cisco.com 2318 Greg Harrison 2319 Cisco 2320 170 West Tasman Drive 2321 San Jose, CA 95134 2322 USA 2323 EMail: greharri@cisco.com 2325 Shawn Jury 2326 Cisco 2327 170 West Tasman Drive 2328 San Jose, CA 95134 2329 USA 2330 Email: sjury@cisco.com 2332 Darryl Satterwhite 2333 Broadcom 2334 USA 2335 Email: dsatterw@broadcom.com