idnits 2.17.00 (12 Aug 2021) /tmp/idnits30628/draft-ietf-manet-dlep-19.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 18, 2016) is 2284 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 2766, 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 21, 2016 Cisco Systems 5 D. Satterwhite 6 Broadcom 7 R. Taylor 8 Airbus Defence & Space 9 B. Berry 10 February 18, 2016 12 Dynamic Link Exchange Protocol (DLEP) 13 draft-ietf-manet-dlep-19 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 21, 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 . . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . 21 83 9.3. DLEP Generic Data Item . . . . . . . . . . . . . . . . . 21 84 10. DLEP Signals and Messages . . . . . . . . . . . . . . . . . . 22 85 10.1. Peer Discovery Signal . . . . . . . . . . . . . . . . . 23 86 10.2. Peer Offer Signal . . . . . . . . . . . . . . . . . . . 24 87 10.3. Session Initialization Message . . . . . . . . . . . . . 24 88 10.4. Session Initialization Response Message . . . . . . . . 25 89 10.5. Session Update Message . . . . . . . . . . . . . . . . . 27 90 10.6. Session Update Response Message . . . . . . . . . . . . 28 91 10.7. Session Termination Message . . . . . . . . . . . . . . 28 92 10.8. Session Termination Response Message . . . . . . . . . . 29 93 10.9. Destination Up Message . . . . . . . . . . . . . . . . . 29 94 10.10. Destination Up Response Message . . . . . . . . . . . . 30 95 10.11. Destination Announce Message . . . . . . . . . . . . . . 31 96 10.12. Destination Announce Response Message . . . . . . . . . 31 97 10.13. Destination Down Message . . . . . . . . . . . . . . . . 33 98 10.14. Destination Down Response Message . . . . . . . . . . . 33 99 10.15. Destination Update Message . . . . . . . . . . . . . . . 34 100 10.16. Heartbeat Message . . . . . . . . . . . . . . . . . . . 35 101 10.17. Link Characteristics Request Message . . . . . . . . . . 35 102 10.18. Link Characteristics Response Message . . . . . . . . . 36 103 11. DLEP Data Items . . . . . . . . . . . . . . . . . . . . . . . 38 104 11.1. Status . . . . . . . . . . . . . . . . . . . . . . . . . 39 105 11.2. IPv4 Connection Point . . . . . . . . . . . . . . . . . 41 106 11.3. IPv6 Connection Point . . . . . . . . . . . . . . . . . 42 107 11.4. Peer Type . . . . . . . . . . . . . . . . . . . . . . . 43 108 11.5. Heartbeat Interval . . . . . . . . . . . . . . . . . . . 44 109 11.6. Extensions Supported . . . . . . . . . . . . . . . . . . 44 110 11.7. MAC Address . . . . . . . . . . . . . . . . . . . . . . 45 111 11.8. IPv4 Address . . . . . . . . . . . . . . . . . . . . . . 46 112 11.9. IPv6 Address . . . . . . . . . . . . . . . . . . . . . . 47 113 11.10. IPv4 Attached Subnet . . . . . . . . . . . . . . . . . . 48 114 11.11. IPv6 Attached Subnet . . . . . . . . . . . . . . . . . . 49 115 11.12. Maximum Data Rate (Receive) . . . . . . . . . . . . . . 50 116 11.13. Maximum Data Rate (Transmit) . . . . . . . . . . . . . . 50 117 11.14. Current Data Rate (Receive) . . . . . . . . . . . . . . 51 118 11.15. Current Data Rate (Transmit) . . . . . . . . . . . . . . 52 119 11.16. Latency . . . . . . . . . . . . . . . . . . . . . . . . 53 120 11.17. Resources (Receive) . . . . . . . . . . . . . . . . . . 53 121 11.18. Resources (Transmit) . . . . . . . . . . . . . . . . . . 54 122 11.19. Relative Link Quality (Receive) . . . . . . . . . . . . 55 123 11.20. Relative Link Quality (Transmit) . . . . . . . . . . . . 55 124 11.21. Maximum Transmission Unit (MTU) . . . . . . . . . . . . 56 125 12. Security Considerations . . . . . . . . . . . . . . . . . . . 57 126 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 127 13.1. Registrations . . . . . . . . . . . . . . . . . . . . . 57 128 13.2. Signal/Message Type Registration . . . . . . . . . . . . 58 129 13.3. DLEP Data Item Registrations . . . . . . . . . . . . . . 58 130 13.4. DLEP Status Code Registrations . . . . . . . . . . . . . 58 131 13.5. DLEP Extensions Registrations . . . . . . . . . . . . . 59 132 13.6. DLEP Well-known Port . . . . . . . . . . . . . . . . . . 59 133 13.7. DLEP IPv4 Link-local Multicast Address . . . . . . . . . 59 134 13.8. DLEP IPv6 Link-local Multicast Address . . . . . . . . . 59 135 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 59 136 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 60 137 15.1. Normative References . . . . . . . . . . . . . . . . . . 60 138 15.2. Informative References . . . . . . . . . . . . . . . . . 60 139 Appendix A. Discovery Signal Flows . . . . . . . . . . . . . . . 60 140 Appendix B. Peer Level Message Flows . . . . . . . . . . . . . . 61 141 B.1. Session Initialization . . . . . . . . . . . . . . . . . 61 142 B.2. Session Initialization - Refused . . . . . . . . . . . . 62 143 B.3. Router Changes IP Addresses . . . . . . . . . . . . . . . 62 144 B.4. Modem Changes Session-wide Metrics . . . . . . . . . . . 62 145 B.5. Router Terminates Session . . . . . . . . . . . . . . . . 63 146 B.6. Modem Terminates Session . . . . . . . . . . . . . . . . 63 147 B.7. Session Heartbeats . . . . . . . . . . . . . . . . . . . 64 148 B.8. Router Detects a Heartbeat timeout . . . . . . . . . . . 65 149 B.9. Modem Detects a Heartbeat timeout . . . . . . . . . . . . 66 150 Appendix C. Destination Specific Message Flows . . . . . . . . . 66 151 C.1. Common Destination Notification . . . . . . . . . . . . . 66 152 C.2. Multicast Destination Notification . . . . . . . . . . . 67 153 C.3. Link Characteristics Request . . . . . . . . . . . . . . 68 154 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69 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 DLEP requires that the MAC address for delivering data traffic is the 301 MAC address used by DLEP to identify the destination. No 302 manipulation or substitution is performed; the MAC address supplied 303 in all destination messages is used as the OSI Layer 2 Destination 304 MAC address. DLEP also requires that MAC addresses are unique within 305 the context of a router-modem session. 307 The reliance on MAC addresses by DLEP forces the requirement that 308 participating DLEP peers are on a single segment (either physical or 309 logically, via tunneling protocols) at Layer 2. 311 2. Protocol Overview 313 DLEP defines a set of messages used by modems and their attached 314 routers to communicate events that occur on the physical link(s) 315 managed by the modem: for example, a remote node entering or leaving 316 the network, or that the link has changed. Associated with these 317 messages are a set of Data Items - information that describes the 318 remote node (e.g., address information), and/or the characteristics 319 of the link to the remote node. Throughout this document, we refer 320 to a modems/routers participating in a DLEP session as 'DLEP Peers', 321 or 'DLEP Participants', unless a specific distinction (e.g. modem or 322 router) is required. 324 DLEP uses a session-oriented paradigm between the modem device and 325 its associated router. If multiple modem devices are attached to a 326 router (as in Figure 2), or the modem supports multiple connections 327 (via multiple logical or physical interfaces), then separate DLEP 328 sessions exist for each modem or connection. A router and modem form 329 a session by completing the discovery and initialization process. 330 This router-modem session persists unless or until it either (1) 331 times out, based on the absence of traffic (including heartbeats), or 332 (2) is explicitly torn down by one of the participants. 334 The router/modem session provides a carrier for information exchange 335 concerning 'destinations' that are available via the modem device. 336 Destinations can be identified by either the router or the modem, and 337 represent a specific, addressable location that can be reached via 338 the link(s) managed by the modem. A destination can be either 339 physical or logical. 341 The example of a physical destination would be that of a remote, far- 342 end router attached via the variable-quality network. 344 The example of a logical destination is Multicast. Multicast traffic 345 destined for the variable-quality network (the network accessed via 346 the modem) is handled in IP networks by deriving a Layer 2 MAC 347 address based on the Layer 3 address. Leveraging on this scheme, 348 multicast traffic is supported in DLEP simply by treating the derived 349 MAC address as any other destination in the network. To support 350 these logical destinations, one of the DLEP participants (typically, 351 the router) informs the other as to the existence of the logical 352 destination. The modem, once it is aware of the existence of this 353 logical destination, reports link characteristics just as it would 354 for any other destination in the network. The specific algorithms a 355 modem would use to derive metrics on logical destinations are outside 356 the scope of this specification, and is left to specific 357 implementations to decide. 359 The DLEP messages concerning destinations thus become the way for 360 routers and modems to maintain, and notify each other about, an 361 information base representing the physical and logical destinations 362 accessible via the modem device, as well as the link characteristics 363 to those destinations. 365 While this document represents the best efforts of the working group 366 to be functionally complete, it is recognized that extensions to DLEP 367 will in all likelihood be necessary as more link types are used. 368 Such extensions are defined as additional rules of behavior, 369 messages, data items and/or status codes that are not defined in this 370 document. DLEP contains a standard mechanism for router and modem 371 implementations to negotiate the available extensions to use on a 372 per-session basis. 374 2.1. Assumptions 376 DLEP specifies UDP multicast for single-hop discovery signaling, and 377 TCP for transport of the control messages. Therefore, DLEP assumes 378 that the modem and router have topologically consistent IP addresses 379 assigned. It is RECOMMENDED that DLEP implementations utilize IPv6 380 link-local addresses to reduce the administrative burden of address 381 assignment. DLEP relies on the guaranteed- delivery of its messages 382 between router and modem, once the 1 hop discovery process is 383 complete, hence, the specification of TCP to carry the messages. 384 Other reliable transports for the protocol are possible, but are 385 outside the scope of this document. 387 DLEP further assumes that security of the implementations (e.g., 388 authentication of stations, encryption of traffic, or both) is dealt 389 with by utilizing Layer 2 security techniques. This reliance on 390 Layer 2 mechanisms secures all DLEP messages - both the UDP discovery 391 messages and the TCP control messages. 393 3. Destinations 395 Destination messages describe the acquisition and loss of network 396 destinations, and control the flow of information about the 397 destinations in the several ways. A destination MUST contain a MAC 398 address; it MAY optionally include a Layer 3 address (or multiple 399 addresses). The MAC address MAY reference a logical destination, as 400 in a derived multicast MAC address, as well as a physical device. As 401 destinations are discovered, DLEP routers and modems build an 402 information base of destinations accessible via the modem. 404 DLEP can support MAC addresses in either EUI-48 or EUI-64 format, 405 with the restriction that all MAC addresses for a given DLEP session 406 MUST be in the same format, and MUST be consistent with the MAC 407 address format of the connected modem (e.g., if the modem is 408 connected to the router with an EUI-48 MAC, all destination addresses 409 via that modem MUST be expressed in EUI-48 format). 411 Destination messages trigger creation/maintenance/deletion of 412 destinations in the information base of the recipient. For example, 413 a modem will inform its attached router of the presence of a new 414 destination via the Destination Up message (Section 10.9). Receipt 415 of a Destination Up causes the router to allocate the necessary 416 resources, creating an entry in the information base with the 417 specifics (i.e. MAC Address, Latency, Data Rate, etc.) of the 418 destination. The loss of a destination is communicated via the 419 Destination Down message (Section 10.13), and changes in status to 420 the destination (e.g., varying link quality, or addressing changes) 421 are communicated via the Destination Update message (Section 10.15). 423 The information on a given destination will persist in the 424 implementation's information base until a Destination Down message is 425 received, indicating that the peer has lost contact or interest with 426 the remote node, or the implementation transitions to the Session 427 Termination state. 429 3.1. Router-requested Destinations 431 Usually a modem will discover the presence of one or more remote 432 router/modem pairs and announce each destination's arrival by sending 433 a corresponding Destination Up message to its peer. However, there 434 may be times when a router wishes to express an interest in the 435 status of the link to a logical destination that has yet to be 436 announced, typically a multicast destination. To facilitate this, 437 DLEP provides the Destination Announce (Section 10.11) and 438 Destination Announce Response (Section 10.12) messages. These 439 messages have similar semantics to the Destination Up and Destination 440 Up Response messages, but flow from router to modem. 442 After successfully receiving and processing a Destination Announce 443 message, a modem then announces changes to the link to the logical 444 destination via Destination Update messages. A modem MAY refuse a 445 Destination Announce message by replying with a Destination Announce 446 Response message with a 'Request Denied' status code, see Table 3. 448 A Destination Announce message MAY also be used by a router to 449 request information concerning a destination that it has previously 450 declined interest in, via the 'Not Interested' status code, see 451 Table 3, or declared as down, via the Destination Down message. 453 One of the advantages of implementing DLEP is to leverage the modem's 454 knowledge of the links between remote destinations allowing routers 455 to avoid using probed neighbor discovery techniques, therefore modem 456 implementations SHOULD announce available destinations via the 457 Destination Up message, rather than relying on Destination Announce 458 messages. 460 4. Metrics 462 DLEP includes the ability for the router and modem to communicate 463 metrics that reflect the characteristics (e.g., datarate, latency) of 464 the variable-quality link in use. DLEP does not specify how a given 465 metric value is to be calculated, rather, the protocol assumes that 466 metrics have been calculated by a 'best effort', incorporating all 467 pertinent data that is available to the modem device. 469 DLEP allows for metrics to be sent within two contexts - metrics for 470 a specific destination within the network (e.g., a specific router), 471 and per-session (those that apply to all destinations accessed via 472 the modem). Most metrics can be further subdivided into transmit and 473 receive metrics. In cases where metrics are provided at session 474 level, the router MUST propagate the metrics to all entries in its 475 information base for destinations that are accessed via the modem. 477 DLEP modem implementations MUST announce all metric items that will 478 be reported during the session, and provide default values for those 479 metrics, in the Session Initialization Response message 480 (Section 10.4). In order to use a metric type that was not included 481 in the Session Initialization Response message, modem implementations 482 MUST terminate the session with the router (via the Session Terminate 483 message (Section 10.7)), and establish a new session. A modem MUST 484 include the following list of metrics in the Session Initialization 485 Response message: 487 o Maximum Data Rate (Receive) (Section 11.12) 489 o Maximum Data Rate (Transmit) (Section 11.13) 491 o Current Data Rate (Receive) (Section 11.14) 493 o Current Data Rate (Transmit) (Section 11.15) 495 o Latency (Section 11.16) 497 A DLEP modem MAY send metrics both in a session context (via the 498 Session Update message) and a specific destination context (via 499 Destination Update) at any time. The most recently received metric 500 value MUST take precedence over any earlier value, regardless of 501 context - that is: 503 1. If the router receives metrics in a specific destination context 504 (via the Destination Update message), then the specific 505 destination is updated with the new metric. 507 2. If the router receives metrics in a modem-wide context (via the 508 Session Update message), then the metrics for all destinations 509 accessed via the modem MUST be updated with the new metric. 511 It is left to implementations to choose sensible default values based 512 on their specific characteristics. Modems having static (non- 513 changing) link metric characteristics MAY report metrics only once 514 for a given destination (or once on a modem-wide basis, if all 515 connections via the modem are of this static nature). 517 In addition to communicating existing metrics about the link, DLEP 518 provides a message allowing a router to request a different datarate 519 or latency from the modem. This message is the Link Characteristics 520 Request message (Section 10.17), and gives the router the ability to 521 deal with requisite increases (or decreases) of allocated datarate/ 522 latency in demand-based schemes in a more deterministic manner. 524 5. DLEP Session Flow 526 All Peers participating in a DLEP session transition through five (5) 527 distinct states during the lifetime of a DLEP session: 529 o Peer Discovery 531 o Session Initialization 533 o In-Session 535 o Session Termination 537 o Session Reset 539 The Peer Discovery state is OPTIONAL to implement for routers. If it 540 is used, this state is the initial state. If it is not used, then a 541 preconfigured TCP address/port combination MUST be provided to the 542 router, and the router starts in the Session Initialization state. 544 Modems MUST support the Peer Discovery state. 546 5.1. Peer Discovery State 548 In the Peer Discovery state, if the router implementation supports 549 IPv6, it SHOULD send UDP packets containing a Peer Discovery signal 550 (Section 10.1) to the DLEP well-known IPv6 link-local multicast 551 address (Section 13.8) and port number (Section 13.6), setting the 552 packet source address to a valid IPv6 link-local address and the 553 source port to a valid port number. 555 If the router implementation supports IPv4, it SHOULD send UDP 556 packets containing a Peer Discovery signal (Section 10.1) to the DLEP 557 well-known IPv4 link-local multicast address (Section 13.7) and port 558 number (Section 13.6), setting the packet source address to a valid 559 local IPv4 address and the source port to a valid port number. 561 The implementation then waits for a unicast UDP packet containing a 562 Peer Offer signal (Section 10.2) from a potential DLEP peer modem. 563 While in the Peer Discovery state, Peer Discovery signals MUST be 564 sent repeatedly by a DLEP router, at regular intervals. The interval 565 MUST be a minimum of one second; it SHOULD be a configurable 566 parameter. Note that this operation (sending Peer Discovery and 567 waiting for Peer Offer) is outside the DLEP Transaction Model, as the 568 Transaction Model only describes messages on a TCP session. 570 In the Peer Discovery state, the DLEP modem implementation MUST 571 listen for incoming Peer Discovery signals on the DLEP well-known 572 link-local multicast address and port. The choice of using the well- 573 known IPv4 or the IPv6 well- known link-local multicast address and 574 port MUST be made by configuration. On receipt of a valid Peer 575 Discovery signal, it MUST unicast a Peer Offer signal to the source 576 address and port of the received UDP packet. Peer Offer signals MAY 577 contain one or more unicast address/port combinations for TCP-based 578 communication with the modem, via the IPv4 Connection Point data item 579 (Section 11.2) or the IPv6 Connection Point data item (Section 11.3), 580 on which it is prepared to accept an incoming TCP connection. If the 581 modem does not include an IPv4 Connection Point data item, nor a IPv6 582 Connection Point data item, then the source address of the packet 583 containing the Peer Offer signal MUST be used as the address on which 584 the modem is willing to accept TCP connections. 586 Upon establishment of a TCP connection, both modem and router enter 587 the Session Initialization state. Anything other than Peer Discovery 588 signals received on the UDP socket MUST be silently dropped. 590 Modems MUST be prepared to accept a TCP connection from a router that 591 is not using the Discovery mechanism, i.e. a connection attempt that 592 occurs without a preceding Peer Discovery signal. 594 Routers MUST use one or more of the modem address/port combinations 595 from the Peer Offer signal or from a priori configuration to 596 establish a new TCP connection to the modem. If more than one modem 597 address/port combinations is available, router implementations MAY 598 use their own heuristics to determine the order in which they are 599 tried. It is RECOMMENDED that an implementation attempt to connect 600 to any announced IPv6 address/port combinations before attempting to 601 use IPv4 combinations. If a TCP connection cannot be achieved using 602 any of the address/port combinations and the Discovery mechanism is 603 in use, then the router SHOULD resume issuing Peer Discovery signals. 604 If no IPv4 Connection Point data items, nor IPv6 Connection Point 605 data items are included in the Peer Offer signal, the router MUST use 606 the origin address of the UDP packet containing the signal as the IP 607 address, and the DLEP well-known port number. 609 Once a TCP connection has been established with the modem, the router 610 begins a new session and enters the Session Initialization state. It 611 is up to the router implementation if Peer Discovery signals continue 612 to be sent after the device has transitioned to the Session 613 Initialization state. 615 5.2. Session Initialization State 617 On entering the Session Initialization state, the router MUST send a 618 Session Initialization message (Section 10.3) to the modem. The 619 router MUST then wait for receipt of a Session Initialization 620 Response message (Section 10.4) from the modem. Receipt of the 621 Session Initialization Response message containing a Status data item 622 (Section 11.1) with value 'Success', see Table 3, indicates that the 623 modem has received and processed the Session Initialization message, 624 and the router MUST transition to the In-Session state. 626 On entering the Session Initialization state, the modem MUST wait for 627 receipt of a Session Initialization message from the router. Upon 628 receipt of a Session Initialization message, the modem MUST send a 629 Session Initialization Response message, and the session MUST 630 transition to the In-Session state. 632 DLEP provides an extension negotiation capability to be used in the 633 Session Initialization state, see Section 7. Extensions supported by 634 an implementation MUST be declared to potential DLEP peers using the 635 Extensions Supported data item (Section 11.6). Once both 636 participants have exchanged initialization messages, an 637 implementation MUST NOT emit any message, signal, data item or status 638 code associated with an extension that was not specified in the 639 received initialization message from its peer. 641 If the router receives any message other than a valid Session 642 Initialization Response, it MUST send a Session Termination message 643 (Section 10.7) with the 'Unexpected Message' status code, see 644 Table 3, and transition to the Session Termination state. 646 If the modem receives any message other than Session Initialization, 647 or it fails to parse the received message, it MUST NOT send any 648 message, and MUST terminate the TCP connection and transition to the 649 Session Reset state. 651 If an additional metric is to be introduced after the session has 652 started, the session between router and modem MUST be terminated and 653 restarted, and the new metric described in the next Session 654 Initialization Response message. 656 5.3. In-Session State 658 In the In-Session state, messages can flow in both directions between 659 participants, indicating changes to the session state, the arrival or 660 departure of reachable destinations, or changes of the state of the 661 links to the destinations. 663 The In-Session state is maintained until one of the following 664 conditions occur: 666 o A peer terminates the session by sending a Session Termination 667 message (Section 10.7)), or, 669 o The peer terminates the session, indicated by receiving a Session 670 Termination message. 672 The peer MUST then transition to the Session Termination state. 674 Prior to the exchange of Destination Up (Section 10.9) and 675 Destination Up Response (Section 10.10) messages, or Destination 676 Announce (Section 10.11) and Destination Announce Response 677 (Section 10.12) messages, no messages concerning the logical 678 destination identified by the MAC Address data item (Section 11.7) 679 may be sent. A peer receiving any message with such an unannounced 680 destination MUST terminate the session by issuing a Session 681 Termination message (Section 10.7) with a status code of 'Invalid 682 Destination', see Table 3, and transition to the Session Termination 683 state. 685 The router receiving a Destination Up message MAY decline further 686 messages concerning a given destination by sending a Destination Up 687 Response with a status code of 'Not Interested'. Modems receiving 688 such responses MUST NOT send further messages concerning that 689 destination to the router. 691 After exchanging Destination Down (Section 10.13) and Destination 692 Down Response (Section 10.14) messages, no messages concerning the 693 logical destination identified by the MAC Address data item may be a 694 sent without previously sending a new Destination Up message. A peer 695 receiving a message about a destination previously announced as 696 'down' MUST terminate the session by issuing a Session Termination 697 message with a status code of 'Invalid Destination' and transition to 698 the Session Termination state. 700 5.3.1. Heartbeats 702 In order to maintain the In-Session state, periodic Heartbeat 703 messages (Section 10.16) MAY be exchanged between router and modem. 704 These messages are intended to keep the session alive, and to verify 705 bidirectional connectivity between the two participants. 707 If Heartbeat messages are used, the following processing rules MUST 708 apply: 710 o Each DLEP peer is responsible for the creation of heartbeat 711 messages. 713 o Receipt of any valid DLEP message MUST reset the heartbeat 714 interval timer (i.e., valid DLEP messages take the place of, and 715 obviate the need for, additional Heartbeat messages). 717 o DLEP peers SHOULD allow two (2) heartbeat intervals to expire with 718 no messages from the peer before terminating the session by 719 issuing a Session Termination message with a status code of 'Timed 720 Out', and then transition to the Session Termination state. 722 5.4. Session Termination State 724 When a DLEP implementation enters the Session Termination state after 725 sending a Session Termination message (Section 10.7) as the result of 726 an invalid message or error, it MUST wait for a Session Termination 727 Response message (Section 10.8) from its peer. If Heartbeat messages 728 (Section 10.16) are in use, senders SHOULD allow four (4) heartbeat 729 intervals to expire before assuming that the peer is unresponsive, 730 and continuing with session termination. If Heartbeat messages are 731 not in use, then if is RECOMMENDED that an interval of eight (8) 732 seconds be used. 734 When the sender of the Session Termination message receives a Session 735 Termination Response message from its peer, or times out, it MUST 736 transition to the Session Reset state. 738 When an implementation enters the Session Termination state having 739 received a Session Termination message from its peer, it MUST 740 immediately send a Session Termination Response and transition to the 741 Session Reset state. 743 Any messages received after either sending or receiving a Session 744 Termination message MUST be silently ignored. 746 5.5. Session Reset state 748 In the Session Reset state the implementation MUST perform the 749 following actions: 751 o Release all resources allocated for the session. 753 o Eliminate all destinations in the information base accessible via 754 the modem represented by the session. Destination Down messages 755 (Section 10.13) MUST NOT be sent. 757 o Terminate the TCP connection. 759 Having completed these actions the implementation SHOULD return to 760 the relevant initial state: Peer Discovery for modems; either Peer 761 Discovery or Session Initialization for routers, depending on 762 configuration. 764 5.5.1. Unexpected TCP connection termination 766 If the TCP connection between peers is terminated when a participant 767 is not in the Session Reset state, the implementation MUST 768 immediately transition to the Session Reset state. 770 6. Transaction Model 772 DLEP defines a simple message transaction model: Only one request per 773 destination may be in progress at a time. A message transaction is 774 considered complete when a response matching a previously issued 775 request is received. If a participant receives a request for a 776 destination for which there is already an outstanding request, the 777 implementation MUST terminate the session by issuing a Session 778 Termination message (Section 10.7) with a status code of 'Unexpected 779 Message', see Table 3, and transition to the Session Termination 780 state. There is no restriction to the total number of message 781 transactions in progress at a time, as long as each transaction 782 refers to a different destination. 784 It should be noted that some requests may take a considerable amount 785 of time for some participants to complete, for example a modem 786 handling a multicast destination up request may have to perform a 787 complex network reconfiguration. A sending implementation MUST be 788 able to handle such long running transactions gracefully. 790 Additionally, only one session request, e.g. a Session Initialization 791 message (Section 10.3) may be in progress at a time. As above, a 792 session transaction is considered complete when a response matching a 793 previously issued request is received. If a participant receives a 794 session request while there is already a session request in progress, 795 it MUST terminate the session by issuing a Session Termination 796 message with a status code of 'Unexpected Message', and transition to 797 the Session Termination state. Only the Session Termination message 798 may be issued when a session transaction is in progress. Heartbeat 799 messages (Section 10.16) MUST NOT be considered part of a session 800 transaction. 802 DLEP transactions do not time out and are not cancellable. An 803 implementation can detect if its peer has failed in some way by use 804 of the session heartbeat mechanism during the In-Session state, see 805 Section 5.3. 807 7. Extensions 809 Extensions MUST be negotiated on a per-session basis during session 810 initialization via the Extensions Supported mechanism. 811 Implementations are not required to support any extension in order to 812 be considered DLEP compliant. An extension document, describing the 813 operation of a credit windowing scheme for flow control, is described 814 in [CREDIT]. 816 If interoperable protocol extensions are required, they MUST be 817 standardized either as an update to this document, or as an 818 additional stand-alone specification. The requests for IANA- 819 controlled registries in this document contain sufficient Reserved 820 space for DLEP signals, messages, data items and status codes to 821 accommodate future extensions to the protocol. 823 As multiple protocol extensions MAY be announced during session 824 initialization, authors of protocol extensions MUST consider the 825 interaction of their extension with other published extensions, and 826 specify any incompatibilities. 828 7.1. Experiments 830 This document requests Private Use numbering space in the DLEP 831 signal/message, data item and status code registries for experimental 832 extensions. The intent is to allow for experimentation with new 833 signals, messages, data items, and/or status codes, while still 834 retaining the documented DLEP behavior. 836 Use of the Private Use signals, messages, data items, status codes, 837 or behaviors MUST be announced as DLEP Extensions, during session 838 initialization, using extension identifiers from the Private Use 839 space in the Extensions Supported registry (Table 4), with a value 840 agreed upon (a priori) between the participating peers. DLEP 841 extensions using the Private Use numbering space are commonly 842 referred to as Experiments. 844 Multiple experiments MAY be announced in the Session Initialization 845 messages. However, use of multiple experiments in a single session 846 could lead to interoperability issues or unexpected results (e.g., 847 clashes of experimental signals, messages, data items and/or status 848 code types), and is therefore discouraged. It is left to 849 implementations to determine the correct processing path (e.g., a 850 decision on whether to terminate the session, or to establish a 851 precedence of the conflicting definitions) if such conflicts arise. 853 8. Scalability 855 The protocol is intended to support thousands of destinations on a 856 given modem/router pair. At large scale, implementations SHOULD 857 consider employing techniques to prevent flooding a peer with a large 858 number of messages in a short time. It is recommended that 859 implementations consider a dampening algorithm to prevent a flapping 860 device from generating a large number of Destination Up/Destination 861 Down messages, for example. Implementations SHOULD also consider 862 techniques such as a hysteresis to lessen the impact of rapid, minor 863 fluctuations in link quality. The specific algorithms to be used for 864 handling flapping destinations and minor changes in link quality are 865 outside the scope of this specification. 867 9. DLEP Signal and Message Structure 869 DLEP defines two protocol units used in two different ways: Signals 870 and Messages. Signals are only used in the Discovery mechanism and 871 are carried in UDP datagrams. Messages are used bi-directionally 872 over a TCP connection between two peers, in the Session 873 Initialization, In-Session and Session Termination states. 875 Both signals and messages consist of a header followed by an 876 unordered list of data items. Headers consist of Type and Length 877 information, while data items are encoded as TLV (Type-Length-Value) 878 structures. In this document, the data items following a signal or 879 message header are described as being 'contained in' the signal or 880 message. 882 There is no restriction on the order of data items following a 883 header, and the multiplicity of duplicate data items is defined by 884 the definition of the signal or message declared by the type in the 885 header. 887 All integers in header fields and values MUST be in network byte- 888 order. 890 9.1. DLEP Signal Header 892 The DLEP signal header contains the following fields: 894 0 1 2 3 895 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 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | 'D' | 'L' | 'E' | 'P' | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | Signal Type | Length | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 Figure 3: DLEP Signal Header 904 "DLEP": Every signal MUST start with the characters: U+44, U+4C, 905 U+45, U+50. 907 Signal Type: An 16-bit unsigned integer containing one of the DLEP 908 Signal/Message Type values defined in this document. 910 Length: The length in octets, expressed as a 16-bit unsigned 911 integer, of all of the DLEP data items associated with this 912 signal. This length SHALL NOT include the length of the header 913 itself. 915 The DLEP signal header is immediately followed by one or more DLEP 916 data items, encoded in TLVs, as defined in this document. 918 If an unrecognized, or unexpected signal is received, or a received 919 signal contains unrecognized, invalid, or disallowed duplicate data 920 items, the receiving participant MUST ignore the signal. 922 9.2. DLEP Message Header 924 The DLEP message header contains the following fields: 926 0 1 2 3 927 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 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | Message Type | Length | 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 Figure 4: DLEP Message Header 934 Message Type: An 16-bit unsigned integer containing one of the DLEP 935 Signal/Message Type values defined in this document. 937 Length: The length in octets, expressed as a 16-bit unsigned 938 integer, of all of the DLEP data items associated with this 939 message. This length SHALL NOT include the length of the header 940 itself. 942 The DLEP message header is immediately followed by one or more DLEP 943 data items, encoded in TLVs, as defined in this document. 945 If an unrecognized, or unexpected message is received, or a received 946 message contains unrecognized, invalid, or disallowed duplicate data 947 items, the receiving participant MUST issue a Session Termination 948 message (Section 10.7) with a Status data item (Section 11.1) 949 containing the most relevant status code, see Table 3, and transition 950 to the Session Termination state. 952 9.3. DLEP Generic Data Item 954 All DLEP data items contain the following fields: 956 0 1 2 3 957 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 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Data Item Type | Length | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | Value... : 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 Figure 5: DLEP Generic Data Item 966 Data Item Type: An 16-bit unsigned integer field specifying the type 967 of data item being sent. 969 Length: The length in octets, expressed as an 16-bit unsigned 970 integer, of the value field of the data item. This length SHALL 971 NOT include the length of the header itself. 973 Value: A field of octets, which contains data specific to a 974 particular data item. 976 10. DLEP Signals and Messages 978 As mentioned above, all DLEP signals begin with the DLEP signal 979 header, and all DLEP messages begin with the DLEP message header. 980 Therefore, in the following descriptions of specific signals and 981 messages, this header is assumed, and will not be replicated. 983 Following is the set of core signals and messages that MUST be 984 recognized by a DLEP compliant implementation. As mentioned before, 985 not all messages may be used during a session, but an implementation 986 MUST correctly process these messages when received. 988 The core DLEP signals and messages are: 990 +-------------+-----------------------------------------------------+ 991 | Type Code | Description | 992 +-------------+-----------------------------------------------------+ 993 | 0 | Reserved | 994 | 1 | Peer Discovery signal (Section 10.1) | 995 | 2 | Peer Offer signal (Section 10.2) | 996 | 3 | Session Initialization message (Section 10.3) | 997 | 4 | Session Initialization Response message (Section | 998 | | 10.4) | 999 | 5 | Session Update message (Section 10.5) | 1000 | 6 | Session Update Response message (Section 10.6) | 1001 | 7 | Session Termination message (Section 10.7) | 1002 | 8 | Session Termination Response message (Section 10.8) | 1003 | 9 | Destination Up message (Section 10.9) | 1004 | 10 | Destination Up Response message (Section 10.10) | 1005 | 11 | Destination Down message (Section 10.13) | 1006 | 12 | Destination Down Response message (Section 10.14) | 1007 | 13 | Destination Update message (Section 10.15) | 1008 | 14 | Heartbeat message (Section 10.16) | 1009 | 15 | Link Characteristics Request message (Section | 1010 | | 10.17) | 1011 | 16 | Link Characteristics Response message (Section | 1012 | | 10.18) | 1013 | 17 | Destination Announce message (Section 10.11) | 1014 | 18 | Destination Announce Response message (Section | 1015 | | 10.12) | 1016 | 19-65519 | Reserved for future extensions | 1017 | 65520-65534 | Private Use. Available for experiments | 1018 | 65535 | Reserved | 1019 +-------------+-----------------------------------------------------+ 1021 Table 1: DLEP Signal/Message types 1023 10.1. Peer Discovery Signal 1025 A Peer Discovery signal SHOULD be sent by a DLEP router to discover 1026 DLEP modems in the network. The Peer Offer signal (Section 10.2) is 1027 required to complete the discovery process. Implementations MUST 1028 implement their own retransmit heuristics in cases where it is 1029 determined the Peer Discovery signal has timed out. 1031 To construct a Peer Discovery signal, the Signal Type value in the 1032 signal header is set to 1, from Table 1. 1034 The Peer Discovery signal MAY contain the following data item: 1036 o Peer Type (Section 11.4) 1038 10.2. Peer Offer Signal 1040 A Peer Offer signal MUST be sent by a DLEP modem in response to a 1041 valid Peer Discovery signal (Section 10.1). 1043 The Peer Offer signal MUST be sent to the unicast address of the 1044 originator of the Peer Discovery signal. 1046 To construct a Peer Offer signal, the Signal Type value in the signal 1047 header is set to 2, from Table 1. 1049 The Peer Offer signal MAY contain the following data item: 1051 o Peer Type (Section 11.4) 1053 The Peer Offer signal MAY contain one or more of any of the following 1054 data items, with different values: 1056 o IPv4 Connection Point (Section 11.2) 1058 o IPv6 Connection Point (Section 11.3) 1060 The IP Connection Point data items indicate the unicast address the 1061 router MUST use when connecting the DLEP TCP session. If multiple IP 1062 Connection Point data items are present in the Peer Offer signal, 1063 router implementations MAY use their own heuristics to select the 1064 address to connect to. If no IP Connection Point data items are 1065 included in the Peer Offer signal, the router MUST use the origin 1066 address of the signal as the IP address, and the DLEP well-known port 1067 number (Section 13.6) to establish the TCP connection. 1069 10.3. Session Initialization Message 1071 A Session Initialization message MUST be sent by a DLEP router as the 1072 first message of the DLEP TCP session. It is sent by the router 1073 after a TCP connect to an address/port combination that was obtained 1074 either via receipt of a Peer Offer, or from a priori configuration. 1076 If any optional extensions are supported by the implementation, they 1077 MUST be enumerated in the Extensions Supported data item. If an 1078 Extensions Supported data item does not exist in a Session 1079 Initialization message, the modem MUST conclude that there is no 1080 support for extensions in the router. 1082 Implementations supporting the Heartbeat Interval (Section 11.5) 1083 should understand that heartbeats are not fully established until 1084 receipt of Session Initialization Response message (Section 10.4), 1085 and should therefore implement their own timeout and retry heuristics 1086 for this message. 1088 To construct a Session Initialization message, the Message Type value 1089 in the message header is set to 3, from Table 1. 1091 The Session Initialization message MUST contain one of each of the 1092 following data items: 1094 o Heartbeat Interval (Section 11.5) 1096 The Session Initialization message MAY contain one of each of the 1097 following data items: 1099 o Peer Type (Section 11.4) 1101 o Extensions Supported (Section 11.6) 1103 A Session Initialization message MUST be acknowledged by the modem 1104 issuing a Session Initialization Response message (Section 10.4). 1106 As an exception to the general rule that an implementation receiving 1107 an unrecognized data item in a message terminating the session with 1108 an error, see Section 9.2, if a Session Initialization message 1109 contains one or more Extension Supported data items announcing 1110 support for extensions that the implementation does not recognize, 1111 then the implementation MAY ignore data items it does not recognize. 1113 10.4. Session Initialization Response Message 1115 A Session Initialization Response message MUST be sent in response to 1116 a received Session Initialization message (Section 10.3). The 1117 Session Initialization Response message completes the DLEP session 1118 establishment; the modem should transition to the In-Session state 1119 when the message is sent, and the router should transition to the In- 1120 Session state upon receipt of an acceptable Session Initialization 1121 Response message. 1123 All supported metric data items MUST be included in the Session 1124 Initialization Response message, with default values to be used on a 1125 'modem-wide' basis. This can be viewed as the modem 'declaring' all 1126 supported metrics at DLEP session initialization. Receipt of any 1127 DLEP message containing a metric data item not included in the 1128 Session Initialization Response message MUST be treated as an error, 1129 resulting in the termination of the DLEP session between router and 1130 modem. 1132 If any optional extensions are supported by the modem, they MUST be 1133 enumerated in the Extensions Supported data item. If an Extensions 1134 Supported data item does not exist in a Session Initialization 1135 Response message, the router MUST conclude that there is no support 1136 for extensions in the modem. 1138 After the Session Initialization/Session Initialization Response 1139 messages have been successfully exchanged, implementations MUST only 1140 use extensions that are supported by BOTH participants. 1142 To construct a Session Initialization Response message, the Message 1143 Type value in the message header is set to 4, from Table 1. 1145 The Session Initialization Response message MUST contain one of each 1146 of the following data items: 1148 o Heartbeat Interval (Section 11.5) 1150 o Maximum Data Rate (Receive) (Section 11.12) 1152 o Maximum Data Rate (Transmit) (Section 11.13) 1154 o Current Data Rate (Receive) (Section 11.14) 1156 o Current Data Rate (Transmit) (Section 11.15) 1158 o Latency (Section 11.16) 1160 The Session Initialization Response message MUST contain one of each 1161 of the following data items, if the data item will be used during the 1162 lifetime of the session: 1164 o Resources (Receive) (Section 11.17) 1166 o Resources (Transmit) (Section 11.18) 1168 o Relative Link Quality (Receive) (Section 11.19) 1170 o Relative Link Quality (Transmit) (Section 11.20) 1172 o Maximum Transmission Unit (MTU) (Section 11.21) 1174 The Session Initialization Response message MAY contain one of each 1175 of the following data items: 1177 o Status (Section 11.1) 1179 o Peer Type (Section 11.4) 1180 o Extensions Supported (Section 11.6) 1182 A router receiving a Session Initialization Response message without 1183 a Status data item MUST behave as if a Status data item with code 1184 'Success' had been received, see Table 3. 1186 10.5. Session Update Message 1188 A Session Update message MAY be sent by a DLEP participant to 1189 indicate local Layer 3 address changes, or metric changes on a modem- 1190 wide basis. It should be noted that Session Update messages can be 1191 sent by both routers and modems. For example, addition of an IPv4 1192 address to the router MAY prompt a Session Update message to its 1193 attached modems. Also, for example, a modem that changes its Maximum 1194 Data Rate (Receive) for all destinations MAY reflect that change via 1195 a Session Update message to its attached router(s). 1197 Concerning Layer 3 addresses: If the modem is capable of 1198 understanding and forwarding this information (via proprietary 1199 mechanisms), the address update would prompt any remote DLEP modems 1200 (DLEP-enabled modems in a remote node) to issue a Destination Update 1201 message (Section 10.15) to their local routers with the new (or 1202 deleted) addresses. Modems that do not track Layer 3 addresses 1203 SHOULD silently parse and ignore Layer 3 data items. The Session 1204 Update message MUST be acknowledged with a Session Update Response 1205 message (Section 10.6). 1207 If metrics are supplied with the Session Update message (e.g., 1208 Maximum Data Rate), these metrics are considered to be modem-wide, 1209 and therefore MUST be applied to all destinations in the information 1210 base associated with the DLEP session. 1212 To construct a Session Update message, the Message Type value in the 1213 message header is set to 5, from Table 1. 1215 The Session Update message MAY contain one of each of the following 1216 data items: 1218 o Maximum Data Rate (Receive) (Section 11.12) 1220 o Maximum Data Rate (Transmit) (Section 11.13) 1222 o Current Data Rate (Receive) (Section 11.14) 1224 o Current Data Rate (Transmit) (Section 11.15) 1226 o Latency (Section 11.16) 1227 The Session Update message MAY contain one of each of the following 1228 data items, if the data item is in use by the session: 1230 o Resources (Receive) (Section 11.17) 1232 o Resources (Transmit) (Section 11.18) 1234 o Relative Link Quality (Receive) (Section 11.19) 1236 o Relative Link Quality (Transmit) (Section 11.20) 1238 o Maximum Transmission Unit (MTU) (Section 11.21) 1240 The Session Update message MAY contain one or more of the following 1241 data items, with different values: 1243 o IPv4 Address (Section 11.8) 1245 o IPv6 Address (Section 11.9) 1247 A Session Update message MUST be acknowledged by the receiver issuing 1248 a Session Update Response message (Section 10.6). 1250 10.6. Session Update Response Message 1252 A Session Update Response message MUST be sent by implementations to 1253 indicate whether a Session Update message (Section 10.5) was 1254 successfully received. 1256 To construct a Session Update Response message, the Message Type 1257 value in the message header is set to 6, from Table 1. 1259 The Session Update Response message MAY contain one Status 1260 (Section 11.1) data item. 1262 A receiver of a Session Update Response message without a Status data 1263 item MUST behave as if a Status data item with status code 'Success' 1264 had been received, see Table 3. 1266 10.7. Session Termination Message 1268 A Session Termination message MUST be sent by a participant when the 1269 DLEP session needs to be terminated. It should be noted that Session 1270 Termination messages can be sent by both routers and modems. 1272 To construct a Session Termination message, the Message Type value in 1273 the message header is set to 7, from Table 1. 1275 The Session Termination message MAY contain one Status (Section 11.1) 1276 data item. 1278 A receiver of a Session Termination message without a Status data 1279 item MUST behave as if a Status data item with status code 'Success', 1280 see Table 3, implying graceful termination, had been received. 1282 A Session Termination message MUST be acknowledged by the receiver 1283 issuing a Session Termination Response message (Section 10.8). 1285 10.8. Session Termination Response Message 1287 A Session Termination Response message MUST be sent by a DLEP 1288 participant in response to a received Session Termination message 1289 (Section 10.7). 1291 Receipt of a Session Termination Response message completes the tear- 1292 down of the DLEP session. 1294 To construct a Session Termination Response message, the Message Type 1295 value in the message header is set to 8, from Table 1. 1297 The Session Termination Response message MAY contain one Status 1298 (Section 11.1) data item. 1300 A receiver of a Session Termination Response message without a Status 1301 data item MUST behave as if a Status data item with status code 1302 'Success', see Table 3, implying graceful termination, had been 1303 received. 1305 10.9. Destination Up Message 1307 A Destination Up message MUST be sent by the modem to indicate that a 1308 new destination has been detected. A Destination Up message MUST be 1309 acknowledged by the router issuing a Destination Up Response message 1310 (Section 10.10). When a Destination Up message is received and 1311 successfully processed, the router should add knowledge of the new 1312 destination to its information base, indicating that the destination 1313 is accessible via the modem. 1315 To construct a Destination Up message, the Message Type value in the 1316 message header is set to 9, from Table 1. 1318 The Destination Up message MUST contain one of each of the following 1319 data items: 1321 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 modem 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) 1512 The Destination Down Response message MAY contain one of each of the 1513 following data items: 1515 o Status (Section 11.1) 1517 A receiver of a Destination Down Response message without a Status 1518 data item MUST behave as if a Status data item with status code 1519 'Success' had been received, see Table 3. 1521 10.15. Destination Update Message 1523 A DLEP modem SHOULD send the Destination Update message when it 1524 detects some change in the information base for a given destination 1525 (remote node or multicast group). Some examples of changes that 1526 would prompt a Destination Update message are: 1528 o Change in link metrics (e.g., Data Rates) 1530 o Layer 3 addressing change 1532 To construct a Destination Update message, the Message Type value in 1533 the message header is set to 13, from Table 1. 1535 The Destination Update message MUST contain one of each of the 1536 following data items: 1538 o MAC Address (Section 11.7) 1540 The Destination Update message MAY contain one of each of the 1541 following data items: 1543 o Maximum Data Rate (Receive) (Section 11.12) 1545 o Maximum Data Rate (Transmit) (Section 11.13) 1547 o Current Data Rate (Receive) (Section 11.14) 1549 o Current Data Rate (Transmit) (Section 11.15) 1551 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) 1559 o Relative Link Quality (Receive) (Section 11.19) 1561 o Relative Link Quality (Transmit) (Section 11.20) 1563 o Maximum Transmission Unit (MTU) (Section 11.21) 1565 The Destination Update message MAY contain one or more of the 1566 following data items, with different values: 1568 o IPv4 Address (Section 11.8) 1570 o IPv6 Address (Section 11.9) 1572 o IPv4 Attached Subnet (Section 11.10) 1574 o IPv6 Attached Subnet (Section 11.11) 1576 10.16. Heartbeat Message 1578 While Heartbeat messages are not required by DLEP implementations, it 1579 is strongly RECOMMENDED that Heartbeat messages be used. 1581 A Heartbeat message SHOULD be sent by a DLEP participant every N 1582 seconds, where N is defined in the Heartbeat Interval data item of 1583 the Session Initialization message (Section 10.3) or Session 1584 Initialization Response message (Section 10.4). 1586 Note that implementations setting the Heartbeat Interval to 0 1587 effectively sets the interval to an infinite value, turning off 1588 Heartbeat messages. Great care MUST be taken when exercising this 1589 option. 1591 The message is used by participants to detect when a DLEP session 1592 peer (either the modem or the router) is no longer communicating. 1593 Participants SHOULD allow two (2) heartbeat intervals to expire with 1594 no messages from the peer before initiating DLEP session termination 1595 procedures. 1597 To construct a Heartbeat message, the Message Type value in the 1598 message header is set to 14, from Table 1. 1600 There are no valid data items for the Heartbeat message. 1602 10.17. Link Characteristics Request Message 1604 The Link Characteristics Request message MAY be sent by a DLEP router 1605 to request that the modem initiate changes for specific 1606 characteristics of the link. The request can reference either a real 1607 destination (e.g., a remote node), or a logical destination (e.g., a 1608 multicast group) within the network. 1610 The Link Characteristics Request message MAY contain either a Current 1611 Data Rate (CDRR or CDRT) data item to request a different datarate 1612 than what is currently allocated, a Latency data item to request that 1613 traffic delay on the link not exceed the specified value, or both. A 1614 Link Characteristics Response message (Section 10.18) is required to 1615 complete the request. Issuing a Link Characteristics Request with 1616 ONLY the MAC Address data item is a mechanism a router MAY use to 1617 request metrics (via the Link Characteristics Response) from its 1618 modem. 1620 The router sending a Link Characteristics Request message should be 1621 aware that a request may take an extended period of time to complete. 1623 To construct a Link Characteristics Request message, the Message Type 1624 value in the message header is set to 15, from Table 1. 1626 The Link Characteristics Request message MUST contain one of each of 1627 the following data items: 1629 o MAC Address (Section 11.7) 1631 The Link Characteristics Request message MAY contain one of each of 1632 the following data items: 1634 o Current Data Rate (Receive) (Section 11.14) 1636 o Current Data Rate (Transmit) (Section 11.15) 1638 o Latency (Section 11.16) 1640 10.18. Link Characteristics Response Message 1642 A DLEP modem MUST send a Link Characteristics Response message to 1643 indicate whether a received Link Characteristics Request message 1644 (Section 10.17) was successfully processed. The Link Characteristics 1645 Response message SHOULD contain a complete set of metric data items, 1646 and MUST contain a full set (i.e. those declared in the Session 1647 Initialization Response message (Section 10.4)), if metrics were 1648 requested by only including a MAC address data item. It MUST contain 1649 the same metric types as the request. The values in the metric data 1650 items in the Link Characteristics Response message MUST reflect the 1651 link characteristics after the request has been processed. 1653 If an implementation is not able to alter the characteristics of the 1654 link in the manner requested, then the message MUST contain a Status 1655 data item with status code 'Request Denied', see Table 3. 1657 To construct a Link Characteristics Response message, the Message 1658 Type value in the message header is set to 16, from Table 1. 1660 The Link Characteristics Response message MUST contain one of each of 1661 the following data items: 1663 o MAC Address (Section 11.7) 1665 The Link Characteristics Response message SHOULD contain one of each 1666 of the following data items: 1668 o Maximum Data Rate (Receive) (Section 11.12) 1670 o Maximum Data Rate (Transmit) (Section 11.13) 1672 o Current Data Rate (Receive) (Section 11.14) 1674 o Current Data Rate (Transmit) (Section 11.15) 1676 o Latency (Section 11.16) 1678 The Link Characteristics Response message MAY contain one of each of 1679 the following data items: 1681 o Status (Section 11.1) 1683 The Link Characteristics Response message MAY contain one of each of 1684 the following data items, if the data item is in use by the session: 1686 o Resources (Receive) (Section 11.17) 1688 o Resources (Transmit) (Section 11.18) 1690 o Relative Link Quality (Receive) (Section 11.19) 1692 o Relative Link Quality (Transmit) (Section 11.20) 1694 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 | 1888 +-+-+-+-+-+-+-+-+ 1890 Reserved: MUST be zero. Reserved for future use. 1892 11.3. IPv6 Connection Point 1894 The IPv6 Connection Point data item MAY appear in the Peer Offer 1895 signal (Section 10.2). 1897 The IPv6 Connection Point data item indicates the IPv6 address and, 1898 optionally, the TCP port number on the DLEP modem available for 1899 connections. If provided, the router MUST use this information to 1900 perform the TCP connect to the modem. 1902 The IPv6 Connection Point data item contains the following fields: 1904 0 1 2 3 1905 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 1906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1907 | Data Item Type | Length | 1908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1909 | Flags | IPv6 Address : 1910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1911 : IPv6 Address : 1912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1913 : IPv6 Address : 1914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1915 : IPv6 Address : 1916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1917 : ...cont. | TCP Port Number (optional) | 1918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1920 Data Item Type: 3 1922 Length: 17 (or 19 if TCP Port included) 1924 Flags: Flags field, defined below. 1926 IPv6 Address: The IPv6 address listening on the DLEP modem. 1928 TCP Port Number: TCP Port number on the DLEP modem. 1930 If the Length field is 19, the port number specified MUST be used to 1931 establish the TCP session. If the TCP Port Number is omitted, i.e. 1932 the Length field is 17, the router MUST use the DLEP well-known port 1933 number (Section 13.6) to establish the TCP connection. 1935 The Flags field is defined as: 1937 0 1 2 3 4 5 6 7 1938 +-+-+-+-+-+-+-+-+ 1939 | Reserved | 1940 +-+-+-+-+-+-+-+-+ 1942 Reserved: MUST be zero. Reserved for future use. 1944 11.4. Peer Type 1946 The Peer Type data item MAY appear in the Peer Discovery 1947 (Section 10.1) and Peer Offer (Section 10.2) signals, and the Session 1948 Initialization (Section 10.3) and Session Initialization Response 1949 (Section 10.4) messages. 1951 The Peer Type data item is used by the router and modem to give 1952 additional information as to its type. The peer type is a string and 1953 is envisioned to be used for informational purposes (e.g., as output 1954 in a display command). 1956 The Peer Type data item contains the following fields: 1958 0 1 2 3 1959 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 1960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1961 | Data Item Type | Length | 1962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1963 | Peer Type... : 1964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1966 Data Item Type: 4 1968 Length: Length of peer type string, in octets. 1970 Peer Type: UTF-8 encoded string. For example, a satellite modem 1971 might set this variable to "Satellite terminal". Since this data 1972 item is intended to provide additional information for display 1973 commands, sending implementations SHOULD limit the data to 1974 printable characters, and receiving implementations SHOULD check 1975 the data for printable characters. 1977 An implementation MUST NOT assume the Peer Type field is NUL- 1978 terminated. 1980 11.5. Heartbeat Interval 1982 The Heartbeat Interval data item MUST appear in both the Session 1983 Initialization (Section 10.3) and Session Initialization Response 1984 (Section 10.4) messages to indicate the Heartbeat timeout window to 1985 be used by the sender. 1987 The Interval is used to specify a period (in seconds) for Heartbeat 1988 messages (Section 10.16). By specifying an Interval value of 0, 1989 implementations MAY indicate the desire to disable Heartbeat messages 1990 entirely (i.e., the Interval is set to an infinite value). However, 1991 it is RECOMMENDED that implementations use non-0 timer values. 1993 The Heartbeat Interval data item contains the following fields: 1995 0 1 2 3 1996 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 1997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1998 | Data Item Type | Length | 1999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2000 | Interval | 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2003 Data Item Type: 5 2005 Length: 2 2007 Interval: 0 = Do not use heartbeats on this DLEP session. Non-zero 2008 = Interval, in seconds, for heartbeat messages. 2010 11.6. Extensions Supported 2012 The Extensions Supported data item MAY be used in both the Session 2013 Initialization (Section 10.3) and Session Initialization Response 2014 (Section 10.4) messages. 2016 The Extensions Supported data item is used by the router and modem to 2017 negotiate additional optional functionality they are willing to 2018 support. The Extensions List is a concatenation of the types of each 2019 supported extension, found in the IANA DLEP Extensions repository. 2020 Each Extension Type definition includes which additional signals and 2021 data-items are supported. 2023 The Extensions Supported data item contains the following fields: 2025 0 1 2 3 2026 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 2027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2028 | Data Item Type | Length | 2029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2030 | Extensions List... 2031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2033 Data Item Type: 6 2035 Length: Length of the extensions list in octets. This is twice (2x) 2036 the number of extensions. 2038 Extension List: A list of extensions supported, identified by their 2039 2-octet value as listed in the extensions registry. 2041 11.7. MAC Address 2043 The MAC address data item MUST appear in all destination-oriented 2044 messages (i.e., Destination Up (Section 10.9), Destination Up 2045 Response (Section 10.10), Destination Down (Section 10.13), 2046 Destination Down Response (Section 10.14), Destination Update 2047 (Section 10.15), Link Characteristics Request (Section 10.17), and 2048 Link Characteristics Response (Section 10.18)). 2050 The MAC Address data item contains the address of the destination on 2051 the remote node. The MAC address MAY be either a physical or a 2052 virtual destination, and MAY be expressed in EUI-48 or EUI-64 format. 2053 Examples of a virtual destination would be a multicast MAC address, 2054 or the broadcast MAC (FF:FF:FF:FF:FF:FF). 2056 0 1 2 3 2057 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 2058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2059 | Data Item Type | Length | 2060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2061 | MAC Address : 2062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2063 : MAC Address : 2064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2065 : MAC Address : (if EUI-64 used) | 2066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2068 Data Item Type: 7 2070 Length: 6 for EUI-48 format, or 8 for EUI-64 format 2072 MAC Address: MAC Address of the destination. 2074 11.8. IPv4 Address 2076 The IPv4 Address data item MAY appear in the Session Update 2077 (Section 10.5), Destination Up (Section 10.9) and Destination Update 2078 (Section 10.15) messages. 2080 When included in Destination messages, this data item contains the 2081 IPv4 address of the destination. When included in the Session Update 2082 message, this data item contains the IPv4 address of the peer. In 2083 either case, the data item also contains an indication of whether 2084 this is a new or existing address, or is a deletion of a previously 2085 known address. 2087 The IPv4 Address data item contains the following fields: 2089 0 1 2 3 2090 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 2091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2092 | Data Item Type | Length | 2093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2094 | Flags | IPv4 Address : 2095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2096 : ...cont. | 2097 +-+-+-+-+-+-+-+-+ 2099 Data Item Type: 8 2101 Length: 5 2103 Flags: Flags field, defined below. 2105 IPv4 Address: The IPv4 address of the destination or peer. 2107 The Flags field is defined as: 2109 0 1 2 3 4 5 6 7 2110 +-+-+-+-+-+-+-+-+ 2111 | Reserved |A| 2112 +-+-+-+-+-+-+-+-+ 2114 A: Add/Drop flag, indicating whether this is a new or existing 2115 address (1), or a withdrawal of an address (0). 2117 Reserved: MUST be zero. Reserved for future use. 2119 11.9. IPv6 Address 2121 The IPv6 Address data item MAY appear in the Session Update 2122 (Section 10.5), Destination Up (Section 10.9) and Destination Update 2123 (Section 10.15) messages. When included in Destination messages, 2124 this data item contains the IPv6 address of the destination. When 2125 included in the Session Update message, this data item contains the 2126 IPv6 address of the peer. In either case, the data item also 2127 contains an indication of whether this is a new or existing address, 2128 or is a deletion of a previously known address. 2130 The IPv6 Address data item contains the following fields: 2132 0 1 2 3 2133 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 2134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2135 | Data Item Type | Length | 2136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2137 | Flags | IPv6 Address : 2138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2139 : IPv6 Address : 2140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2141 : IPv6 Address : 2142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2143 : IPv6 Address : 2144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2145 : IPv6 Address | 2146 +-+-+-+-+-+-+-+-+ 2148 Data Item Type: 9 2150 Length: 17 2152 Flags: Flags field, defined below. 2154 IPv6 Address: IPv6 Address of the destination or peer. 2156 The Flags field is defined as: 2158 0 1 2 3 4 5 6 7 2159 +-+-+-+-+-+-+-+-+ 2160 | Reserved |A| 2161 +-+-+-+-+-+-+-+-+ 2163 A: Add/Drop flag, indicating whether this is a new or existing 2164 address (1), or a withdrawal of an address (0). 2166 Reserved: MUST be zero. Reserved for future use. 2168 11.10. IPv4 Attached Subnet 2170 The DLEP IPv4 Attached Subnet allows a device to declare that it has 2171 an IPv4 subnet (e.g., a stub network) attached, that it has become 2172 aware of an IPv4 subnet being present at a remote destination, or 2173 that it has become aware of the loss of a subnet at the remote 2174 destination. The IPv4 Attached Subnet data item MAY appear in the 2175 Destination Up (Section 10.9) and Destination Update (Section 10.15) 2176 messages. 2178 The DLEP IPv4 Attached Subnet data item contains the following 2179 fields: 2181 0 1 2 3 2182 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 2183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2184 | Data Item Type | Length | 2185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2186 | Flags | IPv4 Attached Subnet : 2187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2188 : ...cont. |Prefix Length | 2189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2191 Data Item Type: 10 2193 Length: 6 2195 Flags: Flags field, defined below. 2197 IPv4 Subnet: The IPv4 subnet reachable at the destination. 2199 Prefix Length: Length of the prefix (1-32) for the IPv4 subnet. A 2200 prefix length outside the specified range MUST be considered as 2201 invalid. 2203 The Flags field is defined as: 2205 0 1 2 3 4 5 6 7 2206 +-+-+-+-+-+-+-+-+ 2207 | Reserved |A| 2208 +-+-+-+-+-+-+-+-+ 2210 A: Add/Drop flag, indicating whether this is a new or existing subnet 2211 address (1), or a withdrawal of a subnet address (0). 2213 Reserved: MUST be zero. Reserved for future use. 2215 11.11. IPv6 Attached Subnet 2217 The DLEP IPv6 Attached Subnet allows a device to declare that it has 2218 an IPv6 subnet (e.g., a stub network) attached, or that it has become 2219 aware of an IPv6 subnet being present at a remote destination. The 2220 IPv6 Attached Subnet data item MAY appear in the Destination Up 2221 (Section 10.9) and Destination Update (Section 10.15) messages. 2223 The DLEP IPv6 Attached Subnet data item contains the following 2224 fields: 2226 0 1 2 3 2227 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 2228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2229 | Data Item Type | Length | 2230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2231 | Flags | IPv6 Attached Subnet : 2232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2233 : IPv6 Attached Subnet : 2234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2235 : IPv6 Attached Subnet : 2236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2237 : IPv6 Attached Subnet : 2238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2239 : ...cont. | Prefix Len. | 2240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2242 Data Item Type: 11 2244 Length: 18 2246 Flags: Flags field, defined below. 2248 IPv6 Attached Subnet: The IPv6 subnet reachable at the destination. 2250 Prefix Length: Length of the prefix (1-128) for the IPv6 subnet. A 2251 prefix length outside the specified range MUST be considered as 2252 invalid. 2254 The Flags field is defined as: 2256 0 1 2 3 4 5 6 7 2257 +-+-+-+-+-+-+-+-+ 2258 | Reserved |A| 2259 +-+-+-+-+-+-+-+-+ 2261 A: Add/Drop flag, indicating whether this is a new or existing subnet 2262 address (1), or a withdrawal of a subnet address (0). 2264 Reserved: MUST be zero. Reserved for future use. 2266 11.12. Maximum Data Rate (Receive) 2268 The Maximum Data Rate (Receive) (MDRR) data item MUST appear in the 2269 Session Initialization Response message (Section 10.4), and MAY 2270 appear in the Session Update (Section 10.5), Destination Up 2271 (Section 10.9), Destination Update (Section 10.15) and Link 2272 Characteristics Response (Section 10.18) messages to indicate the 2273 maximum theoretical data rate, in bits per second, that can be 2274 achieved while receiving data on the link. 2276 The Maximum Data Rate (Receive) data item contains the following 2277 fields: 2279 0 1 2 3 2280 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 2281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2282 | Data Item Type | Length | 2283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2284 | MDRR (bps) : 2285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2286 : MDRR (bps) | 2287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2289 Data Item Type: 12 2291 Length: 8 2293 Maximum Data Rate (Receive): A 64-bit unsigned integer, representing 2294 the maximum theoretical data rate, in bits per second (bps), that 2295 can be achieved while receiving on the link. 2297 11.13. Maximum Data Rate (Transmit) 2299 The Maximum Data Rate (Transmit) (MDRT) data item MUST appear in the 2300 Session Initialization Response message (Section 10.4), and MAY 2301 appear in the Session Update (Section 10.5), Destination Up 2302 (Section 10.9), Destination Update (Section 10.15) and Link 2303 Characteristics Response (Section 10.18) messages to indicate the 2304 maximum theoretical data rate, in bits per second, that can be 2305 achieved while transmitting data on the link. 2307 The Maximum Data Rate (Transmit) data item contains the following 2308 fields: 2310 0 1 2 3 2311 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 2312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2313 | Data Item Type | Length | 2314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2315 | MDRT (bps) : 2316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2317 : MDRT (bps) | 2318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2320 Data Item Type: 13 2322 Length: 8 2324 Maximum Data Rate (Transmit): A 64-bit unsigned integer, 2325 representing the maximum theoretical data rate, in bits per second 2326 (bps), that can be achieved while transmitting on the link. 2328 11.14. Current Data Rate (Receive) 2330 The Current Data Rate (Receive) (CDRR) data item MUST appear in the 2331 Session Initialization Response message (Section 10.4), and MAY 2332 appear in the Session Update (Section 10.5), Destination Up 2333 (Section 10.9), Destination Update (Section 10.15) and Link 2334 Characteristics Response (Section 10.18) messages to indicate the 2335 rate at which the link is currently operating for receiving traffic. 2337 When used in the Link Characteristics Request message 2338 (Section 10.17), CDRR represents the desired receive rate, in bits 2339 per second, on the link. 2341 The Current Data Rate (Receive) data item contains the following 2342 fields: 2344 0 1 2 3 2345 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2347 | Data Item Type | Length | 2348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2349 | CDRR (bps) : 2350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2351 : CDRR (bps) | 2352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2354 Data Item Type: 14 2356 Length: 8 2357 Current Data Rate (Receive): A 64-bit unsigned integer, representing 2358 the current data rate, in bits per second, that can currently be 2359 achieved while receiving traffic on the link. 2361 If there is no distinction between current and maximum receive data 2362 rates, current data rate receive MUST be set equal to the maximum 2363 data rate receive. 2365 11.15. Current Data Rate (Transmit) 2367 The Current Data Rate Transmit (CDRT) data item MUST appear in the 2368 Session Initialization Response message (Section 10.4), and MAY 2369 appear in the Session Update (Section 10.5), Destination Up 2370 (Section 10.9), Destination Update (Section 10.15), and Link 2371 Characteristics Response (Section 10.18) messages to indicate the 2372 rate at which the link is currently operating for transmitting 2373 traffic. 2375 When used in the Link Characteristics Request message 2376 (Section 10.17), CDRT represents the desired transmit rate, in bits 2377 per second, on the link. 2379 The Current Data Rate (Transmit) data item contains the following 2380 fields: 2382 0 1 2 3 2383 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 2384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2385 | Data Item Type | Length | 2386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2387 | CDRT (bps) : 2388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2389 : CDRT (bps) | 2390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2392 Data Item Type: 15 2394 Length: 8 2396 Current Data Rate (Transmit): A 64-bit unsigned integer, 2397 representing the current data rate, in bits per second, that can 2398 currently be achieved while transmitting traffic on the link. 2400 If there is no distinction between current and maximum transmit data 2401 rates, current data rate transmit MUST be set equal to the maximum 2402 data rate transmit. 2404 11.16. Latency 2406 The Latency data item MUST appear in the Session Initialization 2407 Response message (Section 10.4), and MAY appear in the Session Update 2408 (Section 10.5), Destination Up (Section 10.9), Destination Update 2409 (Section 10.15), and Link Characteristics Response (Section 10.18) 2410 messages to indicate the amount of latency, in microseconds, on the 2411 link. 2413 When used in the Link Characteristics Request message 2414 (Section 10.17), Latency represents the maximum latency desired on 2415 the link. 2417 The Latency value is reported as delay. The calculation of latency 2418 is implementation dependent. For example, the latency may be a 2419 running average calculated from the internal queuing. 2421 0 1 2 3 2422 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 2423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2424 | Data Item Type | Length | 2425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2426 | Latency : 2427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2428 : Latency | 2429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2431 Data Item Type: 16 2433 Length: 8 2435 Latency: A 64-bit unsigned integer, representing the transmission 2436 delay, in microseconds, that a packet encounters as it is 2437 transmitted over the link. 2439 11.17. Resources (Receive) 2441 The Resources (Receive) (RESR) data item MAY appear in the Session 2442 Initialization Response message (Section 10.4), Session Update 2443 (Section 10.5), Destination Up (Section 10.9), Destination Update 2444 (Section 10.15) and Link Characteristics Response (Section 10.18) 2445 messages to indicate the amount of resources for reception (with 0 2446 meaning 'no resources available', and 100 meaning 'all resources 2447 available') at the destination. The list of resources that might be 2448 considered is beyond the scope of this document, and is left to 2449 implementations to decide. 2451 The Resources (Receive) data item contains the following fields: 2453 0 1 2 3 2454 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 2455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2456 | Data Item Type | Length | 2457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2458 | RESR | 2459 +-+-+-+-+-+-+-+-+ 2461 Data Item Type: 17 2463 Length: 1 2465 Resources (Receive): An 8-bit integer percentage, 0-100, 2466 representing the amount of resources allocated to receiving data. 2467 Any value greater than 100 MUST be considered as invalid. 2469 If a device cannot calculate RESR, this data item SHOULD NOT be 2470 issued. 2472 11.18. Resources (Transmit) 2474 The Resources (Transmit) (REST) data item MAY appear in the Session 2475 Initialization Response message (Section 10.4), Session Update 2476 (Section 10.5), Destination Up (Section 10.9), Destination Update 2477 (Section 10.15) and Link Characteristics Response (Section 10.18) 2478 messages to indicate the amount of resources for transmission (with 0 2479 meaning 'no resources available', and 100 meaning 'all resources 2480 available') at the destination. The list of resources that might be 2481 considered is beyond the scope of this document, and is left to 2482 implementations to decide. 2484 The Resources (Transmit) data item contains the following fields: 2486 0 1 2 3 2487 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 2488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2489 | Data Item Type | Length | 2490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2491 | REST | 2492 +-+-+-+-+-+-+-+-+ 2494 Data Item Type: 18 2496 Length: 1 2498 Resources (Transmit): An 8-bit integer percentage, 0-100, 2499 representing the amount of resources allocated to transmitting 2500 data. Any value greater than 100 MUST be considered as invalid. 2502 If a device cannot calculate REST, this data item SHOULD NOT be 2503 issued. 2505 11.19. Relative Link Quality (Receive) 2507 The Relative Link Quality (Receive) (RLQR) data item MAY appear in 2508 the Session Initialization Response message (Section 10.4), Session 2509 Update (Section 10.5), Destination Up (Section 10.9), Destination 2510 Update (Section 10.15) and Link Characteristics Response 2511 (Section 10.18) messages to indicate the quality of the link for 2512 receiving data. 2514 The Relative Link Quality (Receive) data item contains the following 2515 fields: 2517 0 1 2 3 2518 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 2519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2520 | Data Item Type | Length | 2521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2522 | RLQR | 2523 +-+-+-+-+-+-+-+-+ 2525 Data Item Type: 19 2527 Length: 1 2529 Relative Link Quality (Receive): A non-dimensional 8-bit integer, 2530 0-100, representing relative link quality. A value of 100 2531 represents a link of the highest quality. Any value greater than 2532 100 MUST be considered as invalid. 2534 If a device cannot calculate the RLQR, this data item SHOULD NOT be 2535 issued. 2537 11.20. Relative Link Quality (Transmit) 2539 The Relative Link Quality (Transmit) (RLQT) data item MAY appear in 2540 the Session Initialization Response message (Section 10.4), Session 2541 Update (Section 10.5), Destination Up (Section 10.9), Destination 2542 Update (Section 10.15) and Link Characteristics Response 2543 (Section 10.18) messages to indicate the quality of the link for 2544 transmitting data. 2546 The Relative Link Quality (Transmit) data item contains the following 2547 fields: 2549 0 1 2 3 2550 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 2551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2552 | Data Item Type | Length | 2553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2554 | RLQT | 2555 +-+-+-+-+-+-+-+-+ 2557 Data Item Type: 20 2559 Length: 1 2561 Relative Link Quality (Transmit): A non-dimensional 8-bit integer, 2562 0-100, representing relative link quality. A value of 100 2563 represents a link of the highest quality. Any value greater than 2564 100 MUST be considered as invalid. 2566 If a device cannot calculate the RLQT, this data item SHOULD NOT be 2567 issued. 2569 11.21. Maximum Transmission Unit (MTU) 2571 The Maximum Transmission Unit (MTU) data item MAY appear in the 2572 Session Initialization Response message (Section 10.4), Session 2573 Update (Section 10.5), Destination Up (Section 10.9), Destination 2574 Update (Section 10.15) and Link Characteristics Response 2575 (Section 10.18) messages to indicate the maximum size, in octets, of 2576 an IP packet that can be transmitted without fragmentation, including 2577 headers, but excluding any lower layer headers. 2579 The Maximum Transmission Unit (MTU) data item contains the following 2580 fields: 2582 0 1 2 3 2583 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 2584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2585 | Data Item Type | Length | 2586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2587 | MTU | 2588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2590 Data Item Type: 21 2592 Length: 2 2594 Maximum Transmission Unit (MTU): The maximum size, in octets, of an 2595 IP packet that can be transmitted without fragmentation, including 2596 headers, but excluding any lower layer headers. 2598 If a device cannot calculate the MTU, this data item SHOULD NOT be 2599 issued. 2601 12. Security Considerations 2603 The potential security concerns when using DLEP are: 2605 1. An attacker might pretend to be a DLEP peer, either at DLEP 2606 session initialization, or by injection of messages once a 2607 session has been established, and/or 2609 2. DLEP data items could be altered by an attacker, causing the 2610 receiving implementation to inappropriately alter its information 2611 base concerning network status. 2613 Since DLEP is restricted to operation over a single (possibly 2614 logical) hop at layer 2, implementations requiring authentication 2615 and/or encryption of traffic MUST take steps to secure the Layer 2 2616 link. Examples of technologies that can be deployed to secure the 2617 Layer 2 link include [IEEE-802.1AE] and [IEEE-802.1X]. 2619 To avoid potential denial of service attack, it is RECOMMENDED that 2620 implementations using the Peer Discovery mechanism maintain an 2621 information base of hosts that persistently fail Session 2622 Initialization having provided an acceptable Discovery signal, and 2623 ignore Peer Discovery signals from such hosts. 2625 This specification does not address security of the data plane, as it 2626 (the data plane) is not affected, and standard security procedures 2627 can be employed. 2629 13. IANA Considerations 2631 This section specifies requests to IANA. 2633 13.1. Registrations 2635 This specification defines: 2637 o A new repository for DLEP signals and messages, with eighteen (18) 2638 values currently assigned. 2640 o Reservation of a Private Use numbering space within the above 2641 repository for experimental DLEP signals and messages. 2643 o A new repository for DLEP data items, with twenty-one (21) values 2644 currently assigned. 2646 o Reservation of a Private Use numbering space within the data items 2647 repository for experimental data items. 2649 o A new repository for DLEP status codes, with eight (8) currently 2650 assigned. 2652 o Reservation of a Private Use numbering space within the status 2653 codes repository for experimental status codes. 2655 o A new repository for DLEP extensions, with one (1) value currently 2656 assigned. 2658 o Reservation of a Private Use numbering space within the extension 2659 repository for experimental extensions. 2661 o A request for allocation of a well-known port for DLEP TCP and UDP 2662 communication. 2664 o A request for allocation of a link-local multicast IPv4 address 2665 for DLEP discovery. 2667 o A request for allocation of a link-local multicast IPv6 address 2668 for DLEP discovery. 2670 13.2. Signal/Message Type Registration 2672 A new repository must be created with the values of the DLEP signals 2673 and messages, entitled "Message Type Values for the Dynamic Link 2674 Event Protocol (DLEP)". The repository is to be managed using the 2675 "Specification Required" policy documented in [RFC5226]. 2677 All signal and message values are in the range [0..65535], defined in 2678 Table 1. 2680 13.3. DLEP Data Item Registrations 2682 A new repository for DLEP data items must be created, entitled "Data 2683 Item Type Values for the Dynamic Link Event Protocol (DLEP)". The 2684 repository is to be managed using the "Specification Required" policy 2685 documented in [RFC5226]. 2687 All data item values are in the range [0..65535], defined in Table 2. 2689 13.4. DLEP Status Code Registrations 2691 A new repository for DLEP status codes must be created, entitled 2692 "Status Code Values for the Dynamic Link Event Protocol (DLEP)". The 2693 repository is to be managed using the "Specification Required" policy 2694 documented in [RFC5226]. 2696 All status codes are in the range [0..255], defined in Table 3. 2698 13.5. DLEP Extensions Registrations 2700 A new repository for DLEP extensions must be created, entitled 2701 "Extension Type Values for the Dynamic Link Event Protocol (DLEP)". 2702 The repository is to be managed using the "Specification Required" 2703 policy documented in [RFC5226]. 2705 All extension values are in the range [0..65535]. Current 2706 allocations are: 2708 +-------------+-----------------------------------------------------+ 2709 | Code | Description | 2710 +-------------+-----------------------------------------------------+ 2711 | 0 | Reserved | 2712 | 1 | Credit Windowing | 2713 | 2-65519 | Unassigned. Available for future extensions | 2714 | 65520-65534 | Private Use. Available for experiments | 2715 | 65535 | Reserved | 2716 +-------------+-----------------------------------------------------+ 2718 Table 4: DLEP Extension types 2720 13.6. DLEP Well-known Port 2722 It is requested that IANA allocate a single well-known port number 2723 for both TCP and UDP, for DLEP communication. SCTP port allocation 2724 is not required. 2726 13.7. DLEP IPv4 Link-local Multicast Address 2728 It is requested that IANA allocate an IPv4 link-local multicast 2729 address for DLEP discovery signals. 2731 13.8. DLEP IPv6 Link-local Multicast Address 2733 It is requested that IANA allocate an IPv6 link-local multicast 2734 address for DLEP discovery signals. 2736 14. Acknowledgements 2738 We would like to acknowledge and thank the members of the DLEP design 2739 team, who have provided invaluable insight. The members of the 2740 design team are: Teco Boot, Bow-Nan Cheng, John Dowdell, and Henning 2741 Rogge. 2743 We would also like to acknowledge the influence and contributions of 2744 Greg Harrison, Chris Olsen, Martin Duke, Subir Das, Jaewon Kang, 2745 Vikram Kaul, Nelson Powell, Lou Berger, and Victoria Mercieca. 2747 15. References 2749 15.1. Normative References 2751 [CREDIT] Ratliff, S., "Credit Windowing extension for DLEP", draft- 2752 ietf-manet-credit-window-00 IETF draft, October 2015. 2754 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2755 Requirement Levels", BCP 14, RFC 2119, 2756 DOI 10.17487/RFC2119, March 1997, 2757 . 2759 15.2. Informative References 2761 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2762 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2763 DOI 10.17487/RFC5226, May 2008, 2764 . 2766 [RFC5578] Berry, B., Ed., Ratliff, S., Paradise, E., Kaiser, T., and 2767 M. Adams, "PPP over Ethernet (PPPoE) Extensions for Credit 2768 Flow and Link Metrics", RFC 5578, DOI 10.17487/RFC5578, 2769 February 2010, . 2771 [IEEE-802.1AE] 2772 IEEE Standards for Local and Metropolitan Area 2773 Networks: Media Access Control (MAC) Security, July 2006 2775 [IEEE-802.1X] 2776 IEEE Standards for Local and Metropolitan Area 2777 Networks: Port based Network Access Control, IEEE 2778 P802.1x-2001, June 2001. 2780 Appendix A. Discovery Signal Flows 2781 Router Modem Signal Description 2782 ======================================================================== 2784 | Router initiates discovery, starts 2785 | a timer, send Peer Discovery 2786 |-------Peer Discovery---->|| signal. 2788 ~ ~ ~ ~ ~ ~ ~ Router discovery timer expires 2789 without receiving Peer Offer. 2791 | Router sends another Peer 2792 |-------Peer Discovery---------->| Discovery signal. 2793 | 2794 | Modem receives Peer Discovery 2795 | signal. 2796 | 2797 | Modem sends Peer Offer with 2798 |<--------Peer Offer-------------| Connection Point information. 2799 : 2800 : Router MAY cancel discovery timer 2801 : and stop sending Peer Discovery 2802 : signals. 2804 Appendix B. Peer Level Message Flows 2806 B.1. Session Initialization 2808 Router Modem Message Description 2809 ======================================================================== 2811 | Router connects to discovered or 2812 | pre-configured Modem Connection 2813 |---------TCP connect----------> Point. 2814 | 2815 | Router sends Session 2816 |----Session Initialization----->| Initialization message. 2817 | 2818 | Modem receives Session 2819 | Initialization message. 2820 | 2821 | Modem sends Session Initialization 2822 |<--Session Initialization Resp.-| Response, with Success status data 2823 | | item. 2824 | | 2825 |<<============================>>| Session established. Heartbeats 2826 : : begin. 2828 B.2. Session Initialization - Refused 2830 Router Modem Message Description 2831 ======================================================================== 2833 | Router connects to discovered or 2834 | pre-configured Modem Connection 2835 |---------TCP connect----------> Point. 2836 | 2837 | Router sends Session 2838 |-----Session Initialization---->| Initialization message. 2839 | 2840 | Modem receives Session 2841 | Initialization message, and will 2842 | not support the advertised 2843 | extensions. 2844 | 2845 | Modem sends Session Initialization 2846 | Response, with 'Request Denied' 2847 |<-Session Initialization Resp.--| status data item. 2848 | 2849 | 2850 | Router receives negative Session 2851 | Initialization Response, closes 2852 ||---------TCP close------------|| TCP connection. 2854 B.3. Router Changes IP Addresses 2856 Router Modem Message Description 2857 ======================================================================== 2859 | Router sends Session Update 2860 |-------Session Update---------->| message to announce change of IP 2861 | address 2862 | 2863 | Modem receives Session Update 2864 | message and updates internal 2865 | state. 2866 | 2867 |<----Session Update Response----| Modem sends Session Update 2868 | Response. 2870 B.4. Modem Changes Session-wide Metrics 2871 Router Modem Message Description 2872 ======================================================================== 2874 | Modem sends Session Update message 2875 | to announce change of modem-wide 2876 |<--------Session Update---------| metrics 2877 | 2878 | Router receives Session Update 2879 | message and updates internal 2880 | state. 2881 | 2882 |----Session Update Response---->| Router sends Session Update 2883 | Response. 2885 B.5. Router Terminates Session 2887 Router Modem Message Description 2888 ======================================================================== 2890 | Router sends Session Termination 2891 |------Session Termination------>| message with Status data item. 2892 | | 2893 |-------TCP shutdown (send)---> | Router stops sending messages. 2894 | 2895 | Modem receives Session 2896 | Termination, stops counting 2897 | received heartbeats and stops 2898 | sending heartbeats. 2899 | 2900 | Modem sends Session Termination 2901 |<---Session Termination Resp.---| Response with Status 'Success'. 2902 | 2903 | Modem stops sending messages. 2904 | 2905 ||---------TCP close------------|| Session terminated. 2907 B.6. Modem Terminates Session 2908 Router Modem Message Description 2909 ======================================================================== 2911 | Modem sends Session Termination 2912 |<----Session Termination--------| message with Status data item. 2913 | 2914 | Modem stops sending messages. 2915 | 2916 | Router receives Session 2917 | Termination, stops counting 2918 | received heartbeats and stops 2919 | sending heartbeats. 2920 | 2921 | Router sends Session Termination 2922 |---Session Termination Resp.--->| Response with Status 'Success'. 2923 | 2924 | Router stops sending messages. 2925 | 2926 ||---------TCP close------------|| Session terminated. 2928 B.7. Session Heartbeats 2929 Router Modem Message Description 2930 ======================================================================== 2932 |----------Heartbeat------------>| Router sends heartbeat message 2933 | 2934 | Modem resets heartbeats missed 2935 | counter. 2937 ~ ~ ~ ~ ~ ~ ~ 2939 |---------[Any message]--------->| When the Modem receives any 2940 | message from the Router. 2941 | 2942 | Modem resets heartbeats missed 2943 | counter. 2945 ~ ~ ~ ~ ~ ~ ~ 2947 |<---------Heartbeat-------------| Modem sends heartbeat message 2948 | 2949 | Router resets heartbeats missed 2950 | counter. 2952 ~ ~ ~ ~ ~ ~ ~ 2954 |<--------[Any message]----------| When the Router receives any 2955 | message from the Modem. 2956 | 2957 | Modem resets heartbeats missed 2958 | counter. 2960 B.8. Router Detects a Heartbeat timeout 2962 Router Modem Message Description 2963 ======================================================================== 2965 ||<----------------------| Router misses a heartbeat 2967 | ||<----------------------| Router misses too many heartbeats 2968 | 2969 | 2970 |------Session Termination------>| Router sends Session Termination 2971 | message with 'Timeout' Status 2972 | data item. 2973 : 2974 : Termination proceeds as above. 2976 B.9. Modem Detects a Heartbeat timeout 2978 Router Modem Message Description 2979 ======================================================================== 2981 |---------------------->|| Modem misses a heartbeat 2983 |---------------------->|| | Modem misses too many heartbeats 2984 | 2985 | 2986 |<-----Session Termination-------| Modem sends Session Termination 2987 | message with 'Timeout' Status 2988 | data item. 2989 : 2990 : Termination proceeds as above. 2992 Appendix C. Destination Specific Message Flows 2994 C.1. Common Destination Notification 2995 Router Modem Message Description 2996 ======================================================================== 2998 | Modem detects a new logical 2999 | destination is reachable, and 3000 |<-------Destination Up----------| sends Destination Up message. 3001 | 3002 |------Destination Up Resp.----->| Router sends Destination Up 3003 | Response. 3005 ~ ~ ~ ~ ~ ~ ~ 3006 | Modem detects change in logical 3007 | destination metrics, and sends 3008 |<-------Destination Update------| Destination Update message. 3010 ~ ~ ~ ~ ~ ~ ~ 3011 | Modem detects change in logical 3012 | destination metrics, and sends 3013 |<-------Destination Update------| Destination Update message. 3015 ~ ~ ~ ~ ~ ~ ~ 3016 | Modem detects logical destination 3017 | is no longer reachable, and sends 3018 |<-------Destination Down--------| Destination Down message. 3019 | 3020 | Router receives Destination Down, 3021 | updates internal state, and sends 3022 |------Destination Down Resp.--->| Destination Down Response message. 3024 C.2. Multicast Destination Notification 3025 Router Modem Message Description 3026 ======================================================================== 3028 | Router detects a new multicast 3029 | destination is in use, and sends 3030 |--------Destination Up--------->| Destination Up message. 3031 | 3032 | Modem updates internal state to 3033 | monitor multicast destination, and 3034 |<-----Destination Up Resp.------| sends Destination Up Response. 3036 ~ ~ ~ ~ ~ ~ ~ 3037 | Modem detects change in multicast 3038 | destination metrics, and sends 3039 |<-------Destination Update------| Destination Update message. 3041 ~ ~ ~ ~ ~ ~ ~ 3042 | Modem detects change in multicast 3043 | destination metrics, and sends 3044 |<-------Destination Update------| Destination Update message. 3046 ~ ~ ~ ~ ~ ~ ~ 3047 | Router detects multicast 3048 | destination is no longer in use, 3049 |--------Destination Down------->| and sends Destination Down 3050 | message. 3051 | 3052 | Modem receives Destination Down, 3053 | updates internal state, and sends 3054 |<-----Destination Down Resp.----| Destination Down Response message. 3056 C.3. Link Characteristics Request 3057 Router Modem Message Description 3058 ======================================================================== 3060 Destination has already been 3061 ~ ~ ~ ~ ~ ~ ~ announced by either peer. 3063 | Router requires different 3064 | Characteristics for the 3065 | destination, and sends Link 3066 |--Link Characteristics Request->| Characteristics Request message. 3067 | 3068 | Modem attempts to adjust link 3069 | status to meet the received 3070 | request, and sends a Link 3071 | Characteristics Response 3072 |<---Link Characteristics Resp.--| message with the new values. 3074 Authors' Addresses 3076 Stan Ratliff 3077 VT iDirect 3078 13861 Sunrise Valley Drive, Suite 300 3079 Herndon, VA 20171 3080 USA 3082 Email: sratliff@idirect.net 3084 Shawn Jury 3085 Cisco Systems 3086 170 West Tasman Drive 3087 San Jose, CA 95134 3088 USA 3090 Email: sjury@cisco.com 3092 Darryl Satterwhite 3093 Broadcom 3095 Email: dsatterw@broadcom.com 3096 Rick Taylor 3097 Airbus Defence & Space 3098 Quadrant House 3099 Celtic Springs 3100 Coedkernew 3101 Newport NP10 8FZ 3102 UK 3104 Email: rick.taylor@airbus.com 3106 Bo Berry