idnits 2.17.1 draft-ietf-manet-dlep-06.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 264 has weird spacing: '... Shared o ...' == Line 265 has weird spacing: '... Medium o...' -- The document date (August 13, 2014) is 3537 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 5578 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE' -- Obsolete informational reference (is this intentional?): RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 3 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: February 14, 2015 Cisco Systems 7 D. Satterwhite 8 Broadcom 9 August 13, 2014 11 Dynamic Link Exchange Protocol (DLEP) 12 draft-ietf-manet-dlep-06 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. Mandatory Versus Optional Items . . . . . . . . . . . . . . . . 9 70 4. Credits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 5. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 6. Extensions to DLEP . . . . . . . . . . . . . . . . . . . . . . 11 73 7. Normal Session Flow . . . . . . . . . . . . . . . . . . . . . 11 74 7.1 DLEP Router session flow - Discovery case . . . . . . . . . 11 75 7.2 DLEP Router session flow - Configured case . . . . . . . . . 12 76 7.3 DLEP Modem session flow . . . . . . . . . . . . . . . . . . 12 77 7.4 Common Session Flow . . . . . . . . . . . . . . . . . . . . 13 78 8. Mandatory Signals and Data Items . . . . . . . . . . . . . . . 14 79 9. Generic DLEP Signal Definition . . . . . . . . . . . . . . . . 15 80 10. DLEP Data Items . . . . . . . . . . . . . . . . . . . . . . . 16 81 10.1 DLEP Port . . . . . . . . . . . . . . . . . . . . . . . . 17 82 10.2 Peer Type . . . . . . . . . . . . . . . . . . . . . . . . 17 83 10.3 MAC Address . . . . . . . . . . . . . . . . . . . . . . . 18 84 10.4 IPv4 Address . . . . . . . . . . . . . . . . . . . . . . . 18 85 10.5 IPv6 Address . . . . . . . . . . . . . . . . . . . . . . . 19 86 10.6 Maximum Data Rate (Receive) . . . . . . . . . . . . . . . 20 87 10.7 Maximum Data Rate (Transmit) . . . . . . . . . . . . . . . 21 88 10.8 Current Data Rate (Receive) . . . . . . . . . . . . . . . 21 89 10.9 Current Data Rate (Transmit) . . . . . . . . . . . . . . . 22 90 10.10 Latency . . . . . . . . . . . . . . . . . . . . . . . . . 23 91 10.11 Resources (Receive) . . . . . . . . . . . . . . . . . . . 23 92 10.12 Resources (Transmit) . . . . . . . . . . . . . . . . . . 24 93 10.13 Relative Link Quality (Receive) . . . . . . . . . . . . . 25 94 10.14 Relative Link Quality (Transmit) . . . . . . . . . . . . 25 95 10.15 Status . . . . . . . . . . . . . . . . . . . . . . . . . 26 96 10.16 Heartbeat Interval . . . . . . . . . . . . . . . . . . . 26 97 10.17 Link Characteristics ACK Timer . . . . . . . . . . . . . 27 98 10.18 Credit Window Status . . . . . . . . . . . . . . . . . . 28 99 10.19 Credit Grant Request . . . . . . . . . . . . . . . . . . 28 100 10.20 Credit Request . . . . . . . . . . . . . . . . . . . . . 29 101 10.22 DLEP Optional Signals Supported . . . . . . . . . . . . . 30 102 10.21 DLEP Optional Data Items Supported . . . . . . . . . . . 31 103 10.22 DLEP Vendor Extension . . . . . . . . . . . . . . . . . . 31 104 11. DLEP Protocol Signals . . . . . . . . . . . . . . . . . . . . 32 105 11.1 Signal TLV Values . . . . . . . . . . . . . . . . . . . . 32 106 11.2 Peer Discovery Signal . . . . . . . . . . . . . . . . . . . 33 107 11.3 Peer Offer Signal . . . . . . . . . . . . . . . . . . . . . 33 108 11.4 Peer Initialization Signal . . . . . . . . . . . . . . . . 34 109 11.5 Peer Initialization ACK Signal . . . . . . . . . . . . . . 34 110 11.6 Peer Update Signal . . . . . . . . . . . . . . . . . . . . 35 111 11.7 Peer Update ACK Signal . . . . . . . . . . . . . . . . . . 36 112 11.8 Peer Termination Signal . . . . . . . . . . . . . . . . . . 37 113 11.9 Peer Termination ACK Signal . . . . . . . . . . . . . . . . 37 114 11.10 Destination Up Signal . . . . . . . . . . . . . . . . . . 37 115 11.11 Destination Up ACK Signal . . . . . . . . . . . . . . . . 38 116 11.12 Destination Down Signal . . . . . . . . . . . . . . . . . 38 117 11.13 Destination Down ACK Signal . . . . . . . . . . . . . . . 39 118 11.14 Destination Update Signal . . . . . . . . . . . . . . . . 39 119 11.15 Heartbeat Signal . . . . . . . . . . . . . . . . . . . . . 40 120 11.16 Link Characteristics Request Signal . . . . . . . . . . . 40 121 11.17 Link Characteristics ACK Signal . . . . . . . . . . . . . 41 122 12. Security Considerations . . . . . . . . . . . . . . . . . . . 42 123 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 124 13.1 Registrations . . . . . . . . . . . . . . . . . . . . . . 42 125 13.2 Expert Review: Evaluation Guidelines . . . . . . . . . . . 42 126 13.3 Signal TLV Type Registration . . . . . . . . . . . . . . . 42 127 13.4 DLEP Data Item Registrations . . . . . . . . . . . . . . . 43 128 13.5 DLEP Well-known Port . . . . . . . . . . . . . . . . . . . 44 129 13.6 DLEP Multicast Address . . . . . . . . . . . . . . . . . . 44 130 14. Appendix A. . . . . . . . . . . . . . . . . . . . . . . . . . 44 131 14.1 Peer Level Signal Flows . . . . . . . . . . . . . . . . . 44 132 14.1.1 Modem Device Restarts Discovery . . . . . . . . . . . 44 133 14.1.2 Modem Device Detects Peer Offer Timeout . . . . . . . 44 134 14.1.3 Router Peer Offer Lost . . . . . . . . . . . . . . . . 46 135 14.1.4 Discovery Success . . . . . . . . . . . . . . . . . . 46 136 14.1.5 Router Detects a Heartbeat timeout . . . . . . . . . . 47 137 14.1.6 Modem Detects a Heartbeat timeout . . . . . . . . . . 47 138 14.1.7 Peer Terminate (from Modem) Lost . . . . . . . . . . . 48 139 14.1.8 Peer Terminate (from Router) Lost . . . . . . . . . . 48 140 14.2 Destination Specific Signal Flows . . . . . . . . . . . . 48 141 14.2.1 Modem Destination Up Lost . . . . . . . . . . . . . . 49 142 14.2.2 Router Detects Duplicate Destination Ups . . . . . . . 49 143 14.2.3 Destination Up, No Layer 3 Addresses . . . . . . . . . 50 144 14.2.4 Destination Up with IPv4, No IPv6 . . . . . . . . . . 50 145 14.2.5 Destination Up with IPv4 and IPv6 . . . . . . . . . . 50 146 14.2.6 Destination Session Success . . . . . . . . . . . . . 51 147 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 51 148 Normative References . . . . . . . . . . . . . . . . . . . . . . . 52 149 Informative References . . . . . . . . . . . . . . . . . . . . . . 52 150 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 152 1. Introduction 154 There exist today a collection of modem devices that control links of 155 variable datarate and quality. Examples of these types of links 156 include line-of-sight (LOS) terrestrial radios, satellite terminals, 157 and cable/DSL modems. Fluctuations in speed and quality of these 158 links can occur due to configuration (in the case of cable/DSL 159 modems), or on a moment-to-moment basis, due to physical phenomena 160 like multipath interference, obstructions, rain fade, etc. It is also 161 quite possible that link quality and datarate varies with respect to 162 individual destinations on a link, and with the type of traffic being 163 sent. As an example, consider the case of an 802.11g access point, 164 serving 2 associated laptop computers. In this environment, the 165 answer to the question "What is the datarate on the 802.11g link?" is 166 "It depends on which associated laptop we're talking about, and on 167 what kind of traffic is being sent." While the first laptop, being 168 physically close to the access point, may have a datarate of 54Mbps 169 for unicast traffic, the other laptop, being relatively far away, or 170 obstructed by some object, can simultaneously have a datarate of only 171 32Mbps for unicast. However, for multicast traffic sent from the 172 access point, all traffic is sent at the base transmission rate 173 (which is configurable, but depending on the model of the access 174 point, is usually 24Mbps or less). 176 In addition to utilizing variable datarate links, mobile networks are 177 challenged by the notion that link connectivity will come and go over 178 time, without an effect on a router's interface state (Up or Down). 179 Effectively utilizing a relatively short-lived connection is 180 problematic in IP routed networks, as routing protocols tend to rely 181 on interface state and independent timers at OSI Layer 3 to maintain 182 network convergence (e.g. HELLO messages and/or recognition of DEAD 183 routing adjacencies). These dynamic connections can be better 184 utilized with an event-driven paradigm, where acquisition of a new 185 neighbor (or loss of an existing one) is signaled, as opposed to a 186 paradigm driven by timers and/or interface state. 188 Another complicating factor for mobile networks are the different 189 methods of physically connecting the modem devices to the router. 190 Modems can be deployed as an interface card in a router's chassis, or 191 as a standalone device connected to the router via Ethernet or serial 192 link. In the case of Ethernet or serial attachment, with existing 193 protocols and techniques, routing software cannot be aware of 194 convergence events occurring on the radio link (e.g. acquisition or 195 loss of a potential routing neighbor), nor can the router be aware of 196 the actual capacity of the link. This lack of awareness, along with 197 the variability in datarate, leads to a situation where finding the 198 (current) best route through the network to a given destination is 199 difficult to establish and properly maintain. This is especially true 200 of demand-based access schemes such as Demand Assigned Multiple 201 Access (DAMA) implementations used on some satellite systems. With a 202 DAMA-based system, additional datarate may be available, but will not 203 be used unless the network devices emit traffic at rate higher than 204 the currently established rate. Increasing the traffic rate does not 205 guarantee additional datarate will be allocated; rather, it may 206 result in data loss and additional retransmissions on the link. 208 Addressing the challenges listed above, the authors have developed 209 the Data Link Exchange Protocol, or DLEP. The DLEP protocol runs 210 between a router and its attached modem devices, allowing the modem 211 to communicate link characteristics as they change, and convergence 212 events (acquisition and loss of potential routing destinations). The 213 following diagrams are used to illustrate the scope of DLEP packets. 215 |-------Local Node-------| |-------Remote Node------| 216 | | | | 217 +--------+ +-------+ +-------+ +--------+ 218 | Router |=======| Modem |{~~~~~~~~}| Modem |=======| Router | 219 | | | Device| | Device| | | 220 +--------+ +-------+ +-------+ +--------+ 221 | | | Link | | | 222 |-DLEP--| | Protocol | |-DLEP--| 223 | | | (e.g. | | | 224 | | | 802.11) | | | 226 Figure 1: DLEP Network 228 In Figure 1, when the local modem detects the presence of a remote 229 node, it (the local modem) sends a signal to its router via the DLEP 230 protocol. Upon receipt of the signal, the local router may take 231 whatever action it deems appropriate, such as initiating discovery 232 protocols, and/or issuing HELLO messages to converge the network. On 233 a continuing, as-needed basis, the modem devices utilize DLEP to 234 report any characteristics of the link (datarate, latency, etc) that 235 have changed. DLEP is independent of the link type and topology 236 supported by the modem. Note that the DLEP protocol is specified to 237 run only on the local link between router and modem. Some over the 238 air signaling may be necessary between the local and remote modem in 239 order to provide some parameters in DLEP signals between the local 240 modem and local router, but DLEP does not specify how such over the 241 air signaling is carried out. Over the air signaling is purely a 242 matter for the modem implementer. 244 Figure 2 shows how DLEP can support a configuration where routers are 245 connected with different link types. In this example, Modem A 246 implements a point-to-point link, and Modem B is connected via a 247 shared medium. In both cases, the DLEP protocol is used to report the 248 characteristics of the link (datarate, latency, etc.) to routers. The 249 modem is also able to use the DLEP session to notify the router when 250 the remote node is lost, shortening the time required to re-converge 251 the network. 253 +--------+ +--------+ 254 +----+ Modem A| | Modem A+---+ 255 | | Device | <===== // ======> | Device | | 256 | +--------+ P-2-P Link +--------+ | 257 +---+----+ +---+----+ 258 | Router | | Router | 259 | | | | 260 +---+----+ +---+----+ 261 | +--------+ +--------+ | 262 +-----+ Modem B| | Modem B| | 263 | Device | o o o o o o o o | Device +--+ 264 +--------+ o Shared o +--------+ 265 o Medium o 266 o o 267 o o 268 o o 269 o 270 +--------+ 271 | Modem B| 272 | Device | 273 +---+----+ 274 | 275 | 276 +---+----+ 277 | Router | 278 | | 279 +--------+ 281 Figure 2: DLEP Network with Multiple Modem Devices 283 DLEP defines a set of signals used by modems and their attached 284 routers. The signals are used to communicate events that occur on the 285 physical link(s) managed by the modem: for example, a remote node 286 entering or leaving the network, or that the link has changed. 287 Associated with these signals are a set of data items - information 288 that describes the remote node (e.g., address information), and/or 289 the characteristics of the link to the remote node. 291 The protocol is defined as a collection of type-length-value (TLV) 292 based formats, specifying the signals that are exchanged between a 293 router and a modem, and the data items associated with the signal. 294 This document specifies transport of DLEP signals and data items via 295 the TCP transport, with a UDP-based discovery mechanism. Other 296 transports for the protocol are possible, but are outside the scope 297 of this document. 299 DLEP signals are further defined as mandatory or optional. Signals 300 will additionally have mandatory and optional data items. 301 Implementations MUST support all mandatory signals and their 302 mandatory data items to be considered compliant. Implementations MAY 303 also support some, or all, of the optional signals and data items. 305 DLEP uses a session-oriented paradigm between the modem device and 306 its associated router. If multiple modem devices are attached to a 307 router (as in Figure 2), a separate DLEP session MUST exist for each 308 modem. If a modem device supports multiple connections to a router 309 (via multiple logical or physical interfaces), or supports 310 connections to multiple routers, a separate DLEP session MUST exist 311 for each connection. This router/modem session provides a carrier for 312 information exchange concerning "destinations" that are available via 313 the modem device. A "destination" can be either physical (as in the 314 case of a specific far-end router), or a logical destination (as in a 315 Multicast group). As such, all of the destination-level exchanges in 316 DLEP can be envisioned as building an information base concerning the 317 remote nodes, and the link characteristics to those nodes. 319 Any DLEP signal that is NOT understood by a receiver MUST result in 320 an error indication being sent to the originator, and also MUST 321 result in termination of the session between the DLEP peers. Any data 322 item that is NOT understood by a receiver MUST be ignored. 324 Multicast traffic destined for the variable-quality network (the 325 network accessed via the DLEP modem) is handled in IP networks by 326 deriving a Layer 2 MAC address based on the Layer 3 address. 327 Leveraging on this scheme, Multicast traffic is supported in DLEP 328 simply by treating the derived MAC address as any other "destination" 329 (albeit a logical one) in the network. To support these logical 330 destinations, one of the DLEP participants (typically, the router) 331 informs the other as to the existence of the logical neighbor. The 332 modem, once it is aware of the existence of this logical neighbor, 333 reports link characteristics just as it would for any other 334 destination in the network. The specific algorithms a modem would use 335 to report metrics on multicast (or logical) destinations is outside 336 the scope of this specification, and is left to specific 337 implementations to decide. 339 1.1 Requirements 341 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 342 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 343 document are to be interpreted as described in BCP 14, RFC 2119 344 [RFC2119]. 346 2. Assumptions 348 Routers and modems that exist as part of the same node (e.g., that 349 are locally connected) can utilize a discovery technique to locate 350 each other, thus avoiding a-priori configuration. The router is 351 responsible for initialing the discovery process, using the Peer 352 Discovery signal. 354 DLEP utilizes a session-oriented paradigm. A router and modem form a 355 session by completing the discovery process. This router-modem 356 session persists unless or until it either (1) times out, based on 357 the timeout values supplied, or (2) is explicitly torn down by one of 358 the participants. Note that while use of timers in DLEP is OPTIONAL, 359 it is strongly recommended that implementations choose to run with 360 timers enabled. 362 DLEP assumes that participating modems, and their physical links, act 363 as a transparent IEEE 802.1D bridge. Specifically, the assumption is 364 that the destination MAC address for data traffic (frames destined 365 for the far-end node, as opposed to the DLEP control traffic itself) 366 in any frame emitted by the router should be the MAC address of a 367 device in the remote node. DLEP also assumes that MAC addresses are 368 unique within the context of the router-modem session. 370 This document refers to a remote node as a "Destination". 371 Destinations can be identified by either the router or the modem, and 372 represent a specific destination (e.g., an address) that exists on 373 the link(s) managed by the modem. A destination MUST contain a MAC 374 address, it MAY optionally include a Layer 3 address (or addresses). 375 Destinations MAY refer either to physical devices in the network, or 376 to logical destinations, as in a derived multicast MAC address 377 associated with a group. As "destinations" are discovered, DLEP 378 routers and modems build an information base on destinations 379 accessible via the modem. Changes in link characteristics MAY then be 380 reported as being "modem-wide" (effecting ALL destinations accessed 381 via the modem) or MAY be neighbor (destination) specific. 383 The DLEP signals concerning destinations thus become the way for 384 routers and modems to maintain, and notify each other about, an 385 information base representing the physical and logical (e.g., 386 multicast) destinations accessible via the modem device. The 387 information base would contain addressing information (e.g., MAC 388 address, and OPTIONALLY, Layer 3 addresses), link characteristics 389 (metrics), and OPTIONALLY, flow control information (credits). 391 DLEP assumes that security on the session (e.g. authentication of 392 session partners, encryption of traffic, or both) is dealt with by 393 the underlying transport mechanism (e.g., by using a transport such 394 as TLS [TLS]). 396 This document specifies an implementation of the DLEP signals and 397 data items running over the TCP transport. It is assumed that DLEP 398 running over other transport mechanisms would be documented 399 separately. 401 3. Mandatory Versus Optional Items 403 As mentioned above, DLEP defines a core set of signals and data items 404 as mandatory. Support for those signals and data items MUST exist in 405 an implementation to guarantee interoperability and therefore make an 406 implementation DLEP compliant. However, a mandatory signal or data 407 item is not necessarily REQUIRED - as an example, consider the data 408 item entitled "DLEP Optional Signals Supported", defined in section 409 10.22 of this document. The data item allows a DLEP implementation to 410 list all optional behavior it supports, and is sent as a part of the 411 Peer Initialization signal. Receiving implementations MUST be capable 412 of parsing and understanding the optional signals that are offered. 413 However, if the sending implementation has chosen NOT to implement 414 ANY optional functionality, this data item would NOT be included in 415 the Peer Initialization (e.g., absence of the mandatory data item 416 would not be considered a protocol error, but as support for the core 417 DLEP signals ONLY). Therefore, care should be taken to differentiate 418 the notion of a mandatory data item versus one that is REQUIRED. 420 4. Credits 422 DLEP includes an OPTIONAL credit-windowing scheme analogous to the 423 one documented in [RFC5578]. In this scheme, traffic between the 424 router and modem is treated as two unidirectional windows. This 425 document identifies these windows as the "Modem Receive Window", or 426 MRW, and the "Router Receive Window", or RRW. 428 If the OPTIONAL credit-windowing scheme is used, credits MUST be 429 granted by the receiver on a given window - that is, on the "Modem 430 Receive Window" (MRW), the modem is responsible for granting credits 431 to the router, allowing it (the router) to send data to the modem. 432 Likewise, the router is responsible for granting credits on the RRW, 433 which allows the modem to send data to the router. 435 DLEP expresses all credit data in number of octets. The total number 436 of credits on a window, and the increment to add to a grant, are 437 always expressed as a 64-bit unsigned quantity. 439 If used, credits are managed on a neighbor-specific basis; that is, 440 separate credit counts are maintained for each neighbor requiring the 441 service. Credits do not apply to the DLEP session that exists between 442 routers and modems. 444 5. Metrics 446 DLEP includes the ability for the router and modem to communicate 447 metrics that reflect the characteristics (e.g. datarate, latency) of 448 the variable-quality link in use. DLEP does NOT specify how a given 449 metric value is to be calculated, rather, the protocol assumes that 450 metrics have been calculated with a "best effort", incorporating all 451 pertinent data that is available to the modem device. 453 As mentioned in the introduction section of this document, metrics 454 have to be used within a context - for example, metrics to a unicast 455 address in the network. DLEP allows for metrics to be sent within two 456 contexts - metrics for a specific destination within the network 457 (e.g., a specific router), and "modem-wide" (those that apply to all 458 destinations accessed via the modem). Metrics are further subdivided 459 into transmit and receive metrics. Metrics supplied on DLEP Peer 460 signals are, by definition, modem-wide; metrics supplied on 461 Destination signals are, by definition, used for the specific 462 neighbor only. 464 DLEP modem implementations MUST announce all supported metric items, 465 and provide default values for those metrics, in the Peer 466 Initialization signal. In order to introduce a new metric type, DLEP 467 modem implementations MUST terminate the session with the router (via 468 the Peer Terminate signal), and re-establish the session. 470 It is left to implementations to choose sensible default values based 471 on their specific characteristics. Modems having static (non- 472 changing) link metric characteristics MAY report metrics only once 473 for a given neighbor (or once on a modem-wide basis, if all 474 connections via the modem are of this static nature). 476 The approach of allowing for different contexts for metric data 477 increases both the flexibility and the complexity of using metric 478 data. This document details the mechanism whereby the data is 479 transmitted, however, the specific algorithms (precedence, etc) for 480 utilizing the dual-context metrics is out of scope and not addressed 481 by this document. 483 6. Extensions to DLEP 485 While this draft represents the best efforts of the co-authors, and 486 the working group, to be functionally complete, it is recognized that 487 extensions to DLEP will in all likelihood be necessary as more link 488 types are utilized. To allow for future innovation, the draft 489 allocates numbering space for experimental implementations of both 490 signals and data items. 492 DLEP implementations MUST be capable of parsing and acting on the 493 mandatory signals and data items as documented in this specification. 494 DLEP signals/data items that are optional, or are in the experimental 495 numbering range SHOULD be silently dropped by an implementation if 496 they are not understood. 498 The intent of the optional signals and data items, as well as the 499 experimental numbering space, is to allow for further development of 500 DLEP protocol features and function. Having experimental space 501 reserved for both signals and data items gives maximum flexibility 502 for extending the protocol as conditions warrant. For example, 503 experimental data items could be used by implementations to send 504 additional metrics. A combination of experimental signals, and 505 associated data items, could be used to implement new flow control 506 schemes. If subsequent research and development define new features 507 and function, then it should be standardized either as an update to 508 this document, or as an additional stand-alone specification. 510 7. Normal Session Flow 512 Normal session flow is slightly different, depending on whether the 513 implementation represents a modem or a router, and whether discovery 514 techniques are used. The normal flow by DLEP partner type is: 516 7.1 DLEP Router session flow - Discovery case 518 If the DLEP router implementation is utilizing the optional discovery 519 mechanism, then the implementation will initialize a UDP socket, 520 binding it to an arbitrary port. This UDP socket is used to send the 521 Peer Discovery signal to the DLEP link-local multicast address and 522 port (TBD). The implementation then waits on receipt of a Peer Offer 523 signal, which MUST contain the unicast address and port for TCP-based 524 communication with a DLEP modem. The Peer Offer signal MAY contain 525 multiple address/port combinations. If more than one address/port 526 combination is in the Peer Offer, the DLEP router implementation 527 SHOULD consider the list to be in priority sequence, with the "most 528 desired" address/port combination listed first. However, router 529 implementations MAY use their own heuristics to determine the best 530 address/port combination. At this point, the router implementation 531 MAY either destroy the UDP socket, or continue to issue Peer 532 Discovery signals to the link-local address/port combination. In 533 either case, the TCP session initialization occurs as in the 534 configured case. 536 7.2 DLEP Router session flow - Configured case 538 When a DLEP router implementation has the address and port 539 information for a TCP connection to a modem (obtained either via 540 configuration or via the discovery process described above), the 541 router will initialize and bind a TCP socket. This socket is used to 542 connect to the DLEP modem software. After a successful TCP connect, 543 the modem implementation MUST issue a Peer Initialization signal to 544 the DLEP router. The Peer Initialization signal MUST contain TLVs for 545 ALL supported metrics from this modem (e.g. all MANDATORY metrics 546 plus all OPTIONAL metrics supported by the implementation), along 547 with the default values of those metrics. After sending the Peer 548 Initialization, the modem implementation should wait for receipt of a 549 Peer Initialization ACK signal from the router. Receipt of the Peer 550 Initialization ACK indicates that the router has received and 551 processed the Peer Initialization, and the session MUST transition to 552 the "in session" state. At this point, signals regarding destinations 553 in the network, and/or Peer Update signals, can flow on the DLEP 554 session between modem and router. The "in session" state is 555 maintained until one of the following conditions occur: 557 o The session is explicitly terminated (using Peer Termination), or 558 o The session times out, based on supplied timeout values. 560 7.3 DLEP Modem session flow 562 DLEP modem implementations MUST support the discovery mechanism. 563 Therefore, the normal flow is as follows: 565 The implementation will initialize a UDP socket, binding that socket 566 to the DLEP link-local multicast address (TBD) and the DLEP well- 567 known port number (also TBD). The implementation will then initialize 568 a TCP socket, on a unicast address and port. This socket is used to 569 listen for incoming TCP connection requests. 571 When the modem implementation receives a Peer Discovery signal on the 572 UDP socket, it responds by issuing a Peer Offer signal to the sender 573 of the Peer Discovery. The Peer Offer signal MUST contain the unicast 574 address and port of the TCP listen socket, described above. A DLEP 575 modem implementation MAY respond with ALL address/port combinations 576 that have an active TCP listen posted. If multiple address/port 577 combinations are listed, the receiver of the Peer Offer MAY connect 578 on any available address/port pair. Anything other than Peer 579 Discovery signals received on the UDP socket MUST be silently 580 dropped. 582 When the DLEP modem implementation accepts a connection via TCP, it 583 MUST send a Peer Initialization signal. The Peer Initialization MUST 584 contain metric TLVs for ALL mandatory metrics, and MUST contain 585 metric TLVs for ANY optional metrics supported by the modem. If a new 586 metric is to be introduced, the DLEP session between router and modem 587 MUST be terminated and restarted, and the new metric described in a 588 Peer Initialization signal. 590 7.4 Common Session Flow 592 In order to maintain the session between router and modem, periodic 593 "Heartbeat" signals MAY be exchanged. These signals are intended to 594 keep the session alive, and to verify bidirectional connectivity 595 between the two participants. DLEP also provides an OPTIONAL Peer 596 Update signal, intended to communicate some change in status (e.g., a 597 change of layer 3 address parameters, or a modem-wide link change). 599 In addition to the local (Peer level) signals above, the participants 600 will transmit DLEP signals concerning destinations in the network. 601 These signals trigger creation/maintenance/deletion of destinations 602 in the information base of the recipient. For example, a modem will 603 inform its attached router of the presence of a new destination via 604 the "Destination Up" signal. Receipt of a Destination Up causes the 605 router to allocate the necessary resources, creating an entry in the 606 information base with the specifics (e.g., MAC Address, Latency, Data 607 Rate, etc) of the neighbor. The loss of a destination is communicated 608 via the "Destination Down" signal, and changes in status to the 609 destination (e.g. varying link quality, or addressing changes) are 610 communicated via the "Destination Update" signal. The information on 611 a given neighbor will persist in the router's information base until 612 (1) a "Destination Down" is received, indicating that the modem has 613 lost contact with the remote node, or (2) the router/modem session 614 terminates, indicating that the router has lost contact with its own 615 local modem. 617 Again, metrics can be expressed within the context of a specific 618 neighbor via the Destination Update signal, or on a modem-wide basis 619 via the Peer Update signal. In cases where metrics are provided on 620 the router/modem session, the receiver MUST propagate the metrics to 621 all destinations in its information base that are accessed via the 622 originator. A DLEP participant MAY send metrics both in a 623 router/modem session context (via the Peer Update signal) and a 624 specific neighbor context (via Destination Update) at any time. The 625 heuristics for applying received metrics is left to implementations. 627 In addition to receiving metrics about the link, DLEP provides an 628 OPTIONAL signal allowing a router to request a different datarate, or 629 latency, from the modem. This signal is referred to as the Link 630 Characteristics Signal, and gives the router the ability to deal with 631 requisite increases (or decreases) of allocated datarate/latency in 632 demand-based schemes in a more deterministic manner. 634 8. Mandatory Signals and Data Items 636 The following DLEP signals are considered core to the specification; 637 implementations MUST support these signals, and the associated data 638 items, in order to be considered compliant: 640 Signal Data Items 641 ====== ========== 642 Peer Discovery (Router Only) None 644 Peer Offer (Modem Only) IPv4 Address 645 IPv6 address 646 DLEP Port 648 Peer Initialization Maximum Data Rate (Receive) 649 Maximum Data Rate (Transmit) 650 Current Data Rate (Receive) 651 Current Data Rate (Transmit) 652 Latency 653 Relative Link Quality (Receive) 654 Relative Link Quality (Transmit) 655 DLEP Optional Signal Support 656 DLEP Optional Data Item Support 658 Peer Initialization ACK Status 660 Peer Termination Status 661 Peer Termination ACK Status 663 Destination Up MAC Address 664 Maximum Data Rate (Receive) 665 Maximum Data Rate (Transmit) 666 Current Data Rate (Receive) 667 Current Data Rate (Transmit) 668 Latency 669 Relative Link Quality (Receive) 670 Relative Link Quality (Transmit) 672 Destination Update MAC Address 673 Maximum Data Rate (Receive) 674 Maximum Data Rate (Transmit) 675 Current Data Rate (Receive) 676 Current Data Rate (Transmit) 677 Latency 678 Relative Link Quality (Receive) 679 Relative Link Quality (Transmit) 681 Destination Down MAC Address 683 All other DLEP signals and data items are OPTIONAL. Implementations 684 MAY choose to provide them. Implementations that do not support 685 optional signals MUST report an error condition and terminate the 686 router/modem session upon receipt of any such signal received. 687 OPTIONAL data items received that are not supported MUST be silently 688 dropped. 690 9. Generic DLEP Signal Definition 692 The Generic DLEP Signal consists of a sequence of TLVs. The first TLV 693 represents the signal being communicated (e.g., a "Destination Up", 694 or a "Peer Offer"). Subsequent TLVs contain the data items pertinent 695 to the signal (e.g., Maximum Data Rate, or Latency, etc). 697 The Generic DLEP Packet Definition contains the following fields: 699 0 1 2 3 700 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 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 |Signal TLV Type | Length | DLEP data items... | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 Signal - One of the DLEP Signal TLV type values 706 defined in this document. 708 Length - The length, expressed as a 16-bit 709 quantity, of all of the DLEP data items 710 associated with this signal. 712 DLEP data items - One or more data items, encoded in TLVs, 713 as defined in this document. 715 10. DLEP Data Items 717 As mentioned earlier, DLEP protocol signals are transported as a 718 collection of TLVs. The first TLV present in a DLEP signal MUST be 719 one of the Signal TLVs, documented in section 10. The signals are 720 followed by one or more data items, indicating the specific changes 721 that need to be instantiated in the receiver's information base. 723 Valid DLEP Data Items are: 725 TLV TLV 726 Value Description 727 ========================================= 728 TBD DLEP Port 729 TBD Peer Type 730 TBD IPv4 Address 731 TBD IPv6 Address 732 TBD Maximum Data Rate (Receive) (MDRR) 733 TBD Maximum Data Rate (Transmit) (MDRT) 734 TBD Current Data Rate (Receive) (CDRR) 735 TBD Current Data Rate (Transmit) (CDRT) 736 TBD Latency 737 TBD Receive Resources 738 TBD Transmit Resources 739 TBD Relative Link Quality (Receive) (RLQR) 740 TBD Relative Link Quality (Transmit) (RLQT) 741 TBD Status 742 TBD Heartbeat Interval/Threshold 743 TBD Neighbor down ACK timer 744 TBD Link Characteristics ACK timer 745 TBD Credit Window Status 746 TBD Credit Grant 747 TBD Credit Request 748 TBD DLEP Optional Signals Supported 749 TBD DLEP Optional Data Items Supported 750 TBD DLEP Vendor Extension 752 DLEP data item TLVs contain the following fields: 754 0 1 2 3 755 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 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | TLV Type | Length | Value... | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 TLV Type - An 8-bit unsigned integer field specifying the data 761 item being sent. 763 Length - An 8-bit length of the value field of the data item 765 Value - A field of length which contains data 766 specific to a particular data item. 768 10.1 DLEP Port 770 The DLEP Port TLV is a MANDATORY TLV in the Peer Offer signal. The 771 DLEP Port TLV is used to indicate the TCP Port number on the DLEP 772 server available for connections. The receiver MUST use this 773 information to perform the TCP connect to the DLEP server. 775 The DLEP Port TLV contains the following fields: 777 0 1 2 3 778 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 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 |TLV Type =TBD |Length=2 | TCP Port Number | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 TLV Type - TBD 785 Length - Length is 2 787 TCP Port Number - TCP Port number on the DLEP server. 789 10.2 Peer Type 791 The Peer Type TLV is an OPTIONAL TLV in both the Peer Discovery and 792 Peer Offer signals. The Peer Type TLV is used by the router and modem 793 to give additional information as to its type. The peer type is a 794 string and is envisioned to be used for informational purposes (e.g. 795 as output in a display command). 797 The Peer Type TLV contains the following fields: 799 0 1 2 3 800 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 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 |TLV Type =TBD |Length= peer |Peer Type String | 804 | |type string len| | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 TLV Type - TBD 809 Length - Length of peer type string. 811 Peer Type String - Non-Null terminated string, using UTF-8 encoding. 812 For example, a satellite modem might set this 813 variable to 'Satellite terminal'. 815 10.3 MAC Address 817 The MAC address TLV MUST appear in all destination-oriented signals 818 (e.g. Destination Up, Destination Up ACK, Destination Down, 819 Destination Down ACK, Destination Update, Link Characteristics 820 Request, and Link Characteristics ACK). The MAC Address TLV contains 821 the address of the destination on the remote node. The MAC address 822 MAY be either a physical or a virtual destination. Examples of a 823 virtual destination would be a multicast MAC address, or the 824 broadcast MAC (0xFFFFFFFFFFFF). 826 0 1 2 3 827 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 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 |TLV Type =TBD |Length = 6 | MAC Address | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | MAC Address | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 TLV Type - TBD 836 Length - 6 838 MAC Address - MAC Address of the destination (either physical or 839 virtual). 841 10.4 IPv4 Address 843 The IPv4 Address TLV is an optional TLV. If supported, it MAY appear 844 in Destination Up, Destination Update, Peer Initialization, and Peer 845 Update signals. When included in Destination signals, the IPv4 846 Address TLV contains the IPv4 address of the destination, as well as 847 a subnet mask value. In the Peer Update signal, it contains the IPv4 848 address of the originator of the signal. In either case, the TLV also 849 contains an indication of whether this is a new or existing address, 850 or is a deletion of a previously known address. 852 The IPv4 Address TLV contains the following fields: 854 0 1 2 3 855 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 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 |TLV Type =TBD |Length = 6 | Add/Drop | IPv4 Address | 858 | | | Indicator | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | IPv4 Address | Subnet Mask | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 TLV Type - TBD 865 Length - 6 867 Add/Drop - Value indicating whether this is a new or existing 868 address (0x01), or a withdrawal of an address (0x02). 870 IPv4 Address - The IPv4 address of the destination or peer. 872 Subnet Mask - A subnet mask (0-32) to be applied to the IPv4 873 address. 875 10.5 IPv6 Address 877 The IPv6 Address TLV is an optional TLV. If supported, it MAY be used 878 in the Destination Up, Destination Update, Peer Initialization, and 879 Peer Update Signals. When included in Destination signals, this data 880 item contains the IPv6 address of the destination. In the Peer 881 Discovery and Peer Update, it contains the IPv6 address of the 882 originating peer. In either case, the data item also contains an 883 indication of whether this is a new or existing address, or is a 884 deletion of a previously known address, as well as a subnet mask. 886 The IPv6 Address TLV contains the following fields: 888 0 1 2 3 889 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 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 |TLV Type =TBD |Length = 18 | Add/Drop | IPv6 Address | 892 | | | Indicator | | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | IPv6 Address | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | IPv6 Address | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | IPv6 Address | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | IPv6 Address | Subnet Mask | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 TLV Type - TBD 905 Length - 18 907 Add/Drop - Value indicating whether this is a new or existing 908 address (0x01), or a withdrawal of an address (0x02). 910 IPv6 Address - IPv6 Address of the destination or peer. 912 Subnet Mask - A subnet mask value (0-128) to be applied to the Ipv6 913 address. 915 10.6 Maximum Data Rate (Receive) 917 The Maximum Data Rate Receive (MDRR) TLV is a mandatory data item, 918 used in Destination Up, Destination Update, Peer Initialization, Peer 919 Update, and Link Characteristics ACK Signals to indicate the maximum 920 theoretical data rate, in bits per second, that can be achieved while 921 receiving data on the link. When metrics are reported via the signals 922 listed above, the maximum data rate receive MUST be reported. 924 0 1 2 3 925 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 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 |TLV Type =TBD |Length = 8 | MDRR (bps) | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | MDRR (bps) | 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 | MDRR (bps) | 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 TLV Type - TBD 936 Length - 8 938 Maximum Data Rate Receive - A 64-bit unsigned number, representing 939 the maximum theoretical data rate, in bits per 940 second (bps), that can be achieved while 941 receiving on the link. 943 10.7 Maximum Data Rate (Transmit) 945 The Maximum Data Rate Transmit (MDRT) TLV is a mandatory data item, 946 used in Destination Up, Destination Update, Peer Initialization, Peer 947 Update, and Link Characteristics ACK Signals to indicate the maximum 948 theoretical data rate, in bits per second, that can be achieved while 949 transmitting data on the link. When metrics are reported via the 950 signals listed above, the maximum data rate transmit MUST be 951 reported. 953 0 1 2 3 954 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 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 |TLV Type =TBD |Length = 8 | MDRT (bps) | 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 | MDRT (bps) | 959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 960 | MDRT (bps) | 961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 TLV Type - TBD 965 Length - 8 967 Maximum Data Rate Transmit - A 64-bit unsigned number, representing 968 the maximum theoretical data rate, in bits per 969 second (bps), that can be achieved while 970 transmitting on the link. 972 10.8 Current Data Rate (Receive) 974 The Current Data Rate Receive (CDRR) TLV is a mandatory data item, 975 used in Destination Up, Destination Update, Peer Initialization, Peer 976 Update, Link Characteristics Request, and Link Characteristics ACK 977 signals to indicate the rate at which the link is currently operating 978 for receiving traffic. In the case of the Link Characteristics 979 Request, CDRR represents the desired receive data rate for the link. 980 When metrics are reported via the signals above (e.g. Destination 981 Update), the current data rate receive MUST be reported. 983 The Current Data Rate Receive TLV contains the following fields: 985 0 1 2 3 986 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 |TLV Type =TBD |TLV Flags=0x10 |Length = 8 |CDRR (bps) | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | CDRR (bps) | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | CDRR (bps) | 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 TLV Type - TBD 997 Length - 8 999 Current Data Rate Receive - A 64-bit unsigned number, representing 1000 the current data rate, in bits per second, that 1001 is currently be achieved while receiving traffic 1002 on the link. When used in the Link 1003 Characteristics Request, CDRR represents the 1004 desired receive rate, in bits per second, on the 1005 link. If there is no distinction between current 1006 and maximum receive data rates, current data 1007 rate receive SHOULD be set equal to the maximum 1008 data rate receive. 1010 10.9 Current Data Rate (Transmit) 1012 The Current Data Rate Receive (CDRT) TLV is a mandatory data item, 1013 used in Destination Up, Destination Update, Peer Initialization, Peer 1014 Update, Link Characteristics Request, and Link Characteristics ACK 1015 signals to indicate the rate at which the link is currently operating 1016 for transmitting traffic. In the case of the Link Characteristics 1017 Request, CDRT represents the desired transmit data rate for the link. 1018 When metrics are reported via the signals above (e.g. Destination 1019 Update), the current data rate transmit MUST be reported. 1021 The Current Data Rate Transmit TLV contains the following fields: 1023 0 1 2 3 1024 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 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 |TLV Type =TBD |TLV Flags=0x10 |Length = 8 |CDRT (bps) | 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 | CDRT (bps) | 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 | CDRT (bps) | 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 TLV Type - TBD 1035 Length - 8 1036 Current Data Rate Transmit - A 64-bit unsigned number, representing 1037 the current data rate, in bits per second, that 1038 is currently be achieved while transmitting 1039 traffic on the link. When used in the Link 1040 Characteristics Request, CDRT represents the 1041 desired transmit rate, in bits per second, on 1042 the link. If there is no distinction between 1043 current and maximum transmit data rates, current 1044 data rate transmit MUST be set equal to the 1045 maximum data rate transmit. 1047 10.10 Latency 1049 The Latency TLV is a mandatory data item. It is used in Peer 1050 Initialization, Destination Up, Destination Update, Peer 1051 Initialization, Peer Update, Link Characteristics Request, and Link 1052 Characteristics ACK signals to indicate the amount of latency on the 1053 link, or in the case of the Link Characteristics Request, to indicate 1054 the maximum latency required on the link. 1056 0 1 2 3 1057 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 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 |TLV Type =TBD |Length = 4 | Latency in microseconds | 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 | Latency (Cont.) microsecs | 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 TLV Type - TBD 1066 Length - 4 1068 Latency - A 32-bit unsigned value, representing the transmission 1069 delay that a packet encounters as it is transmitted 1070 over the link. In Destination Up, Destination Update, 1071 and Link Characteristics ACK, this value is reported 1072 as delay, in microseconds. The calculation of latency 1073 is implementation dependent. For example, the latency 1074 may be a running average calculated from the internal 1075 queuing. If a device cannot calculate latency, this 1076 TLV SHOUD NOT be issued. In the Link Characteristics 1077 Request Signal, this value represents the maximum 1078 delay, in microseconds, expected on the link. 1080 10.11 Resources (Receive) 1081 The Receive Resources TLV is an optional data item. If supported, it 1082 is used in Destination Up, Destination Update, Peer Initialization, 1083 Peer Update, and Link Characteristics ACK signals to indicate a 1084 percentage (0-100) amount of resources (e.g. battery power), 1085 committed to receiving data, remaining on the originating peer. 1087 The Resources TLV contains the following fields: 1089 0 1 2 1090 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 |TLV Type =TBD |Length = 1 | Rcv Resources| 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 TLV Type - TBD 1097 Length - 1 1099 Receive Resources - A percentage, 0-100, representing the amount 1100 of remaining resources, such as battery power, 1101 allocated to receiving data. If a device cannot 1102 calculate receive resources, this TLV SHOULD NOT be 1103 issued. 1105 10.12 Resources (Transmit) 1107 The Transmit Resources TLV is an optional data item. If supported, it 1108 is used in Destination Up, Destination Update, Peer Initialization, 1109 Peer Update, and Link Characteristics ACK signals to indicate a 1110 percentage (0-100) amount of resources (e.g. battery power), 1111 committed to transmitting data, remaining on the originating peer. 1113 The Resources TLV contains the following fields: 1115 0 1 2 1116 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 |TLV Type =TBD |Length = 1 | Xmt Resources| 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 TLV Type - TBD 1123 Length - 1 1125 Transmit Resources - A percentage, 0-100, representing the amount 1126 of remaining resources, such as battery power, 1127 allocated to transmitting data. If the transmit 1128 resources cannot be calculated, then the TLV SHOULD 1129 NOT be issued. 1131 10.13 Relative Link Quality (Receive) 1133 The Relative Link Quality Receive (RLQR) TLV is an optional data 1134 item. If supported, it is used in Peer Initialization, Destination 1135 Up, Destination Update, Peer Initialization, Peer Update, and Link 1136 Characteristics ACK signals to indicate the quality of the link for 1137 receiving data as calculated by the originating peer. 1139 The Relative Link Quality (Receive) TLV contains the following 1140 fields: 1142 0 1 2 1143 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 |TLV Type =TBD |Length = 1 |RCV Rel. Link | 1146 | | |Quality (RLQR) | 1147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1149 TLV Type - TBD 1151 Length - 1 1153 Relative Link Quality (Receive) - A non-dimensional number, 1-100, 1154 representing relative link quality. A value of 1155 100 represents a link of the highest quality. 1156 If a device cannot calculate the RLQR, this 1157 TLV SHOULD NOT be issued. 1159 10.14 Relative Link Quality (Transmit) 1161 The Transmit Link Quality Receive (RLQT) TLV is an optional data 1162 item. It is used in Peer Initialization, Destination Up, Destination 1163 Update, Peer Initialization, Peer Update, and Link Characteristics 1164 ACK signals to indicate the quality of the link for transmitting data 1165 as calculated by the originating peer. 1167 The Relative Link Quality (Transmit) TLV contains the following 1168 fields: 1170 0 1 2 1171 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 |TLV Type =TBD |Length = 1 |XMT Rel. Link | 1174 | | |Quality (RLQR) | 1175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1177 TLV Type - TBD 1179 Length - 1 1181 Relative Link Quality (Transmit) - A non-dimensional number, 1-100, 1182 representing relative link quality. A value of 1183 100 represents a link of the highest quality. 1184 If a device cannot calculate the RLQT, this 1185 TLV SHOULD NOT be issued. 1187 10.15 Status 1189 The Status TLV is sent as part of an acknowledgement signal, from 1190 either the modem or the router, to indicate the success or failure of 1191 a given request. 1193 The Status TLV contains the following fields: 1195 0 1 2 1196 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 |TLV Type =TBD |Length = 1 | Code | 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 TLV Type - TBD 1203 Length - 1 1205 Termination Code - 0 = Success, Non-zero = Failure. Specific values 1206 of a non-zero termination code depend on the 1207 operation requested (e.g. Destination Up, 1208 Destination Down, etc). 1210 10.16 Heartbeat Interval 1212 The Heartbeat Interval TLV is a mandatory TLV. It MUST be sent during 1213 Peer Initialization to indicate the desired Heartbeat timeout window. 1214 The receiver MUST either accept the timeout interval supplied by the 1215 sender, or reject the Peer Initialization, and close the socket. 1216 Implementations MUST implement heuristics such that DLEP signals 1217 sent/received reset the timer interval. 1219 The Interval is used to specify a period (in seconds) for Heartbeat 1220 Signals (See Section 11.15). By specifying an Interval value of 0, 1221 implementations MAY indicates the desire to disable Heartbeat signals 1222 entirely (e.g., the Interval is set to an infinite value), however, 1223 it is strongly recommended that implementations use non 0 timer 1224 values. 1226 A DLEP session will be considered inactive, and MUST be torn down, by 1227 an implementation detecting that two (2) Heartbeat intervals have 1228 transpired without receipt of any DLEP signals. 1230 The Heartbeat Interval TLV contains the following fields: 1232 0 1 2 3 1233 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 1234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1235 |TLV Type =TBD |Length = 2 | Interval | 1236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1238 TLV Type - TBD 1240 Length - 2 1242 Interval - 0 = Do NOT use heartbeats on this peer-to-peer 1243 session. Non-zero = Interval, in seconds, for 1244 heartbeat signals. 1246 10.17 Link Characteristics ACK Timer 1248 The Link Characteristics ACK Timer TLV is an optional TLV. If 1249 supported, it MAY be sent during Peer Initialization to indicate the 1250 desired number of seconds to wait for a response to a Link 1251 Characteristics Request. If this TLV is omitted, implementations 1252 supporting the Link Characteristics Request SHOULD choose a default 1253 value. 1255 The Link Characteristics ACK Timer TLV contains the following fields: 1257 0 1 2 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 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 |TLV Type =TBD |Length = 1 | Interval | 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 TLV Type - TBD 1265 Length - 1 1267 Interval - 0 = Do NOT use timeouts for Link Characteristics 1268 requests on this router/modem session. Non-zero = 1269 Interval, in seconds, to wait before considering a 1270 Link Characteristics Request has been lost. 1272 10.18 Credit Window Status 1274 The Credit Window Status TLV is an optional TLV. If credits are 1275 supported by the DLEP participants (both the router and the modem), 1276 the Credit Window Status TLV MUST be sent by the participant 1277 receiving a Credit Grant Request for a given destination. 1279 The Credit Window Status TLV contains the following fields: 1281 0 1 2 3 1282 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 1283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1284 |TLV Type =TBD |Length = 16 | Modem Receive Window Value | 1285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1286 | Modem Receive Window Value | 1287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1288 | Modem Receive Window Value | Router Receive Window Value | 1289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1290 | Router Receive Window Value | 1291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1292 | Router Receive Window Value | 1293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1295 TLV Type - TBD 1297 Length - 16 1299 Modem Receive Window Value - A 64-bit unsigned number, indicating 1300 the current (or initial) number of 1301 credits available on the Modem Receive 1302 Window. 1304 Router Receive Window Value - A 64-bit unsigned number, indicating 1305 the current (or initial) number of 1306 credits available on the Router Receive 1307 Window. 1309 10.19 Credit Grant Request 1311 The Credit Grant Request TLV is an optional TLV. If credits are 1312 supported, the Credit Grant Request TLV is sent from a DLEP 1313 participant to grant an increment to credits on a window. The Credit 1314 Grant TLV is sent as a data item in either the Destination Up or 1315 Destination Update signals. The value in a Credit Grant TLV 1316 represents an increment to be added to any existing credits available 1317 on the window. Upon successful receipt and processing of a Credit 1318 Grant TLV, the receiver MUST respond with a signal containing a 1319 Credit Window Status TLV to report the updated aggregate values for 1320 synchronization purposes. 1322 In the Destination Up signal, when credits are desired, the 1323 originating peer MUST set the initial credit value of the window it 1324 controls (e.g. the Modem Receive Window, or Router Receive Window) to 1325 an initial, non-zero value. If the receiver of a Destination Up 1326 signal with a Credit Grant Request TLV supports credits, the receiver 1327 MUST either reject the use of credits, via a Destination Up ACK 1328 response with the correct Status TLV, or set the initial value from 1329 the data contained in the Credit Window Status TLV. If the 1330 initialization completes successfully, the receiver MUST respond to 1331 the Destination Up signal with a Destination Up ACK signal that 1332 contains a Credit Window Status TLV, initializing its receive window. 1334 The Credit Grant TLV contains the following fields: 1336 0 1 2 3 1337 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 |TLV Type =TBD |Length = 8 | Credit Increment | 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 | Credit Increment | 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1343 | Credit Increment | 1344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1346 TLV Type - TBD 1348 Length - 8 1350 Reserved - A 64-bit unsigned number representing the 1351 additional credits to be assigned to the credit 1352 window. Since credits can only be granted by the 1353 receiver on a window, the applicable credit window 1354 (either the MRW or the RRW) is derived from the 1355 sender of the grant. The Credit Increment MUST NOT 1356 cause the window to overflow; if this condition 1357 occurs, implementations MUST set the credit window 1358 to the maximum value contained in a 64-bit 1359 quantity. 1361 10.20 Credit Request 1362 The Credit Request TLV is an optional TLV. If credits are supported, 1363 the Credit Request TLV MAY be sent from either DLEP participant, via 1364 a Destination Update signal, to indicate the desire for the partner 1365 to grant additional credits in order for data transfer to proceed on 1366 the session. If the corresponding Destination Up signal for this 1367 session did NOT contain a Credit Window Status TLV, indicating that 1368 credits are to be used on the session, then the Credit Request TLV 1369 MUST be rejected by the receiver via a Destination Update ACK signal. 1371 The Credit Request TLV contains the following fields: 1373 0 1 2 1374 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1376 |TLV Type =TBD |Length = 1 | Reserved, MUST| 1377 | | | be set to 0 | 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1380 TLV Type - TBD 1382 Length - 1 1384 Reserved - This field is currently unused and MUST be set to 0. 1386 10.22 DLEP Optional Signals Supported 1388 The DLEP Optional Signals Supported TLV is a mandatory data item. If 1389 optional signals (e.g., the Link Characteristics Request Signal) are 1390 supported, they MUST be enumerated with this data item inserted into 1391 the Peer Initialization and Peer Initialization ACK signals. Failure 1392 to indicate optional signals indicates to a receiving peer that the 1393 sending implementation ONLY supports the core (mandatory) items 1394 listed in this specification. Optional signals that are NOT 1395 enumerated in this data item when issuing Peer Initialization or Peer 1396 Initialization ACK MUST NOT be used during the DLEP session. 1398 The DLEP Optional Signals Supported TLV contains the following 1399 fields: 1401 0 1 2 3 1402 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 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 |TLV Type =TBD |Length = 2 + |List of optional signals ... | 1405 | |number of opt. | | 1406 | |signals. | | 1407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 TLV Type - TBD 1410 Length - 2 + the number of optional signals supported 1411 List - An enumeration of the optional signal TLV Types 1412 supported by the implementation. 1414 10.21 DLEP Optional Data Items Supported 1416 The DLEP Optional Data Items Supported TLV is a mandatory data item. 1417 If optional data items (e.g., Resources) are supported, they MUST be 1418 enumerated with this data item inserted into the Peer Initialization 1419 and Peer Initialization ACK signals. Failure to indicate optional 1420 data items indicates to a receiving peer that the sending 1421 implementation ONLY supports the core (mandatory) data items listed 1422 in this specification. Optional data items that are NOT listed in 1423 this data item MUST NOT be used during the DLEP session. 1425 The DLEP Optional Data Items Supported TLV contains the following 1426 fields: 1428 0 1 2 3 1429 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1431 |TLV Type =TBD |Length = 2 + |List of optional data items ...| 1432 | |number of opt. | | 1433 | |signals. | | 1434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1436 TLV Type - TBD 1438 Length - 2 + the number of optional data items supported 1439 List - An enumeration of the optional data item TLV Types 1440 supported by the implementation. 1442 10.22 DLEP Vendor Extension 1444 The DLEP Vendor Extension data item is an optional data item, and 1445 allows for vendor-defined information to be passed between DLEP 1446 participants. The precise data carried in the payload portion of the 1447 data item is vendor-specific, however, the payload MUST adhere to a 1448 Type-Length-Value format. This optional data item is ONLY valid on 1449 Peer Initialization ACK, and if present, SHOULD contain device- 1450 specific information geared to optimizing data transmission/reception 1451 over the modem's link. 1453 The DLEP Vendor Extension Data Item TLV contains the following 1454 fields: 1456 0 1 2 3 1457 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1460 |TLV Type = TBD | Length |OUI Length | Vendor OUI + | 1461 | | | | payload... | 1462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1464 TLV Type - TBD 1466 Length - 3 + length of OUI (in octets) + payload length 1468 Vendor OUI - The vendor OUI, as specified in [IEEE] 1470 Payload - Vendor-specific payload, formatted as Type, Length, 1471 Value construct(s). 1473 11. DLEP Protocol Signals 1475 DLEP signals are encoded as a string of Type-Length-Value (TLV) 1476 constructs. The first TLV in a DLEP signal MUST be a valid DLEP 1477 signal, as defined in section 11.1 of this document. Following the 1478 signal TLV is 0 or more TLVs, representing the data items that are 1479 appropriate for the signal. The layout of a DLEP signal is thus: 1481 0 1 2 3 1482 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 1483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1484 | DLEP Signal |DLEP Signal length (3 + length |Start of DLEP | 1485 | Type value |of all data items) |data item TLVs | 1486 | (value TBD) | | | 1487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1489 All DLEP signals begin with this structure. Therefore, in the 1490 following descriptions of specific signals, this header structure is 1491 assumed, and will not be replicated. 1493 11.1 Signal TLV Values 1495 As mentioned above, all DLEP signals begin with the Type value. Valid 1496 DLEP signals are: 1498 TLV TLV 1499 Value Description 1500 ========================================= 1501 TBD Peer Discovery 1502 TBD Peer Offer 1503 TBD Peer Initialization 1504 TBD Peer Update 1505 TBD Peer Update ACK 1506 TBD Peer Termination 1507 TBD Peer Termination ACK 1508 TBD Destination Up 1509 TBD Destination Up ACK 1510 TBD Destination Down 1511 TBD Destination Down ACK 1512 TBD Destination Update 1513 TBD Heartbeat 1514 TBD Link Characteristics Request 1515 TBD Link Characteristics ACK 1517 11.2 Peer Discovery Signal 1519 The Peer Discovery Signal is sent by a router to discover DLEP 1520 routers in the network. The Peer Offer signal is required to complete 1521 the discovery process. Implementations MAY implement their own retry 1522 heuristics in cases where it is determined the Peer Discovery Signal 1523 has timed out. 1525 Given the packet format described in section 11, the initial TLV Type 1526 value is set to DLEP_PEER_DISCOVERY (value TBD). 1528 There are NO Data Item TLVs associated with the Peer Discovery 1529 signal. 1531 11.3 Peer Offer Signal 1533 The Peer Offer Signal is sent by a DLEP modem in response to a Peer 1534 Discovery Signal. Upon receipt, and processing, of a Peer Offer 1535 signal, the router responds by issuing a TCP connect to the 1536 address/port combination specified in the received Peer Offer. 1538 The Peer Offer signal MUST be sent to the unicast address of the 1539 originator of Peer Discovery. 1541 To construct a Peer Offer signal, the initial TLV type value is set 1542 to DLEP_PEER_OFFER (value TBD). The signal TLV is then followed by 1543 all MANDATORY Data Item TLVs, then by any OPTIONAL Data Item TLVs the 1544 implementation supports: 1546 Mandatory Data Item TLVs: 1547 - Heartbeat Interval 1548 - At least one (1) IPv4 or IPv6 Address TLV 1549 - DLEP Port 1551 Optional Data Item TLVs: 1552 - Peer Type 1553 - Status 1555 11.4 Peer Initialization Signal 1557 The Peer Initialization signal is sent by a router to start the DLEP 1558 TCP session. It is sent by the router after a TCP connect to an 1559 address/port combination that was obtained either via receipt of a 1560 Peer Offer, or from a-priori configuration. If any optional signals 1561 or data items are supported by the implementation, they MUST be 1562 enumerated in the DLEP Optional Signals Supported and DLEP Optional 1563 Data Items Supported items. 1565 Mandatory Data Item TLVs: 1566 - Heartbeat Interval 1567 - Optional Signals Supported 1568 - Optional Data Items Supported 1569 Optional Data Item TLVs: 1570 - Peer Type 1571 Note that optional signals and data items supported MUST be supplied 1572 with the Peer Initialization, so that the modem may determine what 1573 optional support is available within the router. If the Optional 1574 Signals Supported (or the Optional Data Items Supported) TLV is 1575 absent in Peer Initialization, the receiver of the signal MUST 1576 conclude that there is NO optional support in the sender. 1578 11.5 Peer Initialization ACK Signal 1580 The Peer Initialization ACK signal is a mandatory signal, sent in 1581 response to a received Peer Initialization signal. The Peer 1582 Initialization ACK signal completes the TCP-level DLEP session 1583 establishment; the sender of the signal should transition to an "in- 1584 session" state when the signal is sent, and the receiver should 1585 transition to the "in-session" state upon receipt (and successful 1586 parsing) of Peer Initialization ACK. 1588 All supported metric data items MUST be included in the Peer 1589 Initialization ACK signal, with default values to be used on a 1590 "modem-wide" basis. This can be viewed as the modem "declaring" all 1591 supported metrics at DLEP session initialization. Receipt of any DLEP 1592 signal containing a metric data item NOT included in Peer 1593 Initialization ACK MUST be treated as an error, resulting in 1594 termination of the DLEP session between router and modem. If optional 1595 signals and/or data items are supported by the modem, they MUST be 1596 enumerated in the DLEP Optional Signals supported and DLEP Optional 1597 data items supported TLVs. 1599 The Peer Initialization ACK signal MAY contain the DLEP Vendor 1600 Extension data item, as documented in section 10.22 1601 After the Peer Initialization/Peer Initialization ACK signals have 1602 been successfully exchanged, implementations SHOULD only utilize 1603 options that are supported in BOTH peers (e.g. router and modem). Any 1604 attempt by a DLEP session peer to send an optional signal to a peer 1605 without support MUST result in an error which terminates the session. 1606 Any optional data item sent to a peer without support will be ignored 1607 and silently dropped. 1609 To construct a Peer Initialization ACK signal, the initial TLV type 1610 value is set to DLEP_PEER_INIT_ACK (value TBD). The signal TLV is 1611 then followed by the required data items: 1613 Mandatory Data Item TLVs: 1614 - Heartbeat Interval 1615 - Maximum Data Rate Receive 1616 - Maximum Data Rate Transmit 1617 - Current Data Rate Receive 1618 - Current Data Rate Transmit 1619 - Latency 1620 - Relative Link Quality Receive 1621 - Relative Link Quality Transmit 1622 - DLEP Optional Signals Supported 1623 - DLEP Optional Data Items Supported 1624 - Status 1625 Optional Data Item TLVs: 1626 - Peer Type 1627 - DLEP Vendor Extension 1629 11.6 Peer Update Signal 1631 The Peer Update signal is an optional signal, sent by a DLEP peer to 1632 indicate local Layer 3 address changes, or for metric changes on a 1633 modem-wide basis. For example, addition of an IPv4 address to the 1634 router MAY prompt a Peer Update signal to its attached DLEP modems. 1635 Also, a modem that changes its Maximum Data Rate for all destinations 1636 MAY reflect that change via a Peer Update Signal to its attached 1637 router(s). 1639 Concerning Layer 3 addresses, if the modem is capable of 1640 understanding and forwarding this information (via proprietary 1641 mechanisms), the address update would prompt any remote DLEP modems 1642 (DLEP-enabled modems in a remote node) to issue a "Destination 1643 Update" signal to their local routers with the new (or deleted) 1644 addresses. Modems that do not track Layer 3 addresses SHOULD silently 1645 parse and ignore the Peer Update Signal. Modems that track Layer 3 1646 addresses MUST acknowledge the Peer Update with a Peer Update ACK 1647 signal. Routers receiving a Peer Update with metric changes MUST 1648 apply the new metric to all destinations (remote nodes) accessible 1649 via the modem. Supporting implementations are free to employ 1650 heuristics to retransmit Peer Update signals. The sending of Peer 1651 Update Signals for Layer 3 address changes SHOULD cease when a either 1652 participant (router or modem) determines that the other 1653 implementation does NOT support Layer 3 address tracking. 1655 If metrics are supplied with the Peer Update signal (e.g. Maximum 1656 Data Rate), these metrics are considered to be modem-wide, and 1657 therefore MUST be applied to all destinations in the information base 1658 associated with the router/modem session. 1660 To construct a Peer Update signal, the initial TLV type value is set 1661 to DLEP_PEER_UPDATE (value TBD). The Signal TLV is followed by any 1662 OPTIONAL Data Item TLVs. 1664 Optional Data Item TLVs: 1665 - IPv4 Address 1666 - IPv6 Address 1667 - Maximum Data Rate (Receive) 1668 - Maximum Data Rate (Transmit) 1669 - Current Data Rate (Receive) 1670 - Current Data Rate (Transmit) 1671 - Latency 1672 - Resources (Receive) 1673 - Resources (Transmit) 1674 - Relative Link Quality (Receive) 1675 - Relative Link Quality (Transmit) 1677 11.7 Peer Update ACK Signal 1679 The Peer Update ACK signal is an optional signal, and is sent by 1680 implementations supporting Layer 3 address tracking and/or modem-wide 1681 metrics to indicate whether a Peer Update Signal was successfully 1682 processed. If the Peer Update ACK is issued, it MUST contain a Status 1683 data item, indicating the success or failure of processing the 1684 received Peer Update. 1686 To construct a Peer Update ACK signal, the initial TLV type value is 1687 set to DLEP_PEER_UPDATE_ACK (value TBD). The Status data item TLV is 1688 placed in the packet next, completing the Peer Update ACK. 1690 Mandatory Data Item TLVs: 1692 - Status 1694 Note that there are NO optional data item TLVs specified for this 1695 signal. 1697 11.8 Peer Termination Signal 1699 The Peer Termination Signal is sent by a DLEP participant when the 1700 router/modem session needs to be terminated. Implementations 1701 receiving a Peer Termination signal MUST send a Peer Termination ACK 1702 signal to confirm the termination process. The sender of a Peer 1703 Termination signal is free to define its heuristics in event of a 1704 timeout. The receiver of a Peer Termination Signal MUST release all 1705 resources allocated for the router/modem session, and MUST eliminate 1706 all destinations in the information base accessible via the 1707 router/modem pair represented by the session. Router and modem state 1708 machines are returned to the "discovery" state. No Destination Down 1709 signals are sent. 1711 To construct a Peer Termination signal, the initial TLV type value is 1712 set to DLEP_PEER_TERMINATION (value TBD). The signal TLV is followed 1713 by any OPTIONAL Data Item TLVs the implementation supports: 1715 Optional Data Item TLVs: 1717 - Status 1719 11.9 Peer Termination ACK Signal 1721 The Peer Termination Signal ACK is sent by a DLEP peer in response to 1722 a received Peer Termination order. Receipt of a Peer Termination ACK 1723 signal completes the teardown of the router/modem session. 1725 To construct a Peer Termination ACK signal, the initial TLV type 1726 value is set to DLEP_PEER_TERMINATION_ACK (value TBD). The 1727 Identification data item TLV is placed in the packet next, followed 1728 by any OPTIONAL TLVs the implementation supports: 1730 Optional Data Item TLVs: 1732 - Status 1734 11.10 Destination Up Signal 1736 A DLEP participant sends the Destination Up signal to report that a 1737 new destination has been detected. A Destination Up ACK Signal is 1738 required to confirm a received Destination Up. A Destination Up 1739 signal can be sent either by the modem, to indicate that a new remote 1740 node has been detected, or by the router, to indicate the presence of 1741 a new logical destination (e.g., a Multicast group) exists in the 1742 network. 1744 The sender of the Destination Up Signal is free to define its retry 1745 heuristics in event of a timeout. When a Destination Up signal is 1746 received and successfully parsed, the receiver should add knowledge 1747 of the new destination to its information base, indicating that the 1748 destination is accessible via the modem/router pair. 1750 To construct a Destination Up signal, the initial TLV type value is 1751 set to DLEP_DESTINATION_UP (value TBD). The MAC Address data item TLV 1752 is placed in the packet next, followed by any supported optional Data 1753 Item TLVs into the packet: 1755 Optional Data Item TLVs: 1757 - IPv4 Address 1758 - IPv6 Address 1759 - Maximum Data Rate (Receive) 1760 - Maximum Data Rate (Transmit) 1761 - Current Data Rate (Receive) 1762 - Current Data Rate (Transmit) 1763 - Latency 1764 - Resources (Receive) 1765 - Resources (Transmit) 1766 - Relative Link Factor (Receive) 1767 - Relative Link Factor (Transmit) 1768 - Credit Window Status 1770 11.11 Destination Up ACK Signal 1772 A DLEP participant sends the Destination Up ACK Signal to indicate 1773 whether a Destination Up Signal was successfully processed. 1775 To construct a Destination Up ACK signal, the initial TLV type value 1776 is set to DLEP_DESTINATION_UP_ACK (value TBD). The MAC Address data 1777 item TLV is placed in the packet next, containing the MAC address of 1778 the DLEP destination. The implementation would then place any 1779 supported optional Data Item TLVs into the packet: 1781 Optional Data Item TLVs: 1782 - Credit Window Status 1784 11.12 Destination Down Signal 1786 A DLEP peer sends the Destination Down signal to report when a 1787 destination (a remote node or a multicast group) is no longer 1788 reachable. The Destination Down signal MUST contain the MAC Address 1789 data item TLV. Other TLVs as listed are OPTIONAL, and MAY be present 1790 if an implementation supports them. A Destination Down ACK Signal 1791 MUST be sent by the recipient of a Destination Down signal to confirm 1792 that the relevant data has been removed from the information base. 1794 The sender of the Destination Down signal is free to define its retry 1795 heuristics in event of a timeout. 1797 To construct a Destination Down signal, the initial TLV type value is 1798 set to DLEP_DESTINATION_DOWN (value TBD). The signal TLV is followed 1799 by the mandatory MAC Address data item TLV. 1801 Note that there are NO OPTIONAL data item TLVs for this signal. 1803 11.13 Destination Down ACK Signal 1805 A DLEP participant sends the Destination Down ACK Signal to indicate 1806 whether a received Destination Down Signal was successfully 1807 processed. If successfully processed, the sender of the ACK MUST have 1808 removed all entries in the information base that pertain to the 1809 referenced destination. As with the Destination Down signal, there 1810 are NO OPTIONAL Data Item TLVs defined for the Destination Down ACK 1811 signal. 1813 To construct a Destination Down signal, the initial TLV type value is 1814 set to DLEP_DESTINATION_DOWN_ACK (value TBD). The mandatory data item 1815 TLVs follow: 1817 - MAC Address Data item 1818 - Status data item 1820 11.14 Destination Update Signal 1822 A DLEP participant sends the Destination Update signal when it 1823 detects some change in the information base for a given destination 1824 (remote node or multicast group). Some examples of changes that would 1825 prompt a Destination Update signal are: 1827 - Change in link metrics (e.g., Data Rates) 1828 - Layer 3 addressing change (for implementations that support it) 1830 To construct a Destination Update signal, the initial TLV type value 1831 is set to DLEP_DESTINATION_UPDATE (value TBD). Following the signal 1832 TLV are the mandatory Data Item TLVs: 1834 MAC Address data item TLV 1836 After placing the mandatory data item TLV into the packet, the 1837 implementation would place any supported OPTIONAL data item TLVs. 1838 Possible OPTIONAL data item TLVs are: 1840 - IPv4 Address 1841 - IPv6 Address 1842 - Maximum Data Rate (Receive) 1843 - Maximum Data Rate (Transmit) 1844 - Current Data Rate (Receive) 1845 - Current Data Rate (Transmit) 1846 - Latency 1847 - Resources (Receive) 1848 - Resources (Transmit) 1849 - Relative Link Quality (Receive) 1850 - Relative Link Quality (Transmit) 1851 - Credit Window Status 1852 - Credit Grant 1853 - Credit Request 1855 11.15 Heartbeat Signal 1857 A Heartbeat Signal is sent by a DLEP participant every N seconds, 1858 where N is defined in the "Heartbeat Interval" field of the Peer 1859 Initialization signal. Note that implementations setting the 1860 Heartbeat Interval to 0 effectively set the interval to an infinite 1861 value, therefore, in those cases, this signal would NOT be sent. 1863 The signal is used by participants to detect when a DLEP session 1864 partner (either the modem or the router) is no longer communicating. 1865 Participants SHOULD allow two (2) heartbeat intervals to expire with 1866 no traffic on the router/modem session before initiating DLEP session 1867 termination procedures. 1869 To construct a Heartbeat signal, the initial TLV type value is set to 1870 DLEP_PEER_HEARTBEAT (value TBD). The signal TLV is followed by the 1871 mandatory Heartbeat Interval/Threshold data item. 1873 Note that there are NO OPTIONAL data item TLVs for this signal. 1875 11.16 Link Characteristics Request Signal 1877 The Link Characteristics Request Signal is an optional signal, and is 1878 sent by the router to request that the modem initiate changes for 1879 specific characteristics of the link. The request can reference 1880 either a real (e.g., a remote node), or a logical (e.g., a multicast 1881 group) destination within the network. 1883 The Link Characteristics Request signal contains either a Current 1884 Data Rate (CDRR or CDRT) TLV to request a different datarate than 1885 what is currently allocated, a Latency TLV to request that traffic 1886 delay on the link not exceed the specified value, or both. A Link 1887 Characteristics ACK Signal is required to complete the request. 1888 Implementations are free to define their retry heuristics in event of 1889 a timeout. Issuing a Link Characteristics Request with ONLY the MAC 1890 Address TLV is a mechanism a peer MAY use to request metrics (via the 1891 Link Characteristics ACK) from its partner. 1893 To construct a Link Characteristics Request signal, the initial TLV 1894 type value is set to DLEP_Destination_LINK_CHAR_REQ (value TBD). 1895 Following the signal TLV is the mandatory Data Item TLV: 1897 MAC Address data item TLV 1899 After placing the mandatory data item TLV into the packet, the 1900 implementation would place any supported OPTIONAL data item TLVs. 1901 Possible optional data item TLVs are: 1903 Current Data Rate - If present, this value represents the NEW (or 1904 unchanged, if the request is denied) Current 1905 Data Rate in bits per second (bps). 1907 Latency - If present, this value represents the maximum 1908 desired latency (e.g., it is a not-to-exceed 1909 value) in microseconds on the link. 1911 11.17 Link Characteristics ACK Signal 1913 The LInk Characteristics ACK signal is an optional signal, and is 1914 sent by modems supporting it to the router letting the router know 1915 the success or failure of a requested change in link characteristics. 1916 The Link Characteristics ACK signal SHOULD contain a complete set of 1917 metric data item TLVs. It MUST contain the same TLV types as the 1918 request. The values in the metric data item TLVs in the Link 1919 Characteristics ACK signal MUST reflect the link characteristics 1920 after the request has been processed. 1922 To construct a Link Characteristics Request ACK signal, the initial 1923 TLV type value is set to DLEP_Destination_LINK_CHAR_ACK (value TBD). 1924 Following the signal TLV is the mandatory Data Item TLV: 1926 MAC Address data item TLV 1928 After placing the mandatory data item TLV into the packet, the 1929 implementation would place any supported OPTIONAL data item TLVs. 1930 Possible OPTIONAL data item TLVs are: 1932 Current Data Rate - If present, this value represents the requested 1933 data rate in bits per second (bps). 1935 Latency - If present, this value represents the NEW 1936 maximum latency (or unchanged, if the request 1937 is denied), expressed in microseconds, on the 1938 link. 1940 12. Security Considerations 1942 The protocol does not contain any mechanisms for security (e.g. 1943 authentication or encryption). The protocol assumes that any security 1944 would be implemented in the underlying transport (for example, by use 1945 of DTLS or some other mechanism), and is therefore outside the scope 1946 of this document. 1948 13. IANA Considerations 1950 This section specifies requests to IANA. 1952 13.1 Registrations 1954 This specification defines: 1956 o A new repository for DLEP signals, with fifteen values currently 1957 assigned. 1959 o Reservation of numbering space for Experimental DLEP signals. 1961 o A new repository for DLEP Data Items, with twenty-one values 1962 currently assigned. 1964 o Reservation of numbering space in the Data Items repository for 1965 experimental data items. 1967 o A request for allocation of a well-known port for DLEP 1968 communication. 1970 o A request for allocation of a multicast address for DLEP 1971 discovery. 1973 13.2 Expert Review: Evaluation Guidelines 1975 No additional guidelines for expert review are anticipated. 1977 13.3 Signal TLV Type Registration 1979 A new repository must be created with the values of the DLEP signals. 1981 Valid signals are: 1983 o Peer Discovery 1984 o Peer Offer 1985 o Peer Initialization 1986 o Peer Initialization ACK 1987 o Peer Update 1988 o Peer Update ACK 1989 o Peer Termination 1990 o Peer Termination ACK 1991 o Destination Up 1992 o Destination Up ACK 1993 o Destination Down 1994 o Destination Down ACK 1995 o Destination Update 1996 o Heartbeat 1997 o Link Characteristics Request 1998 o Link Characteristics ACK 2000 It is also requested that the repository contain space for 2001 experimental signal types. 2003 13.4 DLEP Data Item Registrations 2005 A new repository for DLEP Data Items must be created. Valid Data 2006 Items are: 2008 o Peer Type 2009 o MAC Address 2010 o IPv4 Address 2011 o IPv6 Address 2012 o Maximum Data Rate (Receive) 2013 o Maximum Data Rate (Transmit) 2014 o Current Data Rate (Receive) 2015 o Current Data Rate (Transmit) 2016 o Latency 2017 o Resources (Receive) 2018 o Resources (Transmit) 2019 o Relative Link Quality (Receive) 2020 o Relative Link Quality (Transmit) 2021 o Status 2022 o Heartbeat Interval/Threshold 2023 o Link Characteristics ACK Timer 2024 o Credit Window Status 2025 o Credit Grant 2026 o Credit Request 2027 o DLEP Optional Signals Supported 2028 o DLEP Optional Data Items Supported 2029 o DLEP Vendor Extension 2031 It is also requested that the registry allocation contain space for 2032 experimental data items. 2034 13.5 DLEP Well-known Port 2036 It is requested that IANA allocate a well-known port number for DLEP 2037 communication. 2039 13.6 DLEP Multicast Address 2041 It is requested that IANA allocate a multicast address for DLEP 2042 discovery signals. 2044 14. Appendix A. 2046 14.1 Peer Level Signal Flows 2048 14.1.1 Modem Device Restarts Discovery 2050 Router Modem Signal Description 2051 ==================================================================== 2053 <-------Peer Discovery--------- Modem initiates discovery 2055 ---------Peer Offer-----------> Router detects a problem, sends 2056 w/ Non-zero Status TLV Peer Offer w/Status TLV indicating 2057 the error. 2059 Modem accepts failure, restarts 2060 discovery process. 2062 <-------Peer Discovery--------- Modem initiates discovery 2064 ---------Peer Offer-----------> Router accepts, sends Peer Offer 2065 w/ Zero Status TLV w/ Status TLV indicating success. 2067 Discovery completed. 2069 14.1.2 Modem Device Detects Peer Offer Timeout 2070 Router Modem Signal Description 2071 ==================================================================== 2073 <-------Peer Discovery--------- Modem initiates discovery, starts 2074 a guard timer. 2076 Modem guard timer expires. Modem 2077 restarts discovery process. 2079 <-------Peer Discovery--------- Modem initiates discovery, starts 2080 a guard timer. 2082 ---------Peer Offer-----------> Router accepts, sends Peer Offer 2083 w/ Zero Status TLV w/ Status TLV indicating success. 2085 Discovery completed. 2087 14.1.3 Router Peer Offer Lost 2089 Router Modem Signal Description 2090 ==================================================================== 2092 <-------Peer Discovery--------- Modem initiates discovery, starts 2093 a guard timer. 2095 ---------Peer Offer-------|| Router offers availability 2097 Modem times out on Peer Offer, 2098 restarts discovery process. 2100 <-------Peer Discovery--------- Modem initiates discovery 2102 ---------Peer Offer-----------> Router detects subsequent 2103 discovery, internally terminates 2104 the previous, accepts the new 2105 association, sends Peer Offer 2106 w/Status TLV indicating success. 2108 Discovery completed. 2110 14.1.4 Discovery Success 2112 Router Modem Signal Description 2113 ==================================================================== 2115 <-------Peer Discovery--------- Modem initiates discovery 2117 ---------Peer Offer-----------> Router offers availability 2119 <-----Peer Initialization------ Modem Connects on TCP Port 2121 <------Peer Heartbeat---------- 2123 -------Peer Heartbeat---------> 2125 <==============================> Signal flow about destinations 2126 (i.e. Destination Up, Destination 2127 Down, Destination update) 2129 <-------Peer Heartbeat--------- 2131 -------Peer Heartbeat---------> 2132 --------Peer Term Req---------> Terminate Request 2134 <--------Peer Term Res--------- Terminate Response 2136 14.1.5 Router Detects a Heartbeat timeout 2138 Router Modem Signal Description 2139 ==================================================================== 2141 <-------Peer Heartbeat--------- 2143 -------Peer Heartbeat---------> 2145 ||---Peer Heartbeat--------- 2147 ~ ~ ~ ~ ~ ~ ~ 2149 -------Peer Heartbeat---------> 2151 ||---Peer Heartbeat--------- 2152 Router Heartbeat Timer expires, 2153 detects missing heartbeats. Router 2154 takes down all destination sessions 2155 and terminates the Peer 2156 association. 2158 ------Peer Terminate ---------> Peer Terminate Request 2160 Modem takes down all destination 2161 sessions, then acknowledges the 2162 Peer Terminate 2164 <----Peer Terminate ACK--------- Peer Terminate ACK 2166 14.1.6 Modem Detects a Heartbeat timeout 2168 Router Modem Signal Description 2169 ==================================================================== 2171 <-------Peer Heartbeat--------- 2173 -------Peer Heartbeat------|| 2175 <-------Peer Heartbeat--------- 2177 ~ ~ ~ ~ ~ ~ ~ 2179 -------Peer Heartbeat------|| 2181 <-------Peer Heartbeat--------- 2182 Modem Heartbeat Timer expires, 2183 detects missing heartbeats. Modem 2184 takes down all destination sessions 2186 <-------Peer Terminate-------- Peer Terminate Request 2188 Router takes down all destination 2189 sessions, then acknowledges the 2190 Peer Terminate 2192 ------Peer Terminate ACK-----> Peer Terminate ACK 2194 14.1.7 Peer Terminate (from Modem) Lost 2196 Router Modem Signal Description 2197 ==================================================================== 2199 ||------Peer Terminate-------- Modem Peer Terminate Request 2201 Router Heartbeat times out, 2202 terminates association. 2204 --------Peer Terminate-------> Router Peer Terminate 2206 <-----Peer Terminate ACK------ Modem sends Peer Terminate ACK 2208 14.1.8 Peer Terminate (from Router) Lost 2210 Router Modem Signal Description 2211 ==================================================================== 2213 -------Peer Terminate--------> Router Peer Terminate Request 2215 Modem HB times out, 2216 terminates association. 2218 <------Peer Terminate-------- Modem Peer Terminate 2220 ------Peer Terminate ACK-----> Peer Terminate ACK 2222 14.2 Destination Specific Signal Flows 2223 14.2.1 Modem Destination Up Lost 2225 Router Modem Signal Description 2226 ==================================================================== 2228 ||-----Destination Up ------------ Modem sends Destination Up 2230 Modem timesout on ACK 2232 <------Destination Up ------------ Modem sends Destination Up 2234 ------Destination Up ACK---------> Router accepts the destination 2235 session 2237 <------Destination Update--------- Modem Destination Metrics 2238 . . . . . . . . 2239 <------Destination Update--------- Modem Destination Metrics 2241 14.2.2 Router Detects Duplicate Destination Ups 2243 Router Modem Signal Description 2244 ==================================================================== 2246 <------Destination Up ------------ Modem sends Destination Up 2248 ------Destination Up ACK-------|| Router accepts the destination 2249 session 2251 Modem timesout on ACK 2253 <------Destination Up ------------ Modem resends Destination Up 2255 Router detects duplicate 2256 Destination, takes down the 2257 previous, accepts the new 2258 Destination. 2260 ------Destination Up ACK---------> Router accepts the destination 2261 session 2263 <------Destination Update--------- Modem Destination Metrics 2264 . . . . . . . . 2265 <------Destination Update--------- Modem Destination Metrics 2267 14.2.3 Destination Up, No Layer 3 Addresses 2269 Router Modem Signal Description 2270 ==================================================================== 2272 <------Destination Up ------------ Modem sends Destination Up 2274 ------Destination Up ACK---------> Router accepts the destination 2275 session 2277 Router ARPs for IPv4 if defined. 2278 Router drives ND for IPv6 if 2279 defined. 2281 <------Destination Update--------- Modem Destination Metrics 2282 . . . . . . . . 2283 <------Destination Update--------- Modem Destination Metrics 2285 14.2.4 Destination Up with IPv4, No IPv6 2287 Router Modem Signal Description 2288 ==================================================================== 2290 <------Destination Up ------------ Modem sends Destination Up with 2291 the IPv4 TLV 2293 ------Destination Up ACK---------> Router accepts the destination 2294 session 2296 Router drives ND for IPv6 if 2297 defined. 2299 <------Destination Update--------- Modem Destination Metrics 2300 . . . . . . . . 2301 <------Destination Update--------- Modem Destination Metrics 2303 14.2.5 Destination Up with IPv4 and IPv6 2305 Router Modem Signal Description 2306 ==================================================================== 2308 <------Destination Up ------------ Modem sends Destination Up with 2309 the IPv4 and IPv6 TLVs 2311 ------Destination Up ACK---------> Router accepts the destination 2312 session 2314 <------Destination Update--------- Modem Destination Metrics 2315 . . . . . . . . 2317 14.2.6 Destination Session Success 2319 Router Modem Signal Description 2320 ==================================================================== 2322 ---------Peer Offer-----------> Router offers availability 2324 -------Peer Heartbeat---------> 2326 <------Destination Up ----------- Modem 2328 ------Destination Up ACK--------> Router 2330 <------Destination Update--------- Modem 2331 . . . . . . . . 2332 <------Destination Update--------- Modem 2334 Modem initiates the terminate 2336 <------Destination Down ---------- Modem 2338 ------Destination Down ACK-------> Router 2340 or 2342 Router initiates the terminate 2344 ------Destination Down ----------> Router 2346 <------Destination Down ACK------- Modem 2348 Acknowledgements 2350 The authors would like to acknowledge and thank the members of the 2351 DLEP design team, who have provided invaluable insight. The members 2352 of the design team are: Teco Boot, Bow-Nan Cheng, John Dowdell, 2353 Henning Rogge, and Rick Taylor. 2355 The authors would also like to acknowledge the influence and 2356 contributions of Chris Olsen, Martin Duke, Subir Das, Jaewon Kang, 2357 Vikram Kaul, and Nelson Powell. 2359 Normative References 2361 [RFC5578] Berry, B., Ed., "PPPoE with Credit Flow and Metrics", 2362 RFC 5578, February 2010. 2364 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2366 [IEEE] http://standards.ieee.org/develop/regauth/oui/index.html 2368 Informative References 2370 [TLS] Dierks, T. and Rescorla, E. "The Transport Layer Security 2371 (TLS) Protocol", RFC 5246, August 2008. 2373 Author's Addresses 2375 Stan Ratliff 2376 Cisco 2377 170 West Tasman Drive 2378 San Jose, CA 95134 2379 USA 2380 EMail: sratliff@cisco.com 2382 Bo Berry 2383 Cisco 2384 170 West Tasman Drive 2385 San Jose, CA 95134 2386 USA 2387 EMail: 2389 Greg Harrison 2390 Cisco 2391 170 West Tasman Drive 2392 San Jose, CA 95134 2393 USA 2394 EMail: greharri@cisco.com 2396 Shawn Jury 2397 Cisco 2398 170 West Tasman Drive 2399 San Jose, CA 95134 2400 USA 2401 Email: sjury@cisco.com 2403 Darryl Satterwhite 2404 Broadcom 2405 USA 2406 Email: dsatterw@broadcom.com