idnits 2.17.1 draft-ietf-manet-dlep-26.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 285 has weird spacing: '... Shared o ...' == Line 286 has weird spacing: '... Medium o ...' -- The document date (December 9, 2016) is 2694 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 2986, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-07) exists of draft-ietf-manet-credit-window-04 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networks Working Group S. Ratliff 3 Internet-Draft VT iDirect 4 Intended status: Standards Track S. Jury 5 Expires: June 12, 2017 Cisco Systems 6 D. Satterwhite 7 Broadcom 8 R. Taylor 9 Airbus Defence & Space 10 B. Berry 11 December 9, 2016 13 Dynamic Link Exchange Protocol (DLEP) 14 draft-ietf-manet-dlep-26 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 June 12, 2017. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 64 2.1. Destinations . . . . . . . . . . . . . . . . . . . . . . 8 65 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 9 67 4. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 5. DLEP Session Flow . . . . . . . . . . . . . . . . . . . . . . 11 69 5.1. Peer Discovery State . . . . . . . . . . . . . . . . . . 11 70 5.2. Session Initialization State . . . . . . . . . . . . . . 12 71 5.3. In-Session State . . . . . . . . . . . . . . . . . . . . 13 72 5.3.1. Heartbeats . . . . . . . . . . . . . . . . . . . . . 13 73 5.4. Session Termination State . . . . . . . . . . . . . . . . 14 74 5.5. Session Reset state . . . . . . . . . . . . . . . . . . . 14 75 5.5.1. Unexpected TCP connection termination . . . . . . . . 14 76 6. Transaction Model . . . . . . . . . . . . . . . . . . . . . . 15 77 7. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 7.1. Experiments . . . . . . . . . . . . . . . . . . . . . . . 16 79 8. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 9. DLEP Signal and Message Structure . . . . . . . . . . . . . . 17 81 9.1. DLEP Signal Header . . . . . . . . . . . . . . . . . . . 17 82 9.2. DLEP Message Header . . . . . . . . . . . . . . . . . . . 18 83 9.3. DLEP Generic Data Item . . . . . . . . . . . . . . . . . 18 84 10. DLEP Signals and Messages . . . . . . . . . . . . . . . . . . 19 85 10.1. General Processing Rules . . . . . . . . . . . . . . . . 19 86 10.2. Status code processing . . . . . . . . . . . . . . . . . 20 87 10.3. Peer Discovery Signal . . . . . . . . . . . . . . . . . 20 88 10.4. Peer Offer Signal . . . . . . . . . . . . . . . . . . . 21 89 10.5. Session Initialization Message . . . . . . . . . . . . . 21 90 10.6. Session Initialization Response Message . . . . . . . . 22 91 10.7. Session Update Message . . . . . . . . . . . . . . . . . 24 92 10.8. Session Update Response Message . . . . . . . . . . . . 25 93 10.9. Session Termination Message . . . . . . . . . . . . . . 26 94 10.10. Session Termination Response Message . . . . . . . . . . 26 95 10.11. Destination Up Message . . . . . . . . . . . . . . . . . 26 96 10.12. Destination Up Response Message . . . . . . . . . . . . 28 97 10.13. Destination Announce Message . . . . . . . . . . . . . . 28 98 10.14. Destination Announce Response Message . . . . . . . . . 29 99 10.15. Destination Down Message . . . . . . . . . . . . . . . . 30 100 10.16. Destination Down Response Message . . . . . . . . . . . 31 101 10.17. Destination Update Message . . . . . . . . . . . . . . . 31 102 10.18. Link Characteristics Request Message . . . . . . . . . . 32 103 10.19. Link Characteristics Response Message . . . . . . . . . 33 104 10.20. Heartbeat Message . . . . . . . . . . . . . . . . . . . 34 105 11. DLEP Data Items . . . . . . . . . . . . . . . . . . . . . . . 35 106 11.1. Status . . . . . . . . . . . . . . . . . . . . . . . . . 35 107 11.2. IPv4 Connection Point . . . . . . . . . . . . . . . . . 38 108 11.3. IPv6 Connection Point . . . . . . . . . . . . . . . . . 39 109 11.4. Peer Type . . . . . . . . . . . . . . . . . . . . . . . 40 110 11.5. Heartbeat Interval . . . . . . . . . . . . . . . . . . . 41 111 11.6. Extensions Supported . . . . . . . . . . . . . . . . . . 41 112 11.7. MAC Address . . . . . . . . . . . . . . . . . . . . . . 42 113 11.8. IPv4 Address . . . . . . . . . . . . . . . . . . . . . . 42 114 11.8.1. IPv4 Address Processing . . . . . . . . . . . . . . 43 115 11.9. IPv6 Address . . . . . . . . . . . . . . . . . . . . . . 44 116 11.9.1. IPv6 Address Processing . . . . . . . . . . . . . . 45 117 11.10. IPv4 Attached Subnet . . . . . . . . . . . . . . . . . . 46 118 11.10.1. IPv4 Attached Subnet Processing . . . . . . . . . . 47 119 11.11. IPv6 Attached Subnet . . . . . . . . . . . . . . . . . . 48 120 11.11.1. IPv6 Attached Subnet Processing . . . . . . . . . . 49 121 11.12. Maximum Data Rate (Receive) . . . . . . . . . . . . . . 50 122 11.13. Maximum Data Rate (Transmit) . . . . . . . . . . . . . . 51 123 11.14. Current Data Rate (Receive) . . . . . . . . . . . . . . 52 124 11.15. Current Data Rate (Transmit) . . . . . . . . . . . . . . 52 125 11.16. Latency . . . . . . . . . . . . . . . . . . . . . . . . 53 126 11.17. Resources . . . . . . . . . . . . . . . . . . . . . . . 54 127 11.18. Relative Link Quality (Receive) . . . . . . . . . . . . 55 128 11.19. Relative Link Quality (Transmit) . . . . . . . . . . . . 55 129 11.20. Maximum Transmission Unit (MTU) . . . . . . . . . . . . 56 130 12. Security Considerations . . . . . . . . . . . . . . . . . . . 57 131 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 58 132 13.1. Registrations . . . . . . . . . . . . . . . . . . . . . 58 133 13.2. Signal Type Registration . . . . . . . . . . . . . . . . 58 134 13.3. Message Type Registration . . . . . . . . . . . . . . . 58 135 13.4. DLEP Data Item Registrations . . . . . . . . . . . . . . 59 136 13.5. DLEP Status Code Registrations . . . . . . . . . . . . . 60 137 13.6. DLEP Extensions Registrations . . . . . . . . . . . . . 61 138 13.7. DLEP IPv4 Connection Point Flags . . . . . . . . . . . . 61 139 13.8. DLEP IPv6 Connection Point Flags . . . . . . . . . . . . 62 140 13.9. DLEP IPv4 Address Flag . . . . . . . . . . . . . . . . . 62 141 13.10. DLEP IPv6 Address Flag . . . . . . . . . . . . . . . . . 62 142 13.11. DLEP IPv4 Attached Subnet Flag . . . . . . . . . . . . . 63 143 13.12. DLEP IPv6 Attached Subnet Flag . . . . . . . . . . . . . 63 144 13.13. DLEP Well-known Port . . . . . . . . . . . . . . . . . . 63 145 13.14. DLEP IPv4 Link-local Multicast Address . . . . . . . . . 64 146 13.15. DLEP IPv6 Link-local Multicast Address . . . . . . . . . 64 147 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 64 148 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 64 149 15.1. Normative References . . . . . . . . . . . . . . . . . . 64 150 15.2. Informative References . . . . . . . . . . . . . . . . . 65 151 Appendix A. Discovery Signal Flows . . . . . . . . . . . . . . . 65 152 Appendix B. Peer Level Message Flows . . . . . . . . . . . . . . 66 153 B.1. Session Initialization . . . . . . . . . . . . . . . . . 66 154 B.2. Session Initialization - Refused . . . . . . . . . . . . 67 155 B.3. Router Changes IP Addresses . . . . . . . . . . . . . . . 67 156 B.4. Modem Changes Session-wide Metrics . . . . . . . . . . . 67 157 B.5. Router Terminates Session . . . . . . . . . . . . . . . . 68 158 B.6. Modem Terminates Session . . . . . . . . . . . . . . . . 68 159 B.7. Session Heartbeats . . . . . . . . . . . . . . . . . . . 69 160 B.8. Router Detects a Heartbeat timeout . . . . . . . . . . . 70 161 B.9. Modem Detects a Heartbeat timeout . . . . . . . . . . . . 71 162 Appendix C. Destination Specific Message Flows . . . . . . . . . 71 163 C.1. Common Destination Notification . . . . . . . . . . . . . 71 164 C.2. Multicast Destination Notification . . . . . . . . . . . 72 165 C.3. Link Characteristics Request . . . . . . . . . . . . . . 73 166 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 74 168 1. Introduction 170 There exist today a collection of modem devices that control links of 171 variable datarate and quality. Examples of these types of links 172 include line-of-sight (LOS) terrestrial radios, satellite terminals, 173 and broadband modems. Fluctuations in speed and quality of these 174 links can occur due to configuration, or on a moment-to-moment basis, 175 due to physical phenomena like multipath interference, obstructions, 176 rain fade, etc. It is also quite possible that link quality and 177 datarate vary with respect to individual destinations on a link, and 178 with the type of traffic being sent. As an example, consider the 179 case of an IEEE 802.11 access point, serving two associated laptop 180 computers. In this environment, the answer to the question "What is 181 the datarate on the 802.11 link?" is "It depends on which associated 182 laptop we're talking about, and on what kind of traffic is being 183 sent." While the first laptop, being physically close to the access 184 point, may have a datarate of 54Mbps for unicast traffic, the other 185 laptop, being relatively far away, or obstructed by some object, can 186 simultaneously have a datarate of only 32Mbps for unicast. However, 187 for multicast traffic sent from the access point, all traffic is sent 188 at the base transmission rate (which is configurable, but depending 189 on the model of the access point, is usually 24Mbps or less). 191 In addition to utilizing variable datarate links, mobile networks are 192 challenged by the notion that link connectivity will come and go over 193 time, without an effect on a router's interface state (Up or Down). 194 Effectively utilizing a relatively short-lived connection is 195 problematic in IP routed networks, as IP routing protocols tend to 196 rely on interface state and independent timers to maintain network 197 convergence (e.g., HELLO messages and/or recognition of DEAD routing 198 adjacencies). These dynamic connections can be better utilized with 199 an event-driven paradigm, where acquisition of a new neighbor (or 200 loss of an existing one) is signaled, as opposed to a paradigm driven 201 by timers and/or interface state. DLEP not only implements such an 202 event-driven paradigm, but does so over a local (1 hop) TCP session, 203 which guarantees delivery of the event messages. 205 Another complicating factor for mobile networks are the different 206 methods of physically connecting the modem devices to the router. 207 Modems can be deployed as an interface card in a router's chassis, or 208 as a standalone device connected to the router via Ethernet or serial 209 link. In the case of Ethernet attachment, with existing protocols 210 and techniques, routing software cannot be aware of convergence 211 events occurring on the radio link (e.g., acquisition or loss of a 212 potential routing neighbor), nor can the router be aware of the 213 actual capacity of the link. This lack of awareness, along with the 214 variability in datarate, leads to a situation where finding the 215 (current) best route through the network to a given node is difficult 216 to establish and properly maintain. This is especially true of 217 demand-based access schemes such as Demand Assigned Multiple Access 218 (DAMA) implementations used on some satellite systems. With a DAMA- 219 based system, additional datarate may be available, but will not be 220 used unless the network devices emit traffic at a rate higher than 221 the currently established rate. Increasing the traffic rate does not 222 guarantee additional datarate will be allocated; rather, it may 223 result in data loss and additional retransmissions on the link. 225 Addressing the challenges listed above, the Dynamic Link Exchange 226 Protocol, or DLEP, has been developed. The DLEP protocol runs 227 between a router and its attached modem devices, allowing the modem 228 to communicate link characteristics as they change, and convergence 229 events (acquisition and loss of potential routing next-hops). The 230 following diagrams are used to illustrate the scope of DLEP packets. 232 |-------Local Node-------| |-------Remote Node------| 233 | | | | 234 +--------+ +-------+ +-------+ +--------+ 235 | Router |=======| Modem |{~~~~~~~~}| Modem |=======| Router | 236 | | | Device| | Device| | | 237 +--------+ +-------+ +-------+ +--------+ 238 | | | Link | | | 239 |-DLEP--| | Protocol | |-DLEP--| 240 | | | (e.g. | | | 241 | | | 802.11) | | | 243 Figure 1: DLEP Network 245 In Figure 1, when the local modem detects the presence of a remote 246 node, it (the local modem) sends a message to its router via the DLEP 247 protocol. The message consists of an indication of what change has 248 occurred on the link (e.g., presence of a remote node detected), 249 along with a collection of DLEP-defined data items that further 250 describe the change. Upon receipt of the message, the local router 251 may take whatever action it deems appropriate, such as initiating 252 discovery protocols, and/or issuing HELLO messages to converge the 253 network. On a continuing, as-needed basis, the modem devices use 254 DLEP to report any characteristics of the link (datarate, latency, 255 etc.) that have changed. DLEP is independent of the link type and 256 topology supported by the modem. Note that the DLEP protocol is 257 specified to run only on the local link between router and modem. 258 Some over the air signaling may be necessary between the local and 259 remote modem in order to provide some parameters in DLEP messages 260 between the local modem and local router, but DLEP does not specify 261 how such over the air signaling is carried out. Over the air 262 signaling is purely a matter for the modem implementer. 264 Figure 2 shows how DLEP can support a configuration where routers are 265 connected with different link types. In this example, Modem A 266 implements a point-to-point link, and Modem B is connected via a 267 shared medium. In both cases, the DLEP protocol is used to report 268 the characteristics of the link (datarate, latency, etc.) to routers. 269 The modem is also able to use the DLEP session to notify the router 270 when the remote node is lost, shortening the time required to re- 271 converge the network. 273 +--------+ +--------+ 274 +----+ Modem | | Modem +---+ 275 | | Device | | Device | 276 | | Type A | <===== // ======> | Type A | | 277 | +--------+ P-2-P Link +--------+ | 278 +---+----+ +---+----+ 279 | Router | | Router | 280 | | | | 281 +---+----+ +---+----+ 282 | +--------+ +--------+ | 283 +-----+ Modem | | Modem | | 284 | Device | o o o o o o o o | Device +--+ 285 | Type B | o Shared o | Type B | 286 +--------+ o Medium o +--------+ 287 o o 288 o o 289 o o 290 o 291 +--------+ 292 | Modem | 293 | Device | 294 | Type B | 295 +---+----+ 296 | 297 | 298 +---+----+ 299 | Router | 300 | | 301 +--------+ 303 Figure 2: DLEP Network with Multiple Modem Devices 305 2. Protocol Overview 307 DLEP defines a set of Messages used by modems and their attached 308 routers to communicate events that occur on the physical link(s) 309 managed by the modem: for example, a remote node entering or leaving 310 the network, or that the link has changed. Associated with these 311 Messages are a set of Data Items - information that describes the 312 remote node (e.g., address information), and/or the characteristics 313 of the link to the remote node. Throughout this document, we refer 314 to a modems/routers participating in a DLEP session as 'DLEP 315 Participants', unless a specific distinction (e.g. modem or router) 316 is required. 318 DLEP uses a session-oriented paradigm between the modem device and 319 its associated router. If multiple modem devices are attached to a 320 router (as in Figure 2), or the modem supports multiple connections 321 (via multiple logical or physical interfaces), then separate DLEP 322 sessions exist for each modem or connection. A router and modem form 323 a session by completing the discovery and initialization process. 324 This router-modem session persists unless or until it either (1) 325 times out, based on the absence of DLEP traffic (including 326 heartbeats), or (2) is explicitly torn down by one of the DLEP 327 participants. 329 2.1. Destinations 331 The router/modem session provides a carrier for information exchange 332 concerning 'destinations' that are available via the modem device. 333 Destinations can be identified by either the router or the modem, and 334 represent a specific, addressable location that can be reached via 335 the link(s) managed by the modem. 337 The DLEP Messages concerning destinations thus become the way for 338 routers and modems to maintain, and notify each other about, an 339 information base representing the physical and logical destinations 340 accessible via the modem device, as well as the link characteristics 341 to those destinations. 343 A destination can be either physical or logical. The example of a 344 physical destination would be that of a remote, far-end router 345 attached via the variable-quality network. It should be noted that 346 for physical destinations the MAC address is the address of the far- 347 end router, not the modem. 349 The example of a logical destination is Multicast. Multicast traffic 350 destined for the variable-quality network (the network accessed via 351 the modem) is handled in IP networks by deriving a Layer 2 MAC 352 address based on the Layer 3 address. Leveraging on this scheme, 353 multicast traffic is supported in DLEP simply by treating the derived 354 MAC address as any other destination in the network. 356 To support these logical destinations, one of the DLEP participants 357 (typically, the router) informs the other as to the existence of the 358 logical destination. The modem, once it is aware of the existence of 359 this logical destination, reports link characteristics just as it 360 would for any other destination in the network. The specific 361 algorithms a modem would use to derive metrics on logical 362 destinations are outside the scope of this specification, and is left 363 to specific implementations to decide. 365 In all cases, when this specification uses the term destination, it 366 refers to the addressable locations, either logical or physical, that 367 are accessible by the radio link(s). 369 3. Extensions 371 While this document represents the best efforts of the working group 372 to be functionally complete, it is recognized that extensions to DLEP 373 will in all likelihood be necessary as more link types are used. 374 Such extensions are defined as additional Messages, Data Items and/or 375 status codes, and associated rules of behavior, that are not defined 376 in this document. DLEP contains a standard mechanism for router and 377 modem implementations to negotiate the available extensions to use on 378 a per-session basis. 380 3.1. Requirements 382 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 383 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 384 "OPTIONAL" in this document are to be interpreted as described in BCP 385 14, RFC 2119 [RFC2119]. 387 DLEP MUST be implemented on a single Layer 2 domain. The protocol 388 identifies next-hop destinations by using the MAC address for 389 delivering data traffic. No manipulation or substitution is 390 performed; the MAC address supplied in all DLEP Messages is used as 391 the Destination MAC address for frames emitted by the participating 392 router. MAC addresses MUST be unique within the context of router- 393 modem session. 395 To enforce the single Layer 2 domain, implementations MUST support 396 The Generalized TTL Security Mechanism [RFC5082], and implementations 397 MUST adher to this specification for all DLEP Messages. 399 DLEP specifies UDP multicast for single-hop discovery signaling, and 400 TCP for transport of the Messages. Modems and routers participating 401 in DLEP sessions MUST have topologically consistent IP addresses 402 assigned. It is RECOMMENDED that DLEP implementations utilize IPv6 403 link-local addresses to reduce the administrative burden of address 404 assignment. If the router and modem support both IPv4 and IPv6, the 405 IPv6 transport SHOULD be used for the DLEP session. 407 DLEP relies on the guaranteed delivery of its Messages between router 408 and modem, once the 1 hop discovery process is complete, hence, the 409 specification of TCP to carry the Messages. Other reliable 410 transports for the protocol are possible, but are outside the scope 411 of this document. 413 DLEP further requires that security of the implementations (e.g., 414 authentication of stations, encryption of traffic, or both) is dealt 415 with by utilizing Layer 2 security techniques. This reliance on 416 Layer 2 mechanisms secures all DLEP Messages - both the UDP discovery 417 Signals and the TCP control Messages. 419 4. Metrics 421 DLEP includes the ability for the router and modem to communicate 422 metrics that reflect the characteristics (e.g., datarate, latency) of 423 the variable-quality link in use. DLEP does not specify how a given 424 metric value is to be calculated, rather, the protocol assumes that 425 metrics have been calculated by a 'best effort', incorporating all 426 pertinent data that is available to the modem device. Metrics based 427 on large enough sample sizes will preclude short traffic bursts from 428 adversely skewing reported values. 430 DLEP allows for metrics to be sent within two contexts - metrics for 431 a specific destination within the network (e.g., a specific router), 432 and per-session (those that apply to all destinations accessed via 433 the modem). Most metrics can be further subdivided into transmit and 434 receive metrics. In cases where metrics are provided at session 435 level, the router propagates the metrics to all entries in its 436 information base for destinations that are accessed via the modem. 438 DLEP modems announce all metric Data Items that will be reported 439 during the session, and provide default values for those metrics, in 440 the Session Initialization Response Message (Section 10.6). In order 441 to use a metric type that was not included in the Session 442 Initialization Response Message, modem implementations terminate the 443 session with the router (via the Session Terminate Message 444 (Section 10.9)), and establish a new session. 446 A DLEP modem can send metrics both in a session context, via the 447 Session Update Message (Section 10.7), and a specific destination 448 context, via the Destination Update Message (Section 10.17), at any 449 time. The most recently received metric value takes precedence over 450 any earlier value, regardless of context - that is: 452 1. If the router receives metrics in a specific destination context 453 (via the Destination Update Message), then the specific 454 destination is updated with the new metric. 456 2. If the router receives metrics in a session-wide context (via the 457 Session Update Message), then the metrics for all destinations 458 accessed via the modem are updated with the new metric. 460 It is left to implementations to choose sensible default values based 461 on their specific characteristics. Modems having static (non- 462 changing) link metric characteristics can report metrics only once 463 for a given destination (or once on a session-wide basis, if all 464 connections via the modem are of this static nature). 466 In addition to communicating existing metrics about the link, DLEP 467 provides a Message allowing a router to request a different datarate 468 or latency from the modem. This Message is the Link Characteristics 469 Request Message (Section 10.18), and gives the router the ability to 470 deal with requisite increases (or decreases) of allocated datarate/ 471 latency in demand-based schemes in a more deterministic manner. 473 5. DLEP Session Flow 475 All DLEP participants of a session transition through a number of 476 distinct states during the lifetime of a DLEP session: 478 o Peer Discovery 480 o Session Initialization 482 o In-Session 484 o Session Termination 486 o Session Reset 488 Modems, and routers supporting DLEP discovery, transition through all 489 five (5) of the above states. Routers that rely on preconfigured TCP 490 address/port information start in the Session Initialization state. 492 Modems MUST support the Peer Discovery state. 494 5.1. Peer Discovery State 496 In the Peer Discovery state, routers that support DLEP discovery MUST 497 send Peer Discovery Signals (Section 10.3) to initiate modem 498 discovery. 500 The router implementation then waits for a Peer Offer Signal 501 (Section 10.4) response from a potential DLEP modem. While in the 502 Peer Discovery state, Peer Discovery Signals MUST be sent repeatedly 503 by a DLEP router, at regular intervals. The interval MUST be a 504 minimum of one second; it SHOULD be a configurable parameter. Note 505 that this operation (sending Peer Discovery and waiting for Peer 506 Offer) is outside the DLEP Transaction Model (Section 6), as the 507 Transaction Model only describes Messages on a TCP session. 509 Routers receiving a Peer Offer Signal MUST use one of the modem 510 address/port combinations from the Peer Offer Signal to establish a 511 TCP connection to the modem, even if a priori configuration exists. 512 If multiple connection point Data Items exist in the received Peer 513 Offer Signal, routers SHOULD prioritize IPv6 connection points over 514 IPv4 connection points. Routers supporting TLS [RFC5246] MUST 515 prioritize connection points using TLS over those that do not. If 516 multiple connection points exist with the same transport (e.g. IPv6 517 or IPv4), implementations MAY use their own heuristics to determine 518 the order in which they are tried. If a TCP connection cannot be 519 achieved using any of the address/port combinations and the Discovery 520 mechanism is in use, then the router SHOULD resume issuing Peer 521 Discovery Signals. If no Connection Point Data Items are included in 522 the Peer Offer Signal, the router MUST use the source address of the 523 UDP packet containing the Peer Offer Signal as the IP address, and 524 the DLEP well-known port number. 526 In the Peer Discovery state, the modem implementation MUST listen for 527 incoming Peer Discovery Signals on the DLEP well-known IPv6 and/or 528 IPv4 link-local multicast address and port. On receipt of a valid 529 Peer Discovery Signal, it MUST reply with a Peer Offer Signal. 531 Modems MUST be prepared to accept a TCP connection from a router that 532 is not using the Discovery mechanism, i.e. a connection attempt that 533 occurs without a preceding Peer Discovery Signal. 535 Upon establishment of a TCP connection, both modem and router enter 536 the Session Initialization state. It is up to the router 537 implementation if Peer Discovery Signals continue to be sent after 538 the device has transitioned to the Session Initialization state. 539 Modem implementations MUST silently ignore Peer Discovery Signals 540 from a router with which it already has a TCP connection. 542 5.2. Session Initialization State 544 On entering the Session Initialization state, the router MUST send a 545 Session Initialization Message (Section 10.5) to the modem. The 546 router MUST then wait for receipt of a Session Initialization 547 Response Message (Section 10.6) from the modem. Receipt of the 548 Session Initialization Response Message containing a Status Data Item 549 (Section 11.1) with status code set to 0 'Success', see Table 2, 550 indicates that the modem has received and processed the Session 551 Initialization Message, and the router MUST transition to the In- 552 Session state. 554 On entering the Session Initialization state, the modem MUST wait for 555 receipt of a Session Initialization Message from the router. Upon 556 receipt of a Session Initialization Message, the modem MUST send a 557 Session Initialization Response Message, and the session MUST 558 transition to the In-Session state. If the modem receives any 559 Message other than Session Initialization, or it fails to parse the 560 received Message, it MUST NOT send any Message, and MUST terminate 561 the TCP connection and transition to the Session Reset state. 563 DLEP provides an extension negotiation capability to be used in the 564 Session Initialization state, see Section 3. Extensions supported by 565 an implementation MUST be declared to potential DLEP participants 566 using the Extensions Supported Data Item (Section 11.6). Once both 567 DLEP participants have exchanged initialization Messages, an 568 implementation MUST NOT emit any Message, Signal, Data Item or status 569 code associated with an extension that was not specified in the 570 received initialization Message from its peer. 572 5.3. In-Session State 574 In the In-Session state, Messages can flow in both directions between 575 DLEP participants, indicating changes to the session state, the 576 arrival or departure of reachable destinations, or changes of the 577 state of the links to the destinations. 579 The In-Session state is maintained until one of the following 580 conditions occur: 582 o The implementation terminates the session by sending a Session 583 Termination Message (Section 10.9), or, 585 o Its peer terminates the session, indicated by receiving a Session 586 Termination Message. 588 The implementation MUST then transition to the Session Termination 589 state. 591 5.3.1. Heartbeats 593 In order to maintain the In-Session state, periodic Heartbeat 594 Messages (Section 10.20) MUST be exchanged between router and modem. 595 These Messages are intended to keep the session alive, and to verify 596 bidirectional connectivity between the two DLEP participants. 598 Each DLEP participant is responsible for the creation of Heartbeat 599 Messages. 601 Receipt of any valid DLEP Message MUST reset the heartbeat interval 602 timer (i.e., valid DLEP Messages take the place of, and obviate the 603 need for, additional Heartbeat Messages). 605 Implementations MUST allow a minimum of two (2) heartbeat intervals 606 to expire with no Messages from its peer before terminating the 607 session. When terminating the session, a Session Termination Message 608 containing a Status Data Item (Section 11.1) with status code set to 609 132 'Timed Out', see Table 2, MUST be sent, and then the 610 implementation MUST transition to the Session Termination state. 612 5.4. Session Termination State 614 When an implementation enters the Session Termination state after 615 sending a Session Termination Message (Section 10.9) as the result of 616 an invalid Message or error, it MUST wait for a Session Termination 617 Response Message (Section 10.10) from its peer. Senders SHOULD allow 618 four (4) heartbeat intervals to expire before assuming that its peer 619 is unresponsive, and continuing with session termination. Any other 620 Message received while waiting MUST be silently ignored. 622 When the sender of the Session Termination Message receives a Session 623 Termination Response Message from its peer, or times out, it MUST 624 transition to the Session Reset state. 626 When an implementation receives a Session Termination Message from 627 its peer, it enters the Session Termination state and then it MUST 628 immediately send a Session Termination Response and transition to the 629 Session Reset state. 631 5.5. Session Reset state 633 In the Session Reset state the implementation MUST perform the 634 following actions: 636 o Release all resources allocated for the session. 638 o Eliminate all destinations in the information base represented by 639 the session. Destination Down Messages (Section 10.15) MUST NOT 640 be sent. 642 o Terminate the TCP connection. 644 Having completed these actions the implementation SHOULD return to 645 the relevant initial state: Peer Discovery for modems; either Peer 646 Discovery or Session Initialization for routers, depending on 647 configuration. 649 5.5.1. Unexpected TCP connection termination 651 If the TCP connection between DLEP participants is terminated when an 652 implementation is not in the Session Reset state, the implementation 653 MUST immediately transition to the Session Reset state. 655 6. Transaction Model 657 DLEP defines a simple Message transaction model: Only one request per 658 destination may be in progress at a time per session. A Message 659 transaction is considered complete when a response matching a 660 previously issued request is received. If a DLEP participant 661 receives a request for a destination for which there is already an 662 outstanding request, the implementation MUST terminate the session by 663 issuing a Session Termination Message (Section 10.9) containing a 664 Status Data Item (Section 11.1) with status code set to 129 665 'Unexpected Message', see Table 2, and transition to the Session 666 Termination state. There is no restriction to the total number of 667 Message transactions in progress at a time, as long as each 668 transaction refers to a different destination. 670 It should be noted that some requests may take a considerable amount 671 of time for some DLEP participants to complete, for example, a modem 672 handling a multicast destination up request may have to perform a 673 complex network reconfiguration. A sending implementation MUST be 674 able to handle such long running transactions gracefully. 676 Additionally, only one session request, e.g. a Session Initialization 677 Message (Section 10.5), may be in progress at a time per session. As 678 above, a session transaction is considered complete when a response 679 matching a previously issued request is received. If a DLEP 680 participant receives a session request while there is already a 681 session request in progress, it MUST terminate the session by issuing 682 a Session Termination Message containing a Status Data Item with 683 status code set to 129 'Unexpected Message', and transition to the 684 Session Termination state. Only the Session Termination Message may 685 be issued when a session transaction is in progress. Heartbeat 686 Messages (Section 10.20) MUST NOT be considered part of a session 687 transaction. 689 DLEP transactions do not time out and are not cancellable. An 690 implementation can detect if its peer has failed in some way by use 691 of the session heartbeat mechanism during the In-Session state, see 692 Section 5.3. 694 7. Extensions 696 Extensions MUST be negotiated on a per-session basis during session 697 initialization via the Extensions Supported mechanism. 698 Implementations are not required to support any extension in order to 699 be considered DLEP compliant. An extension document, describing the 700 operation of a credit windowing scheme for flow control, is described 701 in [CREDIT]. 703 If interoperable protocol extensions are required, they will need to 704 be standardized either as an update to this document, or as an 705 additional stand-alone specification. The requests for IANA- 706 controlled registries in this document contain sufficient Reserved 707 space for DLEP Signals, Messages, Data Items and status codes to 708 accommodate future extensions to the protocol. 710 As multiple protocol extensions MAY be announced during session 711 initialization, authors of protocol extensions need to consider the 712 interaction of their extension with other published extensions, and 713 specify any incompatibilities. 715 7.1. Experiments 717 This document requests Private Use numbering space in the DLEP 718 Signal, Message, Data Item and status code registries for 719 experimental extensions. The intent is to allow for experimentation 720 with new Signals, Messages, Data Items, and/or status codes, while 721 still retaining the documented DLEP behavior. 723 Use of the Private Use Signals, Messages, Data Items, status codes, 724 or behaviors MUST be announced as DLEP Extensions, during session 725 initialization, using extension identifiers from the Private Use 726 space in the Extensions Supported registry (Table 3), with a value 727 agreed upon (a priori) between the participants. DLEP extensions 728 using the Private Use numbering space are commonly referred to as 729 Experiments. 731 Multiple experiments MAY be announced in the Session Initialization 732 Messages. However, use of multiple experiments in a single session 733 could lead to interoperability issues or unexpected results (e.g., 734 clashes of experimental Signals, Messages, Data Items and/or status 735 code types), and is therefore discouraged. It is left to 736 implementations to determine the correct processing path (e.g., a 737 decision on whether to terminate the session, or to establish a 738 precedence of the conflicting definitions) if such conflicts arise. 740 8. Scalability 742 The protocol is intended to support thousands of destinations on a 743 given modem/router pair. At large scale, implementations SHOULD 744 consider employing techniques to prevent flooding its peer with a 745 large number of Messages in a short time. For example, a dampening 746 algorithm could be employed to prevent a flapping device from 747 generating a large number of Destination Up/Destination Down 748 Messages. 750 Also, use of techniques such as a hysteresis can lessen the impact of 751 rapid, minor fluctuations in link quality. The specific algorithms 752 for handling flapping destinations and minor changes in link quality 753 are outside the scope of this specification. 755 9. DLEP Signal and Message Structure 757 DLEP defines two protocol units used in two different ways: Signals 758 and Messages. Signals are only used in the Discovery mechanism and 759 are carried in UDP datagrams. Messages are used bi-directionally 760 over a TCP connection between the participants, in the Session 761 Initialization, In-Session and Session Termination states. 763 Both Signals and Messages consist of a Header followed by an 764 unordered list of Data Items. Headers consist of Type and Length 765 information, while Data Items are encoded as TLV (Type-Length-Value) 766 structures. In this document, the Data Items following a Signal or 767 Message Header are described as being 'contained in' the Signal or 768 Message. 770 There is no restriction on the order of Data Items following a 771 Header, and the acceptability of duplicate Data Items is defined by 772 the definition of the Signal or Message declared by the type in the 773 Header. 775 All integers in Header fields and values MUST be in network byte- 776 order. 778 9.1. DLEP Signal Header 780 The DLEP Signal Header contains the following fields: 782 0 1 2 3 783 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 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | 'D' | 'L' | 'E' | 'P' | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | Signal Type | Length | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 Figure 3: DLEP Signal Header 792 "DLEP": Every Signal MUST start with the characters: U+0044, U+004C, 793 U+0045, U+0050. 795 Signal Type: A 16-bit unsigned integer containing one of the DLEP 796 Signal Type values defined in this document. 798 Length: The length in octets, expressed as a 16-bit unsigned 799 integer, of all of the DLEP Data Items contained in this Signal. 800 This length MUST NOT include the length of the Signal Header 801 itself. 803 The DLEP Signal Header is immediately followed by zero or more DLEP 804 Data Items, encoded in TLVs, as defined in this document. 806 9.2. DLEP Message Header 808 The DLEP Message Header contains the following fields: 810 0 1 2 3 811 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 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | Message Type | Length | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 Figure 4: DLEP Message Header 818 Message Type: A 16-bit unsigned integer containing one of the DLEP 819 Message Type values defined in this document. 821 Length: The length in octets, expressed as a 16-bit unsigned 822 integer, of all of the DLEP Data Items contained in this Message. 823 This length MUST NOT include the length of the Message Header 824 itself. 826 The DLEP Message Header is immediately followed by zero or more DLEP 827 Data Items, encoded in TLVs, as defined in this document. 829 9.3. DLEP Generic Data Item 831 All DLEP Data Items contain the following fields: 833 0 1 2 3 834 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 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | Data Item Type | Length | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | Value... : 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 Figure 5: DLEP Generic Data Item 843 Data Item Type: A 16-bit unsigned integer field specifying the type 844 of Data Item being sent. 846 Length: The length in octets, expressed as a 16-bit unsigned 847 integer, of the Value field of the Data Item. This length MUST 848 NOT include the length of the Data Item Type and Length fields. 850 Value: A field of octets, which contains data specific to a 851 particular Data Item. 853 10. DLEP Signals and Messages 855 10.1. General Processing Rules 857 If an unrecognized, or unexpected Signal is received, or a received 858 Signal contains unrecognized, invalid, or disallowed duplicate Data 859 Items, the receiving implementation MUST ignore the Signal. 861 If a Signal is received with a TTL value that is NOT equal to 255, 862 the receiving implementation MUST ignore the Signal. 864 If an unrecognized Message is received, the receiving implementation 865 MUST issue a Session Termination Message (Section 10.9) containing a 866 Status Data Item (Section 11.1) with status code set to 128 'Unknown 867 Message', see Table 2, and transition to the Session Termination 868 state. 870 If an unexpected Message is received, the receiving implementation 871 MUST issue a Session Termination Message containing a Status Data 872 Item with status code set to 129 'Unexpected Message', and transition 873 to the Session Termination state. 875 If a received Message contains unrecognized, invalid, or disallowed 876 duplicate Data Items, the receiving implementation MUST issue a 877 Session Termination Message containing a Status Data Item with status 878 code set to 130 'Invalid Data', and transition to the Session 879 Termination state. 881 If a packet in the TCP stream is received with a TTL value other than 882 255, the receiving implementation MUST immediately transition to the 883 Session Reset state. 885 Prior to the exchange of Destination Up (Section 10.11) and 886 Destination Up Response (Section 10.12) Messages, or Destination 887 Announce (Section 10.13) and Destination Announce Response 888 (Section 10.14) Messages, no Messages concerning a destination may be 889 sent. An implementation receiving any Message with such an 890 unannounced destination MUST terminate the session by issuing a 891 Session Termination Message containing a Status Data Item with status 892 code set to 131 'Invalid Destination', and transition to the Session 893 Termination state. 895 After exchanging Destination Down (Section 10.15) and Destination 896 Down Response (Section 10.16) Messages, no Messages concerning a 897 destination may be a sent until a new Destination Up or Destination 898 Announce Message is sent. An implementation receiving a Message 899 about a destination previously announced as 'down' MUST terminate the 900 session by issuing a Session Termination Message containing a Status 901 Data Item with status code set to 131 'Invalid Destination', and 902 transition to the Session Termination state. 904 10.2. Status code processing 906 The behaviour of a DLEP participant receiving a Message containing a 907 Status Data Item (Section 11.1) is defined by the failure mode 908 associated with the value of the status code field, see Table 2. All 909 status code values less than 100 have a failure mode of 'Continue', 910 all other status codes have a failure mode of 'Terminate'. 912 A DLEP participant receiving any Message apart from Session 913 Termination Message (Section 10.9) containing a Status Data Item with 914 a status code value with failure mode 'Terminate' MUST immediately 915 issue a Session Termination Message containing an identical Status 916 Data Item, and then transition to the Session Termination state. 918 A DLEP participant receiving a Message containing a Status Data Item 919 with a status code value with failure mode 'Continue' can continue 920 normal operation of the session. 922 10.3. Peer Discovery Signal 924 A Peer Discovery Signal SHOULD be sent by a DLEP router to discover 925 DLEP modems in the network, see Section 5.1. 927 A Peer Discovery Signal MUST be encoded within a UDP packet. The 928 destination MUST be set to the DLEP well-known address and port 929 number. For routers supporting both IPv4 and IPv6 DLEP operation, it 930 is RECOMMENDED that IPv6 be selected as the transport. The source IP 931 address MUST be set to the router IP address associated with the DLEP 932 interface. There is no DLEP-specific restriction on source port. 934 To construct a Peer Discovery Signal, the Signal Type value in the 935 Signal Header is set to 1 (see Signal Type Registration 936 (Section 13.2)). 938 The Peer Discovery Signal MAY contain a Peer Type Data Item 939 (Section 11.4). 941 10.4. Peer Offer Signal 943 A Peer Offer Signal MUST be sent by a DLEP modem in response to a 944 properly formatted and addressed Peer Discovery Signal 945 (Section 10.3). 947 A Peer Offer Signal MUST be encoded within a UDP packet. The IP 948 destination MUST be set to the IP address and port number received in 949 the corresponding Peer Discovery Signal. The source IP address MUST 950 be set to the modem's IP address associated with the DLEP interface. 951 The source port number MUST be set to the DLEP well-known port 952 number. The Peer Offer Signal completes the discovery process, see 953 Section 5.1. 955 To construct a Peer Offer Signal, the Signal Type value in the Signal 956 Header is set to 2 (see Signal Type Registration (Section 13.2)). 958 The Peer Offer Signal MAY contain a Peer Type Data Item 959 (Section 11.4). 961 The Peer Offer Signal MAY contain one or more of any of the following 962 Data Items, with different values: 964 o IPv4 Connection Point (Section 11.2) 966 o IPv6 Connection Point (Section 11.3) 968 The IP Connection Point Data Items indicate the unicast address the 969 router MUST use when connecting the DLEP TCP session. 971 10.5. Session Initialization Message 973 A Session Initialization Message MUST be sent by a DLEP router as the 974 first Message of the DLEP TCP session. It is sent by the router 975 after a TCP connect to an address/port combination that was obtained 976 either via receipt of a Peer Offer, or from a priori configuration. 978 To construct a Session Initialization Message, the Message Type value 979 in the Message Header is set to 1 (see Message Type Registration 980 (Section 13.3)). 982 The Session Initialization Message MUST contain a Heartbeat Interval 983 Data Item (Section 11.5). 985 The Session Initialization Message MAY contain one of each of the 986 following Data Items: 988 o Peer Type (Section 11.4) 989 o Extensions Supported (Section 11.6) 991 The Session Initialization Message MAY contain one or more of each of 992 the following Data Items, with different values, and the data item 993 Add flag set to 1: 995 o IPv4 Address (Section 11.8) 997 o IPv6 Address (Section 11.9) 999 o IPv4 Attached Subnet (Section 11.10) 1001 o IPv6 Attached Subnet (Section 11.11) 1003 If any optional extensions are supported by the implementation, they 1004 MUST be enumerated in the Extensions Supported Data Item. If an 1005 Extensions Supported Data Item does not exist in a Session 1006 Initialization Message, the modem MUST conclude that there is no 1007 support for extensions in the router. 1009 DLEP Heartbeats are not fully established until receipt of the 1010 Session Initialization Response Message (Section 10.6), and therefore 1011 implementations MUST use their own timeout and retry heuristics for 1012 this Message. 1014 As an exception to the general rule governing an implementation 1015 receiving an unrecognized Data Item in a Message, see Section 10.1, 1016 if a Session Initialization Message contains one or more Extension 1017 Supported Data Items announcing support for extensions that the 1018 implementation does not recognize, then the implementation MAY ignore 1019 Data Items it does not recognize. 1021 10.6. Session Initialization Response Message 1023 A Session Initialization Response Message MUST be sent by a DLEP 1024 modem in response to a received Session Initialization Message 1025 (Section 10.5). 1027 To construct a Session Initialization Response Message, the Message 1028 Type value in the Message Header is set to 2 (see Message Type 1029 Registration (Section 13.3)). 1031 The Session Initialization Response Message MUST contain one of each 1032 of the following Data Items: 1034 o Status (Section 11.1) 1036 o Heartbeat Interval (Section 11.5) 1037 o Maximum Data Rate (Receive) (Section 11.12) 1039 o Maximum Data Rate (Transmit) (Section 11.13) 1041 o Current Data Rate (Receive) (Section 11.14) 1043 o Current Data Rate (Transmit) (Section 11.15) 1045 o Latency (Section 11.16) 1047 The Session Initialization Response Message MUST contain one of each 1048 of the following Data Items, if the Data Item will be used during the 1049 lifetime of the session: 1051 o Resources (Section 11.17) 1053 o Relative Link Quality (Receive) (Section 11.18) 1055 o Relative Link Quality (Transmit) (Section 11.19) 1057 o Maximum Transmission Unit (MTU) (Section 11.20) 1059 The Session Initialization Response Message MUST contain an 1060 Extensions Supported Data Item (Section 11.6), if DLEP extensions are 1061 supported. 1063 The Session Initialization Response Message MAY contain a Peer Type 1064 Data Item (Section 11.4). 1066 The Session Initialization Response Message MAY contain one or more 1067 of each of the following Data Items, with different values, and the 1068 data item Add flag set to 1: 1070 o IPv4 Address (Section 11.8) 1072 o IPv6 Address (Section 11.9) 1074 o IPv4 Attached Subnet (Section 11.10) 1076 o IPv6 Attached Subnet (Section 11.11) 1078 The Session Initialization Response Message completes the DLEP 1079 session establishment; the modem should transition to the In-Session 1080 state when the Message is sent, and the router should transition to 1081 the In-Session state upon receipt of an acceptable Session 1082 Initialization Response Message. 1084 All supported metric Data Items MUST be included in the Session 1085 Initialization Response Message, with default values to be used on a 1086 session-wide basis. This can be viewed as the modem 'declaring' all 1087 supported metrics at DLEP session initialization. Receipt of any 1088 further DLEP Message containing a metric Data Item not included in 1089 the Session Initialization Response Message MUST be treated as an 1090 error, resulting in the termination of the DLEP session between 1091 router and modem. 1093 If any optional extensions are supported by the modem, they MUST be 1094 enumerated in the Extensions Supported Data Item. If an Extensions 1095 Supported Data Item does not exist in a Session Initialization 1096 Response Message, the router MUST conclude that there is no support 1097 for extensions in the modem. 1099 After the Session Initialization/Session Initialization Response 1100 Messages have been successfully exchanged, implementations MUST only 1101 use extensions that are supported by both DLEP participants, see 1102 Section 5.2. 1104 10.7. Session Update Message 1106 A Session Update Message MAY be sent by a DLEP participant to 1107 indicate local Layer 3 address changes, or metric changes on a 1108 session-wide basis. 1110 To construct a Session Update Message, the Message Type value in the 1111 Message Header is set to 3 (see Message Type Registration 1112 (Section 13.3)). 1114 The Session Update Message MAY contain one or more of each of the 1115 following Data Items, with different values: 1117 o IPv4 Address (Section 11.8) 1119 o IPv6 Address (Section 11.9) 1121 o IPv4 Attached Subnet (Section 11.10) 1123 o IPv6 Attached Subnet (Section 11.11) 1125 When sent by a modem, the Session Update Message MAY contain one of 1126 each of the following Data Items: 1128 o Maximum Data Rate (Receive) (Section 11.12) 1130 o Maximum Data Rate (Transmit) (Section 11.13) 1131 o Current Data Rate (Receive) (Section 11.14) 1133 o Current Data Rate (Transmit) (Section 11.15) 1135 o Latency (Section 11.16) 1137 When sent by a modem, the Session Update Message MAY contain one of 1138 each of the following Data Items, if the Data Item is in use by the 1139 session: 1141 o Resources (Section 11.17) 1143 o Relative Link Quality (Receive) (Section 11.18) 1145 o Relative Link Quality (Transmit) (Section 11.19) 1147 o Maximum Transmission Unit (MTU) (Section 11.20) 1149 If metrics are supplied with the Session Update Message (e.g., 1150 Maximum Data Rate), these metrics are considered to be session-wide, 1151 and therefore MUST be applied to all destinations in the information 1152 base associated with the DLEP session. This includes destinations 1153 for which metrics may have been stored based on received Destination 1154 Update messages. 1156 It should be noted that Session Update Messages can be sent by both 1157 routers and modems. For example, addition of an IPv4 address on the 1158 router MAY prompt a Session Update Message to its attached modems. 1159 Also, for example, a modem that changes its Maximum Data Rate 1160 (Receive) for all destinations MAY reflect that change via a Session 1161 Update Message to its attached router(s). 1163 Concerning Layer 3 addresses and subnets: If the modem is capable of 1164 understanding and forwarding this information (via mechanisms not 1165 defined by DLEP), the update would prompt any remote DLEP-enabled 1166 modems to issue a Destination Update Message (Section 10.17) to their 1167 local routers with the new (or deleted) addresses and subnets. 1169 10.8. Session Update Response Message 1171 A Session Update Response Message MUST be sent by a DLEP participant 1172 when a Session Update Message (Section 10.7) is received. 1174 To construct a Session Update Response Message, the Message Type 1175 value in the Message Header is set to 4 (see Message Type 1176 Registration (Section 13.3)). 1178 The Session Update Response Message MUST contain a Status Data Item 1179 (Section 11.1). 1181 10.9. Session Termination Message 1183 A Session Termination Message MUST be sent by a DLEP participant when 1184 the DLEP session needs to be terminated. 1186 To construct a Session Termination Message, the Message Type value in 1187 the Message Header is set to 5 (see Message Type Registration 1188 (Section 13.3)). 1190 The Session Termination Message MUST contain Status Data Item 1191 (Section 11.1). 1193 It should be noted that Session Termination Messages can be sent by 1194 both routers and modems. 1196 10.10. Session Termination Response Message 1198 A Session Termination Response Message MUST be sent by a DLEP 1199 participant when a Session Termination Message (Section 10.9) is 1200 received. 1202 To construct a Session Termination Response Message, the Message Type 1203 value in the Message Header is set to 6 (see Message Type 1204 Registration (Section 13.3)). 1206 There are no valid Data Items for the Session Termination Response 1207 Message. 1209 Receipt of a Session Termination Response Message completes the tear- 1210 down of the DLEP session, see Section 5.4. 1212 10.11. Destination Up Message 1214 Destination Up Messages MAY be sent by a modem to inform its attached 1215 router of the presence of a new reachable destination. 1217 To construct a Destination Up Message, the Message Type value in the 1218 Message Header is set to 7 (see Message Type Registration 1219 (Section 13.3)). 1221 The Destination Up Message MUST contain a MAC Address Data Item 1222 (Section 11.7). 1224 The Destination Up Message SHOULD contain one or more of each of the 1225 following Data Items, with different values: 1227 o IPv4 Address (Section 11.8) 1229 o IPv6 Address (Section 11.9) 1231 The Destination Up Message MAY contain one of each of the following 1232 Data Items: 1234 o Maximum Data Rate (Receive) (Section 11.12) 1236 o Maximum Data Rate (Transmit) (Section 11.13) 1238 o Current Data Rate (Receive) (Section 11.14) 1240 o Current Data Rate (Transmit) (Section 11.15) 1242 o Latency (Section 11.16) 1244 The Destination Up Message MAY contain one of each of the following 1245 Data Items, if the Data Item is in use by the session: 1247 o Resources (Section 11.17) 1249 o Relative Link Quality (Receive) (Section 11.18) 1251 o Relative Link Quality (Transmit) (Section 11.19) 1253 o Maximum Transmission Unit (MTU) (Section 11.20) 1255 The Destination Up Message MAY contain one or more of each of the 1256 following Data Items, with different values: 1258 o IPv4 Attached Subnet (Section 11.10) 1260 o IPv6 Attached Subnet (Section 11.11) 1262 A router receiving a Destination Up Message allocates the necessary 1263 resources, creating an entry in the information base with the 1264 specifics (MAC Address, Latency, Data Rate, etc.) of the destination. 1265 The information about this destination will persist in the router's 1266 information base until a Destination Down Message (Section 10.15) is 1267 received, indicating that the modem has lost contact with the remote 1268 node, or the implementation transitions to the Session Termination 1269 state. 1271 10.12. Destination Up Response Message 1273 A router MUST send a Destination Up Response Message when a 1274 Destination Up Message (Section 10.11) is received. 1276 To construct a Destination Up Response Message, the Message Type 1277 value in the Message Header is set to 8 (see Message Type 1278 Registration (Section 13.3)). 1280 The Destination Up Response Message MUST contain one of each of the 1281 following Data Items: 1283 o MAC Address (Section 11.7) 1285 o Status (Section 11.1) 1287 A router that wishes to receive further information concerning the 1288 destination identified in the corresponding Destination Up Message 1289 MUST set the status code of the included Status Data Item to 0 1290 'Success', see Table 2. 1292 If the router has no interest in the destination identified in the 1293 corresponding Destination Up Message, then it MAY set the status code 1294 of the included Status Data Item to 1 'Not Interested'. 1296 A modem receiving a Destination Up Response Message containing a 1297 Status Data Item with status code of any value other than 0 'Success' 1298 MUST NOT send further Destination messages about the destination, 1299 e.g. Destination Down (Section 10.15) or Destination Update 1300 (Section 10.17) with the same MAC address. 1302 10.13. Destination Announce Message 1304 Usually a modem will discover the presence of one or more remote 1305 router/modem pairs and announce each destination's arrival by sending 1306 a corresponding Destination Up Message (Section 10.11) to the router. 1307 However, there may be times when a router wishes to express an 1308 interest in a destination that has yet to be announced, typically a 1309 multicast destination. Destination Announce Messages MAY be sent by 1310 a router to announce such an interest. 1312 A Destination Announce Message MAY also be sent by a router to 1313 request information concerning a destination in which it has 1314 previously declined interest, via the 1 'Not Interested' status code 1315 in a Destination Up Response Message (Section 10.12), see Table 2, or 1316 declared as 'down', via the Destination Down Message (Section 10.15). 1318 To construct a Destination Announce Message, the Message Type value 1319 in the Message Header is set to 9 (see Message Type Registration 1320 (Section 13.3)). 1322 The Destination Announce Message MUST contain a MAC Address Data Item 1323 (Section 11.7). 1325 The Destination Announce Message MAY contain zero or more of the 1326 following Data Items, with different values: 1328 o IPv4 Address (Section 11.8) 1330 o IPv6 Address (Section 11.9) 1332 One of the advantages of implementing DLEP is to leverage the modem's 1333 knowledge of the links between remote destinations allowing routers 1334 to avoid using probed neighbor discovery techniques, therefore modem 1335 implementations SHOULD announce available destinations via the 1336 Destination Up Message, rather than relying on Destination Announce 1337 Messages. 1339 10.14. Destination Announce Response Message 1341 A modem MUST send a Destination Announce Response Message when a 1342 Destination Announce Message (Section 10.13) is received. 1344 To construct a Destination Announce Response Message, the Message 1345 Type value in the Message Header is set to 10 (see Message Type 1346 Registration (Section 13.3)). 1348 The Destination Announce Response Message MUST contain one of each of 1349 the following Data Items: 1351 o MAC Address (Section 11.7) 1353 o Status (Section 11.1) 1355 The Destination Announce Response Message MAY contain one or more of 1356 each of the following Data Items, with different values: 1358 o IPv4 Address (Section 11.8) 1360 o IPv6 Address (Section 11.9) 1362 o IPv4 Attached Subnet (Section 11.10) 1364 o IPv6 Attached Subnet (Section 11.11) 1365 The Destination Announce Response Message MAY contain one of each of 1366 the following Data Items: 1368 o Maximum Data Rate (Receive) (Section 11.12) 1370 o Maximum Data Rate (Transmit) (Section 11.13) 1372 o Current Data Rate (Receive) (Section 11.14) 1374 o Current Data Rate (Transmit) (Section 11.15) 1376 o Latency (Section 11.16) 1378 The Destination Announce Response Message MAY contain one of each of 1379 the following Data Items, if the Data Item is in use by the session: 1381 o Resources (Section 11.17) 1383 o Relative Link Quality (Receive) (Section 11.18) 1385 o Relative Link Quality (Transmit) (Section 11.19) 1387 o Maximum Transmission Unit (MTU) (Section 11.20) 1389 If a modem is unable to report information immediately about the 1390 requested information, if the destination is not currently reachable, 1391 for example, the status code in the Status Data Item MUST be set to 2 1392 'Request Denied', see Table 2. 1394 After sending a Destination Announce Response Message containing a 1395 Status Data Item with status code of 0 'Success', a modem then 1396 announces changes to the link to the destination via Destination 1397 Update Messages. 1399 When a successful Destination Announce Response Message is received, 1400 the router should add knowledge of the available destination to its 1401 information base. 1403 10.15. Destination Down Message 1405 A modem MUST send a Destination Down Message to report when a 1406 destination (a remote node or a multicast group) is no longer 1407 reachable. 1409 A router MAY send a Destination Down Message to report when it no 1410 longer requires information concerning a destination. 1412 To construct a Destination Down Message, the Message Type value in 1413 the Message Header is set to 11 (see Message Type Registration 1414 (Section 13.3)). 1416 The Destination Down Message MUST contain a MAC Address Data Item 1417 (Section 11.7). 1419 It should be noted that both modem and router may send a Destination 1420 Down Message to their peer, regardless of which participant initially 1421 indicated the destination to be 'up'. 1423 10.16. Destination Down Response Message 1425 A Destination Down Response MUST be sent by the recipient of a 1426 Destination Down Message (Section 10.15) to confirm that the relevant 1427 data concerning the destination has been removed from the information 1428 base. 1430 To construct a Destination Down Response Message, the Message Type 1431 value in the Message Header is set to 12 (see Message Type 1432 Registration (Section 13.3)). 1434 The Destination Down Response Message MUST contain one of each of the 1435 following Data Items: 1437 o MAC Address (Section 11.7) 1439 o Status (Section 11.1) 1441 10.17. Destination Update Message 1443 A modem SHOULD send the Destination Update Message when it detects 1444 some change in the information base for a given destination (remote 1445 node or multicast group). Some examples of changes that would prompt 1446 a Destination Update Message are: 1448 o Change in link metrics (e.g., Data Rates) 1450 o Layer 3 addressing change 1452 To construct a Destination Update Message, the Message Type value in 1453 the Message Header is set to 13 (see Message Type Registration 1454 (Section 13.3)). 1456 The Destination Update Message MUST contain a MAC Address Data Item 1457 (Section 11.7). 1459 The Destination Update Message MAY contain one of each of the 1460 following Data Items: 1462 o Maximum Data Rate (Receive) (Section 11.12) 1464 o Maximum Data Rate (Transmit) (Section 11.13) 1466 o Current Data Rate (Receive) (Section 11.14) 1468 o Current Data Rate (Transmit) (Section 11.15) 1470 o Latency (Section 11.16) 1472 The Destination Update Message MAY contain one of each of the 1473 following Data Items, if the Data Item is in use by the session: 1475 o Resources (Section 11.17) 1477 o Relative Link Quality (Receive) (Section 11.18) 1479 o Relative Link Quality (Transmit) (Section 11.19) 1481 o Maximum Transmission Unit (MTU) (Section 11.20) 1483 The Destination Update Message MAY contain one or more of each of the 1484 following Data Items, with different values: 1486 o IPv4 Address (Section 11.8) 1488 o IPv6 Address (Section 11.9) 1490 o IPv4 Attached Subnet (Section 11.10) 1492 o IPv6 Attached Subnet (Section 11.11) 1494 If metrics are supplied with the Message (e.g., Resources), these 1495 metrics are MUST be applied to all destinations identified in the 1496 Message. Note that this may overwrite metrics provided in a 1497 previously received Session or Destination Up Messages. 1499 It should be noted that this Message has no corresponding response. 1501 10.18. Link Characteristics Request Message 1503 The Link Characteristics Request Message MAY be sent by a router to 1504 request that the modem initiate changes for specific characteristics 1505 of the link. The request can reference either a real destination 1506 (e.g., a remote node), or a logical destination (e.g., a multicast 1507 group) within the network. 1509 To construct a Link Characteristics Request Message, the Message Type 1510 value in the Message Header is set to 14 (see Message Type 1511 Registration (Section 13.3)). 1513 The Link Characteristics Request Message MUST contain one of the 1514 following Data Items: 1516 o MAC Address (Section 11.7) 1518 The Link Characteristics Request Message MUST contain at least one of 1519 each of the following Data Items: 1521 o Current Data Rate (Receive) (Section 11.14) 1523 o Current Data Rate (Transmit) (Section 11.15) 1525 o Latency (Section 11.16) 1527 The Link Characteristics Request Message MAY contain either a Current 1528 Data Rate (CDRR or CDRT) Data Item to request a different datarate 1529 than is currently allocated, a Latency Data Item to request that 1530 traffic delay on the link not exceed the specified value, or both. 1532 The router sending a Link Characteristics Request Message should be 1533 aware that a request may take an extended period of time to complete. 1535 10.19. Link Characteristics Response Message 1537 A modem MUST send a Link Characteristics Response Message when a Link 1538 Characteristics Request Message (Section 10.18) is received. 1540 To construct a Link Characteristics Response Message, the Message 1541 Type value in the Message Header is set to 15 (see Message Type 1542 Registration (Section 13.3)). 1544 The Link Characteristics Response Message MUST contain one of each of 1545 the following Data Items: 1547 o MAC Address (Section 11.7) 1549 o Status (Section 11.1) 1551 The Link Characteristics Response Message SHOULD contain one of each 1552 of the following Data Items: 1554 o Maximum Data Rate (Receive) (Section 11.12) 1556 o Maximum Data Rate (Transmit) (Section 11.13) 1558 o Current Data Rate (Receive) (Section 11.14) 1560 o Current Data Rate (Transmit) (Section 11.15) 1562 o Latency (Section 11.16) 1564 The Link Characteristics Response Message MAY contain one of each of 1565 the following Data Items, if the Data Item is in use by the session: 1567 o Resources (Section 11.17) 1569 o Relative Link Quality (Receive) (Section 11.18) 1571 o Relative Link Quality (Transmit) (Section 11.19) 1573 o Maximum Transmission Unit (MTU) (Section 11.20) 1575 The Link Characteristics Response Message MUST contain a complete set 1576 of metric Data Items, referencing all metrics declared in the Session 1577 Initialization Response Message (Section 10.6). The values in the 1578 metric Data Items in the Link Characteristics Response Message MUST 1579 reflect the link characteristics after the request has been 1580 processed. 1582 If an implementation is not able to alter the characteristics of the 1583 link in the manner requested, then the status code of the Status Data 1584 Item MUST be set to 2 'Request Denied', see Table 2. 1586 10.20. Heartbeat Message 1588 A Heartbeat Message MUST be sent by a DLEP participant every N 1589 milliseconds, where N is defined in the Heartbeat Interval Data Item 1590 (Section 11.5) of the Session Initialization Message (Section 10.5) 1591 or Session Initialization Response Message (Section 10.6). 1593 To construct a Heartbeat Message, the Message Type value in the 1594 Message Header is set to 16 (see Message Type Registration 1595 (Section 13.3)). 1597 There are no valid Data Items for the Heartbeat Message. 1599 The Message is used by DLEP participants to detect when a DLEP 1600 session peer (either the modem or the router) is no longer 1601 communicating, see Section 5.3.1. 1603 11. DLEP Data Items 1605 Following is the list of core Data Items that MUST be recognized by a 1606 DLEP compliant implementation. As mentioned before, not all Data 1607 Items need be used during a session, but an implementation MUST 1608 correctly process these Data Items when correctly associated with a 1609 Signal or Message. 1611 The core DLEP Data Items are: 1613 +-------------+-----------------------------------------------------+ 1614 | Type Code | Description | 1615 +-------------+-----------------------------------------------------+ 1616 | 0 | Reserved | 1617 | 1 | Status (Section 11.1) | 1618 | 2 | IPv4 Connection Point (Section 11.2) | 1619 | 3 | IPv6 Connection Point (Section 11.3) | 1620 | 4 | Peer Type (Section 11.4) | 1621 | 5 | Heartbeat Interval (Section 11.5) | 1622 | 6 | Extensions Supported (Section 11.6) | 1623 | 7 | MAC Address (Section 11.7) | 1624 | 8 | IPv4 Address (Section 11.8) | 1625 | 9 | IPv6 Address (Section 11.9) | 1626 | 10 | IPv4 Attached Subnet (Section 11.10) | 1627 | 11 | IPv6 Attached Subnet (Section 11.11) | 1628 | 12 | Maximum Data Rate (Receive) (MDRR) (Section 11.12) | 1629 | 13 | Maximum Data Rate (Transmit) (MDRT) (Section 11.13) | 1630 | 14 | Current Data Rate (Receive) (CDRR) (Section 11.14) | 1631 | 15 | Current Data Rate (Transmit) (CDRT) (Section 11.15) | 1632 | 16 | Latency (Section 11.16) | 1633 | 17 | Resources (RES) (Section 11.17) | 1634 | 18 | Relative Link Quality (Receive) (RLQR) (Section | 1635 | | 11.18) | 1636 | 19 | Relative Link Quality (Transmit) (RLQT) (Section | 1637 | | 11.19) | 1638 | 20 | Maximum Transmission Unit (MTU) (Section 11.20) | 1639 | 21-65407 | Reserved for future extensions | 1640 | 65408-65534 | Private Use. Available for experiments | 1641 | 65535 | Reserved | 1642 +-------------+-----------------------------------------------------+ 1644 Table 1: DLEP Data Item types 1646 11.1. Status 1648 For the Session Termination Message (Section 10.9), the Status Data 1649 Item indicates a reason for the termination. For all response 1650 Messages, the Status Data Item is used to indicate the success or 1651 failure of the previously received Message. 1653 The Status Data Item includes an optional Text field that can be used 1654 to provide a textual description of the status. The use of the Text 1655 field is entirely up to the receiving implementation, e.g., it could 1656 be output to a log file or discarded. If no Text field is supplied 1657 with the Status Data Item, the Length field MUST be set to 1. 1659 The Status Data Item contains the following fields: 1661 0 1 2 3 1662 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 1663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1664 | Data Item Type | Length | 1665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1666 | Code | Text... : 1667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1669 Data Item Type: 1 1671 Length: 1 + Length of text, in octets 1673 Status Code: One of the codes defined in Table 2 below. 1675 Text: UTF-8 encoded string of UNICODE [RFC3629] characters, 1676 describing the cause, used for implementation defined purposes. 1677 Since this field is used for description, implementations SHOULD 1678 limit characters in this field to printable characters. 1679 Implementations receiving this Data Item SHOULD check for 1680 printable characters in the field. 1682 An implementation MUST NOT assume the Text field is NUL-terminated. 1684 +----------+-------------+------------------+-----------------------+ 1685 | Status | Failure | Description | Reason | 1686 | Code | Mode | | | 1687 +----------+-------------+------------------+-----------------------+ 1688 | 0 | Continue | Success | The Message was | 1689 | | | | processed | 1690 | | | | successfully. | 1691 | 1 | Continue | Not Interested | The receiver is not | 1692 | | | | interested in this | 1693 | | | | Message subject, e.g. | 1694 | | | | in a Destination Up | 1695 | | | | Response Message | 1696 | | | | (Section 10.12) to | 1697 | | | | indicate no further | 1698 | | | | Messages about the | 1699 | | | | destination. | 1700 | 2 | Continue | Request Denied | The receiver refuses | 1701 | | | | to complete the | 1702 | | | | request. | 1703 | 3 | Continue | Inconsistent | One or more Data | 1704 | | | Data | Items in the Message | 1705 | | | | describe a logically | 1706 | | | | inconsistent state in | 1707 | | | | the network. For | 1708 | | | | example, in the | 1709 | | | | Destination Up | 1710 | | | | Message (Section | 1711 | | | | 10.11) when an | 1712 | | | | announced subnet | 1713 | | | | clashes with an | 1714 | | | | existing destination | 1715 | | | | subnet. | 1716 | 4-111 | Continue | | Reserved for future | 1717 | | | | extensions. | 1718 | 112-127 | Continue | | Available for | 1719 | | | | experiments. | 1720 | 128 | Terminate | Unknown Message | The Message was not | 1721 | | | | recognized by the | 1722 | | | | implementation. | 1723 | 129 | Terminate | Unexpected | The Message was not | 1724 | | | Message | expected while the | 1725 | | | | device was in the | 1726 | | | | current state, e.g., | 1727 | | | | a Session | 1728 | | | | Initialization | 1729 | | | | Message (Section | 1730 | | | | 10.5) in the In- | 1731 | | | | Session state. | 1732 | 130 | Terminate | Invalid Data | One or more Data | 1733 | | | | Items in the Message | 1734 | | | | are invalid, | 1735 | | | | unexpected or | 1736 | | | | incorrectly | 1737 | | | | duplicated. | 1738 | 131 | Terminate | Invalid | The destination | 1739 | | | Destination | included in the | 1740 | | | | Message does not | 1741 | | | | match a previously | 1742 | | | | announced | 1743 | | | | destination. For | 1744 | | | | example, in the Link | 1745 | | | | Characteristic | 1746 | | | | Response Message | 1747 | | | | (Section 10.19). | 1748 | 132 | Terminate | Timed Out | The session has timed | 1749 | | | | out. | 1750 | 133-239 | Terminate | | Reserved for future | 1751 | | | | extensions. | 1752 | 240-254 | Terminate | | Available for | 1753 | | | | experiments. | 1754 | 255 | Terminate | | Reserved. | 1755 +----------+-------------+------------------+-----------------------+ 1757 Table 2: DLEP Status Codes 1759 11.2. IPv4 Connection Point 1761 The IPv4 Connection Point Data Item indicates the IPv4 address and, 1762 optionally, the TCP port number on the modem available for 1763 connections. If provided, the router MUST use this information to 1764 initiate the TCP connection to the modem. 1766 The IPv4 Connection Point Data Item contains the following fields: 1768 0 1 2 3 1769 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 1770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1771 | Data Item Type | Length | 1772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1773 | Flags | IPv4 Address... : 1774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1775 : ...cont. | TCP Port Number (optional) | 1776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1778 Data Item Type: 2 1780 Length: 5 (or 7 if TCP Port included) 1782 Flags: Flags field, defined below. 1784 IPv4 Address: The IPv4 address listening on the modem. 1786 TCP Port Number: TCP Port number on the modem. 1788 If the Length field is 7, the port number specified MUST be used to 1789 establish the TCP session. If the TCP Port Number is omitted, i.e. 1790 the Length field is 5, the router MUST use the DLEP well-known port 1791 number (Section 13.13) to establish the TCP connection. 1793 The Flags field is defined as: 1795 0 1 2 3 4 5 6 7 1796 +-+-+-+-+-+-+-+-+ 1797 | Reserved |T| 1798 +-+-+-+-+-+-+-+-+ 1800 T: :Use TLS flag, indicating whether the TCP connection requires the 1801 use of TLS [RFC5246] (1), or not (0). 1803 Reserved: MUST be zero. Left for future assignment. 1805 11.3. IPv6 Connection Point 1807 The IPv6 Connection Point Data Item indicates the IPv6 address and, 1808 optionally, the TCP port number on the modem available for 1809 connections. If provided, the router MUST use this information to 1810 initiate the TCP connection to the modem. 1812 The IPv6 Connection Point Data Item contains the following fields: 1814 0 1 2 3 1815 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 1816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1817 | Data Item Type | Length | 1818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1819 | Flags | IPv6 Address : 1820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1821 : IPv6 Address : 1822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1823 : IPv6 Address : 1824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1825 : IPv6 Address : 1826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1827 : ...cont. | TCP Port Number (optional) | 1828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1830 Data Item Type: 3 1832 Length: 17 (or 19 if TCP Port included) 1834 Flags: Flags field, defined below. 1836 IPv6 Address: The IPv6 address listening on the modem. 1838 TCP Port Number: TCP Port number on the modem. 1840 If the Length field is 19, the port number specified MUST be used to 1841 establish the TCP session. If the TCP Port Number is omitted, i.e. 1843 the Length field is 17, the router MUST use the DLEP well-known port 1844 number (Section 13.13) to establish the TCP connection. 1846 The Flags field is defined as: 1848 0 1 2 3 4 5 6 7 1849 +-+-+-+-+-+-+-+-+ 1850 | Reserved |T| 1851 +-+-+-+-+-+-+-+-+ 1853 T: :Use TLS flag, indicating whether the TCP connection requires the 1854 use of TLS [RFC5246] (1), or not (0). 1856 Reserved: MUST be zero. Left for future assignment. 1858 11.4. Peer Type 1860 The Peer Type Data Item is used by the router and modem to give 1861 additional information as to its type. The Peer Type is a string and 1862 is envisioned to be used for informational purposes (e.g., as output 1863 in a display command). 1865 The Peer Type Data Item contains the following fields: 1867 0 1 2 3 1868 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 1869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1870 | Data Item Type | Length | 1871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1872 | Peer Type... : 1873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1875 Data Item Type: 4 1877 Length: Length of Peer Type string, in octets. 1879 Peer Type: UTF-8 encoded string of UNICODE [RFC3629] characters. 1880 For example, a satellite modem might set this variable to 1881 "Satellite terminal". Since this Data Item is intended to provide 1882 additional information for display commands, sending 1883 implementations SHOULD limit the data to printable characters, and 1884 receiving implementations SHOULD check the data for printable 1885 characters. 1887 An implementation MUST NOT assume the Peer Type field is NUL- 1888 terminated. 1890 11.5. Heartbeat Interval 1892 The Heartbeat Interval Data Item is used to specify a period in 1893 milliseconds for Heartbeat Messages (Section 10.20). 1895 The Heartbeat Interval Data Item contains the following fields: 1897 0 1 2 3 1898 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 1899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1900 | Data Item Type | Length | 1901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1902 | Heartbeat Interval | 1903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1905 Data Item Type: 5 1907 Length: 4 1909 Heartbeat Interval: The interval in milliseconds, expressed as a 1910 32-bit unsigned integer, for Heartbeat Messages. This value MUST 1911 NOT be 0. 1913 11.6. Extensions Supported 1915 The Extensions Supported Data Item is used by the router and modem to 1916 negotiate additional optional functionality they are willing to 1917 support. The Extensions List is a concatenation of the types of each 1918 supported extension, found in the IANA DLEP Extensions repository. 1919 Each Extension Type definition includes which additional Signals and 1920 Data Items are supported. 1922 The Extensions Supported Data Item contains the following fields: 1924 0 1 2 3 1925 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 1926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1927 | Data Item Type | Length | 1928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1929 | Extensions List... : 1930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1932 Data Item Type: 6 1934 Length: Length of the extensions list in octets. This is twice (2x) 1935 the number of extensions. 1937 Extension List: A list of extensions supported, identified by their 1938 2-octet value as listed in the extensions registry. 1940 11.7. MAC Address 1942 The MAC Address Data Item contains the address of the destination on 1943 the remote node. 1945 DLEP can support MAC addresses in either EUI-48 or EUI-64 format, 1946 with the restriction that all MAC addresses for a given DLEP session 1947 MUST be in the same format, and MUST be consistent with the MAC 1948 address format of the connected modem (e.g., if the modem is 1949 connected to the router with an EUI-48 MAC, all destination addresses 1950 via that modem MUST be expressed in EUI-48 format). 1952 Examples of a virtual destination would be a multicast MAC address, 1953 or the broadcast MAC (FF:FF:FF:FF:FF:FF). 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 | MAC Address : 1961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1962 : MAC Address : 1963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1964 : MAC Address : (if EUI-64 used) | 1965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1967 Data Item Type: 7 1969 Length: 6 for EUI-48 format, or 8 for EUI-64 format 1971 MAC Address: MAC Address of the destination. 1973 11.8. IPv4 Address 1975 When included in the Session Update Message, this Data Item contains 1976 the IPv4 address of the peer. When included in Destination Messages, 1977 this Data Item contains the IPv4 address of the destination. In 1978 either case, the Data Item also contains an indication of whether 1979 this is a new or existing address, or is a deletion of a previously 1980 known address. 1982 The IPv4 Address Data Item contains the following fields: 1984 0 1 2 3 1985 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 1986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1987 | Data Item Type | Length | 1988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1989 | Flags | IPv4 Address : 1990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1991 : ...cont. | 1992 +-+-+-+-+-+-+-+-+ 1994 Data Item Type: 8 1996 Length: 5 1998 Flags: Flags field, defined below. 2000 IPv4 Address: The IPv4 address of the destination or peer. 2002 The Flags field is defined as: 2004 0 1 2 3 4 5 6 7 2005 +-+-+-+-+-+-+-+-+ 2006 | Reserved |A| 2007 +-+-+-+-+-+-+-+-+ 2009 A: Add/Drop flag, indicating whether this is a new or existing 2010 address (1), or a withdrawal of an address (0). 2012 Reserved: MUST be zero. Reserved for future use. 2014 11.8.1. IPv4 Address Processing 2016 Processing of the IPv4 Address Data Item MUST be done within the 2017 context of the DLEP Peer session on which it is presented. 2019 The handling of erroneous or logically inconsistent conditions 2020 depends upon the type of the message that contains the data item: 2022 If the containing message is a Session Message, e.g., Session 2023 Initialization Message (Section 10.5), or Session Update Message 2024 (Section 10.7), the receiver of inconsistent information MUST issue a 2025 Session Termination Message (Section 10.9) containing a Status Data 2026 Item (Section 11.1) with status code set to 130 'Invalid Data', and 2027 transition to the Session Termination state. Examples of such 2028 conditions are: 2030 o An address Drop operation referencing an address that is not 2031 associated with the peer in the current session. 2033 o An address Add operation referencing an address that has already 2034 been added to the peer in the current session. 2036 If the containing message is a Destination Message, e.g., Destination 2037 Up Message (Section 10.11), or Destination Update Message 2038 (Section 10.17), the receiver of inconsistent information MAY issue 2039 the appropriate response message containing a Status Data Item, with 2040 status code set to 3 'Inconsistent Data', but MUST continue with 2041 session processing. Examples of such conditions are: 2043 o An address Add operation referencing an address that has already 2044 been added to the destination in the current session. 2046 o An address Add operation referencing an address that is associated 2047 with a different destination or the peer in the current session 2049 o An address Drop operation referencing an address that is not 2050 associated with the destination in the current session. 2052 If no response message is appropriate, for example, the Destination 2053 Update Message, then the implementation MUST continue with session 2054 processing. 2056 Modems that do not track IPv4 addresses MUST silently ignore IPv4 2057 Address Data Items. 2059 11.9. IPv6 Address 2061 When included in the Session Update Message, this Data Item contains 2062 the IPv6 address of the peer. When included in Destination Messages, 2063 this Data Item contains the IPv6 address of the destination. In 2064 either case, the Data Item also contains an indication of whether 2065 this is a new or existing address, or is a deletion of a previously 2066 known address. 2068 The IPv6 Address Data Item contains the following fields: 2070 0 1 2 3 2071 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 2072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2073 | Data Item Type | Length | 2074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2075 | Flags | IPv6 Address : 2076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2077 : IPv6 Address : 2078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2079 : IPv6 Address : 2080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2081 : IPv6 Address : 2082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2083 : IPv6 Address | 2084 +-+-+-+-+-+-+-+-+ 2086 Data Item Type: 9 2088 Length: 17 2090 Flags: Flags field, defined below. 2092 IPv6 Address: IPv6 Address of the destination or peer. 2094 The Flags field is defined as: 2096 0 1 2 3 4 5 6 7 2097 +-+-+-+-+-+-+-+-+ 2098 | Reserved |A| 2099 +-+-+-+-+-+-+-+-+ 2101 A: Add/Drop flag, indicating whether this is a new or existing 2102 address (1), or a withdrawal of an address (0). 2104 Reserved: MUST be zero. Reserved for future use. 2106 11.9.1. IPv6 Address Processing 2108 Processing of the IPv6 Address Data Item MUST be done within the 2109 context of the DLEP Peer session on which it is presented. 2111 The handling of erroneous or logically inconsistent conditions 2112 depends upon the type of the message that contains the data item: 2114 If the containing message is a Session Message, e.g., Session 2115 Initialization Message (Section 10.5), or Session Update Message 2116 (Section 10.7), the receiver of inconsistent information MUST issue a 2117 Session Termination Message (Section 10.9) containing a Status Data 2118 Item (Section 11.1) with status code set to 130 'Invalid Data', and 2119 transition to the Session Termination state. Examples of such 2120 conditions are: 2122 o An address Drop operation referencing an address that is not 2123 associated with the peer in the current session. 2125 o An address Add operation referencing an address that has already 2126 been added to the peer in the current session. 2128 If the containing message is a Destination Message, e.g., Destination 2129 Up Message (Section 10.11), or Destination Update Message 2130 (Section 10.17), the receiver of inconsistent information MAY issue 2131 the appropriate response message containing a Status Data Item, with 2132 status code set to 3 'Inconsistent Data', but MUST continue with 2133 session processing. Examples of such conditions are: 2135 o An address Add operation referencing an address that has already 2136 been added to the destination in the current session. 2138 o An address Add operation referencing an address that is associated 2139 with a different destination or the peer in the current session 2141 o An address Drop operation referencing an address that is not 2142 associated with the destination in the current session. 2144 If no response message is appropriate, for example, the Destination 2145 Update Message, then the implementation MUST continue with session 2146 processing. 2148 Modems that do not track IPv6 addresses MUST silently ignore IPv6 2149 Address Data Items. 2151 11.10. IPv4 Attached Subnet 2153 The DLEP IPv4 Attached Subnet allows a device to declare that it has 2154 an IPv4 subnet (e.g., a stub network) attached, that it has become 2155 aware of an IPv4 subnet being present at a remote destination, or 2156 that it has become aware of the loss of a subnet at the remote 2157 destination. 2159 The DLEP IPv4 Attached Subnet Data Item contains the following 2160 fields: 2162 0 1 2 3 2163 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 2164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2165 | Data Item Type | Length | 2166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2167 | Flags | IPv4 Attached Subnet : 2168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2169 : ...cont. |Prefix Length | 2170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2172 Data Item Type: 10 2174 Length: 6 2176 Flags: Flags field, defined below. 2178 IPv4 Subnet: The IPv4 subnet reachable at the destination. 2180 Prefix Length: Length of the prefix (0-32) for the IPv4 subnet. A 2181 prefix length outside the specified range MUST be considered as 2182 invalid. 2184 The Flags field is defined as: 2186 0 1 2 3 4 5 6 7 2187 +-+-+-+-+-+-+-+-+ 2188 | Reserved |A| 2189 +-+-+-+-+-+-+-+-+ 2191 A: Add/Drop flag, indicating whether this is a new or existing subnet 2192 address (1), or a withdrawal of a subnet address (0). 2194 Reserved: MUST be zero. Reserved for future use. 2196 11.10.1. IPv4 Attached Subnet Processing 2198 Processing of the IPv4 Attached Subnet Data Item MUST be done within 2199 the context of the DLEP Peer session on which it is presented. 2201 If the containing message is a Session Message, e.g., Session 2202 Initialization Message (Section 10.5), or Session Update Message 2203 (Section 10.7), the receiver of inconsistent information MUST issue a 2204 Session Termination Message (Section 10.9) containing a Status Data 2205 Item (Section 11.1) with status code set to 130 'Invalid Data', and 2206 transition to the Session Termination state. Examples of such 2207 conditions are: 2209 o A subnet Drop operation referencing a subnet that is not 2210 associated with the peer in the current session. 2212 o A subnet Add operation referencing a subnet that has already been 2213 added to the peer in the current session. 2215 If the containing message is a Destination Message, e.g., Destination 2216 Up Message (Section 10.11), or Destination Update Message 2217 (Section 10.17), the receiver of inconsistent information MAY issue 2218 the appropriate response message containing a Status Data Item, with 2219 status code set to 3 'Inconsistent Data', but MUST continue with 2220 session processing. Examples of such conditions are: 2222 o A subnet Add operation referencing a subnet that has already been 2223 added to the destination in the current session. 2225 o A subnet Add operation referencing a subnet that is associated 2226 with a different destination in the current session. 2228 o A subnet Drop operation referencing a subnet that is not 2229 associated with the destination in the current session. 2231 If no response message is appropriate, for example, the Destination 2232 Update Message, then the implementation MUST continue with session 2233 processing. 2235 Modems that do not track IPv4 subnets MUST silently ignore IPv4 2236 Attached Subnet Data Items. 2238 11.11. IPv6 Attached Subnet 2240 The DLEP IPv6 Attached Subnet allows a device to declare that it has 2241 an IPv6 subnet (e.g., a stub network) attached, that it has become 2242 aware of an IPv6 subnet being present at a remote destination, or 2243 that it has become aware of the loss of a subnet at the remote 2244 destination. 2246 The DLEP IPv6 Attached Subnet Data Item contains the following 2247 fields: 2249 0 1 2 3 2250 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 2251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2252 | Data Item Type | Length | 2253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2254 | Flags | IPv6 Attached Subnet : 2255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2256 : IPv6 Attached Subnet : 2257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2258 : IPv6 Attached Subnet : 2259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2260 : IPv6 Attached Subnet : 2261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2262 : ...cont. | Prefix Len. | 2263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2265 Data Item Type: 11 2267 Length: 18 2269 Flags: Flags field, defined below. 2271 IPv6 Attached Subnet: The IPv6 subnet reachable at the destination. 2273 Prefix Length: Length of the prefix (0-128) for the IPv6 subnet. A 2274 prefix length outside the specified range MUST be considered as 2275 invalid. 2277 The Flags field is defined as: 2279 0 1 2 3 4 5 6 7 2280 +-+-+-+-+-+-+-+-+ 2281 | Reserved |A| 2282 +-+-+-+-+-+-+-+-+ 2284 A: Add/Drop flag, indicating whether this is a new or existing subnet 2285 address (1), or a withdrawal of a subnet address (0). 2287 Reserved: MUST be zero. Reserved for future use. 2289 11.11.1. IPv6 Attached Subnet Processing 2291 Processing of the IPv6 Attached Subnet Data Item MUST be done within 2292 the context of the DLEP Peer session on which it is presented. 2294 If the containing message is a Session Message, e.g., Session 2295 Initialization Message (Section 10.5), or Session Update Message 2296 (Section 10.7), the receiver of inconsistent information MUST issue a 2297 Session Termination Message (Section 10.9) containing a Status Data 2298 Item (Section 11.1) with status code set to 130 'Invalid Data', and 2299 transition to the Session Termination state. Examples of such 2300 conditions are: 2302 o A subnet Drop operation referencing a subnet that is not 2303 associated with the peer in the current session. 2305 o A subnet Add operation referencing a subnet that has already been 2306 added to the peer in the current session. 2308 If the containing message is a Destination Message, e.g., Destination 2309 Up Message (Section 10.11), or Destination Update Message 2310 (Section 10.17), the receiver of inconsistent information MAY issue 2311 the appropriate response message containing a Status Data Item, with 2312 status code set to 3 'Inconsistent Data', but MUST continue with 2313 session processing. Examples of such conditions are: 2315 o A subnet Add operation referencing a subnet that has already been 2316 added to the destination in the current session. 2318 o A subnet Add operation referencing a subnet that is associated 2319 with a different destination in the current session. 2321 o A subnet Drop operation referencing a subnet that is not 2322 associated with the destination in the current session. 2324 If no response message is appropriate, for example, the Destination 2325 Update Message, then the implementation MUST continue with session 2326 processing. 2328 Modems that do not track IPv6 subnets MUST silently ignore IPv4 2329 Attached Subnet Data Items. 2331 11.12. Maximum Data Rate (Receive) 2333 The Maximum Data Rate (Receive) (MDRR) Data Item is used to indicate 2334 the maximum theoretical data rate, in bits per second, that can be 2335 achieved while receiving data on the link. 2337 The Maximum Data Rate (Receive) Data Item contains the following 2338 fields: 2340 0 1 2 3 2341 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 2342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2343 | Data Item Type | Length | 2344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2345 | MDRR (bps) : 2346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2347 : MDRR (bps) | 2348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2350 Data Item Type: 12 2352 Length: 8 2354 Maximum Data Rate (Receive): A 64-bit unsigned integer, representing 2355 the maximum theoretical data rate, in bits per second (bps), that 2356 can be achieved while receiving on the link. 2358 11.13. Maximum Data Rate (Transmit) 2360 The Maximum Data Rate (Transmit) (MDRT) Data Item is used to indicate 2361 the maximum theoretical data rate, in bits per second, that can be 2362 achieved while transmitting data on the link. 2364 The Maximum Data Rate (Transmit) Data Item contains the following 2365 fields: 2367 0 1 2 3 2368 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 2369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2370 | Data Item Type | Length | 2371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2372 | MDRT (bps) : 2373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2374 : MDRT (bps) | 2375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2377 Data Item Type: 13 2379 Length: 8 2381 Maximum Data Rate (Transmit): A 64-bit unsigned integer, 2382 representing the maximum theoretical data rate, in bits per second 2383 (bps), that can be achieved while transmitting on the link. 2385 11.14. Current Data Rate (Receive) 2387 The Current Data Rate (Receive) (CDRR) Data Item is used to indicate 2388 the rate at which the link is currently operating for receiving 2389 traffic. 2391 When used in the Link Characteristics Request Message 2392 (Section 10.18), Current Data Rate (Receive) represents the desired 2393 receive rate, in bits per second, on the link. 2395 The Current Data Rate (Receive) Data Item contains the following 2396 fields: 2398 0 1 2 3 2399 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 2400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2401 | Data Item Type | Length | 2402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2403 | CDRR (bps) : 2404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2405 : CDRR (bps) | 2406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2408 Data Item Type: 14 2410 Length: 8 2412 Current Data Rate (Receive): A 64-bit unsigned integer, representing 2413 the current data rate, in bits per second, that can currently be 2414 achieved while receiving traffic on the link. 2416 If there is no distinction between Current Data Rate (Receive) and 2417 Maximum Data Rate (Receive) (Section 11.12), Current Data Rate 2418 (Receive) MUST be set equal to the Maximum Data Rate (Receive). The 2419 Current Data Rate (Receive) MUST NOT exceed the Maximum Data Rate 2420 (Receive). 2422 11.15. Current Data Rate (Transmit) 2424 The Current Data Rate (Transmit) (CDRT) Data Item is used to indicate 2425 the rate at which the link is currently operating for transmitting 2426 traffic. 2428 When used in the Link Characteristics Request Message 2429 (Section 10.18), Current Data Rate (Transmit) represents the desired 2430 transmit rate, in bits per second, on the link. 2432 The Current Data Rate (Transmit) Data Item contains the following 2433 fields: 2435 0 1 2 3 2436 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 2437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2438 | Data Item Type | Length | 2439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2440 | CDRT (bps) : 2441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2442 : CDRT (bps) | 2443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2445 Data Item Type: 15 2447 Length: 8 2449 Current Data Rate (Transmit): A 64-bit unsigned integer, 2450 representing the current data rate, in bits per second, that can 2451 currently be achieved while transmitting traffic on the link. 2453 If there is no distinction between Current Data Rate (Transmit) and 2454 Maximum Data Rate (Transmit) (Section 11.13), Current Data Rate 2455 (Transmit) MUST be set equal to the Maximum Data Rate (Transmit). 2456 The Current Data Rate (Transmit) MUST NOT exceed the Maximum Data 2457 Rate (Transmit). 2459 11.16. Latency 2461 The Latency Data Item is used to indicate the amount of latency, in 2462 microseconds, on the link. 2464 The Latency value is reported as transmission delay. The calculation 2465 of latency is implementation dependent. For example, the latency may 2466 be a running average calculated from the internal queuing. 2468 The Latency Data Item contains the following fields: 2470 0 1 2 3 2471 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 2472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2473 | Data Item Type | Length | 2474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2475 | Latency : 2476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2477 : Latency | 2478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2479 Data Item Type: 16 2481 Length: 8 2483 Latency: A 64-bit unsigned integer, representing the transmission 2484 delay, in microseconds, that a packet encounters as it is 2485 transmitted over the link. 2487 11.17. Resources 2489 The Resources (RES) Data Item is used to indicate the amount of 2490 finite resources available for data transmission and reception at the 2491 destination as a percentage, with 0 meaning 'no resources remaining', 2492 and 100 meaning 'a full supply', assuming that when Resources reaches 2493 0 data transmission and/or reception will cease. 2495 An example of such resources might be battery life, but could equally 2496 be magic beans. The list of resources that might be considered is 2497 beyond the scope of this document, and is left to implementations to 2498 decide. 2500 This Data Item is designed to be used as an indication of some 2501 capability of the modem and/or router at the destination. 2503 The Resources Data Item contains the following fields: 2505 0 1 2 3 2506 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 2507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2508 | Data Item Type | Length | 2509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2510 | RES | 2511 +-+-+-+-+-+-+-+-+ 2513 Data Item Type: 17 2515 Length: 1 2517 Resources: An 8-bit unsigned integer percentage, 0-100, representing 2518 the amount of resources available. Any value greater than 100 2519 MUST be considered as invalid. 2521 If a device cannot calculate Resources, this Data Item MUST NOT be 2522 issued. 2524 11.18. Relative Link Quality (Receive) 2526 The Relative Link Quality (Receive) (RLQR) Data Item is used to 2527 indicate the quality of the link to a destination for receiving 2528 traffic, with 0 meaning 'worst quality', and 100 meaning 'best 2529 quality'. 2531 Quality in this context is defined as an indication of the stability 2532 of a link for reception; a destination with high Relative Link 2533 Quality (Receive) is expected to have generally stable DLEP metrics, 2534 and the metrics of a destination with low Relative Link Quality 2535 (Receive) can be expected to rapidly fluctuate over a wide range. 2537 The Relative Link Quality (Receive) Data Item contains the following 2538 fields: 2540 0 1 2 3 2541 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 2542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2543 | Data Item Type | Length | 2544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2545 | RLQR | 2546 +-+-+-+-+-+-+-+-+ 2548 Data Item Type: 18 2550 Length: 1 2552 Relative Link Quality (Receive): A non-dimensional unsigned 8-bit 2553 integer, 0-100, representing relative quality of the link for 2554 receiving traffic. Any value greater than 100 MUST be considered 2555 as invalid. 2557 If a device cannot calculate the Relative Link Quality (Receive), 2558 this Data Item MUST NOT be issued. 2560 11.19. Relative Link Quality (Transmit) 2562 The Relative Link Quality (Transmit) (RLQT) Data Item is used to 2563 indicate the quality of the link to a destination for transmitting 2564 traffic, with 0 meaning 'worst quality', and 100 meaning 'best 2565 quality'. 2567 Quality in this context is defined as an indication of the stability 2568 of a link for transmission; a destination with high Relative Link 2569 Quality (Transmit) is expected to have generally stable DLEP metrics, 2570 and the metrics of a destination with low Relative Link Quality 2571 (Transmit) can be expected to rapidly fluctuate over a wide range. 2573 The Relative Link Quality (Transmit) Data Item contains the following 2574 fields: 2576 0 1 2 3 2577 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 2578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2579 | Data Item Type | Length | 2580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2581 | RLQT | 2582 +-+-+-+-+-+-+-+-+ 2584 Data Item Type: 19 2586 Length: 1 2588 Relative Link Quality (Transmit): A non-dimensional unsigned 8-bit 2589 integer, 0-100, representing relative quality of the link for 2590 transmitting traffic. Any value greater than 100 MUST be 2591 considered as invalid. 2593 If a device cannot calculate the Relative Link Quality (Transmit), 2594 this Data Item MUST NOT be issued. 2596 11.20. Maximum Transmission Unit (MTU) 2598 The Maximum Transmission Unit (MTU) Data Item is used to indicate the 2599 maximum size, in octets, of an IP packet that can be transmitted 2600 without fragmentation, including headers, but excluding any lower 2601 layer headers. 2603 The Maximum Transmission Unit Data Item contains the following 2604 fields: 2606 0 1 2 3 2607 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 2608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2609 | Data Item Type | Length | 2610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2611 | MTU | 2612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2614 Data Item Type: 20 2616 Length: 2 2618 Maximum Transmission Unit: The maximum size, in octets, of an IP 2619 packet that can be transmitted without fragmentation, including 2620 headers, but excluding any lower layer headers. 2622 If a device cannot calculate the Maximum Transmission Unit, this Data 2623 Item MUST NOT be issued. 2625 12. Security Considerations 2627 The potential security concerns when using DLEP are: 2629 1. An attacker might pretend to be a DLEP participant, either at 2630 DLEP session initialization, or by injection of DLEP Messages 2631 once a session has been established, and/or 2633 2. DLEP Data Items could be altered by an attacker, causing the 2634 receiving implementation to inappropriately alter its information 2635 base concerning network status. 2637 The implications of attacks on DLEP peers are directly proportional 2638 to the extent to which DLEP data is used within the control plane. 2639 While the use of DLEP data in other control plane components is out 2640 of scope for this document, as an example, if DLEP statistics are 2641 incorporated into route cost calculations, adversaries masquerading 2642 as a DLEP peer, and injecting malicious data via DLEP, could cause 2643 suboptimal route selection, adversely impacting network performance. 2644 Similar issues can arise if DLEP data is used as an input to policing 2645 algorithms - injection of malicious data via DLEP can cause those 2646 policing algorithms to make incorrect decisions, degrading network 2647 throughput. 2649 For these reasons, security of the DLEP transport must be considered 2650 at both the transport layer, and at Layer 2. 2652 At the transport layer, implementations of DLEP SHOULD implement, and 2653 use, TLS [RFC5246] to protect the TCP session. Deployments that are 2654 protected by strong physical security (e.g., deployments where the 2655 DLEP router and modem are the only devices on a physical Layer 2 2656 segment) may consider use of DLEP without TLS. When TLS is in use, 2657 each peer SHOULD check the validity of credentials presented by the 2658 other peer during TLS session extablishment. Refer to [RFC7525] for 2659 additional details. 2661 At layer 2 - since DLEP is restricted to operation over a single 2662 (possibly logical) hop, implementations SHOULD also secure the Layer 2663 2 link. Examples of technologies that can be deployed to secure the 2664 Layer 2 link include [IEEE-802.1AE] and [IEEE-802.1X]. 2666 To avoid potential denial of service attack, it is RECOMMENDED that 2667 implementations using the Peer Discovery mechanism maintain an 2668 information base of hosts that persistently fail Session 2669 Initialization having provided an acceptable Peer Discovery Signal, 2670 and ignore subsequent Peer Discovery Signals from such hosts. 2672 This specification does not address security of the data plane, as it 2673 (the data plane) is not affected, and standard security procedures 2674 can be employed. 2676 13. IANA Considerations 2678 13.1. Registrations 2680 Upon approval of this document, IANA is requested to create a new 2681 protocol registry for Dynamic Link Exchange Protocol (DLEP). The 2682 remainder of this section requests the creation of new DLEP specific 2683 registries. 2685 13.2. Signal Type Registration 2687 Upon approval of this document, IANA is requested to create a new 2688 DLEP registry, named "Signal Type Values". 2690 The following table provides initial registry values and the 2691 [RFC5226] defined policies that should apply to the registry: 2693 +--------------+-------------------------+ 2694 | Type Code | Description/Policy | 2695 +--------------+-------------------------+ 2696 | 0 | Reserved | 2697 | 1 | Peer Discovery Signal | 2698 | 2 | Peer Offer Signal | 2699 | 3-65519 | Specification Required | 2700 | 65520-65534 | Private Use | 2701 | 65535 | Reserved | 2702 +--------------+-------------------------+ 2704 13.3. Message Type Registration 2706 Upon approval of this document, IANA is requested to create a new 2707 DLEP registry, named "Message Type Values". 2709 The following table provides initial registry values and the 2710 [RFC5226] defined policies that should apply to the registry: 2712 +--------------+------------------------------------------+ 2713 | Type Code | Description/Policy | 2714 +--------------+------------------------------------------+ 2715 | 0 | Reserved | 2716 | 1 | Session Initialization Message | 2717 | 2 | Session Initialization Response Message | 2718 | 3 | Session Update Message | 2719 | 4 | Session Update Response Message | 2720 | 5 | Session Termination Message | 2721 | 6 | Session Termination Response Message | 2722 | 7 | Destination Up Message | 2723 | 8 | Destination Up Response Message | 2724 | 9 | Destination Announce Message | 2725 | 10 | Destination Announce Response Message | 2726 | 11 | Destination Down Message | 2727 | 12 | Destination Down Response Message | 2728 | 13 | Destination Update Message | 2729 | 14 | Link Characteristics Request Message | 2730 | 15 | Link Characteristics Response Message | 2731 | 16 | Heartbeat Message | 2732 | 17-65519 | Specification Required | 2733 | 65520-65534 | Private Use | 2734 | 65535 | Reserved | 2735 +--------------+------------------------------------------+ 2737 13.4. DLEP Data Item Registrations 2739 Upon approval of this document, IANA is requested to create a new 2740 DLEP registry, named "Data Item Values". 2742 The following table provides initial registry values and the 2743 [RFC5226] defined policies that should apply to the registry: 2745 +-------------------+------------------------------------------+ 2746 | Type Code | Description/Policy | 2747 +-------------------+------------------------------------------+ 2748 | 0 | Reserved | 2749 | 1 | Status | 2750 | 2 | IPv4 Connection Point | 2751 | 3 | IPv6 Connection Point | 2752 | 4 | Peer Type | 2753 | 5 | Heartbeat Interval | 2754 | 6 | Extensions Supported | 2755 | 7 | MAC Address | 2756 | 8 | IPv4 Address | 2757 | 9 | IPv6 Address | 2758 | 10 | IPv4 Attached Subnet | 2759 | 11 | IPv6 Attached Subnet | 2760 | 12 | Maximum Data Rate (Receive) (MDRR) | 2761 | 13 | Maximum Data Rate (Transmit) (MDRT) | 2762 | 14 | Current Data Rate (Receive) (CDRR) | 2763 | 15 | Current Data Rate (Transmit) (CDRT) | 2764 | 16 | Latency | 2765 | 17 | Resources (RES) | 2766 | 18 | Relative Link Quality (Receive) (RLQR) | 2767 | 19 | Relative Link Quality (Transmit) (RLQT) | 2768 | 20 | Maximum Transmission Unit (MTU) | 2769 | 21-65407 | Specification Required | 2770 | 65408-65534 | Private Use | 2771 | 65535 | Reserved | 2772 +-------------------+------------------------------------------+ 2774 13.5. DLEP Status Code Registrations 2776 Upon approval of this document, IANA is requested to create a new 2777 DLEP registry, named "Status Code Values". 2779 The following table provides initial registry values and the 2780 [RFC5226] defined policies that should apply to the registry: 2782 +--------------+---------------+-------------------------+ 2783 | Status Code | Failure Mode | Description/Policy | 2784 +--------------+---------------+-------------------------+ 2785 | 0 | Continue | Success | 2786 | 1 | Continue | Not Interested | 2787 | 2 | Continue | Request Denied | 2788 | 3 | Continue | Inconsistent Data | 2789 | 4-111 | Continue | Specification Required | 2790 | 112-127 | Continue | Private Use | 2791 | 128 | Terminate | Unknown Message | 2792 | 129 | Terminate | Unexpected Message | 2793 | 130 | Terminate | Invalid Data | 2794 | 131 | Terminate | Invalid Destination | 2795 | 132 | Terminate | Timed Out | 2796 | 133-239 | Terminate | Specification Required | 2797 | 240-254 | Terminate | Private Use | 2798 | 255 | Terminate | Reserved | 2799 +--------------+---------------+-------------------------+ 2801 13.6. DLEP Extensions Registrations 2803 Upon approval of this document, IANA is requested to create a new 2804 DLEP registry, named "Extension Type Values". 2806 The following table provides initial registry values and the 2807 [RFC5226] defined policies that should apply to the registry: 2809 +--------------+----------------------------+ 2810 | Code | Description/Policy | 2811 +--------------+----------------------------+ 2812 | 0 | Reserved | 2813 | 1 | Credit Windowing [CREDIT] | 2814 | 2-65519 | Specification Required | 2815 | 65520-65534 | Private Use | 2816 | 65535 | Reserved | 2817 +--------------+----------------------------+ 2819 Table 3: DLEP Extension types 2821 13.7. DLEP IPv4 Connection Point Flags 2823 Upon approval of this document, IANA is requested to create a new 2824 DLEP registry, named "IPv4 Connection Point Flags". 2826 The following table provides initial registry values and the 2827 [RFC5226] defined policies that should apply to the registry: 2829 +------------+------------------------------------+ 2830 | Bit | Description/Policy | 2831 +------------+------------------------------------+ 2832 | 0-6 | Unassigned/Specification Required | 2833 | 7 | Use TLS [RFC5246] indicator | 2834 +------------+------------------------------------+ 2836 13.8. DLEP IPv6 Connection Point Flags 2838 Upon approval of this document, IANA is requested to create a new 2839 DLEP registry, named "IPv6 Connection Point Flags". 2841 The following table provides initial registry values and the 2842 [RFC5226] defined policies that should apply to the registry: 2844 +------------+------------------------------------+ 2845 | Bit | Description/Policy | 2846 +------------+------------------------------------+ 2847 | 0-6 | Unassigned/Specification Required | 2848 | 7 | Use TLS [RFC5246] indicator | 2849 +------------+------------------------------------+ 2851 13.9. DLEP IPv4 Address Flag 2853 Upon approval of this document, IANA is requested to create a new 2854 DLEP registry, named "IPv4 Address Flags". 2856 The following table provides initial registry values and the 2857 [RFC5226] defined policies that should apply to the registry: 2859 +------------+------------------------------------+ 2860 | Bit | Description/Policy | 2861 +------------+------------------------------------+ 2862 | 0-6 | Unassigned/Specification Required | 2863 | 7 | Add/Drop indicator | 2864 +------------+------------------------------------+ 2866 13.10. DLEP IPv6 Address Flag 2868 Upon approval of this document, IANA is requested to create a new 2869 DLEP registry, named "IPv6 Address Flags". 2871 The following table provides initial registry values and the 2872 [RFC5226] defined policies that should apply to the registry: 2874 +------------+------------------------------------+ 2875 | Bit | Description/Policy | 2876 +------------+------------------------------------+ 2877 | 0-6 | Unassigned/Specification Required | 2878 | 7 | Add/Drop indicator | 2879 +------------+------------------------------------+ 2881 13.11. DLEP IPv4 Attached Subnet Flag 2883 Upon approval of this document, IANA is requested to create a new 2884 DLEP registry, named "IPv4 Attached Subnet Flags". 2886 The following table provides initial registry values and the 2887 [RFC5226] defined policies that should apply to the registry: 2889 +------------+------------------------------------+ 2890 | Bit | Description/Policy | 2891 +------------+------------------------------------+ 2892 | 0-6 | Unassigned/Specification Required | 2893 | 7 | Add/Drop indicator | 2894 +------------+------------------------------------+ 2896 13.12. DLEP IPv6 Attached Subnet Flag 2898 Upon approval of this document, IANA is requested to create a new 2899 DLEP registry, named "IPv6 Attached Subnet Flags". 2901 The following table provides initial registry values and the 2902 [RFC5226] defined policies that should apply to the registry: 2904 +------------+------------------------------------+ 2905 | Bit | Description/Policy | 2906 +------------+------------------------------------+ 2907 | 0-6 | Unassigned/Specification Required | 2908 | 7 | Add/Drop indicator | 2909 +------------+------------------------------------+ 2911 13.13. DLEP Well-known Port 2913 Upon approval of this document, IANA is requested to assign a single 2914 value in the "Service Name and Transport Protocol Port Number 2915 Registry" found at https://www.iana.org/assignments/service-names- 2916 port-numbers/service-names-port-numbers.xhtml for use by "DLEP", as 2917 defined in this document. This assignment should be valid for TCP 2918 and UDP. 2920 13.14. DLEP IPv4 Link-local Multicast Address 2922 Upon approval of this document, IANA is requested to assign an IPv4 2923 multicast address registry found at http://www.iana.org/assignments/ 2924 multicast-addresses for use as the "IPv4 DLEP Discovery Address". 2926 13.15. DLEP IPv6 Link-local Multicast Address 2928 Upon approval of this document, IANA is requested to assign an IPv6 2929 multicast address registry found at http://www.iana.org/assignments/ 2930 multicast-addresses for use as the "IPv6 DLEP Discovery Address". 2932 14. Acknowledgements 2934 We would like to acknowledge and thank the members of the DLEP design 2935 team, who have provided invaluable insight. The members of the 2936 design team are: Teco Boot, Bow-Nan Cheng, John Dowdell, and Henning 2937 Rogge. 2939 We would also like to acknowledge the influence and contributions of 2940 Greg Harrison, Chris Olsen, Martin Duke, Subir Das, Jaewon Kang, 2941 Vikram Kaul, Nelson Powell, Lou Berger, and Victoria Pritchard. 2943 15. References 2945 15.1. Normative References 2947 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2948 Requirement Levels", BCP 14, RFC 2119, 2949 DOI 10.17487/RFC2119, March 1997, 2950 . 2952 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2953 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2954 2003, . 2956 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 2957 Pignataro, "The Generalized TTL Security Mechanism 2958 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 2959 . 2961 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2962 (TLS) Protocol Version 1.2", RFC 5246, 2963 DOI 10.17487/RFC5246, August 2008, 2964 . 2966 15.2. Informative References 2968 [CREDIT] Ratliff, S., "Credit Windowing extension for DLEP", IETF 2969 draft draft-ietf-manet-credit-window-04, March 2016. 2971 [IEEE-802.1AE] 2972 "IEEE Standards for Local and Metropolitan Area Networks: 2973 Media Access Control (MAC) Security", 2974 DOI 10.1109/IEEESTD.2006.245590, August 2006. 2976 [IEEE-802.1X] 2977 "IEEE Standards for Local and Metropolitan Area Networks: 2978 Port based Network Access Control", 2979 DOI 10.1109/IEEESTD.2010.5409813, February 2010. 2981 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2982 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2983 DOI 10.17487/RFC5226, May 2008, 2984 . 2986 [RFC5578] Berry, B., Ed., Ratliff, S., Paradise, E., Kaiser, T., and 2987 M. Adams, "PPP over Ethernet (PPPoE) Extensions for Credit 2988 Flow and Link Metrics", RFC 5578, DOI 10.17487/RFC5578, 2989 February 2010, . 2991 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2992 "Recommendations for Secure Use of Transport Layer 2993 Security (TLS) and Datagram Transport Layer Security 2994 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2995 2015, . 2997 Appendix A. Discovery Signal Flows 2998 Router Modem Signal Description 2999 ======================================================================== 3001 | Router initiates discovery, starts 3002 | a timer, send Peer Discovery 3003 |-------Peer Discovery---->X Signal. 3005 ~ ~ ~ ~ ~ ~ ~ Router discovery timer expires 3006 without receiving Peer Offer. 3008 | Router sends another Peer 3009 |-------Peer Discovery---------->| Discovery Signal. 3010 | 3011 | Modem receives Peer Discovery 3012 | Signal. 3013 | 3014 | Modem sends Peer Offer with 3015 |<--------Peer Offer-------------| Connection Point information. 3016 : 3017 : Router MAY cancel discovery timer 3018 : and stop sending Peer Discovery 3019 : Signals. 3021 Appendix B. Peer Level Message Flows 3023 B.1. Session Initialization 3025 Router Modem Message Description 3026 ======================================================================== 3028 | Router connects to discovered or 3029 | pre-configured Modem Connection 3030 |--TCP connection established---> Point. 3031 | 3032 | Router sends Session 3033 |----Session Initialization----->| Initialization Message. 3034 | 3035 | Modem receives Session 3036 | Initialization Message. 3037 | 3038 | Modem sends Session Initialization 3039 |<--Session Initialization Resp.-| Response, with Success Status Data 3040 | | Item. 3041 | | 3042 |<<============================>>| Session established. Heartbeats 3043 : : begin. 3045 B.2. Session Initialization - Refused 3047 Router Modem Message Description 3048 ======================================================================== 3050 | Router connects to discovered or 3051 | pre-configured Modem Connection 3052 |--TCP connection established---> Point. 3053 | 3054 | Router sends Session 3055 |-----Session Initialization---->| Initialization Message. 3056 | 3057 | Modem receives Session 3058 | Initialization Message, and will 3059 | not support the advertised 3060 | extensions. 3061 | 3062 | Modem sends Session Initialization 3063 | Response, with 'Request Denied' 3064 |<-Session Initialization Resp.--| Status Data Item. 3065 | 3066 | 3067 | Router receives negative Session 3068 | Initialization Response, closes 3069 ||---------TCP close------------|| TCP connection. 3071 B.3. Router Changes IP Addresses 3073 Router Modem Message Description 3074 ======================================================================== 3076 | Router sends Session Update 3077 |-------Session Update---------->| Message to announce change of IP 3078 | address 3079 | 3080 | Modem receives Session Update 3081 | Message and updates internal 3082 | state. 3083 | 3084 |<----Session Update Response----| Modem sends Session Update 3085 | Response. 3087 B.4. Modem Changes Session-wide Metrics 3088 Router Modem Message Description 3089 ======================================================================== 3091 | Modem sends Session Update Message 3092 | to announce change of modem-wide 3093 |<--------Session Update---------| metrics 3094 | 3095 | Router receives Session Update 3096 | Message and updates internal 3097 | state. 3098 | 3099 |----Session Update Response---->| Router sends Session Update 3100 | Response. 3102 B.5. Router Terminates Session 3104 Router Modem Message Description 3105 ======================================================================== 3107 | Router sends Session Termination 3108 |------Session Termination------>| Message with Status Data Item. 3109 | | 3110 |-------TCP shutdown (send)---> | Router stops sending Messages. 3111 | 3112 | Modem receives Session 3113 | Termination, stops counting 3114 | received heartbeats and stops 3115 | sending heartbeats. 3116 | 3117 | Modem sends Session Termination 3118 |<---Session Termination Resp.---| Response with Status 'Success'. 3119 | 3120 | Modem stops sending Messages. 3121 | 3122 ||---------TCP close------------|| Session terminated. 3124 B.6. Modem Terminates Session 3125 Router Modem Message Description 3126 ======================================================================== 3128 | Modem sends Session Termination 3129 |<----Session Termination--------| Message with Status Data Item. 3130 | 3131 | Modem stops sending Messages. 3132 | 3133 | Router receives Session 3134 | Termination, stops counting 3135 | received heartbeats and stops 3136 | sending heartbeats. 3137 | 3138 | Router sends Session Termination 3139 |---Session Termination Resp.--->| Response with Status 'Success'. 3140 | 3141 | Router stops sending Messages. 3142 | 3143 ||---------TCP close------------|| Session terminated. 3145 B.7. Session Heartbeats 3146 Router Modem Message Description 3147 ======================================================================== 3149 |----------Heartbeat------------>| Router sends heartbeat Message 3150 | 3151 | Modem resets heartbeats missed 3152 | counter. 3154 ~ ~ ~ ~ ~ ~ ~ 3156 |---------[Any Message]--------->| When the Modem receives any 3157 | Message from the Router. 3158 | 3159 | Modem resets heartbeats missed 3160 | counter. 3162 ~ ~ ~ ~ ~ ~ ~ 3164 |<---------Heartbeat-------------| Modem sends heartbeat Message 3165 | 3166 | Router resets heartbeats missed 3167 | counter. 3169 ~ ~ ~ ~ ~ ~ ~ 3171 |<--------[Any Message]----------| When the Router receives any 3172 | Message from the Modem. 3173 | 3174 | Modem resets heartbeats missed 3175 | counter. 3177 B.8. Router Detects a Heartbeat timeout 3179 Router Modem Message Description 3180 ======================================================================== 3182 X<----------------------| Router misses a heartbeat 3184 | X<----------------------| Router misses too many heartbeats 3185 | 3186 | 3187 |------Session Termination------>| Router sends Session Termination 3188 | Message with 'Timeout' Status 3189 | Data Item. 3190 : 3191 : Termination proceeds... 3193 B.9. Modem Detects a Heartbeat timeout 3195 Router Modem Message Description 3196 ======================================================================== 3198 |---------------------->X Modem misses a heartbeat 3200 |---------------------->X | Modem misses too many heartbeats 3201 | 3202 | 3203 |<-----Session Termination-------| Modem sends Session Termination 3204 | Message with 'Timeout' Status 3205 | Data Item. 3206 : 3207 : Termination proceeds... 3209 Appendix C. Destination Specific Message Flows 3211 C.1. Common Destination Notification 3212 Router Modem Message Description 3213 ======================================================================== 3215 | Modem detects a new logical 3216 | destination is reachable, and 3217 |<-------Destination Up----------| sends Destination Up Message. 3218 | 3219 |------Destination Up Resp.----->| Router sends Destination Up 3220 | Response. 3222 ~ ~ ~ ~ ~ ~ ~ 3223 | Modem detects change in logical 3224 | destination metrics, and sends 3225 |<-------Destination Update------| Destination Update Message. 3227 ~ ~ ~ ~ ~ ~ ~ 3228 | Modem detects change in logical 3229 | destination metrics, and sends 3230 |<-------Destination Update------| Destination Update Message. 3232 ~ ~ ~ ~ ~ ~ ~ 3233 | Modem detects logical destination 3234 | is no longer reachable, and sends 3235 |<-------Destination Down--------| Destination Down Message. 3236 | 3237 | Router receives Destination Down, 3238 | updates internal state, and sends 3239 |------Destination Down Resp.--->| Destination Down Response Message. 3241 C.2. Multicast Destination Notification 3242 Router Modem Message Description 3243 ======================================================================== 3245 | Router detects a new multicast 3246 | destination is in use, and sends 3247 |-----Destination Announce------>| Destination Announce Message. 3248 | 3249 | Modem updates internal state to 3250 | monitor multicast destination, and 3251 |<-----Dest. Announce Resp.------| sends Destination Announce 3252 Response. 3254 ~ ~ ~ ~ ~ ~ ~ 3255 | Modem detects change in multicast 3256 | destination metrics, and sends 3257 |<-------Destination Update------| Destination Update Message. 3259 ~ ~ ~ ~ ~ ~ ~ 3260 | Modem detects change in multicast 3261 | destination metrics, and sends 3262 |<-------Destination Update------| Destination Update Message. 3264 ~ ~ ~ ~ ~ ~ ~ 3265 | Router detects multicast 3266 | destination is no longer in use, 3267 |--------Destination Down------->| and sends Destination Down 3268 | Message. 3269 | 3270 | Modem receives Destination Down, 3271 | updates internal state, and sends 3272 |<-----Destination Down Resp.----| Destination Down Response Message. 3274 C.3. Link Characteristics Request 3275 Router Modem Message Description 3276 ======================================================================== 3278 Destination has already been 3279 ~ ~ ~ ~ ~ ~ ~ announced by either peer. 3281 | Router requires different 3282 | Characteristics for the 3283 | destination, and sends Link 3284 |--Link Characteristics Request->| Characteristics Request Message. 3285 | 3286 | Modem attempts to adjust link 3287 | properties to meet the received 3288 | request, and sends a Link 3289 | Characteristics Response 3290 |<---Link Characteristics Resp.--| Message with the new values. 3292 Authors' Addresses 3294 Stan Ratliff 3295 VT iDirect 3296 13861 Sunrise Valley Drive, Suite 300 3297 Herndon, VA 20171 3298 USA 3300 Email: sratliff@idirect.net 3302 Shawn Jury 3303 Cisco Systems 3304 170 West Tasman Drive 3305 San Jose, CA 95134 3306 USA 3308 Email: sjury@cisco.com 3310 Darryl Satterwhite 3311 Broadcom 3313 Email: dsatterw@broadcom.com 3314 Rick Taylor 3315 Airbus Defence & Space 3316 Quadrant House 3317 Celtic Springs 3318 Coedkernew 3319 Newport NP10 8FZ 3320 UK 3322 Email: rick.taylor@airbus.com 3324 Bo Berry