idnits 2.17.1 draft-ietf-manet-dlep-09.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 (April 13, 2015) is 3300 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. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networks Working Group S. Ratliff 3 Internet-Draft VT iDirect 4 Intended status: Standards Track B. Berry 5 Expires: October 15, 2015 6 S. Jury 7 Cisco Systems 8 D. Satterwhite 9 Broadcom 10 R. Taylor 11 Airbus Defence & Space 12 April 13, 2015 14 Dynamic Link Exchange Protocol (DLEP) 15 draft-ietf-manet-dlep-09 17 Abstract 19 When routing devices rely on modems to effect communications over 20 wireless links, they need timely and accurate knowledge of the 21 characteristics of the link (speed, state, etc.) in order to make 22 forwarding decisions. In mobile or other environments where these 23 characteristics change frequently, manual configurations or the 24 inference of state through routing or transport protocols does not 25 allow the router to make the best decisions. A bidirectional, event- 26 driven communication channel between the router and the modem is 27 necessary. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on October 15, 2015. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 7 65 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 8 66 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 3. Core Features and Optional Extensions . . . . . . . . . . . . 10 68 3.1. Negotiation of Optional Extensions . . . . . . . . . . . 10 69 3.2. Protocol Extensions . . . . . . . . . . . . . . . . . . . 10 70 3.3. Experimental Signals and Data Items . . . . . . . . . . . 11 71 4. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 4.1. Mandatory Metrics . . . . . . . . . . . . . . . . . . . . 12 73 4.2. DLEP Router session flow - Discovery case . . . . . . . . 12 74 4.3. DLEP Router session flow - Configured case . . . . . . . 13 75 4.4. DLEP Modem session flow . . . . . . . . . . . . . . . . . 13 76 4.5. Common Session Flow . . . . . . . . . . . . . . . . . . . 14 77 5. DLEP Message Processing . . . . . . . . . . . . . . . . . . . 15 78 5.1. DLEP Signal Header . . . . . . . . . . . . . . . . . . . 16 79 5.2. DLEP Generic Data Item . . . . . . . . . . . . . . . . . 16 80 6. DLEP Signals . . . . . . . . . . . . . . . . . . . . . . . . 17 81 6.1. Peer Discovery Signal . . . . . . . . . . . . . . . . . . 17 82 6.2. Peer Offer Signal . . . . . . . . . . . . . . . . . . . . 18 83 6.3. Peer Initialization Signal . . . . . . . . . . . . . . . 18 84 6.4. Peer Initialization ACK Signal . . . . . . . . . . . . . 19 85 6.5. Peer Update Signal . . . . . . . . . . . . . . . . . . . 21 86 6.6. Peer Update ACK Signal . . . . . . . . . . . . . . . . . 22 87 6.7. Peer Termination Signal . . . . . . . . . . . . . . . . . 23 88 6.8. Peer Termination ACK Signal . . . . . . . . . . . . . . . 24 89 6.9. Destination Up Signal . . . . . . . . . . . . . . . . . . 24 90 6.10. Destination Up ACK Signal . . . . . . . . . . . . . . . . 25 91 6.11. Destination Down Signal . . . . . . . . . . . . . . . . . 26 92 6.12. Destination Down ACK Signal . . . . . . . . . . . . . . . 26 93 6.13. Destination Update Signal . . . . . . . . . . . . . . . . 27 94 6.14. Heartbeat Signal . . . . . . . . . . . . . . . . . . . . 28 95 6.15. Link Characteristics Request Signal . . . . . . . . . . . 28 96 6.16. Link Characteristics ACK Signal . . . . . . . . . . . . . 29 97 7. DLEP Data Items . . . . . . . . . . . . . . . . . . . . . . . 30 98 7.1. DLEP Version . . . . . . . . . . . . . . . . . . . . . . 31 99 7.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . 32 100 7.3. IPv4 Connection Point . . . . . . . . . . . . . . . . . . 33 101 7.4. IPv6 Connection Point . . . . . . . . . . . . . . . . . . 34 102 7.5. Peer Type . . . . . . . . . . . . . . . . . . . . . . . . 35 103 7.6. Heartbeat Interval . . . . . . . . . . . . . . . . . . . 35 104 7.7. Extensions Supported . . . . . . . . . . . . . . . . . . 36 105 7.8. Experimental Definition . . . . . . . . . . . . . . . . . 36 106 7.9. MAC Address . . . . . . . . . . . . . . . . . . . . . . . 37 107 7.10. IPv4 Address . . . . . . . . . . . . . . . . . . . . . . 38 108 7.11. IPv6 Address . . . . . . . . . . . . . . . . . . . . . . 38 109 7.12. IPv4 Attached Subnet . . . . . . . . . . . . . . . . . . 39 110 7.13. IPv6 Attached Subnet . . . . . . . . . . . . . . . . . . 40 111 7.14. Maximum Data Rate (Receive) . . . . . . . . . . . . . . . 40 112 7.15. Maximum Data Rate (Transmit) . . . . . . . . . . . . . . 41 113 7.16. Current Data Rate (Receive) . . . . . . . . . . . . . . . 42 114 7.17. Current Data Rate (Transmit) . . . . . . . . . . . . . . 42 115 7.18. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 43 116 7.19. Resources (Receive) . . . . . . . . . . . . . . . . . . . 44 117 7.20. Resources (Transmit) . . . . . . . . . . . . . . . . . . 45 118 7.21. Relative Link Quality (Receive) . . . . . . . . . . . . . 45 119 7.22. Relative Link Quality (Transmit) . . . . . . . . . . . . 46 120 7.23. Link Characteristics ACK Timer . . . . . . . . . . . . . 46 121 8. Credit-Windowing . . . . . . . . . . . . . . . . . . . . . . 47 122 8.1. Credit-Windowing Signals . . . . . . . . . . . . . . . . 47 123 8.1.1. Destination Up Signal . . . . . . . . . . . . . . . . 48 124 8.1.2. Destination Up ACK Signal . . . . . . . . . . . . . . 48 125 8.1.3. Destination Update Signal . . . . . . . . . . . . . . 48 126 8.2. Credit-Windowing Data Items . . . . . . . . . . . . . . . 48 127 8.2.1. Credit Grant . . . . . . . . . . . . . . . . . . . . 49 128 8.2.2. Credit Window Status . . . . . . . . . . . . . . . . 50 129 8.2.3. Credit Request . . . . . . . . . . . . . . . . . . . 50 130 9. Security Considerations . . . . . . . . . . . . . . . . . . . 51 131 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 132 10.1. Registrations . . . . . . . . . . . . . . . . . . . . . 51 133 10.2. Expert Review: Evaluation Guidelines . . . . . . . . . . 52 134 10.3. Signal Type Registration . . . . . . . . . . . . . . . . 52 135 10.4. DLEP Data Item Registrations . . . . . . . . . . . . . . 53 136 10.5. DLEP Status Code Registrations . . . . . . . . . . . . . 54 137 10.6. DLEP Extensions Registrations . . . . . . . . . . . . . 54 138 10.7. DLEP Well-known Port . . . . . . . . . . . . . . . . . . 55 139 10.8. DLEP Multicast Address . . . . . . . . . . . . . . . . . 55 140 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 55 141 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 142 12.1. Normative References . . . . . . . . . . . . . . . . . . 55 143 12.2. Informative References . . . . . . . . . . . . . . . . . 55 144 Appendix A. Peer Level Signal Flows . . . . . . . . . . . . . . 55 145 A.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 55 146 A.2. Session Initialization . . . . . . . . . . . . . . . . . 56 147 A.3. Session Initialization - Refused . . . . . . . . . . . . 57 148 A.4. Router Changes IP Addresses . . . . . . . . . . . . . . . 57 149 A.5. Modem Changes Session-wide Metrics . . . . . . . . . . . 57 150 A.6. Router Terminates Session . . . . . . . . . . . . . . . . 58 151 A.7. Modem Terminates Session . . . . . . . . . . . . . . . . 58 152 A.8. Session Heartbeats . . . . . . . . . . . . . . . . . . . 59 153 A.9. Router Detects a Heartbeat timeout . . . . . . . . . . . 60 154 A.10. Modem Detects a Heartbeat timeout . . . . . . . . . . . . 61 155 Appendix B. Destination Specific Signal Flows . . . . . . . . . 61 156 B.1. Common Destination Signaling . . . . . . . . . . . . . . 61 157 B.2. Multicast Destination Signaling . . . . . . . . . . . . . 62 158 B.3. Link Characteristics Request . . . . . . . . . . . . . . 62 159 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63 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 6.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 6.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. 368 DLEP utilizes UDP multicast for single-hop discovery, and TCP for 369 transport of the control signals. Therefore, DLEP assumes that the 370 modem and router have topologically consistent IP addresses assigned. 371 It is recommended that DLEP implementations utilize IPv6 link-local 372 addresses to reduce the administrative burden of address assignment. 374 Destinations can be identified by either the router or the modem, and 375 represent a specific destination (e.g., an address) that exists on 376 the link(s) managed by the modem. A destination MUST contain a MAC 377 address, it MAY optionally include a Layer 3 address (or addresses). 378 Note that since a destination is a MAC address, the MAC could 379 reference a logical destination, as in a derived multicast MAC 380 address, as well as a physical device. As destinations are 381 discovered, DLEP routers and modems build an information base on 382 destinations accessible via the modem. 384 The DLEP signals concerning destinations thus become the way for 385 routers and modems to maintain, and notify each other about, an 386 information base representing the physical and logical (e.g., 387 multicast) destinations accessible via the modem device. The 388 information base would contain addressing information (i.e. MAC 389 address, and OPTIONALLY, Layer 3 addresses), link characteristics 390 (metrics), and OPTIONALLY, flow control information (credits). 392 DLEP assumes that any signal not understood by a receiver MUST result 393 in an error indication being sent to the originator, and also MUST 394 result in termination of the session between the DLEP peers. Any 395 data item that is not understood by a receiver MUST be ignored. 397 DLEP assumes that security on the session (e.g., authentication of 398 session partners, encryption of traffic, or both) is dealt with by 399 the underlying transport mechanism (e.g., by using a transport such 400 as TLS [RFC5246]). 402 This document specifies an implementation of the DLEP signals and 403 data items running over the TCP transport. It is assumed that DLEP 404 running over other transport mechanisms would be documented 405 separately. 407 3. Core Features and Optional Extensions 409 DLEP has a core set of signals and data items that MUST be processed 410 without error by an implementation in order to guarantee 411 interoperability and therefore make the implementation DLEP 412 compliant. This document defines the core set of signals and data 413 items, listing them as 'mandatory'. It should be noted that some 414 core signals and data items might not be used during the lifetime of 415 a single DLEP session, but a compliant implementation MUST support 416 them. 418 While this document represents the best efforts of the co-authors, 419 and the working group, to be functionally complete, it is recognized 420 that extensions to DLEP will in all likelihood be necessary as more 421 link types are utilized. To support future extension of DLEP, this 422 document describes an extension negotiation capability to be used 423 during session initialization via the Extensions Supported data item, 424 documented in Section 7.7 of this document. 426 All extensions are considered OPTIONAL. Only the DLEP functionality 427 listed as 'mandatory' is required by implementation in order to be 428 DLEP compliant. 430 This specification defines one extension, Credit windowing, exposed 431 via the Extensions Supported mechanism that implementations MAY 432 choose to implement, or to omit. 434 3.1. Negotiation of Optional Extensions 436 Optional extensions supported by an implementation MUST be declared 437 to potential DLEP peers using the Extensions Supported data item 438 (Section 7.7) during the session initialization sequence. Once both 439 peers have exchanged initialization signals, an implementation MUST 440 NOT emit any signal or data item associated with an optional 441 extension that was not specified in the received initialization 442 signal from its peer. 444 3.2. Protocol Extensions 446 If/when protocol extensions are required, they should be standardized 447 either as an update to this document, or as an additional stand-alone 448 specification. The requests for IANA-controlled registries in this 449 document contain sufficient reserved space, both in terms of DLEP 450 signals and DLEP data items, to accommodate future extensions to the 451 protocol and the data transferred. 453 3.3. Experimental Signals and Data Items 455 This document requests numbering space in both the DLEP signal and 456 data item registries for experimental items. The intent is to allow 457 for experimentation with new signals and/or data items, while still 458 retaining the documented DLEP behavior. If a given experiment proves 459 successful, it SHOULD be documented as an update to this document, or 460 as a stand-alone specification. 462 Use of the experimental signals, data items, or behaviors MUST be 463 announced by inclusion of an Experimental Definition data item 464 (Section 7.8) with a value agreed upon (a-priori) between the 465 participating peers. The exact mechanism for a-priori communication 466 of the experimental definition formats is beyond the scope of this 467 document. 469 Multiple Experimental Definition data items MAY appear in the Peer 470 Initialization/Peer Initialization ACK sequence. However, use of 471 multiple experiments in a single peer session could lead to 472 interoperability issues or unexpected results (e.g., redefinition of 473 experimental signals and/or data items), and is therefore 474 discouraged. It is left to implementations to determine the correct 475 processing path (e.g., a decision on whether to terminate the peer 476 session, or to establish a precedence of the conflicting definitions) 477 if such conflicts arise. 479 4. Metrics 481 DLEP includes the ability for the router and modem to communicate 482 metrics that reflect the characteristics (e.g., datarate, latency) of 483 the variable-quality link in use. DLEP does NOT specify how a given 484 metric value is to be calculated, rather, the protocol assumes that 485 metrics have been calculated with a 'best effort', incorporating all 486 pertinent data that is available to the modem device. 488 As mentioned in the introduction section of this document, DLEP 489 allows for metrics to be sent within two contexts - metrics for a 490 specific destination within the network (e.g., a specific router), 491 and 'modem-wide' (those that apply to all destinations accessed via 492 the modem). Most metrics can be further subdivided into transmit and 493 receive metrics. Metrics supplied on DLEP Peer signals are, by 494 definition, modem-wide; metrics supplied on Destination signals are, 495 by definition, used for the specific logical destination only. 497 DLEP modem implementations MUST announce all supported metric items, 498 and provide default values for those metrics, in the Peer 499 Initialization ACK signal (Section 6.4). In order to introduce a new 500 metric type, DLEP modem implementations MUST terminate the session 501 with the router (via the Peer Terminate signal (Section 6.7)), and 502 re-establish the session. 504 It is left to implementations to choose sensible default values based 505 on their specific characteristics. Modems having static (non- 506 changing) link metric characteristics MAY report metrics only once 507 for a given destination (or once on a modem-wide basis, if all 508 connections via the modem are of this static nature). 510 The approach of allowing for different contexts for metric data 511 increases both the flexibility and the complexity of using metric 512 data. This document details the mechanism whereby the data is 513 transmitted, however, the specific algorithms (precedence, etc.) for 514 utilizing the dual-context metrics is out of scope and not addressed 515 by this document. 517 4.1. Mandatory Metrics 519 As mentioned above, DLEP modem implementations MUST announce all 520 supported metric items during session initialization. However, an 521 implementation MUST include the following list of metrics: 523 o Maximum Data Rate (Receive) (Section 7.14) 525 o Maximum Data Rate (Transmit) (Section 7.15) 527 o Current Data Rate (Receive) (Section 7.16) 529 o Current Data Rate (Transmit) (Section 7.17) 531 o Latency (Section 7.18) 533 4.2. DLEP Router session flow - Discovery case 535 If the DLEP router implementation is utilizing the optional discovery 536 mechanism, then the implementation will initialize a UDP socket, 537 binding it to an arbitrary port. This UDP socket is used to send the 538 Peer Discovery signal (Section 6.1) to the DLEP link-local multicast 539 address and port (TBD). The implementation then waits on receipt of 540 a Peer Offer signal (Section 6.2), which MAY contain the unicast 541 address and port for TCP-based communication with a DLEP modem, via 542 the IPv4 Connection Point data item (Section 7.3) or the IPv6 543 Connection Point data item (Section 7.4). The Peer Offer signal MAY 544 contain multiple IP Connection Point data items. If more than one IP 545 Connection Point data items is in the Peer Offer, router 546 implementations MAY use their own heuristics to determine the best 547 address/port combination. If no IP Connection Point data items are 548 included in the Peer Offer signal, the receiver MUST use the origin 549 address of the signal as the IP address, and the DLEP well-known port 550 number (Section 10.7) to establish the TCP connection. At this 551 point, the router implementation MAY either destroy the UDP socket, 552 or continue to issue Peer Discovery signals to the link-local 553 address/port combination. In either case, the TCP session 554 initialization occurs as in the configured case. 556 4.3. DLEP Router session flow - Configured case 558 When a DLEP router implementation has the address and port 559 information for a TCP connection to a modem (obtained either via 560 configuration or via the discovery process described above), the 561 router will initialize and bind a TCP socket. This socket is used to 562 connect to the DLEP modem software. After a successful TCP connect, 563 the router implementation MUST issue a Peer Initialization signal 564 (Section 6.3) to the DLEP modem. After sending the Peer 565 Initialization, the router implementation MUST wait for receipt of a 566 Peer Initialization ACK signal (Section 6.4) from the modem. Receipt 567 of the Peer Initialization ACK signal containing a Status data item 568 (Section 7.2) with value 'Success', indicates that the modem has 569 received and processed the Peer Initialization, and the session MUST 570 transition to the 'in session' state. At this point, signals 571 regarding destinations in the network, and/or Peer Update signals 572 (Section 6.5), can flow on the DLEP session between modem and router, 573 and Heartbeat signals can begin to flow, if Heartbeats are used. The 574 'in session' state is maintained until one of the following 575 conditions occur: 577 o The session is explicitly terminated (using Peer Termination), or 579 o The session times out, based on supplied timeout values. 581 4.4. DLEP Modem session flow 583 DLEP modem implementations MUST support the discovery mechanism. 584 Therefore, the normal flow is as follows: 586 The implementation will initialize a UDP socket, binding that socket 587 to the DLEP link-local multicast address (TBD) and the DLEP well- 588 known port number (also TBD). The implementation will then 589 initialize a TCP socket, on a unicast address and port. This socket 590 is used to listen for incoming TCP connection requests. 592 When the modem implementation receives a Peer Discovery signal 593 (Section 6.1) on the UDP socket, it responds by issuing a Peer Offer 594 signal (Section 6.2) to the sender of the Peer Discovery signal. The 595 Peer Offer signal MAY contain the unicast address and port of the 596 listening TCP socket, as described above. A DLEP modem 597 implementation MAY respond with ALL address/port combinations that 598 have an active TCP listen posted. Anything other than Peer Discovery 599 signals received on the UDP socket MUST be silently dropped. 601 When the DLEP modem implementation accepts a connection via TCP, it 602 MUST wait for receipt of a Peer Initialization signal (Section 6.3), 603 sent by the router. Upon receipt and successful parsing of a Peer 604 Initialization signal, the modem MUST respond with a Peer 605 Initialization ACK signal (Section 6.4). The Peer Initialization ACK 606 signal MUST contain metric data items for ALL supported metrics. If 607 an additional metric is to be introduced, the DLEP session between 608 router and modem MUST be terminated and restarted, and the new metric 609 described in a Peer Initialization ACK signal. Once the Peer 610 Initialization signal (Section 6.3) and Peer Initialization ACK 611 signal (Section 6.4) have been exchanged, the session is transitioned 612 to the 'in session' state. As in the router case, when the 'in 613 session' state is reached, signals regarding destinations in the 614 network, and/or Peer Update signals (Section 6.5), can flow on the 615 DLEP session between modem and router, and Heartbeat signals can 616 begin to flow, if Heartbeats are used. The 'in session' state 617 persists until the session is explicitly terminated (using Peer 618 Termination), or it times out (based on timeout values). 620 4.5. Common Session Flow 622 In order to maintain the session between router and modem, periodic 623 Heartbeat signals (Section 6.14) MAY be exchanged. These signals are 624 intended to keep the session alive, and to verify bidirectional 625 connectivity between the two participants. If [Heartbeat 626 signals]#(sig_heartbeat) are exchanged, they do not begin until the 627 DLEP peer session has entered the 'in session' state. Each DLEP peer 628 is responsible for the creation of Heartbeat signals (Section 6.14). 629 Receipt of any DLEP signal SHOULD reset the heartbeat interval timer 630 (e.g., valid DLEP signals take the place of, and obviate the need 631 for, Heartbeat signals). 633 DLEP also provides a Peer Update signal (Section 6.5), intended to 634 communicate some change in status (e.g., a change of layer 3 address 635 parameters, or a modem-wide link change). 637 In addition to the local (Peer level) signals above, the participants 638 will transmit DLEP signals concerning destinations in the network. 639 These signals trigger creation/maintenance/deletion of destinations 640 in the information base of the recipient. For example, a modem will 641 inform its attached router of the presence of a new destination via 642 the Destination Up signal (Section 6.9). Receipt of a Destination Up 643 causes the router to allocate the necessary resources, creating an 644 entry in the information base with the specifics (i.e. MAC Address, 645 Latency, Data Rate, etc.) of the destination. The loss of a 646 destination is communicated via the Destination Down signal 647 (Section 6.11), and changes in status to the destination (e.g., 648 varying link quality, or addressing changes) are communicated via the 649 Destination Update signal (Section 6.13). The information on a given 650 destination will persist in the router's information base until (1) a 651 Destination Down signal is received, indicating that the modem has 652 lost contact with the remote node, or (2) the router/modem session 653 terminates, indicating that the router has lost contact with its own 654 local modem. 656 Metrics can be expressed within the context of a specific destination 657 via the Destination Update signal, or on a modem-wide basis via the 658 Peer Update signal. In cases where metrics are provided at peer 659 level, the receiver MUST propagate the metrics to all destinations in 660 its information base that are accessed via the originator. A DLEP 661 participant MAY send metrics both in a router/modem session context 662 (via the Peer Update signal) and a specific destination context (via 663 Destination Update) at any time. The heuristics for applying 664 received metrics is left to implementations. 666 In addition to receiving metrics about the link, DLEP provides a 667 signal allowing a router to request a different datarate, or latency, 668 from the modem. This signal is referred to as the Link 669 Characteristics Request signal (Section 6.15), and gives the router 670 the ability to deal with requisite increases (or decreases) of 671 allocated datarate/latency in demand-based schemes in a more 672 deterministic manner. 674 5. DLEP Message Processing 676 Communication between DLEP peers consists of a bidirectional stream 677 of signals, each signal consisting of a signal header and an 678 unordered list of data items. Both signal headers and data items are 679 encoded as TLV (Type-Length-Value) structures. In this document, the 680 data items following the signal header are described as being 681 'contained in' the signal. 683 All integer values in all TLV structures MUST be in network byte- 684 order. 686 There is no restriction on the order of data items following a 687 signal, and the multiplicity of duplicate data items is defined by 688 the definition of the signal declared by the type in the signal 689 header. 691 If an unrecognized, or unexpected signal is received, or a received 692 signal contains unrecognized, invalid or disallowed duplicate data 693 items, the receiving peer MUST terminate the session by issuing a 694 Peer Termination signal (Section 6.7) with a Status data item 695 (Section 7.2) containing the most relevant status code, and then 696 close the TCP connection. 698 5.1. DLEP Signal Header 700 The DLEP signal header contains the following fields: 702 0 1 2 703 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Signal Type | Length | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 Figure 3: DLEP Signal Header 710 Signal Type: One of the DLEP Signal Type values defined in this 711 document. 713 Length: The length, expressed as a 16-bit unsigned integer, of all 714 of the DLEP data items associated with this signal. This length 715 does not include the length of the header itself 717 The DLEP Signal Header is immediately followed bu one or more DLEP 718 data items, encoded in TLVs, as defined in this document. 720 5.2. DLEP Generic Data Item 722 All DLEP data items contain the following fields: 724 0 1 2 3 725 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 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | Data Item Type| Length | Value... | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 Figure 4: DLEP Generic Data Item 732 Data Item Type: An 8-bit unsigned integer field specifying the data 733 item being sent. 735 Length: The length, expressed as an 8-bit unsigned integer, of the 736 value field of the data item. 738 Value: A field of length which contains data specific to a 739 particular data item. 741 6. DLEP Signals 743 As mentioned above, all DLEP signals begin with the DLEP signal 744 header structure. Therefore, in the following descriptions of 745 specific signals, this header structure is assumed, and will not be 746 replicated. 748 Following is the set of MANDATORY signals that must be recognized by 749 a DLEP compliant implementation. As mentioned before, not all 750 signals may be used during a session, but an implementation MUST 751 correctly process these signals when received. 753 The mandatory DLEP signals are: 755 +---------+-------------------------------+---------------+ 756 | Signal | Description | Section | 757 +---------+-------------------------------+---------------+ 758 | TBD | Peer Discovery | Section 6.1 | 759 | TBD | Peer Offer | Section 6.2 | 760 | TBD | Peer Initialization | Section 6.3 | 761 | TBD | Peer Initialization ACK | Section 6.4 | 762 | TBD | Peer Update | Section 6.5 | 763 | TBD | Peer Update ACK | Section 6.6 | 764 | TBD | Peer Termination | Section 6.7 | 765 | TBD | Peer Termination ACK | Section 6.8 | 766 | TBD | Destination Up | Section 6.9 | 767 | TBD | Destination Up ACK | Section 6.10 | 768 | TBD | Destination Down | Section 6.11 | 769 | TBD | Destination Down ACK | Section 6.12 | 770 | TBD | Destination Update | Section 6.13 | 771 | TBD | Heartbeat | Section 6.14 | 772 | TBD | Link Characteristics Request | Section 6.15 | 773 | TBD | Link Characteristics ACK | Section 6.16 | 774 +---------+-------------------------------+---------------+ 776 6.1. Peer Discovery Signal 778 A Peer Discovery signal SHOULD be sent by a router to discover DLEP 779 modems in the network. The Peer Offer signal (Section 6.2) is 780 required to complete the discovery process. Implementations MAY 781 implement their own retry heuristics in cases where it is determined 782 the Peer Discovery signal has timed out. 784 To construct a Peer Discovery signal, the Signal Type value in the 785 signal header is set to DLEP_PEER_DISCOVERY (value TBD). 787 The Peer Discovery signal MUST contain the following data item: 789 o DLEP Version (Section 7.1) 791 The Peer Discovery signal MAY contain the following data item: 793 o Peer Type (Section 7.5) 795 6.2. Peer Offer Signal 797 A Peer Offer signal MUST be sent by a DLEP modem in response to a 798 valid Peer Discovery signal (Section 6.1). 800 The Peer Offer signal MUST be sent to the unicast address of the 801 originator of the Peer Discovery signal. 803 To construct a Peer Offer signal, the Signal Type value in the signal 804 header is set to DLEP_PEER_OFFER (value TBD). 806 The Peer Offer signal MUST contain the following data item: 808 o DLEP Version (Section 7.1) 810 The Peer Offer signal MAY contain the following data item: 812 o Peer Type (Section 7.5) 814 The Peer Offer signal MAY contain one or more of any of the following 815 data items, with different values: 817 o IPv4 Connection Point (Section 7.3) 819 o IPv6 Connection Point (Section 7.4) 821 The IP Connection Point data items indicate the unicast address the 822 receiver of Peer Offer MUST use when connecting the DLEP TCP session. 823 If multiple IP Connection Point data items are present in the Peer 824 Offer signal, implementations MAY use their own heuristics to select 825 the address to connect to. If no IP Connection Point data items are 826 included in the Peer Offer signal, the receiver MUST use the origin 827 address of the signal as the IP address, and the DLEP well-known port 828 number (Section 10.7) to establish the TCP connection. 830 6.3. Peer Initialization Signal 832 A Peer Initialization signal MUST be sent by a router as the first 833 signal of the DLEP TCP session. It is sent by the router after a TCP 834 connect to an address/port combination that was obtained either via 835 receipt of a Peer Offer, or from a-priori configuration. 837 If any optional extensions are supported by the implementation, they 838 MUST be enumerated in the Extensions Supported data item. If an 839 Extensions Supported data item does NOT exist in a Peer 840 Initialization signal, the receiver of the signal MUST conclude that 841 there is NO support for extensions in the sender. 843 If any experimental signals or data items are used by the 844 implementation, they MUST be enumerated in one or more Experimental 845 Definition data items. If there are no Experimental Definition data 846 items in a Peer Initialization signal, the receiver of the signal 847 MUST conclude that NO experimental definitions are in use by the 848 sender. 850 To construct a Peer Initialization signal, the Signal Type value in 851 the signal header is set to DLEP_PEER_INITIALIZATION (value TBD). 853 The Peer Initialization signal MUST contain one of each of the 854 following data items: 856 o DLEP Version (Section 7.1) 858 o Heartbeat Interval (Section 7.6) 860 The Peer Initialization signal MAY contain one of each of the 861 following data items: 863 o Peer Type (Section 7.5) 865 o Extensions Supported (Section 7.7) 867 The Peer Initialization signal MAY contain one or more of any of the 868 following data items, with different values: 870 o Experimental Definition (Section 7.8) 872 A Peer Initialization signal MUST be acknowledged by the receiver 873 issuing a Peer Initialization ACK signal (Section 6.4). 875 6.4. Peer Initialization ACK Signal 877 A Peer Initialization ACK signal MUST be sent in response to a 878 received Peer Initialization signal (Section 6.3). The Peer 879 Initialization ACK signal completes the DLEP session establishment; 880 the sender of the signal should transition to an 'in- session' state 881 when the signal is sent, and the receiver should transition to the 882 'in-session' state upon receipt (and successful parsing) of an 883 acceptable Peer Initialization ACK signal. 885 All supported metric data items MUST be included in the Peer 886 Initialization ACK signal, with default values to be used on a 887 'modem-wide' basis. This can be viewed as the modem 'declaring' all 888 supported metrics at DLEP session initialization. Receipt of any 889 DLEP signal containing a metric data item NOT included in the Peer 890 Initialization ACK signal MUST be treated as an error, resulting in 891 the termination of the DLEP session between router and modem. 893 If any optional extensions are supported by the modem, they MUST be 894 enumerated in the Extensions Supported data item. If an Extensions 895 Supported data item does NOT exist in a Peer Initialization ACK 896 signal, the receiver of the signal MUST conclude that there is NO 897 support for extensions in the sender. 899 If any experimental signals or data items are used by the 900 implementation, they MUST be enumerated in one or more Experimental 901 Definition data items. If there are no Experimental Definition data 902 items in a Peer Initialization ACK signal, the receiver of the signal 903 MUST conclude that NO experimental definitions are in use by the 904 sender. 906 After the Peer Initialization/Peer Initialization ACK signals have 907 been successfully exchanged, implementations MUST only utilize 908 extensions and experimental definitions that are supported by BOTH 909 peers. 911 To construct a Peer Initialization ACK signal, the Signal Type value 912 in the signal header is set to DLEP_PEER_INIT_ACK (value TBD). 914 The Peer Initialization ACK signal MUST contain one of each of the 915 following data items: 917 o DLEP Version (Section 7.1) 919 o Heartbeat Interval (Section 7.6) 921 o Maximum Data Rate (Receive) (Section 7.14) 923 o Maximum Data Rate (Transmit) (Section 7.15) 925 o Current Data Rate (Receive) (Section 7.16) 927 o Current Data Rate (Transmit) (Section 7.17) 929 o Latency (Section 7.18) 930 The Peer Initialization ACK signal MUST contain one of each of the 931 following data items, if the data item will be used during the 932 lifetime of the session: 934 o Resources (Receive) (Section 7.19) 936 o Resources (Transmit) (Section 7.20) 938 o Relative Link Quality (Receive) (Section 7.21) 940 o Relative Link Quality (Transmit) (Section 7.22) 942 The Peer Initialization ACK signal MAY contain one of each of the 943 following data items: 945 o Status (Section 7.2) 947 o Peer Type (Section 7.5) 949 o Extensions Supported (Section 7.7) 951 The Peer Initialization ACK signal MAY contain one or more of any of 952 the following data items, with different values: 954 o Experimental Definition (Section 7.8) 956 6.5. Peer Update Signal 958 A Peer Update signal MAY be sent by a DLEP peer to indicate local 959 Layer 3 address changes, or metric changes on a modem-wide basis. 960 For example, addition of an IPv4 address to the router MAY prompt a 961 Peer Update signal to its attached DLEP modems. Also, for example, a 962 modem that changes its Maximum Data Rate (Receive) for all 963 destinations MAY reflect that change via a Peer Update signal to its 964 attached router(s). 966 Concerning Layer 3 addresses, if the modem is capable of 967 understanding and forwarding this information (via proprietary 968 mechanisms), the address update would prompt any remote DLEP modems 969 (DLEP-enabled modems in a remote node) to issue a Destination Update 970 signal (Section 6.13) to their local routers with the new (or 971 deleted) addresses. Modems that do not track Layer 3 addresses 972 SHOULD silently parse and ignore the Peer Update signal. Modems that 973 track Layer 3 addresses MUST acknowledge the Peer Update with a Peer 974 Update ACK signal (Section 6.6). 976 If metrics are supplied with the Peer Update signal (e.g., Maximum 977 Data Rate), these metrics are considered to be modem-wide, and 978 therefore MUST be applied to all destinations in the information base 979 associated with the router/modem session. 981 Supporting implementations are free to employ heuristics to 982 retransmit Peer Update signals. The sending of Peer Update signals 983 for Layer 3 address changes SHOULD cease when either participant 984 (router or modem) determines that the other implementation does NOT 985 support Layer 3 address tracking. 987 To construct a Peer Update signal, the Signal Type value in the 988 signal header is set to DLEP_PEER_UPDATE (value TBD). 990 The Peer Update signal MAY contain one of each of the following data 991 items: 993 o Maximum Data Rate (Receive) (Section 7.14) 995 o Maximum Data Rate (Transmit) (Section 7.15) 997 o Current Data Rate (Receive) (Section 7.16) 999 o Current Data Rate (Transmit) (Section 7.17) 1001 o Latency (Section 7.18) 1003 o Resources (Receive) (Section 7.19) 1005 o Resources (Transmit) (Section 7.20) 1007 o Relative Link Quality (Receive) (Section 7.21) 1009 o Relative Link Quality (Transmit) (Section 7.22) 1011 The Peer Update signal MAY contain one or more of the following data 1012 items, with different values: 1014 o IPv4 Address (Section 7.10) 1016 o IPv6 Address (Section 7.11) 1018 A Peer Update signal MUST be acknowledged by the receiver issuing a 1019 Peer Update ACK signal (Section 6.6). 1021 6.6. Peer Update ACK Signal 1023 A Peer Update ACK signal MUST be sent by implementations to indicate 1024 whether a Peer Update signal (Section 6.5) was successfully received. 1026 To construct a Peer Update ACK signal, the Signal Type value in the 1027 signal header is set to DLEP_PEER_UPDATE_ACK (value TBD). 1029 The Peer Update ACK signal MAY contain one of each of the following 1030 data items: 1032 o Status (Section 7.2) 1034 A receiver of a Peer Update ACK signal without a Status data item 1035 MUST behave as if a Status data item with code 'Success' had been 1036 received. 1038 6.7. Peer Termination Signal 1040 A Peer Termination signal MUST be sent by a DLEP participant when the 1041 router/modem session needs to be terminated. Implementations 1042 receiving a Peer Termination signal MUST send a Peer Termination ACK 1043 signal (Section 6.8) to confirm the termination process. 1045 The receiver of a Peer Termination signal MUST release all resources 1046 allocated for the router/modem session, and MUST eliminate all 1047 destinations in the information base accessible via the router/modem 1048 pair represented by the session. Router and modem state machines are 1049 returned to the 'discovery' state. No Destination Down signals 1050 (Section 6.11) are sent. 1052 The sender of a Peer Termination signal is free to define its 1053 heuristics in event of a timeout. It may resend the Peer Termination 1054 or free resources and return to the 'discovery' state. 1056 To construct a Peer Termination signal, the Signal Type value in the 1057 signal header is set to DLEP_PEER_TERMINATION (value TBD). 1059 The Peer Termination signal MAY contain one of each of the following 1060 data items: 1062 o Status (Section 7.2) 1064 A receiver of a Peer Termination signal without a Status data item 1065 MUST behave as if a Status data item with status code 'Success', 1066 implying graceful termination, had been received. 1068 A Peer Termination signal MUST be acknowledged by the receiver 1069 issuing a Peer Termination ACK signal (Section 6.8). 1071 6.8. Peer Termination ACK Signal 1073 A Peer Termination ACK signal MUST be sent by a DLEP peer in response 1074 to a received Peer Termination signal (Section 6.7). Receipt of a 1075 Peer Termination ACK signal completes the teardown of the router/ 1076 modem session. 1078 To construct a Peer Termination ACK signal, the Signal Type value in 1079 the signal header is set to DLEP_PEER_TERMINATION_ACK (value TBD). 1081 The Peer Termination ACK signal MAY contain one of each of the 1082 following data items: 1084 o Status (Section 7.2) 1086 A receiver of a Peer Termination ACK signal without a Status data 1087 item MUST behave as if a Status data item with status code 'Success', 1088 implying graceful termination, had been received. 1090 6.9. Destination Up Signal 1092 A Destination Up signal can be sent either by the modem, to indicate 1093 that a new remote node has been detected, or by the router, to 1094 indicate the presence of a new logical destination (e.g., a Multicast 1095 group) in the network. 1097 A Destination Up signal MUST be acknowledged by the receiver issuing 1098 a Destination Up ACK signal (Section 6.10). The sender of the 1099 Destination Up signal is free to define its retry heuristics in event 1100 of a timeout. When a Destination Up signal is received and 1101 successfully processed, the receiver should add knowledge of the new 1102 destination to its information base, indicating that the destination 1103 is accessible via the modem/router pair. 1105 To construct a Destination Up signal, the Signal Type value in the 1106 signal header is set to DLEP_DESTINATION_UP (value TBD). 1108 The Destination Up signal MUST contain one of each of the following 1109 data items: 1111 o MAC Address (Section 7.9) 1113 The Destination Up signal MAY contain one of each of the following 1114 data items: 1116 o Maximum Data Rate (Receive) (Section 7.14) 1118 o Maximum Data Rate (Transmit) (Section 7.15) 1119 o Current Data Rate (Receive) (Section 7.16) 1121 o Current Data Rate (Transmit) (Section 7.17) 1123 o Latency (Section 7.18) 1125 o Resources (Receive) (Section 7.19) 1127 o Resources (Transmit) (Section 7.20) 1129 o Relative Link Quality (Receive) (Section 7.21) 1131 o Relative Link Quality (Transmit) (Section 7.22) 1133 The Destination Up signal MAY contain one or more of the following 1134 data items, with different values: 1136 o IPv4 Address (Section 7.10) 1138 o IPv6 Address (Section 7.11) 1140 o IPv4 Attached Subnet (Section 7.12) 1142 o IPv6 Attached Subnet (Section 7.13) 1144 If the sender has IPv4 and/or IPv6 address information for a 1145 destination it SHOULD include the relevant data items in the 1146 Destination Up signal, reducing the need for the receiver to probe 1147 for any address. 1149 6.10. Destination Up ACK Signal 1151 A DLEP participant MUST send a Destination Up ACK signal to indicate 1152 whether a Destination Up signal (Section 6.9) was successfully 1153 processed. 1155 To construct a Destination Up ACK signal, the Signal Type value in 1156 the signal header is set to DLEP_DESTINATION_UP_ACK (value TBD). 1158 The Destination Up ACK signal MUST contain one of each of the 1159 following data items: 1161 o MAC Address (Section 7.9) 1163 The Destination Up ACK signal MAY contain one of each of the 1164 following data items: 1166 o Status (Section 7.2) 1167 A receiver of a Destination Up ACK signal without a Status data item 1168 MUST behave as if a Status data item with status code 'Success' had 1169 been received. 1171 6.11. Destination Down Signal 1173 A DLEP peer MUST send a Destination Down signal to report when a 1174 destination (a remote node or a multicast group) is no longer 1175 reachable. A Destination Down ACK signal (Section 6.12) MUST be sent 1176 by the recipient of a Destination Down signal to confirm that the 1177 relevant data has been removed from the information base. The sender 1178 of the Destination Down signal is free to define its retry heuristics 1179 in event of a timeout. 1181 To construct a Destination Down signal, the Signal Type value in the 1182 signal header is set to DLEP_DESTINATION_DOWN (value TBD). 1184 The Destination Down signal MUST contain one of each of the following 1185 data items: 1187 o MAC Address (Section 7.9) 1189 6.12. Destination Down ACK Signal 1191 A DLEP participant MUST send a Destination Down ACK signal to 1192 indicate whether a received Destination Down signal (Section 6.11) 1193 was successfully processed. If successfully processed, the sender of 1194 the ACK MUST have removed all entries in the information base that 1195 pertain to the referenced destination. 1197 To construct a Destination Down ACK signal, the Signal Type value in 1198 the signal header is set to DLEP_DESTINATION_DOWN_ACK (value TBD). 1200 The Destination Down ACK signal MUST contain one of each of the 1201 following data items: 1203 o MAC Address (Section 7.9) 1205 The Destination Down ACK signal MAY contain one of each of the 1206 following data items: 1208 o Status (Section 7.2) 1210 A receiver of a Destination Down ACK signal without a Status data 1211 item MUST behave as if a Status data item with status code 'Success' 1212 had been received. 1214 6.13. Destination Update Signal 1216 A DLEP participant SHOULD send the Destination Update signal when it 1217 detects some change in the information base for a given destination 1218 (remote node or multicast group). Some examples of changes that 1219 would prompt a Destination Update signal are: 1221 o Change in link metrics (e.g., Data Rates) 1223 o Layer 3 addressing change 1225 To construct a Destination Update signal, the Signal Type value in 1226 the signal header is set to DLEP_DESTINATION_UPDATE (value TBD). 1228 The Destination Update signal MUST contain one of each of the 1229 following data items: 1231 o MAC Address (Section 7.9) 1233 The Destination Update signal MAY contain one of each of the 1234 following data items: 1236 o Maximum Data Rate (Receive) (Section 7.14) 1238 o Maximum Data Rate (Transmit) (Section 7.15) 1240 o Current Data Rate (Receive) (Section 7.16) 1242 o Current Data Rate (Transmit) (Section 7.17) 1244 o Latency (Section 7.18) 1246 o Resources (Receive) (Section 7.19) 1248 o Resources (Transmit) (Section 7.20) 1250 o Relative Link Quality (Receive) (Section 7.21) 1252 o Relative Link Quality (Transmit) (Section 7.22) 1254 The Destination Update signal MAY contain one or more of the 1255 following data items, with different values: 1257 o IPv4 Address (Section 7.10) 1259 o IPv6 Address (Section 7.11) 1261 o IPv4 Attached Subnet (Section 7.12) 1262 o IPv6 Attached Subnet (Section 7.13) 1264 6.14. Heartbeat Signal 1266 A Heartbeat signal SHOULD be sent by a DLEP participant every N 1267 seconds, where N is defined in the Heartbeat Interval data item of 1268 the Peer Initialization signal (Section 6.3) or Peer Initialization 1269 ACK signal (Section 6.4). Note that implementations setting the 1270 Heartbeat Interval to 0 effectively set the interval to an infinite 1271 value, therefore, in those cases, this signal SHOULD NOT be sent. 1273 The signal is used by participants to detect when a DLEP session 1274 partner (either the modem or the router) is no longer communicating. 1275 Participants SHOULD allow two (2) heartbeat intervals to expire with 1276 no traffic on the router/modem session before initiating DLEP session 1277 termination procedures. 1279 To construct a Heartbeat signal, the Signal Type value in the signal 1280 header is set to DLEP_PEER_HEARTBEAT (value TBD). 1282 There are no valid data items for the Heartbeat signal. 1284 6.15. Link Characteristics Request Signal 1286 The Link Characteristics Request signal MAY be sent by the router to 1287 request that the modem initiate changes for specific characteristics 1288 of the link. The request can reference either a real destination 1289 (e.g., a remote node), or a logical destination (e.g., a multicast 1290 group) within the network. 1292 The Link Characteristics Request signal contains either a Current 1293 Data Rate (CDRR or CDRT) data item to request a different datarate 1294 than what is currently allocated, a Latency data item to request that 1295 traffic delay on the link not exceed the specified value, or both. A 1296 Link Characteristics ACK signal (Section 6.16) is required to 1297 complete the request. Issuing a Link Characteristics Request with 1298 ONLY the MAC Address data item is a mechanism a peer MAY use to 1299 request metrics (via the Link Characteristics ACK) from its partner. 1301 The sender of a Link Characteristics Request signal MAY attach a 1302 timer to the request using the Link Characteristics ACK Timer data 1303 item. If a Link Characteristics ACK signal is received after the 1304 timer expires, the sender MUST NOT assume that the request succeeded. 1305 Implementations are free to define their retry heuristics in event of 1306 a timeout. 1308 To construct a Link Characteristics Request signal, the Signal Type 1309 value in the signal header is set to DLEP_LINK_CHAR_REQ (value TBD). 1311 The Link Characteristics Request signal MUST contain one of each of 1312 the following data items: 1314 o MAC Address (Section 7.9) 1316 The Link Characteristics Request signal MAY contain one of each of 1317 the following data items: 1319 o Link Characteristics ACK Timer (Section 7.23) 1321 o Current Data Rate (Receive) (Section 7.16) 1323 o Current Data Rate (Transmit) (Section 7.17) 1325 o Latency (Section 7.18) 1327 6.16. Link Characteristics ACK Signal 1329 A DLEP participant MUST send a Link Characteristics ACK signal to 1330 indicate whether a received Link Characteristics Request signal 1331 (Section 6.15) was successfully processed. The Link Characteristics 1332 ACK signal SHOULD contain a complete set of metric data items, and 1333 MUST contain a full set (i.e. those declared in the Peer 1334 Initialization ACK signal (Section 6.4)), if metrics were requested 1335 by only including a MAC address data item. It MUST contain the same 1336 metric types as the request. The values in the metric data items in 1337 the Link Characteristics ACK signal MUST reflect the link 1338 characteristics after the request has been processed. 1340 If an implementation is not able to alter the characteristics of the 1341 link in the manner requested, then a Status data item with status 1342 code 'Request Denied' MUST be added to the signal. 1344 To construct a Link Characteristics Request ACK signal, the Signal 1345 Type value in the signal header is set to DLEP_LINK_CHAR_ACK (value 1346 TBD). 1348 The Link Characteristics ACK signal MUST contain one of each of the 1349 following data items: 1351 o MAC Address (Section 7.9) 1353 The Link Characteristics ACK signal SHOULD contain one of each of the 1354 following data items: 1356 o Maximum Data Rate (Receive) (Section 7.14) 1358 o Maximum Data Rate (Transmit) (Section 7.15) 1359 o Current Data Rate (Receive) (Section 7.16) 1361 o Current Data Rate (Transmit) (Section 7.17) 1363 o Latency (Section 7.18) 1365 The Link Characteristics ACK signal MAY contain one of each of the 1366 following data items: 1368 o Resources (Receive) (Section 7.19) 1370 o Resources (Transmit) (Section 7.20) 1372 o Relative Link Quality (Receive) (Section 7.21) 1374 o Relative Link Quality (Transmit) (Section 7.22) 1376 o Status (Section 7.2) 1378 A receiver of a Link Characteristics ACK signal without a Status data 1379 item MUST behave as if a Status data item with status code 'Success' 1380 had been received. 1382 7. DLEP Data Items 1384 Following is the list of MANDATORY data items that must be recognized 1385 by a DLEP compliant implementation. As mentioned before, not all 1386 data items need be used during a session, but an implementation MUST 1387 correctly process these data items when correctly associated with a 1388 signal. 1390 The DLEP data items are: 1392 +------------+--------------------------------------+---------------+ 1393 | Data Item | Description | Section | 1394 +------------+--------------------------------------+---------------+ 1395 | TBD | DLEP Version | Section 7.1 | 1396 | TBD | Status | Section 7.2 | 1397 | TBD | IPv4 Connection Point | Section 7.3 | 1398 | TBD | IPv6 Connection Point | Section 7.4 | 1399 | TBD | Peer Type | Section 7.5 | 1400 | TBD | Heartbeat Interval | Section 7.6 | 1401 | TBD | Extensions Supported | Section 7.7 | 1402 | TBD | Experimental Definition | Section 7.8 | 1403 | TBD | MAC Address | Section 7.9 | 1404 | TBD | IPv4 Address | Section 7.10 | 1405 | TBD | IPv6 Address | Section 7.11 | 1406 | TBD | IPv4 Attached Subnet | Section 7.12 | 1407 | TBD | IPv6 Attached Subnet | Section 7.13 | 1408 | TBD | Maximum Data Rate (Receive) MDRR) | Section 7.14 | 1409 | TBD | Maximum Data Rate (Transmit) (MDRT) | Section 7.15 | 1410 | TBD | Current Data Rate (Receive) (CDRR) | Section 7.16 | 1411 | TBD | Current Data Rate (Transmit) (CDRT) | Section 7.17 | 1412 | TBD | Latency | Section 7.18 | 1413 | TBD | Resources (Receive) (RESR) | Section 7.19 | 1414 | TBD | Resources (Transmit) (REST) | Section 7.20 | 1415 | TBD | Relative Link Quality (Receive) | Section 7.21 | 1416 | | (RLQR) | | 1417 | TBD | Relative Link Quality (Transmit) | Section 7.22 | 1418 | | (RLQT) | | 1419 | TBD | Link Characteristics ACK Timer | Section 7.23 | 1420 +------------+--------------------------------------+---------------+ 1422 7.1. DLEP Version 1424 The DLEP Version data item MUST appear in the Peer Discovery 1425 (Section 6.1), Peer Offer (Section 6.2), Peer Initialization 1426 (Section 6.3) and Peer Initialization ACK (Section 6.4) signals The 1427 Version data item is used to indicate the version of the protocol 1428 running in the originator. A DLEP implementation SHOULD use this 1429 information to decide if the potential session partner is running at 1430 a supported level. 1432 The DLEP Version data item contains the following fields: 1434 0 1 2 3 1435 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 1436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1437 | Data Item Type| Length | Major Version | 1438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1439 | Minor Version | 1440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1442 Data Item Type: TBD 1444 Length: 4 1446 Major Version: The major version of the DLEP protocol, expressed as 1447 an 16-bit unsigned integer. 1449 Minor Version: The minor version of the DLEP protocol, expressed as 1450 an 16-bit unsigned integer. 1452 Support of this draft is indicated by setting the Major Version to 1453 '0', and the Minor Version to '9' (i.e. Version 0.9). 1455 7.2. Status 1457 The Status data item MAY appear in the Peer Initialization ACK 1458 (Section 6.4), Peer Termination (Section 6.7), Peer Termination ACK 1459 (Section 6.8), Peer Update ACK (Section 6.6), Destination Up ACK 1460 (Section 6.10), Destination Down ACK (Section 6.12) and Link 1461 Characteristics ACK (Section 6.16) signals as part of an 1462 acknowledgement from either the modem or the router, to indicate the 1463 success or failure of the previously received signal. 1465 The status data item includes an optional Text field that can be used 1466 to provide a textual description of the status. The use of the Text 1467 field is entirely up to the receiving implementation, i.e., it could 1468 be output to a log file or discarded. If no Text field is supplied 1469 with the Status data item, the Length field MUST be set to 1. 1471 The Status data item contains the following fields: 1473 0 1 2 3 1474 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 1475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1476 | Data Item Type| Length | Code | Text... 1477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1479 Data Item Type: TBD 1481 Length: 1 + Length of text 1482 Status Code: One of the codes defined below. 1484 Text: UTF-8 encoded string, describing an problem, used for 1485 implementation defined purposes. 1487 An implementation MUST NOT assume the Text field is NUL-terminated. 1489 +----------------+-------+------------------------------------------+ 1490 | Status Code | Value | Reason | 1491 +----------------+-------+------------------------------------------+ 1492 | Success | 0 | The signal was processed successfully. | 1493 | Unknown Signal | TBD | The signal was not recognized by the | 1494 | | | implementation. | 1495 | Invalid Data | TBD | One or more data items in the signal are | 1496 | | | invalid, unexpected or duplicated. | 1497 | Unexpected | TBD | The signal was not expected while the | 1498 | Signal | | machine was in this state, e.g., a Peer | 1499 | | | Initialization signal after session | 1500 | | | establishment. | 1501 | Request Denied | TBD | The receiver has not completed the | 1502 | | | request. | 1503 | Timed Out | TBD | The request could not be completed in | 1504 | | | the time allowed. | 1505 | Invalid | TBD | The destination provided in the signal | 1506 | Destination | | does not match a previously announced | 1507 | | | destination. For example, in the Link | 1508 | | | Characteristic Request ACK signal | 1509 | | | (Section 6.16). | 1510 +----------------+-------+------------------------------------------+ 1512 7.3. IPv4 Connection Point 1514 The IPv4 Connection Point data item MAY appear in the Peer Offer 1515 signal (Section 6.2). The IPv4 Connection Point data item indicates 1516 the IPv4 address and, optionally, the TCP port number on the DLEP 1517 modem available for connections. If provided, the receiver MUST use 1518 this information to perform the TCP connect to the DLEP server. 1520 The IPv4 Connection Point data item contains the following fields: 1522 0 1 2 3 1523 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 1524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1525 | Data Item Type| Length | IPv4 Address | 1526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1527 | IPv4 Address | TCP Port Number (optional) | 1528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1529 Data Item Type: TBD 1531 Length: 4 (or 6 if TCP Port included) 1533 IPv4 Address: The IPv4 address listening on the DLEP modem. 1535 TCP Port Number: TCP Port number on the DLEP modem. 1537 If the Length field is 6, the port number specified MUST be used to 1538 establish the TCP session. If the TCP Port Number is omitted, i.e. 1539 the Length field is 4, the receiver MUST use the DLEP well-known port 1540 number (Section 10.7) to establish the TCP connection. 1542 7.4. IPv6 Connection Point 1544 The IPv6 Connection Point data item MAY appear in the Peer Offer 1545 signal (Section 6.2). The IPv6 Connection Point data item indicates 1546 the IPv6 address and, optionally, the TCP port number on the DLEP 1547 modem available for connections. If provided, the receiver MUST use 1548 this information to perform the TCP connect to the DLEP server. 1550 The IPv4 Connection Point data item contains the following fields: 1552 0 1 2 3 1553 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 1554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1555 | Data Item Type| Length | IPv6 Address | 1556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1557 | IPv6 Address | 1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 | IPv6 Address | 1560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1561 | IPv6 Address | 1562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1563 | IPv6 Address | TCP Port Number (optional) | 1564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 Data Item Type: TBD 1568 Length: 16 (or 18 if TCP Port included) 1570 IPv6 Address: The IPv6 address listening on the DLEP modem. 1572 TCP Port Number: TCP Port number on the DLEP modem. 1574 If the Length field is 18, the port number specified MUST be used to 1575 establish the TCP session. If the TCP Port Number is omitted, i.e. 1577 the Length field is 16, the receiver MUST use the DLEP well-known 1578 port number (Section 10.7) to establish the TCP connection. 1580 7.5. Peer Type 1582 The Peer Type data item MAY appear in the Peer Discovery 1583 (Section 6.1), Peer Offer (Section 6.2), Peer Initialization 1584 (Section 6.3) and Peer Initialization ACK (Section 6.4) signals. The 1585 Peer Type data item is used by the router and modem to give 1586 additional information as to its type. The peer type is a string and 1587 is envisioned to be used for informational purposes (e.g., as output 1588 in a display command). 1590 The Peer Type data item contains the following fields: 1592 0 1 2 3 1593 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 1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1595 | Data Item Type| Length | Peer Type | 1596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1598 Data Item Type: TBD 1600 Length: Length of peer type string. 1602 Peer Type: UTF-8 encoded string. For example, a satellite modem 1603 might set this variable to "Satellite terminal". 1605 An implementation MUST NOT assume the Peer Type field is NUL- 1606 terminated. 1608 7.6. Heartbeat Interval 1610 The Heartbeat Interval data item MUST appear in both the Peer 1611 Initialization (Section 6.3) and Peer Initialization ACK 1612 (Section 6.4) signals to indicate the Heartbeat timeout window to be 1613 used by the sender. 1615 The Interval is used to specify a period (in seconds) for Heartbeat 1616 signals (Section 6.14). By specifying an Interval value of 0, 1617 implementations MAY indicates the desire to disable Heartbeat signals 1618 entirely (i.e., the Interval is set to an infinite value). However, 1619 it is strongly recommended that implementations use non 0 timer 1620 values. Implementations MUST implement heuristics such that DLEP 1621 signals sent/received reset the timer interval. 1623 A DLEP session will be considered inactive, and MUST be torn down, 1624 via the Peer Termination procedure, by an implementation detecting 1625 that two (2) Heartbeat intervals have transpired without receipt of 1626 any DLEP signals. 1628 The Heartbeat Interval data item contains the following fields: 1630 0 1 2 3 1631 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 1632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1633 | Data Item Type| Length | Interval | 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1636 Data Item Type: TBD 1638 Length: 2 1640 Interval: 0 = Do NOT use heartbeats on this DLEP session. Non-zero 1641 = Interval, in seconds, for heartbeat signals. 1643 7.7. Extensions Supported 1645 The Extensions Supported data item MAY be used in both the Peer 1646 Initialization and Peer Initialization ACK signals. The Extensions 1647 Supported data item is used by the router and modem to negotiate 1648 additional optional functionality they are willing to support. The 1649 Extensions List is a concatenation of the types of each supported 1650 extension, found in the IANA DLEP Extensions repository. 1652 The Extensions Supported data item contains the following fields: 1654 0 1 2 3 1655 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 1656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1657 | Data Item Type| Length | Extensions List | 1658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1660 Data Item Type: TBD 1662 Length: Number of Extensions supported. 1664 Extension List: A list of extensions supported, identified by their 1665 1-octet value as listed in the extensions registry. 1667 7.8. Experimental Definition 1669 The Experimental Definition data item MAY be used in both the Peer 1670 Initialization and Peer Initialization ACK signals. The Experimental 1671 Definition data item is used by the router and modem to indicate the 1672 formats to be used for experimental signals and data items for the 1673 given peer session. The formats are identified by using a string 1674 that matches the 'name' given to the experiment. 1676 The Experimental Definition item contains the following fields: 1678 0 1 2 3 1679 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 1680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1681 | Data Item Type| Length | Experiment Name | 1682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1684 Data Item Type: TBD 1686 Length: Length of the name string for the Experiment. 1688 Experiment Name: UTF-8 encoded string, containing the name of the 1689 experiment being utilized. 1691 An implementation receiving this data item MUST compare the received 1692 string to a list of experiments that it supports. 1694 An implementation MUST NOT assume the Experiment Name field is NUL- 1695 terminated. 1697 7.9. MAC Address 1699 The MAC address data item MUST appear in all destination-oriented 1700 signals (i.e., Destination Up (Section 6.9), Destination Up ACK 1701 (Section 6.10), Destination Down (Section 6.11), Destination Down ACK 1702 (Section 6.12), Destination Update (Section 6.13), Link 1703 Characteristics Request (Section 6.15), and Link Characteristics ACK 1704 (Section 6.16)). The MAC Address data item contains the address of 1705 the destination on the remote node. The MAC address MAY be either a 1706 physical or a virtual destination. Examples of a virtual destination 1707 would be a multicast MAC address, or the broadcast MAC 1708 (FF:FF:FF:FF:FF:FF). 1710 0 1 2 3 1711 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 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 | Data Item Type| Length | MAC Address | 1714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1715 | MAC Address | 1716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1718 Data Item Type: TBD 1720 Length: 6 1721 MAC Address: MAC Address of the destination. 1723 7.10. IPv4 Address 1725 The IPv4 Address data item MAY appear in the Peer Update 1726 (Section 6.5), Destination Up (Section 6.9) and Destination Update 1727 (Section 6.13) signals. When included in Destination signals, this 1728 data item contains the IPv4 address of the destination. When 1729 included in the Peer Update signal, this data item contains the IPv4 1730 address of the peer. In either case, the data item also contains an 1731 indication of whether this is a new or existing address, or is a 1732 deletion of a previously known address. 1734 The IPv4 Address data item contains the following fields: 1736 0 1 2 3 1737 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 1738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1739 | Data Item Type| Length | Add/Drop | IPv4 Address | 1740 | | | Indicator | | 1741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1742 | IPv4 Address | 1743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1745 Data Item Type: TBD 1747 Length: 5 1749 Add/Drop: Value indicating whether this is a new or existing address 1750 (1), or a withdrawal of an address (0). 1752 IPv4 Address: The IPv4 address of the destination or peer. 1754 7.11. IPv6 Address 1756 The IPv6 Address data item MAY appear in the Peer Update 1757 (Section 6.5), Destination Up (Section 6.9) and Destination Update 1758 (Section 6.13) signals. When included in Destination signals, this 1759 data item contains the IPv6 address of the destination. When 1760 included in the Peer Update signal, this data item contains the IPv4 1761 address of the peer. In either case, the data item also contains an 1762 indication of whether this is a new or existing address, or is a 1763 deletion of a previously known address. 1765 The IPv6 Address data item contains the following fields: 1767 0 1 2 3 1768 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 1769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1770 | Data Item Type| Length | Add/Drop | IPv6 Address | 1771 | | | Indicator | | 1772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1773 | IPv6 Address | 1774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1775 | IPv6 Address | 1776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1777 | IPv6 Address | 1778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1779 | IPv6 Address | 1780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1782 Data Item Type: TBD 1784 Length: 17 1786 Add/Drop: Value indicating whether this is a new or existing address 1787 (1), or a withdrawal of an address (0). 1789 IPv6 Address: IPv6 Address of the destination or peer. 1791 7.12. IPv4 Attached Subnet 1793 The DLEP IPv4 Attached Subnet allows a device to declare that it has 1794 an IPv4 subnet (e.g., a stub network) attached, and MAY appear in the 1795 Destination Up (Section 6.9) and Destination Update (Section 6.13) 1796 signals. Once an IPv4 Subnet has been declared on a device, the 1797 declaration can NOT be withdrawn without terminating the destination 1798 (via the Destination Down signal (Section 6.11)) and re-issuing the 1799 Destination Up signal. 1801 The DLEP IPv4 Attached Subnet data item contains the following 1802 fields: 1804 0 1 2 3 1805 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 1806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1807 |Data Item Type | Length | IPv4 Attached Subnet | 1808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1809 | IPv4 Attached Subnet | Subnet Mask | 1810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1812 Data Item Type: TBD 1814 Length: 5 1815 IPv4 Subnet: The IPv4 subnet reachable at the destination. 1817 Subnet Mask: A subnet mask (0-32) to be applied to the IPv4 subnet. 1819 7.13. IPv6 Attached Subnet 1821 The DLEP IPv6 Attached Subnet allows a device to declare that it has 1822 an IPv6 subnet (e.g., a stub network) attached, and MAY appear in the 1823 Destination Up (Section 6.9) and Destination Update (Section 6.13) 1824 signals. As in the case of the IPv4 attached Subnet data item above, 1825 once an IPv6 attached subnet has been declared, it can NOT be 1826 withdrawn without terminating the destination (via the Destination 1827 Down signal (Section 6.11)) and re-issuing the Destination Up signal. 1829 The DLEP IPv6 Attached Subnet data item contains the following 1830 fields: 1832 0 1 2 3 1833 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 1834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1835 | Data Item Type| Length | IPv6 Attached Subnet | 1836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1837 | IPv6 Attached Subnet | 1838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1839 | IPv6 Attached Subnet | 1840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1841 | IPv6 Attached Subnet | 1842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1843 | IPv6 Attached Subnet | Subnet Mask | 1844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1846 Data Item Type: TBD 1848 Length: 17 1850 IPv4 Subnet: The IPv6 subnet reachable at the destination. 1852 Subnet Mask: A subnet mask (0-128) to be applied to the IPv6 subnet. 1854 7.14. Maximum Data Rate (Receive) 1856 The Maximum Data Rate (Receive) (MDRR) data item MUST appear in the 1857 Peer Initialization ACK signal (Section 6.4), and MAY appear in the 1858 Peer Update (Section 6.5), Destination Up (Section 6.9), Destination 1859 Update (Section 6.13) and Link Characteristics ACK (Section 6.16) 1860 signals to indicate the maximum theoretical data rate, in bits per 1861 second, that can be achieved while receiving data on the link. 1863 The Maximum Data Rate (Receive) data item contains the following 1864 fields: 1866 0 1 2 3 1867 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 1868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1869 | Data Item Type| Length | MDRR (bps) | 1870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1871 | MDRR (bps) | 1872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1873 | MDRR (bps) | 1874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1876 Data Item Type: TBD 1878 Length: 8 1880 Maximum Data Rate (Receive): A 64-bit unsigned integer, representing 1881 the maximum theoretical data rate, in bits per second (bps), that 1882 can be achieved while receiving on the link. 1884 7.15. Maximum Data Rate (Transmit) 1886 The Maximum Data Rate (Transmit) (MDRT) data item MUST appear in the 1887 Peer Initialization ACK signal (Section 6.4), and MAY appear in the 1888 Peer Update (Section 6.5), Destination Up (Section 6.9), Destination 1889 Update (Section 6.13) and Link Characteristics ACK (Section 6.16) 1890 signals to indicate the maximum theoretical data rate, in bits per 1891 second, that can be achieved while transmitting data on the link. 1893 The Maximum Data Rate (Transmit) data item contains the following 1894 fields: 1896 0 1 2 3 1897 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 1898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1899 | Data Item Type| Length | MDRT (bps) | 1900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1901 | MDRT (bps) | 1902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1903 | MDRT (bps) | 1904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1906 Data Item Type: TBD 1908 Length: 8 1909 Maximum Data Rate (Transmit): A 64-bit unsigned integer, 1910 representing the maximum theoretical data rate, in bits per second 1911 (bps), that can be achieved while transmitting on the link. 1913 7.16. Current Data Rate (Receive) 1915 The Current Data Rate (Receive) (CDRR) data item MUST appear in the 1916 Peer Initialization ACK signal (Section 6.4), and MAY appear in the 1917 Peer Update (Section 6.5), Destination Up (Section 6.9), Destination 1918 Update (Section 6.13) and Link Characteristics ACK (Section 6.16) 1919 signals to indicate the rate at which the link is currently operating 1920 for receiving traffic. 1922 When used in the Link Characteristics Request signal (Section 6.15), 1923 CDRR represents the desired receive rate, in bits per second, on the 1924 link. 1926 The Current Data Rate (Receive) data item contains the following 1927 fields: 1929 0 1 2 3 1930 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 1931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1932 | Data Item Type| Length | CDRR (bps) | 1933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1934 | CDRR (bps) | 1935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1936 | CDRR (bps) | 1937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1939 Data Item Type: TBD 1941 Length: 8 1943 Current Data Rate (Receive): A 64-bit unsigned integer, representing 1944 the current data rate, in bits per second, that can currently be 1945 achieved while receiving traffic on the link. 1947 If there is no distinction between current and maximum receive data 1948 rates, current data rate receive MUST be set equal to the maximum 1949 data rate receive. 1951 7.17. Current Data Rate (Transmit) 1953 The Current Data Rate Transmit (CDRT) data item MUST appear in the 1954 Peer Initialization ACK signal (Section 6.4), and MAY appear in the 1955 Peer Update (Section 6.5), Destination Up (Section 6.9), Destination 1956 Update (Section 6.13), and Link Characteristics ACK (Section 6.16) 1957 signals to indicate the rate at which the link is currently operating 1958 for transmitting traffic. 1960 When used in the Link Characteristics Request signal (Section 6.15), 1961 CDRT represents the desired transmit rate, in bits per second, on the 1962 link. 1964 The Current Data Rate (Transmit) data item contains the following 1965 fields: 1967 0 1 2 3 1968 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 1969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1970 | Data Item Type| Length | CDRT (bps) | 1971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1972 | CDRT (bps) | 1973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1974 | CDRT (bps) | 1975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1977 Data Item Type: TBD 1979 Length: 8 1981 Current Data Rate (Transmit): A 64-bit unsigned integer, 1982 representing the current data rate, in bits per second, that can 1983 currently be achieved while transmitting traffic on the link. 1985 If there is no distinction between current and maximum transmit data 1986 rates, current data rate transmit MUST be set equal to the maximum 1987 data rate transmit. 1989 7.18. Latency 1991 The Latency data item data item MUST appear in the Peer 1992 Initialization ACK signal (Section 6.4), and MAY appear in the Peer 1993 Update (Section 6.5), Destination Up (Section 6.9), Destination 1994 Update (Section 6.13), and Link Characteristics ACK (Section 6.16) 1995 signals to indicate the amount of latency, in microseconds, on the 1996 link. 1998 When used in the Link Characteristics Request signal (Section 6.15), 1999 Latency represents the maximum latency desired on the link. 2001 The Latency value is reported as delay. The calculation of latency 2002 is implementation dependent. For example, the latency may be a 2003 running average calculated from the internal queuing. 2005 0 1 2 3 2006 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 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2008 | Data Item Type| Length | Latency | 2009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2010 | Latency (cont.) | 2011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2013 Data Item Type: TBD 2015 Length: 4 2017 Latency: A 32-bit unsigned integer, representing the transmission 2018 delay, in microseconds, that a packet encounters as it is 2019 transmitted over the link. 2021 7.19. Resources (Receive) 2023 The Resources (Receive) (RESR) data item MAY appear in the Peer 2024 Initialization ACK signal (Section 6.4), Peer Update (Section 6.5), 2025 Destination Up (Section 6.9), Destination Update (Section 6.13) and 2026 Link Characteristics ACK (Section 6.16) signals to indicate the 2027 amount of resources for reception (with 0 meaning 'no resources 2028 available', and 100 meaning 'all resources available') at the 2029 destination. The list of resources that might be considered is 2030 beyond the scope of this document, and is left to implementations to 2031 decide. 2033 The Resources (Receive) data item contains the following fields: 2035 0 1 2 2036 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2038 | Data Item Type| Length | RESR | 2039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2041 Data Item Type: TBD 2043 Length: 1 2045 Resources (Receive): An 8-bit integer percentage, 0-100, 2046 representing the amount of resources allocated to receiving data. 2048 If a device cannot calculate RESR, this data item SHOULD NOT be 2049 issued. 2051 7.20. Resources (Transmit) 2053 The Resources (Transmit) (REST) data item MAY appear in the Peer 2054 Initialization ACK signal (Section 6.4), Peer Update (Section 6.5), 2055 Destination Up (Section 6.9), Destination Update (Section 6.13) and 2056 Link Characteristics ACK (Section 6.16) signals to indicate the 2057 amount of resources for transmission (with 0 meaning 'no resources 2058 available', and 100 meaning 'all resources available') at the 2059 destination. The list of resources that might be considered is 2060 beyond the scope of this document, and is left to implementations to 2061 decide. 2063 The Resources (Transmit) data item contains the following fields: 2065 0 1 2 2066 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2068 | Data Item Type| Length | REST | 2069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2071 Data Item Type: TBD 2073 Length: 1 2075 Resources (Transmit): An 8-bit integer percentage, 0-100, 2076 representing the amount of resources allocated to transmitting 2077 data. 2079 If a device cannot calculate REST, this data item SHOULD NOT be 2080 issued. 2082 7.21. Relative Link Quality (Receive) 2084 The Relative Link Quality (Receive) (RLQR) data item MAY appear in 2085 the Peer Initialization ACK signal (Section 6.4), Peer Update 2086 (Section 6.5), Destination Up (Section 6.9), Destination Update 2087 (Section 6.13) and Link Characteristics ACK (Section 6.16) signals to 2088 indicate the quality of the link for receiving data. 2090 The Relative Link Quality (Receive) data item contains the following 2091 fields: 2093 0 1 2 2094 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2096 | Data Item Type| Length | RLQR | 2097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2098 Data Item Type: TBD 2100 Length: 1 2102 Relative Link Quality (Receive): A non-dimensional 8-bit integer, 2103 1-100, representing relative link quality. A value of 100 2104 represents a link of the highest quality. 2106 If a device cannot calculate the RLQR, this data item SHOULD NOT be 2107 issued. 2109 7.22. Relative Link Quality (Transmit) 2111 The Relative Link Quality (Transmit) (RLQT) data item MAY appear in 2112 the Peer Initialization ACK signal (Section 6.4), Peer Update 2113 (Section 6.5), Destination Up (Section 6.9), Destination Update 2114 (Section 6.13) and Link Characteristics ACK (Section 6.16) signals to 2115 indicate the quality of the link for transmitting data. 2117 The Relative Link Quality (Transmit) data item contains the following 2118 fields: 2120 0 1 2 2121 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2123 | Data Item Type| Length | RLQT | 2124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2126 Data Item Type: TBD 2128 Length: 1 2130 Relative Link Quality (Transmit): A non-dimensional 8-bit integer, 2131 1-100, representing relative link quality. A value of 100 2132 represents a link of the highest quality. 2134 If a device cannot calculate the RLQT, this data item SHOULD NOT be 2135 issued. 2137 7.23. Link Characteristics ACK Timer 2139 The Link Characteristics ACK Timer data item MAY appear in the Link 2140 Characteristics Request signal (Section 6.15) to indicate the desired 2141 number of seconds to the sender will wait for a response to the 2142 request. If this data item is omitted, implementations supporting 2143 the Link Characteristics Request SHOULD choose a default value. 2145 The Link Characteristics ACK Timer data item contains the following 2146 fields: 2148 0 1 2 2149 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2151 | Data Item Type| Length | Interval | 2152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2154 Data Item Type: TBD 2156 Length: 1 2158 Interval: 0 = Do NOT use timeouts for this Link Characteristics 2159 request. Non-zero = Interval, in seconds, to wait before 2160 considering this Link Characteristics Request has been lost. 2162 8. Credit-Windowing 2164 DLEP includes an OPTIONAL Protocol Extension for a credit-windowing 2165 scheme analogous to the one documented in [RFC5578]. In this scheme, 2166 traffic between the router and modem is treated as two unidirectional 2167 windows. This document identifies these windows as the 'Modem 2168 Receive Window' (MRW), and the 'Router Receive Window' (RRW). 2170 If the OPTIONAL credit-windowing extension is used, credits MUST be 2171 granted by the receiver on a given window - that is, on the 'Modem 2172 Receive Window' (MRW), the modem is responsible for granting credits 2173 to the router, allowing it (the router) to send data to the modem. 2174 Likewise, the router is responsible for granting credits on the RRW, 2175 which allows the modem to send data to the router. 2177 Credits are managed on a destination-specific basis; that is, 2178 separate credit counts are maintained for each destination requiring 2179 the service. Credits do not apply to the DLEP session that exists 2180 between routers and modems. 2182 If a peer is able to support the OPTIONAL credit-windowing extension 2183 then it MUST include a Extensions Supported data item (Section 7.7) 2184 including the value DLEP_EXT_CREDITS (value TBD) in the appropriate 2185 Peer Initialization or Peer Initialization ACK signal. 2187 8.1. Credit-Windowing Signals 2189 The credit-windowing extension introduces no additional DLEP signals. 2190 However, if a peer has advertised during session initialization that 2191 it supports the credit-windowing extension then the following DLEP 2192 signals MAY contain additional credit-windowing data items: 2194 8.1.1. Destination Up Signal 2196 The Destination Up signal MAY contain one of each of the following 2197 data items: 2199 o Credit Grant (Section 8.2.1) 2201 If the Destination Up signal does not contain the Credit Grant data 2202 item, credits MUST NOT be used for that destination. 2204 8.1.2. Destination Up ACK Signal 2206 If the corresponding Destination Up signal contained the Credit Grant 2207 data item, the Destination Up ACK signal MUST contain one of each of 2208 the following data items: 2210 o Credit Window Status (Section 8.2.2) 2212 8.1.3. Destination Update Signal 2214 If the corresponding Destination Up signal contained the Credit Grant 2215 data item, the Destination Update signal MUST contain one of each of 2216 the following data items: 2218 o Credit Window Status (Section 8.2.2) 2220 If the corresponding Destination Up signal contained the Credit Grant 2221 data item, the Destination Update signal MAY contain one of each of 2222 the following data items: 2224 o Credit Grant (Section 8.2.1) 2226 o Credit Request (Section 8.2.3) 2228 8.2. Credit-Windowing Data Items 2230 The credit-windowing extension introduces 3 additional data items. 2231 If a peer has advertised during session initialization that it 2232 supports the credit-windowing extension then it MUST correctly 2233 process the following data items without error. 2235 +------------+-----------------------+----------------+ 2236 | Data Item | Description | Section | 2237 +------------+-----------------------+----------------+ 2238 | TBD | Credit Grant | Section 8.2.1 | 2239 | TBD | Credit Window Status | Section 8.2.2 | 2240 | TBD | Credit Request | Section 8.2.3 | 2241 +------------+-----------------------+----------------+ 2243 8.2.1. Credit Grant 2245 The Credit Grant data item is sent from a DLEP participant to grant 2246 an increment to credits on a window. The Credit Grant data item MAY 2247 appear in the Destination Up (Section 6.9) and Destination Update 2248 (Section 6.13) signals. The value in a Credit Grant data item 2249 represents an increment to be added to any existing credits available 2250 on the window. Upon successful receipt and processing of a Credit 2251 Grant data item, the receiver MUST respond with a signal containing a 2252 Credit Window Status data item to report the updated aggregate values 2253 for synchronization purposes, and if initializing a new credit 2254 window, granting initial credits. 2256 In the Destination Up signal, when credits are desired, the 2257 originating peer MUST set the initial credit value of the window it 2258 controls (i.e., the Modem Receive Window, or Router Receive Window) 2259 to an initial, non-zero value. If the receiver of a Destination Up 2260 signal with a Credit Grant data item supports credits, the receiver 2261 MUST either reject the use of credits for this destination, via a 2262 Destination Up ACK response containing a Status data item 2263 (Section 7.2) with a status code of 'Request Denied', or set the 2264 initial value from the data contained in the Credit Window Status 2265 data item. If the initialization completes successfully, the 2266 receiver MUST respond to the Destination Up signal with a Destination 2267 Up ACK signal that contains a Credit Window Status data item, 2268 initializing its receive window. 2270 The Credit Grant data item contains the following fields: 2272 0 1 2 3 2273 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 2274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2275 | Data Item Type| Length | Credit Increment | 2276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2277 | Credit Increment | 2278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2279 | Credit Increment | 2280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2282 Data Item Type: TBD 2284 Length: 8 2286 Reserved: A 64-bit unsigned integer representing the additional 2287 credits to be assigned to the credit window. 2289 Since credits can only be granted by the receiver on a window, the 2290 applicable credit window (either the MRW or the RRW) is derived from 2291 the sender of the grant. The Credit Increment MUST NOT cause the 2292 window to overflow; if this condition occurs, implementations MUST 2293 set the credit window to the maximum value contained in a 64-bit 2294 quantity. 2296 8.2.2. Credit Window Status 2298 If the credit-window extension is supported by the DLEP participants 2299 (both the router and the modem), the Credit Window Status data item 2300 MUST be sent by the participant receiving a Credit Grant for a given 2301 destination. 2303 The Credit Window Status data item contains the following fields: 2305 0 1 2 3 2306 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 2307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2308 | Data Item Type| Length | Modem Receive Window Value | 2309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2310 | Modem Receive Window Value | 2311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2312 | Modem Receive Window Value | Router Receive Window Value | 2313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2314 | Router Receive Window Value | 2315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2316 | Router Receive Window Value | 2317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2319 Data Item Type: TBD 2321 Length: 16 2323 Modem Receive Window Value: A 64-bit unsigned integer, indicating 2324 the current number of credits available on the Modem Receive 2325 Window, for the destination referred to by the signal. 2327 Router Receive Window Value: A 64-bit unsigned integer, indicating 2328 the current number of credits available on the Router Receive 2329 Window, for the destination referred to by the signal. 2331 8.2.3. Credit Request 2333 The Credit Request data item MAY be sent from either DLEP 2334 participant, via the Destination Update signal (Section 6.13), to 2335 indicate the desire for the partner to grant additional credits in 2336 order for data transfer to proceed on the session. If the 2337 corresponding Destination Up signal (Section 6.9) for this session 2338 did NOT contain a Credit Window Status data item, indicating that 2339 credits are to be used on the session, then the Credit Request data 2340 item MUST be silently dropped by the receiver. 2342 The Credit Request data item contains the following fields: 2344 0 1 2 2345 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2347 | Data Item Type| Length | Reserved, MUST| 2348 | | | be set to 0 | 2349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2351 Data Item Type: TBD 2353 Length: 1 2355 Reserved: This field is currently unused and MUST be set to 0. 2357 9. Security Considerations 2359 The protocol does not contain any mechanisms for security (e.g., 2360 authentication or encryption). The protocol assumes that any 2361 security would be implemented in the underlying transport (for 2362 example, by use of DTLS or some other mechanism), and is therefore 2363 outside the scope of this document. 2365 10. IANA Considerations 2367 This section specifies requests to IANA. 2369 10.1. Registrations 2371 This specification defines: 2373 o A new repository for DLEP signals, with sixteen values currently 2374 assigned. 2376 o Reservation of numbering space for Experimental DLEP signals. 2378 o A new repository for DLEP data items, with twenty-six values 2379 currently assigned. 2381 o Reservation of numbering space in the data items repository for 2382 experimental data items. 2384 o A new repository for DLEP status codes, with seven currently 2385 assigned. 2387 o A new repository for DLEP extensions, with one value currently 2388 assigned. 2390 o A request for allocation of a well-known port for DLEP TCP and UDP 2391 communication. 2393 o A request for allocation of a multicast IP address for DLEP 2394 discovery. 2396 10.2. Expert Review: Evaluation Guidelines 2398 No additional guidelines for expert review are anticipated. 2400 10.3. Signal Type Registration 2402 A new repository must be created with the values of the DLEP signals. 2404 All signal values are in the range [0..255]. 2406 Valid signals are: 2408 o Peer Discovery 2410 o Peer Offer 2412 o Peer Initialization 2414 o Peer Initialization ACK 2416 o Peer Update 2418 o Peer Update ACK 2420 o Peer Termination 2422 o Peer Termination ACK 2424 o Destination Up 2426 o Destination Up ACK 2428 o Destination Down 2430 o Destination Down ACK 2432 o Destination Update 2434 o Heartbeat 2435 o Link Characteristics Request 2437 o Link Characteristics ACK 2439 It is also requested that the repository contain space for 2440 experimental signal types. 2442 10.4. DLEP Data Item Registrations 2444 A new repository for DLEP data items must be created. 2446 All data item values are in the range [0..255]. 2448 Valid data items are: 2450 o DLEP Version 2452 o Status 2454 o IPv4 Connection Point 2456 o IPv6 Connection Point 2458 o Peer Type 2460 o Heartbeat Interval 2462 o Extensions Supported 2464 o Experimental Definition 2466 o MAC Address 2468 o IPv4 Address 2470 o IPv6 Address 2472 o IPv4 Attached Subnet 2474 o IPv6 Attached Subnet 2476 o Maximum Data Rate (Receive) 2478 o Maximum Data Rate (Transmit) 2480 o Current Data Rate (Receive) 2482 o Current Data Rate (Transmit) 2483 o Latency 2485 o Resources (Receive) 2487 o Resources (Transmit) 2489 o Relative Link Quality (Receive) 2491 o Relative Link Quality (Transmit) 2493 o Link Characteristics ACK Timer 2495 o Credit Window Status 2497 o Credit Grant 2499 o Credit Request 2501 It is also requested that the registry allocation contain space for 2502 experimental data items. 2504 10.5. DLEP Status Code Registrations 2506 A new repository for DLEP status codes must be created. 2508 All status codes are in the range [0..255]. 2510 Valid status codes are: 2512 o Success (value 0) 2514 o Unknown Signal 2516 o Invalid Data 2518 o Unexpected Signal 2520 o Request Denied 2522 o Timed Out 2524 o Invalid Destination 2526 10.6. DLEP Extensions Registrations 2528 A new repository for DLEP extensions must be created. 2530 All extension values are in the range [0..255]. 2532 Valid extensions are: 2534 o DLEP_EXT_CREDITS - Credit windowing 2536 10.7. DLEP Well-known Port 2538 It is requested that IANA allocate a well-known port number for DLEP 2539 communication. 2541 10.8. DLEP Multicast Address 2543 It is requested that IANA allocate a multicast address for DLEP 2544 discovery signals. 2546 11. Acknowledgements 2548 The authors would like to acknowledge and thank the members of the 2549 DLEP design team, who have provided invaluable insight. The members 2550 of the design team are: Teco Boot, Bow-Nan Cheng, John Dowdell, and 2551 Henning Rogge. 2553 The authors would also like to acknowledge the influence and 2554 contributions of Greg Harrison, Chris Olsen, Martin Duke, Subir Das, 2555 Jaewon Kang, Vikram Kaul, Nelson Powell and Victoria Mercieca. 2557 12. References 2559 12.1. Normative References 2561 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2562 Requirement Levels", BCP 14, RFC 2119, March 1997. 2564 [RFC5578] Berry, B., Ratliff, S., Paradise, E., Kaiser, T., and M. 2565 Adams, "PPP over Ethernet (PPPoE) Extensions for Credit 2566 Flow and Link Metrics", RFC 5578, February 2010. 2568 12.2. Informative References 2570 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2571 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 2573 Appendix A. Peer Level Signal Flows 2575 A.1. Discovery 2576 Router Modem Signal Description 2577 ======================================================================== 2579 | Router initiates discovery, starts 2580 | a timer, send Peer Discovery 2581 |-------Peer Discovery---->|| signal. 2583 ~ ~ ~ ~ ~ ~ ~ Router discovery timer expires 2584 without receiving Peer Offer. 2586 | Router sends another Peer 2587 |-------Peer Discovery---------->| Discovery signal. 2588 | 2589 | Modem receives Peer Discovery 2590 | signal. 2591 | 2592 | Modem sends Peer Offer with 2593 |<--------Peer Offer-------------| Connection Point information. 2594 : 2595 : Router MAY cancel discovery timer 2596 : and stop sending Peer Discovery 2597 : signals. 2599 A.2. Session Initialization 2601 Router Modem Signal Description 2602 ======================================================================== 2604 | Router connects to discovered or 2605 | pre-configured Modem Connection 2606 |---------TCP connect----------> Point. 2607 | 2608 | Router sends Peer Initialization 2609 |-------Peer Initialization----->| signal. 2610 | 2611 | Modem receives Peer Initialization 2612 | signal. 2613 | 2614 | Modem sends Peer Initialization 2615 | ACK, with compatible extensions, 2616 |<----Peer Initialization ACK----| and Success status data item. 2617 | | 2618 |<<============================>>| Session established. Heartbeats 2619 : : begin. 2621 A.3. Session Initialization - Refused 2623 Router Modem Signal Description 2624 ======================================================================== 2626 | Router connects to discovered or 2627 | pre-configured Modem Connection 2628 |---------TCP connect----------> Point. 2629 | 2630 | Router sends Peer Initialization 2631 |-------Peer Initialization----->| signal. 2632 | 2633 | Modem receives Peer Initialization 2634 | signal, and will not support the 2635 | advertised version, experiment or 2636 | extensions. 2637 | 2638 | Modem sends Peer Initialization 2639 | ACK, with 'Request Denied' status 2640 |<----Peer Initialization ACK----| data item. 2641 | | 2642 | <---- TCP shutdown (send)-----| Modem closes TCP connection. 2643 | 2644 | Router receives negative Peer 2645 | Initialization ACK, closes 2646 |---------TCP close-----------> TCP connection. 2647 | 2648 ||------------------------------|| Session not started. 2650 A.4. Router Changes IP Addresses 2652 Router Modem Signal Description 2653 ======================================================================== 2655 | Router sends Peer Update signal to 2656 |--------Peer Update------------>| announce change of IP address 2657 | 2658 | Modem receives Peer Update signal 2659 | and updates internal state. 2660 | 2661 |<-------Peer Update ACK---------| Modem sends Peer Update ACK. 2663 A.5. Modem Changes Session-wide Metrics 2664 Router Modem Signal Description 2665 ======================================================================== 2667 | Modem sends Peer Update signal to 2668 | announce change of modem-wide 2669 |<--------Peer Update------------| metrics 2670 | 2671 | Router receives Peer Update signal 2672 | and updates internal state. 2673 | 2674 |-------Peer Update ACK--------->| Router sends Peer Update ACK. 2676 A.6. Router Terminates Session 2678 Router Modem Signal Description 2679 ======================================================================== 2681 | Router sends Peer Termination 2682 |-------Peer Termination-------->| signal with Status data item. 2683 | | 2684 |-------TCP shutdown (send)---> | Router stops sending signals. 2685 | 2686 | Modem receives Peer Termination, 2687 | stops counting received heartbeats 2688 | and stops sending heartbeats. 2689 | 2690 | Modem sends Peer Termination ACK 2691 |<-----Peer Termination ACK------| with Status 'Success'. 2692 | | 2693 | <----TCP shutdown (send)------| Modem stops sending signals. 2694 | 2695 ||------------------------------|| Session terminated. 2697 A.7. Modem Terminates Session 2698 Router Modem Signal Description 2699 ======================================================================== 2701 | Modem sends Peer Termination 2702 |<------Peer Termination---------| signal with Status data item. 2703 | | 2704 | <----TCP shutdown (send)------| Modem stops sending signals. 2705 | 2706 | Router receives Peer Termination, 2707 | stops counting received heartbeats 2708 | and stops sending heartbeats. 2709 | 2710 | Router sends Peer Termination ACK 2711 |------Peer Termination ACK----->| with Status 'Success'. 2712 | | 2713 |-------TCP shutdown (send)---> | Router stops sending signals. 2714 | 2715 ||------------------------------|| Session terminated. 2717 A.8. Session Heartbeats 2718 Router Modem Signal Description 2719 ======================================================================== 2721 |----------Heartbeat------------>| Router sends heartbeat signal 2722 | 2723 | Modem resets heartbeats missed 2724 | counter. 2726 ~ ~ ~ ~ ~ ~ ~ 2728 |----------[Any signal]--------->| When the Modem receives any signal 2729 | from the Router. 2730 | 2731 | Modem resets heartbeats missed 2732 | counter. 2734 ~ ~ ~ ~ ~ ~ ~ 2736 |<---------Heartbeat-------------| Modem sends heartbeat signal 2737 | 2738 | Router resets heartbeats missed 2739 | counter. 2741 ~ ~ ~ ~ ~ ~ ~ 2743 |<---------[Any signal]----------| When the Router receives any 2744 | signal from the Modem. 2745 | 2746 | Modem resets heartbeats missed 2747 | counter. 2749 A.9. Router Detects a Heartbeat timeout 2751 Router Modem Signal Description 2752 ======================================================================== 2754 ||<----------------------| Router misses a heartbeat 2756 | ||<----------------------| Router misses too many heartbeats 2757 | 2758 | 2759 |-------Peer Termination-------->| Router sends Peer Termination 2760 | signal with 'Timeout' Status 2761 | data item. 2762 : 2763 : Termination proceeds as above. 2765 A.10. Modem Detects a Heartbeat timeout 2767 Router Modem Signal Description 2768 ======================================================================== 2770 |---------------------->|| Modem misses a heartbeat 2772 |---------------------->|| | Modem misses too many heartbeats 2773 | 2774 | 2775 |<-------Peer Termination--------| Modem sends Peer Termination 2776 | signal with 'Timeout' Status 2777 | data item. 2778 : 2779 : Termination proceeds as above. 2781 Appendix B. Destination Specific Signal Flows 2783 B.1. Common Destination Signaling 2785 Router Modem Signal Description 2786 ======================================================================== 2788 | Modem detects a new logical 2789 | destination is reachable, and 2790 |<-------Destination Up----------| sends Destination Up signal. 2791 | 2792 |--------Destination Up ACK----->| Router sends Destination Up ACK. 2794 ~ ~ ~ ~ ~ ~ ~ 2795 | Modem detects change in logical 2796 | destination metrics, and sends 2797 |<-------Destination Update------| Destination Update signal. 2799 ~ ~ ~ ~ ~ ~ ~ 2800 | Modem detects change in logical 2801 | destination metrics, and sends 2802 |<-------Destination Update------| Destination Update signal. 2804 ~ ~ ~ ~ ~ ~ ~ 2805 | Modem detects logical destination 2806 | is no longer reachable, and sends 2807 |<-------Destination Down--------| Destination Down signal. 2808 | 2809 | Router receives Destination Down, 2810 | updates internal state, and sends 2811 |--------Destination Down ACK--->| Destination Down ACK signal. 2813 B.2. Multicast Destination Signaling 2815 Router Modem Signal Description 2816 ======================================================================== 2818 | Router detects a new multicast 2819 | destination is in use, and sends 2820 |--------Destination Up--------->| Destination Up signal. 2821 | 2822 | Modem updates internal state to 2823 | monitor multicast destination, and 2824 |<-------Destination Up ACK------| sends Destination Up ACK. 2826 ~ ~ ~ ~ ~ ~ ~ 2827 | Modem detects change in multicast 2828 | destination metrics, and sends 2829 |<-------Destination Update------| Destination Update signal. 2831 ~ ~ ~ ~ ~ ~ ~ 2832 | Modem detects change in multicast 2833 | destination metrics, and sends 2834 |<-------Destination Update------| Destination Update signal. 2836 ~ ~ ~ ~ ~ ~ ~ 2837 | Router detects multicast 2838 | destination is no longer in use, 2839 |--------Destination Down------->| and sends Destination Down signal. 2840 | 2841 | Modem receives Destination Down, 2842 | updates internal state, and sends 2843 |<-------Destination Down ACK----| Destination Down ACK signal. 2845 B.3. Link Characteristics Request 2846 Router Modem Signal Description 2847 ======================================================================== 2849 Destination has already been 2850 ~ ~ ~ ~ ~ ~ ~ announced by either peer. 2852 | Router requires different 2853 | Characteristics for the 2854 | destination, and sends Link 2855 |--Link Characteristics Request->| Characteristics Request signal. 2856 | 2857 | Modem attempts to adjust link 2858 | status to meet the received 2859 | request, and sends a Link 2860 | Characteristics Request ACK 2861 |<---Link Char. Request ACK------| signal with the new values. 2863 Authors' Addresses 2865 Stan Ratliff 2866 VT iDirect 2867 13861 Sunrise Valley Drive, Suite 300 2868 Herndon, VA 20171 2869 USA 2871 Email: sratliff@idirect.net 2873 Bo Berry 2875 Shawn Jury 2876 Cisco Systems 2877 170 West Tasman Drive 2878 San Jose, CA 95134 2879 USA 2881 Email: sjury@cisco.com 2883 Darryl Satterwhite 2884 Broadcom 2886 Email: dsatterw@broadcom.com 2887 Rick Taylor 2888 Airbus Defence & Space 2889 Quadrant House 2890 Celtic Springs 2891 Coedkernew 2892 Newport NP10 8FZ 2893 UK 2895 Email: rick.taylor@airbus.com