idnits 2.17.1 draft-ietf-manet-dlep-18.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 (February 4, 2016) is 3003 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) == Unused Reference: 'RFC5578' is defined on line 2770, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-manet-credit-window-00 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile Ad hoc Networks Working Group S. Ratliff 2 Internet-Draft VT iDirect 3 Intended status: Standards Track S. Jury 4 Expires: August 7, 2016 Cisco Systems 5 D. Satterwhite 6 Broadcom 7 R. Taylor 8 Airbus Defence & Space 9 B. Berry 10 February 4, 2016 12 Dynamic Link Exchange Protocol (DLEP) 13 draft-ietf-manet-dlep-18 15 Abstract 17 When routing devices rely on modems to effect communications over 18 wireless links, they need timely and accurate knowledge of the 19 characteristics of the link (speed, state, etc.) in order to make 20 routing decisions. In mobile or other environments where these 21 characteristics change frequently, manual configurations or the 22 inference of state through routing or transport protocols does not 23 allow the router to make the best decisions. A bidirectional, event- 24 driven communication channel between the router and the modem is 25 necessary. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 7, 2016. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 7 63 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 64 2.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 9 65 3. Destinations . . . . . . . . . . . . . . . . . . . . . . . . 9 66 3.1. Router-requested Destinations . . . . . . . . . . . . . . 10 67 4. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 5. DLEP Session Flow . . . . . . . . . . . . . . . . . . . . . . 12 69 5.1. Peer Discovery State . . . . . . . . . . . . . . . . . . 12 70 5.2. Session Initialization State . . . . . . . . . . . . . . 14 71 5.3. In-Session State . . . . . . . . . . . . . . . . . . . . 15 72 5.3.1. Heartbeats . . . . . . . . . . . . . . . . . . . . . 16 73 5.4. Session Termination State . . . . . . . . . . . . . . . . 16 74 5.5. Session Reset state . . . . . . . . . . . . . . . . . . . 17 75 5.5.1. Unexpected TCP connection termination . . . . . . . . 17 76 6. Transaction Model . . . . . . . . . . . . . . . . . . . . . . 17 77 7. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 18 78 7.1. Experiments . . . . . . . . . . . . . . . . . . . . . . . 18 79 8. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 19 80 9. DLEP Signal and Message Structure . . . . . . . . . . . . . . 19 81 9.1. DLEP Signal Header . . . . . . . . . . . . . . . . . . . 20 82 9.2. DLEP Message Header . . . . . . . . . . . . . . . . . . . 20 83 9.3. DLEP Generic Data Item . . . . . . . . . . . . . . . . . 21 84 10. DLEP Signals and Messages . . . . . . . . . . . . . . . . . . 21 85 10.1. Peer Discovery Signal . . . . . . . . . . . . . . . . . 22 86 10.2. Peer Offer Signal . . . . . . . . . . . . . . . . . . . 23 87 10.3. Session Initialization Message . . . . . . . . . . . . . 23 88 10.4. Session Initialization Response Message . . . . . . . . 24 89 10.5. Session Update Message . . . . . . . . . . . . . . . . . 26 90 10.6. Session Update Response Message . . . . . . . . . . . . 27 91 10.7. Session Termination Message . . . . . . . . . . . . . . 28 92 10.8. Session Termination Response Message . . . . . . . . . . 28 93 10.9. Destination Up Message . . . . . . . . . . . . . . . . . 28 94 10.10. Destination Up Response Message . . . . . . . . . . . . 30 95 10.11. Destination Announce Message . . . . . . . . . . . . . . 30 96 10.12. Destination Announce Response Message . . . . . . . . . 31 97 10.13. Destination Down Message . . . . . . . . . . . . . . . . 32 98 10.14. Destination Down Response Message . . . . . . . . . . . 32 99 10.15. Destination Update Message . . . . . . . . . . . . . . . 33 100 10.16. Heartbeat Message . . . . . . . . . . . . . . . . . . . 34 101 10.17. Link Characteristics Request Message . . . . . . . . . . 35 102 10.18. Link Characteristics Response Message . . . . . . . . . 35 103 11. DLEP Data Items . . . . . . . . . . . . . . . . . . . . . . . 37 104 11.1. Status . . . . . . . . . . . . . . . . . . . . . . . . . 38 105 11.2. IPv4 Connection Point . . . . . . . . . . . . . . . . . 40 106 11.3. IPv6 Connection Point . . . . . . . . . . . . . . . . . 41 107 11.4. Peer Type . . . . . . . . . . . . . . . . . . . . . . . 42 108 11.5. Heartbeat Interval . . . . . . . . . . . . . . . . . . . 43 109 11.6. Extensions Supported . . . . . . . . . . . . . . . . . . 43 110 11.7. MAC Address . . . . . . . . . . . . . . . . . . . . . . 44 111 11.8. IPv4 Address . . . . . . . . . . . . . . . . . . . . . . 45 112 11.9. IPv6 Address . . . . . . . . . . . . . . . . . . . . . . 46 113 11.10. IPv4 Attached Subnet . . . . . . . . . . . . . . . . . . 47 114 11.11. IPv6 Attached Subnet . . . . . . . . . . . . . . . . . . 48 115 11.12. Maximum Data Rate (Receive) . . . . . . . . . . . . . . 49 116 11.13. Maximum Data Rate (Transmit) . . . . . . . . . . . . . . 49 117 11.14. Current Data Rate (Receive) . . . . . . . . . . . . . . 50 118 11.15. Current Data Rate (Transmit) . . . . . . . . . . . . . . 51 119 11.16. Latency . . . . . . . . . . . . . . . . . . . . . . . . 52 120 11.17. Resources (Receive) . . . . . . . . . . . . . . . . . . 52 121 11.18. Resources (Transmit) . . . . . . . . . . . . . . . . . . 53 122 11.19. Relative Link Quality (Receive) . . . . . . . . . . . . 54 123 11.20. Relative Link Quality (Transmit) . . . . . . . . . . . . 54 124 11.21. Maximum Transmission Unit (MTU) . . . . . . . . . . . . 55 125 12. Security Considerations . . . . . . . . . . . . . . . . . . . 56 126 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 127 13.1. Registrations . . . . . . . . . . . . . . . . . . . . . 56 128 13.2. Signal/Message Type Registration . . . . . . . . . . . . 57 129 13.3. DLEP Data Item Registrations . . . . . . . . . . . . . . 57 130 13.4. DLEP Status Code Registrations . . . . . . . . . . . . . 57 131 13.5. DLEP Extensions Registrations . . . . . . . . . . . . . 58 132 13.6. DLEP Well-known Port . . . . . . . . . . . . . . . . . . 58 133 13.7. DLEP IPv4 Link-local Multicast Address . . . . . . . . . 58 134 13.8. DLEP IPv6 Link-local Multicast Address . . . . . . . . . 58 135 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 58 136 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 137 15.1. Normative References . . . . . . . . . . . . . . . . . . 59 138 15.2. Informative References . . . . . . . . . . . . . . . . . 59 139 Appendix A. Discovery Signal Flows . . . . . . . . . . . . . . . 59 140 Appendix B. Peer Level Message Flows . . . . . . . . . . . . . . 60 141 B.1. Session Initialization . . . . . . . . . . . . . . . . . 60 142 B.2. Session Initialization - Refused . . . . . . . . . . . . 61 143 B.3. Router Changes IP Addresses . . . . . . . . . . . . . . . 61 144 B.4. Modem Changes Session-wide Metrics . . . . . . . . . . . 61 145 B.5. Router Terminates Session . . . . . . . . . . . . . . . . 62 146 B.6. Modem Terminates Session . . . . . . . . . . . . . . . . 62 147 B.7. Session Heartbeats . . . . . . . . . . . . . . . . . . . 63 148 B.8. Router Detects a Heartbeat timeout . . . . . . . . . . . 64 149 B.9. Modem Detects a Heartbeat timeout . . . . . . . . . . . . 65 150 Appendix C. Destination Specific Message Flows . . . . . . . . . 65 151 C.1. Common Destination Notification . . . . . . . . . . . . . 65 152 C.2. Multicast Destination Notification . . . . . . . . . . . 66 153 C.3. Link Characteristics Request . . . . . . . . . . . . . . 67 154 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68 156 1. Introduction 158 There exist today a collection of modem devices that control links of 159 variable datarate and quality. Examples of these types of links 160 include line-of-sight (LOS) terrestrial radios, satellite terminals, 161 and broadband modems. Fluctuations in speed and quality of these 162 links can occur due to configuration, or on a moment-to-moment basis, 163 due to physical phenomena like multipath interference, obstructions, 164 rain fade, etc. It is also quite possible that link quality and 165 datarate vary with respect to individual destinations on a link, and 166 with the type of traffic being sent. As an example, consider the 167 case of an 802.11 access point, serving two associated laptop 168 computers. In this environment, the answer to the question "What is 169 the datarate on the 802.11 link?" is "It depends on which associated 170 laptop we're talking about, and on what kind of traffic is being 171 sent." While the first laptop, being physically close to the access 172 point, may have a datarate of 54Mbps for unicast traffic, the other 173 laptop, being relatively far away, or obstructed by some object, can 174 simultaneously have a datarate of only 32Mbps for unicast. However, 175 for multicast traffic sent from the access point, all traffic is sent 176 at the base transmission rate (which is configurable, but depending 177 on the model of the access point, is usually 24Mbps or less). 179 In addition to utilizing variable datarate links, mobile networks are 180 challenged by the notion that link connectivity will come and go over 181 time, without an effect on a router's interface state (Up or Down). 182 Effectively utilizing a relatively short-lived connection is 183 problematic in IP routed networks, as routing protocols tend to rely 184 on interface state and independent timers at OSI Layer 3 to maintain 185 network convergence (e.g., HELLO messages and/or recognition of DEAD 186 routing adjacencies). These dynamic connections can be better 187 utilized with an event-driven paradigm, where acquisition of a new 188 neighbor (or loss of an existing one) is signaled, as opposed to a 189 paradigm driven by timers and/or interface state. DLEP not only 190 implements such an event-driven paradigm, but does so over a local (1 191 hop) TCP session, which guarantees delivery of the event messages. 193 Another complicating factor for mobile networks are the different 194 methods of physically connecting the modem devices to the router. 195 Modems can be deployed as an interface card in a router's chassis, or 196 as a standalone device connected to the router via Ethernet or serial 197 link. In the case of Ethernet attachment, with existing protocols 198 and techniques, routing software cannot be aware of convergence 199 events occurring on the radio link (e.g., acquisition or loss of a 200 potential routing neighbor), nor can the router be aware of the 201 actual capacity of the link. This lack of awareness, along with the 202 variability in datarate, leads to a situation where finding the 203 (current) best route through the network to a given destination is 204 difficult to establish and properly maintain. This is especially 205 true of demand-based access schemes such as Demand Assigned Multiple 206 Access (DAMA) implementations used on some satellite systems. With a 207 DAMA-based system, additional datarate may be available, but will not 208 be used unless the network devices emit traffic at a rate higher than 209 the currently established rate. Increasing the traffic rate does not 210 guarantee additional datarate will be allocated; rather, it may 211 result in data loss and additional retransmissions on the link. 213 Addressing the challenges listed above, the co-authors have developed 214 the Dynamic Link Exchange Protocol, or DLEP. The DLEP protocol runs 215 between a router and its attached modem devices, allowing the modem 216 to communicate link characteristics as they change, and convergence 217 events (acquisition and loss of potential routing destinations). The 218 following diagrams are used to illustrate the scope of DLEP packets. 220 |-------Local Node-------| |-------Remote Node------| 221 | | | | 222 +--------+ +-------+ +-------+ +--------+ 223 | Router |=======| Modem |{~~~~~~~~}| Modem |=======| Router | 224 | | | Device| | Device| | | 225 +--------+ +-------+ +-------+ +--------+ 226 | | | Link | | | 227 |-DLEP--| | Protocol | |-DLEP--| 228 | | | (e.g. | | | 229 | | | 802.11) | | | 231 Figure 1: DLEP Network 233 In Figure 1, when the local modem detects the presence of a remote 234 node, it (the local modem) sends a message to its router via the DLEP 235 protocol. The message consists of an indication of what change has 236 occurred on the link (e.g., presence of a remote node detected), 237 along with a collection of DLEP-defined Data Items that further 238 describe the change. Upon receipt of the message, the local router 239 may take whatever action it deems appropriate, such as initiating 240 discovery protocols, and/or issuing HELLO messages to converge the 241 network. On a continuing, as-needed basis, the modem devices use 242 DLEP to report any characteristics of the link (datarate, latency, 243 etc.) that have changed. DLEP is independent of the link type and 244 topology supported by the modem. Note that the DLEP protocol is 245 specified to run only on the local link between router and modem. 246 Some over the air signaling may be necessary between the local and 247 remote modem in order to provide some parameters in DLEP messages 248 between the local modem and local router, but DLEP does not specify 249 how such over the air signaling is carried out. Over the air 250 signaling is purely a matter for the modem implementer. 252 Figure 2 shows how DLEP can support a configuration where routers are 253 connected with different link types. In this example, Modem A 254 implements a point-to-point link, and Modem B is connected via a 255 shared medium. In both cases, the DLEP protocol is used to report 256 the characteristics of the link (datarate, latency, etc.) to routers. 257 The modem is also able to use the DLEP session to notify the router 258 when the remote node is lost, shortening the time required to re- 259 converge the network. 261 +--------+ +--------+ 262 +----+ Modem | | Modem +---+ 263 | | Device | | Device | 264 | | Type A | <===== // ======> | Type A | | 265 | +--------+ P-2-P Link +--------+ | 266 +---+----+ +---+----+ 267 | Router | | Router | 268 | | | | 269 +---+----+ +---+----+ 270 | +--------+ +--------+ | 271 +-----+ Modem | | Modem | | 272 | Device | o o o o o o o o | Device +--+ 273 | Type B | o Shared o | Type B | 274 +--------+ o Medium o +--------+ 275 o o 276 o o 277 o o 278 o 279 +--------+ 280 | Modem | 281 | Device | 282 | Type B | 283 +---+----+ 284 | 285 | 286 +---+----+ 287 | Router | 288 | | 289 +--------+ 291 Figure 2: DLEP Network with Multiple Modem Devices 293 1.1. Requirements 295 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 296 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 297 "OPTIONAL" in this document are to be interpreted as described in BCP 298 14, RFC 2119 [RFC2119]. 300 2. Protocol Overview 302 DLEP defines a set of messages used by modems and their attached 303 routers to communicate events that occur on the physical link(s) 304 managed by the modem: for example, a remote node entering or leaving 305 the network, or that the link has changed. Associated with these 306 messages are a set of Data Items - information that describes the 307 remote node (e.g., address information), and/or the characteristics 308 of the link to the remote node. Throughout this document, we refer 309 to a modems/routers participating in a DLEP session as 'DLEP Peers', 310 unless a specific distinction (e.g. modem or router) is required. 312 DLEP uses a session-oriented paradigm between the modem device and 313 its associated router. If multiple modem devices are attached to a 314 router (as in Figure 2), or the modem supports multiple connections 315 (via multiple logical or physical interfaces), then separate DLEP 316 sessions exist for each modem or connection. A router and modem form 317 a session by completing the discovery and initialization process. 318 This router-modem session persists unless or until it either (1) 319 times out, based on the absence of traffic (including heartbeats), or 320 (2) is explicitly torn down by one of the participants. 322 The router/modem session provides a carrier for information exchange 323 concerning 'destinations' that are available via the modem device. 324 Destinations can be identified by either the router or the modem, and 325 represent a specific, addressable location that can be reached via 326 the link(s) managed by the modem. A destination can be either 327 physical or logical. 329 The example of a physical destination would be that of a remote, far- 330 end router attached via the variable-quality network. 332 The example of a logical destination is Multicast. Multicast traffic 333 destined for the variable-quality network (the network accessed via 334 the modem) is handled in IP networks by deriving a Layer 2 MAC 335 address based on the Layer 3 address. Leveraging on this scheme, 336 multicast traffic is supported in DLEP simply by treating the derived 337 MAC address as any other destination in the network. To support 338 these logical destinations, one of the DLEP participants (typically, 339 the router) informs the other as to the existence of the logical 340 destination. The modem, once it is aware of the existence of this 341 logical destination, reports link characteristics just as it would 342 for any other destination in the network. The specific algorithms a 343 modem would use to derive metrics on logical destinations are outside 344 the scope of this specification, and is left to specific 345 implementations to decide. 347 The DLEP messages concerning destinations thus become the way for 348 routers and modems to maintain, and notify each other about, an 349 information base representing the physical and logical destinations 350 accessible via the modem device, as well as the link characteristics 351 to those destinations. 353 While this document represents the best efforts of the working group 354 to be functionally complete, it is recognized that extensions to DLEP 355 will in all likelihood be necessary as more link types are used. 356 Such extensions are defined as additional rules of behavior, 357 messages, data items and/or status codes that are not defined in this 358 document. DLEP contains a standard mechanism for router and modem 359 implementations to negotiate the available extensions to use on a 360 per-session basis. 362 2.1. Assumptions 364 DLEP specifies UDP multicast for single-hop discovery signaling, and 365 TCP for transport of the control messages. Therefore, DLEP assumes 366 that the modem and router have topologically consistent IP addresses 367 assigned. It is RECOMMENDED that DLEP implementations utilize IPv6 368 link-local addresses to reduce the administrative burden of address 369 assignment. DLEP relies on the guaranteed- delivery of its messages 370 between router and modem, once the 1 hop discovery process is 371 complete, hence, the specification of TCP to carry the messages. 372 Other reliable transports for the protocol are possible, but are 373 outside the scope of this document. 375 DLEP assumes that the MAC address for delivering data traffic is the 376 MAC address used by DLEP to identify the destination. No 377 manipulation or substitution is performed; the MAC address supplied 378 in all destination messages is used as the OSI Layer 2 Destination 379 MAC address. DLEP also assumes that MAC addresses are unique within 380 the context of a router-modem session. 382 The reliance on MAC addresses by DLEP forces the assumption that 383 participating DLEP peers are on a single segment (either physical or 384 logically, via tunneling protocols) at Layer 2. DLEP further assumes 385 that security of the implementations (e.g., authentication of 386 stations, encryption of traffic, or both) is dealt with by by 387 utilizing Layer 2 security techniques. This reliance on Layer 2 388 mechanisms secures all DLEP messages - both the UDP discovery 389 messages and the TCP control messages. 391 3. Destinations 393 Destination messages describe the acquisition and loss of network 394 destinations, and control the flow of information about the 395 destinations in the several ways. A destination MUST contain a MAC 396 address; it MAY optionally include a Layer 3 address (or multiple 397 addresses). The MAC address MAY reference a logical destination, as 398 in a derived multicast MAC address, as well as a physical device. As 399 destinations are discovered, DLEP routers and modems build an 400 information base of destinations accessible via the modem. 402 DLEP can support MAC addresses in either EUI-48 or EUI-64 format, 403 with the restriction that all MAC addresses for a given DLEP session 404 MUST be in the same format, and MUST be consistent with the MAC 405 address format of the connected modem (e.g., if the modem is 406 connected to the router with an EUI-48 MAC, all destination addresses 407 via that modem MUST be expressed in EUI-48 format). 409 Destination messages trigger creation/maintenance/deletion of 410 destinations in the information base of the recipient. For example, 411 a modem will inform its attached router of the presence of a new 412 destination via the Destination Up message (Section 10.9). Receipt 413 of a Destination Up causes the router to allocate the necessary 414 resources, creating an entry in the information base with the 415 specifics (i.e. MAC Address, Latency, Data Rate, etc.) of the 416 destination. The loss of a destination is communicated via the 417 Destination Down message (Section 10.13), and changes in status to 418 the destination (e.g., varying link quality, or addressing changes) 419 are communicated via the Destination Update message (Section 10.15). 421 The information on a given destination will persist in the 422 implementation's information base until a Destination Down message is 423 received, indicating that the peer has lost contact or interest with 424 the remote node, or the implementation transitions to the Session 425 Termination state. 427 3.1. Router-requested Destinations 429 Usually a modem will discover the presence of one or more remote 430 router/modem pairs and announce each destination's arrival by sending 431 a corresponding Destination Up message to its peer. However, there 432 may be times when a router wishes to express an interest in the 433 status of the link to a logical destination that has yet to be 434 announced, typically a multicast destination. To facilitate this, 435 DLEP provides the Destination Announce (Section 10.11) and 436 Destination Announce Response (Section 10.12) messages. These 437 messages have similar semantics to the Destination Up and Destination 438 Up Response messages, but flow from router to modem. 440 After successfully receiving and processing a Destination Announce 441 message, a modem then announces changes to the link to the logical 442 destination via Destination Update messages. A modem MAY refuse a 443 Destination Announce message by replying with a Destination Announce 444 Response message with a 'Request Denied' status code, see Table 3. 446 A Destination Announce message MAY also be used by a router to 447 request information concerning a destination that it has previously 448 declined interest in, via the 'Not Interested' status code, see 449 Table 3, or declared as down, via the Destination Down message. 451 One of the advantages of implementing DLEP is to leverage the modem's 452 knowledge of the links between remote destinations allowing routers 453 to avoid using probed neighbor discovery techniques, therefore modem 454 implementations SHOULD announce available destinations via the 455 Destination Up message, rather than relying on Destination Announce 456 messages. 458 4. Metrics 460 DLEP includes the ability for the router and modem to communicate 461 metrics that reflect the characteristics (e.g., datarate, latency) of 462 the variable-quality link in use. DLEP does not specify how a given 463 metric value is to be calculated, rather, the protocol assumes that 464 metrics have been calculated by a 'best effort', incorporating all 465 pertinent data that is available to the modem device. 467 DLEP allows for metrics to be sent within two contexts - metrics for 468 a specific destination within the network (e.g., a specific router), 469 and per-session (those that apply to all destinations accessed via 470 the modem). Most metrics can be further subdivided into transmit and 471 receive metrics. In cases where metrics are provided at session 472 level, the router MUST propagate the metrics to all entries in its 473 information base for destinations that are accessed via the modem. 475 DLEP modem implementations MUST announce all metric items that will 476 be reported during the session, and provide default values for those 477 metrics, in the Session Initialization Response message 478 (Section 10.4). In order to use a metric type that was not included 479 in the Session Initialization Response message, modem implementations 480 MUST terminate the session with the router (via the Session Terminate 481 message (Section 10.7)), and establish a new session. A modem MUST 482 include the following list of metrics in the Session Initialization 483 Response message: 485 o Maximum Data Rate (Receive) (Section 11.12) 487 o Maximum Data Rate (Transmit) (Section 11.13) 489 o Current Data Rate (Receive) (Section 11.14) 491 o Current Data Rate (Transmit) (Section 11.15) 493 o Latency (Section 11.16) 495 A DLEP modem MAY send metrics both in a session context (via the 496 Session Update message) and a specific destination context (via 497 Destination Update) at any time. The most recently received metric 498 value MUST take precedence over any earlier value, regardless of 499 context - that is: 501 1. If the router receives metrics in a specific destination context 502 (via the Destination Update message), then the specific 503 destination is updated with the new metric. 505 2. If the router receives metrics in a modem-wide context (via the 506 Session Update message), then the metrics for all destinations 507 accessed via the modem MUST be updated with the new metric. 509 It is left to implementations to choose sensible default values based 510 on their specific characteristics. Modems having static (non- 511 changing) link metric characteristics MAY report metrics only once 512 for a given destination (or once on a modem-wide basis, if all 513 connections via the modem are of this static nature). 515 In addition to communicating existing metrics about the link, DLEP 516 provides a message allowing a router to request a different datarate 517 or latency from the modem. This message is the Link Characteristics 518 Request message (Section 10.17), and gives the router the ability to 519 deal with requisite increases (or decreases) of allocated datarate/ 520 latency in demand-based schemes in a more deterministic manner. 522 5. DLEP Session Flow 524 All Peers participating in a DLEP session transition through five (5) 525 distinct states during the lifetime of a DLEP session: 527 o Peer Discovery 529 o Session Initialization 531 o In-Session 533 o Session Termination 535 o Session Reset 537 The Peer Discovery state is OPTIONAL to implement for routers. If it 538 is used, this state is the initial state. If it is not used, then a 539 preconfigured TCP address/port combination MUST be provided to the 540 router, and the router starts in the Session Initialization state. 542 Modems MUST support the Peer Discovery state. 544 5.1. Peer Discovery State 546 In the Peer Discovery state, if the router implementation supports 547 IPv6, it SHOULD send UDP packets containing a Peer Discovery signal 548 (Section 10.1) to the DLEP well-known IPv6 link-local multicast 549 address (Section 13.8) and port number (Section 13.6), setting the 550 packet source address to a valid IPv6 link-local address and the 551 source port to a valid port number. 553 If the router implementation supports IPv4, it SHOULD send UDP 554 packets containing a Peer Discovery signal (Section 10.1) to the DLEP 555 well-known IPv4 link-local multicast address (Section 13.7) and port 556 number (Section 13.6), setting the packet source address to a valid 557 local IPv4 address and the source port to a valid port number. 559 The implementation then waits for a unicast UDP packet containing a 560 Peer Offer signal (Section 10.2) from a potential DLEP peer modem. 561 While in the Peer Discovery state, Peer Discovery signals MUST be 562 sent repeatedly by a DLEP router, at regular intervals. The interval 563 MUST be a minimum of one second; it SHOULD be a configurable 564 parameter. Note that this operation (sending Peer Discovery and 565 waiting for Peer Offer) is outside the DLEP Transaction Model, as the 566 Transaction Model only describes messages on a TCP session. 568 In the Peer Discovery state, the DLEP modem implementation MUST 569 listen for incoming Peer Discovery signals on the DLEP well-known 570 link-local multicast address and port. The choice of using the well- 571 known IPv4 or the IPv6 well- known link-local multicast address and 572 port MUST be made by configuration. On receipt of a valid Peer 573 Discovery signal, it MUST unicast a Peer Offer signal to the source 574 address and port of the received UDP packet. Peer Offer signals MAY 575 contain one or more unicast address/port combinations for TCP-based 576 communication with the modem, via the IPv4 Connection Point data item 577 (Section 11.2) or the IPv6 Connection Point data item (Section 11.3), 578 on which it is prepared to accept an incoming TCP connection. If the 579 modem does not include an IPv4 Connection Point data item, nor a IPv6 580 Connection Point data item, then the source address of the packet 581 containing the Peer Offer signal MUST be used as the address on which 582 the modem is willing to accept TCP connections. 584 Upon establishment of a TCP connection, both modem and router enter 585 the Session Initialization state. Anything other than Peer Discovery 586 signals received on the UDP socket MUST be silently dropped. 588 Modems MUST be prepared to accept a TCP connection from a router that 589 is not using the Discovery mechanism, i.e. a connection attempt that 590 occurs without a preceding Peer Discovery signal. 592 Routers MUST use one or more of the modem address/port combinations 593 from the Peer Offer signal or from a priori configuration to 594 establish a new TCP connection to the modem. If more than one modem 595 address/port combinations is available, router implementations MAY 596 use their own heuristics to determine the order in which they are 597 tried. It is RECOMMENDED that an implementation attempt to connect 598 to any announced IPv6 address/port combinations before attempting to 599 use IPv4 combinations. If a TCP connection cannot be achieved using 600 any of the address/port combinations and the Discovery mechanism is 601 in use, then the router SHOULD resume issuing Peer Discovery signals. 602 If no IPv4 Connection Point data items, nor IPv6 Connection Point 603 data items are included in the Peer Offer signal, the router MUST use 604 the origin address of the UDP packet containing the signal as the IP 605 address, and the DLEP well-known port number. 607 Once a TCP connection has been established with the modem, the router 608 begins a new session and enters the Session Initialization state. It 609 is up to the router implementation if Peer Discovery signals continue 610 to be sent after the device has transitioned to the Session 611 Initialization state. 613 5.2. Session Initialization State 615 On entering the Session Initialization state, the router MUST send a 616 Session Initialization message (Section 10.3) to the modem. The 617 router MUST then wait for receipt of a Session Initialization 618 Response message (Section 10.4) from the modem. Receipt of the 619 Session Initialization Response message containing a Status data item 620 (Section 11.1) with value 'Success', see Table 3, indicates that the 621 modem has received and processed the Session Initialization message, 622 and the router MUST transition to the In-Session state. 624 On entering the Session Initialization state, the modem MUST wait for 625 receipt of a Session Initialization message from the router. Upon 626 receipt of a Session Initialization message, the modem MUST send a 627 Session Initialization Response message, and the session MUST 628 transition to the In-Session state. 630 DLEP provides an extension negotiation capability to be used in the 631 Session Initialization state, see Section 7. Extensions supported by 632 an implementation MUST be declared to potential DLEP peers using the 633 Extensions Supported data item (Section 11.6). Once both 634 participants have exchanged initialization messages, an 635 implementation MUST NOT emit any message, signal, data item or status 636 code associated with an extension that was not specified in the 637 received initialization message from its peer. 639 If the router receives any message other than a valid Session 640 Initialization Response, it MUST send a Session Termination message 641 (Section 10.7) with the 'Unexpected Message' status code, see 642 Table 3, and transition to the Session Termination state. 644 If the modem receives any message other than Session Initialization, 645 or it fails to parse the received message, it MUST NOT send any 646 message, and MUST terminate the TCP connection and transition to the 647 Session Reset state. 649 If an additional metric is to be introduced after the session has 650 started, the session between router and modem MUST be terminated and 651 restarted, and the new metric described in the next Session 652 Initialization Response message. 654 5.3. In-Session State 656 In the In-Session state, messages can flow in both directions between 657 participants, indicating changes to the session state, the arrival or 658 departure of reachable destinations, or changes of the state of the 659 links to the destinations. 661 The In-Session state is maintained until one of the following 662 conditions occur: 664 o A peer terminates the session by sending a Session Termination 665 message (Section 10.7)), or, 667 o The peer terminates the session, indicated by receiving a Session 668 Termination message. 670 The peer MUST then transition to the Session Termination state. 672 Prior to the exchange of Destination Up (Section 10.9) and 673 Destination Up Response (Section 10.10) messages, or Destination 674 Announce (Section 10.11) and Destination Announce Response 675 (Section 10.12) messages, no messages concerning the logical 676 destination identified by the MAC Address data item (Section 11.7) 677 may be sent. A peer receiving any message with such an unannounced 678 destination MUST terminate the session by issuing a Session 679 Termination message (Section 10.7) with a status code of 'Invalid 680 Destination', see Table 3, and transition to the Session Termination 681 state. 683 The router receiving a Destination Up message MAY decline further 684 messages concerning a given destination by sending a Destination Up 685 Response with a status code of 'Not Interested'. Modems receiving 686 such responses MUST NOT send further messages concerning that 687 destination to the router. 689 After exchanging Destination Down (Section 10.13) and Destination 690 Down Response (Section 10.14) messages, no messages concerning the 691 logical destination identified by the MAC Address data item may be a 692 sent without previously sending a new Destination Up message. A peer 693 receiving a message about a destination previously announced as 694 'down' MUST terminate the session by issuing a Session Termination 695 message with a status code of 'Invalid Destination' and transition to 696 the Session Termination state. 698 5.3.1. Heartbeats 700 In order to maintain the In-Session state, periodic Heartbeat 701 messages (Section 10.16) MAY be exchanged between router and modem. 702 These messages are intended to keep the session alive, and to verify 703 bidirectional connectivity between the two participants. 705 If Heartbeat messages are used, the following processing rules MUST 706 apply: 708 o Each DLEP peer is responsible for the creation of heartbeat 709 messages. 711 o Receipt of any valid DLEP message MUST reset the heartbeat 712 interval timer (i.e., valid DLEP messages take the place of, and 713 obviate the need for, additional Heartbeat messages). 715 o DLEP peers SHOULD allow two (2) heartbeat intervals to expire with 716 no messages from the peer before terminating the session by 717 issuing a Session Termination message with a status code of 'Timed 718 Out', and then transition to the Session Termination state. 720 5.4. Session Termination State 722 When a DLEP implementation enters the Session Termination state after 723 sending a Session Termination message (Section 10.7) as the result of 724 an invalid message or error, it MUST wait for a Session Termination 725 Response message (Section 10.8) from its peer. If Heartbeat messages 726 (Section 10.16) are in use, senders SHOULD allow four (4) heartbeat 727 intervals to expire before assuming that the peer is unresponsive, 728 and continuing with session termination. If Heartbeat messages are 729 not in use, then if is RECOMMENDED that an interval of eight (8) 730 seconds be used. 732 When the sender of the Session Termination message receives a Session 733 Termination Response message from its peer, or times out, it MUST 734 transition to the Session Reset state. 736 When an implementation enters the Session Termination state having 737 received a Session Termination message from its peer, it MUST 738 immediately send a Session Termination Response and transition to the 739 Session Reset state. 741 Any messages received after either sending or receiving a Session 742 Termination message MUST be silently ignored. 744 5.5. Session Reset state 746 In the Session Reset state the implementation MUST perform the 747 following actions: 749 o Release all resources allocated for the session. 751 o Eliminate all destinations in the information base accessible via 752 the modem represented by the session. Destination Down messages 753 (Section 10.13) MUST NOT be sent. 755 o Terminate the TCP connection. 757 Having completed these actions the implementation SHOULD return to 758 the relevant initial state: Peer Discovery for modems; either Peer 759 Discovery or Session Initialization for routers, depending on 760 configuration. 762 5.5.1. Unexpected TCP connection termination 764 If the TCP connection between peers is terminated when a participant 765 is not in the Session Reset state, the implementation MUST 766 immediately transition to the Session Reset state. 768 6. Transaction Model 770 DLEP defines a simple message transaction model: Only one request per 771 destination may be in progress at a time. A message transaction is 772 considered complete when a response matching a previously issued 773 request is received. If a participant receives a request for a 774 destination for which there is already an outstanding request, the 775 implementation MUST terminate the session by issuing a Session 776 Termination message (Section 10.7) with a status code of 'Unexpected 777 Message', see Table 3, and transition to the Session Termination 778 state. There is no restriction to the total number of message 779 transactions in progress at a time, as long as each transaction 780 refers to a different destination. 782 It should be noted that some requests may take a considerable amount 783 of time for some participants to complete, for example a modem 784 handling a multicast destination up request may have to perform a 785 complex network reconfiguration. A sending implementation MUST be 786 able to handle such long running transactions gracefully. 788 Additionally, only one session request, e.g. a Session Initialization 789 message (Section 10.3) may be in progress at a time. As above, a 790 session transaction is considered complete when a response matching a 791 previously issued request is received. If a participant receives a 792 session request while there is already a session request in progress, 793 it MUST terminate the session by issuing a Session Termination 794 message with a status code of 'Unexpected Message', and transition to 795 the Session Termination state. Only the Session Termination message 796 may be issued when a session transaction is in progress. Heartbeat 797 messages (Section 10.16) MUST NOT be considered part of a session 798 transaction. 800 DLEP transactions do not time out and are not cancellable. An 801 implementation can detect if its peer has failed in some way by use 802 of the session heartbeat mechanism during the In-Session state, see 803 Section 5.3. 805 7. Extensions 807 Extensions MUST be negotiated on a per-session basis during session 808 initialization via the Extensions Supported mechanism. 809 Implementations are not required to support any extension in order to 810 be considered DLEP compliant. An extension document, describing the 811 operation of a credit windowing scheme for flow control, is described 812 in [CREDIT]. 814 If interoperable protocol extensions are required, they MUST be 815 standardized either as an update to this document, or as an 816 additional stand-alone specification. The requests for IANA- 817 controlled registries in this document contain sufficient Reserved 818 space for DLEP signals, messages, data items and status codes to 819 accommodate future extensions to the protocol. 821 As multiple protocol extensions MAY be announced during session 822 initialization, authors of protocol extensions MUST consider the 823 interaction of their extension with other published extensions, and 824 specify any incompatibilities. 826 7.1. Experiments 828 This document requests Private Use numbering space in the DLEP 829 signal/message, data item and status code registries for experimental 830 extensions. The intent is to allow for experimentation with new 831 signals, messages, data items, and/or status codes, while still 832 retaining the documented DLEP behavior. 834 Use of the Private Use signals, messages, data items, status codes, 835 or behaviors MUST be announced as DLEP Extensions, during session 836 initialization, using extension identifiers from the Private Use 837 space in the Extensions Supported registry (Table 4), with a value 838 agreed upon (a priori) between the participating peers. DLEP 839 extensions using the Private Use numbering space are commonly 840 referred to as Experiments. 842 Multiple experiments MAY be announced in the Session Initialization 843 messages. However, use of multiple experiments in a single session 844 could lead to interoperability issues or unexpected results (e.g., 845 clashes of experimental signals, messages, data items and/or status 846 code types), and is therefore discouraged. It is left to 847 implementations to determine the correct processing path (e.g., a 848 decision on whether to terminate the session, or to establish a 849 precedence of the conflicting definitions) if such conflicts arise. 851 8. Scalability 853 The protocol is intended to support thousands of destinations on a 854 given modem/router pair. At large scale, implementations SHOULD 855 consider employing techniques to prevent flooding a peer with a large 856 number of messages in a short time. It is recommended that 857 implementations consider a dampening algorithm to prevent a flapping 858 device from generating a large number of Destination Up/Destination 859 Down messages, for example. Implementations SHOULD also consider 860 techniques such as a hysteresis to lessen the impact of rapid, minor 861 fluctuations in link quality. The specific algorithms to be used for 862 handling flapping destinations and minor changes in link quality are 863 outside the scope of this specification. 865 9. DLEP Signal and Message Structure 867 DLEP defines two protocol units used in two different ways: Signals 868 and Messages. Signals are only used in the Discovery mechanism and 869 are carried in UDP datagrams. Messages are used bi-directionally 870 over a TCP connection between two peers, in the Session 871 Initialization, In-Session and Session Termination states. 873 Both signals and messages consist of a header followed by an 874 unordered list of data items. Headers consist of Type and Length 875 information, while data items are encoded as TLV (Type-Length-Value) 876 structures. In this document, the data items following a signal or 877 message header are described as being 'contained in' the signal or 878 message. 880 There is no restriction on the order of data items following a 881 header, and the multiplicity of duplicate data items is defined by 882 the definition of the signal or message declared by the type in the 883 header. 885 All integers in header fields and values MUST be in network byte- 886 order. 888 9.1. DLEP Signal Header 890 The DLEP signal header contains the following fields: 892 0 1 2 3 893 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 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | 'D' | 'L' | 'E' | 'P' | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | Signal Type | Length | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 Figure 3: DLEP Signal Header 902 "DLEP": Every signal MUST start with the characters: U+44, U+4C, 903 U+45, U+50. 905 Signal Type: An 16-bit unsigned integer containing one of the DLEP 906 Signal/Message Type values defined in this document. 908 Length: The length in octets, expressed as a 16-bit unsigned 909 integer, of all of the DLEP data items associated with this 910 signal. This length SHALL NOT include the length of the header 911 itself. 913 The DLEP signal header is immediately followed by one or more DLEP 914 data items, encoded in TLVs, as defined in this document. 916 If an unrecognized, or unexpected signal is received, or a received 917 signal contains unrecognized, invalid, or disallowed duplicate data 918 items, the receiving participant MUST ignore the signal. 920 9.2. DLEP Message Header 922 The DLEP message header contains the following fields: 924 0 1 2 3 925 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | Message Type | Length | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 Figure 4: DLEP Message Header 932 Message Type: An 16-bit unsigned integer containing one of the DLEP 933 Signal/Message Type values defined in this document. 935 Length: The length in octets, expressed as a 16-bit unsigned 936 integer, of all of the DLEP data items associated with this 937 message. This length SHALL NOT include the length of the header 938 itself. 940 The DLEP message header is immediately followed by one or more DLEP 941 data items, encoded in TLVs, as defined in this document. 943 If an unrecognized, or unexpected message is received, or a received 944 message contains unrecognized, invalid, or disallowed duplicate data 945 items, the receiving participant MUST issue a Session Termination 946 message (Section 10.7) with a Status data item (Section 11.1) 947 containing the most relevant status code, see Table 3, and transition 948 to the Session Termination state. 950 9.3. DLEP Generic Data Item 952 All DLEP data items contain the following fields: 954 0 1 2 3 955 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 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 | Data Item Type | Length | 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Value... : 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 Figure 5: DLEP Generic Data Item 964 Data Item Type: An 16-bit unsigned integer field specifying the type 965 of data item being sent. 967 Length: The length in octets, expressed as an 16-bit unsigned 968 integer, of the value field of the data item. This length SHALL 969 NOT include the length of the header itself. 971 Value: A field of octets, which contains data specific to a 972 particular data item. 974 10. DLEP Signals and Messages 976 As mentioned above, all DLEP signals begin with the DLEP signal 977 header, and all DLEP messages begin with the DLEP message header. 979 Therefore, in the following descriptions of specific signals and 980 messages, this header is assumed, and will not be replicated. 982 Following is the set of core signals and messages that MUST be 983 recognized by a DLEP compliant implementation. As mentioned before, 984 not all messages may be used during a session, but an implementation 985 MUST correctly process these messages when received. 987 The core DLEP signals and messages are: 989 +-------------+-----------------------------------------------------+ 990 | Type Code | Description | 991 +-------------+-----------------------------------------------------+ 992 | 0 | Reserved | 993 | 1 | Peer Discovery signal (Section 10.1) | 994 | 2 | Peer Offer signal (Section 10.2) | 995 | 3 | Session Initialization message (Section 10.3) | 996 | 4 | Session Initialization Response message (Section | 997 | | 10.4) | 998 | 5 | Session Update message (Section 10.5) | 999 | 6 | Session Update Response message (Section 10.6) | 1000 | 7 | Session Termination message (Section 10.7) | 1001 | 8 | Session Termination Response message (Section 10.8) | 1002 | 9 | Destination Up message (Section 10.9) | 1003 | 10 | Destination Up Response message (Section 10.10) | 1004 | 11 | Destination Down message (Section 10.13) | 1005 | 12 | Destination Down Response message (Section 10.14) | 1006 | 13 | Destination Update message (Section 10.15) | 1007 | 14 | Heartbeat message (Section 10.16) | 1008 | 15 | Link Characteristics Request message (Section | 1009 | | 10.17) | 1010 | 16 | Link Characteristics Response message (Section | 1011 | | 10.18) | 1012 | 17 | Destination Announce message (Section 10.11) | 1013 | 18 | Destination Announce Response message (Section | 1014 | | 10.12) | 1015 | 19-65519 | Reserved for future extensions | 1016 | 65520-65534 | Private Use. Available for experiments | 1017 | 65535 | Reserved | 1018 +-------------+-----------------------------------------------------+ 1020 Table 1: DLEP Signal/Message types 1022 10.1. Peer Discovery Signal 1024 A Peer Discovery signal SHOULD be sent by a DLEP router to discover 1025 DLEP modems in the network. The Peer Offer signal (Section 10.2) is 1026 required to complete the discovery process. Implementations MUST 1027 implement their own retransmit heuristics in cases where it is 1028 determined the Peer Discovery signal has timed out. 1030 To construct a Peer Discovery signal, the Signal Type value in the 1031 signal header is set to 1, from Table 1. 1033 The Peer Discovery signal MAY contain the following data item: 1035 o Peer Type (Section 11.4) 1037 10.2. Peer Offer Signal 1039 A Peer Offer signal MUST be sent by a DLEP modem in response to a 1040 valid Peer Discovery signal (Section 10.1). 1042 The Peer Offer signal MUST be sent to the unicast address of the 1043 originator of the Peer Discovery signal. 1045 To construct a Peer Offer signal, the Signal Type value in the signal 1046 header is set to 2, from Table 1. 1048 The Peer Offer signal MAY contain the following data item: 1050 o Peer Type (Section 11.4) 1052 The Peer Offer signal MAY contain one or more of any of the following 1053 data items, with different values: 1055 o IPv4 Connection Point (Section 11.2) 1057 o IPv6 Connection Point (Section 11.3) 1059 The IP Connection Point data items indicate the unicast address the 1060 router MUST use when connecting the DLEP TCP session. If multiple IP 1061 Connection Point data items are present in the Peer Offer signal, 1062 router implementations MAY use their own heuristics to select the 1063 address to connect to. If no IP Connection Point data items are 1064 included in the Peer Offer signal, the router MUST use the origin 1065 address of the signal as the IP address, and the DLEP well-known port 1066 number (Section 13.6) to establish the TCP connection. 1068 10.3. Session Initialization Message 1070 A Session Initialization message MUST be sent by a DLEP router as the 1071 first message of the DLEP TCP session. It is sent by the router 1072 after a TCP connect to an address/port combination that was obtained 1073 either via receipt of a Peer Offer, or from a priori configuration. 1075 If any optional extensions are supported by the implementation, they 1076 MUST be enumerated in the Extensions Supported data item. If an 1077 Extensions Supported data item does not exist in a Session 1078 Initialization message, the modem MUST conclude that there is no 1079 support for extensions in the router. 1081 Implementations supporting the Heartbeat Interval (Section 11.5) 1082 should understand that heartbeats are not fully established until 1083 receipt of Session Initialization Response message (Section 10.4), 1084 and should therefore implement their own timeout and retry heuristics 1085 for this message. 1087 To construct a Session Initialization message, the Message Type value 1088 in the message header is set to 3, from Table 1. 1090 The Session Initialization message MUST contain one of each of the 1091 following data items: 1093 o Heartbeat Interval (Section 11.5) 1095 The Session Initialization message MAY contain one of each of the 1096 following data items: 1098 o Peer Type (Section 11.4) 1100 o Extensions Supported (Section 11.6) 1102 A Session Initialization message MUST be acknowledged by the modem 1103 issuing a Session Initialization Response message (Section 10.4). 1105 As an exception to the general rule that an implementation receiving 1106 an unrecognized data item in a message terminating the session with 1107 an error, see Section 9.2, if a Session Initialization message 1108 contains one or more Extension Supported data items announcing 1109 support for extensions that the implementation does not recognize, 1110 then the implementation MAY ignore data items it does not recognize. 1112 10.4. Session Initialization Response Message 1114 A Session Initialization Response message MUST be sent in response to 1115 a received Session Initialization message (Section 10.3). The 1116 Session Initialization Response message completes the DLEP session 1117 establishment; the modem should transition to the In-Session state 1118 when the message is sent, and the router should transition to the In- 1119 Session state upon receipt of an acceptable Session Initialization 1120 Response message. 1122 All supported metric data items MUST be included in the Session 1123 Initialization Response message, with default values to be used on a 1124 'modem-wide' basis. This can be viewed as the modem 'declaring' all 1125 supported metrics at DLEP session initialization. Receipt of any 1126 DLEP message containing a metric data item not included in the 1127 Session Initialization Response message MUST be treated as an error, 1128 resulting in the termination of the DLEP session between router and 1129 modem. 1131 If any optional extensions are supported by the modem, they MUST be 1132 enumerated in the Extensions Supported data item. If an Extensions 1133 Supported data item does not exist in a Session Initialization 1134 Response message, the router MUST conclude that there is no support 1135 for extensions in the modem. 1137 After the Session Initialization/Session Initialization Response 1138 messages have been successfully exchanged, implementations MUST only 1139 use extensions that are supported by BOTH participants. 1141 To construct a Session Initialization Response message, the Message 1142 Type value in the message header is set to 4, from Table 1. 1144 The Session Initialization Response message MUST contain one of each 1145 of the following data items: 1147 o Heartbeat Interval (Section 11.5) 1149 o Maximum Data Rate (Receive) (Section 11.12) 1151 o Maximum Data Rate (Transmit) (Section 11.13) 1153 o Current Data Rate (Receive) (Section 11.14) 1155 o Current Data Rate (Transmit) (Section 11.15) 1157 o Latency (Section 11.16) 1159 The Session Initialization Response message MUST contain one of each 1160 of the following data items, if the data item will be used during the 1161 lifetime of the session: 1163 o Resources (Receive) (Section 11.17) 1165 o Resources (Transmit) (Section 11.18) 1167 o Relative Link Quality (Receive) (Section 11.19) 1169 o Relative Link Quality (Transmit) (Section 11.20) 1170 o Maximum Transmission Unit (MTU) (Section 11.21) 1172 The Session Initialization Response message MAY contain one of each 1173 of the following data items: 1175 o Status (Section 11.1) 1177 o Peer Type (Section 11.4) 1179 o Extensions Supported (Section 11.6) 1181 A router receiving a Session Initialization Response message without 1182 a Status data item MUST behave as if a Status data item with code 1183 'Success' had been received, see Table 3. 1185 10.5. Session Update Message 1187 A Session Update message MAY be sent by a DLEP participant to 1188 indicate local Layer 3 address changes, or metric changes on a modem- 1189 wide basis. It should be noted that Session Update messages can be 1190 sent by both routers and modems. For example, addition of an IPv4 1191 address to the router MAY prompt a Session Update message to its 1192 attached modems. Also, for example, a modem that changes its Maximum 1193 Data Rate (Receive) for all destinations MAY reflect that change via 1194 a Session Update message to its attached router(s). 1196 Concerning Layer 3 addresses: If the modem is capable of 1197 understanding and forwarding this information (via proprietary 1198 mechanisms), the address update would prompt any remote DLEP modems 1199 (DLEP-enabled modems in a remote node) to issue a Destination Update 1200 message (Section 10.15) to their local routers with the new (or 1201 deleted) addresses. Modems that do not track Layer 3 addresses 1202 SHOULD silently parse and ignore Layer 3 data items. The Session 1203 Update message MUST be acknowledged with a Session Update Response 1204 message (Section 10.6). 1206 If metrics are supplied with the Session Update message (e.g., 1207 Maximum Data Rate), these metrics are considered to be modem-wide, 1208 and therefore MUST be applied to all destinations in the information 1209 base associated with the DLEP session. 1211 To construct a Session Update message, the Message Type value in the 1212 message header is set to 5, from Table 1. 1214 The Session Update message MAY contain one of each of the following 1215 data items: 1217 o Maximum Data Rate (Receive) (Section 11.12) 1218 o Maximum Data Rate (Transmit) (Section 11.13) 1220 o Current Data Rate (Receive) (Section 11.14) 1222 o Current Data Rate (Transmit) (Section 11.15) 1224 o Latency (Section 11.16) 1226 The Session Update message MAY contain one of each of the following 1227 data items, if the data item is in use by the session: 1229 o Resources (Receive) (Section 11.17) 1231 o Resources (Transmit) (Section 11.18) 1233 o Relative Link Quality (Receive) (Section 11.19) 1235 o Relative Link Quality (Transmit) (Section 11.20) 1237 o Maximum Transmission Unit (MTU) (Section 11.21) 1239 The Session Update message MAY contain one or more of the following 1240 data items, with different values: 1242 o IPv4 Address (Section 11.8) 1244 o IPv6 Address (Section 11.9) 1246 A Session Update message MUST be acknowledged by the receiver issuing 1247 a Session Update Response message (Section 10.6). 1249 10.6. Session Update Response Message 1251 A Session Update Response message MUST be sent by implementations to 1252 indicate whether a Session Update message (Section 10.5) was 1253 successfully received. 1255 To construct a Session Update Response message, the Message Type 1256 value in the message header is set to 6, from Table 1. 1258 The Session Update Response message MAY contain one Status 1259 (Section 11.1) data item. 1261 A receiver of a Session Update Response message without a Status data 1262 item MUST behave as if a Status data item with status code 'Success' 1263 had been received, see Table 3. 1265 10.7. Session Termination Message 1267 A Session Termination message MUST be sent by a participant when the 1268 DLEP session needs to be terminated. It should be noted that Session 1269 Termination messages can be sent by both routers and modems. 1271 To construct a Session Termination message, the Message Type value in 1272 the message header is set to 7, from Table 1. 1274 The Session Termination message MAY contain one Status (Section 11.1) 1275 data item. 1277 A receiver of a Session Termination message without a Status data 1278 item MUST behave as if a Status data item with status code 'Success', 1279 see Table 3, implying graceful termination, had been received. 1281 A Session Termination message MUST be acknowledged by the receiver 1282 issuing a Session Termination Response message (Section 10.8). 1284 10.8. Session Termination Response Message 1286 A Session Termination Response message MUST be sent by a DLEP 1287 participant in response to a received Session Termination message 1288 (Section 10.7). 1290 Receipt of a Session Termination Response message completes the tear- 1291 down of the DLEP session. 1293 To construct a Session Termination Response message, the Message Type 1294 value in the message header is set to 8, from Table 1. 1296 The Session Termination Response message MAY contain one Status 1297 (Section 11.1) data item. 1299 A receiver of a Session Termination Response message without a Status 1300 data item MUST behave as if a Status data item with status code 1301 'Success', see Table 3, implying graceful termination, had been 1302 received. 1304 10.9. Destination Up Message 1306 A Destination Up message MUST be sent by the modem to indicate that a 1307 new destination has been detected. A Destination Up message MUST be 1308 acknowledged by the router issuing a Destination Up Response message 1309 (Section 10.10). When a Destination Up message is received and 1310 successfully processed, the router should add knowledge of the new 1311 destination to its information base, indicating that the destination 1312 is accessible via the modem. 1314 To construct a Destination Up message, the Message Type value in the 1315 message header is set to 9, from Table 1. 1317 The Destination Up message MUST contain one of each of the following 1318 data items: 1320 o MAC Address (Section 11.7) 1322 The Destination Up message MAY contain one of each of the following 1323 data items: 1325 o Maximum Data Rate (Receive) (Section 11.12) 1327 o Maximum Data Rate (Transmit) (Section 11.13) 1329 o Current Data Rate (Receive) (Section 11.14) 1331 o Current Data Rate (Transmit) (Section 11.15) 1333 o Latency (Section 11.16) 1335 The Destination Up message MAY contain one of each of the following 1336 data items, if the data item is in use by the session: 1338 o Resources (Receive) (Section 11.17) 1340 o Resources (Transmit) (Section 11.18) 1342 o Relative Link Quality (Receive) (Section 11.19) 1344 o Relative Link Quality (Transmit) (Section 11.20) 1346 o Maximum Transmission Unit (MTU) (Section 11.21) 1348 The Destination Up message MAY contain one or more of the following 1349 data items, with different values: 1351 o IPv4 Address (Section 11.8) 1353 o IPv6 Address (Section 11.9) 1355 o IPv4 Attached Subnet (Section 11.10) 1357 o IPv6 Attached Subnet (Section 11.11) 1359 If the modem has IPv4 and/or IPv6 address information for a 1360 destination it SHOULD include the relevant data items in the 1361 Destination Up message, reducing the need for the router to probe for 1362 any address. 1364 10.10. Destination Up Response Message 1366 A DLEP router MUST send a Destination Up Response message to indicate 1367 whether a Destination Up message (Section 10.9) was successfully 1368 processed. 1370 To construct a Destination Up Response message, the Message Type 1371 value in the message header is set to 10, from Table 1. 1373 The Destination Up Response message MUST contain one MAC Address 1374 (Section 11.7) data item. 1376 The Destination Up Response message MAY contain one Status 1377 (Section 11.1) data item. 1379 A modem receiving a Destination Up Response message without a Status 1380 data item MUST behave as if a Status data item with status code 1381 'Success' had been received, see Table 3. 1383 10.11. Destination Announce Message 1385 If a router wishes to request information concerning a destination 1386 that has not yet been announced by a mode via a Destination Up 1387 message (Section 10.9), it MAY send a Destination Announce message to 1388 the modem. 1390 A Destination Announce message MUST be acknowledged by the modem 1391 issuing a Destination Announce Response message (Section 10.12). 1393 To construct a Destination Announce message, the Message Type value 1394 in the message header is set to 17, from Table 1. 1396 The Destination Announce message MUST contain one of each of the 1397 following data items: 1399 o MAC Address (Section 11.7) 1401 The Destination Announce message MAY contain zero or more of the 1402 following data items, with different values: 1404 o IPv4 Address (Section 11.8) 1406 o IPv6 Address (Section 11.9) 1408 10.12. Destination Announce Response Message 1410 A DLEP modem MUST send a Destination Announce Response message to 1411 indicate whether a Destination Announce message (Section 10.11) was 1412 successfully processed and the destination identified by the MAC 1413 Address data item is available. 1415 When a Destination Announce Response message is received and 1416 successfully processed, the router should add knowledge of the new 1417 destination to its information base, indicating that the destination 1418 is accessible via the modem. 1420 To construct a Destination Announce Response message, the Message 1421 Type value in the message header is set to 18, from Table 1. 1423 The Destination Announce Response message MUST contain one of each of 1424 the following data items: 1426 o MAC Address (Section 11.7) 1428 The Destination Announce Response message MAY contain one of each of 1429 the following data items: 1431 o Maximum Data Rate (Receive) (Section 11.12) 1433 o Maximum Data Rate (Transmit) (Section 11.13) 1435 o Current Data Rate (Receive) (Section 11.14) 1437 o Current Data Rate (Transmit) (Section 11.15) 1439 o Latency (Section 11.16) 1441 The Destination Announce Response message MAY contain one of each of 1442 the following data items, if the data item is in use by the session: 1444 o Resources (Receive) (Section 11.17) 1446 o Resources (Transmit) (Section 11.18) 1448 o Relative Link Quality (Receive) (Section 11.19) 1450 o Relative Link Quality (Transmit) (Section 11.20) 1452 o Maximum Transmission Unit (MTU) (Section 11.21) 1454 The Destination Announce Response message MAY contain zero or more of 1455 the following data items, with different values: 1457 o IPv4 Address (Section 11.8) 1459 o IPv6 Address (Section 11.9) 1461 If the modem has IPv4 and/or IPv6 address information for a 1462 destination it SHOULD include the relevant data items in the 1463 Destination Announce Response message, reducing the need for the 1464 router to probe for any address. 1466 o Status (Section 11.1) 1468 A router receiving a Destination Announce Response message without a 1469 Status data item MUST behave as if a Status data item with status 1470 code 'Success' had been received, see Table 3. 1472 If a modem does not support Destination Announce messages, or the 1473 modem is unable to report information immediately about the requested 1474 information, if the destination is not currently accessible, for 1475 example, the status code in the Status data item SHOULD be set to 1476 'Request Denied'. 1478 10.13. Destination Down Message 1480 A DLEP participant MUST send a Destination Down message to report 1481 when a destination (a remote node or a multicast group) is no longer 1482 reachable. A Destination Down Response message (Section 10.14) MUST 1483 be sent by the recipient of a Destination Down message to confirm 1484 that the relevant data has been removed from the information base. 1486 To construct a Destination Down message, the Message Type value in 1487 the message header is set to 11, from Table 1. 1489 The Destination Down message MUST contain one of each of the 1490 following data items: 1492 o MAC Address (Section 11.7) 1494 It should be noted that both modem and router may send a Destination 1495 Down message to its peer. 1497 10.14. Destination Down Response Message 1499 A DLEP participant MUST send a Destination Down Response message to 1500 indicate whether a received Destination Down message (Section 10.13) 1501 was successfully processed. If successfully processed, the sender of 1502 the Response MUST have removed all entries in the information base 1503 that pertain to the referenced destination. 1505 To construct a Destination Down Response message, the Message Type 1506 value in the message header is set to 12, from Table 1. 1508 The Destination Down Response message MUST contain one of each of the 1509 following data items: 1511 o MAC Address (Section 11.7) 1513 The Destination Down Response message MAY contain one of each of the 1514 following data items: 1516 o Status (Section 11.1) 1518 A receiver of a Destination Down Response message without a Status 1519 data item MUST behave as if a Status data item with status code 1520 'Success' had been received, see Table 3. 1522 10.15. Destination Update Message 1524 A DLEP modem SHOULD send the Destination Update message when it 1525 detects some change in the information base for a given destination 1526 (remote node or multicast group). Some examples of changes that 1527 would prompt a Destination Update message are: 1529 o Change in link metrics (e.g., Data Rates) 1531 o Layer 3 addressing change 1533 To construct a Destination Update message, the Message Type value in 1534 the message header is set to 13, from Table 1. 1536 The Destination Update message MUST contain one of each of the 1537 following data items: 1539 o MAC Address (Section 11.7) 1541 The Destination Update message MAY contain one of each of the 1542 following data items: 1544 o Maximum Data Rate (Receive) (Section 11.12) 1546 o Maximum Data Rate (Transmit) (Section 11.13) 1548 o Current Data Rate (Receive) (Section 11.14) 1550 o Current Data Rate (Transmit) (Section 11.15) 1552 o Latency (Section 11.16) 1553 The Destination Update message MAY contain one of each of the 1554 following data items, if the data item is in use by the session: 1556 o Resources (Receive) (Section 11.17) 1558 o Resources (Transmit) (Section 11.18) 1560 o Relative Link Quality (Receive) (Section 11.19) 1562 o Relative Link Quality (Transmit) (Section 11.20) 1564 o Maximum Transmission Unit (MTU) (Section 11.21) 1566 The Destination Update message MAY contain one or more of the 1567 following data items, with different values: 1569 o IPv4 Address (Section 11.8) 1571 o IPv6 Address (Section 11.9) 1573 o IPv4 Attached Subnet (Section 11.10) 1575 o IPv6 Attached Subnet (Section 11.11) 1577 10.16. Heartbeat Message 1579 While Heartbeat messages are not required by DLEP implementations, it 1580 is strongly RECOMMENDED that Heartbeat messages be used. 1582 A Heartbeat message SHOULD be sent by a DLEP participant every N 1583 seconds, where N is defined in the Heartbeat Interval data item of 1584 the Session Initialization message (Section 10.3) or Session 1585 Initialization Response message (Section 10.4). 1587 Note that implementations setting the Heartbeat Interval to 0 1588 effectively sets the interval to an infinite value, turning off 1589 Heartbeat messages. Great care MUST be taken when exercising this 1590 option. 1592 The message is used by participants to detect when a DLEP session 1593 peer (either the modem or the router) is no longer communicating. 1594 Participants SHOULD allow two (2) heartbeat intervals to expire with 1595 no messages from the peer before initiating DLEP session termination 1596 procedures. 1598 To construct a Heartbeat message, the Message Type value in the 1599 message header is set to 14, from Table 1. 1601 There are no valid data items for the Heartbeat message. 1603 10.17. Link Characteristics Request Message 1605 The Link Characteristics Request message MAY be sent by a DLEP router 1606 to request that the modem initiate changes for specific 1607 characteristics of the link. The request can reference either a real 1608 destination (e.g., a remote node), or a logical destination (e.g., a 1609 multicast group) within the network. 1611 The Link Characteristics Request message MAY contain either a Current 1612 Data Rate (CDRR or CDRT) data item to request a different datarate 1613 than what is currently allocated, a Latency data item to request that 1614 traffic delay on the link not exceed the specified value, or both. A 1615 Link Characteristics Response message (Section 10.18) is required to 1616 complete the request. Issuing a Link Characteristics Request with 1617 ONLY the MAC Address data item is a mechanism a router MAY use to 1618 request metrics (via the Link Characteristics Response) from its 1619 modem. 1621 The router sending a Link Characteristics Request message should be 1622 aware that a request may take an extended period of time to complete. 1624 To construct a Link Characteristics Request message, the Message Type 1625 value in the message header is set to 15, from Table 1. 1627 The Link Characteristics Request message MUST contain one of each of 1628 the following data items: 1630 o MAC Address (Section 11.7) 1632 The Link Characteristics Request message MAY contain one of each of 1633 the following data items: 1635 o Current Data Rate (Receive) (Section 11.14) 1637 o Current Data Rate (Transmit) (Section 11.15) 1639 o Latency (Section 11.16) 1641 10.18. Link Characteristics Response Message 1643 A DLEP modem MUST send a Link Characteristics Response message to 1644 indicate whether a received Link Characteristics Request message 1645 (Section 10.17) was successfully processed. The Link Characteristics 1646 Response message SHOULD contain a complete set of metric data items, 1647 and MUST contain a full set (i.e. those declared in the Session 1648 Initialization Response message (Section 10.4)), if metrics were 1649 requested by only including a MAC address data item. It MUST contain 1650 the same metric types as the request. The values in the metric data 1651 items in the Link Characteristics Response message MUST reflect the 1652 link characteristics after the request has been processed. 1654 If an implementation is not able to alter the characteristics of the 1655 link in the manner requested, then the message MUST contain a Status 1656 data item with status code 'Request Denied', see Table 3. 1658 To construct a Link Characteristics Response message, the Message 1659 Type value in the message header is set to 16, from Table 1. 1661 The Link Characteristics Response message MUST contain one of each of 1662 the following data items: 1664 o MAC Address (Section 11.7) 1666 The Link Characteristics Response message SHOULD contain one of each 1667 of the following data items: 1669 o Maximum Data Rate (Receive) (Section 11.12) 1671 o Maximum Data Rate (Transmit) (Section 11.13) 1673 o Current Data Rate (Receive) (Section 11.14) 1675 o Current Data Rate (Transmit) (Section 11.15) 1677 o Latency (Section 11.16) 1679 The Link Characteristics Response message MAY contain one of each of 1680 the following data items: 1682 o Status (Section 11.1) 1684 The Link Characteristics Response message MAY contain one of each of 1685 the following data items, if the data item is in use by the session: 1687 o Resources (Receive) (Section 11.17) 1689 o Resources (Transmit) (Section 11.18) 1691 o Relative Link Quality (Receive) (Section 11.19) 1693 o Relative Link Quality (Transmit) (Section 11.20) 1695 o Maximum Transmission Unit (MTU) (Section 11.21) 1696 A router receiving a Link Characteristics Response message without a 1697 Status data item MUST behave as if a Status data item with status 1698 code 'Success', see Table 3, had been received. 1700 11. DLEP Data Items 1702 Following is the list of core data items that MUST be recognized by a 1703 DLEP compliant implementation. As mentioned before, not all data 1704 items need be used during a session, but an implementation MUST 1705 correctly process these data items when correctly associated with a 1706 signal or message. 1708 The core DLEP data items are: 1710 +-------------+-----------------------------------------------------+ 1711 | Type Code | Description | 1712 +-------------+-----------------------------------------------------+ 1713 | 0 | Reserved | 1714 | 1 | Status (Section 11.1) | 1715 | 2 | IPv4 Connection Point (Section 11.2) | 1716 | 3 | IPv6 Connection Point (Section 11.3) | 1717 | 4 | Peer Type (Section 11.4) | 1718 | 5 | Heartbeat Interval (Section 11.5) | 1719 | 6 | Extensions Supported (Section 11.6) | 1720 | 7 | MAC Address (Section 11.7) | 1721 | 8 | IPv4 Address (Section 11.8) | 1722 | 9 | IPv6 Address (Section 11.9) | 1723 | 10 | IPv4 Attached Subnet (Section 11.10) | 1724 | 11 | IPv6 Attached Subnet (Section 11.11) | 1725 | 12 | Maximum Data Rate (Receive) MDRR) (Section 11.12) | 1726 | 13 | Maximum Data Rate (Transmit) (MDRT) (Section 11.13) | 1727 | 14 | Current Data Rate (Receive) (CDRR) (Section 11.14) | 1728 | 15 | Current Data Rate (Transmit) (CDRT) (Section 11.15) | 1729 | 16 | Latency (Section 11.16) | 1730 | 17 | Resources (Receive) (RESR) (Section 11.17) | 1731 | 18 | Resources (Transmit) (REST) (Section 11.18) | 1732 | 19 | Relative Link Quality (Receive) (RLQR) (Section | 1733 | | 11.19) | 1734 | 20 | Relative Link Quality (Transmit) (RLQT) (Section | 1735 | | 11.20) | 1736 | 21 | Maximum Transmission Unit (MTU) (Section 11.21) | 1737 | 22-65407 | Reserved for future extensions | 1738 | 65408-65534 | Private Use. Available for experiments | 1739 | 65535 | Reserved | 1740 +-------------+-----------------------------------------------------+ 1742 Table 2: DLEP Data Item types 1744 11.1. Status 1746 The Status data item MAY appear in the Session Initialization 1747 Response (Section 10.4), Session Termination (Section 10.7), Session 1748 Termination Response (Section 10.8), Session Update Response 1749 (Section 10.6), Destination Up Response (Section 10.10), Destination 1750 Down Response (Section 10.14) and Link Characteristics Response 1751 (Section 10.18) messages. 1753 For the Session Termination message (Section 10.7), the Status data 1754 item indicates a reason for the termination. For all acknowledgement 1755 messages, the Status data item is used to indicate the success or 1756 failure of the previously received message. 1758 The status data item includes an optional Text field that can be used 1759 to provide a textual description of the status. The use of the Text 1760 field is entirely up to the receiving implementation, i.e., it could 1761 be output to a log file or discarded. If no Text field is supplied 1762 with the Status data item, the Length field MUST be set to 1. 1764 The Status data item contains the following fields: 1766 0 1 2 3 1767 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 1768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1769 | Data Item Type | Length | 1770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1771 | Code | Text... : 1772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1774 Data Item Type: 1 1776 Length: 1 + Length of text, in octets 1778 Status Code: One of the codes defined in Table 3 below. 1780 Text: UTF-8 encoded string, describing the cause, used for 1781 implementation defined purposes. Since this field is used for 1782 description, implementations SHOULD limit characters in this field 1783 to printable characters. Implementations receiving this data item 1784 SHOULD check for printable characters in the field. 1786 An implementation MUST NOT assume the Text field is NUL-terminated. 1788 +-------------+---------+-----------+-------------------------------+ 1789 | Status Code | Value | Failure | Reason | 1790 | | | Mode | | 1791 +-------------+---------+-----------+-------------------------------+ 1792 | Success | 0 | Success | The message was processed | 1793 | | | | successfully. | 1794 | Unknown | 1 | Terminate | The message was not | 1795 | Message | | | recognized by the | 1796 | | | | implementation. | 1797 | Unexpected | 2 | Terminate | The message was not expected | 1798 | Message | | | while the device was in the | 1799 | | | | current state, e.g., a | 1800 | | | | Session Initialization | 1801 | | | | message (Section 10.3) in the | 1802 | | | | In-Session state. | 1803 | Invalid | 3 | Terminate | One or more data items in the | 1804 | Data | | | message are invalid, | 1805 | | | | unexpected or incorrectly | 1806 | | | | duplicated. | 1807 | Invalid | 4 | Terminate | The destination provided in | 1808 | Destination | | | the message does not match a | 1809 | | | | previously announced | 1810 | | | | destination. For example, in | 1811 | | | | the Link Characteristic | 1812 | | | | Response message (Section | 1813 | | | | 10.18). | 1814 | Timed Out | 5 | Terminate | The session has timed out. | 1815 | | 6-90 | Terminate | Reserved for future | 1816 | | | | extensions. | 1817 | | | | | 1819 | Not | 100 | Continue | The receiver is not | 1820 | Interested | | | interested in this message | 1821 | | | | subject, e.g. a Destination | 1822 | | | | Up Response message (Section | 1823 | | | | 10.10) to indicate no further | 1824 | | | | messages about the | 1825 | | | | destination. | 1826 | Request | 101 | Continue | The receiver refuses to | 1827 | Denied | | | complete the request. | 1828 | | 102-243 | Continue | Reserved for future | 1829 | | | | extensions. | 1830 | | | | | 1832 | | 255 | Terminate | Reserved. | 1833 +-------------+---------+-----------+-------------------------------+ 1835 Table 3: DLEP Status Codes 1837 A failure mode of 'Terminate' indicates that the session MUST be 1838 terminated immediately instead of sending any relevant response 1839 message, by sending a Session Termination message (Section 10.7) 1840 containing the status code, and then transitioning to the Session 1841 Termination state. 1843 A failure mode of 'Continue' indicates that the session SHOULD 1844 continue as normal. 1846 11.2. IPv4 Connection Point 1848 The IPv4 Connection Point data item MAY appear in the Peer Offer 1849 signal (Section 10.2). 1851 The IPv4 Connection Point data item indicates the IPv4 address and, 1852 optionally, the TCP port number on the DLEP modem available for 1853 connections. If provided, the router MUST use this information to 1854 perform the TCP connect to the modem. 1856 The IPv4 Connection Point data item contains the following fields: 1858 0 1 2 3 1859 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 1860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1861 | Data Item Type | Length | 1862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1863 | Flags | IPv4 Address... : 1864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1865 : ...cont. | TCP Port Number (optional) | 1866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1868 Data Item Type: 2 1870 Length: 5 (or 7 if TCP Port included) 1872 Flags: Flags field, defined below. 1874 IPv4 Address: The IPv4 address listening on the DLEP modem. 1876 TCP Port Number: TCP Port number on the DLEP modem. 1878 If the Length field is 7, the port number specified MUST be used to 1879 establish the TCP session. If the TCP Port Number is omitted, i.e. 1880 the Length field is 5, the router MUST use the DLEP well-known port 1881 number (Section 13.6) to establish the TCP connection. 1883 The Flags field is defined as: 1885 0 1 2 3 4 5 6 7 1886 +-+-+-+-+-+-+-+-+ 1887 | Reserved |T| 1888 +-+-+-+-+-+-+-+-+ 1890 T: Use TLS flag, indicating whether the TCP connection requires the 1891 use of TLS (1), or not (0). 1893 Reserved: MUST be zero. Reserved for future use. 1895 11.3. IPv6 Connection Point 1897 The IPv6 Connection Point data item MAY appear in the Peer Offer 1898 signal (Section 10.2). 1900 The IPv6 Connection Point data item indicates the IPv6 address and, 1901 optionally, the TCP port number on the DLEP modem available for 1902 connections. If provided, the router MUST use this information to 1903 perform the TCP connect to the modem. 1905 The IPv6 Connection Point data item contains the following fields: 1907 0 1 2 3 1908 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 1909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1910 | Data Item Type | Length | 1911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1912 | Flags | IPv6 Address : 1913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1914 : IPv6 Address : 1915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1916 : IPv6 Address : 1917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1918 : IPv6 Address : 1919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1920 : ...cont. | TCP Port Number (optional) | 1921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1923 Data Item Type: 3 1925 Length: 17 (or 19 if TCP Port included) 1927 Flags: Flags field, defined below. 1929 IPv6 Address: The IPv6 address listening on the DLEP modem. 1931 TCP Port Number: TCP Port number on the DLEP modem. 1933 If the Length field is 19, the port number specified MUST be used to 1934 establish the TCP session. If the TCP Port Number is omitted, i.e. 1935 the Length field is 17, the router MUST use the DLEP well-known port 1936 number (Section 13.6) to establish the TCP connection. 1938 The Flags field is defined as: 1940 0 1 2 3 4 5 6 7 1941 +-+-+-+-+-+-+-+-+ 1942 | Reserved |T| 1943 +-+-+-+-+-+-+-+-+ 1945 T: Use TLS flag, indicating whether the TCP connection requires the 1946 use of TLS (1), or not (0). 1948 Reserved: MUST be zero. Reserved for future use. 1950 11.4. Peer Type 1952 The Peer Type data item MAY appear in the Peer Discovery 1953 (Section 10.1) and Peer Offer (Section 10.2) signals, and the Session 1954 Initialization (Section 10.3) and Session Initialization Response 1955 (Section 10.4) messages. 1957 The Peer Type data item is used by the router and modem to give 1958 additional information as to its type. The peer type is a string and 1959 is envisioned to be used for informational purposes (e.g., as output 1960 in a display command). 1962 The Peer Type data item contains the following fields: 1964 0 1 2 3 1965 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 1966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1967 | Data Item Type | Length | 1968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1969 | Peer Type... : 1970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1972 Data Item Type: 4 1974 Length: Length of peer type string, in octets. 1976 Peer Type: UTF-8 encoded string. For example, a satellite modem 1977 might set this variable to "Satellite terminal". Since this data 1978 item is intended to provide additional information for display 1979 commands, sending implementations SHOULD limit the data to 1980 printable characters, and receiving implementations SHOULD check 1981 the data for printable characters. 1983 An implementation MUST NOT assume the Peer Type field is NUL- 1984 terminated. 1986 11.5. Heartbeat Interval 1988 The Heartbeat Interval data item MUST appear in both the Session 1989 Initialization (Section 10.3) and Session Initialization Response 1990 (Section 10.4) messages to indicate the Heartbeat timeout window to 1991 be used by the sender. 1993 The Interval is used to specify a period (in seconds) for Heartbeat 1994 messages (Section 10.16). By specifying an Interval value of 0, 1995 implementations MAY indicate the desire to disable Heartbeat messages 1996 entirely (i.e., the Interval is set to an infinite value). However, 1997 it is RECOMMENDED that implementations use non-0 timer values. 1999 The Heartbeat Interval data item contains the following fields: 2001 0 1 2 3 2002 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 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2004 | Data Item Type | Length | 2005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2006 | Interval | 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2009 Data Item Type: 5 2011 Length: 2 2013 Interval: 0 = Do not use heartbeats on this DLEP session. Non-zero 2014 = Interval, in seconds, for heartbeat messages. 2016 11.6. Extensions Supported 2018 The Extensions Supported data item MAY be used in both the Session 2019 Initialization (Section 10.3) and Session Initialization Response 2020 (Section 10.4) messages. 2022 The Extensions Supported data item is used by the router and modem to 2023 negotiate additional optional functionality they are willing to 2024 support. The Extensions List is a concatenation of the types of each 2025 supported extension, found in the IANA DLEP Extensions repository. 2026 Each Extension Type definition includes which additional signals and 2027 data-items are supported. 2029 The Extensions Supported data item contains the following fields: 2031 0 1 2 3 2032 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 2033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2034 | Data Item Type | Length | 2035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2036 | Extensions List... 2037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2039 Data Item Type: 6 2041 Length: Length of the extensions list in octets. This is twice (2x) 2042 the number of extensions. 2044 Extension List: A list of extensions supported, identified by their 2045 2-octet value as listed in the extensions registry. 2047 11.7. MAC Address 2049 The MAC address data item MUST appear in all destination-oriented 2050 messages (i.e., Destination Up (Section 10.9), Destination Up 2051 Response (Section 10.10), Destination Down (Section 10.13), 2052 Destination Down Response (Section 10.14), Destination Update 2053 (Section 10.15), Link Characteristics Request (Section 10.17), and 2054 Link Characteristics Response (Section 10.18)). 2056 The MAC Address data item contains the address of the destination on 2057 the remote node. The MAC address MAY be either a physical or a 2058 virtual destination, and MAY be expressed in EUI-48 or EUI-64 format. 2059 Examples of a virtual destination would be a multicast MAC address, 2060 or the broadcast MAC (FF:FF:FF:FF:FF:FF). 2062 0 1 2 3 2063 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 2064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2065 | Data Item Type | Length | 2066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2067 | MAC Address : 2068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2069 : MAC Address : 2070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2071 : MAC Address : (if EUI-64 used) | 2072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2074 Data Item Type: 7 2076 Length: 6 for EUI-48 format, or 8 for EUI-64 format 2077 MAC Address: MAC Address of the destination. 2079 11.8. IPv4 Address 2081 The IPv4 Address data item MAY appear in the Session Update 2082 (Section 10.5), Destination Up (Section 10.9) and Destination Update 2083 (Section 10.15) messages. 2085 When included in Destination messages, this data item contains the 2086 IPv4 address of the destination. When included in the Session Update 2087 message, this data item contains the IPv4 address of the peer. In 2088 either case, the data item also contains an indication of whether 2089 this is a new or existing address, or is a deletion of a previously 2090 known address. 2092 The IPv4 Address data item contains the following fields: 2094 0 1 2 3 2095 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 2096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2097 | Data Item Type | Length | 2098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2099 | Flags | IPv4 Address : 2100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2101 : ...cont. | 2102 +-+-+-+-+-+-+-+-+ 2104 Data Item Type: 8 2106 Length: 5 2108 Flags: Flags field, defined below. 2110 IPv4 Address: The IPv4 address of the destination or peer. 2112 The Flags field is defined as: 2114 0 1 2 3 4 5 6 7 2115 +-+-+-+-+-+-+-+-+ 2116 | Reserved |A| 2117 +-+-+-+-+-+-+-+-+ 2119 A: Add/Drop flag, indicating whether this is a new or existing 2120 address (1), or a withdrawal of an address (0). 2122 Reserved: MUST be zero. Reserved for future use. 2124 11.9. IPv6 Address 2126 The IPv6 Address data item MAY appear in the Session Update 2127 (Section 10.5), Destination Up (Section 10.9) and Destination Update 2128 (Section 10.15) messages. When included in Destination messages, 2129 this data item contains the IPv6 address of the destination. When 2130 included in the Session Update message, this data item contains the 2131 IPv6 address of the peer. In either case, the data item also 2132 contains an indication of whether this is a new or existing address, 2133 or is a deletion of a previously known address. 2135 The IPv6 Address data item contains the following fields: 2137 0 1 2 3 2138 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 2139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2140 | Data Item Type | Length | 2141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2142 | Flags | IPv6 Address : 2143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2144 : IPv6 Address : 2145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2146 : IPv6 Address : 2147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2148 : IPv6 Address : 2149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2150 : IPv6 Address | 2151 +-+-+-+-+-+-+-+-+ 2153 Data Item Type: 9 2155 Length: 17 2157 Flags: Flags field, defined below. 2159 IPv6 Address: IPv6 Address of the destination or peer. 2161 The Flags field is defined as: 2163 0 1 2 3 4 5 6 7 2164 +-+-+-+-+-+-+-+-+ 2165 | Reserved |A| 2166 +-+-+-+-+-+-+-+-+ 2168 A: Add/Drop flag, indicating whether this is a new or existing 2169 address (1), or a withdrawal of an address (0). 2171 Reserved: MUST be zero. Reserved for future use. 2173 11.10. IPv4 Attached Subnet 2175 The DLEP IPv4 Attached Subnet allows a device to declare that it has 2176 an IPv4 subnet (e.g., a stub network) attached, that it has become 2177 aware of an IPv4 subnet being present at a remote destination, or 2178 that it has become aware of the loss of a subnet at the remote 2179 destination. The IPv4 Attached Subnet data item MAY appear in the 2180 Destination Up (Section 10.9) and Destination Update (Section 10.15) 2181 messages. 2183 The DLEP IPv4 Attached Subnet data item contains the following 2184 fields: 2186 0 1 2 3 2187 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 2188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2189 | Data Item Type | Length | 2190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2191 | Flags | IPv4 Attached Subnet : 2192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2193 : ...cont. |Prefix Length | 2194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2196 Data Item Type: 10 2198 Length: 6 2200 Flags: Flags field, defined below. 2202 IPv4 Subnet: The IPv4 subnet reachable at the destination. 2204 Prefix Length: Length of the prefix (1-32) for the IPv4 subnet. A 2205 prefix length outside the specified range MUST be considered as 2206 invalid. 2208 The Flags field is defined as: 2210 0 1 2 3 4 5 6 7 2211 +-+-+-+-+-+-+-+-+ 2212 | Reserved |A| 2213 +-+-+-+-+-+-+-+-+ 2215 A: Add/Drop flag, indicating whether this is a new or existing subnet 2216 address (1), or a withdrawal of a subnet address (0). 2218 Reserved: MUST be zero. Reserved for future use. 2220 11.11. IPv6 Attached Subnet 2222 The DLEP IPv6 Attached Subnet allows a device to declare that it has 2223 an IPv6 subnet (e.g., a stub network) attached, or that it has become 2224 aware of an IPv6 subnet being present at a remote destination. The 2225 IPv6 Attached Subnet data item MAY appear in the Destination Up 2226 (Section 10.9) and Destination Update (Section 10.15) messages. 2228 The DLEP IPv6 Attached Subnet data item contains the following 2229 fields: 2231 0 1 2 3 2232 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 2233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2234 | Data Item Type | Length | 2235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2236 | Flags | IPv6 Attached Subnet : 2237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2238 : IPv6 Attached Subnet : 2239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2240 : IPv6 Attached Subnet : 2241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2242 : IPv6 Attached Subnet : 2243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2244 : ...cont. | Prefix Len. | 2245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2247 Data Item Type: 11 2249 Length: 18 2251 Flags: Flags field, defined below. 2253 IPv6 Attached Subnet: The IPv6 subnet reachable at the destination. 2255 Prefix Length: Length of the prefix (1-128) for the IPv6 subnet. A 2256 prefix length outside the specified range MUST be considered as 2257 invalid. 2259 The Flags field is defined as: 2261 0 1 2 3 4 5 6 7 2262 +-+-+-+-+-+-+-+-+ 2263 | Reserved |A| 2264 +-+-+-+-+-+-+-+-+ 2266 A: Add/Drop flag, indicating whether this is a new or existing subnet 2267 address (1), or a withdrawal of a subnet address (0). 2269 Reserved: MUST be zero. Reserved for future use. 2271 11.12. Maximum Data Rate (Receive) 2273 The Maximum Data Rate (Receive) (MDRR) data item MUST appear in the 2274 Session Initialization Response message (Section 10.4), and MAY 2275 appear in the Session Update (Section 10.5), Destination Up 2276 (Section 10.9), Destination Update (Section 10.15) and Link 2277 Characteristics Response (Section 10.18) messages to indicate the 2278 maximum theoretical data rate, in bits per second, that can be 2279 achieved while receiving data on the link. 2281 The Maximum Data Rate (Receive) data item contains the following 2282 fields: 2284 0 1 2 3 2285 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 2286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2287 | Data Item Type | Length | 2288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2289 | MDRR (bps) : 2290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2291 : MDRR (bps) | 2292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2294 Data Item Type: 12 2296 Length: 8 2298 Maximum Data Rate (Receive): A 64-bit unsigned integer, representing 2299 the maximum theoretical data rate, in bits per second (bps), that 2300 can be achieved while receiving on the link. 2302 11.13. Maximum Data Rate (Transmit) 2304 The Maximum Data Rate (Transmit) (MDRT) data item MUST appear in the 2305 Session Initialization Response message (Section 10.4), and MAY 2306 appear in the Session Update (Section 10.5), Destination Up 2307 (Section 10.9), Destination Update (Section 10.15) and Link 2308 Characteristics Response (Section 10.18) messages to indicate the 2309 maximum theoretical data rate, in bits per second, that can be 2310 achieved while transmitting data on the link. 2312 The Maximum Data Rate (Transmit) data item contains the following 2313 fields: 2315 0 1 2 3 2316 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 2317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2318 | Data Item Type | Length | 2319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2320 | MDRT (bps) : 2321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2322 : MDRT (bps) | 2323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2325 Data Item Type: 13 2327 Length: 8 2329 Maximum Data Rate (Transmit): A 64-bit unsigned integer, 2330 representing the maximum theoretical data rate, in bits per second 2331 (bps), that can be achieved while transmitting on the link. 2333 11.14. Current Data Rate (Receive) 2335 The Current Data Rate (Receive) (CDRR) data item MUST appear in the 2336 Session Initialization Response message (Section 10.4), and MAY 2337 appear in the Session Update (Section 10.5), Destination Up 2338 (Section 10.9), Destination Update (Section 10.15) and Link 2339 Characteristics Response (Section 10.18) messages to indicate the 2340 rate at which the link is currently operating for receiving traffic. 2342 When used in the Link Characteristics Request message 2343 (Section 10.17), CDRR represents the desired receive rate, in bits 2344 per second, on the link. 2346 The Current Data Rate (Receive) data item contains the following 2347 fields: 2349 0 1 2 3 2350 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 2351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2352 | Data Item Type | Length | 2353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2354 | CDRR (bps) : 2355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2356 : CDRR (bps) | 2357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2359 Data Item Type: 14 2361 Length: 8 2362 Current Data Rate (Receive): A 64-bit unsigned integer, representing 2363 the current data rate, in bits per second, that can currently be 2364 achieved while receiving traffic on the link. 2366 If there is no distinction between current and maximum receive data 2367 rates, current data rate receive MUST be set equal to the maximum 2368 data rate receive. 2370 11.15. Current Data Rate (Transmit) 2372 The Current Data Rate Transmit (CDRT) data item MUST appear in the 2373 Session Initialization Response message (Section 10.4), and MAY 2374 appear in the Session Update (Section 10.5), Destination Up 2375 (Section 10.9), Destination Update (Section 10.15), and Link 2376 Characteristics Response (Section 10.18) messages to indicate the 2377 rate at which the link is currently operating for transmitting 2378 traffic. 2380 When used in the Link Characteristics Request message 2381 (Section 10.17), CDRT represents the desired transmit rate, in bits 2382 per second, on the link. 2384 The Current Data Rate (Transmit) data item contains the following 2385 fields: 2387 0 1 2 3 2388 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 2389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2390 | Data Item Type | Length | 2391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2392 | CDRT (bps) : 2393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2394 : CDRT (bps) | 2395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2397 Data Item Type: 15 2399 Length: 8 2401 Current Data Rate (Transmit): A 64-bit unsigned integer, 2402 representing the current data rate, in bits per second, that can 2403 currently be achieved while transmitting traffic on the link. 2405 If there is no distinction between current and maximum transmit data 2406 rates, current data rate transmit MUST be set equal to the maximum 2407 data rate transmit. 2409 11.16. Latency 2411 The Latency data item MUST appear in the Session Initialization 2412 Response message (Section 10.4), and MAY appear in the Session Update 2413 (Section 10.5), Destination Up (Section 10.9), Destination Update 2414 (Section 10.15), and Link Characteristics Response (Section 10.18) 2415 messages to indicate the amount of latency, in microseconds, on the 2416 link. 2418 When used in the Link Characteristics Request message 2419 (Section 10.17), Latency represents the maximum latency desired on 2420 the link. 2422 The Latency value is reported as delay. The calculation of latency 2423 is implementation dependent. For example, the latency may be a 2424 running average calculated from the internal queuing. 2426 0 1 2 3 2427 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 2428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2429 | Data Item Type | Length | 2430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2431 | Latency : 2432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2433 : Latency | 2434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2436 Data Item Type: 16 2438 Length: 8 2440 Latency: A 64-bit unsigned integer, representing the transmission 2441 delay, in microseconds, that a packet encounters as it is 2442 transmitted over the link. 2444 11.17. Resources (Receive) 2446 The Resources (Receive) (RESR) data item MAY appear in the Session 2447 Initialization Response message (Section 10.4), Session Update 2448 (Section 10.5), Destination Up (Section 10.9), Destination Update 2449 (Section 10.15) and Link Characteristics Response (Section 10.18) 2450 messages to indicate the amount of resources for reception (with 0 2451 meaning 'no resources available', and 100 meaning 'all resources 2452 available') at the destination. The list of resources that might be 2453 considered is beyond the scope of this document, and is left to 2454 implementations to decide. 2456 The Resources (Receive) data item contains the following fields: 2458 0 1 2 3 2459 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 2460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2461 | Data Item Type | Length | 2462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2463 | RESR | 2464 +-+-+-+-+-+-+-+-+ 2466 Data Item Type: 17 2468 Length: 1 2470 Resources (Receive): An 8-bit integer percentage, 0-100, 2471 representing the amount of resources allocated to receiving data. 2472 Any value greater than 100 MUST be considered as invalid. 2474 If a device cannot calculate RESR, this data item SHOULD NOT be 2475 issued. 2477 11.18. Resources (Transmit) 2479 The Resources (Transmit) (REST) data item MAY appear in the Session 2480 Initialization Response message (Section 10.4), Session Update 2481 (Section 10.5), Destination Up (Section 10.9), Destination Update 2482 (Section 10.15) and Link Characteristics Response (Section 10.18) 2483 messages to indicate the amount of resources for transmission (with 0 2484 meaning 'no resources available', and 100 meaning 'all resources 2485 available') at the destination. The list of resources that might be 2486 considered is beyond the scope of this document, and is left to 2487 implementations to decide. 2489 The Resources (Transmit) data item contains the following fields: 2491 0 1 2 3 2492 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 2493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2494 | Data Item Type | Length | 2495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2496 | REST | 2497 +-+-+-+-+-+-+-+-+ 2499 Data Item Type: 18 2501 Length: 1 2503 Resources (Transmit): An 8-bit integer percentage, 0-100, 2504 representing the amount of resources allocated to transmitting 2505 data. Any value greater than 100 MUST be considered as invalid. 2507 If a device cannot calculate REST, this data item SHOULD NOT be 2508 issued. 2510 11.19. Relative Link Quality (Receive) 2512 The Relative Link Quality (Receive) (RLQR) data item MAY appear in 2513 the Session Initialization Response message (Section 10.4), Session 2514 Update (Section 10.5), Destination Up (Section 10.9), Destination 2515 Update (Section 10.15) and Link Characteristics Response 2516 (Section 10.18) messages to indicate the quality of the link for 2517 receiving data. 2519 The Relative Link Quality (Receive) data item contains the following 2520 fields: 2522 0 1 2 3 2523 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 2524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2525 | Data Item Type | Length | 2526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2527 | RLQR | 2528 +-+-+-+-+-+-+-+-+ 2530 Data Item Type: 19 2532 Length: 1 2534 Relative Link Quality (Receive): A non-dimensional 8-bit integer, 2535 0-100, representing relative link quality. A value of 100 2536 represents a link of the highest quality. Any value greater than 2537 100 MUST be considered as invalid. 2539 If a device cannot calculate the RLQR, this data item SHOULD NOT be 2540 issued. 2542 11.20. Relative Link Quality (Transmit) 2544 The Relative Link Quality (Transmit) (RLQT) data item MAY appear in 2545 the Session Initialization Response message (Section 10.4), Session 2546 Update (Section 10.5), Destination Up (Section 10.9), Destination 2547 Update (Section 10.15) and Link Characteristics Response 2548 (Section 10.18) messages to indicate the quality of the link for 2549 transmitting data. 2551 The Relative Link Quality (Transmit) data item contains the following 2552 fields: 2554 0 1 2 3 2555 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 2556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2557 | Data Item Type | Length | 2558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2559 | RLQT | 2560 +-+-+-+-+-+-+-+-+ 2562 Data Item Type: 20 2564 Length: 1 2566 Relative Link Quality (Transmit): A non-dimensional 8-bit integer, 2567 0-100, representing relative link quality. A value of 100 2568 represents a link of the highest quality. Any value greater than 2569 100 MUST be considered as invalid. 2571 If a device cannot calculate the RLQT, this data item SHOULD NOT be 2572 issued. 2574 11.21. Maximum Transmission Unit (MTU) 2576 The Maximum Transmission Unit (MTU) data item MAY appear in the 2577 Session Initialization Response message (Section 10.4), Session 2578 Update (Section 10.5), Destination Up (Section 10.9), Destination 2579 Update (Section 10.15) and Link Characteristics Response 2580 (Section 10.18) messages to indicate the maximum size, in octets, of 2581 an IP packet that can be transmitted without fragmentation, including 2582 headers, but excluding any lower layer headers. 2584 The Maximum Transmission Unit (MTU) data item contains the following 2585 fields: 2587 0 1 2 3 2588 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 2589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2590 | Data Item Type | Length | 2591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2592 | MTU | 2593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2595 Data Item Type: 21 2597 Length: 2 2599 Maximum Transmission Unit (MTU): The maximum size, in octets, of an 2600 IP packet that can be transmitted without fragmentation, including 2601 headers, but excluding any lower layer headers. 2603 If a device cannot calculate the MTU, this data item SHOULD NOT be 2604 issued. 2606 12. Security Considerations 2608 The potential security concerns when using DLEP are: 2610 1. An attacker might pretend to be a DLEP peer, either at DLEP 2611 session initialization, or by injection of messages once a 2612 session has been established, and/or 2614 2. DLEP data items could be altered by an attacker, causing the 2615 receiving implementation to inappropriately alter its information 2616 base concerning network status. 2618 Since DLEP is restricted to operation over a single (possibly 2619 logical) hop at layer 2, implementations requiring authentication 2620 and/or encryption of traffic MUST take steps to secure the Layer 2 2621 link. 2623 To avoid potential denial of service attack, it is RECOMMENDED that 2624 implementations using the Peer Discovery mechanism maintain an 2625 information base of hosts that persistently fail Session 2626 Initialization having provided an acceptable Discovery signal, and 2627 ignore Peer Discovery signals from such hosts. 2629 This specification does not address security of the data plane, as it 2630 (the data plane) is not affected, and standard security procedures 2631 can be employed. 2633 13. IANA Considerations 2635 This section specifies requests to IANA. 2637 13.1. Registrations 2639 This specification defines: 2641 o A new repository for DLEP signals and messages, with eighteen (18) 2642 values currently assigned. 2644 o Reservation of a Private Use numbering space within the above 2645 repository for experimental DLEP signals and messages. 2647 o A new repository for DLEP data items, with twenty-one (21) values 2648 currently assigned. 2650 o Reservation of a Private Use numbering space within the data items 2651 repository for experimental data items. 2653 o A new repository for DLEP status codes, with eight (8) currently 2654 assigned. 2656 o Reservation of a Private Use numbering space within the status 2657 codes repository for experimental status codes. 2659 o A new repository for DLEP extensions, with one (1) value currently 2660 assigned. 2662 o Reservation of a Private Use numbering space within the extension 2663 repository for experimental extensions. 2665 o A request for allocation of a well-known port for DLEP TCP and UDP 2666 communication. 2668 o A request for allocation of a link-local multicast IPv4 address 2669 for DLEP discovery. 2671 o A request for allocation of a link-local multicast IPv6 address 2672 for DLEP discovery. 2674 13.2. Signal/Message Type Registration 2676 A new repository must be created with the values of the DLEP signals 2677 and messages, entitled "Message Type Values for the Dynamic Link 2678 Event Protocol (DLEP)". The repository is to be managed using the 2679 "Specification Required" policy documented in [RFC5226]. 2681 All signal and message values are in the range [0..65535], defined in 2682 Table 1. 2684 13.3. DLEP Data Item Registrations 2686 A new repository for DLEP data items must be created, entitled "Data 2687 Item Type Values for the Dynamic Link Event Protocol (DLEP)". The 2688 repository is to be managed using the "Specification Required" policy 2689 documented in [RFC5226]. 2691 All data item values are in the range [0..65535], defined in Table 2. 2693 13.4. DLEP Status Code Registrations 2695 A new repository for DLEP status codes must be created, entitled 2696 "Status Code Values for the Dynamic Link Event Protocol (DLEP)". The 2697 repository is to be managed using the "Specification Required" policy 2698 documented in [RFC5226]. 2700 All status codes are in the range [0..255], defined in Table 3. 2702 13.5. DLEP Extensions Registrations 2704 A new repository for DLEP extensions must be created, entitled 2705 "Extension Type Values for the Dynamic Link Event Protocol (DLEP)". 2706 The repository is to be managed using the "Specification Required" 2707 policy documented in [RFC5226]. 2709 All extension values are in the range [0..65535]. Current 2710 allocations are: 2712 +-------------+-----------------------------------------------------+ 2713 | Code | Description | 2714 +-------------+-----------------------------------------------------+ 2715 | 0 | Reserved | 2716 | 1 | Credit Windowing | 2717 | 2-65519 | Unassigned. Available for future extensions | 2718 | 65520-65534 | Private Use. Available for experiments | 2719 | 65535 | Reserved | 2720 +-------------+-----------------------------------------------------+ 2722 Table 4: DLEP Extension types 2724 13.6. DLEP Well-known Port 2726 It is requested that IANA allocate a single well-known port number 2727 for both TCP and UDP, for DLEP communication. SCTP port allocation 2728 is not required. 2730 13.7. DLEP IPv4 Link-local Multicast Address 2732 It is requested that IANA allocate an IPv4 link-local multicast 2733 address for DLEP discovery signals. 2735 13.8. DLEP IPv6 Link-local Multicast Address 2737 It is requested that IANA allocate an IPv6 link-local multicast 2738 address for DLEP discovery signals. 2740 14. Acknowledgements 2742 We would like to acknowledge and thank the members of the DLEP design 2743 team, who have provided invaluable insight. The members of the 2744 design team are: Teco Boot, Bow-Nan Cheng, John Dowdell, and Henning 2745 Rogge. 2747 We would also like to acknowledge the influence and contributions of 2748 Greg Harrison, Chris Olsen, Martin Duke, Subir Das, Jaewon Kang, 2749 Vikram Kaul, Nelson Powell, Lou Berger, and Victoria Mercieca. 2751 15. References 2753 15.1. Normative References 2755 [CREDIT] Ratliff, S., "Credit Windowing extension for DLEP", draft- 2756 ietf-manet-credit-window-00 IETF draft, October 2015. 2758 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2759 Requirement Levels", BCP 14, RFC 2119, 2760 DOI 10.17487/RFC2119, March 1997, 2761 . 2763 15.2. Informative References 2765 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2766 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2767 DOI 10.17487/RFC5226, May 2008, 2768 . 2770 [RFC5578] Berry, B., Ed., Ratliff, S., Paradise, E., Kaiser, T., and 2771 M. Adams, "PPP over Ethernet (PPPoE) Extensions for Credit 2772 Flow and Link Metrics", RFC 5578, DOI 10.17487/RFC5578, 2773 February 2010, . 2775 Appendix A. Discovery Signal Flows 2776 Router Modem Signal Description 2777 ======================================================================== 2779 | Router initiates discovery, starts 2780 | a timer, send Peer Discovery 2781 |-------Peer Discovery---->|| signal. 2783 ~ ~ ~ ~ ~ ~ ~ Router discovery timer expires 2784 without receiving Peer Offer. 2786 | Router sends another Peer 2787 |-------Peer Discovery---------->| Discovery signal. 2788 | 2789 | Modem receives Peer Discovery 2790 | signal. 2791 | 2792 | Modem sends Peer Offer with 2793 |<--------Peer Offer-------------| Connection Point information. 2794 : 2795 : Router MAY cancel discovery timer 2796 : and stop sending Peer Discovery 2797 : signals. 2799 Appendix B. Peer Level Message Flows 2801 B.1. Session Initialization 2803 Router Modem Message Description 2804 ======================================================================== 2806 | Router connects to discovered or 2807 | pre-configured Modem Connection 2808 |---------TCP connect----------> Point. 2809 | 2810 | Router sends Session 2811 |----Session Initialization----->| Initialization message. 2812 | 2813 | Modem receives Session 2814 | Initialization message. 2815 | 2816 | Modem sends Session Initialization 2817 |<--Session Initialization Resp.-| Response, with Success status data 2818 | | item. 2819 | | 2820 |<<============================>>| Session established. Heartbeats 2821 : : begin. 2823 B.2. Session Initialization - Refused 2825 Router Modem Message Description 2826 ======================================================================== 2828 | Router connects to discovered or 2829 | pre-configured Modem Connection 2830 |---------TCP connect----------> Point. 2831 | 2832 | Router sends Session 2833 |-----Session Initialization---->| Initialization message. 2834 | 2835 | Modem receives Session 2836 | Initialization message, and will 2837 | not support the advertised 2838 | extensions. 2839 | 2840 | Modem sends Session Initialization 2841 | Response, with 'Request Denied' 2842 |<-Session Initialization Resp.--| status data item. 2843 | 2844 | 2845 | Router receives negative Session 2846 | Initialization Response, closes 2847 ||---------TCP close------------|| TCP connection. 2849 B.3. Router Changes IP Addresses 2851 Router Modem Message Description 2852 ======================================================================== 2854 | Router sends Session Update 2855 |-------Session Update---------->| message to announce change of IP 2856 | address 2857 | 2858 | Modem receives Session Update 2859 | message and updates internal 2860 | state. 2861 | 2862 |<----Session Update Response----| Modem sends Session Update 2863 | Response. 2865 B.4. Modem Changes Session-wide Metrics 2866 Router Modem Message Description 2867 ======================================================================== 2869 | Modem sends Session Update message 2870 | to announce change of modem-wide 2871 |<--------Session Update---------| metrics 2872 | 2873 | Router receives Session Update 2874 | message and updates internal 2875 | state. 2876 | 2877 |----Session Update Response---->| Router sends Session Update 2878 | Response. 2880 B.5. Router Terminates Session 2882 Router Modem Message Description 2883 ======================================================================== 2885 | Router sends Session Termination 2886 |------Session Termination------>| message with Status data item. 2887 | | 2888 |-------TCP shutdown (send)---> | Router stops sending messages. 2889 | 2890 | Modem receives Session 2891 | Termination, stops counting 2892 | received heartbeats and stops 2893 | sending heartbeats. 2894 | 2895 | Modem sends Session Termination 2896 |<---Session Termination Resp.---| Response with Status 'Success'. 2897 | 2898 | Modem stops sending messages. 2899 | 2900 ||---------TCP close------------|| Session terminated. 2902 B.6. Modem Terminates Session 2903 Router Modem Message Description 2904 ======================================================================== 2906 | Modem sends Session Termination 2907 |<----Session Termination--------| message with Status data item. 2908 | 2909 | Modem stops sending messages. 2910 | 2911 | Router receives Session 2912 | Termination, stops counting 2913 | received heartbeats and stops 2914 | sending heartbeats. 2915 | 2916 | Router sends Session Termination 2917 |---Session Termination Resp.--->| Response with Status 'Success'. 2918 | 2919 | Router stops sending messages. 2920 | 2921 ||---------TCP close------------|| Session terminated. 2923 B.7. Session Heartbeats 2924 Router Modem Message Description 2925 ======================================================================== 2927 |----------Heartbeat------------>| Router sends heartbeat message 2928 | 2929 | Modem resets heartbeats missed 2930 | counter. 2932 ~ ~ ~ ~ ~ ~ ~ 2934 |---------[Any message]--------->| When the Modem receives any 2935 | message from the Router. 2936 | 2937 | Modem resets heartbeats missed 2938 | counter. 2940 ~ ~ ~ ~ ~ ~ ~ 2942 |<---------Heartbeat-------------| Modem sends heartbeat message 2943 | 2944 | Router resets heartbeats missed 2945 | counter. 2947 ~ ~ ~ ~ ~ ~ ~ 2949 |<--------[Any message]----------| When the Router receives any 2950 | message from the Modem. 2951 | 2952 | Modem resets heartbeats missed 2953 | counter. 2955 B.8. Router Detects a Heartbeat timeout 2957 Router Modem Message Description 2958 ======================================================================== 2960 ||<----------------------| Router misses a heartbeat 2962 | ||<----------------------| Router misses too many heartbeats 2963 | 2964 | 2965 |------Session Termination------>| Router sends Session Termination 2966 | message with 'Timeout' Status 2967 | data item. 2968 : 2969 : Termination proceeds as above. 2971 B.9. Modem Detects a Heartbeat timeout 2973 Router Modem Message Description 2974 ======================================================================== 2976 |---------------------->|| Modem misses a heartbeat 2978 |---------------------->|| | Modem misses too many heartbeats 2979 | 2980 | 2981 |<-----Session Termination-------| Modem sends Session Termination 2982 | message with 'Timeout' Status 2983 | data item. 2984 : 2985 : Termination proceeds as above. 2987 Appendix C. Destination Specific Message Flows 2989 C.1. Common Destination Notification 2990 Router Modem Message Description 2991 ======================================================================== 2993 | Modem detects a new logical 2994 | destination is reachable, and 2995 |<-------Destination Up----------| sends Destination Up message. 2996 | 2997 |------Destination Up Resp.----->| Router sends Destination Up 2998 | Response. 3000 ~ ~ ~ ~ ~ ~ ~ 3001 | Modem detects change in logical 3002 | destination metrics, and sends 3003 |<-------Destination Update------| Destination Update message. 3005 ~ ~ ~ ~ ~ ~ ~ 3006 | Modem detects change in logical 3007 | destination metrics, and sends 3008 |<-------Destination Update------| Destination Update message. 3010 ~ ~ ~ ~ ~ ~ ~ 3011 | Modem detects logical destination 3012 | is no longer reachable, and sends 3013 |<-------Destination Down--------| Destination Down message. 3014 | 3015 | Router receives Destination Down, 3016 | updates internal state, and sends 3017 |------Destination Down Resp.--->| Destination Down Response message. 3019 C.2. Multicast Destination Notification 3020 Router Modem Message Description 3021 ======================================================================== 3023 | Router detects a new multicast 3024 | destination is in use, and sends 3025 |--------Destination Up--------->| Destination Up message. 3026 | 3027 | Modem updates internal state to 3028 | monitor multicast destination, and 3029 |<-----Destination Up Resp.------| sends Destination Up Response. 3031 ~ ~ ~ ~ ~ ~ ~ 3032 | Modem detects change in multicast 3033 | destination metrics, and sends 3034 |<-------Destination Update------| Destination Update message. 3036 ~ ~ ~ ~ ~ ~ ~ 3037 | Modem detects change in multicast 3038 | destination metrics, and sends 3039 |<-------Destination Update------| Destination Update message. 3041 ~ ~ ~ ~ ~ ~ ~ 3042 | Router detects multicast 3043 | destination is no longer in use, 3044 |--------Destination Down------->| and sends Destination Down 3045 | message. 3046 | 3047 | Modem receives Destination Down, 3048 | updates internal state, and sends 3049 |<-----Destination Down Resp.----| Destination Down Response message. 3051 C.3. Link Characteristics Request 3052 Router Modem Message Description 3053 ======================================================================== 3055 Destination has already been 3056 ~ ~ ~ ~ ~ ~ ~ announced by either peer. 3058 | Router requires different 3059 | Characteristics for the 3060 | destination, and sends Link 3061 |--Link Characteristics Request->| Characteristics Request message. 3062 | 3063 | Modem attempts to adjust link 3064 | status to meet the received 3065 | request, and sends a Link 3066 | Characteristics Response 3067 |<---Link Characteristics Resp.--| message with the new values. 3069 Authors' Addresses 3071 Stan Ratliff 3072 VT iDirect 3073 13861 Sunrise Valley Drive, Suite 300 3074 Herndon, VA 20171 3075 USA 3077 Email: sratliff@idirect.net 3079 Shawn Jury 3080 Cisco Systems 3081 170 West Tasman Drive 3082 San Jose, CA 95134 3083 USA 3085 Email: sjury@cisco.com 3087 Darryl Satterwhite 3088 Broadcom 3090 Email: dsatterw@broadcom.com 3091 Rick Taylor 3092 Airbus Defence & Space 3093 Quadrant House 3094 Celtic Springs 3095 Coedkernew 3096 Newport NP10 8FZ 3097 UK 3099 Email: rick.taylor@airbus.com 3101 Bo Berry