idnits 2.17.1 draft-ietf-manet-dlep-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 273 has weird spacing: '... Shared o ...' == Line 274 has weird spacing: '... Medium o...' -- The document date (May 5, 2015) is 3277 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 5578 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile Ad hoc Networks Working Group S. Ratliff 2 Internet-Draft VT iDirect 3 Intended status: Standards Track B. Berry 4 Expires: November 6, 2015 5 S. Jury 6 Cisco Systems 7 D. Satterwhite 8 Broadcom 9 R. Taylor 10 Airbus Defence & Space 11 May 5, 2015 13 Dynamic Link Exchange Protocol (DLEP) 14 draft-ietf-manet-dlep-10 16 Abstract 18 When routing devices rely on modems to effect communications over 19 wireless links, they need timely and accurate knowledge of the 20 characteristics of the link (speed, state, etc.) in order to make 21 forwarding decisions. In mobile or other environments where these 22 characteristics change frequently, manual configurations or the 23 inference of state through routing or transport protocols does not 24 allow the router to make the best decisions. A bidirectional, event- 25 driven communication channel between the router and the modem is 26 necessary. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on November 6, 2015. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 7 64 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 8 65 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 3. Core Features and Optional Extensions . . . . . . . . . . . . 10 67 3.1. Negotiation of Optional Extensions . . . . . . . . . . . 10 68 3.2. Protocol Extensions . . . . . . . . . . . . . . . . . . . 11 69 3.3. Experimental Signals and Data Items . . . . . . . . . . . 11 70 4. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 4.1. Mandatory Metrics . . . . . . . . . . . . . . . . . . . . 12 72 5. DLEP Session Flow . . . . . . . . . . . . . . . . . . . . . . 12 73 5.1. DLEP Router session flow - Discovery case . . . . . . . . 13 74 5.2. DLEP Router session flow - Configured case . . . . . . . 13 75 5.3. DLEP Modem session flow . . . . . . . . . . . . . . . . . 14 76 5.4. Common Session Flow . . . . . . . . . . . . . . . . . . . 14 77 6. DLEP Message Processing . . . . . . . . . . . . . . . . . . . 16 78 6.1. DLEP Signal Header . . . . . . . . . . . . . . . . . . . 16 79 6.2. DLEP Generic Data Item . . . . . . . . . . . . . . . . . 17 80 7. DLEP Signals . . . . . . . . . . . . . . . . . . . . . . . . 17 81 7.1. Peer Discovery Signal . . . . . . . . . . . . . . . . . . 18 82 7.2. Peer Offer Signal . . . . . . . . . . . . . . . . . . . . 18 83 7.3. Peer Initialization Signal . . . . . . . . . . . . . . . 19 84 7.4. Peer Initialization ACK Signal . . . . . . . . . . . . . 20 85 7.5. Peer Update Signal . . . . . . . . . . . . . . . . . . . 22 86 7.6. Peer Update ACK Signal . . . . . . . . . . . . . . . . . 23 87 7.7. Peer Termination Signal . . . . . . . . . . . . . . . . . 24 88 7.8. Peer Termination ACK Signal . . . . . . . . . . . . . . . 24 89 7.9. Destination Up Signal . . . . . . . . . . . . . . . . . . 25 90 7.10. Destination Up ACK Signal . . . . . . . . . . . . . . . . 26 91 7.11. Destination Down Signal . . . . . . . . . . . . . . . . . 27 92 7.12. Destination Down ACK Signal . . . . . . . . . . . . . . . 27 93 7.13. Destination Update Signal . . . . . . . . . . . . . . . . 28 94 7.14. Heartbeat Signal . . . . . . . . . . . . . . . . . . . . 29 95 7.15. Link Characteristics Request Signal . . . . . . . . . . . 29 96 7.16. Link Characteristics ACK Signal . . . . . . . . . . . . . 30 97 8. DLEP Data Items . . . . . . . . . . . . . . . . . . . . . . . 31 98 8.1. DLEP Version . . . . . . . . . . . . . . . . . . . . . . 32 99 8.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . 33 100 8.3. IPv4 Connection Point . . . . . . . . . . . . . . . . . . 34 101 8.4. IPv6 Connection Point . . . . . . . . . . . . . . . . . . 35 102 8.5. Peer Type . . . . . . . . . . . . . . . . . . . . . . . . 36 103 8.6. Heartbeat Interval . . . . . . . . . . . . . . . . . . . 36 104 8.7. Extensions Supported . . . . . . . . . . . . . . . . . . 37 105 8.8. Experimental Definition . . . . . . . . . . . . . . . . . 37 106 8.9. MAC Address . . . . . . . . . . . . . . . . . . . . . . . 38 107 8.10. IPv4 Address . . . . . . . . . . . . . . . . . . . . . . 39 108 8.11. IPv6 Address . . . . . . . . . . . . . . . . . . . . . . 39 109 8.12. IPv4 Attached Subnet . . . . . . . . . . . . . . . . . . 40 110 8.13. IPv6 Attached Subnet . . . . . . . . . . . . . . . . . . 41 111 8.14. Maximum Data Rate (Receive) . . . . . . . . . . . . . . . 41 112 8.15. Maximum Data Rate (Transmit) . . . . . . . . . . . . . . 42 113 8.16. Current Data Rate (Receive) . . . . . . . . . . . . . . . 43 114 8.17. Current Data Rate (Transmit) . . . . . . . . . . . . . . 43 115 8.18. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 44 116 8.19. Resources (Receive) . . . . . . . . . . . . . . . . . . . 45 117 8.20. Resources (Transmit) . . . . . . . . . . . . . . . . . . 46 118 8.21. Relative Link Quality (Receive) . . . . . . . . . . . . . 46 119 8.22. Relative Link Quality (Transmit) . . . . . . . . . . . . 47 120 8.23. Link Characteristics ACK Timer . . . . . . . . . . . . . 47 121 9. Credit-Windowing . . . . . . . . . . . . . . . . . . . . . . 48 122 9.1. Credit-Windowing Signals . . . . . . . . . . . . . . . . 48 123 9.1.1. Destination Up Signal . . . . . . . . . . . . . . . . 49 124 9.1.2. Destination Up ACK Signal . . . . . . . . . . . . . . 49 125 9.1.3. Destination Update Signal . . . . . . . . . . . . . . 49 126 9.2. Credit-Windowing Data Items . . . . . . . . . . . . . . . 49 127 9.2.1. Credit Grant . . . . . . . . . . . . . . . . . . . . 50 128 9.2.2. Credit Window Status . . . . . . . . . . . . . . . . 51 129 9.2.3. Credit Request . . . . . . . . . . . . . . . . . . . 51 130 10. Security Considerations . . . . . . . . . . . . . . . . . . . 52 131 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 132 11.1. Registrations . . . . . . . . . . . . . . . . . . . . . 52 133 11.2. Expert Review: Evaluation Guidelines . . . . . . . . . . 53 134 11.3. Signal Type Registration . . . . . . . . . . . . . . . . 53 135 11.4. DLEP Data Item Registrations . . . . . . . . . . . . . . 54 136 11.5. DLEP Status Code Registrations . . . . . . . . . . . . . 55 137 11.6. DLEP Extensions Registrations . . . . . . . . . . . . . 55 138 11.7. DLEP Well-known Port . . . . . . . . . . . . . . . . . . 56 139 11.8. DLEP Multicast Address . . . . . . . . . . . . . . . . . 56 140 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56 141 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 142 13.1. Normative References . . . . . . . . . . . . . . . . . . 56 143 13.2. Informative References . . . . . . . . . . . . . . . . . 56 144 Appendix A. Peer Level Signal Flows . . . . . . . . . . . . . . 56 145 A.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 56 146 A.2. Session Initialization . . . . . . . . . . . . . . . . . 57 147 A.3. Session Initialization - Refused . . . . . . . . . . . . 58 148 A.4. Router Changes IP Addresses . . . . . . . . . . . . . . . 58 149 A.5. Modem Changes Session-wide Metrics . . . . . . . . . . . 58 150 A.6. Router Terminates Session . . . . . . . . . . . . . . . . 59 151 A.7. Modem Terminates Session . . . . . . . . . . . . . . . . 59 152 A.8. Session Heartbeats . . . . . . . . . . . . . . . . . . . 60 153 A.9. Router Detects a Heartbeat timeout . . . . . . . . . . . 61 154 A.10. Modem Detects a Heartbeat timeout . . . . . . . . . . . . 62 155 Appendix B. Destination Specific Signal Flows . . . . . . . . . 62 156 B.1. Common Destination Signaling . . . . . . . . . . . . . . 62 157 B.2. Multicast Destination Signaling . . . . . . . . . . . . . 63 158 B.3. Link Characteristics Request . . . . . . . . . . . . . . 63 159 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64 161 1. Introduction 163 There exist today a collection of modem devices that control links of 164 variable datarate and quality. Examples of these types of links 165 include line-of-sight (LOS) terrestrial radios, satellite terminals, 166 and cable/DSL modems. Fluctuations in speed and quality of these 167 links can occur due to configuration (in the case of cable/DSL 168 modems), or on a moment-to-moment basis, due to physical phenomena 169 like multipath interference, obstructions, rain fade, etc. It is 170 also quite possible that link quality and datarate varies with 171 respect to individual destinations on a link, and with the type of 172 traffic being sent. As an example, consider the case of an 802.11g 173 access point, serving 2 associated laptop computers. In this 174 environment, the answer to the question "What is the datarate on the 175 802.11g link?" is "It depends on which associated laptop we're 176 talking about, and on what kind of traffic is being sent." While the 177 first laptop, being physically close to the access point, may have a 178 datarate of 54Mbps for unicast traffic, the other laptop, being 179 relatively far away, or obstructed by some object, can simultaneously 180 have a datarate of only 32Mbps for unicast. However, for multicast 181 traffic sent from the access point, all traffic is sent at the base 182 transmission rate (which is configurable, but depending on the model 183 of the access point, is usually 24Mbps or less). 185 In addition to utilizing variable datarate links, mobile networks are 186 challenged by the notion that link connectivity will come and go over 187 time, without an effect on a router's interface state (Up or Down). 188 Effectively utilizing a relatively short-lived connection is 189 problematic in IP routed networks, as routing protocols tend to rely 190 on interface state and independent timers at OSI Layer 3 to maintain 191 network convergence (e.g., HELLO messages and/or recognition of DEAD 192 routing adjacencies). These dynamic connections can be better 193 utilized with an event-driven paradigm, where acquisition of a new 194 neighbor (or loss of an existing one) is signaled, as opposed to a 195 paradigm driven by timers and/or interface state. 197 Another complicating factor for mobile networks are the different 198 methods of physically connecting the modem devices to the router. 199 Modems can be deployed as an interface card in a router's chassis, or 200 as a standalone device connected to the router via Ethernet or serial 201 link. In the case of Ethernet or serial attachment, with existing 202 protocols and techniques, routing software cannot be aware of 203 convergence events occurring on the radio link (e.g., acquisition or 204 loss of a potential routing neighbor), nor can the router be aware of 205 the actual capacity of the link. This lack of awareness, along with 206 the variability in datarate, leads to a situation where finding the 207 (current) best route through the network to a given destination is 208 difficult to establish and properly maintain. This is especially 209 true of demand-based access schemes such as Demand Assigned Multiple 210 Access (DAMA) implementations used on some satellite systems. With a 211 DAMA-based system, additional datarate may be available, but will not 212 be used unless the network devices emit traffic at a rate higher than 213 the currently established rate. Increasing the traffic rate does not 214 guarantee additional datarate will be allocated; rather, it may 215 result in data loss and additional retransmissions on the link. 217 Addressing the challenges listed above, the authors have developed 218 the Dynamic Link Exchange Protocol, or DLEP. The DLEP protocol runs 219 between a router and its attached modem devices, allowing the modem 220 to communicate link characteristics as they change, and convergence 221 events (acquisition and loss of potential routing destinations). The 222 following diagrams are used to illustrate the scope of DLEP packets. 224 |-------Local Node-------| |-------Remote Node------| 225 | | | | 226 +--------+ +-------+ +-------+ +--------+ 227 | Router |=======| Modem |{~~~~~~~~}| Modem |=======| Router | 228 | | | Device| | Device| | | 229 +--------+ +-------+ +-------+ +--------+ 230 | | | Link | | | 231 |-DLEP--| | Protocol | |-DLEP--| 232 | | | (e.g. | | | 233 | | | 802.11) | | | 235 Figure 1: DLEP Network 237 In Figure 1, when the local modem detects the presence of a remote 238 node, it (the local modem) sends a signal to its router via the DLEP 239 protocol. Upon receipt of the signal, the local router may take 240 whatever action it deems appropriate, such as initiating discovery 241 protocols, and/or issuing HELLO messages to converge the network. On 242 a continuing, as-needed basis, the modem devices utilize DLEP to 243 report any characteristics of the link (datarate, latency, etc.) that 244 have changed. DLEP is independent of the link type and topology 245 supported by the modem. Note that the DLEP protocol is specified to 246 run only on the local link between router and modem. Some over the 247 air signaling may be necessary between the local and remote modem in 248 order to provide some parameters in DLEP signals between the local 249 modem and local router, but DLEP does not specify how such over the 250 air signaling is carried out. Over the air signaling is purely a 251 matter for the modem implementer. 253 Figure 2 shows how DLEP can support a configuration where routers are 254 connected with different link types. In this example, Modem A 255 implements a point-to-point link, and Modem B is connected via a 256 shared medium. In both cases, the DLEP protocol is used to report 257 the characteristics of the link (datarate, latency, etc.) to routers. 258 The modem is also able to use the DLEP session to notify the router 259 when the remote node is lost, shortening the time required to re- 260 converge the network. 262 +--------+ +--------+ 263 +----+ Modem A| | Modem A+---+ 264 | | Device | <===== // ======> | Device | | 265 | +--------+ P-2-P Link +--------+ | 266 +---+----+ +---+----+ 267 | Router | | Router | 268 | | | | 269 +---+----+ +---+----+ 270 | +--------+ +--------+ | 271 +-----+ Modem B| | Modem B| | 272 | Device | o o o o o o o o | Device +--+ 273 +--------+ o Shared o +--------+ 274 o Medium o 275 o o 276 o o 277 o o 278 o 279 +--------+ 280 | Modem B| 281 | Device | 282 +---+----+ 283 | 284 | 285 +---+----+ 286 | Router | 287 | | 288 +--------+ 290 Figure 2: DLEP Network with Multiple Modem Devices 292 1.1. Protocol Overview 294 DLEP defines a set of signals used by modems and their attached 295 routers. The signals are used to communicate events that occur on 296 the physical link(s) managed by the modem: for example, a remote node 297 entering or leaving the network, or that the link has changed. 298 Associated with these signals are a set of data items - information 299 that describes the remote node (e.g., address information), and/or 300 the characteristics of the link to the remote node. 302 The protocol is defined as a collection of type-length-value (TLV) 303 based formats, specifying the signals that are exchanged between a 304 router and a modem, and the data items associated with the signal. 305 This document specifies transport of DLEP signals and data items via 306 the TCP transport, with a UDP-based discovery mechanism. Other 307 transports for the protocol are possible, but are outside the scope 308 of this document. 310 DLEP uses a session-oriented paradigm between the modem device and 311 its associated router. If multiple modem devices are attached to a 312 router (as in Figure 2), or the modem supports multiple connections 313 (via multiple logical or physical interfaces), then separate DLEP 314 sessions exist for each modem or connection. This router/modem 315 session provides a carrier for information exchange concerning 316 'destinations' that are available via the modem device. A 317 'destination' can be either physical (as in the case of a specific 318 far-end router), or a logical destination (as in a Multicast group). 319 As such, all of the destination-level exchanges in DLEP can be 320 envisioned as building an information base concerning the remote 321 nodes, and the link characteristics to those nodes. 323 Multicast traffic destined for the variable-quality network (the 324 network accessed via the DLEP modem) is handled in IP networks by 325 deriving a Layer 2 MAC address based on the Layer 3 address. 326 Leveraging on this scheme, multicast traffic is supported in DLEP 327 simply by treating the derived MAC address as any other 'destination' 328 (albeit a logical one) in the network. To support these logical 329 destinations, one of the DLEP participants (typically, the router) 330 informs the other as to the existence of the logical destination. 331 The modem, once it is aware of the existence of this logical 332 destination, reports link characteristics just as it would for any 333 other destination in the network. The specific algorithms a modem 334 would use to derive metrics on multicast (or logical) destinations is 335 outside the scope of this specification, and is left to specific 336 implementations to decide. 338 1.2. Requirements 340 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 341 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 342 document are to be interpreted as described in BCP 14, RFC 2119 343 [RFC2119]. 345 2. Assumptions 347 Routers and modems that exist as part of the same node (e.g., that 348 are locally connected) can utilize a discovery technique to locate 349 each other, thus avoiding a-priori configuration. The router is 350 responsible for initializing the discovery process, using the Peer 351 Discovery signal (Section 7.1). 353 DLEP utilizes a session-oriented paradigm. A router and modem form a 354 session by completing the discovery and initialization process. This 355 router-modem session persists unless or until it either (1) times 356 out, based on the timeout values supplied, or (2) is explicitly torn 357 down by one of the participants. Note that while use of timers in 358 DLEP is optional, it is strongly recommended that implementations 359 choose to run with timers enabled. 361 DLEP assumes that the MAC address for delivering data traffic is the 362 MAC specified in the Destination Up signal (Section 7.9). No 363 manipulation or substitution is performed; the MAC address supplied 364 in Destination Up is used as the OSI Layer 2 Destination MAC address. 365 DLEP also assumes that MAC addresses MUST be unique within the 366 context of a router-modem session. Additionally, DLEP can support 367 MAC addresses in either EUI-48 or EUI-64 format, with the restriction 368 that ALL MAC addresses for a given DLEP session MUST be in the same 369 format, and MUST be consistent with the MAC address format of the 370 connected modem (e.g., if the modem is connected to the router with 371 an EUI-48 MAC, all destination addresses via that modem MUST be 372 expressed in EUI-48 format). 374 DLEP utilizes UDP multicast for single-hop discovery, and TCP for 375 transport of the control signals. Therefore, DLEP assumes that the 376 modem and router have topologically consistent IP addresses assigned. 377 It is recommended that DLEP implementations utilize IPv6 link-local 378 addresses to reduce the administrative burden of address assignment. 380 Destinations can be identified by either the router or the modem, and 381 represent a specific destination (e.g., an address) that exists on 382 the link(s) managed by the modem. A destination MUST contain a MAC 383 address, it MAY optionally include a Layer 3 address (or addresses). 384 Note that since a destination is a MAC address, the MAC could 385 reference a logical destination, as in a derived multicast MAC 386 address, as well as a physical device. As destinations are 387 discovered, DLEP routers and modems build an information base on 388 destinations accessible via the modem. 390 The DLEP signals concerning destinations thus become the way for 391 routers and modems to maintain, and notify each other about, an 392 information base representing the physical and logical (e.g., 393 multicast) destinations accessible via the modem device. The 394 information base would contain addressing information (i.e. MAC 395 address, and OPTIONALLY, Layer 3 addresses), link characteristics 396 (metrics), and OPTIONALLY, flow control information (credits). 398 DLEP assumes that any signal not understood by a receiver MUST result 399 in an error indication being sent to the originator, and also MUST 400 result in termination of the session between the DLEP peers. Any 401 DLEP data item not understood by a receiver MUST also result in 402 termination of the session. 404 DLEP assumes that security on the session (e.g., authentication of 405 session partners, encryption of traffic, or both) is dealt with by 406 the underlying transport mechanism (e.g., by using a transport such 407 as TLS [RFC5246]). 409 This document specifies an implementation of the DLEP signals and 410 data items running over the TCP transport. It is assumed that DLEP 411 running over other transport mechanisms would be documented 412 separately. 414 3. Core Features and Optional Extensions 416 DLEP has a core set of signals and data items that MUST be processed 417 without error by an implementation in order to guarantee 418 interoperability and therefore make the implementation DLEP 419 compliant. This document defines the core set of signals and data 420 items, listing them as 'mandatory'. It should be noted that some 421 core signals and data items might not be used during the lifetime of 422 a single DLEP session, but a compliant implementation MUST support 423 them. 425 While this document represents the best efforts of the co-authors, 426 and the working group, to be functionally complete, it is recognized 427 that extensions to DLEP will in all likelihood be necessary as more 428 link types are utilized. To support future extension of DLEP, this 429 document describes an extension negotiation capability to be used 430 during session initialization via the Extensions Supported data item, 431 documented in Section 8.7 of this document. 433 All extensions are considered OPTIONAL. Only the DLEP functionality 434 listed as 'mandatory' is required by implementation in order to be 435 DLEP compliant. 437 This specification defines one extension, Credit windowing, exposed 438 via the Extensions Supported mechanism that implementations MAY 439 choose to implement, or to omit. 441 3.1. Negotiation of Optional Extensions 443 Optional extensions supported by an implementation MUST be declared 444 to potential DLEP peers using the Extensions Supported data item 445 (Section 8.7) during the session initialization sequence. Once both 446 peers have exchanged initialization signals, an implementation MUST 447 NOT emit any signal or data item associated with an optional 448 extension that was not specified in the received initialization 449 signal from its peer. 451 3.2. Protocol Extensions 453 If/when protocol extensions are required, they should be standardized 454 either as an update to this document, or as an additional stand-alone 455 specification. The requests for IANA-controlled registries in this 456 document contain sufficient reserved space, both in terms of DLEP 457 signals and DLEP data items, to accommodate future extensions to the 458 protocol and the data transferred. 460 3.3. Experimental Signals and Data Items 462 This document requests numbering space in both the DLEP signal and 463 data item registries for experimental items. The intent is to allow 464 for experimentation with either (1) new signals, (2) new data items, 465 or (3) both new signals and new data items, while still retaining the 466 documented DLEP behavior. If a given experiment proves successful, 467 it SHOULD be documented as an update to this document, or as a stand- 468 alone specification. 470 Use of the experimental signals, data items, or behaviors MUST be 471 announced by inclusion of an Experimental Definition data item 472 (Section 8.8) with a value agreed upon (a-priori) between the 473 participating peers. The exact mechanism for a-priori communication 474 of the experimental definition formats is beyond the scope of this 475 document. 477 Multiple Experimental Definition data items MAY appear in the Peer 478 Initialization/Peer Initialization ACK sequence. However, use of 479 multiple experiments in a single peer session could lead to 480 interoperability issues or unexpected results (e.g., redefinition of 481 experimental signals and/or data items), and is therefore 482 discouraged. It is left to implementations to determine the correct 483 processing path (e.g., a decision on whether to terminate the peer 484 session, or to establish a precedence of the conflicting definitions) 485 if such conflicts arise. 487 4. Metrics 489 DLEP includes the ability for the router and modem to communicate 490 metrics that reflect the characteristics (e.g., datarate, latency) of 491 the variable-quality link in use. DLEP does NOT specify how a given 492 metric value is to be calculated, rather, the protocol assumes that 493 metrics have been calculated with a 'best effort', incorporating all 494 pertinent data that is available to the modem device. 496 As mentioned in the introduction section of this document, DLEP 497 allows for metrics to be sent within two contexts - metrics for a 498 specific destination within the network (e.g., a specific router), 499 and 'modem-wide' (those that apply to all destinations accessed via 500 the modem). Most metrics can be further subdivided into transmit and 501 receive metrics. Metrics supplied on DLEP Peer signals are, by 502 definition, modem-wide; metrics supplied on Destination signals are, 503 by definition, used for the specific logical destination only. 505 DLEP modem implementations MUST announce all supported metric items, 506 and provide default values for those metrics, in the Peer 507 Initialization ACK signal (Section 7.4). In order to introduce a new 508 metric type, DLEP modem implementations MUST terminate the session 509 with the router (via the Peer Terminate signal (Section 7.7)), and 510 re-establish the session. 512 It is left to implementations to choose sensible default values based 513 on their specific characteristics. Modems having static (non- 514 changing) link metric characteristics MAY report metrics only once 515 for a given destination (or once on a modem-wide basis, if all 516 connections via the modem are of this static nature). 518 The approach of allowing for different contexts for metric data 519 increases both the flexibility and the complexity of using metric 520 data. This document details the mechanism whereby the data is 521 transmitted, however, the specific algorithms (precedence, etc.) for 522 utilizing the dual-context metrics is out of scope and not addressed 523 by this document. 525 4.1. Mandatory Metrics 527 As mentioned above, DLEP modem implementations MUST announce all 528 supported metric items during session initialization. However, an 529 implementation MUST include the following list of metrics: 531 o Maximum Data Rate (Receive) (Section 8.14) 533 o Maximum Data Rate (Transmit) (Section 8.15) 535 o Current Data Rate (Receive) (Section 8.16) 537 o Current Data Rate (Transmit) (Section 8.17) 539 o Latency (Section 8.18) 541 5. DLEP Session Flow 543 For routers supporting DLEP, support of Discovery is optional. 544 Therefore, normal session flow is described for both the 'Discovery 545 case', and the 'Configured case'. For modem implementations of DLEP, 546 support of Discovery is mandatory; therefore, that is the only case 547 to be described. 549 5.1. DLEP Router session flow - Discovery case 551 If the DLEP router implementation is utilizing the optional discovery 552 mechanism, then the implementation will initialize a UDP socket, 553 binding it to an arbitrary port. This UDP socket is used to send the 554 Peer Discovery signal (Section 7.1) to the DLEP link-local multicast 555 address and port (TBD). The implementation then waits on receipt of 556 a Peer Offer signal (Section 7.2), which MAY contain the unicast 557 address and port for TCP-based communication with a DLEP modem, via 558 the IPv4 Connection Point data item (Section 8.3) or the IPv6 559 Connection Point data item (Section 8.4). The Peer Offer signal MAY 560 contain multiple IP Connection Point data items. If more than one IP 561 Connection Point data items is in the Peer Offer, router 562 implementations MAY use their own heuristics to determine the best 563 address/port combination. If no IP Connection Point data items are 564 included in the Peer Offer signal, the receiver MUST use the origin 565 address of the signal as the IP address, and the DLEP well-known port 566 number (Section 11.7) to establish the TCP connection. At this 567 point, the router implementation MAY either destroy the UDP socket, 568 or continue to issue Peer Discovery signals to the link-local 569 address/port combination. In either case, the TCP session 570 initialization occurs as in the configured case. 572 5.2. DLEP Router session flow - Configured case 574 When a DLEP router implementation has the address and port 575 information for a TCP connection to a modem (obtained either via 576 configuration or via the discovery process described above), the 577 router will initialize and bind a TCP socket. This socket is used to 578 connect to the DLEP modem software. After a successful TCP connect, 579 the router implementation MUST issue a Peer Initialization signal 580 (Section 7.3) to the DLEP modem. After sending the Peer 581 Initialization, the router implementation MUST wait for receipt of a 582 Peer Initialization ACK signal (Section 7.4) from the modem. Receipt 583 of the Peer Initialization ACK signal containing a Status data item 584 (Section 8.2) with value 'Success', indicates that the modem has 585 received and processed the Peer Initialization, and the session MUST 586 transition to the 'in session' state. At this point, signals 587 regarding destinations in the network, and/or Peer Update signals 588 (Section 7.5), can flow on the DLEP session between modem and router, 589 and Heartbeat signals can begin to flow, if Heartbeats are used. The 590 'in session' state is maintained until one of the following 591 conditions occur: 593 o The session is explicitly terminated (using Peer Termination), or 594 o The session times out, based on supplied timeout values. 596 5.3. DLEP Modem session flow 598 DLEP modem implementations MUST support the discovery mechanism. 599 Therefore, the normal flow is as follows: 601 The implementation will initialize a UDP socket, binding that socket 602 to the DLEP link-local multicast address (TBD) and the DLEP well- 603 known port number (also TBD). The implementation will then 604 initialize a TCP socket, on a unicast address and port. This socket 605 is used to listen for incoming TCP connection requests. 607 When the modem implementation receives a Peer Discovery signal 608 (Section 7.1) on the UDP socket, it responds by issuing a Peer Offer 609 signal (Section 7.2) to the sender of the Peer Discovery signal. The 610 Peer Offer signal MAY contain the unicast address and port of the 611 listening TCP socket, as described above. A DLEP modem 612 implementation MAY respond with ALL address/port combinations that 613 have an active TCP listen posted. Anything other than Peer Discovery 614 signals received on the UDP socket MUST be silently dropped. 616 When the DLEP modem implementation accepts a connection via TCP, it 617 MUST wait for receipt of a Peer Initialization signal (Section 7.3), 618 sent by the router. Upon receipt and successful parsing of a Peer 619 Initialization signal, the modem MUST respond with a Peer 620 Initialization ACK signal (Section 7.4). The Peer Initialization ACK 621 signal MUST contain metric data items for ALL supported metrics. If 622 an additional metric is to be introduced, the DLEP session between 623 router and modem MUST be terminated and restarted, and the new metric 624 described in a Peer Initialization ACK signal. Once the Peer 625 Initialization signal (Section 7.3) and Peer Initialization ACK 626 signal (Section 7.4) have been exchanged, the session is transitioned 627 to the 'in session' state. As in the router case, when the 'in 628 session' state is reached, signals regarding destinations in the 629 network, and/or Peer Update signals (Section 7.5), can flow on the 630 DLEP session between modem and router, and Heartbeat signals can 631 begin to flow, if Heartbeats are used. The 'in session' state 632 persists until the session is explicitly terminated (using Peer 633 Termination), or it times out (based on timeout values). 635 5.4. Common Session Flow 637 In order to maintain the session between router and modem, periodic 638 Heartbeat signals (Section 7.14) MAY be exchanged. These signals are 639 intended to keep the session alive, and to verify bidirectional 640 connectivity between the two participants. If heartbeat signals are 641 exchanged, they do not begin until the DLEP peer session has entered 642 the 'in session' state. Each DLEP peer is responsible for the 643 creation of heartbeat signals. Receipt of any DLEP signal SHOULD 644 reset the heartbeat interval timer (e.g., valid DLEP signals take the 645 place of, and obviate the need for, Heartbeat signals). 647 DLEP also provides a Peer Update signal (Section 7.5), intended to 648 communicate some change in status (e.g., a change of layer 3 address 649 parameters, or a modem-wide link change). 651 In addition to the local (Peer level) signals above, the participants 652 will transmit DLEP signals concerning destinations in the network. 653 These signals trigger creation/maintenance/deletion of destinations 654 in the information base of the recipient. For example, a modem will 655 inform its attached router of the presence of a new destination via 656 the Destination Up signal (Section 7.9). Receipt of a Destination Up 657 causes the router to allocate the necessary resources, creating an 658 entry in the information base with the specifics (i.e. MAC Address, 659 Latency, Data Rate, etc.) of the destination. The loss of a 660 destination is communicated via the Destination Down signal 661 (Section 7.11), and changes in status to the destination (e.g., 662 varying link quality, or addressing changes) are communicated via the 663 Destination Update signal (Section 7.13). The information on a given 664 destination will persist in the router's information base until (1) a 665 Destination Down signal is received, indicating that the modem has 666 lost contact with the remote node, or (2) the router/modem session 667 terminates, indicating that the router has lost contact with its own 668 local modem. 670 Metrics can be expressed within the context of a specific destination 671 via the Destination Update signal, or on a modem-wide basis via the 672 Peer Update signal. In cases where metrics are provided at peer 673 level, the receiver MUST propagate the metrics to all destinations in 674 its information base that are accessed via the originator. A DLEP 675 participant MAY send metrics both in a router/modem session context 676 (via the Peer Update signal) and a specific destination context (via 677 Destination Update) at any time. The heuristics for applying 678 received metrics is left to implementations. 680 In addition to receiving metrics about the link, DLEP provides a 681 signal allowing a router to request a different datarate, or latency, 682 from the modem. This signal is referred to as the Link 683 Characteristics Request signal (Section 7.15), and gives the router 684 the ability to deal with requisite increases (or decreases) of 685 allocated datarate/latency in demand-based schemes in a more 686 deterministic manner. 688 6. DLEP Message Processing 690 Communication between DLEP peers consists of a bidirectional stream 691 of signals, each signal consisting of a signal header and an 692 unordered list of data items. Both signal headers and data items are 693 encoded as TLV (Type-Length-Value) structures. In this document, the 694 data items following the signal header are described as being 695 'contained in' the signal. 697 All integer values in all TLV structures MUST be in network byte- 698 order. 700 There is no restriction on the order of data items following a 701 signal, and the multiplicity of duplicate data items is defined by 702 the definition of the signal declared by the type in the signal 703 header. 705 If an unrecognized, or unexpected signal is received, or a received 706 signal contains unrecognized, invalid or disallowed duplicate data 707 items, the receiving peer MUST terminate the session by issuing a 708 Peer Termination signal (Section 7.7) with a Status data item 709 (Section 8.2) containing the most relevant status code, and then 710 close the TCP connection. 712 6.1. DLEP Signal Header 714 The DLEP signal header contains the following fields: 716 0 1 2 717 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Signal Type | Length | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 Figure 3: DLEP Signal Header 724 Signal Type: One of the DLEP Signal Type values defined in this 725 document. 727 Length: The length, expressed as a 16-bit unsigned integer, of all 728 of the DLEP data items associated with this signal. This length 729 does not include the length of the header itself 731 The DLEP Signal Header is immediately followed by one or more DLEP 732 data items, encoded in TLVs, as defined in this document. 734 6.2. DLEP Generic Data Item 736 All DLEP data items contain the following fields: 738 0 1 2 3 739 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 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | Data Item Type| Length | Value... | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 Figure 4: DLEP Generic Data Item 746 Data Item Type: An 8-bit unsigned integer field specifying the data 747 item being sent. 749 Length: The length, expressed as an 8-bit unsigned integer, of the 750 value field of the data item. 752 Value: A field of length which contains data specific to a 753 particular data item. 755 7. DLEP Signals 757 As mentioned above, all DLEP signals begin with the DLEP signal 758 header structure. Therefore, in the following descriptions of 759 specific signals, this header structure is assumed, and will not be 760 replicated. 762 Following is the set of MANDATORY signals that must be recognized by 763 a DLEP compliant implementation. As mentioned before, not all 764 signals may be used during a session, but an implementation MUST 765 correctly process these signals when received. 767 The mandatory DLEP signals are: 769 +---------+-------------------------------+---------------+ 770 | Signal | Description | Section | 771 +---------+-------------------------------+---------------+ 772 | TBD | Peer Discovery | Section 7.1 | 773 | TBD | Peer Offer | Section 7.2 | 774 | TBD | Peer Initialization | Section 7.3 | 775 | TBD | Peer Initialization ACK | Section 7.4 | 776 | TBD | Peer Update | Section 7.5 | 777 | TBD | Peer Update ACK | Section 7.6 | 778 | TBD | Peer Termination | Section 7.7 | 779 | TBD | Peer Termination ACK | Section 7.8 | 780 | TBD | Destination Up | Section 7.9 | 781 | TBD | Destination Up ACK | Section 7.10 | 782 | TBD | Destination Down | Section 7.11 | 783 | TBD | Destination Down ACK | Section 7.12 | 784 | TBD | Destination Update | Section 7.13 | 785 | TBD | Heartbeat | Section 7.14 | 786 | TBD | Link Characteristics Request | Section 7.15 | 787 | TBD | Link Characteristics ACK | Section 7.16 | 788 +---------+-------------------------------+---------------+ 790 7.1. Peer Discovery Signal 792 A Peer Discovery signal SHOULD be sent by a router to discover DLEP 793 modems in the network. The Peer Offer signal (Section 7.2) is 794 required to complete the discovery process. Implementations MAY 795 implement their own retry heuristics in cases where it is determined 796 the Peer Discovery signal has timed out. 798 To construct a Peer Discovery signal, the Signal Type value in the 799 signal header is set to DLEP_PEER_DISCOVERY (value TBD). 801 The Peer Discovery signal MUST contain the following data item: 803 o DLEP Version (Section 8.1) 805 The Peer Discovery signal MAY contain the following data item: 807 o Peer Type (Section 8.5) 809 7.2. Peer Offer Signal 811 A Peer Offer signal MUST be sent by a DLEP modem in response to a 812 valid Peer Discovery signal (Section 7.1). 814 The Peer Offer signal MUST be sent to the unicast address of the 815 originator of the Peer Discovery signal. 817 To construct a Peer Offer signal, the Signal Type value in the signal 818 header is set to DLEP_PEER_OFFER (value TBD). 820 The Peer Offer signal MUST contain the following data item: 822 o DLEP Version (Section 8.1) 824 The Peer Offer signal MAY contain the following data item: 826 o Peer Type (Section 8.5) 828 The Peer Offer signal MAY contain one or more of any of the following 829 data items, with different values: 831 o IPv4 Connection Point (Section 8.3) 833 o IPv6 Connection Point (Section 8.4) 835 The IP Connection Point data items indicate the unicast address the 836 receiver of Peer Offer MUST use when connecting the DLEP TCP session. 837 If multiple IP Connection Point data items are present in the Peer 838 Offer signal, implementations MAY use their own heuristics to select 839 the address to connect to. If no IP Connection Point data items are 840 included in the Peer Offer signal, the receiver MUST use the origin 841 address of the signal as the IP address, and the DLEP well-known port 842 number (Section 11.7) to establish the TCP connection. 844 7.3. Peer Initialization Signal 846 A Peer Initialization signal MUST be sent by a router as the first 847 signal of the DLEP TCP session. It is sent by the router after a TCP 848 connect to an address/port combination that was obtained either via 849 receipt of a Peer Offer, or from a-priori configuration. 851 If any optional extensions are supported by the implementation, they 852 MUST be enumerated in the Extensions Supported data item. If an 853 Extensions Supported data item does NOT exist in a Peer 854 Initialization signal, the receiver of the signal MUST conclude that 855 there is NO support for extensions in the sender. 857 If any experimental signals or data items are used by the 858 implementation, they MUST be enumerated in one or more Experimental 859 Definition data items. If there are no Experimental Definition data 860 items in a Peer Initialization signal, the receiver of the signal 861 MUST conclude that NO experimental definitions are in use by the 862 sender. 864 Implementations supporting the Heartbeat Interval (Section 8.6) 865 should understand that heartbeats are NOT fully established until 866 receipt of Peer Initialization ACK Signal (Section 7.4), and should 867 therefore implement their own timeout and retry heurestics for this 868 signal. 870 To construct a Peer Initialization signal, the Signal Type value in 871 the signal header is set to DLEP_PEER_INITIALIZATION (value TBD). 873 The Peer Initialization signal MUST contain one of each of the 874 following data items: 876 o DLEP Version (Section 8.1) 878 o Heartbeat Interval (Section 8.6) 880 The Peer Initialization signal MAY contain one of each of the 881 following data items: 883 o Peer Type (Section 8.5) 885 o Extensions Supported (Section 8.7) 887 The Peer Initialization signal MAY contain one or more of any of the 888 following data items, with different values: 890 o Experimental Definition (Section 8.8) 892 A Peer Initialization signal MUST be acknowledged by the receiver 893 issuing a Peer Initialization ACK signal (Section 7.4). 895 7.4. Peer Initialization ACK Signal 897 A Peer Initialization ACK signal MUST be sent in response to a 898 received Peer Initialization signal (Section 7.3). The Peer 899 Initialization ACK signal completes the DLEP session establishment; 900 the sender of the signal should transition to an 'in-session' state 901 when the signal is sent, and the receiver should transition to the 902 'in-session' state upon receipt (and successful parsing) of an 903 acceptable Peer Initialization ACK signal. 905 All supported metric data items MUST be included in the Peer 906 Initialization ACK signal, with default values to be used on a 907 'modem-wide' basis. This can be viewed as the modem 'declaring' all 908 supported metrics at DLEP session initialization. Receipt of any 909 DLEP signal containing a metric data item NOT included in the Peer 910 Initialization ACK signal MUST be treated as an error, resulting in 911 the termination of the DLEP session between router and modem. 913 If any optional extensions are supported by the modem, they MUST be 914 enumerated in the Extensions Supported data item. If an Extensions 915 Supported data item does NOT exist in a Peer Initialization ACK 916 signal, the receiver of the signal MUST conclude that there is NO 917 support for extensions in the sender. 919 If any experimental signals or data items are used by the 920 implementation, they MUST be enumerated in one or more Experimental 921 Definition data items. If there are no Experimental Definition data 922 items in a Peer Initialization ACK signal, the receiver of the signal 923 MUST conclude that NO experimental definitions are in use by the 924 sender. 926 After the Peer Initialization/Peer Initialization ACK signals have 927 been successfully exchanged, implementations MUST only utilize 928 extensions and experimental definitions that are supported by BOTH 929 peers. 931 To construct a Peer Initialization ACK signal, the Signal Type value 932 in the signal header is set to DLEP_PEER_INIT_ACK (value TBD). 934 The Peer Initialization ACK signal MUST contain one of each of the 935 following data items: 937 o DLEP Version (Section 8.1) 939 o Heartbeat Interval (Section 8.6) 941 o Maximum Data Rate (Receive) (Section 8.14) 943 o Maximum Data Rate (Transmit) (Section 8.15) 945 o Current Data Rate (Receive) (Section 8.16) 947 o Current Data Rate (Transmit) (Section 8.17) 949 o Latency (Section 8.18) 951 The Peer Initialization ACK signal MUST contain one of each of the 952 following data items, if the data item will be used during the 953 lifetime of the session: 955 o Resources (Receive) (Section 8.19) 957 o Resources (Transmit) (Section 8.20) 959 o Relative Link Quality (Receive) (Section 8.21) 960 o Relative Link Quality (Transmit) (Section 8.22) 962 The Peer Initialization ACK signal MAY contain one of each of the 963 following data items: 965 o Status (Section 8.2) 967 o Peer Type (Section 8.5) 969 o Extensions Supported (Section 8.7) 971 The Peer Initialization ACK signal MAY contain one or more of any of 972 the following data items, with different values: 974 o Experimental Definition (Section 8.8) 976 7.5. Peer Update Signal 978 A Peer Update signal MAY be sent by a DLEP peer to indicate local 979 Layer 3 address changes, or metric changes on a modem-wide basis. 980 For example, addition of an IPv4 address to the router MAY prompt a 981 Peer Update signal to its attached DLEP modems. Also, for example, a 982 modem that changes its Maximum Data Rate (Receive) for all 983 destinations MAY reflect that change via a Peer Update signal to its 984 attached router(s). 986 Concerning Layer 3 addresses, if the modem is capable of 987 understanding and forwarding this information (via proprietary 988 mechanisms), the address update would prompt any remote DLEP modems 989 (DLEP-enabled modems in a remote node) to issue a Destination Update 990 signal (Section 7.13) to their local routers with the new (or 991 deleted) addresses. Modems that do not track Layer 3 addresses 992 SHOULD silently parse and ignore the Peer Update signal. Modems that 993 track Layer 3 addresses MUST acknowledge the Peer Update with a Peer 994 Update ACK signal (Section 7.6). 996 If metrics are supplied with the Peer Update signal (e.g., Maximum 997 Data Rate), these metrics are considered to be modem-wide, and 998 therefore MUST be applied to all destinations in the information base 999 associated with the router/modem session. 1001 Supporting implementations are free to employ heuristics to 1002 retransmit Peer Update signals. The sending of Peer Update signals 1003 for Layer 3 address changes SHOULD cease when either participant 1004 (router or modem) determines that the other implementation does NOT 1005 support Layer 3 address tracking. 1007 To construct a Peer Update signal, the Signal Type value in the 1008 signal header is set to DLEP_PEER_UPDATE (value TBD). 1010 The Peer Update signal MAY contain one of each of the following data 1011 items: 1013 o Maximum Data Rate (Receive) (Section 8.14) 1015 o Maximum Data Rate (Transmit) (Section 8.15) 1017 o Current Data Rate (Receive) (Section 8.16) 1019 o Current Data Rate (Transmit) (Section 8.17) 1021 o Latency (Section 8.18) 1023 o Resources (Receive) (Section 8.19) 1025 o Resources (Transmit) (Section 8.20) 1027 o Relative Link Quality (Receive) (Section 8.21) 1029 o Relative Link Quality (Transmit) (Section 8.22) 1031 The Peer Update signal MAY contain one or more of the following data 1032 items, with different values: 1034 o IPv4 Address (Section 8.10) 1036 o IPv6 Address (Section 8.11) 1038 A Peer Update signal MUST be acknowledged by the receiver issuing a 1039 Peer Update ACK signal (Section 7.6). 1041 7.6. Peer Update ACK Signal 1043 A Peer Update ACK signal MUST be sent by implementations to indicate 1044 whether a Peer Update signal (Section 7.5) was successfully received. 1046 To construct a Peer Update ACK signal, the Signal Type value in the 1047 signal header is set to DLEP_PEER_UPDATE_ACK (value TBD). 1049 The Peer Update ACK signal MAY contain one of each of the following 1050 data items: 1052 o Status (Section 8.2) 1053 A receiver of a Peer Update ACK signal without a Status data item 1054 MUST behave as if a Status data item with code 'Success' had been 1055 received. 1057 7.7. Peer Termination Signal 1059 A Peer Termination signal MUST be sent by a DLEP participant when the 1060 router/modem session needs to be terminated. Implementations 1061 receiving a Peer Termination signal MUST send a Peer Termination ACK 1062 signal (Section 7.8) to confirm the termination process. 1064 The receiver of a Peer Termination signal MUST release all resources 1065 allocated for the router/modem session, and MUST eliminate all 1066 destinations in the information base accessible via the router/modem 1067 pair represented by the session. Router and modem state machines are 1068 returned to the 'discovery' state. No Destination Down signals 1069 (Section 7.11) are sent. 1071 The sender of a Peer Termination signal is free to define its 1072 heuristics in event of a timeout. It may resend the Peer Termination 1073 or free resources and return to the 'discovery' state. 1075 To construct a Peer Termination signal, the Signal Type value in the 1076 signal header is set to DLEP_PEER_TERMINATION (value TBD). 1078 The Peer Termination signal MAY contain one of each of the following 1079 data items: 1081 o Status (Section 8.2) 1083 A receiver of a Peer Termination signal without a Status data item 1084 MUST behave as if a Status data item with status code 'Success', 1085 implying graceful termination, had been received. 1087 A Peer Termination signal MUST be acknowledged by the receiver 1088 issuing a Peer Termination ACK signal (Section 7.8). 1090 7.8. Peer Termination ACK Signal 1092 A Peer Termination ACK signal MUST be sent by a DLEP peer in response 1093 to a received Peer Termination signal (Section 7.7). Receipt of a 1094 Peer Termination ACK signal completes the teardown of the router/ 1095 modem session. 1097 To construct a Peer Termination ACK signal, the Signal Type value in 1098 the signal header is set to DLEP_PEER_TERMINATION_ACK (value TBD). 1100 The Peer Termination ACK signal MAY contain one of each of the 1101 following data items: 1103 o Status (Section 8.2) 1105 A receiver of a Peer Termination ACK signal without a Status data 1106 item MUST behave as if a Status data item with status code 'Success', 1107 implying graceful termination, had been received. 1109 7.9. Destination Up Signal 1111 A Destination Up signal can be sent either by the modem, to indicate 1112 that a new remote node has been detected, or by the router, to 1113 indicate the presence of a new logical destination (e.g., a Multicast 1114 group) in the network. 1116 A Destination Up signal MUST be acknowledged by the receiver issuing 1117 a Destination Up ACK signal (Section 7.10). The sender of the 1118 Destination Up signal is free to define its retry heuristics in event 1119 of a timeout. When a Destination Up signal is received and 1120 successfully processed, the receiver should add knowledge of the new 1121 destination to its information base, indicating that the destination 1122 is accessible via the modem/router pair. 1124 To construct a Destination Up signal, the Signal Type value in the 1125 signal header is set to DLEP_DESTINATION_UP (value TBD). 1127 The Destination Up signal MUST contain one of each of the following 1128 data items: 1130 o MAC Address (Section 8.9) 1132 The Destination Up signal MAY contain one of each of the following 1133 data items: 1135 o Maximum Data Rate (Receive) (Section 8.14) 1137 o Maximum Data Rate (Transmit) (Section 8.15) 1139 o Current Data Rate (Receive) (Section 8.16) 1141 o Current Data Rate (Transmit) (Section 8.17) 1143 o Latency (Section 8.18) 1145 o Resources (Receive) (Section 8.19) 1147 o Resources (Transmit) (Section 8.20) 1148 o Relative Link Quality (Receive) (Section 8.21) 1150 o Relative Link Quality (Transmit) (Section 8.22) 1152 The Destination Up signal MAY contain one or more of the following 1153 data items, with different values: 1155 o IPv4 Address (Section 8.10) 1157 o IPv6 Address (Section 8.11) 1159 o IPv4 Attached Subnet (Section 8.12) 1161 o IPv6 Attached Subnet (Section 8.13) 1163 If the sender has IPv4 and/or IPv6 address information for a 1164 destination it SHOULD include the relevant data items in the 1165 Destination Up signal, reducing the need for the receiver to probe 1166 for any address. 1168 7.10. Destination Up ACK Signal 1170 A DLEP participant MUST send a Destination Up ACK signal to indicate 1171 whether a Destination Up signal (Section 7.9) was successfully 1172 processed. 1174 To construct a Destination Up ACK signal, the Signal Type value in 1175 the signal header is set to DLEP_DESTINATION_UP_ACK (value TBD). 1177 The Destination Up ACK signal MUST contain one of each of the 1178 following data items: 1180 o MAC Address (Section 8.9) 1182 The Destination Up ACK signal MAY contain one of each of the 1183 following data items: 1185 o Status (Section 8.2) 1187 A receiver of a Destination Up ACK signal without a Status data item 1188 MUST behave as if a Status data item with status code 'Success' had 1189 been received. Implementations are free to define retry heurestics 1190 when receiving a Destination Up ACK signal indicating an error. 1192 7.11. Destination Down Signal 1194 A DLEP peer MUST send a Destination Down signal to report when a 1195 destination (a remote node or a multicast group) is no longer 1196 reachable. A Destination Down ACK signal (Section 7.12) MUST be sent 1197 by the recipient of a Destination Down signal to confirm that the 1198 relevant data has been removed from the information base. The sender 1199 of the Destination Down signal is free to define its retry heuristics 1200 in event of a timeout. 1202 To construct a Destination Down signal, the Signal Type value in the 1203 signal header is set to DLEP_DESTINATION_DOWN (value TBD). 1205 The Destination Down signal MUST contain one of each of the following 1206 data items: 1208 o MAC Address (Section 8.9) 1210 7.12. Destination Down ACK Signal 1212 A DLEP participant MUST send a Destination Down ACK signal to 1213 indicate whether a received Destination Down signal (Section 7.11) 1214 was successfully processed. If successfully processed, the sender of 1215 the ACK MUST have removed all entries in the information base that 1216 pertain to the referenced destination. 1218 To construct a Destination Down ACK signal, the Signal Type value in 1219 the signal header is set to DLEP_DESTINATION_DOWN_ACK (value TBD). 1221 The Destination Down ACK signal MUST contain one of each of the 1222 following data items: 1224 o MAC Address (Section 8.9) 1226 The Destination Down ACK signal MAY contain one of each of the 1227 following data items: 1229 o Status (Section 8.2) 1231 A receiver of a Destination Down ACK signal without a Status data 1232 item MUST behave as if a Status data item with status code 'Success' 1233 had been received. Implementations are free to define retry 1234 heurestics when receiving a Destination Down ACK signal indicating an 1235 error. 1237 7.13. Destination Update Signal 1239 A DLEP participant SHOULD send the Destination Update signal when it 1240 detects some change in the information base for a given destination 1241 (remote node or multicast group). Some examples of changes that 1242 would prompt a Destination Update signal are: 1244 o Change in link metrics (e.g., Data Rates) 1246 o Layer 3 addressing change 1248 To construct a Destination Update signal, the Signal Type value in 1249 the signal header is set to DLEP_DESTINATION_UPDATE (value TBD). 1251 The Destination Update signal MUST contain one of each of the 1252 following data items: 1254 o MAC Address (Section 8.9) 1256 The Destination Update signal MAY contain one of each of the 1257 following data items: 1259 o Maximum Data Rate (Receive) (Section 8.14) 1261 o Maximum Data Rate (Transmit) (Section 8.15) 1263 o Current Data Rate (Receive) (Section 8.16) 1265 o Current Data Rate (Transmit) (Section 8.17) 1267 o Latency (Section 8.18) 1269 o Resources (Receive) (Section 8.19) 1271 o Resources (Transmit) (Section 8.20) 1273 o Relative Link Quality (Receive) (Section 8.21) 1275 o Relative Link Quality (Transmit) (Section 8.22) 1277 The Destination Update signal MAY contain one or more of the 1278 following data items, with different values: 1280 o IPv4 Address (Section 8.10) 1282 o IPv6 Address (Section 8.11) 1284 o IPv4 Attached Subnet (Section 8.12) 1285 o IPv6 Attached Subnet (Section 8.13) 1287 7.14. Heartbeat Signal 1289 A Heartbeat signal SHOULD be sent by a DLEP participant every N 1290 seconds, where N is defined in the Heartbeat Interval data item of 1291 the Peer Initialization signal (Section 7.3) or Peer Initialization 1292 ACK signal (Section 7.4). Note that implementations setting the 1293 Heartbeat Interval to 0 effectively set the interval to an infinite 1294 value, therefore, in those cases, this signal SHOULD NOT be sent. 1296 The signal is used by participants to detect when a DLEP session 1297 partner (either the modem or the router) is no longer communicating. 1298 Participants SHOULD allow two (2) heartbeat intervals to expire with 1299 no traffic on the router/modem session before initiating DLEP session 1300 termination procedures. 1302 To construct a Heartbeat signal, the Signal Type value in the signal 1303 header is set to DLEP_PEER_HEARTBEAT (value TBD). 1305 There are no valid data items for the Heartbeat signal. 1307 7.15. Link Characteristics Request Signal 1309 The Link Characteristics Request signal MAY be sent by the router to 1310 request that the modem initiate changes for specific characteristics 1311 of the link. The request can reference either a real destination 1312 (e.g., a remote node), or a logical destination (e.g., a multicast 1313 group) within the network. 1315 The Link Characteristics Request signal MAY contain either a Current 1316 Data Rate (CDRR or CDRT) data item to request a different datarate 1317 than what is currently allocated, a Latency data item to request that 1318 traffic delay on the link not exceed the specified value, or both. A 1319 Link Characteristics ACK signal (Section 7.16) is required to 1320 complete the request. Issuing a Link Characteristics Request with 1321 ONLY the MAC Address data item is a mechanism a peer MAY use to 1322 request metrics (via the Link Characteristics ACK) from its partner. 1324 The sender of a Link Characteristics Request signal MAY attach a 1325 timer to the request using the Link Characteristics ACK Timer data 1326 item. If a Link Characteristics ACK signal is received after the 1327 timer expires, the sender MUST NOT assume that the request succeeded. 1328 Implementations are free to define their retry heuristics in event of 1329 a timeout. 1331 To construct a Link Characteristics Request signal, the Signal Type 1332 value in the signal header is set to DLEP_LINK_CHAR_REQ (value TBD). 1334 The Link Characteristics Request signal MUST contain one of each of 1335 the following data items: 1337 o MAC Address (Section 8.9) 1339 The Link Characteristics Request signal MAY contain one of each of 1340 the following data items: 1342 o Link Characteristics ACK Timer (Section 8.23) 1344 o Current Data Rate (Receive) (Section 8.16) 1346 o Current Data Rate (Transmit) (Section 8.17) 1348 o Latency (Section 8.18) 1350 7.16. Link Characteristics ACK Signal 1352 A DLEP participant MUST send a Link Characteristics ACK signal to 1353 indicate whether a received Link Characteristics Request signal 1354 (Section 7.15) was successfully processed. The Link Characteristics 1355 ACK signal SHOULD contain a complete set of metric data items, and 1356 MUST contain a full set (i.e. those declared in the Peer 1357 Initialization ACK signal (Section 7.4)), if metrics were requested 1358 by only including a MAC address data item. It MUST contain the same 1359 metric types as the request. The values in the metric data items in 1360 the Link Characteristics ACK signal MUST reflect the link 1361 characteristics after the request has been processed. 1363 If an implementation is not able to alter the characteristics of the 1364 link in the manner requested, then a Status data item with status 1365 code 'Request Denied' MUST be added to the signal. 1367 To construct a Link Characteristics Request ACK signal, the Signal 1368 Type value in the signal header is set to DLEP_LINK_CHAR_ACK (value 1369 TBD). 1371 The Link Characteristics ACK signal MUST contain one of each of the 1372 following data items: 1374 o MAC Address (Section 8.9) 1376 The Link Characteristics ACK signal SHOULD contain one of each of the 1377 following data items: 1379 o Maximum Data Rate (Receive) (Section 8.14) 1381 o Maximum Data Rate (Transmit) (Section 8.15) 1382 o Current Data Rate (Receive) (Section 8.16) 1384 o Current Data Rate (Transmit) (Section 8.17) 1386 o Latency (Section 8.18) 1388 The Link Characteristics ACK signal MAY contain one of each of the 1389 following data items: 1391 o Resources (Receive) (Section 8.19) 1393 o Resources (Transmit) (Section 8.20) 1395 o Relative Link Quality (Receive) (Section 8.21) 1397 o Relative Link Quality (Transmit) (Section 8.22) 1399 o Status (Section 8.2) 1401 A receiver of a Link Characteristics ACK signal without a Status data 1402 item MUST behave as if a Status data item with status code 'Success' 1403 had been received. 1405 8. DLEP Data Items 1407 Following is the list of MANDATORY data items that must be recognized 1408 by a DLEP compliant implementation. As mentioned before, not all 1409 data items need be used during a session, but an implementation MUST 1410 correctly process these data items when correctly associated with a 1411 signal. 1413 The DLEP data items are: 1415 +------------+--------------------------------------+---------------+ 1416 | Data Item | Description | Section | 1417 +------------+--------------------------------------+---------------+ 1418 | TBD | DLEP Version | Section 8.1 | 1419 | TBD | Status | Section 8.2 | 1420 | TBD | IPv4 Connection Point | Section 8.3 | 1421 | TBD | IPv6 Connection Point | Section 8.4 | 1422 | TBD | Peer Type | Section 8.5 | 1423 | TBD | Heartbeat Interval | Section 8.6 | 1424 | TBD | Extensions Supported | Section 8.7 | 1425 | TBD | Experimental Definition | Section 8.8 | 1426 | TBD | MAC Address | Section 8.9 | 1427 | TBD | IPv4 Address | Section 8.10 | 1428 | TBD | IPv6 Address | Section 8.11 | 1429 | TBD | IPv4 Attached Subnet | Section 8.12 | 1430 | TBD | IPv6 Attached Subnet | Section 8.13 | 1431 | TBD | Maximum Data Rate (Receive) MDRR) | Section 8.14 | 1432 | TBD | Maximum Data Rate (Transmit) (MDRT) | Section 8.15 | 1433 | TBD | Current Data Rate (Receive) (CDRR) | Section 8.16 | 1434 | TBD | Current Data Rate (Transmit) (CDRT) | Section 8.17 | 1435 | TBD | Latency | Section 8.18 | 1436 | TBD | Resources (Receive) (RESR) | Section 8.19 | 1437 | TBD | Resources (Transmit) (REST) | Section 8.20 | 1438 | TBD | Relative Link Quality (Receive) | Section 8.21 | 1439 | | (RLQR) | | 1440 | TBD | Relative Link Quality (Transmit) | Section 8.22 | 1441 | | (RLQT) | | 1442 | TBD | Link Characteristics ACK Timer | Section 8.23 | 1443 +------------+--------------------------------------+---------------+ 1445 8.1. DLEP Version 1447 The DLEP Version data item MUST appear in the Peer Discovery 1448 (Section 7.1), Peer Offer (Section 7.2), Peer Initialization 1449 (Section 7.3) and Peer Initialization ACK (Section 7.4) signals. The 1450 Version data item is used to indicate the version of the protocol 1451 running in the originator. A DLEP implementation SHOULD use this 1452 information to decide if the potential session partner is running at 1453 a supported level. 1455 The DLEP Version data item contains the following fields: 1457 0 1 2 3 1458 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 | Data Item Type| Length | Major Version | 1461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1462 | Minor Version | 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1465 Data Item Type: TBD 1467 Length: 4 1469 Major Version: The major version of the DLEP protocol, expressed as 1470 an 16-bit unsigned integer. 1472 Minor Version: The minor version of the DLEP protocol, expressed as 1473 an 16-bit unsigned integer. 1475 Support of this draft is indicated by setting the Major Version to 1476 '0', and the Minor Version to '9' (i.e. Version 0.9). 1478 8.2. Status 1480 The Status data item MAY appear in the Peer Initialization ACK 1481 (Section 7.4), Peer Termination (Section 7.7), Peer Termination ACK 1482 (Section 7.8), Peer Update ACK (Section 7.6), Destination Up ACK 1483 (Section 7.10), Destination Down ACK (Section 7.12) and Link 1484 Characteristics ACK (Section 7.16) signals as part of an 1485 acknowledgement from either the modem or the router, to indicate the 1486 success or failure of the previously received signal. 1488 The status data item includes an optional Text field that can be used 1489 to provide a textual description of the status. The use of the Text 1490 field is entirely up to the receiving implementation, i.e., it could 1491 be output to a log file or discarded. If no Text field is supplied 1492 with the Status data item, the Length field MUST be set to 1. 1494 The Status data item contains the following fields: 1496 0 1 2 3 1497 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 1498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1499 | Data Item Type| Length | Code | Text... 1500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1502 Data Item Type: TBD 1504 Length: 1 + Length of text 1505 Status Code: One of the codes defined below. 1507 Text: UTF-8 encoded string, describing an problem, used for 1508 implementation defined purposes. 1510 An implementation MUST NOT assume the Text field is NUL-terminated. 1512 +----------------+-------+------------------------------------------+ 1513 | Status Code | Value | Reason | 1514 +----------------+-------+------------------------------------------+ 1515 | Success | 0 | The signal was processed successfully. | 1516 | Unknown Signal | TBD | The signal was not recognized by the | 1517 | | | implementation. | 1518 | Invalid Data | TBD | One or more data items in the signal are | 1519 | | | invalid, unexpected or duplicated. | 1520 | Unexpected | TBD | The signal was not expected while the | 1521 | Signal | | machine was in this state, e.g., a Peer | 1522 | | | Initialization signal after session | 1523 | | | establishment. | 1524 | Request Denied | TBD | The receiver has not completed the | 1525 | | | request. | 1526 | Timed Out | TBD | The request could not be completed in | 1527 | | | the time allowed. | 1528 | Invalid | TBD | The destination provided in the signal | 1529 | Destination | | does not match a previously announced | 1530 | | | destination. For example, in the Link | 1531 | | | Characteristic Request ACK signal | 1532 | | | (Section 7.16). | 1533 +----------------+-------+------------------------------------------+ 1535 8.3. IPv4 Connection Point 1537 The IPv4 Connection Point data item MAY appear in the Peer Offer 1538 signal (Section 7.2). The IPv4 Connection Point data item indicates 1539 the IPv4 address and, optionally, the TCP port number on the DLEP 1540 modem available for connections. If provided, the receiver MUST use 1541 this information to perform the TCP connect to the DLEP server. 1543 The IPv4 Connection Point data item contains the following fields: 1545 0 1 2 3 1546 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 1547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1548 | Data Item Type| Length | IPv4 Address | 1549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1550 | IPv4 Address | TCP Port Number (optional) | 1551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1552 Data Item Type: TBD 1554 Length: 4 (or 6 if TCP Port included) 1556 IPv4 Address: The IPv4 address listening on the DLEP modem. 1558 TCP Port Number: TCP Port number on the DLEP modem. 1560 If the Length field is 6, the port number specified MUST be used to 1561 establish the TCP session. If the TCP Port Number is omitted, i.e. 1562 the Length field is 4, the receiver MUST use the DLEP well-known port 1563 number (Section 11.7) to establish the TCP connection. 1565 8.4. IPv6 Connection Point 1567 The IPv6 Connection Point data item MAY appear in the Peer Offer 1568 signal (Section 7.2). The IPv6 Connection Point data item indicates 1569 the IPv6 address and, optionally, the TCP port number on the DLEP 1570 modem available for connections. If provided, the receiver MUST use 1571 this information to perform the TCP connect to the DLEP server. 1573 The IPv4 Connection Point data item contains the following fields: 1575 0 1 2 3 1576 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 1577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1578 | Data Item Type| Length | IPv6 Address | 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 | IPv6 Address | 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 | IPv6 Address | 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1584 | IPv6 Address | 1585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1586 | IPv6 Address | TCP Port Number (optional) | 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1589 Data Item Type: TBD 1591 Length: 16 (or 18 if TCP Port included) 1593 IPv6 Address: The IPv6 address listening on the DLEP modem. 1595 TCP Port Number: TCP Port number on the DLEP modem. 1597 If the Length field is 18, the port number specified MUST be used to 1598 establish the TCP session. If the TCP Port Number is omitted, i.e. 1600 the Length field is 16, the receiver MUST use the DLEP well-known 1601 port number (Section 11.7) to establish the TCP connection. 1603 8.5. Peer Type 1605 The Peer Type data item MAY appear in the Peer Discovery 1606 (Section 7.1), Peer Offer (Section 7.2), Peer Initialization 1607 (Section 7.3) and Peer Initialization ACK (Section 7.4) signals. The 1608 Peer Type data item is used by the router and modem to give 1609 additional information as to its type. The peer type is a string and 1610 is envisioned to be used for informational purposes (e.g., as output 1611 in a display command). 1613 The Peer Type data item contains the following fields: 1615 0 1 2 3 1616 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 1617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1618 | Data Item Type| Length | Peer Type | 1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1621 Data Item Type: TBD 1623 Length: Length of peer type string. 1625 Peer Type: UTF-8 encoded string. For example, a satellite modem 1626 might set this variable to "Satellite terminal". 1628 An implementation MUST NOT assume the Peer Type field is NUL- 1629 terminated. 1631 8.6. Heartbeat Interval 1633 The Heartbeat Interval data item MUST appear in both the Peer 1634 Initialization (Section 7.3) and Peer Initialization ACK 1635 (Section 7.4) signals to indicate the Heartbeat timeout window to be 1636 used by the sender. 1638 The Interval is used to specify a period (in seconds) for Heartbeat 1639 signals (Section 7.14). By specifying an Interval value of 0, 1640 implementations MAY indicates the desire to disable Heartbeat signals 1641 entirely (i.e., the Interval is set to an infinite value). However, 1642 it is strongly recommended that implementations use non 0 timer 1643 values. Implementations MUST implement heuristics such that DLEP 1644 signals sent/received reset the timer interval. 1646 A DLEP session will be considered inactive, and MUST be torn down, 1647 via the Peer Termination procedure, by an implementation detecting 1648 that two (2) Heartbeat intervals have transpired without receipt of 1649 any DLEP signals. 1651 The Heartbeat Interval data item contains the following fields: 1653 0 1 2 3 1654 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 1655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1656 | Data Item Type| Length | Interval | 1657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1659 Data Item Type: TBD 1661 Length: 2 1663 Interval: 0 = Do NOT use heartbeats on this DLEP session. Non-zero 1664 = Interval, in seconds, for heartbeat signals. 1666 8.7. Extensions Supported 1668 The Extensions Supported data item MAY be used in both the Peer 1669 Initialization and Peer Initialization ACK signals. The Extensions 1670 Supported data item is used by the router and modem to negotiate 1671 additional optional functionality they are willing to support. The 1672 Extensions List is a concatenation of the types of each supported 1673 extension, found in the IANA DLEP Extensions repository. 1675 The Extensions Supported data item contains the following fields: 1677 0 1 2 3 1678 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 1679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1680 | Data Item Type| Length | Extensions List | 1681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1683 Data Item Type: TBD 1685 Length: Number of Extensions supported. 1687 Extension List: A list of extensions supported, identified by their 1688 1-octet value as listed in the extensions registry. 1690 8.8. Experimental Definition 1692 The Experimental Definition data item MAY be used in both the Peer 1693 Initialization and Peer Initialization ACK signals. The Experimental 1694 Definition data item is used by the router and modem to indicate the 1695 formats to be used for experimental signals and data items for the 1696 given peer session. The formats are identified by using a string 1697 that matches the 'name' given to the experiment. 1699 The Experimental Definition item contains the following fields: 1701 0 1 2 3 1702 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 1703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1704 | Data Item Type| Length | Experiment Name | 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1707 Data Item Type: TBD 1709 Length: Length of the name string for the Experiment. 1711 Experiment Name: UTF-8 encoded string, containing the name of the 1712 experiment being utilized. 1714 An implementation receiving this data item MUST compare the received 1715 string to a list of experiments that it supports. 1717 An implementation MUST NOT assume the Experiment Name field is NUL- 1718 terminated. 1720 8.9. MAC Address 1722 The MAC address data item MUST appear in all destination-oriented 1723 signals (i.e., Destination Up (Section 7.9), Destination Up ACK 1724 (Section 7.10), Destination Down (Section 7.11), Destination Down ACK 1725 (Section 7.12), Destination Update (Section 7.13), Link 1726 Characteristics Request (Section 7.15), and Link Characteristics ACK 1727 (Section 7.16)). The MAC Address data item contains the address of 1728 the destination on the remote node. The MAC address MAY be either a 1729 physical or a virtual destination, and MAY be expressed in EUI-48 or 1730 EUI-64 format. Examples of a virtual destination would be a 1731 multicast MAC address, or the broadcast MAC (FF:FF:FF:FF:FF:FF). 1733 0 1 2 3 1734 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 1735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1736 | Data Item Type| Length | MAC Address | 1737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1738 | MAC Address | 1739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1740 | MAC Address | 1741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1743 Data Item Type: TBD 1744 Length: 6 for EUI-48 format, or 8 for EUI-64 format 1746 MAC Address: MAC Address of the destination. 1748 8.10. IPv4 Address 1750 The IPv4 Address data item MAY appear in the Peer Update 1751 (Section 7.5), Destination Up (Section 7.9) and Destination Update 1752 (Section 7.13) signals. When included in Destination signals, this 1753 data item contains the IPv4 address of the destination. When 1754 included in the Peer Update signal, this data item contains the IPv4 1755 address of the peer. In either case, the data item also contains an 1756 indication of whether this is a new or existing address, or is a 1757 deletion of a previously known address. 1759 The IPv4 Address data item contains the following fields: 1761 0 1 2 3 1762 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 1763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1764 | Data Item Type| Length | Add/Drop | IPv4 Address | 1765 | | | Indicator | | 1766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1767 | IPv4 Address | 1768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1770 Data Item Type: TBD 1772 Length: 5 1774 Add/Drop: Value indicating whether this is a new or existing address 1775 (1), or a withdrawal of an address (0). 1777 IPv4 Address: The IPv4 address of the destination or peer. 1779 8.11. IPv6 Address 1781 The IPv6 Address data item MAY appear in the Peer Update 1782 (Section 7.5), Destination Up (Section 7.9) and Destination Update 1783 (Section 7.13) signals. When included in Destination signals, this 1784 data item contains the IPv6 address of the destination. When 1785 included in the Peer Update signal, this data item contains the IPv6 1786 address of the peer. In either case, the data item also contains an 1787 indication of whether this is a new or existing address, or is a 1788 deletion of a previously known address. 1790 The IPv6 Address data item contains the following fields: 1792 0 1 2 3 1793 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 1794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1795 | Data Item Type| Length | Add/Drop | IPv6 Address | 1796 | | | Indicator | | 1797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1798 | IPv6 Address | 1799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1800 | IPv6 Address | 1801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1802 | IPv6 Address | 1803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1804 | IPv6 Address | 1805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1807 Data Item Type: TBD 1809 Length: 17 1811 Add/Drop: Value indicating whether this is a new or existing address 1812 (1), or a withdrawal of an address (0). 1814 IPv6 Address: IPv6 Address of the destination or peer. 1816 8.12. IPv4 Attached Subnet 1818 The DLEP IPv4 Attached Subnet allows a device to declare that it has 1819 an IPv4 subnet (e.g., a stub network) attached, and MAY appear in the 1820 Destination Up (Section 7.9) and Destination Update (Section 7.13) 1821 signals. Once an IPv4 Subnet has been declared on a device, the 1822 declaration can NOT be withdrawn without terminating the destination 1823 (via the Destination Down signal (Section 7.11)) and re-issuing the 1824 Destination Up signal. 1826 The DLEP IPv4 Attached Subnet data item contains the following 1827 fields: 1829 0 1 2 3 1830 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 1831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1832 |Data Item Type | Length | IPv4 Attached Subnet | 1833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1834 | IPv4 Attached Subnet | Subnet Mask | 1835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1837 Data Item Type: TBD 1839 Length: 5 1840 IPv4 Subnet: The IPv4 subnet reachable at the destination. 1842 Subnet Mask: A subnet mask (0-32) to be applied to the IPv4 subnet. 1844 8.13. IPv6 Attached Subnet 1846 The DLEP IPv6 Attached Subnet allows a device to declare that it has 1847 an IPv6 subnet (e.g., a stub network) attached, and MAY appear in the 1848 Destination Up (Section 7.9) and Destination Update (Section 7.13) 1849 signals. As in the case of the IPv4 attached Subnet data item above, 1850 once an IPv6 attached subnet has been declared, it can NOT be 1851 withdrawn without terminating the destination (via the Destination 1852 Down signal (Section 7.11)) and re-issuing the Destination Up signal. 1854 The DLEP IPv6 Attached Subnet data item contains the following 1855 fields: 1857 0 1 2 3 1858 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 1859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1860 | Data Item Type| Length | IPv6 Attached Subnet | 1861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1862 | IPv6 Attached Subnet | 1863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1864 | IPv6 Attached Subnet | 1865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1866 | IPv6 Attached Subnet | 1867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1868 | IPv6 Attached Subnet | Subnet Mask | 1869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1871 Data Item Type: TBD 1873 Length: 17 1875 IPv6 Subnet: The IPv6 subnet reachable at the destination. 1877 Subnet Mask: A subnet mask (0-128) to be applied to the IPv6 subnet. 1879 8.14. Maximum Data Rate (Receive) 1881 The Maximum Data Rate (Receive) (MDRR) data item MUST appear in the 1882 Peer Initialization ACK signal (Section 7.4), and MAY appear in the 1883 Peer Update (Section 7.5), Destination Up (Section 7.9), Destination 1884 Update (Section 7.13) and Link Characteristics ACK (Section 7.16) 1885 signals to indicate the maximum theoretical data rate, in bits per 1886 second, that can be achieved while receiving data on the link. 1888 The Maximum Data Rate (Receive) data item contains the following 1889 fields: 1891 0 1 2 3 1892 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 1893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1894 | Data Item Type| Length | MDRR (bps) | 1895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1896 | MDRR (bps) | 1897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1898 | MDRR (bps) | 1899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1901 Data Item Type: TBD 1903 Length: 8 1905 Maximum Data Rate (Receive): A 64-bit unsigned integer, representing 1906 the maximum theoretical data rate, in bits per second (bps), that 1907 can be achieved while receiving on the link. 1909 8.15. Maximum Data Rate (Transmit) 1911 The Maximum Data Rate (Transmit) (MDRT) data item MUST appear in the 1912 Peer Initialization ACK signal (Section 7.4), and MAY appear in the 1913 Peer Update (Section 7.5), Destination Up (Section 7.9), Destination 1914 Update (Section 7.13) and Link Characteristics ACK (Section 7.16) 1915 signals to indicate the maximum theoretical data rate, in bits per 1916 second, that can be achieved while transmitting data on the link. 1918 The Maximum Data Rate (Transmit) data item contains the following 1919 fields: 1921 0 1 2 3 1922 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 1923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1924 | Data Item Type| Length | MDRT (bps) | 1925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1926 | MDRT (bps) | 1927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1928 | MDRT (bps) | 1929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1931 Data Item Type: TBD 1933 Length: 8 1934 Maximum Data Rate (Transmit): A 64-bit unsigned integer, 1935 representing the maximum theoretical data rate, in bits per second 1936 (bps), that can be achieved while transmitting on the link. 1938 8.16. Current Data Rate (Receive) 1940 The Current Data Rate (Receive) (CDRR) data item MUST appear in the 1941 Peer Initialization ACK signal (Section 7.4), and MAY appear in the 1942 Peer Update (Section 7.5), Destination Up (Section 7.9), Destination 1943 Update (Section 7.13) and Link Characteristics ACK (Section 7.16) 1944 signals to indicate the rate at which the link is currently operating 1945 for receiving traffic. 1947 When used in the Link Characteristics Request signal (Section 7.15), 1948 CDRR represents the desired receive rate, in bits per second, on the 1949 link. 1951 The Current Data Rate (Receive) data item contains the following 1952 fields: 1954 0 1 2 3 1955 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 1956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1957 | Data Item Type| Length | CDRR (bps) | 1958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1959 | CDRR (bps) | 1960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1961 | CDRR (bps) | 1962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1964 Data Item Type: TBD 1966 Length: 8 1968 Current Data Rate (Receive): A 64-bit unsigned integer, representing 1969 the current data rate, in bits per second, that can currently be 1970 achieved while receiving traffic on the link. 1972 If there is no distinction between current and maximum receive data 1973 rates, current data rate receive MUST be set equal to the maximum 1974 data rate receive. 1976 8.17. Current Data Rate (Transmit) 1978 The Current Data Rate Transmit (CDRT) data item MUST appear in the 1979 Peer Initialization ACK signal (Section 7.4), and MAY appear in the 1980 Peer Update (Section 7.5), Destination Up (Section 7.9), Destination 1981 Update (Section 7.13), and Link Characteristics ACK (Section 7.16) 1982 signals to indicate the rate at which the link is currently operating 1983 for transmitting traffic. 1985 When used in the Link Characteristics Request signal (Section 7.15), 1986 CDRT represents the desired transmit rate, in bits per second, on the 1987 link. 1989 The Current Data Rate (Transmit) data item contains the following 1990 fields: 1992 0 1 2 3 1993 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 1994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1995 | Data Item Type| Length | CDRT (bps) | 1996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1997 | CDRT (bps) | 1998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1999 | CDRT (bps) | 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2002 Data Item Type: TBD 2004 Length: 8 2006 Current Data Rate (Transmit): A 64-bit unsigned integer, 2007 representing the current data rate, in bits per second, that can 2008 currently be achieved while transmitting traffic on the link. 2010 If there is no distinction between current and maximum transmit data 2011 rates, current data rate transmit MUST be set equal to the maximum 2012 data rate transmit. 2014 8.18. Latency 2016 The Latency data item data item MUST appear in the Peer 2017 Initialization ACK signal (Section 7.4), and MAY appear in the Peer 2018 Update (Section 7.5), Destination Up (Section 7.9), Destination 2019 Update (Section 7.13), and Link Characteristics ACK (Section 7.16) 2020 signals to indicate the amount of latency, in microseconds, on the 2021 link. 2023 When used in the Link Characteristics Request signal (Section 7.15), 2024 Latency represents the maximum latency desired on the link. 2026 The Latency value is reported as delay. The calculation of latency 2027 is implementation dependent. For example, the latency may be a 2028 running average calculated from the internal queuing. 2030 0 1 2 3 2031 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 2032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2033 | Data Item Type| Length | Latency | 2034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2035 | Latency (cont.) | 2036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2038 Data Item Type: TBD 2040 Length: 4 2042 Latency: A 32-bit unsigned integer, representing the transmission 2043 delay, in microseconds, that a packet encounters as it is 2044 transmitted over the link. 2046 8.19. Resources (Receive) 2048 The Resources (Receive) (RESR) data item MAY appear in the Peer 2049 Initialization ACK signal (Section 7.4), Peer Update (Section 7.5), 2050 Destination Up (Section 7.9), Destination Update (Section 7.13) and 2051 Link Characteristics ACK (Section 7.16) signals to indicate the 2052 amount of resources for reception (with 0 meaning 'no resources 2053 available', and 100 meaning 'all resources available') at the 2054 destination. The list of resources that might be considered is 2055 beyond the scope of this document, and is left to implementations to 2056 decide. 2058 The Resources (Receive) data item contains the following fields: 2060 0 1 2 2061 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2063 | Data Item Type| Length | RESR | 2064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2066 Data Item Type: TBD 2068 Length: 1 2070 Resources (Receive): An 8-bit integer percentage, 0-100, 2071 representing the amount of resources allocated to receiving data. 2073 If a device cannot calculate RESR, this data item SHOULD NOT be 2074 issued. 2076 8.20. Resources (Transmit) 2078 The Resources (Transmit) (REST) data item MAY appear in the Peer 2079 Initialization ACK signal (Section 7.4), Peer Update (Section 7.5), 2080 Destination Up (Section 7.9), Destination Update (Section 7.13) and 2081 Link Characteristics ACK (Section 7.16) signals to indicate the 2082 amount of resources for transmission (with 0 meaning 'no resources 2083 available', and 100 meaning 'all resources available') at the 2084 destination. The list of resources that might be considered is 2085 beyond the scope of this document, and is left to implementations to 2086 decide. 2088 The Resources (Transmit) data item contains the following fields: 2090 0 1 2 2091 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2093 | Data Item Type| Length | REST | 2094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2096 Data Item Type: TBD 2098 Length: 1 2100 Resources (Transmit): An 8-bit integer percentage, 0-100, 2101 representing the amount of resources allocated to transmitting 2102 data. 2104 If a device cannot calculate REST, this data item SHOULD NOT be 2105 issued. 2107 8.21. Relative Link Quality (Receive) 2109 The Relative Link Quality (Receive) (RLQR) data item MAY appear in 2110 the Peer Initialization ACK signal (Section 7.4), Peer Update 2111 (Section 7.5), Destination Up (Section 7.9), Destination Update 2112 (Section 7.13) and Link Characteristics ACK (Section 7.16) signals to 2113 indicate the quality of the link for receiving data. 2115 The Relative Link Quality (Receive) data item contains the following 2116 fields: 2118 0 1 2 2119 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2121 | Data Item Type| Length | RLQR | 2122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2123 Data Item Type: TBD 2125 Length: 1 2127 Relative Link Quality (Receive): A non-dimensional 8-bit integer, 2128 1-100, representing relative link quality. A value of 100 2129 represents a link of the highest quality. 2131 If a device cannot calculate the RLQR, this data item SHOULD NOT be 2132 issued. 2134 8.22. Relative Link Quality (Transmit) 2136 The Relative Link Quality (Transmit) (RLQT) data item MAY appear in 2137 the Peer Initialization ACK signal (Section 7.4), Peer Update 2138 (Section 7.5), Destination Up (Section 7.9), Destination Update 2139 (Section 7.13) and Link Characteristics ACK (Section 7.16) signals to 2140 indicate the quality of the link for transmitting data. 2142 The Relative Link Quality (Transmit) data item contains the following 2143 fields: 2145 0 1 2 2146 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2148 | Data Item Type| Length | RLQT | 2149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2151 Data Item Type: TBD 2153 Length: 1 2155 Relative Link Quality (Transmit): A non-dimensional 8-bit integer, 2156 1-100, representing relative link quality. A value of 100 2157 represents a link of the highest quality. 2159 If a device cannot calculate the RLQT, this data item SHOULD NOT be 2160 issued. 2162 8.23. Link Characteristics ACK Timer 2164 The Link Characteristics ACK Timer data item MAY appear in the Link 2165 Characteristics Request signal (Section 7.15) to indicate the desired 2166 number of seconds to the sender will wait for a response to the 2167 request. If this data item is omitted, implementations supporting 2168 the Link Characteristics Request SHOULD choose a default value. 2170 The Link Characteristics ACK Timer data item contains the following 2171 fields: 2173 0 1 2 2174 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2176 | Data Item Type| Length | Interval | 2177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2179 Data Item Type: TBD 2181 Length: 1 2183 Interval: 0 = Do NOT use timeouts for this Link Characteristics 2184 request. Non-zero = Interval, in seconds, to wait before 2185 considering this Link Characteristics Request has been lost. 2187 9. Credit-Windowing 2189 DLEP includes an OPTIONAL Protocol Extension for a credit-windowing 2190 scheme analogous to the one documented in [RFC5578]. In this scheme, 2191 traffic between the router and modem is treated as two unidirectional 2192 windows. This document identifies these windows as the 'Modem 2193 Receive Window' (MRW), and the 'Router Receive Window' (RRW). 2195 If the OPTIONAL credit-windowing extension is used, credits MUST be 2196 granted by the receiver on a given window - that is, on the 'Modem 2197 Receive Window' (MRW), the modem is responsible for granting credits 2198 to the router, allowing it (the router) to send data to the modem. 2199 Likewise, the router is responsible for granting credits on the RRW, 2200 which allows the modem to send data to the router. 2202 Credits are managed on a destination-specific basis; that is, 2203 separate credit counts are maintained for each destination requiring 2204 the service. Credits do not apply to the DLEP session that exists 2205 between routers and modems. 2207 If a peer is able to support the OPTIONAL credit-windowing extension 2208 then it MUST include a Extensions Supported data item (Section 8.7) 2209 including the value DLEP_EXT_CREDITS (value TBD) in the appropriate 2210 Peer Initialization or Peer Initialization ACK signal. 2212 9.1. Credit-Windowing Signals 2214 The credit-windowing extension introduces no additional DLEP signals. 2215 However, if a peer has advertised during session initialization that 2216 it supports the credit-windowing extension then the following DLEP 2217 signals MAY contain additional credit-windowing data items: 2219 9.1.1. Destination Up Signal 2221 The Destination Up signal MAY contain one of each of the following 2222 data items: 2224 o Credit Grant (Section 9.2.1) 2226 If the Destination Up signal does not contain the Credit Grant data 2227 item, credits MUST NOT be used for that destination. 2229 9.1.2. Destination Up ACK Signal 2231 If the corresponding Destination Up signal contained the Credit Grant 2232 data item, the Destination Up ACK signal MUST contain one of each of 2233 the following data items: 2235 o Credit Window Status (Section 9.2.2) 2237 9.1.3. Destination Update Signal 2239 If the corresponding Destination Up signal contained the Credit Grant 2240 data item, the Destination Update signal MUST contain one of each of 2241 the following data items: 2243 o Credit Window Status (Section 9.2.2) 2245 If the corresponding Destination Up signal contained the Credit Grant 2246 data item, the Destination Update signal MAY contain one of each of 2247 the following data items: 2249 o Credit Grant (Section 9.2.1) 2251 o Credit Request (Section 9.2.3) 2253 9.2. Credit-Windowing Data Items 2255 The credit-windowing extension introduces 3 additional data items. 2256 If a peer has advertised during session initialization that it 2257 supports the credit-windowing extension then it MUST correctly 2258 process the following data items without error. 2260 +------------+-----------------------+----------------+ 2261 | Data Item | Description | Section | 2262 +------------+-----------------------+----------------+ 2263 | TBD | Credit Grant | Section 9.2.1 | 2264 | TBD | Credit Window Status | Section 9.2.2 | 2265 | TBD | Credit Request | Section 9.2.3 | 2266 +------------+-----------------------+----------------+ 2268 9.2.1. Credit Grant 2270 The Credit Grant data item is sent from a DLEP participant to grant 2271 an increment to credits on a window. The Credit Grant data item MAY 2272 appear in the Destination Up (Section 7.9) and Destination Update 2273 (Section 7.13) signals. The value in a Credit Grant data item 2274 represents an increment to be added to any existing credits available 2275 on the window. Upon successful receipt and processing of a Credit 2276 Grant data item, the receiver MUST respond with a signal containing a 2277 Credit Window Status data item to report the updated aggregate values 2278 for synchronization purposes, and if initializing a new credit 2279 window, granting initial credits. 2281 In the Destination Up signal, when credits are desired, the 2282 originating peer MUST set the initial credit value of the window it 2283 controls (i.e., the Modem Receive Window, or Router Receive Window) 2284 to an initial, non-zero value. If the receiver of a Destination Up 2285 signal with a Credit Grant data item supports credits, the receiver 2286 MUST either reject the use of credits for this destination, via a 2287 Destination Up ACK response containing a Status data item 2288 (Section 8.2) with a status code of 'Request Denied', or set the 2289 initial value from the data contained in the Credit Window Status 2290 data item. If the initialization completes successfully, the 2291 receiver MUST respond to the Destination Up signal with a Destination 2292 Up ACK signal that contains a Credit Window Status data item, 2293 initializing its receive window. 2295 The Credit Grant data item contains the following fields: 2297 0 1 2 3 2298 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 2299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2300 | Data Item Type| Length | Credit Increment | 2301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2302 | Credit Increment | 2303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2304 | Credit Increment | 2305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2307 Data Item Type: TBD 2309 Length: 8 2311 Reserved: A 64-bit unsigned integer representing the additional 2312 credits to be assigned to the credit window. 2314 Since credits can only be granted by the receiver on a window, the 2315 applicable credit window (either the MRW or the RRW) is derived from 2316 the sender of the grant. The Credit Increment MUST NOT cause the 2317 window to overflow; if this condition occurs, implementations MUST 2318 set the credit window to the maximum value contained in a 64-bit 2319 quantity. 2321 9.2.2. Credit Window Status 2323 If the credit-window extension is supported by the DLEP participants 2324 (both the router and the modem), the Credit Window Status data item 2325 MUST be sent by the participant receiving a Credit Grant for a given 2326 destination. 2328 The Credit Window Status data item contains the following fields: 2330 0 1 2 3 2331 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 2332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2333 | Data Item Type| Length | Modem Receive Window Value | 2334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2335 | Modem Receive Window Value | 2336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2337 | Modem Receive Window Value | Router Receive Window Value | 2338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2339 | Router Receive Window Value | 2340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2341 | Router Receive Window Value | 2342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2344 Data Item Type: TBD 2346 Length: 16 2348 Modem Receive Window Value: A 64-bit unsigned integer, indicating 2349 the current number of credits available on the Modem Receive 2350 Window, for the destination referred to by the signal. 2352 Router Receive Window Value: A 64-bit unsigned integer, indicating 2353 the current number of credits available on the Router Receive 2354 Window, for the destination referred to by the signal. 2356 9.2.3. Credit Request 2358 The Credit Request data item MAY be sent from either DLEP 2359 participant, via the Destination Update signal (Section 7.13), to 2360 indicate the desire for the partner to grant additional credits in 2361 order for data transfer to proceed on the session. If the 2362 corresponding Destination Up signal (Section 7.9) for this session 2363 did NOT contain a Credit Window Status data item, indicating that 2364 credits are to be used on the session, then the Credit Request data 2365 item MUST be silently dropped by the receiver. 2367 The Credit Request data item contains the following fields: 2369 0 1 2 2370 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2372 | Data Item Type| Length | Reserved, MUST| 2373 | | | be set to 0 | 2374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2376 Data Item Type: TBD 2378 Length: 1 2380 Reserved: This field is currently unused and MUST be set to 0. 2382 10. Security Considerations 2384 The protocol does not contain any mechanisms for security (e.g., 2385 authentication or encryption). The protocol assumes that any 2386 security would be implemented in the underlying transport (for 2387 example, by use of DTLS or some other mechanism), and is therefore 2388 outside the scope of this document. 2390 11. IANA Considerations 2392 This section specifies requests to IANA. 2394 11.1. Registrations 2396 This specification defines: 2398 o A new repository for DLEP signals, with sixteen values currently 2399 assigned. 2401 o Reservation of numbering space for Experimental DLEP signals. 2403 o A new repository for DLEP data items, with twenty-six values 2404 currently assigned. 2406 o Reservation of numbering space in the data items repository for 2407 experimental data items. 2409 o A new repository for DLEP status codes, with seven currently 2410 assigned. 2412 o A new repository for DLEP extensions, with one value currently 2413 assigned. 2415 o A request for allocation of a well-known port for DLEP TCP and UDP 2416 communication. 2418 o A request for allocation of a multicast IP address for DLEP 2419 discovery. 2421 11.2. Expert Review: Evaluation Guidelines 2423 No additional guidelines for expert review are anticipated. 2425 11.3. Signal Type Registration 2427 A new repository must be created with the values of the DLEP signals. 2429 All signal values are in the range [0..255]. 2431 Valid signals are: 2433 o Peer Discovery 2435 o Peer Offer 2437 o Peer Initialization 2439 o Peer Initialization ACK 2441 o Peer Update 2443 o Peer Update ACK 2445 o Peer Termination 2447 o Peer Termination ACK 2449 o Destination Up 2451 o Destination Up ACK 2453 o Destination Down 2455 o Destination Down ACK 2457 o Destination Update 2459 o Heartbeat 2460 o Link Characteristics Request 2462 o Link Characteristics ACK 2464 It is also requested that the repository contain space for 2465 experimental signal types. 2467 11.4. DLEP Data Item Registrations 2469 A new repository for DLEP data items must be created. 2471 All data item values are in the range [0..255]. 2473 Valid data items are: 2475 o DLEP Version 2477 o Status 2479 o IPv4 Connection Point 2481 o IPv6 Connection Point 2483 o Peer Type 2485 o Heartbeat Interval 2487 o Extensions Supported 2489 o Experimental Definition 2491 o MAC Address 2493 o IPv4 Address 2495 o IPv6 Address 2497 o IPv4 Attached Subnet 2499 o IPv6 Attached Subnet 2501 o Maximum Data Rate (Receive) 2503 o Maximum Data Rate (Transmit) 2505 o Current Data Rate (Receive) 2507 o Current Data Rate (Transmit) 2508 o Latency 2510 o Resources (Receive) 2512 o Resources (Transmit) 2514 o Relative Link Quality (Receive) 2516 o Relative Link Quality (Transmit) 2518 o Link Characteristics ACK Timer 2520 o Credit Window Status 2522 o Credit Grant 2524 o Credit Request 2526 It is also requested that the registry allocation contain space for 2527 experimental data items. 2529 11.5. DLEP Status Code Registrations 2531 A new repository for DLEP status codes must be created. 2533 All status codes are in the range [0..255]. 2535 Valid status codes are: 2537 o Success (value 0) 2539 o Unknown Signal 2541 o Invalid Data 2543 o Unexpected Signal 2545 o Request Denied 2547 o Timed Out 2549 o Invalid Destination 2551 11.6. DLEP Extensions Registrations 2553 A new repository for DLEP extensions must be created. 2555 All extension values are in the range [0..255]. 2557 Valid extensions are: 2559 o DLEP_EXT_CREDITS - Credit windowing 2561 11.7. DLEP Well-known Port 2563 It is requested that IANA allocate a well-known port number for DLEP 2564 communication. 2566 11.8. DLEP Multicast Address 2568 It is requested that IANA allocate a multicast address for DLEP 2569 discovery signals. 2571 12. Acknowledgements 2573 The authors would like to acknowledge and thank the members of the 2574 DLEP design team, who have provided invaluable insight. The members 2575 of the design team are: Teco Boot, Bow-Nan Cheng, John Dowdell, and 2576 Henning Rogge. 2578 The authors would also like to acknowledge the influence and 2579 contributions of Greg Harrison, Chris Olsen, Martin Duke, Subir Das, 2580 Jaewon Kang, Vikram Kaul, Nelson Powell and Victoria Mercieca. 2582 13. References 2584 13.1. Normative References 2586 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2587 Requirement Levels", BCP 14, RFC 2119, March 1997. 2589 [RFC5578] Berry, B., Ratliff, S., Paradise, E., Kaiser, T., and M. 2590 Adams, "PPP over Ethernet (PPPoE) Extensions for Credit 2591 Flow and Link Metrics", RFC 5578, February 2010. 2593 13.2. Informative References 2595 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2596 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 2598 Appendix A. Peer Level Signal Flows 2600 A.1. Discovery 2601 Router Modem Signal Description 2602 ======================================================================== 2604 | Router initiates discovery, starts 2605 | a timer, send Peer Discovery 2606 |-------Peer Discovery---->|| signal. 2608 ~ ~ ~ ~ ~ ~ ~ Router discovery timer expires 2609 without receiving Peer Offer. 2611 | Router sends another Peer 2612 |-------Peer Discovery---------->| Discovery signal. 2613 | 2614 | Modem receives Peer Discovery 2615 | signal. 2616 | 2617 | Modem sends Peer Offer with 2618 |<--------Peer Offer-------------| Connection Point information. 2619 : 2620 : Router MAY cancel discovery timer 2621 : and stop sending Peer Discovery 2622 : signals. 2624 A.2. Session Initialization 2626 Router Modem Signal Description 2627 ======================================================================== 2629 | Router connects to discovered or 2630 | pre-configured Modem Connection 2631 |---------TCP connect----------> Point. 2632 | 2633 | Router sends Peer Initialization 2634 |-------Peer Initialization----->| signal. 2635 | 2636 | Modem receives Peer Initialization 2637 | signal. 2638 | 2639 | Modem sends Peer Initialization 2640 | ACK, with compatible extensions, 2641 |<----Peer Initialization ACK----| and Success status data item. 2642 | | 2643 |<<============================>>| Session established. Heartbeats 2644 : : begin. 2646 A.3. Session Initialization - Refused 2648 Router Modem Signal Description 2649 ======================================================================== 2651 | Router connects to discovered or 2652 | pre-configured Modem Connection 2653 |---------TCP connect----------> Point. 2654 | 2655 | Router sends Peer Initialization 2656 |-------Peer Initialization----->| signal. 2657 | 2658 | Modem receives Peer Initialization 2659 | signal, and will not support the 2660 | advertised version, experiment or 2661 | extensions. 2662 | 2663 | Modem sends Peer Initialization 2664 | ACK, with 'Request Denied' status 2665 |<----Peer Initialization ACK----| data item. 2666 | | 2667 | <---- TCP shutdown (send)-----| Modem closes TCP connection. 2668 | 2669 | Router receives negative Peer 2670 | Initialization ACK, closes 2671 |---------TCP close-----------> TCP connection. 2672 | 2673 ||------------------------------|| Session not started. 2675 A.4. Router Changes IP Addresses 2677 Router Modem Signal Description 2678 ======================================================================== 2680 | Router sends Peer Update signal to 2681 |--------Peer Update------------>| announce change of IP address 2682 | 2683 | Modem receives Peer Update signal 2684 | and updates internal state. 2685 | 2686 |<-------Peer Update ACK---------| Modem sends Peer Update ACK. 2688 A.5. Modem Changes Session-wide Metrics 2689 Router Modem Signal Description 2690 ======================================================================== 2692 | Modem sends Peer Update signal to 2693 | announce change of modem-wide 2694 |<--------Peer Update------------| metrics 2695 | 2696 | Router receives Peer Update signal 2697 | and updates internal state. 2698 | 2699 |-------Peer Update ACK--------->| Router sends Peer Update ACK. 2701 A.6. Router Terminates Session 2703 Router Modem Signal Description 2704 ======================================================================== 2706 | Router sends Peer Termination 2707 |-------Peer Termination-------->| signal with Status data item. 2708 | | 2709 |-------TCP shutdown (send)---> | Router stops sending signals. 2710 | 2711 | Modem receives Peer Termination, 2712 | stops counting received heartbeats 2713 | and stops sending heartbeats. 2714 | 2715 | Modem sends Peer Termination ACK 2716 |<-----Peer Termination ACK------| with Status 'Success'. 2717 | | 2718 | <----TCP shutdown (send)------| Modem stops sending signals. 2719 | 2720 ||------------------------------|| Session terminated. 2722 A.7. Modem Terminates Session 2723 Router Modem Signal Description 2724 ======================================================================== 2726 | Modem sends Peer Termination 2727 |<------Peer Termination---------| signal with Status data item. 2728 | | 2729 | <----TCP shutdown (send)------| Modem stops sending signals. 2730 | 2731 | Router receives Peer Termination, 2732 | stops counting received heartbeats 2733 | and stops sending heartbeats. 2734 | 2735 | Router sends Peer Termination ACK 2736 |------Peer Termination ACK----->| with Status 'Success'. 2737 | | 2738 |-------TCP shutdown (send)---> | Router stops sending signals. 2739 | 2740 ||------------------------------|| Session terminated. 2742 A.8. Session Heartbeats 2743 Router Modem Signal Description 2744 ======================================================================== 2746 |----------Heartbeat------------>| Router sends heartbeat signal 2747 | 2748 | Modem resets heartbeats missed 2749 | counter. 2751 ~ ~ ~ ~ ~ ~ ~ 2753 |----------[Any signal]--------->| When the Modem receives any signal 2754 | from the Router. 2755 | 2756 | Modem resets heartbeats missed 2757 | counter. 2759 ~ ~ ~ ~ ~ ~ ~ 2761 |<---------Heartbeat-------------| Modem sends heartbeat signal 2762 | 2763 | Router resets heartbeats missed 2764 | counter. 2766 ~ ~ ~ ~ ~ ~ ~ 2768 |<---------[Any signal]----------| When the Router receives any 2769 | signal from the Modem. 2770 | 2771 | Modem resets heartbeats missed 2772 | counter. 2774 A.9. Router Detects a Heartbeat timeout 2776 Router Modem Signal Description 2777 ======================================================================== 2779 ||<----------------------| Router misses a heartbeat 2781 | ||<----------------------| Router misses too many heartbeats 2782 | 2783 | 2784 |-------Peer Termination-------->| Router sends Peer Termination 2785 | signal with 'Timeout' Status 2786 | data item. 2787 : 2788 : Termination proceeds as above. 2790 A.10. Modem Detects a Heartbeat timeout 2792 Router Modem Signal Description 2793 ======================================================================== 2795 |---------------------->|| Modem misses a heartbeat 2797 |---------------------->|| | Modem misses too many heartbeats 2798 | 2799 | 2800 |<-------Peer Termination--------| Modem sends Peer Termination 2801 | signal with 'Timeout' Status 2802 | data item. 2803 : 2804 : Termination proceeds as above. 2806 Appendix B. Destination Specific Signal Flows 2808 B.1. Common Destination Signaling 2810 Router Modem Signal Description 2811 ======================================================================== 2813 | Modem detects a new logical 2814 | destination is reachable, and 2815 |<-------Destination Up----------| sends Destination Up signal. 2816 | 2817 |--------Destination Up ACK----->| Router sends Destination Up ACK. 2819 ~ ~ ~ ~ ~ ~ ~ 2820 | Modem detects change in logical 2821 | destination metrics, and sends 2822 |<-------Destination Update------| Destination Update signal. 2824 ~ ~ ~ ~ ~ ~ ~ 2825 | Modem detects change in logical 2826 | destination metrics, and sends 2827 |<-------Destination Update------| Destination Update signal. 2829 ~ ~ ~ ~ ~ ~ ~ 2830 | Modem detects logical destination 2831 | is no longer reachable, and sends 2832 |<-------Destination Down--------| Destination Down signal. 2833 | 2834 | Router receives Destination Down, 2835 | updates internal state, and sends 2836 |--------Destination Down ACK--->| Destination Down ACK signal. 2838 B.2. Multicast Destination Signaling 2840 Router Modem Signal Description 2841 ======================================================================== 2843 | Router detects a new multicast 2844 | destination is in use, and sends 2845 |--------Destination Up--------->| Destination Up signal. 2846 | 2847 | Modem updates internal state to 2848 | monitor multicast destination, and 2849 |<-------Destination Up ACK------| sends Destination Up ACK. 2851 ~ ~ ~ ~ ~ ~ ~ 2852 | Modem detects change in multicast 2853 | destination metrics, and sends 2854 |<-------Destination Update------| Destination Update signal. 2856 ~ ~ ~ ~ ~ ~ ~ 2857 | Modem detects change in multicast 2858 | destination metrics, and sends 2859 |<-------Destination Update------| Destination Update signal. 2861 ~ ~ ~ ~ ~ ~ ~ 2862 | Router detects multicast 2863 | destination is no longer in use, 2864 |--------Destination Down------->| and sends Destination Down signal. 2865 | 2866 | Modem receives Destination Down, 2867 | updates internal state, and sends 2868 |<-------Destination Down ACK----| Destination Down ACK signal. 2870 B.3. Link Characteristics Request 2871 Router Modem Signal Description 2872 ======================================================================== 2874 Destination has already been 2875 ~ ~ ~ ~ ~ ~ ~ announced by either peer. 2877 | Router requires different 2878 | Characteristics for the 2879 | destination, and sends Link 2880 |--Link Characteristics Request->| Characteristics Request signal. 2881 | 2882 | Modem attempts to adjust link 2883 | status to meet the received 2884 | request, and sends a Link 2885 | Characteristics Request ACK 2886 |<---Link Char. Request ACK------| signal with the new values. 2888 Authors' Addresses 2890 Stan Ratliff 2891 VT iDirect 2892 13861 Sunrise Valley Drive, Suite 300 2893 Herndon, VA 20171 2894 USA 2896 Email: sratliff@idirect.net 2898 Bo Berry 2900 Shawn Jury 2901 Cisco Systems 2902 170 West Tasman Drive 2903 San Jose, CA 95134 2904 USA 2906 Email: sjury@cisco.com 2908 Darryl Satterwhite 2909 Broadcom 2911 Email: dsatterw@broadcom.com 2912 Rick Taylor 2913 Airbus Defence & Space 2914 Quadrant House 2915 Celtic Springs 2916 Coedkernew 2917 Newport NP10 8FZ 2918 UK 2920 Email: rick.taylor@airbus.com