idnits 2.17.00 (12 Aug 2021) /tmp/idnits46893/draft-ietf-manet-dlep-20.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 44 instances of too long lines in the document, the longest one being 3 characters in excess of 72. 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 (March 8, 2016) is 2265 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 2571, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-manet-credit-window-02 -- Possible downref: Non-RFC (?) normative reference: ref. 'UNIV8' -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile Ad hoc Networks Working Group S. Ratliff 2 Internet-Draft VT iDirect 3 Intended status: Standards Track B. Berry 4 Expires: September 9, 2016 5 S. Jury 6 Cisco Systems 7 D. Satterwhite 8 Broadcom 9 R. Taylor 10 Airbus Defence & Space 11 March 8, 2016 13 Dynamic Link Exchange Protocol (DLEP) 14 draft-ietf-manet-dlep-20 16 Abstract 18 When routing devices rely on modems to effect communications over 19 wireless links, they need timely and accurate knowledge of the 20 characteristics of the link (speed, state, etc.) in order to make 21 routing decisions. In mobile or other environments where these 22 characteristics change frequently, manual configurations or the 23 inference of state through routing or transport protocols does not 24 allow the router to make the best decisions. A bidirectional, event- 25 driven communication channel between the router and the modem is 26 necessary. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 9, 2016. 45 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 7 63 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 64 2.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 9 65 3. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 4. DLEP Session Flow . . . . . . . . . . . . . . . . . . . . . . 10 67 4.1. Peer Discovery State . . . . . . . . . . . . . . . . . . 11 68 4.2. Session Initialization State . . . . . . . . . . . . . . 12 69 4.3. In-Session State . . . . . . . . . . . . . . . . . . . . 12 70 4.3.1. Heartbeats . . . . . . . . . . . . . . . . . . . . . 13 71 4.4. Session Termination State . . . . . . . . . . . . . . . . 13 72 4.5. Session Reset state . . . . . . . . . . . . . . . . . . . 13 73 4.5.1. Unexpected TCP connection termination . . . . . . . . 14 74 5. Transaction Model . . . . . . . . . . . . . . . . . . . . . . 14 75 6. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 6.1. Experiments . . . . . . . . . . . . . . . . . . . . . . . 15 77 7. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 8. DLEP Signal and Message Structure . . . . . . . . . . . . . . 16 79 8.1. DLEP Signal Header . . . . . . . . . . . . . . . . . . . 17 80 8.2. DLEP Message Header . . . . . . . . . . . . . . . . . . . 17 81 8.3. DLEP Generic Data Item . . . . . . . . . . . . . . . . . 18 82 9. DLEP Signals and Messages . . . . . . . . . . . . . . . . . . 18 83 9.1. General Processing Rules . . . . . . . . . . . . . . . . 20 84 9.2. Status code processing . . . . . . . . . . . . . . . . . 20 85 9.3. Peer Discovery Signal . . . . . . . . . . . . . . . . . . 21 86 9.4. Peer Offer Signal . . . . . . . . . . . . . . . . . . . . 21 87 9.5. Session Initialization Message . . . . . . . . . . . . . 22 88 9.6. Session Initialization Response Message . . . . . . . . . 23 89 9.7. Session Update Message . . . . . . . . . . . . . . . . . 24 90 9.8. Session Update Response Message . . . . . . . . . . . . . 25 91 9.9. Session Termination Message . . . . . . . . . . . . . . . 26 92 9.10. Session Termination Response Message . . . . . . . . . . 26 93 9.11. Destination Up Message . . . . . . . . . . . . . . . . . 26 94 9.12. Destination Up Response Message . . . . . . . . . . . . . 27 95 9.13. Destination Announce Message . . . . . . . . . . . . . . 28 96 9.14. Destination Announce Response Message . . . . . . . . . . 29 97 9.15. Destination Down Message . . . . . . . . . . . . . . . . 30 98 9.16. Destination Down Response Message . . . . . . . . . . . . 30 99 9.17. Destination Update Message . . . . . . . . . . . . . . . 31 100 9.18. Link Characteristics Request Message . . . . . . . . . . 32 101 9.19. Link Characteristics Response Message . . . . . . . . . . 33 102 9.20. Heartbeat Message . . . . . . . . . . . . . . . . . . . . 34 103 10. DLEP Data Items . . . . . . . . . . . . . . . . . . . . . . . 34 104 10.1. Status . . . . . . . . . . . . . . . . . . . . . . . . . 35 105 10.2. IPv4 Connection Point . . . . . . . . . . . . . . . . . 37 106 10.3. IPv6 Connection Point . . . . . . . . . . . . . . . . . 38 107 10.4. Peer Type . . . . . . . . . . . . . . . . . . . . . . . 39 108 10.5. Heartbeat Interval . . . . . . . . . . . . . . . . . . . 39 109 10.6. Extensions Supported . . . . . . . . . . . . . . . . . . 40 110 10.7. MAC Address . . . . . . . . . . . . . . . . . . . . . . 41 111 10.8. IPv4 Address . . . . . . . . . . . . . . . . . . . . . . 41 112 10.9. IPv6 Address . . . . . . . . . . . . . . . . . . . . . . 42 113 10.10. IPv4 Attached Subnet . . . . . . . . . . . . . . . . . . 43 114 10.11. IPv6 Attached Subnet . . . . . . . . . . . . . . . . . . 44 115 10.12. Maximum Data Rate (Receive) . . . . . . . . . . . . . . 45 116 10.13. Maximum Data Rate (Transmit) . . . . . . . . . . . . . . 46 117 10.14. Current Data Rate (Receive) . . . . . . . . . . . . . . 46 118 10.15. Current Data Rate (Transmit) . . . . . . . . . . . . . . 47 119 10.16. Latency . . . . . . . . . . . . . . . . . . . . . . . . 48 120 10.17. Resources . . . . . . . . . . . . . . . . . . . . . . . 48 121 10.18. Relative Link Quality (Receive) . . . . . . . . . . . . 49 122 10.19. Relative Link Quality (Transmit) . . . . . . . . . . . . 50 123 10.20. Maximum Transmission Unit (MTU) . . . . . . . . . . . . 50 124 11. Security Considerations . . . . . . . . . . . . . . . . . . . 51 125 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 126 12.1. Registrations . . . . . . . . . . . . . . . . . . . . . 52 127 12.2. Signal Type Registration . . . . . . . . . . . . . . . . 53 128 12.3. Message Type Registration . . . . . . . . . . . . . . . 53 129 12.4. DLEP Data Item Registrations . . . . . . . . . . . . . . 53 130 12.5. DLEP Status Code Registrations . . . . . . . . . . . . . 53 131 12.6. DLEP Extensions Registrations . . . . . . . . . . . . . 53 132 12.7. DLEP Well-known Port . . . . . . . . . . . . . . . . . . 54 133 12.8. DLEP IPv4 Link-local Multicast Address . . . . . . . . . 54 134 12.9. DLEP IPv6 Link-local Multicast Address . . . . . . . . . 54 135 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54 136 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 137 14.1. Normative References . . . . . . . . . . . . . . . . . . 54 138 14.2. Informative References . . . . . . . . . . . . . . . . . 55 139 Appendix A. Discovery Signal Flows . . . . . . . . . . . . . . . 55 140 Appendix B. Peer Level Message Flows . . . . . . . . . . . . . . 56 141 B.1. Session Initialization . . . . . . . . . . . . . . . . . 56 142 B.2. Session Initialization - Refused . . . . . . . . . . . . 56 143 B.3. Router Changes IP Addresses . . . . . . . . . . . . . . . 57 144 B.4. Modem Changes Session-wide Metrics . . . . . . . . . . . 57 145 B.5. Router Terminates Session . . . . . . . . . . . . . . . . 58 146 B.6. Modem Terminates Session . . . . . . . . . . . . . . . . 58 147 B.7. Session Heartbeats . . . . . . . . . . . . . . . . . . . 58 148 B.8. Router Detects a Heartbeat timeout . . . . . . . . . . . 59 149 B.9. Modem Detects a Heartbeat timeout . . . . . . . . . . . . 59 150 Appendix C. Destination Specific Message Flows . . . . . . . . . 60 151 C.1. Common Destination Notification . . . . . . . . . . . . . 60 152 C.2. Multicast Destination Notification . . . . . . . . . . . 61 153 C.3. Link Characteristics Request . . . . . . . . . . . . . . 61 154 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62 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 | 287 +---+----+ 288 | Router | 289 | | 290 +--------+ 292 Figure 2: DLEP Network with Multiple Modem Devices 294 1.1. Requirements 296 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 297 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 298 "OPTIONAL" in this document are to be interpreted as described in BCP 299 14, RFC 2119 [RFC2119]. 301 2. Protocol Overview 303 DLEP defines a set of Messages used by modems and their attached 304 routers to communicate events that occur on the physical link(s) 305 managed by the modem: for example, a remote node entering or leaving 306 the network, or that the link has changed. Associated with these 307 Messages are a set of Data Items - information that describes the 308 remote node (e.g., address information), and/or the characteristics 309 of the link to the remote node. Throughout this document, we refer 310 to a modems/routers participating in a DLEP session as 'DLEP Peers', 311 or 'DLEP Participants', unless a specific distinction (e.g. modem or 312 router) is required. 314 DLEP uses a session-oriented paradigm between the modem device and 315 its associated router. If multiple modem devices are attached to a 316 router (as in Figure 2), or the modem supports multiple connections 317 (via multiple logical or physical interfaces), then separate DLEP 318 sessions exist for each modem or connection. A router and modem form 319 a session by completing the discovery and initialization process. 320 This router-modem session persists unless or until it either (1) 321 times out, based on the absence of DLEP traffic (including 322 heartbeats), or (2) is explicitly torn down by one of the DLEP 323 participants. 325 The router/modem session provides a carrier for information exchange 326 concerning 'destinations' that are available via the modem device. 327 Destinations can be identified by either the router or the modem, and 328 represent a specific, addressable location that can be reached via 329 the link(s) managed by the modem. 331 The DLEP Messages concerning destinations thus become the way for 332 routers and modems to maintain, and notify each other about, an 333 information base representing the physical and logical destinations 334 accessible via the modem device, as well as the link characteristics 335 to those destinations. 337 DLEP indentifies destinations by using the MAC address for delivering 338 data traffic. No manipulation or substitution is performed; the MAC 339 address supplied in all destination Messages is used as the OSI Layer 340 2 Destination MAC address. DLEP therefore requires that MAC 341 addresses are unique within the context of a router-modem session. 343 The reliance on MAC addresses by DLEP forces the requirement that 344 participating DLEP peers are on a single segment (either physical or 345 logically, via tunneling protocols) at Layer 2. 347 A destination can be either physical or logical. The example of a 348 physical destination would be that of a remote, far-end router 349 attached via the variable-quality network. It should be noted that 350 for physical destinations the MAC address is the address of the far- 351 end router, not the modem. 353 The example of a logical destination is Multicast. Multicast traffic 354 destined for the variable-quality network (the network accessed via 355 the modem) is handled in IP networks by deriving a Layer 2 MAC 356 address based on the Layer 3 address. Leveraging on this scheme, 357 multicast traffic is supported in DLEP simply by treating the derived 358 MAC address as any other destination in the network. 360 To support these logical destinations, one of the DLEP participants 361 (typically, the router) informs the other as to the existence of the 362 logical destination. The modem, once it is aware of the existence of 363 this logical destination, reports link characteristics just as it 364 would for any other destination in the network. The specific 365 algorithms a modem would use to derive metrics on logical 366 destinations are outside the scope of this specification, and is left 367 to specific implementations to decide. 369 While this document represents the best efforts of the working group 370 to be functionally complete, it is recognized that extensions to DLEP 371 will in all likelihood be necessary as more link types are used. 372 Such extensions are defined as additional rules of behavior, 373 Messages, Data Items and/or status codes that are not defined in this 374 document. DLEP contains a standard mechanism for router and modem 375 implementations to negotiate the available extensions to use on a 376 per-session basis. 378 2.1. Assumptions 380 DLEP specifies UDP multicast for single-hop discovery signaling, and 381 TCP for transport of the Messages. Therefore, DLEP assumes that the 382 modem and router have topologically consistent IP addresses assigned. 383 It is RECOMMENDED that DLEP implementations utilize IPv6 link-local 384 addresses to reduce the administrative burden of address assignment. 385 DLEP relies on the guaranteed- delivery of its Messages between 386 router and modem, once the 1 hop discovery process is complete, 387 hence, the specification of TCP to carry the Messages. Other 388 reliable transports for the protocol are possible, but are outside 389 the scope of this document. 391 DLEP further assumes that security of the implementations (e.g., 392 authentication of stations, encryption of traffic, or both) is dealt 393 with by utilizing Layer 2 security techniques. This reliance on 394 Layer 2 mechanisms secures all DLEP Messages - both the UDP discovery 395 Signals and the TCP control Messages. 397 3. Metrics 399 DLEP includes the ability for the router and modem to communicate 400 metrics that reflect the characteristics (e.g., datarate, latency) of 401 the variable-quality link in use. DLEP does not specify how a given 402 metric value is to be calculated, rather, the protocol assumes that 403 metrics have been calculated by a 'best effort', incorporating all 404 pertinent data that is available to the modem device. 406 DLEP allows for metrics to be sent within two contexts - metrics for 407 a specific destination within the network (e.g., a specific router), 408 and per-session (those that apply to all destinations accessed via 409 the modem). Most metrics can be further subdivided into transmit and 410 receive metrics. In cases where metrics are provided at session 411 level, the router MUST propagate the metrics to all entries in its 412 information base for destinations that are accessed via the modem. 414 DLEP modem implementations MUST announce all metric Data Items that 415 will be reported during the session, and provide default values for 416 those metrics, in the Session Initialization Response Message 417 (Section 9.6). In order to use a metric type that was not included 418 in the Session Initialization Response Message, modem implementations 419 MUST terminate the session with the router (via the Session Terminate 420 Message (Section 9.9)), and establish a new session. 422 A DLEP modem MAY send metrics both in a session context (via the 423 Session Update Message) and a specific destination context (via 424 Destination Update) at any time. The most recently received metric 425 value MUST take precedence over any earlier value, regardless of 426 context - that is: 428 1. If the router receives metrics in a specific destination context 429 (via the Destination Update Message), then the specific 430 destination is updated with the new metric. 432 2. If the router receives metrics in a session-wide context (via the 433 Session Update Message), then the metrics for all destinations 434 accessed via the modem MUST be updated with the new metric. 436 It is left to implementations to choose sensible default values based 437 on their specific characteristics. Modems having static (non- 438 changing) link metric characteristics MAY report metrics only once 439 for a given destination (or once on a session-wide basis, if all 440 connections via the modem are of this static nature). 442 In addition to communicating existing metrics about the link, DLEP 443 provides a Message allowing a router to request a different datarate 444 or latency from the modem. This Message is the Link Characteristics 445 Request Message (Section 9.18), and gives the router the ability to 446 deal with requisite increases (or decreases) of allocated datarate/ 447 latency in demand-based schemes in a more deterministic manner. 449 4. DLEP Session Flow 451 All DLEP participants of a session transition through a number of 452 distinct states during the lifetime of a DLEP session: 454 o Peer Discovery 456 o Session Initialization 458 o In-Session 460 o Session Termination 462 o Session Reset 464 Modems, and routers supporting DLEP discovery, transition through all 465 five (5) of the above states. Routers that rely on preconfigured TCP 466 address/port information start in the Session Initialization state. 468 Modems MUST support the Peer Discovery state. 470 4.1. Peer Discovery State 472 In the Peer Discovery state, routers that support DLEP discovery MUST 473 send UDP packets containing a Peer Discovery Signal (Section 9.3) to 474 the DLEP well-known address and port number. For routers supporting 475 both IPv4 and IPv6 DLEP operation, it is RECOMMENDED that IPv6 be 476 selected as the transport. 478 The router implementation then waits for a unicast UDP packet 479 containing a Peer Offer Signal (Section 9.4) from a potential DLEP 480 peer modem. While in the Peer Discovery state, Peer Discovery 481 Signals MUST be sent repeatedly by a DLEP router, at regular 482 intervals. The interval MUST be a minimum of one second; it SHOULD 483 be a configurable parameter. Note that this operation (sending Peer 484 Discovery and waiting for Peer Offer) is outside the DLEP Transaction 485 Model, as the Transaction Model only describes Messages on a TCP 486 session. 488 Routers MUST use one or more of the modem address/port combinations 489 from the Peer Offer Signal or from a priori configuration to 490 establish a new TCP connection to the modem. If more than one modem 491 address/port combinations is available, router implementations MAY 492 use their own heuristics to determine the order in which they are 493 tried. If a TCP connection cannot be achieved using any of the 494 address/port combinations and the Discovery mechanism is in use, then 495 the router SHOULD resume issuing Peer Discovery Signals. If no IPv4 496 Connection Point Data Items, nor IPv6 Connection Point Data Items are 497 included in the Peer Offer Signal, the router MUST use the source 498 address of the UDP packet containing the Signal as the IP address, 499 and the DLEP well-known port number. 501 In the Peer Discovery state, the modem implementation MUST listen for 502 incoming Peer Discovery Signals on the DLEP well-known link-local 503 multicast address and port. On receipt of a valid Peer Discovery 504 Signal, it MUST unicast a Peer Offer Signal to the source address and 505 port of the received UDP packet. 507 Modems MUST be prepared to accept a TCP connection from a router that 508 is not using the Discovery mechanism, i.e. a connection attempt that 509 occurs without a preceding Peer Discovery Signal. 511 Upon establishment of a TCP connection, both modem and router enter 512 the Session Initialization state. It is up to the router 513 implementation if Peer Discovery Signals continue to be sent after 514 the device has transitioned to the Session Initialization state. 515 Modem implementations MUST silently ignore Peer Discovery Signals 516 from a router with which it already has a TCP connection. 518 4.2. Session Initialization State 520 On entering the Session Initialization state, the router MUST send a 521 Session Initialization Message (Section 9.5) to the modem. The 522 router MUST then wait for receipt of a Session Initialization 523 Response Message (Section 9.6) from the modem. Receipt of the 524 Session Initialization Response Message containing a Status Data Item 525 (Section 10.1) with status code set to 0 'Success', see Table 4, 526 indicates that the modem has received and processed the Session 527 Initialization Message, and the router MUST transition to the In- 528 Session state. 530 On entering the Session Initialization state, the modem MUST wait for 531 receipt of a Session Initialization Message from the router. Upon 532 receipt of a Session Initialization Message, the modem MUST send a 533 Session Initialization Response Message, and the session MUST 534 transition to the In-Session state. If the modem receives any 535 Message other than Session Initialization, or it fails to parse the 536 received Message, it MUST NOT send any Message, and MUST terminate 537 the TCP connection and transition to the Session Reset state. 539 DLEP provides an extension negotiation capability to be used in the 540 Session Initialization state, see Section 6. Extensions supported by 541 an implementation MUST be declared to potential DLEP peers using the 542 Extensions Supported Data Item (Section 10.6). Once both DLEP peers 543 have exchanged initialization Messages, an implementation MUST NOT 544 emit any Message, Signal, Data Item or status code associated with an 545 extension that was not specified in the received initialization 546 Message from its peer. 548 4.3. In-Session State 550 In the In-Session state, Messages can flow in both directions between 551 DLEP peers, indicating changes to the session state, the arrival or 552 departure of reachable destinations, or changes of the state of the 553 links to the destinations. 555 The In-Session state is maintained until one of the following 556 conditions occur: 558 o The implementation terminates the session by sending a Session 559 Termination Message (Section 9.9)), or, 561 o The peer terminates the session, indicated by receiving a Session 562 Termination Message. 564 The implementation MUST then transition to the Session Termination 565 state. 567 4.3.1. Heartbeats 569 In order to maintain the In-Session state, periodic Heartbeat 570 Messages (Section 9.20) MUST be exchanged between router and modem. 571 These Messages are intended to keep the session alive, and to verify 572 bidirectional connectivity between the two DLEP peers. 574 Each DLEP participant is responsible for the creation of Heartbeat 575 Messages. 577 Receipt of any valid DLEP Message MUST reset the heartbeat interval 578 timer (i.e., valid DLEP Messages take the place of, and obviate the 579 need for, additional Heartbeat Messages). 581 Implementations SHOULD allow two (2) heartbeat intervals to expire 582 with no Messages from the peer before terminating the session by 583 issuing a Session Termination Message containing a Status Data Item 584 (Section 10.1) with status code set to 5 'Timed Out', see Table 4, 585 and then transition to the Session Termination state. 587 4.4. Session Termination State 589 When an implementation enters the Session Termination state after 590 sending a Session Termination Message (Section 9.9) as the result of 591 an invalid Message or error, it MUST wait for a Session Termination 592 Response Message (Section 9.10) from its peer. Senders SHOULD allow 593 four (4) heartbeat intervals to expire before assuming that the peer 594 is unresponsive, and continuing with session termination. Any other 595 Message received while waiting MUST be silently ignored. 597 When the sender of the Session Termination Message receives a Session 598 Termination Response Message from its peer, or times out, it MUST 599 transition to the Session Reset state. 601 When an implementation enters the Session Termination state having 602 received a Session Termination Message from its peer, it MUST 603 immediately send a Session Termination Response and transition to the 604 Session Reset state. 606 4.5. Session Reset state 608 In the Session Reset state the implementation MUST perform the 609 following actions: 611 o Release all resources allocated for the session. 613 o Eliminate all destinations in the information base represented by 614 the session. Destination Down Messages (Section 9.15) MUST NOT be 615 sent. 617 o Terminate the TCP connection. 619 Having completed these actions the implementation SHOULD return to 620 the relevant initial state: Peer Discovery for modems; either Peer 621 Discovery or Session Initialization for routers, depending on 622 configuration. 624 4.5.1. Unexpected TCP connection termination 626 If the TCP connection between DLEP peers is terminated when an 627 implementation is not in the Session Reset state, the implementation 628 MUST immediately transition to the Session Reset state. 630 5. Transaction Model 632 DLEP defines a simple Message transaction model: Only one request per 633 destination may be in progress at a time per session. A Message 634 transaction is considered complete when a response matching a 635 previously issued request is received. If a DLEP participant 636 receives a request for a destination for which there is already an 637 outstanding request, the implementation MUST terminate the session by 638 issuing a Session Termination Message (Section 9.9) containing a 639 Status Data Item (Section 10.1) with status code set to 2 'Unexpected 640 Message', see Table 4, and transition to the Session Termination 641 state. There is no restriction to the total number of Message 642 transactions in progress at a time, as long as each transaction 643 refers to a different destination. 645 It should be noted that some requests may take a considerable amount 646 of time for some DLEP participants to complete, for example a modem 647 handling a multicast destination up request may have to perform a 648 complex network reconfiguration. A sending implementation MUST be 649 able to handle such long running transactions gracefully. 651 Additionally, only one session request, e.g. a Session Initialization 652 Message (Section 9.5), may be in progress at a time per session. As 653 above, a session transaction is considered complete when a response 654 matching a previously issued request is received. If a DLEP 655 participant receives a session request while there is already a 656 session request in progress, it MUST terminate the session by issuing 657 a Session Termination Message containing a Status Data Item with 658 status code set to 2 'Unexpected Message', and transition to the 659 Session Termination state. Only the Session Termination Message may 660 be issued when a session transaction is in progress. Heartbeat 661 Messages (Section 9.20) MUST NOT be considered part of a session 662 transaction. 664 DLEP transactions do not time out and are not cancellable. An 665 implementation can detect if its peer has failed in some way by use 666 of the session heartbeat mechanism during the In-Session state, see 667 Section 4.3. 669 6. Extensions 671 Extensions MUST be negotiated on a per-session basis during session 672 initialization via the Extensions Supported mechanism. 673 Implementations are not required to support any extension in order to 674 be considered DLEP compliant. An extension document, describing the 675 operation of a credit windowing scheme for flow control, is described 676 in [CREDIT]. 678 If interoperable protocol extensions are required, they MUST be 679 standardized either as an update to this document, or as an 680 additional stand-alone specification. The requests for IANA- 681 controlled registries in this document contain sufficient Reserved 682 space for DLEP Signals, Messages, Data Items and status codes to 683 accommodate future extensions to the protocol. 685 As multiple protocol extensions MAY be announced during session 686 initialization, authors of protocol extensions MUST consider the 687 interaction of their extension with other published extensions, and 688 specify any incompatibilities. 690 6.1. Experiments 692 This document requests Private Use numbering space in the DLEP 693 Signal, Message, Data Item and status code registries for 694 experimental extensions. The intent is to allow for experimentation 695 with new Signals, Messages, Data Items, and/or status codes, while 696 still retaining the documented DLEP behavior. 698 Use of the Private Use Signals, Messages, Data Items, status codes, 699 or behaviors MUST be announced as DLEP Extensions, during session 700 initialization, using extension identifiers from the Private Use 701 space in the Extensions Supported registry (Table 5), with a value 702 agreed upon (a priori) between the participating peers. DLEP 703 extensions using the Private Use numbering space are commonly 704 referred to as Experiments. 706 Multiple experiments MAY be announced in the Session Initialization 707 Messages. However, use of multiple experiments in a single session 708 could lead to interoperability issues or unexpected results (e.g., 709 clashes of experimental Signals, Messages, Data Items and/or status 710 code types), and is therefore discouraged. It is left to 711 implementations to determine the correct processing path (e.g., a 712 decision on whether to terminate the session, or to establish a 713 precedence of the conflicting definitions) if such conflicts arise. 715 7. Scalability 717 The protocol is intended to support thousands of destinations on a 718 given modem/router pair. At large scale, implementations SHOULD 719 consider employing techniques to prevent flooding a peer with a large 720 number of Messages in a short time. It is recommended that 721 implementations consider a dampening algorithm to prevent a flapping 722 device from generating a large number of Destination Up/Destination 723 Down Messages, for example. Implementations SHOULD also consider 724 techniques such as a hysteresis to lessen the impact of rapid, minor 725 fluctuations in link quality. The specific algorithms to be used for 726 handling flapping destinations and minor changes in link quality are 727 outside the scope of this specification. 729 8. DLEP Signal and Message Structure 731 DLEP defines two protocol units used in two different ways: Signals 732 and Messages. Signals are only used in the Discovery mechanism and 733 are carried in UDP datagrams. Messages are used bi-directionally 734 over a TCP connection between two peers, in the Session 735 Initialization, In-Session and Session Termination states. 737 Both Signals and Messages consist of a Header followed by an 738 unordered list of Data Items. Headers consist of Type and Length 739 information, while Data Items are encoded as TLV (Type-Length-Value) 740 structures. In this document, the Data Items following a Signal or 741 Message Header are described as being 'contained in' the Signal or 742 Message. 744 There is no restriction on the order of Data Items following a 745 Header, and the multiplicity of duplicate Data Items is defined by 746 the definition of the Signal or Message declared by the type in the 747 Header. 749 All integers in Header fields and values MUST be in network byte- 750 order. 752 8.1. DLEP Signal Header 754 The DLEP Signal Header contains the following fields: 756 0 1 2 3 757 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 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | 'D' | 'L' | 'E' | 'P' | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Signal Type | Length | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 Figure 3: DLEP Signal Header 766 "DLEP": Every Signal MUST start with the characters: U+0044, U+004C, 767 U+0045, U+0050. 769 Signal Type: A 16-bit unsigned integer containing one of the DLEP 770 Signal Type values defined in this document. 772 Length: The length in octets, expressed as a 16-bit unsigned 773 integer, of all of the DLEP Data Items associated with this 774 Signal. This length MUST NOT include the length of the Signal 775 Header itself. 777 The DLEP Signal Header is immediately followed by zero or more DLEP 778 Data Items, encoded in TLVs, as defined in this document. 780 8.2. DLEP Message Header 782 The DLEP Message Header contains the following fields: 784 0 1 2 3 785 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 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | Message Type | Length | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 Figure 4: DLEP Message Header 792 Message Type: A 16-bit unsigned integer containing one of the DLEP 793 Message Type values defined in this document. 795 Length: The length in octets, expressed as a 16-bit unsigned 796 integer, of all of the DLEP Data Items associated with this 797 Message. This length MUST NOT include the length of the Message 798 Header itself. 800 The DLEP Message Header is immediately followed by zero or more DLEP 801 Data Items, encoded in TLVs, as defined in this document. 803 8.3. DLEP Generic Data Item 805 All DLEP Data Items contain the following fields: 807 0 1 2 3 808 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 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | Data Item Type | Length | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | Value... : 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 Figure 5: DLEP Generic Data Item 817 Data Item Type: A 16-bit unsigned integer field specifying the type 818 of Data Item being sent. 820 Length: The length in octets, expressed as a 16-bit unsigned 821 integer, of the Value field of the Data Item. This length MUST 822 NOT include the length of the Data Item Type and Length fields. 824 Value: A field of octets, which contains data specific to a 825 particular Data Item. 827 9. DLEP Signals and Messages 829 As mentioned above, all DLEP Signals begin with the DLEP Signal 830 Header, and all DLEP Messages begin with the DLEP Message Header. 831 Therefore, in the following descriptions of specific Signals and 832 Messages, this Header is assumed, and will not be replicated. 834 Following is the set of core Signals and Messages that MUST be 835 recognized by a DLEP compliant implementation. As mentioned before, 836 not all Messages may be used during a session, but an implementation 837 MUST correctly process these Messages when received. 839 The core DLEP Signals are: 841 +--------------+-----------------------------------------+ 842 | Type Code | Description | 843 +--------------+-----------------------------------------+ 844 | 0 | Reserved | 845 | 1 | Peer Discovery Signal (Section 9.3) | 846 | 2 | Peer Offer Signal (Section 9.4) | 847 | 3-65519 | Reserved for future extensions | 848 | 65520-65534 | Private Use. Available for experiments | 849 | 65535 | Reserved | 850 +--------------+-----------------------------------------+ 852 Table 1: DLEP Signal types 854 The core DLEP Messages are: 856 +-------------------+-----------------------------------------------+ 857 | Type Code | Description | 858 +-------------------+-----------------------------------------------+ 859 | 0 | Reserved | 860 | 1 | Session Initialization Message (Section 9.5) | 861 | 2 | Session Initialization Response Message | 862 | | (Section 9.6) | 863 | 3 | Session Update Message (Section 9.7) | 864 | 4 | Session Update Response Message (Section 9.8) | 865 | 5 | Session Termination Message (Section 9.9) | 866 | 6 | Session Termination Response Message (Section | 867 | | 9.10) | 868 | 7 | Destination Up Message (Section 9.11) | 869 | 8 | Destination Up Response Message (Section | 870 | | 9.12) | 871 | 9 | Destination Announce Message (Section 9.13) | 872 | 10 | Destination Announce Response Message | 873 | | (Section 9.14) | 874 | 11 | Destination Down Message (Section 9.15) | 875 | 12 | Destination Down Response Message (Section | 876 | | 9.16) | 877 | 13 | Destination Update Message (Section 9.17) | 878 | 14 | Link Characteristics Request Message (Section | 879 | | 9.18) | 880 | 15 | Link Characteristics Response Message | 881 | | (Section 9.19) | 882 | 16 | Heartbeat Message (Section 9.20) | 883 | 17-65519 | Reserved for future extensions | 884 | 65520-65534 | Private Use. Available for experiments | 885 | 65535 | Reserved | 886 +-------------------+-----------------------------------------------+ 888 Table 2: DLEP Message types 890 9.1. General Processing Rules 892 If an unrecognized, or unexpected Signal is received, or a received 893 Signal contains unrecognized, invalid, or disallowed duplicate Data 894 Items, the receiving DLEP peer MUST ignore the Signal. 896 If an unrecognized Message is received, the receiving DLEP peer MUST 897 issue a Session Termination Message (Section 9.9) containing a Status 898 Data Item (Section 10.1) with status code set to 1 'Unknown Message', 899 see Table 4, and transition to the Session Termination state. 901 If an unexpected Message is received, the receiving DLEP peer MUST 902 issue a Session Termination Message containing a Status Data Item 903 with status code set to 2 'Unexpected Message', and transition to the 904 Session Termination state. 906 If a received Message contains unrecognized, invalid, or disallowed 907 duplicate Data Items, the receiving DLEP peer MUST issue a Session 908 Termination Message containing a Status Data Item with status code 909 set to 3 'Invalid Data', and transition to the Session Termination 910 state. 912 Prior to the exchange of Destination Up (Section 9.11) and 913 Destination Up Response (Section 9.12) Messages, or Destination 914 Announce (Section 9.13) and Destination Announce Response 915 (Section 9.14) Messages, no Messages concerning a destination may be 916 sent. A peer receiving any Message with such an unannounced 917 destination MUST terminate the session by issuing a Session 918 Termination Message containing a Status Data Item with status code 919 set to 4 'Invalid Destination', and transition to the Session 920 Termination state. 922 After exchanging Destination Down (Section 9.15) and Destination Down 923 Response (Section 9.16) Messages, no Messages concerning a 924 destination may be a sent until a new Destination Up or Destination 925 Announce Message is sent. A peer receiving a Message about a 926 destination previously announced as 'down' MUST terminate the session 927 by issuing a Session Termination Message with a Status Data Item with 928 status code set to 4 'Invalid Destination', and transition to the 929 Session Termination state. 931 9.2. Status code processing 932 The behaviour of a DLEP participant receiving a Message containing a 933 Status Data Item (Section 10.1) is defined by the failure mode 934 associated with the value of the status code field, see Table 4. 935 Except for the reserved value of 255, all status code values greater 936 than or equal to 100 have a failure mode of 'Continue', all other 937 status codes have a failure mode of 'Terminate'. 939 A DLEP participant receiving any Message apart from Session 940 Termination Message (Section 9.9) containing a Status Data Item with 941 a status code value with failure mode 'Terminate' MUST immediately 942 issue a Session Termination Message containing an identical Status 943 Data Item, and then transition to the Session Termination state. 945 A DLEP participant receiving a Message containing a Status Data Item 946 with a status code value with failure mode 'Continue' can continue 947 normal operation of the session. 949 9.3. Peer Discovery Signal 951 A Peer Discovery Signal SHOULD be sent by a DLEP router to discover 952 DLEP modems in the network. 954 To construct a Peer Discovery Signal, the Signal Type value in the 955 Signal Header is set to 1, from Table 1. 957 The Peer Discovery Signal MAY contain a Peer Type Data Item 958 (Section 10.4). 960 Implementations MUST implement their own retransmit heuristics in 961 cases where it is determined the Peer Discovery Signal has timed out. 963 9.4. Peer Offer Signal 965 A Peer Offer Signal MUST be sent by a DLEP modem to the unicast 966 address of the originator of a valid Peer Discovery Signal 967 (Section 9.3). The Peer Offer Signal is completes the discovery 968 process. 970 To construct a Peer Offer Signal, the Signal Type value in the Signal 971 Header is set to 2, from Table 1. 973 The Peer Offer Signal MAY contain a Peer Type Data Item 974 (Section 10.4). 976 The Peer Offer Signal MAY contain one or more of any of the following 977 Data Items, with different values: 979 o IPv4 Connection Point (Section 10.2) 980 o IPv6 Connection Point (Section 10.3) 982 The IP Connection Point Data Items indicate the unicast address the 983 router MUST use when connecting the DLEP TCP session. If multiple IP 984 Connection Point Data Items are present in the Peer Offer Signal, 985 router implementations MAY use their own heuristics to select the 986 address to connect to. If no IP Connection Point Data Items are 987 included in the Peer Offer Signal, the router MUST use the source 988 address of the Signal as the IP address, and the DLEP well-known port 989 number (Section 12.7) to establish the TCP connection. 991 9.5. Session Initialization Message 993 A Session Initialization Message MUST be sent by a DLEP router as the 994 first Message of the DLEP TCP session. It is sent by the router 995 after a TCP connect to an address/port combination that was obtained 996 either via receipt of a Peer Offer, or from a priori configuration. 998 To construct a Session Initialization Message, the Message Type value 999 in the Message Header is set to 1, from Table 2. 1001 The Session Initialization Message MUST contain a Heartbeat Interval 1002 Data Item (Section 10.5). 1004 The Session Initialization Message MAY contain one of each of the 1005 following Data Items: 1007 o Peer Type (Section 10.4) 1009 o Extensions Supported (Section 10.6) 1011 If any optional extensions are supported by the implementation, they 1012 MUST be enumerated in the Extensions Supported Data Item. If an 1013 Extensions Supported Data Item does not exist in a Session 1014 Initialization Message, the modem MUST conclude that there is no 1015 support for extensions in the router. 1017 DLEP Heartbeats are not fully established until receipt of Session 1018 Initialization Response Message (Section 9.6), and therefore 1019 implementations must use their own timeout and retry heuristics for 1020 this Message. 1022 As an exception to the general rule governing an implementation 1023 receiving an unrecognized Data Item in a Message, see Section 9.1, if 1024 a Session Initialization Message contains one or more Extension 1025 Supported Data Items announcing support for extensions that the 1026 implementation does not recognize, then the implementation MAY ignore 1027 Data Items it does not recognize. 1029 9.6. Session Initialization Response Message 1031 A Session Initialization Response Message MUST be sent in response to 1032 a received Session Initialization Message (Section 9.5). 1034 To construct a Session Initialization Response Message, the Message 1035 Type value in the Message Header is set to 2, from Table 2. 1037 The Session Initialization Response Message MUST contain one of each 1038 of the following Data Items: 1040 o Status (Section 10.1) 1042 o Heartbeat Interval (Section 10.5) 1044 o Maximum Data Rate (Receive) (Section 10.12) 1046 o Maximum Data Rate (Transmit) (Section 10.13) 1048 o Current Data Rate (Receive) (Section 10.14) 1050 o Current Data Rate (Transmit) (Section 10.15) 1052 o Latency (Section 10.16) 1054 The Session Initialization Response Message MUST contain one of each 1055 of the following Data Items, if the Data Item will be used during the 1056 lifetime of the session: 1058 o Resources (Section 10.17) 1060 o Relative Link Quality (Receive) (Section 10.18) 1062 o Relative Link Quality (Transmit) (Section 10.19) 1064 o Maximum Transmission Unit (MTU) (Section 10.20) 1066 The Session Initialization Response Message MAY contain one of each 1067 of the following Data Items: 1069 o Peer Type (Section 10.4) 1071 o Extensions Supported (Section 10.6) 1072 The Session Initialization Response Message completes the DLEP 1073 session establishment; the modem should transition to the In-Session 1074 state when the Message is sent, and the router should transition to 1075 the In-Session state upon receipt of an acceptable Session 1076 Initialization Response Message. 1078 All supported metric Data Items MUST be included in the Session 1079 Initialization Response Message, with default values to be used on a 1080 session-wide basis. This can be viewed as the modem 'declaring' all 1081 supported metrics at DLEP session initialization. Receipt of any 1082 further DLEP Message containing a metric Data Item not included in 1083 the Session Initialization Response Message MUST be treated as an 1084 error, resulting in the termination of the DLEP session between 1085 router and modem. 1087 If any optional extensions are supported by the modem, they MUST be 1088 enumerated in the Extensions Supported Data Item. If an Extensions 1089 Supported Data Item does not exist in a Session Initialization 1090 Response Message, the router MUST conclude that there is no support 1091 for extensions in the modem. 1093 After the Session Initialization/Session Initialization Response 1094 Messages have been successfully exchanged, implementations MUST only 1095 use extensions that are supported by both DLEP peers. 1097 9.7. Session Update Message 1099 A Session Update Message MAY be sent by a DLEP participant to 1100 indicate local Layer 3 address changes, or metric changes on a 1101 session-wide basis. 1103 To construct a Session Update Message, the Message Type value in the 1104 Message Header is set to 3, from Table 2. 1106 The Session Update Message MAY contain one of each of the following 1107 Data Items: 1109 o Maximum Data Rate (Receive) (Section 10.12) 1111 o Maximum Data Rate (Transmit) (Section 10.13) 1113 o Current Data Rate (Receive) (Section 10.14) 1115 o Current Data Rate (Transmit) (Section 10.15) 1117 o Latency (Section 10.16) 1118 The Session Update Message MAY contain one of each of the following 1119 Data Items, if the Data Item is in use by the session: 1121 o Resources (Section 10.17) 1123 o Relative Link Quality (Receive) (Section 10.18) 1125 o Relative Link Quality (Transmit) (Section 10.19) 1127 o Maximum Transmission Unit (MTU) (Section 10.20) 1129 The Session Update Message MAY contain one or more of the following 1130 Data Items, with different values: 1132 o IPv4 Address (Section 10.8) 1134 o IPv6 Address (Section 10.9) 1136 If metrics are supplied with the Session Update Message (e.g., 1137 Maximum Data Rate), these metrics are considered to be session-wide, 1138 and therefore MUST be applied to all destinations in the information 1139 base associated with the DLEP session. 1141 It should be noted that Session Update Messages can be sent by both 1142 routers and modems. For example, addition of an IPv4 address to the 1143 router MAY prompt a Session Update Message to its attached modems. 1144 Also, for example, a modem that changes its Maximum Data Rate 1145 (Receive) for all destinations MAY reflect that change via a Session 1146 Update Message to its attached router(s). 1148 Concerning Layer 3 addresses: If the modem is capable of 1149 understanding and forwarding this information (via proprietary 1150 mechanisms), the address update would prompt any remote DLEP modems 1151 (DLEP-enabled modems in a remote node) to issue a Destination Update 1152 Message (Section 9.17) to their local routers with the new (or 1153 deleted) addresses. Modems that do not track Layer 3 addresses 1154 SHOULD silently ignore Address Data Items. 1156 9.8. Session Update Response Message 1158 A Session Update Response Message MUST be sent by by a DLEP 1159 participant when a Session Update Message (Section 9.7) is received. 1161 To construct a Session Update Response Message, the Message Type 1162 value in the Message Header is set to 4, from Table 2. 1164 The Session Update Response Message MUST contain a Status Data Item 1165 (Section 10.1). 1167 9.9. Session Termination Message 1169 A Session Termination Message MUST be sent by a DLEP participant when 1170 the DLEP session needs to be terminated. 1172 To construct a Session Termination Message, the Message Type value in 1173 the Message Header is set to 5, from Table 2. 1175 The Session Termination Message MUST contain Status Data Item 1176 (Section 10.1). 1178 It should be noted that Session Termination Messages can be sent by 1179 both routers and modems. 1181 9.10. Session Termination Response Message 1183 A Session Termination Response Message MUST be sent by a DLEP 1184 participant when a Session Termination Message (Section 9.9) is 1185 recevied. 1187 To construct a Session Termination Response Message, the Message Type 1188 value in the Message Header is set to 6, from Table 2. 1190 There are no valid Data Items for the Session Termination Response 1191 Message. 1193 Receipt of a Session Termination Response Message completes the tear- 1194 down of the DLEP session. 1196 9.11. Destination Up Message 1198 Destination Up Messages are sent by a modem to inform its attached 1199 router of the presence of a new reachable destination. 1201 To construct a Destination Up Message, the Message Type value in the 1202 Message Header is set to 7, from Table 2. 1204 The Destination Up Message MUST contain a MAC Address Data Item 1205 (Section 10.7). 1207 The Destination Up Message SHOULD contain one or more of the 1208 following Data Items, with different values: 1210 o IPv4 Address (Section 10.8) 1212 o IPv6 Address (Section 10.9) 1213 The Destination Up Message MAY contain one of each of the following 1214 Data Items: 1216 o Maximum Data Rate (Receive) (Section 10.12) 1218 o Maximum Data Rate (Transmit) (Section 10.13) 1220 o Current Data Rate (Receive) (Section 10.14) 1222 o Current Data Rate (Transmit) (Section 10.15) 1224 o Latency (Section 10.16) 1226 The Destination Up Message MAY contain one of each of the following 1227 Data Items, if the Data Item is in use by the session: 1229 o Resources (Section 10.17) 1231 o Relative Link Quality (Receive) (Section 10.18) 1233 o Relative Link Quality (Transmit) (Section 10.19) 1235 o Maximum Transmission Unit (MTU) (Section 10.20) 1237 The Destination Up Message MAY contain one or more of the following 1238 Data Items, with different values: 1240 o IPv4 Attached Subnet (Section 10.10) 1242 o IPv6 Attached Subnet (Section 10.11) 1244 A router receiving a Destination Up Message allocates the necessary 1245 resources, creating an entry in the information base with the 1246 specifics (i.e. MAC Address, Latency, Data Rate, etc.) of the 1247 destination. The information about this destination will persist in 1248 the router's information base until a Destination Down Message 1249 (Section 9.15) is received, indicating that the modem has lost 1250 contact with the remote node, or the implementation transitions to 1251 the Session Termination state. 1253 9.12. Destination Up Response Message 1255 A router MUST send a Destination Up Response Message when a 1256 Destination Up Message (Section 9.11) is received. 1258 To construct a Destination Up Response Message, the Message Type 1259 value in the Message Header is set to 8, from Table 2. 1261 The Destination Up Response Message MUST contain one of each of the 1262 following Data Items: 1264 o MAC Address (Section 10.7) 1266 o Status (Section 10.1) 1268 A router that wishes to receive further information concerning the 1269 destination identified in the corresponding Destination Up Message 1270 MUST set the status code of the included Status Data Item to 0 1271 'Success', see Table 4. 1273 If the router has no interest in the destination identified in the 1274 corresponding Destination Up Message, then it MAY set the status code 1275 of the included Status Data Item to 100 'Not Interested'. 1277 A modem receiving a Destination Up Response Message containing a 1278 Status Data Item with status code of any value other than 0 'Success' 1279 MUST NOT send further Destination messages about the destination, 1280 e.g. Destination Down (Section 9.15) or Destination Update 1281 (Section 9.17) with the same MAC address. 1283 9.13. Destination Announce Message 1285 Usually a modem will discover the presence of one or more remote 1286 router/modem pairs and announce each destination's arrival by sending 1287 a corresponding Destination Up Message (Section 9.11) to the router. 1288 However, there may be times when a router wishes to express an 1289 interest in a destination that has yet to be announced, typically a 1290 multicast destination. Destination Announce Messages MAY be sent by 1291 a router to announce such an interest. 1293 A Destination Announce Message MAY also be used by a router to 1294 request information concerning a destination in which it has 1295 previously declined interest, via the 100 'Not Interested' status 1296 code in a Destination Up Response Message (Section 9.12), see Table 1297 4, or declared as 'down', via the Destination Down Message 1298 (Section 9.15). 1300 To construct a Destination Announce Message, the Message Type value 1301 in the Message Header is set to 9, from Table 2. 1303 The Destination Announce Message MUST contain a MAC Address Data Item 1304 (Section 10.7). 1306 The Destination Announce Message MAY contain zero or more of the 1307 following Data Items, with different values: 1309 o IPv4 Address (Section 10.8) 1311 o IPv6 Address (Section 10.9) 1313 One of the advantages of implementing DLEP is to leverage the modem's 1314 knowledge of the links between remote destinations allowing routers 1315 to avoid using probed neighbor discovery techniques, therefore modem 1316 implementations SHOULD announce available destinations via the 1317 Destination Up Message, rather than relying on Destination Announce 1318 Messages. 1320 9.14. Destination Announce Response Message 1322 A modem MUST send a Destination Announce Response Message when a 1323 Destination Announce Message (Section 9.13) is received. 1325 To construct a Destination Announce Response Message, the Message 1326 Type value in the Message Header is set to 10, from Table 2. 1328 The Destination Announce Response Message MUST contain one of each of 1329 the following Data Items: 1331 o MAC Address (Section 10.7) 1333 o Status (Section 10.1) 1335 The Destination Announce Response Message MAY contain one of each of 1336 the following Data Items: 1338 o Maximum Data Rate (Receive) (Section 10.12) 1340 o Maximum Data Rate (Transmit) (Section 10.13) 1342 o Current Data Rate (Receive) (Section 10.14) 1344 o Current Data Rate (Transmit) (Section 10.15) 1346 o Latency (Section 10.16) 1348 The Destination Announce Response Message MAY contain one of each of 1349 the following Data Items, if the Data Item is in use by the session: 1351 o Resources (Section 10.17) 1353 o Relative Link Quality (Receive) (Section 10.18) 1355 o Relative Link Quality (Transmit) (Section 10.19) 1356 o Maximum Transmission Unit (MTU) (Section 10.20) 1358 If a modem is unable to report information immediately about the 1359 requested information, if the destination is not currently reachable, 1360 for example, the status code in the Status Data Item MUST be set to 1361 101 'Request Denied', see Table 4. 1363 After sending a Destination Announce Response Message containing a 1364 Status Data Item with status code of 0 'Success', a modem then 1365 announces changes to the link to the destination via Destination 1366 Update Messages. 1368 When a successful Destination Announce Response Message is received, 1369 the router should add knowledge of the available destination to its 1370 information base. 1372 9.15. Destination Down Message 1374 A modem MUST send a Destination Down Message to report when a 1375 destination (a remote node or a multicast group) is no longer 1376 reachable. 1378 A router MAY send a Destination Down Message to report when it no 1379 longer requires information concerning a destination. 1381 To construct a Destination Down Message, the Message Type value in 1382 the Message Header is set to 11, from Table 2. 1384 The Destination Down Message MUST contain a MAC Address Data Item 1385 (Section 10.7). 1387 It should be noted that both modem and router may send a Destination 1388 Down Message to their peer, regardless of which peer initially 1389 indicated the destination to be 'up'. 1391 9.16. Destination Down Response Message 1393 A Destination Down Response MUST be sent by the recipient of a 1394 Destination Down Message (Section 9.15) to confirm that the relevant 1395 data concerning the destination has been removed from the information 1396 base. 1398 To construct a Destination Down Response Message, the Message Type 1399 value in the Message Header is set to 12, from Table 2. 1401 The Destination Down Response Message MUST contain one of each of the 1402 following Data Items: 1404 o MAC Address (Section 10.7) 1406 o Status (Section 10.1) 1408 9.17. Destination Update Message 1410 A modem SHOULD send the Destination Update Message when it detects 1411 some change in the information base for a given destination (remote 1412 node or multicast group). Some examples of changes that would prompt 1413 a Destination Update Message are: 1415 o Change in link metrics (e.g., Data Rates) 1417 o Layer 3 addressing change 1419 To construct a Destination Update Message, the Message Type value in 1420 the Message Header is set to 13, from Table 2. 1422 The Destination Update Message MUST contain a MAC Address Data Item 1423 (Section 10.7). 1425 The Destination Update Message MAY contain one of each of the 1426 following Data Items: 1428 o Maximum Data Rate (Receive) (Section 10.12) 1430 o Maximum Data Rate (Transmit) (Section 10.13) 1432 o Current Data Rate (Receive) (Section 10.14) 1434 o Current Data Rate (Transmit) (Section 10.15) 1436 o Latency (Section 10.16) 1438 The Destination Update Message MAY contain one of each of the 1439 following Data Items, if the Data Item is in use by the session: 1441 o Resources (Section 10.17) 1443 o Relative Link Quality (Receive) (Section 10.18) 1445 o Relative Link Quality (Transmit) (Section 10.19) 1447 o Maximum Transmission Unit (MTU) (Section 10.20) 1449 The Destination Update Message MAY contain one or more of the 1450 following Data Items, with different values: 1452 o IPv4 Address (Section 10.8) 1454 o IPv6 Address (Section 10.9) 1456 o IPv4 Attached Subnet (Section 10.10) 1458 o IPv6 Attached Subnet (Section 10.11) 1460 It should be noted that this Message has no corresponding response. 1462 9.18. Link Characteristics Request Message 1464 The Link Characteristics Request Message MAY be sent by a router to 1465 request that the modem initiate changes for specific characteristics 1466 of the link. The request can reference either a real destination 1467 (e.g., a remote node), or a logical destination (e.g., a multicast 1468 group) within the network. 1470 To construct a Link Characteristics Request Message, the Message Type 1471 value in the Message Header is set to 14, from Table 2. 1473 The Link Characteristics Request Message MUST contain one of the 1474 following Data Items: 1476 o MAC Address (Section 10.7) 1478 The Link Characteristics Request Message MUST contain at least one of 1479 each of the following Data Items: 1481 o Current Data Rate (Receive) (Section 10.14) 1483 o Current Data Rate (Transmit) (Section 10.15) 1485 o Latency (Section 10.16) 1487 The Link Characteristics Request Message MAY contain either a Current 1488 Data Rate (CDRR or CDRT) Data Item to request a different datarate 1489 than what is currently allocated, a Latency Data Item to request that 1490 traffic delay on the link not exceed the specified value, or both. 1492 The router sending a Link Characteristics Request Message should be 1493 aware that a request may take an extended period of time to complete. 1495 9.19. Link Characteristics Response Message 1497 A modem MUST send a Link Characteristics Response Message when a Link 1498 Characteristics Request Message (Section 9.18) is received. 1500 To construct a Link Characteristics Response Message, the Message 1501 Type value in the Message Header is set to 15, from Table 2. 1503 The Link Characteristics Response Message MUST contain one of each of 1504 the following Data Items: 1506 o MAC Address (Section 10.7) 1508 o Status (Section 10.1) 1510 The Link Characteristics Response Message SHOULD contain one of each 1511 of the following Data Items: 1513 o Maximum Data Rate (Receive) (Section 10.12) 1515 o Maximum Data Rate (Transmit) (Section 10.13) 1517 o Current Data Rate (Receive) (Section 10.14) 1519 o Current Data Rate (Transmit) (Section 10.15) 1521 o Latency (Section 10.16) 1523 The Link Characteristics Response Message MAY contain one of each of 1524 the following Data Items, if the Data Item is in use by the session: 1526 o Resources (Section 10.17) 1528 o Relative Link Quality (Receive) (Section 10.18) 1530 o Relative Link Quality (Transmit) (Section 10.19) 1532 o Maximum Transmission Unit (MTU) (Section 10.20) 1534 The Link Characteristics Response Message MUST contain a complete set 1535 of metric Data Items, referencing all metrics declared in the Session 1536 Initialization Response Message (Section 9.6). The values in the 1537 metric Data Items in the Link Characteristics Response Message MUST 1538 reflect the link characteristics after the request has been 1539 processed. 1541 If an implementation is not able to alter the characteristics of the 1542 link in the manner requested, then the status code of the Status Data 1543 Item MUST be set to 101 'Request Denied', see Table 4. 1545 9.20. Heartbeat Message 1547 A Heartbeat Message MUST be sent by a DLEP participant every N 1548 milliseconds, where N is defined in the Heartbeat Interval Data Item 1549 (Section 10.5) of the Session Initialization Message (Section 9.5) or 1550 Session Initialization Response Message (Section 9.6). 1552 To construct a Heartbeat Message, the Message Type value in the 1553 Message Header is set to 16, from Table 2. 1555 There are no valid Data Items for the Heartbeat Message. 1557 The Message is used by DLEP peers to detect when a DLEP session peer 1558 (either the modem or the router) is no longer communicating. DLEP 1559 participants SHOULD allow two (2) heartbeat intervals to expire with 1560 no Messages from the DLEP peer before initiating DLEP session 1561 termination procedures. 1563 10. DLEP Data Items 1565 Following is the list of core Data Items that MUST be recognized by a 1566 DLEP compliant implementation. As mentioned before, not all Data 1567 Items need be used during a session, but an implementation MUST 1568 correctly process these Data Items when correctly associated with a 1569 Signal or Message. 1571 The core DLEP Data Items are: 1573 +--------------------+----------------------------------------------+ 1574 | Type Code | Description | 1575 +--------------------+----------------------------------------------+ 1576 | 0 | Reserved | 1577 | 1 | Status (Section 10.1) | 1578 | 2 | IPv4 Connection Point (Section 10.2) | 1579 | 3 | IPv6 Connection Point (Section 10.3) | 1580 | 4 | Peer Type (Section 10.4) | 1581 | 5 | Heartbeat Interval (Section 10.5) | 1582 | 6 | Extensions Supported (Section 10.6) | 1583 | 7 | MAC Address (Section 10.7) | 1584 | 8 | IPv4 Address (Section 10.8) | 1585 | 9 | IPv6 Address (Section 10.9) | 1586 | 10 | IPv4 Attached Subnet (Section 10.10) | 1587 | 11 | IPv6 Attached Subnet (Section 10.11) | 1588 | 12 | Maximum Data Rate (Receive) MDRR) (Section | 1589 | | 10.12) | 1590 | 13 | Maximum Data Rate (Transmit) (MDRT) (Section | 1591 | | 10.13) | 1592 | 14 | Current Data Rate (Receive) (CDRR) (Section | 1593 | | 10.14) | 1594 | 15 | Current Data Rate (Transmit) (CDRT) (Section | 1595 | | 10.15) | 1596 | 16 | Latency (Section 10.16) | 1597 | 17 | Resources (RES) (Section 10.17) | 1598 | 18 | Relative Link Quality (Receive) (RLQR) | 1599 | | (Section 10.18) | 1600 | 19 | Relative Link Quality (Transmit) (RLQT) | 1601 | | (Section 10.19) | 1602 | 20 | Maximum Transmission Unit (MTU) (Section | 1603 | | 10.20) | 1604 | 21-65407 | Reserved for future extensions | 1605 | 65408-65534 | Private Use. Available for experiments | 1606 | 65535 | Reserved | 1607 +--------------------+----------------------------------------------+ 1609 Table 3: DLEP Data Item types 1611 10.1. Status 1613 For the Session Termination Message (Section 9.9), the Status Data 1614 Item indicates a reason for the termination. For all response 1615 Messages, the Status Data Item is used to indicate the success or 1616 failure of the previously received Message. 1618 The Status Data Item includes an optional Text field that can be used 1619 to provide a textual description of the status. The use of the Text 1620 field is entirely up to the receiving implementation, i.e., it could 1621 be output to a log file or discarded. If no Text field is supplied 1622 with the Status Data Item, the Length field MUST be set to 1. 1624 The Status Data Item contains the following fields: 1626 0 1 2 3 1627 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 1628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1629 | Data Item Type | Length | 1630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1631 | Code | Text... : 1632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1634 Data Item Type: 1 1636 Length: 1 + Length of text, in octets 1637 Status Code: One of the codes defined in Table 4 below. 1639 Text: UTF-8 encoded string of UNICODE [UNIV8] characters, describing 1640 the cause, used for implementation defined purposes. Since this 1641 field is used for description, implementations SHOULD limit 1642 characters in this field to printable characters. Implementations 1643 receiving this Data Item SHOULD check for printable characters in 1644 the field. 1646 An implementation MUST NOT assume the Text field is NUL-terminated. 1648 +---------------+---------+-----------+-----------------------------+ 1649 | Status Code | Value | Failure | Reason | 1650 | | | Mode | | 1651 +---------------+---------+-----------+-----------------------------+ 1652 | Success | 0 | Success | The Message was processed | 1653 | | | | successfully. | 1654 | Unknown | 1 | Terminate | The Message was not | 1655 | Message | | | recognized by the | 1656 | | | | implementation. | 1657 | Unexpected | 2 | Terminate | The Message was not | 1658 | Message | | | expected while the device | 1659 | | | | was in the current state, | 1660 | | | | e.g., a Session | 1661 | | | | Initialization Message | 1662 | | | | (Section 9.5) in the In- | 1663 | | | | Session state. | 1664 | Invalid Data | 3 | Terminate | One or more Data Items in | 1665 | | | | the Message are invalid, | 1666 | | | | unexpected or incorrectly | 1667 | | | | duplicated. | 1668 | Invalid | 4 | Terminate | The destination included in | 1669 | Destination | | | the Message does not match | 1670 | | | | a previously announced | 1671 | | | | destination. For example, | 1672 | | | | in the Link Characteristic | 1673 | | | | Response Message (Section | 1674 | | | | 9.19). | 1675 | Timed Out | 5 | Terminate | The session has timed out. | 1676 | | 6-90 | Terminate | Reserved for future | 1677 | | | | extensions. | 1678 | | 91-99 | Terminate | Available for experiments. | 1679 | Not | 100 | Continue | The receiver is not | 1680 | Interested | | | interested in this Message | 1681 | | | | subject, e.g. in a | 1682 | | | | Destination Up Response | 1683 | | | | Message (Section 9.12) to | 1684 | | | | indicate no further | 1685 | | | | Messages about the | 1686 | | | | destination. | 1687 | Request | 101 | Continue | The receiver refuses to | 1688 | Denied | | | complete the request. | 1689 | | 102-243 | Continue | Reserved for future | 1690 | | | | extensions. | 1691 | | 244-254 | Continue | Available for experiments. | 1692 | | 255 | Terminate | Reserved. | 1693 +---------------+---------+-----------+-----------------------------+ 1695 Table 4: DLEP Status Codes 1697 10.2. IPv4 Connection Point 1699 The IPv4 Connection Point Data Item indicates the IPv4 address and, 1700 optionally, the TCP port number on the modem available for 1701 connections. If provided, the router MUST use this information to 1702 initiate the TCP connection to the modem. 1704 The IPv4 Connection Point Data Item contains the following fields: 1706 0 1 2 3 1707 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 1708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1709 | Data Item Type | Length | 1710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 | Flags | IPv4 Address... : 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 : ...cont. | TCP Port Number (optional) | 1714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1716 Data Item Type: 2 1718 Length: 5 (or 7 if TCP Port included) 1720 Flags: Flags field, defined below. 1722 IPv4 Address: The IPv4 address listening on the modem. 1724 TCP Port Number: TCP Port number on the modem. 1726 If the Length field is 7, the port number specified MUST be used to 1727 establish the TCP session. If the TCP Port Number is omitted, i.e. 1728 the Length field is 5, the router MUST use the DLEP well-known port 1729 number (Section 12.7) to establish the TCP connection. 1731 The Flags field is defined as: 1733 0 1 2 3 4 5 6 7 1734 +-+-+-+-+-+-+-+-+ 1735 | Reserved | 1736 +-+-+-+-+-+-+-+-+ 1738 Reserved: MUST be zero. Reserved for future use. 1740 10.3. IPv6 Connection Point 1742 The IPv6 Connection Point Data Item indicates the IPv6 address and, 1743 optionally, the TCP port number on the modem available for 1744 connections. If provided, the router MUST use this information to 1745 initiate the TCP connection to the modem. 1747 The IPv6 Connection Point Data Item contains the following fields: 1749 0 1 2 3 1750 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 1751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1752 | Data Item Type | Length | 1753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1754 | Flags | IPv6 Address : 1755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1756 : IPv6 Address : 1757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1758 : IPv6 Address : 1759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1760 : IPv6 Address : 1761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1762 : ...cont. | TCP Port Number (optional) | 1763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1765 Data Item Type: 3 1767 Length: 17 (or 19 if TCP Port included) 1769 Flags: Flags field, defined below. 1771 IPv6 Address: The IPv6 address listening on the modem. 1773 TCP Port Number: TCP Port number on the modem. 1775 If the Length field is 19, the port number specified MUST be used to 1776 establish the TCP session. If the TCP Port Number is omitted, i.e. 1777 the Length field is 17, the router MUST use the DLEP well-known port 1778 number (Section 12.7) to establish the TCP connection. 1780 The Flags field is defined as: 1782 0 1 2 3 4 5 6 7 1783 +-+-+-+-+-+-+-+-+ 1784 | Reserved | 1785 +-+-+-+-+-+-+-+-+ 1787 Reserved: MUST be zero. Reserved for future use. 1789 10.4. Peer Type 1791 The Peer Type Data Item is used by the router and modem to give 1792 additional information as to its type. The peer type is a string and 1793 is envisioned to be used for informational purposes (e.g., as output 1794 in a display command). 1796 The Peer Type Data Item contains the following fields: 1798 0 1 2 3 1799 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 1800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1801 | Data Item Type | Length | 1802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1803 | Peer Type... : 1804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 Data Item Type: 4 1808 Length: Length of peer type string, in octets. 1810 Peer Type: UTF-8 encoded string of UNICODE [UNIV8] characters. For 1811 example, a satellite modem might set this variable to "Satellite 1812 terminal". Since this Data Item is intended to provide additional 1813 information for display commands, sending implementations SHOULD 1814 limit the data to printable characters, and receiving 1815 implementations SHOULD check the data for printable characters. 1817 An implementation MUST NOT assume the Peer Type field is NUL- 1818 terminated. 1820 10.5. Heartbeat Interval 1822 The Heartbeat Interval Data Item is used to specify a period in 1823 milliseconds for Heartbeat Messages (Section 9.20). 1825 The Heartbeat Interval Data Item contains the following fields: 1827 0 1 2 3 1828 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 1829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1830 | Data Item Type | Length | 1831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1832 | Heartbeat Interval | 1833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1835 Data Item Type: 5 1837 Length: 4 1839 Heartbeat Interval: The interval in milliseconds, expressed as a 1840 32-bit unsigned integer, for Heartbeat Messages. 1841 This value MUST NOT be 0. 1843 10.6. Extensions Supported 1845 The Extensions Supported Data Item is used by the router and modem to 1846 negotiate additional optional functionality they are willing to 1847 support. The Extensions List is a concatenation of the types of each 1848 supported extension, found in the IANA DLEP Extensions repository. 1849 Each Extension Type definition includes which additional Signals and 1850 Data Items are supported. 1852 The Extensions Supported Data Item contains the following fields: 1854 0 1 2 3 1855 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 1856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1857 | Data Item Type | Length | 1858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1859 | Extensions List... 1860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1862 Data Item Type: 6 1864 Length: Length of the extensions list in octets. This is twice (2x) 1865 the number of extensions. 1867 Extension List: A list of extensions supported, identified by their 1868 2-octet value as listed in the extensions registry. 1870 10.7. MAC Address 1872 The MAC Address Data Item contains the address of the destination on 1873 the remote node. 1875 DLEP can support MAC addresses in either EUI-48 or EUI-64 format, 1876 with the restriction that all MAC addresses for a given DLEP session 1877 MUST be in the same format, and MUST be consistent with the MAC 1878 address format of the connected modem (e.g., if the modem is 1879 connected to the router with an EUI-48 MAC, all destination addresses 1880 via that modem MUST be expressed in EUI-48 format). 1882 Examples of a virtual destination would be a multicast MAC address, 1883 or the broadcast MAC (FF:FF:FF:FF:FF:FF). 1885 0 1 2 3 1886 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 1887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1888 | Data Item Type | Length | 1889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1890 | MAC Address : 1891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1892 : MAC Address : 1893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1894 : MAC Address : (if EUI-64 used) | 1895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1897 Data Item Type: 7 1899 Length: 6 for EUI-48 format, or 8 for EUI-64 format 1901 MAC Address: MAC Address of the destination. 1903 10.8. IPv4 Address 1905 When included in Destination Messages, this Data Item contains the 1906 IPv4 address of the destination. When included in the Session Update 1907 Message, this Data Item contains the IPv4 address of the peer. In 1908 either case, the Data Item also contains an indication of whether 1909 this is a new or existing address, or is a deletion of a previously 1910 known address. 1912 The IPv4 Address Data Item contains the following fields: 1914 0 1 2 3 1915 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 1916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1917 | Data Item Type | Length | 1918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1919 | Flags | IPv4 Address : 1920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1921 : ...cont. | 1922 +-+-+-+-+-+-+-+-+ 1924 Data Item Type: 8 1926 Length: 5 1928 Flags: Flags field, defined below. 1930 IPv4 Address: The IPv4 address of the destination or peer. 1932 The Flags field is defined as: 1934 0 1 2 3 4 5 6 7 1935 +-+-+-+-+-+-+-+-+ 1936 | Reserved |A| 1937 +-+-+-+-+-+-+-+-+ 1939 A: Add/Drop flag, indicating whether this is a new or existing 1940 address (1), or a withdrawal of an address (0). 1942 Reserved: MUST be zero. Reserved for future use. 1944 10.9. IPv6 Address 1946 When included in Destination Messages, this Data Item contains the 1947 IPv6 address of the destination. When included in the Session Update 1948 Message, this Data Item contains the IPv6 address of the peer. In 1949 either case, the Data Item also contains an indication of whether 1950 this is a new or existing address, or is a deletion of a previously 1951 known address. 1953 The IPv6 Address Data Item contains the following fields: 1955 0 1 2 3 1956 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 1957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1958 | Data Item Type | Length | 1959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1960 | Flags | IPv6 Address : 1961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1962 : IPv6 Address : 1963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1964 : IPv6 Address : 1965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1966 : IPv6 Address : 1967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1968 : IPv6 Address | 1969 +-+-+-+-+-+-+-+-+ 1971 Data Item Type: 9 1973 Length: 17 1975 Flags: Flags field, defined below. 1977 IPv6 Address: IPv6 Address of the destination or peer. 1979 The Flags field is defined as: 1981 0 1 2 3 4 5 6 7 1982 +-+-+-+-+-+-+-+-+ 1983 | Reserved |A| 1984 +-+-+-+-+-+-+-+-+ 1986 A: Add/Drop flag, indicating whether this is a new or existing 1987 address (1), or a withdrawal of an address (0). 1989 Reserved: MUST be zero. Reserved for future use. 1991 10.10. IPv4 Attached Subnet 1993 The DLEP IPv4 Attached Subnet allows a device to declare that it has 1994 an IPv4 subnet (e.g., a stub network) attached, that it has become 1995 aware of an IPv4 subnet being present at a remote destination, or 1996 that it has become aware of the loss of a subnet at the remote 1997 destination. 1999 The DLEP IPv4 Attached Subnet Data Item contains the following 2000 fields: 2002 0 1 2 3 2003 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 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2005 | Data Item Type | Length | 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2007 | Flags | IPv4 Attached Subnet : 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2009 : ...cont. |Prefix Length | 2010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2012 Data Item Type: 10 2013 Length: 6 2015 Flags: Flags field, defined below. 2017 IPv4 Subnet: The IPv4 subnet reachable at the destination. 2019 Prefix Length: Length of the prefix (1-32) for the IPv4 subnet. A 2020 prefix length outside the specified range MUST be considered as 2021 invalid. 2023 The Flags field is defined as: 2025 0 1 2 3 4 5 6 7 2026 +-+-+-+-+-+-+-+-+ 2027 | Reserved |A| 2028 +-+-+-+-+-+-+-+-+ 2030 A: Add/Drop flag, indicating whether this is a new or existing subnet 2031 address (1), or a withdrawal of a subnet address (0). 2033 Reserved: MUST be zero. Reserved for future use. 2035 10.11. IPv6 Attached Subnet 2037 The DLEP IPv6 Attached Subnet allows a device to declare that it has 2038 an IPv6 subnet (e.g., a stub network) attached, that it has become 2039 aware of an IPv6 subnet being present at a remote destination, or 2040 that it has become aware of the loss of a subnet at the remote 2041 destination. 2043 The DLEP IPv6 Attached Subnet Data Item contains the following 2044 fields: 2046 0 1 2 3 2047 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 2048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2049 | Data Item Type | Length | 2050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2051 | Flags | IPv6 Attached Subnet : 2052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2053 : IPv6 Attached Subnet : 2054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2055 : IPv6 Attached Subnet : 2056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2057 : IPv6 Attached Subnet : 2058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2059 : ...cont. | Prefix Len. | 2060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2061 Data Item Type: 11 2063 Length: 18 2065 Flags: Flags field, defined below. 2067 IPv6 Attached Subnet: The IPv6 subnet reachable at the destination. 2069 Prefix Length: Length of the prefix (1-128) for the IPv6 subnet. A 2070 prefix length outside the specified range MUST be considered as 2071 invalid. 2073 The Flags field is defined as: 2075 0 1 2 3 4 5 6 7 2076 +-+-+-+-+-+-+-+-+ 2077 | Reserved |A| 2078 +-+-+-+-+-+-+-+-+ 2080 A: Add/Drop flag, indicating whether this is a new or existing subnet 2081 address (1), or a withdrawal of a subnet address (0). 2083 Reserved: MUST be zero. Reserved for future use. 2085 10.12. Maximum Data Rate (Receive) 2087 The Maximum Data Rate (Receive) (MDRR) Data Item is used to indicate 2088 the maximum theoretical data rate, in bits per second, that can be 2089 achieved while receiving data on the link. 2091 The Maximum Data Rate (Receive) Data Item contains the following 2092 fields: 2094 0 1 2 3 2095 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2097 | Data Item Type | Length | 2098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2099 | MDRR (bps) : 2100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2101 : MDRR (bps) | 2102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2104 Data Item Type: 12 2106 Length: 8 2107 Maximum Data Rate (Receive): A 64-bit unsigned integer, representing 2108 the maximum theoretical data rate, in bits per second (bps), that 2109 can be achieved while receiving on the link. 2111 10.13. Maximum Data Rate (Transmit) 2113 The Maximum Data Rate (Transmit) (MDRT) Data Item is used to indicate 2114 the maximum theoretical data rate, in bits per second, that can be 2115 achieved while transmitting data on the link. 2117 The Maximum Data Rate (Transmit) Data Item contains the following 2118 fields: 2120 0 1 2 3 2121 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2123 | Data Item Type | Length | 2124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2125 | MDRT (bps) : 2126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2127 : MDRT (bps) | 2128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2130 Data Item Type: 13 2132 Length: 8 2134 Maximum Data Rate (Transmit): A 64-bit unsigned integer, 2135 representing the maximum theoretical data rate, in bits per second 2136 (bps), that can be achieved while transmitting on the link. 2138 10.14. Current Data Rate (Receive) 2140 The Current Data Rate (Receive) (CDRR) Data Item is used to indicate 2141 the rate at which the link is currently operating for receiving 2142 traffic. 2144 When used in the Link Characteristics Request Message (Section 9.18), 2145 Current Data Rate (Receive) represents the desired receive rate, in 2146 bits per second, on the link. 2148 The Current Data Rate (Receive) Data Item contains the following 2149 fields: 2151 0 1 2 3 2152 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 2153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2154 | Data Item Type | Length | 2155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2156 | CDRR (bps) : 2157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2158 : CDRR (bps) | 2159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2161 Data Item Type: 14 2163 Length: 8 2165 Current Data Rate (Receive): A 64-bit unsigned integer, representing 2166 the current data rate, in bits per second, that can currently be 2167 achieved while receiving traffic on the link. 2169 If there is no distinction between current and maximum receive data 2170 rates, current data rate receive MUST be set equal to the maximum 2171 data rate receive. 2173 10.15. Current Data Rate (Transmit) 2175 The Current Data Rate (Transmit) (CDRT) Data Item is used to indicate 2176 the rate at which the link is currently operating for transmitting 2177 traffic. 2179 When used in the Link Characteristics Request Message (Section 9.18), 2180 Current Data Rate (Transmit) represents the desired transmit rate, in 2181 bits per second, on the link. 2183 The Current Data Rate (Transmit) Data Item contains the following 2184 fields: 2186 0 1 2 3 2187 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2189 | Data Item Type | Length | 2190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2191 | CDRT (bps) : 2192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2193 : CDRT (bps) | 2194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2196 Data Item Type: 15 2198 Length: 8 2200 Current Data Rate (Transmit): A 64-bit unsigned integer, 2201 representing the current data rate, in bits per second, that can 2202 currently be achieved while transmitting traffic on the link. 2204 If there is no distinction between current and maximum transmit data 2205 rates, current data rate transmit MUST be set equal to the maximum 2206 data rate transmit. 2208 10.16. Latency 2210 The Latency Data Item is used to indicate the amount of latency, in 2211 microseconds, on the link. 2213 The Latency value is reported as transmission delay. The calculation 2214 of latency is implementation dependent. For example, the latency may 2215 be a running average calculated from the internal queuing. 2217 The Latency Data Item contains the following fields: 2219 0 1 2 3 2220 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 2221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2222 | Data Item Type | Length | 2223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2224 | Latency : 2225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2226 : Latency | 2227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2229 Data Item Type: 16 2231 Length: 8 2233 Latency: A 64-bit unsigned integer, representing the transmission 2234 delay, in microseconds, that a packet encounters as it is 2235 transmitted over the link. 2237 10.17. Resources 2239 The Resources (RES) Data Item is used to indicate the amount of 2240 finite resources available for data transmission and reception at the 2241 destination as a percentage, with 0 meaning 'no resources remaining', 2242 and 100 meaning 'a full supply', assuming that when Resources reaches 2243 0 data transmission and/or reception will cease. 2245 An example of such resources might be battery life, but could equally 2246 be magic beans. The list of resources that might be considered is 2247 beyond the scope of this document, and is left to implementations to 2248 decide. 2250 This Data Item is designed to be used as an indication of some 2251 capability of the modem and/or router at the destination. 2253 The Resources Data Item contains the following fields: 2255 0 1 2 3 2256 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 2257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2258 | Data Item Type | Length | 2259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2260 | RES | 2261 +-+-+-+-+-+-+-+-+ 2263 Data Item Type: 17 2265 Length: 1 2267 Resources: An 8-bit unsigned integer percentage, 0-100, representing 2268 the amount of resources available. Any value greater than 100 2269 MUST be considered as invalid. 2271 If a device cannot calculate Resources, this Data Item SHOULD NOT be 2272 issued. 2274 10.18. Relative Link Quality (Receive) 2276 The Relative Link Quality (Receive) (RLQR) Data Item is used to 2277 indicate the quality of the link to a destination for receiving 2278 traffic as a percentage, with 0 meaning 'worst quality', and 100 2279 meaning 'best quality'. 2281 Quality in this context is defined as an indication of the stability 2282 of a link for reception; a destination with high Relative Link 2283 Quality (Receive) is expected to have generally stable DLEP metrics, 2284 and the metrics of a destination with low Relative Link Quality 2285 (Receive) can be expected to rapidly fluctuate over a wide range. 2287 The Relative Link Quality (Receive) Data Item contains the following 2288 fields: 2290 0 1 2 3 2291 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 2292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2293 | Data Item Type | Length | 2294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2295 | RLQR | 2296 +-+-+-+-+-+-+-+-+ 2298 Data Item Type: 18 2300 Length: 1 2301 Relative Link Quality (Receive): A non-dimensional unsigned 8-bit 2302 integer, 0-100, representing relative quality of the link for 2303 receiving traffic. Any value greater than 100 MUST be considered 2304 as invalid. 2306 If a device cannot calculate the Relative Link Quality (Receive), 2307 this Data Item SHOULD NOT be issued. 2309 10.19. Relative Link Quality (Transmit) 2311 The Relative Link Quality (Transmit) (RLQT) Data Item is used to 2312 indicate the quality of the link to a destination for transmitting 2313 traffic as a percentage, with 0 meaning 'worst quality', and 100 2314 meaning 'best quality'. 2316 Quality in this context is defined as an indication of the stability 2317 of a link for transmission; a destination with high Relative Link 2318 Quality (Transmit) is expected to have generally stable DLEP metrics, 2319 and the metrics of a destination with low Relative Link Quality 2320 (Transmit) can be expected to rapidly fluctuate over a wide range. 2322 The Relative Link Quality (Transmit) Data Item contains the following 2323 fields: 2325 0 1 2 3 2326 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 2327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2328 | Data Item Type | Length | 2329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2330 | RLQT | 2331 +-+-+-+-+-+-+-+-+ 2333 Data Item Type: 19 2335 Length: 1 2337 Relative Link Quality (Transmit): A non-dimensional unsigned 8-bit 2338 integer, 0-100, representing relative quality of the link for 2339 transmitting traffic. Any value greater than 100 MUST be 2340 considered as invalid. 2342 If a device cannot calculate the Relative Link Quality (Transmit), 2343 this Data Item SHOULD NOT be issued. 2345 10.20. Maximum Transmission Unit (MTU) 2347 The Maximum Transmission Unit (MTU) Data Item is used to indicate the 2348 maximum size, in octets, of an IP packet that can be transmitted 2349 without fragmentation, including headers, but excluding any lower 2350 layer headers. 2352 The Maximum Transmission Unit Data Item contains the following 2353 fields: 2355 0 1 2 3 2356 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 2357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2358 | Data Item Type | Length | 2359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2360 | MTU | 2361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2363 Data Item Type: 20 2365 Length: 2 2367 Maximum Transmission Unit: The maximum size, in octets, of an IP 2368 packet that can be transmitted without fragmentation, including 2369 headers, but excluding any lower layer headers. 2371 If a device cannot calculate the Maximum Transmission Unit, this Data 2372 Item SHOULD NOT be issued. 2374 11. Security Considerations 2376 The potential security concerns when using DLEP are: 2378 1. An attacker might pretend to be a DLEP peer, either at DLEP 2379 session initialization, or by injection of DLEP Messages once a 2380 session has been established, and/or 2382 2. DLEP Data Items could be altered by an attacker, causing the 2383 receiving implementation to inappropriately alter its information 2384 base concerning network status. 2386 Since DLEP is restricted to operation over a single (possibly 2387 logical) hop at layer 2, implementations requiring authentication and 2388 /or encryption of traffic MUST take steps to secure the Layer 2 link. 2389 Examples of technologies that can be deployed to secure the Layer 2 2390 link include [IEEE-802.1AE] and [IEEE-802.1X]. 2392 To avoid potential denial of service attack, it is RECOMMENDED that 2393 implementations using the Peer Discovery mechanism maintain an 2394 information base of hosts that persistently fail Session 2395 Initialization having provided an acceptable Peer Discovery Signal, 2396 and ignore subsequent Peer Discovery Signals from such hosts. 2398 This specification does not address security of the data plane, as it 2399 (the data plane) is not affected, and standard security procedures 2400 can be employed. 2402 12. IANA Considerations 2404 This section specifies requests to IANA. 2406 12.1. Registrations 2408 This specification defines: 2410 o A new repository for DLEP Signals, with three (3) values currently 2411 assigned. 2413 o Reservation of a Private Use numbering space within the above 2414 repository for experimental DLEP Signals. 2416 o A new repository for DLEP Messages, with seventeen (17) values 2417 currently assigned. 2419 o Reservation of a Private Use numbering space within the above 2420 repository for experimental DLEP Messages. 2422 o A new repository for DLEP Data Items, with twenty one (21) values 2423 currently assigned. 2425 o Reservation of a Private Use numbering space within the Data Items 2426 repository for experimental Data Items. 2428 o A new repository for DLEP status codes, with eight (8) currently 2429 assigned. 2431 o Reservation of a Private Use numbering space within the status 2432 codes repository for experimental status codes. 2434 o A new repository for DLEP extensions, with one (1) value currently 2435 assigned. 2437 o Reservation of a Private Use numbering space within the extension 2438 repository for experimental extensions. 2440 o A request for allocation of a well-known port for DLEP TCP and UDP 2441 communication. 2443 o A request for allocation of a link-local multicast IPv4 address 2444 for DLEP discovery. 2446 o A request for allocation of a link-local multicast IPv6 address 2447 for DLEP discovery. 2449 12.2. Signal Type Registration 2451 A new repository must be created with the values of the DLEP Signals, 2452 entitled "Signal Type Values for the Dynamic Link Event Protocol 2453 (DLEP)". The repository is to be managed using the "Specification 2454 Required" policy documented in [RFC5226]. 2456 All Signal values are in the range [0..65535], defined in Table 1. 2458 12.3. Message Type Registration 2460 A new repository must be created with the values of the DLEP 2461 Messages, entitled "Message Type Values for the Dynamic Link Event 2462 Protocol (DLEP)". The repository is to be managed using the 2463 "Specification Required" policy documented in [RFC5226]. 2465 All Message values are in the range [0..65535], defined in Table 2. 2467 12.4. DLEP Data Item Registrations 2469 A new repository for DLEP Data Items must be created, entitled "Data 2470 Item Type Values for the Dynamic Link Event Protocol (DLEP)". The 2471 repository is to be managed using the "Specification Required" policy 2472 documented in [RFC5226]. 2474 All Data Item values are in the range [0..65535], defined in Table 3. 2476 12.5. DLEP Status Code Registrations 2478 A new repository for DLEP status codes must be created, entitled 2479 "Status Code Values for the Dynamic Link Event Protocol (DLEP)". The 2480 repository is to be managed using the "Specification Required" policy 2481 documented in [RFC5226]. 2483 All status codes are in the range [0..255] , defined in Table 4. 2485 With the exception of the reserved value 255, all status codes with 2486 values >= 100 are marked as 'Continue' codes, others 'Terminate'. 2488 12.6. DLEP Extensions Registrations 2490 A new repository for DLEP extensions must be created, entitled 2491 "Extension Type Values for the Dynamic Link Event Protocol (DLEP)". 2492 The repository is to be managed using the "Specification Required" 2493 policy documented in [RFC5226]. 2495 All extension values are in the range [0..65535]. Current 2496 allocations are: 2498 +--------------+----------------------------------------------+ 2499 | Code | Description | 2500 +--------------+----------------------------------------------+ 2501 | 0 | Reserved | 2502 | 1 | Credit Windowing | 2503 | 2-65519 | Unassigned. Available for future extensions | 2504 | 65520-65534 | Private Use. Available for experiments | 2505 | 65535 | Reserved | 2506 +--------------+----------------------------------------------+ 2508 Table 5: DLEP Extension types 2510 12.7. DLEP Well-known Port 2512 It is requested that IANA allocate a single well-known port number 2513 for both TCP and UDP, for DLEP communication. SCTP port allocation 2514 is not required. 2516 12.8. DLEP IPv4 Link-local Multicast Address 2518 It is requested that IANA allocate an IPv4 link-local multicast 2519 address for DLEP discovery Signals. 2521 12.9. DLEP IPv6 Link-local Multicast Address 2523 It is requested that IANA allocate an IPv6 link-local multicast 2524 address for DLEP discovery Signals. 2526 13. Acknowledgements 2528 We would like to acknowledge and thank the members of the DLEP design 2529 team, who have provided invaluable insight. The members of the 2530 design team are: Teco Boot, Bow-Nan Cheng, John Dowdell, and Henning 2531 Rogge. 2533 We would also like to acknowledge the influence and contributions of 2534 Greg Harrison, Chris Olsen, Martin Duke, Subir Das, Jaewon Kang, 2535 Vikram Kaul, Nelson Powell, Lou Berger, and Victoria Mercieca. 2537 14. References 2539 14.1. Normative References 2541 [CREDIT] Ratliff, S., "Credit Windowing extension for DLEP", IETF 2542 draft draft-ietf-manet-credit-window-02, March 2016. 2544 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2545 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 2546 RFC2119, March 1997, 2547 . 2549 [UNIV8] , "The Unicode Consortium. The Unicode Standard, Version 2550 8.0.0, (Mountain View, CA: The Unicode Consortium, 2015. 2551 ISBN 978-1-936213-10-8)", 2552 http://www.unicode.org/versions/Unicode8.0.0/, June 2015. 2554 14.2. Informative References 2556 [IEEE-802.1AE] 2557 , "IEEE Standards for Local and Metropolitan Area 2558 Networks: Media Access Control (MAC) Security", DOI 2559 10.1109/IEEESTD.2006.245590, August 2006. 2561 [IEEE-802.1X] 2562 , "IEEE Standards for Local and Metropolitan Area 2563 Networks: Port based Network Access Control", DOI 10.1109/ 2564 IEEESTD.2010.5409813, February 2010. 2566 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2567 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2568 DOI 10.17487/RFC5226, May 2008, 2569 . 2571 [RFC5578] Berry, B., Ed., Ratliff, S., Paradise, E., Kaiser, T., and 2572 M. Adams, "PPP over Ethernet (PPPoE) Extensions for Credit 2573 Flow and Link Metrics", RFC 5578, DOI 10.17487/RFC5578, 2574 February 2010, . 2576 Appendix A. Discovery Signal Flows 2578 Router Modem Signal Description 2579 ======================================================================== 2581 | Router initiates discovery, starts 2582 | a timer, send Peer Discovery 2583 |-------Peer Discovery---->|| Signal. 2585 ~ ~ ~ ~ ~ ~ ~ Router discovery timer expires 2586 without receiving Peer Offer. 2588 | Router sends another Peer 2589 |-------Peer Discovery---------->| Discovery Signal. 2590 | 2591 | Modem receives Peer Discovery 2592 | Signal. 2593 | 2594 | Modem sends Peer Offer with 2595 |<--------Peer Offer-------------| Connection Point information. 2596 : 2597 : Router MAY cancel discovery timer 2598 : and stop sending Peer Discovery 2599 : Signals. 2601 Appendix B. Peer Level Message Flows 2603 B.1. Session Initialization 2605 Router Modem Message Description 2606 ======================================================================== 2608 | Router connects to discovered or 2609 | pre-configured Modem Connection 2610 |---------TCP connect----------> Point. 2611 | 2612 | Router sends Session 2613 |----Session Initialization----->| Initialization Message. 2614 | 2615 | Modem receives Session 2616 | Initialization Message. 2617 | 2618 | Modem sends Session Initialization 2619 |<--Session Initialization Resp.-| Response, with Success Status Data 2620 | | Item. 2621 | | 2622 |<<============================>>| Session established. Heartbeats 2623 : : begin. 2625 B.2. Session Initialization - Refused 2627 Router Modem Message Description 2628 ======================================================================== 2630 | Router connects to discovered or 2631 | pre-configured Modem Connection 2632 |---------TCP connect----------> Point. 2633 | 2634 | Router sends Session 2635 |-----Session Initialization---->| Initialization Message. 2636 | 2637 | Modem receives Session 2638 | Initialization Message, and will 2639 | not support the advertised 2640 | extensions. 2641 | 2642 | Modem sends Session Initialization 2643 | Response, with 'Request Denied' 2644 |<-Session Initialization Resp.--| Status Data Item. 2645 | 2646 | 2647 | Router receives negative Session 2648 | Initialization Response, closes 2649 ||---------TCP close------------|| TCP connection. 2651 B.3. Router Changes IP Addresses 2653 Router Modem Message Description 2654 ======================================================================== 2656 | Router sends Session Update 2657 |-------Session Update---------->| Message to announce change of IP 2658 | address 2659 | 2660 | Modem receives Session Update 2661 | Message and updates internal 2662 | state. 2663 | 2664 |<----Session Update Response----| Modem sends Session Update 2665 | Response. 2667 B.4. Modem Changes Session-wide Metrics 2669 Router Modem Message Description 2670 ======================================================================== 2672 | Modem sends Session Update Message 2673 | to announce change of modem-wide 2674 |<--------Session Update---------| metrics 2675 | 2676 | Router receives Session Update 2677 | Message and updates internal 2678 | state. 2679 | 2680 |----Session Update Response---->| Router sends Session Update 2681 | Response. 2683 B.5. Router Terminates Session 2685 Router Modem Message Description 2686 ======================================================================== 2688 | Router sends Session Termination 2689 |------Session Termination------>| Message with Status Data Item. 2690 | | 2691 |-------TCP shutdown (send)---> | Router stops sending Messages. 2692 | 2693 | Modem receives Session 2694 | Termination, stops counting 2695 | received heartbeats and stops 2696 | sending heartbeats. 2697 | 2698 | Modem sends Session Termination 2699 |<---Session Termination Resp.---| Response with Status 'Success'. 2700 | 2701 | Modem stops sending Messages. 2702 | 2703 ||---------TCP close------------|| Session terminated. 2705 B.6. Modem Terminates Session 2707 Router Modem Message Description 2708 ======================================================================== 2710 | Modem sends Session Termination 2711 |<----Session Termination--------| Message with Status Data Item. 2712 | 2713 | Modem stops sending Messages. 2714 | 2715 | Router receives Session 2716 | Termination, stops counting 2717 | received heartbeats and stops 2718 | sending heartbeats. 2719 | 2720 | Router sends Session Termination 2721 |---Session Termination Resp.--->| Response with Status 'Success'. 2722 | 2723 | Router stops sending Messages. 2724 | 2725 ||---------TCP close------------|| Session terminated. 2727 B.7. Session Heartbeats 2729 Router Modem Message Description 2730 ======================================================================== 2731 |----------Heartbeat------------>| Router sends heartbeat Message 2732 | 2733 | Modem resets heartbeats missed 2734 | counter. 2736 ~ ~ ~ ~ ~ ~ ~ 2738 |---------[Any Message]--------->| When the Modem receives any 2739 | Message from the Router. 2740 | 2741 | Modem resets heartbeats missed 2742 | counter. 2744 ~ ~ ~ ~ ~ ~ ~ 2746 |<---------Heartbeat-------------| Modem sends heartbeat Message 2747 | 2748 | Router resets heartbeats missed 2749 | counter. 2751 ~ ~ ~ ~ ~ ~ ~ 2753 |<--------[Any Message]----------| When the Router receives any 2754 | Message from the Modem. 2755 | 2756 | Modem resets heartbeats missed 2757 | counter. 2759 B.8. Router Detects a Heartbeat timeout 2761 Router Modem Message Description 2762 ======================================================================== 2764 ||<----------------------| Router misses a heartbeat 2766 | ||<----------------------| Router misses too many heartbeats 2767 | 2768 | 2769 |------Session Termination------>| Router sends Session Termination 2770 | Message with 'Timeout' Status 2771 | Data Item. 2772 : 2773 : Termination proceeds as above. 2775 B.9. Modem Detects a Heartbeat timeout 2776 Router Modem Message Description 2777 ======================================================================== 2779 |---------------------->|| Modem misses a heartbeat 2781 |---------------------->|| | Modem misses too many heartbeats 2782 | 2783 | 2784 |<-----Session Termination-------| Modem sends Session Termination 2785 | Message with 'Timeout' Status 2786 | Data Item. 2787 : 2788 : Termination proceeds as above. 2790 Appendix C. Destination Specific Message Flows 2792 C.1. Common Destination Notification 2794 Router Modem Message Description 2795 ======================================================================== 2797 | Modem detects a new logical 2798 | destination is reachable, and 2799 |<-------Destination Up----------| sends Destination Up Message. 2800 | 2801 |------Destination Up Resp.----->| Router sends Destination Up 2802 | Response. 2804 ~ ~ ~ ~ ~ ~ ~ 2805 | Modem detects change in logical 2806 | destination metrics, and sends 2807 |<-------Destination Update------| Destination Update Message. 2809 ~ ~ ~ ~ ~ ~ ~ 2810 | Modem detects change in logical 2811 | destination metrics, and sends 2812 |<-------Destination Update------| Destination Update Message. 2814 ~ ~ ~ ~ ~ ~ ~ 2815 | Modem detects logical destination 2816 | is no longer reachable, and sends 2817 |<-------Destination Down--------| Destination Down Message. 2818 | 2819 | Router receives Destination Down, 2820 | updates internal state, and sends 2821 |------Destination Down Resp.--->| Destination Down Response Message. 2823 C.2. Multicast Destination Notification 2825 Router Modem Message Description 2826 ======================================================================== 2828 | Router detects a new multicast 2829 | destination is in use, and sends 2830 |-----Destination Announce------>| Destination Announce Message. 2831 | 2832 | Modem updates internal state to 2833 | monitor multicast destination, and 2834 |<-----Dest. Announce Resp.------| sends Destination Announce 2835 Response. 2837 ~ ~ ~ ~ ~ ~ ~ 2838 | Modem detects change in multicast 2839 | destination metrics, and sends 2840 |<-------Destination Update------| Destination Update Message. 2842 ~ ~ ~ ~ ~ ~ ~ 2843 | Modem detects change in multicast 2844 | destination metrics, and sends 2845 |<-------Destination Update------| Destination Update Message. 2847 ~ ~ ~ ~ ~ ~ ~ 2848 | Router detects multicast 2849 | destination is no longer in use, 2850 |--------Destination Down------->| and sends Destination Down 2851 | Message. 2852 | 2853 | Modem receives Destination Down, 2854 | updates internal state, and sends 2855 |<-----Destination Down Resp.----| Destination Down Response Message. 2857 C.3. Link Characteristics Request 2859 Router Modem Message Description 2860 ======================================================================== 2862 Destination has already been 2863 ~ ~ ~ ~ ~ ~ ~ announced by either peer. 2865 | Router requires different 2866 | Characteristics for the 2867 | destination, and sends Link 2868 |--Link Characteristics Request->| Characteristics Request Message. 2869 | 2870 | Modem attempts to adjust link 2871 | properties to meet the received 2872 | request, and sends a Link 2873 | Characteristics Response 2874 |<---Link Characteristics Resp.--| Message with the new values. 2876 Authors' Addresses 2878 Stan Ratliff 2879 VT iDirect 2880 13861 Sunrise Valley Drive, Suite 300 2881 Herndon, VA 20171 2882 USA 2884 Email: sratliff@idirect.net 2886 Bo Berry 2888 Shawn Jury 2889 Cisco Systems 2890 170 West Tasman Drive 2891 San Jose, CA 95134 2892 USA 2894 Email: sjury@cisco.com 2896 Darryl Satterwhite 2897 Broadcom 2899 Email: dsatterw@broadcom.com 2901 Rick Taylor 2902 Airbus Defence & Space 2903 Quadrant House 2904 Celtic Springs 2905 Coedkernew 2906 Newport NP10 8FZ 2907 UK 2909 Email: rick.taylor@airbus.com