idnits 2.17.1 draft-ietf-manet-dlep-25.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 (October 28, 2016) is 2738 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 2957, but no explicit reference was found in the text == 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) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networks Working Group S. Ratliff 3 Internet-Draft VT iDirect 4 Intended status: Standards Track S. Jury 5 Expires: May 1, 2017 Cisco Systems 6 D. Satterwhite 7 Broadcom 8 R. Taylor 9 Airbus Defence & Space 10 B. Berry 11 October 28, 2016 13 Dynamic Link Exchange Protocol (DLEP) 14 draft-ietf-manet-dlep-25 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 May 1, 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 . . . . . . . . 15 76 6. Transaction Model . . . . . . . . . . . . . . . . . . . . . . 15 77 7. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 7.1. Experiments . . . . . . . . . . . . . . . . . . . . . . . 16 79 8. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . 21 88 10.4. Peer Offer Signal . . . . . . . . . . . . . . . . . . . 21 89 10.5. Session Initialization Message . . . . . . . . . . . . . 22 90 10.6. Session Initialization Response Message . . . . . . . . 23 91 10.7. Session Update Message . . . . . . . . . . . . . . . . . 24 92 10.8. Session Update Response Message . . . . . . . . . . . . 26 93 10.9. Session Termination Message . . . . . . . . . . . . . . 26 94 10.10. Session Termination Response Message . . . . . . . . . . 26 95 10.11. Destination Up Message . . . . . . . . . . . . . . . . . 27 96 10.12. Destination Up Response Message . . . . . . . . . . . . 28 97 10.13. Destination Announce Message . . . . . . . . . . . . . . 29 98 10.14. Destination Announce Response Message . . . . . . . . . 29 99 10.15. Destination Down Message . . . . . . . . . . . . . . . . 31 100 10.16. Destination Down Response Message . . . . . . . . . . . 31 101 10.17. Destination Update Message . . . . . . . . . . . . . . . 31 102 10.18. Link Characteristics Request Message . . . . . . . . . . 33 103 10.19. Link Characteristics Response Message . . . . . . . . . 33 104 10.20. Heartbeat Message . . . . . . . . . . . . . . . . . . . 34 105 11. DLEP Data Items . . . . . . . . . . . . . . . . . . . . . . . 35 106 11.1. Status . . . . . . . . . . . . . . . . . . . . . . . . . 36 107 11.2. IPv4 Connection Point . . . . . . . . . . . . . . . . . 39 108 11.3. IPv6 Connection Point . . . . . . . . . . . . . . . . . 40 109 11.4. Peer Type . . . . . . . . . . . . . . . . . . . . . . . 41 110 11.5. Heartbeat Interval . . . . . . . . . . . . . . . . . . . 41 111 11.6. Extensions Supported . . . . . . . . . . . . . . . . . . 42 112 11.7. MAC Address . . . . . . . . . . . . . . . . . . . . . . 42 113 11.8. IPv4 Address . . . . . . . . . . . . . . . . . . . . . . 43 114 11.8.1. IPv4 Address Processing . . . . . . . . . . . . . . 44 115 11.9. IPv6 Address . . . . . . . . . . . . . . . . . . . . . . 45 116 11.9.1. IPv6 Address Processing . . . . . . . . . . . . . . 46 117 11.10. IPv4 Attached Subnet . . . . . . . . . . . . . . . . . . 47 118 11.10.1. IPv4 Attached Subnet Processing . . . . . . . . . . 48 119 11.11. IPv6 Attached Subnet . . . . . . . . . . . . . . . . . . 48 120 11.11.1. IPv6 Attached Subnet Processing . . . . . . . . . . 50 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 . . . . . . . . . . . . . . . . . . . . . 57 132 13.1. Registrations . . . . . . . . . . . . . . . . . . . . . 57 133 13.2. Signal Type Registration . . . . . . . . . . . . . . . . 57 134 13.3. Message Type Registration . . . . . . . . . . . . . . . 58 135 13.4. DLEP Data Item Registrations . . . . . . . . . . . . . . 59 136 13.5. DLEP Status Code Registrations . . . . . . . . . . . . . 59 137 13.6. DLEP Extensions Registrations . . . . . . . . . . . . . 60 138 13.7. DLEP IPv4 Connection Point Flags . . . . . . . . . . . . 60 139 13.8. DLEP IPv6 Connection Point Flags . . . . . . . . . . . . 61 140 13.9. DLEP IPv4 Address Flag . . . . . . . . . . . . . . . . . 61 141 13.10. DLEP IPv6 Address Flag . . . . . . . . . . . . . . . . . 61 142 13.11. DLEP IPv4 Attached Subnet Flag . . . . . . . . . . . . . 62 143 13.12. DLEP IPv6 Attached Subnet Flag . . . . . . . . . . . . . 62 144 13.13. DLEP Well-known Port . . . . . . . . . . . . . . . . . . 62 145 13.14. DLEP IPv4 Link-local Multicast Address . . . . . . . . . 63 146 13.15. DLEP IPv6 Link-local Multicast Address . . . . . . . . . 63 147 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 63 148 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 63 149 15.1. Normative References . . . . . . . . . . . . . . . . . . 63 150 15.2. Informative References . . . . . . . . . . . . . . . . . 63 151 Appendix A. Discovery Signal Flows . . . . . . . . . . . . . . . 64 152 Appendix B. Peer Level Message Flows . . . . . . . . . . . . . . 65 153 B.1. Session Initialization . . . . . . . . . . . . . . . . . 65 154 B.2. Session Initialization - Refused . . . . . . . . . . . . 65 155 B.3. Router Changes IP Addresses . . . . . . . . . . . . . . . 66 156 B.4. Modem Changes Session-wide Metrics . . . . . . . . . . . 66 157 B.5. Router Terminates Session . . . . . . . . . . . . . . . . 67 158 B.6. Modem Terminates Session . . . . . . . . . . . . . . . . 67 159 B.7. Session Heartbeats . . . . . . . . . . . . . . . . . . . 68 160 B.8. Router Detects a Heartbeat timeout . . . . . . . . . . . 69 161 B.9. Modem Detects a Heartbeat timeout . . . . . . . . . . . . 70 162 Appendix C. Destination Specific Message Flows . . . . . . . . . 70 163 C.1. Common Destination Notification . . . . . . . . . . . . . 70 164 C.2. Multicast Destination Notification . . . . . . . . . . . 71 165 C.3. Link Characteristics Request . . . . . . . . . . . . . . 72 166 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73 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]. 398 DLEP specifies UDP multicast for single-hop discovery signaling, and 399 TCP for transport of the Messages. Modems and routers participating 400 in DLEP sessions MUST have topologically consistent IP addresses 401 assigned. It is RECOMMENDED that DLEP implementations utilize IPv6 402 link-local addresses to reduce the administrative burden of address 403 assignment. If the router and modem support both IPv4 and IPv6, the 404 IPv6 transport MUST be used for the DLEP session. 406 To enforce the single Layer 2 domain for DLEP Messages, 407 implementations MUST adhere to the Generalized TTL Security Mechanism 408 documented in [RFC5082] for all TCP-based DLEP Messages. 410 In order to keep the DLEP discovery Signals, which are multicast UDP- 411 based, limited to the same Layer 2 domain, implementations MUST set 412 the TTL of all DLEP Signals to 1, and MUST check for TTL = 1 on 413 receipt of DLEP Signals. Any signal received with a TTL not equal to 414 1 MUST be discarded. 416 DLEP relies on the guaranteed delivery of its Messages between router 417 and modem, once the 1 hop discovery process is complete, hence, the 418 specification of TCP to carry the Messages. Other reliable 419 transports for the protocol are possible, but are outside the scope 420 of this document. 422 DLEP further requires that security of the implementations (e.g., 423 authentication of stations, encryption of traffic, or both) is dealt 424 with by utilizing Layer 2 security techniques. This reliance on 425 Layer 2 mechanisms secures all DLEP Messages - both the UDP discovery 426 Signals and the TCP control Messages. 428 4. Metrics 430 DLEP includes the ability for the router and modem to communicate 431 metrics that reflect the characteristics (e.g., datarate, latency) of 432 the variable-quality link in use. DLEP does not specify how a given 433 metric value is to be calculated, rather, the protocol assumes that 434 metrics have been calculated by a 'best effort', incorporating all 435 pertinent data that is available to the modem device. Metrics based 436 on large enough sample sizes will preclude short traffic bursts from 437 adversely skewing reported values. 439 DLEP allows for metrics to be sent within two contexts - metrics for 440 a specific destination within the network (e.g., a specific router), 441 and per-session (those that apply to all destinations accessed via 442 the modem). Most metrics can be further subdivided into transmit and 443 receive metrics. In cases where metrics are provided at session 444 level, the router propagates the metrics to all entries in its 445 information base for destinations that are accessed via the modem. 447 DLEP modems announce all metric Data Items that will be reported 448 during the session, and provide default values for those metrics, in 449 the Session Initialization Response Message (Section 10.6). In order 450 to use a metric type that was not included in the Session 451 Initialization Response Message, modem implementations terminate the 452 session with the router (via the Session Terminate Message 453 (Section 10.9)), and establish a new session. 455 A DLEP modem can send metrics both in a session context, via the 456 Session Update Message (Section 10.7), and a specific destination 457 context, via the Destination Update Message (Section 10.17), at any 458 time. The most recently received metric value takes precedence over 459 any earlier value, regardless of context - that is: 461 1. If the router receives metrics in a specific destination context 462 (via the Destination Update Message), then the specific 463 destination is updated with the new metric. 465 2. If the router receives metrics in a session-wide context (via the 466 Session Update Message), then the metrics for all destinations 467 accessed via the modem are updated with the new metric. 469 It is left to implementations to choose sensible default values based 470 on their specific characteristics. Modems having static (non- 471 changing) link metric characteristics can report metrics only once 472 for a given destination (or once on a session-wide basis, if all 473 connections via the modem are of this static nature). 475 In addition to communicating existing metrics about the link, DLEP 476 provides a Message allowing a router to request a different datarate 477 or latency from the modem. This Message is the Link Characteristics 478 Request Message (Section 10.18), and gives the router the ability to 479 deal with requisite increases (or decreases) of allocated datarate/ 480 latency in demand-based schemes in a more deterministic manner. 482 5. DLEP Session Flow 484 All DLEP participants of a session transition through a number of 485 distinct states during the lifetime of a DLEP session: 487 o Peer Discovery 489 o Session Initialization 491 o In-Session 493 o Session Termination 495 o Session Reset 497 Modems, and routers supporting DLEP discovery, transition through all 498 five (5) of the above states. Routers that rely on preconfigured TCP 499 address/port information start in the Session Initialization state. 501 Modems MUST support the Peer Discovery state. 503 5.1. Peer Discovery State 505 In the Peer Discovery state, routers that support DLEP discovery MUST 506 send Peer Discovery Signals (Section 10.3) to initiate modem 507 discovery. 509 The router implementation then waits for a Peer Offer Signal 510 (Section 10.4) response from a potential DLEP modem. While in the 511 Peer Discovery state, Peer Discovery Signals MUST be sent repeatedly 512 by a DLEP router, at regular intervals. The interval MUST be a 513 minimum of one second; it SHOULD be a configurable parameter. Note 514 that this operation (sending Peer Discovery and waiting for Peer 515 Offer) is outside the DLEP Transaction Model (Section 6), as the 516 Transaction Model only describes Messages on a TCP session. 518 Routers receiving a Peer Offer Signal MUST use one of the modem 519 address/port combinations from the Peer Offer Signal to establish a 520 TCP connection to the modem, even if a priori configuration exists. 521 If multiple connection point Data Items exist in the received Peer 522 Offer Signal, routers MUST prioritize IPv6 connection points over 523 IPv4 connection points. If multiple connection points exist with the 524 same transport (e.g. IPv6 or IPv4), implementations MAY use their 525 own heuristics to determine the order in which they are tried. If a 526 TCP connection cannot be achieved using any of the address/port 527 combinations and the Discovery mechanism is in use, then the router 528 SHOULD resume issuing Peer Discovery Signals. If no Connection Point 529 Data Items are included in the Peer Offer Signal, the router MUST use 530 the source address of the UDP packet containing the Peer Offer Signal 531 as the IP address, and the DLEP well-known port number. 533 In the Peer Discovery state, the modem implementation MUST listen for 534 incoming Peer Discovery Signals on the DLEP well-known IPv6 and/or 535 IPv4 link-local multicast address and port. On receipt of a valid 536 Peer Discovery Signal, it MUST reply with a Peer Offer Signal. 538 Modems MUST be prepared to accept a TCP connection from a router that 539 is not using the Discovery mechanism, i.e. a connection attempt that 540 occurs without a preceding Peer Discovery Signal. 542 Upon establishment of a TCP connection, both modem and router enter 543 the Session Initialization state. It is up to the router 544 implementation if Peer Discovery Signals continue to be sent after 545 the device has transitioned to the Session Initialization state. 546 Modem implementations MUST silently ignore Peer Discovery Signals 547 from a router with which it already has a TCP connection. 549 5.2. Session Initialization State 551 On entering the Session Initialization state, the router MUST send a 552 Session Initialization Message (Section 10.5) to the modem. The 553 router MUST then wait for receipt of a Session Initialization 554 Response Message (Section 10.6) from the modem. Receipt of the 555 Session Initialization Response Message containing a Status Data Item 556 (Section 11.1) with status code set to 0 'Success', see Table 2, 557 indicates that the modem has received and processed the Session 558 Initialization Message, and the router MUST transition to the In- 559 Session state. 561 On entering the Session Initialization state, the modem MUST wait for 562 receipt of a Session Initialization Message from the router. Upon 563 receipt of a Session Initialization Message, the modem MUST send a 564 Session Initialization Response Message, and the session MUST 565 transition to the In-Session state. If the modem receives any 566 Message other than Session Initialization, or it fails to parse the 567 received Message, it MUST NOT send any Message, and MUST terminate 568 the TCP connection and transition to the Session Reset state. 570 DLEP provides an extension negotiation capability to be used in the 571 Session Initialization state, see Section 3. Extensions supported by 572 an implementation MUST be declared to potential DLEP participants 573 using the Extensions Supported Data Item (Section 11.6). Once both 574 DLEP participants have exchanged initialization Messages, an 575 implementation MUST NOT emit any Message, Signal, Data Item or status 576 code associated with an extension that was not specified in the 577 received initialization Message from its peer. 579 5.3. In-Session State 581 In the In-Session state, Messages can flow in both directions between 582 DLEP participants, indicating changes to the session state, the 583 arrival or departure of reachable destinations, or changes of the 584 state of the links to the destinations. 586 The In-Session state is maintained until one of the following 587 conditions occur: 589 o The implementation terminates the session by sending a Session 590 Termination Message (Section 10.9), or, 592 o Its peer terminates the session, indicated by receiving a Session 593 Termination Message. 595 The implementation MUST then transition to the Session Termination 596 state. 598 5.3.1. Heartbeats 600 In order to maintain the In-Session state, periodic Heartbeat 601 Messages (Section 10.20) MUST be exchanged between router and modem. 602 These Messages are intended to keep the session alive, and to verify 603 bidirectional connectivity between the two DLEP participants. 605 Each DLEP participant is responsible for the creation of Heartbeat 606 Messages. 608 Receipt of any valid DLEP Message MUST reset the heartbeat interval 609 timer (i.e., valid DLEP Messages take the place of, and obviate the 610 need for, additional Heartbeat Messages). 612 Implementations MUST allow a minimum of two (2) heartbeat intervals 613 to expire with no Messages from its peer before terminating the 614 session. When terminating the session, a Session Termination Message 615 containing a Status Data Item (Section 11.1) with status code set to 616 132 'Timed Out', see Table 2, MUST be sent, and then the 617 implementation MUST transition to the Session Termination state. 619 5.4. Session Termination State 621 When an implementation enters the Session Termination state after 622 sending a Session Termination Message (Section 10.9) as the result of 623 an invalid Message or error, it MUST wait for a Session Termination 624 Response Message (Section 10.10) from its peer. Senders SHOULD allow 625 four (4) heartbeat intervals to expire before assuming that its peer 626 is unresponsive, and continuing with session termination. Any other 627 Message received while waiting MUST be silently ignored. 629 When the sender of the Session Termination Message receives a Session 630 Termination Response Message from its peer, or times out, it MUST 631 transition to the Session Reset state. 633 When an implementation receives a Session Termination Message from 634 its peer, it enters the Session Termination state and then it MUST 635 immediately send a Session Termination Response and transition to the 636 Session Reset state. 638 5.5. Session Reset state 640 In the Session Reset state the implementation MUST perform the 641 following actions: 643 o Release all resources allocated for the session. 645 o Eliminate all destinations in the information base represented by 646 the session. Destination Down Messages (Section 10.15) MUST NOT 647 be sent. 649 o Terminate the TCP connection. 651 Having completed these actions the implementation SHOULD return to 652 the relevant initial state: Peer Discovery for modems; either Peer 653 Discovery or Session Initialization for routers, depending on 654 configuration. 656 5.5.1. Unexpected TCP connection termination 658 If the TCP connection between DLEP participants is terminated when an 659 implementation is not in the Session Reset state, the implementation 660 MUST immediately transition to the Session Reset state. 662 6. Transaction Model 664 DLEP defines a simple Message transaction model: Only one request per 665 destination may be in progress at a time per session. A Message 666 transaction is considered complete when a response matching a 667 previously issued request is received. If a DLEP participant 668 receives a request for a destination for which there is already an 669 outstanding request, the implementation MUST terminate the session by 670 issuing a Session Termination Message (Section 10.9) containing a 671 Status Data Item (Section 11.1) with status code set to 129 672 'Unexpected Message', see Table 2, and transition to the Session 673 Termination state. There is no restriction to the total number of 674 Message transactions in progress at a time, as long as each 675 transaction refers to a different destination. 677 It should be noted that some requests may take a considerable amount 678 of time for some DLEP participants to complete, for example, a modem 679 handling a multicast destination up request may have to perform a 680 complex network reconfiguration. A sending implementation MUST be 681 able to handle such long running transactions gracefully. 683 Additionally, only one session request, e.g. a Session Initialization 684 Message (Section 10.5), may be in progress at a time per session. As 685 above, a session transaction is considered complete when a response 686 matching a previously issued request is received. If a DLEP 687 participant receives a session request while there is already a 688 session request in progress, it MUST terminate the session by issuing 689 a Session Termination Message containing a Status Data Item with 690 status code set to 129 'Unexpected Message', and transition to the 691 Session Termination state. Only the Session Termination Message may 692 be issued when a session transaction is in progress. Heartbeat 693 Messages (Section 10.20) MUST NOT be considered part of a session 694 transaction. 696 DLEP transactions do not time out and are not cancellable. An 697 implementation can detect if its peer has failed in some way by use 698 of the session heartbeat mechanism during the In-Session state, see 699 Section 5.3. 701 7. Extensions 703 Extensions MUST be negotiated on a per-session basis during session 704 initialization via the Extensions Supported mechanism. 705 Implementations are not required to support any extension in order to 706 be considered DLEP compliant. An extension document, describing the 707 operation of a credit windowing scheme for flow control, is described 708 in [CREDIT]. 710 If interoperable protocol extensions are required, they will need to 711 be standardized either as an update to this document, or as an 712 additional stand-alone specification. The requests for IANA- 713 controlled registries in this document contain sufficient Reserved 714 space for DLEP Signals, Messages, Data Items and status codes to 715 accommodate future extensions to the protocol. 717 As multiple protocol extensions MAY be announced during session 718 initialization, authors of protocol extensions need to consider the 719 interaction of their extension with other published extensions, and 720 specify any incompatibilities. 722 7.1. Experiments 724 This document requests Private Use numbering space in the DLEP 725 Signal, Message, Data Item and status code registries for 726 experimental extensions. The intent is to allow for experimentation 727 with new Signals, Messages, Data Items, and/or status codes, while 728 still retaining the documented DLEP behavior. 730 Use of the Private Use Signals, Messages, Data Items, status codes, 731 or behaviors MUST be announced as DLEP Extensions, during session 732 initialization, using extension identifiers from the Private Use 733 space in the Extensions Supported registry (Table 3), with a value 734 agreed upon (a priori) between the participants. DLEP extensions 735 using the Private Use numbering space are commonly referred to as 736 Experiments. 738 Multiple experiments MAY be announced in the Session Initialization 739 Messages. However, use of multiple experiments in a single session 740 could lead to interoperability issues or unexpected results (e.g., 741 clashes of experimental Signals, Messages, Data Items and/or status 742 code types), and is therefore discouraged. It is left to 743 implementations to determine the correct processing path (e.g., a 744 decision on whether to terminate the session, or to establish a 745 precedence of the conflicting definitions) if such conflicts arise. 747 8. Scalability 749 The protocol is intended to support thousands of destinations on a 750 given modem/router pair. At large scale, implementations SHOULD 751 consider employing techniques to prevent flooding its peer with a 752 large number of Messages in a short time. For example, a dampening 753 algorithm could be employed to prevent a flapping device from 754 generating a large number of Destination Up/Destination Down 755 Messages. 757 Also, use of techniques such as a hysteresis can lessen the impact of 758 rapid, minor fluctuations in link quality. The specific algorithms 759 for handling flapping destinations and minor changes in link quality 760 are outside the scope of this specification. 762 9. DLEP Signal and Message Structure 764 DLEP defines two protocol units used in two different ways: Signals 765 and Messages. Signals are only used in the Discovery mechanism and 766 are carried in UDP datagrams. Messages are used bi-directionally 767 over a TCP connection between the participants, in the Session 768 Initialization, In-Session and Session Termination states. 770 Both Signals and Messages consist of a Header followed by an 771 unordered list of Data Items. Headers consist of Type and Length 772 information, while Data Items are encoded as TLV (Type-Length-Value) 773 structures. In this document, the Data Items following a Signal or 774 Message Header are described as being 'contained in' the Signal or 775 Message. 777 There is no restriction on the order of Data Items following a 778 Header, and the acceptability of duplicate Data Items is defined by 779 the definition of the Signal or Message declared by the type in the 780 Header. 782 All integers in Header fields and values MUST be in network byte- 783 order. 785 9.1. DLEP Signal Header 787 The DLEP Signal Header contains the following fields: 789 0 1 2 3 790 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 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | 'D' | 'L' | 'E' | 'P' | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | Signal Type | Length | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 Figure 3: DLEP Signal Header 799 "DLEP": Every Signal MUST start with the characters: U+0044, U+004C, 800 U+0045, U+0050. 802 Signal Type: A 16-bit unsigned integer containing one of the DLEP 803 Signal Type values defined in this document. 805 Length: The length in octets, expressed as a 16-bit unsigned 806 integer, of all of the DLEP Data Items contained in this Signal. 807 This length MUST NOT include the length of the Signal Header 808 itself. 810 The DLEP Signal Header is immediately followed by zero or more DLEP 811 Data Items, encoded in TLVs, as defined in this document. 813 9.2. DLEP Message Header 815 The DLEP Message Header contains the following fields: 817 0 1 2 3 818 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 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 | Message Type | Length | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 Figure 4: DLEP Message Header 825 Message Type: A 16-bit unsigned integer containing one of the DLEP 826 Message Type values defined in this document. 828 Length: The length in octets, expressed as a 16-bit unsigned 829 integer, of all of the DLEP Data Items contained in this Message. 830 This length MUST NOT include the length of the Message Header 831 itself. 833 The DLEP Message Header is immediately followed by zero or more DLEP 834 Data Items, encoded in TLVs, as defined in this document. 836 9.3. DLEP Generic Data Item 838 All DLEP Data Items contain the following fields: 840 0 1 2 3 841 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 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | Data Item Type | Length | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | Value... : 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 Figure 5: DLEP Generic Data Item 850 Data Item Type: A 16-bit unsigned integer field specifying the type 851 of Data Item being sent. 853 Length: The length in octets, expressed as a 16-bit unsigned 854 integer, of the Value field of the Data Item. This length MUST 855 NOT include the length of the Data Item Type and Length fields. 857 Value: A field of octets, which contains data specific to a 858 particular Data Item. 860 10. DLEP Signals and Messages 862 10.1. General Processing Rules 864 If an unrecognized, or unexpected Signal is received, or a received 865 Signal contains unrecognized, invalid, or disallowed duplicate Data 866 Items, the receiving implementation MUST ignore the Signal. 868 If a Signal is received with a TTL value that is NOT equal to 1, the 869 receiving implementation MUST ignore the Signal. 871 If an unrecognized Message is received, the receiving implementation 872 MUST issue a Session Termination Message (Section 10.9) containing a 873 Status Data Item (Section 11.1) with status code set to 128 'Unknown 874 Message', see Table 2, and transition to the Session Termination 875 state. 877 If an unexpected Message is received, the receiving implementation 878 MUST issue a Session Termination Message containing a Status Data 879 Item with status code set to 129 'Unexpected Message', and transition 880 to the Session Termination state. 882 If a received Message contains unrecognized, invalid, or disallowed 883 duplicate Data Items, the receiving implementation MUST issue a 884 Session Termination Message containing a Status Data Item with status 885 code set to 130 'Invalid Data', and transition to the Session 886 Termination state. 888 If a packet in the TCP stream is received with a TTL value other than 889 255, the receiving implementation MUST immediately transition to the 890 Session Reset state. 892 Prior to the exchange of Destination Up (Section 10.11) and 893 Destination Up Response (Section 10.12) Messages, or Destination 894 Announce (Section 10.13) and Destination Announce Response 895 (Section 10.14) Messages, no Messages concerning a destination may be 896 sent. An implementation receiving any Message with such an 897 unannounced destination MUST terminate the session by issuing a 898 Session Termination Message containing a Status Data Item with status 899 code set to 131 'Invalid Destination', and transition to the Session 900 Termination state. 902 After exchanging Destination Down (Section 10.15) and Destination 903 Down Response (Section 10.16) Messages, no Messages concerning a 904 destination may be a sent until a new Destination Up or Destination 905 Announce Message is sent. An implementation receiving a Message 906 about a destination previously announced as 'down' MUST terminate the 907 session by issuing a Session Termination Message containing a Status 908 Data Item with status code set to 131 'Invalid Destination', and 909 transition to the Session Termination state. 911 10.2. Status code processing 913 The behaviour of a DLEP participant receiving a Message containing a 914 Status Data Item (Section 11.1) is defined by the failure mode 915 associated with the value of the status code field, see Table 2. All 916 status code values less than 100 have a failure mode of 'Continue', 917 all other status codes have a failure mode of 'Terminate'. 919 A DLEP participant receiving any Message apart from Session 920 Termination Message (Section 10.9) containing a Status Data Item with 921 a status code value with failure mode 'Terminate' MUST immediately 922 issue a Session Termination Message containing an identical Status 923 Data Item, and then transition to the Session Termination state. 925 A DLEP participant receiving a Message containing a Status Data Item 926 with a status code value with failure mode 'Continue' can continue 927 normal operation of the session. 929 10.3. Peer Discovery Signal 931 A Peer Discovery Signal SHOULD be sent by a DLEP router to discover 932 DLEP modems in the network, see Section 5.1. 934 A Peer Discovery Signal MUST be encoded within a UDP packet. The 935 destination MUST be set to the DLEP well-known address and port 936 number. For routers supporting both IPv4 and IPv6 DLEP operation, it 937 is RECOMMENDED that IPv6 be selected as the transport. The source IP 938 address MUST be set to the router IP address associated with the DLEP 939 interface. There is no DLEP-specific restriction on source port. 941 To construct a Peer Discovery Signal, the Signal Type value in the 942 Signal Header is set to 1 (see Signal Type Registration 943 (Section 13.2)). 945 The Peer Discovery Signal MAY contain a Peer Type Data Item 946 (Section 11.4). 948 10.4. Peer Offer Signal 950 A Peer Offer Signal MUST be sent by a DLEP modem in response to a 951 properly formatted and addressed Peer Discovery Signal 952 (Section 10.3). 954 A Peer Offer Signal MUST be encoded within a UDP packet. The IP 955 destination MUST be set to the IP address and port number received in 956 the corresponding Peer Discovery Signal. The source IP address MUST 957 be set to the modem's IP address associated with the DLEP interface. 958 The source port number MUST be set to the DLEP well-known port 959 number. The Peer Offer Signal completes the discovery process, see 960 Section 5.1. 962 To construct a Peer Offer Signal, the Signal Type value in the Signal 963 Header is set to 2 (see Signal Type Registration (Section 13.2)). 965 The Peer Offer Signal MAY contain a Peer Type Data Item 966 (Section 11.4). 968 The Peer Offer Signal MAY contain one or more of any of the following 969 Data Items, with different values: 971 o IPv4 Connection Point (Section 11.2) 973 o IPv6 Connection Point (Section 11.3) 975 The IP Connection Point Data Items indicate the unicast address the 976 router MUST use when connecting the DLEP TCP session. 978 10.5. Session Initialization Message 980 A Session Initialization Message MUST be sent by a DLEP router as the 981 first Message of the DLEP TCP session. It is sent by the router 982 after a TCP connect to an address/port combination that was obtained 983 either via receipt of a Peer Offer, or from a priori configuration. 985 To construct a Session Initialization Message, the Message Type value 986 in the Message Header is set to 1 (see Message Type Registration 987 (Section 13.3)). 989 The Session Initialization Message MUST contain a Heartbeat Interval 990 Data Item (Section 11.5). 992 The Session Initialization Message MAY contain one of each of the 993 following Data Items: 995 o Peer Type (Section 11.4) 997 o Extensions Supported (Section 11.6) 999 The Session Initialization Message MAY contain one or more of each of 1000 the following Data Items, with different values, and the data item 1001 Add flag set to 1: 1003 o IPv4 Address (Section 11.8) 1005 o IPv6 Address (Section 11.9) 1007 o IPv4 Attached Subnet (Section 11.10) 1009 o IPv6 Attached Subnet (Section 11.11) 1011 If any optional extensions are supported by the implementation, they 1012 MUST be enumerated in the Extensions Supported Data Item. If an 1013 Extensions Supported Data Item does not exist in a Session 1014 Initialization Message, the modem MUST conclude that there is no 1015 support for extensions in the router. 1017 DLEP Heartbeats are not fully established until receipt of the 1018 Session Initialization Response Message (Section 10.6), and therefore 1019 implementations MUST use their own timeout and retry heuristics for 1020 this Message. 1022 As an exception to the general rule governing an implementation 1023 receiving an unrecognized Data Item in a Message, see Section 10.1, 1024 if a Session Initialization Message contains one or more Extension 1025 Supported Data Items announcing support for extensions that the 1026 implementation does not recognize, then the implementation MAY ignore 1027 Data Items it does not recognize. 1029 10.6. Session Initialization Response Message 1031 A Session Initialization Response Message MUST be sent by a DLEP 1032 modem in response to a received Session Initialization Message 1033 (Section 10.5). 1035 To construct a Session Initialization Response Message, the Message 1036 Type value in the Message Header is set to 2 (see Message Type 1037 Registration (Section 13.3)). 1039 The Session Initialization Response Message MUST contain one of each 1040 of the following Data Items: 1042 o Status (Section 11.1) 1044 o Heartbeat Interval (Section 11.5) 1046 o Maximum Data Rate (Receive) (Section 11.12) 1048 o Maximum Data Rate (Transmit) (Section 11.13) 1050 o Current Data Rate (Receive) (Section 11.14) 1052 o Current Data Rate (Transmit) (Section 11.15) 1054 o Latency (Section 11.16) 1056 The Session Initialization Response Message MUST contain one of each 1057 of the following Data Items, if the Data Item will be used during the 1058 lifetime of the session: 1060 o Resources (Section 11.17) 1062 o Relative Link Quality (Receive) (Section 11.18) 1064 o Relative Link Quality (Transmit) (Section 11.19) 1066 o Maximum Transmission Unit (MTU) (Section 11.20) 1068 The Session Initialization Response Message MUST contain an 1069 Extensions Supported Data Item (Section 11.6), if DLEP extensions are 1070 supported. 1072 The Session Initialization Response Message MAY contain a Peer Type 1073 Data Item (Section 11.4). 1075 The Session Initialization Response Message MAY contain one or more 1076 of each of the following Data Items, with different values, and the 1077 data item Add flag set to 1: 1079 o IPv4 Address (Section 11.8) 1081 o IPv6 Address (Section 11.9) 1083 o IPv4 Attached Subnet (Section 11.10) 1085 o IPv6 Attached Subnet (Section 11.11) 1087 The Session Initialization Response Message completes the DLEP 1088 session establishment; the modem should transition to the In-Session 1089 state when the Message is sent, and the router should transition to 1090 the In-Session state upon receipt of an acceptable Session 1091 Initialization Response Message. 1093 All supported metric Data Items MUST be included in the Session 1094 Initialization Response Message, with default values to be used on a 1095 session-wide basis. This can be viewed as the modem 'declaring' all 1096 supported metrics at DLEP session initialization. Receipt of any 1097 further DLEP Message containing a metric Data Item not included in 1098 the Session Initialization Response Message MUST be treated as an 1099 error, resulting in the termination of the DLEP session between 1100 router and modem. 1102 If any optional extensions are supported by the modem, they MUST be 1103 enumerated in the Extensions Supported Data Item. If an Extensions 1104 Supported Data Item does not exist in a Session Initialization 1105 Response Message, the router MUST conclude that there is no support 1106 for extensions in the modem. 1108 After the Session Initialization/Session Initialization Response 1109 Messages have been successfully exchanged, implementations MUST only 1110 use extensions that are supported by both DLEP participants, see 1111 Section 5.2. 1113 10.7. Session Update Message 1115 A Session Update Message MAY be sent by a DLEP participant to 1116 indicate local Layer 3 address changes, or metric changes on a 1117 session-wide basis. 1119 To construct a Session Update Message, the Message Type value in the 1120 Message Header is set to 3 (see Message Type Registration 1121 (Section 13.3)). 1123 The Session Update Message MAY contain one or more of each of the 1124 following Data Items, with different values: 1126 o IPv4 Address (Section 11.8) 1128 o IPv6 Address (Section 11.9) 1130 o IPv4 Attached Subnet (Section 11.10) 1132 o IPv6 Attached Subnet (Section 11.11) 1134 When sent by a modem, the Session Update Message MAY contain one of 1135 each of the following Data Items: 1137 o Maximum Data Rate (Receive) (Section 11.12) 1139 o Maximum Data Rate (Transmit) (Section 11.13) 1141 o Current Data Rate (Receive) (Section 11.14) 1143 o Current Data Rate (Transmit) (Section 11.15) 1145 o Latency (Section 11.16) 1147 When sent by a modem, the Session Update Message MAY contain one of 1148 each of the following Data Items, if the Data Item is in use by the 1149 session: 1151 o Resources (Section 11.17) 1153 o Relative Link Quality (Receive) (Section 11.18) 1155 o Relative Link Quality (Transmit) (Section 11.19) 1157 o Maximum Transmission Unit (MTU) (Section 11.20) 1159 If metrics are supplied with the Session Update Message (e.g., 1160 Maximum Data Rate), these metrics are considered to be session-wide, 1161 and therefore MUST be applied to all destinations in the information 1162 base associated with the DLEP session. This includes destinations 1163 for which metrics may have been stored based on received Destination 1164 Update messages. 1166 It should be noted that Session Update Messages can be sent by both 1167 routers and modems. For example, addition of an IPv4 address on the 1168 router MAY prompt a Session Update Message to its attached modems. 1169 Also, for example, a modem that changes its Maximum Data Rate 1170 (Receive) for all destinations MAY reflect that change via a Session 1171 Update Message to its attached router(s). 1173 Concerning Layer 3 addresses and subnets: If the modem is capable of 1174 understanding and forwarding this information (via mechanisms not 1175 defined by DLEP), the update would prompt any remote DLEP-enabled 1176 modems to issue a Destination Update Message (Section 10.17) to their 1177 local routers with the new (or deleted) addresses and subnets. 1179 10.8. Session Update Response Message 1181 A Session Update Response Message MUST be sent by a DLEP participant 1182 when a Session Update Message (Section 10.7) is received. 1184 To construct a Session Update Response Message, the Message Type 1185 value in the Message Header is set to 4 (see Message Type 1186 Registration (Section 13.3)). 1188 The Session Update Response Message MUST contain a Status Data Item 1189 (Section 11.1). 1191 10.9. Session Termination Message 1193 A Session Termination Message MUST be sent by a DLEP participant when 1194 the DLEP session needs to be terminated. 1196 To construct a Session Termination Message, the Message Type value in 1197 the Message Header is set to 5 (see Message Type Registration 1198 (Section 13.3)). 1200 The Session Termination Message MUST contain Status Data Item 1201 (Section 11.1). 1203 It should be noted that Session Termination Messages can be sent by 1204 both routers and modems. 1206 10.10. Session Termination Response Message 1208 A Session Termination Response Message MUST be sent by a DLEP 1209 participant when a Session Termination Message (Section 10.9) is 1210 received. 1212 To construct a Session Termination Response Message, the Message Type 1213 value in the Message Header is set to 6 (see Message Type 1214 Registration (Section 13.3)). 1216 There are no valid Data Items for the Session Termination Response 1217 Message. 1219 Receipt of a Session Termination Response Message completes the tear- 1220 down of the DLEP session, see Section 5.4. 1222 10.11. Destination Up Message 1224 Destination Up Messages MAY be sent by a modem to inform its attached 1225 router of the presence of a new reachable destination. 1227 To construct a Destination Up Message, the Message Type value in the 1228 Message Header is set to 7 (see Message Type Registration 1229 (Section 13.3)). 1231 The Destination Up Message MUST contain a MAC Address Data Item 1232 (Section 11.7). 1234 The Destination Up Message SHOULD contain one or more of each of the 1235 following Data Items, with different values: 1237 o IPv4 Address (Section 11.8) 1239 o IPv6 Address (Section 11.9) 1241 The Destination Up Message MAY contain one of each of the following 1242 Data Items: 1244 o Maximum Data Rate (Receive) (Section 11.12) 1246 o Maximum Data Rate (Transmit) (Section 11.13) 1248 o Current Data Rate (Receive) (Section 11.14) 1250 o Current Data Rate (Transmit) (Section 11.15) 1252 o Latency (Section 11.16) 1254 The Destination Up Message MAY contain one of each of the following 1255 Data Items, if the Data Item is in use by the session: 1257 o Resources (Section 11.17) 1259 o Relative Link Quality (Receive) (Section 11.18) 1261 o Relative Link Quality (Transmit) (Section 11.19) 1263 o Maximum Transmission Unit (MTU) (Section 11.20) 1265 The Destination Up Message MAY contain one or more of each of the 1266 following Data Items, with different values: 1268 o IPv4 Attached Subnet (Section 11.10) 1270 o IPv6 Attached Subnet (Section 11.11) 1272 A router receiving a Destination Up Message allocates the necessary 1273 resources, creating an entry in the information base with the 1274 specifics (MAC Address, Latency, Data Rate, etc.) of the destination. 1275 The information about this destination will persist in the router's 1276 information base until a Destination Down Message (Section 10.15) is 1277 received, indicating that the modem has lost contact with the remote 1278 node, or the implementation transitions to the Session Termination 1279 state. 1281 10.12. Destination Up Response Message 1283 A router MUST send a Destination Up Response Message when a 1284 Destination Up Message (Section 10.11) is received. 1286 To construct a Destination Up Response Message, the Message Type 1287 value in the Message Header is set to 8 (see Message Type 1288 Registration (Section 13.3)). 1290 The Destination Up Response Message MUST contain one of each of the 1291 following Data Items: 1293 o MAC Address (Section 11.7) 1295 o Status (Section 11.1) 1297 A router that wishes to receive further information concerning the 1298 destination identified in the corresponding Destination Up Message 1299 MUST set the status code of the included Status Data Item to 0 1300 'Success', see Table 2. 1302 If the router has no interest in the destination identified in the 1303 corresponding Destination Up Message, then it MAY set the status code 1304 of the included Status Data Item to 1 'Not Interested'. 1306 A modem receiving a Destination Up Response Message containing a 1307 Status Data Item with status code of any value other than 0 'Success' 1308 MUST NOT send further Destination messages about the destination, 1309 e.g. Destination Down (Section 10.15) or Destination Update 1310 (Section 10.17) with the same MAC address. 1312 10.13. Destination Announce Message 1314 Usually a modem will discover the presence of one or more remote 1315 router/modem pairs and announce each destination's arrival by sending 1316 a corresponding Destination Up Message (Section 10.11) to the router. 1317 However, there may be times when a router wishes to express an 1318 interest in a destination that has yet to be announced, typically a 1319 multicast destination. Destination Announce Messages MAY be sent by 1320 a router to announce such an interest. 1322 A Destination Announce Message MAY also be sent by a router to 1323 request information concerning a destination in which it has 1324 previously declined interest, via the 1 'Not Interested' status code 1325 in a Destination Up Response Message (Section 10.12), see Table 2, or 1326 declared as 'down', via the Destination Down Message (Section 10.15). 1328 To construct a Destination Announce Message, the Message Type value 1329 in the Message Header is set to 9 (see Message Type Registration 1330 (Section 13.3)). 1332 The Destination Announce Message MUST contain a MAC Address Data Item 1333 (Section 11.7). 1335 The Destination Announce Message MAY contain zero or more of the 1336 following Data Items, with different values: 1338 o IPv4 Address (Section 11.8) 1340 o IPv6 Address (Section 11.9) 1342 One of the advantages of implementing DLEP is to leverage the modem's 1343 knowledge of the links between remote destinations allowing routers 1344 to avoid using probed neighbor discovery techniques, therefore modem 1345 implementations SHOULD announce available destinations via the 1346 Destination Up Message, rather than relying on Destination Announce 1347 Messages. 1349 10.14. Destination Announce Response Message 1351 A modem MUST send a Destination Announce Response Message when a 1352 Destination Announce Message (Section 10.13) is received. 1354 To construct a Destination Announce Response Message, the Message 1355 Type value in the Message Header is set to 10 (see Message Type 1356 Registration (Section 13.3)). 1358 The Destination Announce Response Message MUST contain one of each of 1359 the following Data Items: 1361 o MAC Address (Section 11.7) 1363 o Status (Section 11.1) 1365 The Destination Announce Response Message MAY contain one or more of 1366 each of the following Data Items, with different values: 1368 o IPv4 Address (Section 11.8) 1370 o IPv6 Address (Section 11.9) 1372 o IPv4 Attached Subnet (Section 11.10) 1374 o IPv6 Attached Subnet (Section 11.11) 1376 The Destination Announce Response Message MAY contain one of each of 1377 the following Data Items: 1379 o Maximum Data Rate (Receive) (Section 11.12) 1381 o Maximum Data Rate (Transmit) (Section 11.13) 1383 o Current Data Rate (Receive) (Section 11.14) 1385 o Current Data Rate (Transmit) (Section 11.15) 1387 o Latency (Section 11.16) 1389 The Destination Announce Response Message MAY contain one of each of 1390 the following Data Items, if the Data Item is in use by the session: 1392 o Resources (Section 11.17) 1394 o Relative Link Quality (Receive) (Section 11.18) 1396 o Relative Link Quality (Transmit) (Section 11.19) 1398 o Maximum Transmission Unit (MTU) (Section 11.20) 1400 If a modem is unable to report information immediately about the 1401 requested information, if the destination is not currently reachable, 1402 for example, the status code in the Status Data Item MUST be set to 2 1403 'Request Denied', see Table 2. 1405 After sending a Destination Announce Response Message containing a 1406 Status Data Item with status code of 0 'Success', a modem then 1407 announces changes to the link to the destination via Destination 1408 Update Messages. 1410 When a successful Destination Announce Response Message is received, 1411 the router should add knowledge of the available destination to its 1412 information base. 1414 10.15. Destination Down Message 1416 A modem MUST send a Destination Down Message to report when a 1417 destination (a remote node or a multicast group) is no longer 1418 reachable. 1420 A router MAY send a Destination Down Message to report when it no 1421 longer requires information concerning a destination. 1423 To construct a Destination Down Message, the Message Type value in 1424 the Message Header is set to 11 (see Message Type Registration 1425 (Section 13.3)). 1427 The Destination Down Message MUST contain a MAC Address Data Item 1428 (Section 11.7). 1430 It should be noted that both modem and router may send a Destination 1431 Down Message to their peer, regardless of which participant initially 1432 indicated the destination to be 'up'. 1434 10.16. Destination Down Response Message 1436 A Destination Down Response MUST be sent by the recipient of a 1437 Destination Down Message (Section 10.15) to confirm that the relevant 1438 data concerning the destination has been removed from the information 1439 base. 1441 To construct a Destination Down Response Message, the Message Type 1442 value in the Message Header is set to 12 (see Message Type 1443 Registration (Section 13.3)). 1445 The Destination Down Response Message MUST contain one of each of the 1446 following Data Items: 1448 o MAC Address (Section 11.7) 1450 o Status (Section 11.1) 1452 10.17. Destination Update Message 1454 A modem SHOULD send the Destination Update Message when it detects 1455 some change in the information base for a given destination (remote 1456 node or multicast group). Some examples of changes that would prompt 1457 a Destination Update Message are: 1459 o Change in link metrics (e.g., Data Rates) 1461 o Layer 3 addressing change 1463 To construct a Destination Update Message, the Message Type value in 1464 the Message Header is set to 13 (see Message Type Registration 1465 (Section 13.3)). 1467 The Destination Update Message MUST contain a MAC Address Data Item 1468 (Section 11.7). 1470 The Destination Update Message MAY contain one of each of the 1471 following Data Items: 1473 o Maximum Data Rate (Receive) (Section 11.12) 1475 o Maximum Data Rate (Transmit) (Section 11.13) 1477 o Current Data Rate (Receive) (Section 11.14) 1479 o Current Data Rate (Transmit) (Section 11.15) 1481 o Latency (Section 11.16) 1483 The Destination Update Message MAY contain one of each of the 1484 following Data Items, if the Data Item is in use by the session: 1486 o Resources (Section 11.17) 1488 o Relative Link Quality (Receive) (Section 11.18) 1490 o Relative Link Quality (Transmit) (Section 11.19) 1492 o Maximum Transmission Unit (MTU) (Section 11.20) 1494 The Destination Update Message MAY contain one or more of each of the 1495 following Data Items, with different values: 1497 o IPv4 Address (Section 11.8) 1499 o IPv6 Address (Section 11.9) 1501 o IPv4 Attached Subnet (Section 11.10) 1503 o IPv6 Attached Subnet (Section 11.11) 1505 If metrics are supplied with the Message (e.g., Resources), these 1506 metrics are MUST be applied to all destinations identified in the 1507 Message. Note that this may overwrite metrics provided in a 1508 previously received Session or Destination Up Messages. 1510 It should be noted that this Message has no corresponding response. 1512 10.18. Link Characteristics Request Message 1514 The Link Characteristics Request Message MAY be sent by a router to 1515 request that the modem initiate changes for specific characteristics 1516 of the link. The request can reference either a real destination 1517 (e.g., a remote node), or a logical destination (e.g., a multicast 1518 group) within the network. 1520 To construct a Link Characteristics Request Message, the Message Type 1521 value in the Message Header is set to 14 (see Message Type 1522 Registration (Section 13.3)). 1524 The Link Characteristics Request Message MUST contain one of the 1525 following Data Items: 1527 o MAC Address (Section 11.7) 1529 The Link Characteristics Request Message MUST contain at least one of 1530 each of the following Data Items: 1532 o Current Data Rate (Receive) (Section 11.14) 1534 o Current Data Rate (Transmit) (Section 11.15) 1536 o Latency (Section 11.16) 1538 The Link Characteristics Request Message MAY contain either a Current 1539 Data Rate (CDRR or CDRT) Data Item to request a different datarate 1540 than is currently allocated, a Latency Data Item to request that 1541 traffic delay on the link not exceed the specified value, or both. 1543 The router sending a Link Characteristics Request Message should be 1544 aware that a request may take an extended period of time to complete. 1546 10.19. Link Characteristics Response Message 1548 A modem MUST send a Link Characteristics Response Message when a Link 1549 Characteristics Request Message (Section 10.18) is received. 1551 To construct a Link Characteristics Response Message, the Message 1552 Type value in the Message Header is set to 15 (see Message Type 1553 Registration (Section 13.3)). 1555 The Link Characteristics Response Message MUST contain one of each of 1556 the following Data Items: 1558 o MAC Address (Section 11.7) 1560 o Status (Section 11.1) 1562 The Link Characteristics Response Message SHOULD contain one of each 1563 of the following Data Items: 1565 o Maximum Data Rate (Receive) (Section 11.12) 1567 o Maximum Data Rate (Transmit) (Section 11.13) 1569 o Current Data Rate (Receive) (Section 11.14) 1571 o Current Data Rate (Transmit) (Section 11.15) 1573 o Latency (Section 11.16) 1575 The Link Characteristics Response Message MAY contain one of each of 1576 the following Data Items, if the Data Item is in use by the session: 1578 o Resources (Section 11.17) 1580 o Relative Link Quality (Receive) (Section 11.18) 1582 o Relative Link Quality (Transmit) (Section 11.19) 1584 o Maximum Transmission Unit (MTU) (Section 11.20) 1586 The Link Characteristics Response Message MUST contain a complete set 1587 of metric Data Items, referencing all metrics declared in the Session 1588 Initialization Response Message (Section 10.6). The values in the 1589 metric Data Items in the Link Characteristics Response Message MUST 1590 reflect the link characteristics after the request has been 1591 processed. 1593 If an implementation is not able to alter the characteristics of the 1594 link in the manner requested, then the status code of the Status Data 1595 Item MUST be set to 2 'Request Denied', see Table 2. 1597 10.20. Heartbeat Message 1599 A Heartbeat Message MUST be sent by a DLEP participant every N 1600 milliseconds, where N is defined in the Heartbeat Interval Data Item 1601 (Section 11.5) of the Session Initialization Message (Section 10.5) 1602 or Session Initialization Response Message (Section 10.6). 1604 To construct a Heartbeat Message, the Message Type value in the 1605 Message Header is set to 16 (see Message Type Registration 1606 (Section 13.3)). 1608 There are no valid Data Items for the Heartbeat Message. 1610 The Message is used by DLEP participants to detect when a DLEP 1611 session peer (either the modem or the router) is no longer 1612 communicating, see Section 5.3.1. 1614 11. DLEP Data Items 1616 Following is the list of core Data Items that MUST be recognized by a 1617 DLEP compliant implementation. As mentioned before, not all Data 1618 Items need be used during a session, but an implementation MUST 1619 correctly process these Data Items when correctly associated with a 1620 Signal or Message. 1622 The core DLEP Data Items are: 1624 +-------------+-----------------------------------------------------+ 1625 | Type Code | Description | 1626 +-------------+-----------------------------------------------------+ 1627 | 0 | Reserved | 1628 | 1 | Status (Section 11.1) | 1629 | 2 | IPv4 Connection Point (Section 11.2) | 1630 | 3 | IPv6 Connection Point (Section 11.3) | 1631 | 4 | Peer Type (Section 11.4) | 1632 | 5 | Heartbeat Interval (Section 11.5) | 1633 | 6 | Extensions Supported (Section 11.6) | 1634 | 7 | MAC Address (Section 11.7) | 1635 | 8 | IPv4 Address (Section 11.8) | 1636 | 9 | IPv6 Address (Section 11.9) | 1637 | 10 | IPv4 Attached Subnet (Section 11.10) | 1638 | 11 | IPv6 Attached Subnet (Section 11.11) | 1639 | 12 | Maximum Data Rate (Receive) (MDRR) (Section 11.12) | 1640 | 13 | Maximum Data Rate (Transmit) (MDRT) (Section 11.13) | 1641 | 14 | Current Data Rate (Receive) (CDRR) (Section 11.14) | 1642 | 15 | Current Data Rate (Transmit) (CDRT) (Section 11.15) | 1643 | 16 | Latency (Section 11.16) | 1644 | 17 | Resources (RES) (Section 11.17) | 1645 | 18 | Relative Link Quality (Receive) (RLQR) (Section | 1646 | | 11.18) | 1647 | 19 | Relative Link Quality (Transmit) (RLQT) (Section | 1648 | | 11.19) | 1649 | 20 | Maximum Transmission Unit (MTU) (Section 11.20) | 1650 | 21-65407 | Reserved for future extensions | 1651 | 65408-65534 | Private Use. Available for experiments | 1652 | 65535 | Reserved | 1653 +-------------+-----------------------------------------------------+ 1655 Table 1: DLEP Data Item types 1657 11.1. Status 1659 For the Session Termination Message (Section 10.9), the Status Data 1660 Item indicates a reason for the termination. For all response 1661 Messages, the Status Data Item is used to indicate the success or 1662 failure of the previously received Message. 1664 The Status Data Item includes an optional Text field that can be used 1665 to provide a textual description of the status. The use of the Text 1666 field is entirely up to the receiving implementation, e.g., it could 1667 be output to a log file or discarded. If no Text field is supplied 1668 with the Status Data Item, the Length field MUST be set to 1. 1670 The Status Data Item contains the following fields: 1672 0 1 2 3 1673 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 1674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1675 | Data Item Type | Length | 1676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1677 | Code | Text... : 1678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1680 Data Item Type: 1 1682 Length: 1 + Length of text, in octets 1684 Status Code: One of the codes defined in Table 2 below. 1686 Text: UTF-8 encoded string of UNICODE [RFC3629] characters, 1687 describing the cause, used for implementation defined purposes. 1688 Since this field is used for description, implementations SHOULD 1689 limit characters in this field to printable characters. 1690 Implementations receiving this Data Item SHOULD check for 1691 printable characters in the field. 1693 An implementation MUST NOT assume the Text field is NUL-terminated. 1695 +----------+-------------+------------------+-----------------------+ 1696 | Status | Failure | Description | Reason | 1697 | Code | Mode | | | 1698 +----------+-------------+------------------+-----------------------+ 1699 | 0 | Continue | Success | The Message was | 1700 | | | | processed | 1701 | | | | successfully. | 1702 | 1 | Continue | Not Interested | The receiver is not | 1703 | | | | interested in this | 1704 | | | | Message subject, e.g. | 1705 | | | | in a Destination Up | 1706 | | | | Response Message | 1707 | | | | (Section 10.12) to | 1708 | | | | indicate no further | 1709 | | | | Messages about the | 1710 | | | | destination. | 1711 | 2 | Continue | Request Denied | The receiver refuses | 1712 | | | | to complete the | 1713 | | | | request. | 1714 | 3 | Continue | Inconsistent | One or more Data | 1715 | | | Data | Items in the Message | 1716 | | | | describe a logically | 1717 | | | | inconsistent state in | 1718 | | | | the network. For | 1719 | | | | example, in the | 1720 | | | | Destination Up | 1721 | | | | Message (Section | 1722 | | | | 10.11) when an | 1723 | | | | announced subnet | 1724 | | | | clashes with an | 1725 | | | | existing destination | 1726 | | | | subnet. | 1727 | 4-111 | Continue | | Reserved for future | 1728 | | | | extensions. | 1729 | 112-127 | Continue | | Available for | 1730 | | | | experiments. | 1731 | 128 | Terminate | Unknown Message | The Message was not | 1732 | | | | recognized by the | 1733 | | | | implementation. | 1734 | 129 | Terminate | Unexpected | The Message was not | 1735 | | | Message | expected while the | 1736 | | | | device was in the | 1737 | | | | current state, e.g., | 1738 | | | | a Session | 1739 | | | | Initialization | 1740 | | | | Message (Section | 1741 | | | | 10.5) in the In- | 1742 | | | | Session state. | 1743 | 130 | Terminate | Invalid Data | One or more Data | 1744 | | | | Items in the Message | 1745 | | | | are invalid, | 1746 | | | | unexpected or | 1747 | | | | incorrectly | 1748 | | | | duplicated. | 1749 | 131 | Terminate | Invalid | The destination | 1750 | | | Destination | included in the | 1751 | | | | Message does not | 1752 | | | | match a previously | 1753 | | | | announced | 1754 | | | | destination. For | 1755 | | | | example, in the Link | 1756 | | | | Characteristic | 1757 | | | | Response Message | 1758 | | | | (Section 10.19). | 1759 | 132 | Terminate | Timed Out | The session has timed | 1760 | | | | out. | 1761 | 133-239 | Terminate | | Reserved for future | 1762 | | | | extensions. | 1763 | 240-254 | Terminate | | Available for | 1764 | | | | experiments. | 1765 | 255 | Terminate | | Reserved. | 1766 +----------+-------------+------------------+-----------------------+ 1767 Table 2: DLEP Status Codes 1769 11.2. IPv4 Connection Point 1771 The IPv4 Connection Point Data Item indicates the IPv4 address and, 1772 optionally, the TCP port number on the modem available for 1773 connections. If provided, the router MUST use this information to 1774 initiate the TCP connection to the modem. 1776 The IPv4 Connection Point Data Item contains the following fields: 1778 0 1 2 3 1779 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 1780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1781 | Data Item Type | Length | 1782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1783 | Flags | IPv4 Address... : 1784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1785 : ...cont. | TCP Port Number (optional) | 1786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1788 Data Item Type: 2 1790 Length: 5 (or 7 if TCP Port included) 1792 Flags: Flags field, defined below. 1794 IPv4 Address: The IPv4 address listening on the modem. 1796 TCP Port Number: TCP Port number on the modem. 1798 If the Length field is 7, the port number specified MUST be used to 1799 establish the TCP session. If the TCP Port Number is omitted, i.e. 1800 the Length field is 5, the router MUST use the DLEP well-known port 1801 number (Section 13.13) to establish the TCP connection. 1803 The Flags field is defined as: 1805 0 1 2 3 4 5 6 7 1806 +-+-+-+-+-+-+-+-+ 1807 | Reserved | 1808 +-+-+-+-+-+-+-+-+ 1810 Reserved: MUST be zero. Reserved for future use. 1812 11.3. IPv6 Connection Point 1814 The IPv6 Connection Point Data Item indicates the IPv6 address and, 1815 optionally, the TCP port number on the modem available for 1816 connections. If provided, the router MUST use this information to 1817 initiate the TCP connection to the modem. 1819 The IPv6 Connection Point Data Item contains the following fields: 1821 0 1 2 3 1822 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 1823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1824 | Data Item Type | Length | 1825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1826 | Flags | IPv6 Address : 1827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1828 : IPv6 Address : 1829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1830 : IPv6 Address : 1831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1832 : IPv6 Address : 1833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1834 : ...cont. | TCP Port Number (optional) | 1835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1837 Data Item Type: 3 1839 Length: 17 (or 19 if TCP Port included) 1841 Flags: Flags field, defined below. 1843 IPv6 Address: The IPv6 address listening on the modem. 1845 TCP Port Number: TCP Port number on the modem. 1847 If the Length field is 19, the port number specified MUST be used to 1848 establish the TCP session. If the TCP Port Number is omitted, i.e. 1849 the Length field is 17, the router MUST use the DLEP well-known port 1850 number (Section 13.13) to establish the TCP connection. 1852 The Flags field is defined as: 1854 0 1 2 3 4 5 6 7 1855 +-+-+-+-+-+-+-+-+ 1856 | Reserved | 1857 +-+-+-+-+-+-+-+-+ 1859 Reserved: MUST be zero. Reserved for future use. 1861 11.4. Peer Type 1863 The Peer Type Data Item is used by the router and modem to give 1864 additional information as to its type. The Peer Type is a string and 1865 is envisioned to be used for informational purposes (e.g., as output 1866 in a display command). 1868 The Peer Type Data Item contains the following fields: 1870 0 1 2 3 1871 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 1872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1873 | Data Item Type | Length | 1874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1875 | Peer Type... : 1876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1878 Data Item Type: 4 1880 Length: Length of Peer Type string, in octets. 1882 Peer Type: UTF-8 encoded string of UNICODE [RFC3629] characters. 1883 For example, a satellite modem might set this variable to 1884 "Satellite terminal". Since this Data Item is intended to provide 1885 additional information for display commands, sending 1886 implementations SHOULD limit the data to printable characters, and 1887 receiving implementations SHOULD check the data for printable 1888 characters. 1890 An implementation MUST NOT assume the Peer Type field is NUL- 1891 terminated. 1893 11.5. Heartbeat Interval 1895 The Heartbeat Interval Data Item is used to specify a period in 1896 milliseconds for Heartbeat Messages (Section 10.20). 1898 The Heartbeat Interval Data Item contains the following fields: 1900 0 1 2 3 1901 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 1902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1903 | Data Item Type | Length | 1904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1905 | Heartbeat Interval | 1906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1908 Data Item Type: 5 1909 Length: 4 1911 Heartbeat Interval: The interval in milliseconds, expressed as a 1912 32-bit unsigned integer, for Heartbeat Messages. This value MUST 1913 NOT be 0. 1915 11.6. Extensions Supported 1917 The Extensions Supported Data Item is used by the router and modem to 1918 negotiate additional optional functionality they are willing to 1919 support. The Extensions List is a concatenation of the types of each 1920 supported extension, found in the IANA DLEP Extensions repository. 1921 Each Extension Type definition includes which additional Signals and 1922 Data Items are supported. 1924 The Extensions Supported Data Item contains the following fields: 1926 0 1 2 3 1927 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 1928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1929 | Data Item Type | Length | 1930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1931 | Extensions List... : 1932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1934 Data Item Type: 6 1936 Length: Length of the extensions list in octets. This is twice (2x) 1937 the number of extensions. 1939 Extension List: A list of extensions supported, identified by their 1940 2-octet value as listed in the extensions registry. 1942 11.7. MAC Address 1944 The MAC Address Data Item contains the address of the destination on 1945 the remote node. 1947 DLEP can support MAC addresses in either EUI-48 or EUI-64 format, 1948 with the restriction that all MAC addresses for a given DLEP session 1949 MUST be in the same format, and MUST be consistent with the MAC 1950 address format of the connected modem (e.g., if the modem is 1951 connected to the router with an EUI-48 MAC, all destination addresses 1952 via that modem MUST be expressed in EUI-48 format). 1954 Examples of a virtual destination would be a multicast MAC address, 1955 or the broadcast MAC (FF:FF:FF:FF:FF:FF). 1957 0 1 2 3 1958 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 1959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1960 | Data Item Type | Length | 1961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1962 | MAC Address : 1963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1964 : MAC Address : 1965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1966 : MAC Address : (if EUI-64 used) | 1967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1969 Data Item Type: 7 1971 Length: 6 for EUI-48 format, or 8 for EUI-64 format 1973 MAC Address: MAC Address of the destination. 1975 11.8. IPv4 Address 1977 When included in the Session Update Message, this Data Item contains 1978 the IPv4 address of the peer. When included in Destination Messages, 1979 this Data Item contains the IPv4 address of the destination. In 1980 either case, the Data Item also contains an indication of whether 1981 this is a new or existing address, or is a deletion of a previously 1982 known address. 1984 The IPv4 Address Data Item contains the following fields: 1986 0 1 2 3 1987 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 1988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1989 | Data Item Type | Length | 1990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1991 | Flags | IPv4 Address : 1992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1993 : ...cont. | 1994 +-+-+-+-+-+-+-+-+ 1996 Data Item Type: 8 1998 Length: 5 2000 Flags: Flags field, defined below. 2002 IPv4 Address: The IPv4 address of the destination or peer. 2004 The Flags field is defined as: 2006 0 1 2 3 4 5 6 7 2007 +-+-+-+-+-+-+-+-+ 2008 | Reserved |A| 2009 +-+-+-+-+-+-+-+-+ 2011 A: Add/Drop flag, indicating whether this is a new or existing 2012 address (1), or a withdrawal of an address (0). 2014 Reserved: MUST be zero. Reserved for future use. 2016 11.8.1. IPv4 Address Processing 2018 Processing of the IPv4 Address Data Item MUST be done within the 2019 context of the DLEP Peer session on which it is presented. 2021 The handling of erroneous or logically inconsistent conditions 2022 depends upon the type of the message that contains the data item: 2024 If the containing message is a Session Message, e.g., Session 2025 Initialization Message (Section 10.5), or Session Update Message 2026 (Section 10.7), the receiver of inconsistent information MUST issue a 2027 Session Termination Message (Section 10.9) containing a Status Data 2028 Item (Section 11.1) with status code set to 130 'Invalid Data', and 2029 transition to the Session Termination state. Examples of such 2030 conditions are: 2032 o An address Drop operation referencing an address that is not 2033 associated with the peer in the current session. 2035 o An address Add operation referencing an address that has already 2036 been added to the peer in the current session. 2038 If the containing message is a Destination Message, e.g., Destination 2039 Up Message (Section 10.11), or Destination Update Message 2040 (Section 10.17), the receiver of inconsistent information MAY issue 2041 the appropriate response message containing a Status Data Item, with 2042 status code set to 3 'Inconsistent Data', but MUST continue with 2043 session processing. Examples of such conditions are: 2045 o An address Add operation referencing an address that has already 2046 been added to the destination in the current session. 2048 o An address Add operation referencing an address that is associated 2049 with a different destination or the peer in the current session 2051 o An address Drop operation referencing an address that is not 2052 associated with the destination in the current session. 2054 If no response message is appropriate, for example, the Destination 2055 Update Message, then the implementation MUST continue with session 2056 processing. 2058 Modems that do not track IPv4 addresses MUST silently ignore IPv4 2059 Address Data Items. 2061 11.9. IPv6 Address 2063 When included in the Session Update Message, this Data Item contains 2064 the IPv6 address of the peer. When included in Destination Messages, 2065 this Data Item contains the IPv6 address of the destination. In 2066 either case, the Data Item also contains an indication of whether 2067 this is a new or existing address, or is a deletion of a previously 2068 known address. 2070 The IPv6 Address Data Item contains the following fields: 2072 0 1 2 3 2073 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 2074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2075 | Data Item Type | Length | 2076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2077 | Flags | IPv6 Address : 2078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2079 : IPv6 Address : 2080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2081 : IPv6 Address : 2082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2083 : IPv6 Address : 2084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2085 : IPv6 Address | 2086 +-+-+-+-+-+-+-+-+ 2088 Data Item Type: 9 2090 Length: 17 2092 Flags: Flags field, defined below. 2094 IPv6 Address: IPv6 Address of the destination or peer. 2096 The Flags field is defined as: 2098 0 1 2 3 4 5 6 7 2099 +-+-+-+-+-+-+-+-+ 2100 | Reserved |A| 2101 +-+-+-+-+-+-+-+-+ 2102 A: Add/Drop flag, indicating whether this is a new or existing 2103 address (1), or a withdrawal of an address (0). 2105 Reserved: MUST be zero. Reserved for future use. 2107 11.9.1. IPv6 Address Processing 2109 Processing of the IPv6 Address Data Item MUST be done within the 2110 context of the DLEP Peer session on which it is presented. 2112 The handling of erroneous or logically inconsistent conditions 2113 depends upon the type of the message that contains the data item: 2115 If the containing message is a Session Message, e.g., Session 2116 Initialization Message (Section 10.5), or Session Update Message 2117 (Section 10.7), the receiver of inconsistent information MUST issue a 2118 Session Termination Message (Section 10.9) containing a Status Data 2119 Item (Section 11.1) with status code set to 130 'Invalid Data', and 2120 transition to the Session Termination state. Examples of such 2121 conditions are: 2123 o An address Drop operation referencing an address that is not 2124 associated with the peer in the current session. 2126 o An address Add operation referencing an address that has already 2127 been added to the peer in the current session. 2129 If the containing message is a Destination Message, e.g., Destination 2130 Up Message (Section 10.11), or Destination Update Message 2131 (Section 10.17), the receiver of inconsistent information MAY issue 2132 the appropriate response message containing a Status Data Item, with 2133 status code set to 3 'Inconsistent Data', but MUST continue with 2134 session processing. Examples of such conditions are: 2136 o An address Add operation referencing an address that has already 2137 been added to the destination in the current session. 2139 o An address Add operation referencing an address that is associated 2140 with a different destination or the peer in the current session 2142 o An address Drop operation referencing an address that is not 2143 associated with the destination in the current session. 2145 If no response message is appropriate, for example, the Destination 2146 Update Message, then the implementation MUST continue with session 2147 processing. 2149 Modems that do not track IPv6 addresses MUST silently ignore IPv6 2150 Address Data Items. 2152 11.10. IPv4 Attached Subnet 2154 The DLEP IPv4 Attached Subnet allows a device to declare that it has 2155 an IPv4 subnet (e.g., a stub network) attached, that it has become 2156 aware of an IPv4 subnet being present at a remote destination, or 2157 that it has become aware of the loss of a subnet at the remote 2158 destination. 2160 The DLEP IPv4 Attached Subnet Data Item contains the following 2161 fields: 2163 0 1 2 3 2164 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 2165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2166 | Data Item Type | Length | 2167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2168 | Flags | IPv4 Attached Subnet : 2169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2170 : ...cont. |Prefix Length | 2171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2173 Data Item Type: 10 2175 Length: 6 2177 Flags: Flags field, defined below. 2179 IPv4 Subnet: The IPv4 subnet reachable at the destination. 2181 Prefix Length: Length of the prefix (0-32) for the IPv4 subnet. A 2182 prefix length outside the specified range MUST be considered as 2183 invalid. 2185 The Flags field is defined as: 2187 0 1 2 3 4 5 6 7 2188 +-+-+-+-+-+-+-+-+ 2189 | Reserved |A| 2190 +-+-+-+-+-+-+-+-+ 2192 A: Add/Drop flag, indicating whether this is a new or existing subnet 2193 address (1), or a withdrawal of a subnet address (0). 2195 Reserved: MUST be zero. Reserved for future use. 2197 11.10.1. IPv4 Attached Subnet Processing 2199 Processing of the IPv4 Attached Subnet Data Item MUST be done within 2200 the context of the DLEP Peer session on which it is presented. 2202 If the containing message is a Session Message, e.g., Session 2203 Initialization Message (Section 10.5), or Session Update Message 2204 (Section 10.7), the receiver of inconsistent information MUST issue a 2205 Session Termination Message (Section 10.9) containing a Status Data 2206 Item (Section 11.1) with status code set to 130 'Invalid Data', and 2207 transition to the Session Termination state. Examples of such 2208 conditions are: 2210 o A subnet Drop operation referencing a subnet that is not 2211 associated with the peer in the current session. 2213 o A subnet Add operation referencing a subnet that has already been 2214 added to the peer in the current session. 2216 If the containing message is a Destination Message, e.g., Destination 2217 Up Message (Section 10.11), or Destination Update Message 2218 (Section 10.17), the receiver of inconsistent information MAY issue 2219 the appropriate response message containing a Status Data Item, with 2220 status code set to 3 'Inconsistent Data', but MUST continue with 2221 session processing. Examples of such conditions are: 2223 o A subnet Add operation referencing a subnet that has already been 2224 added to the destination in the current session. 2226 o A subnet Add operation referencing a subnet that is associated 2227 with a different destination in the current session. 2229 o A subnet Drop operation referencing a subnet that is not 2230 associated with the destination in the current session. 2232 If no response message is appropriate, for example, the Destination 2233 Update Message, then the implementation MUST continue with session 2234 processing. 2236 Modems that do not track IPv4 subnets MUST silently ignore IPv4 2237 Attached Subnet Data Items. 2239 11.11. IPv6 Attached Subnet 2241 The DLEP IPv6 Attached Subnet allows a device to declare that it has 2242 an IPv6 subnet (e.g., a stub network) attached, that it has become 2243 aware of an IPv6 subnet being present at a remote destination, or 2244 that it has become aware of the loss of a subnet at the remote 2245 destination. 2247 The DLEP IPv6 Attached Subnet Data Item contains the following 2248 fields: 2250 0 1 2 3 2251 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 2252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2253 | Data Item Type | Length | 2254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2255 | Flags | IPv6 Attached Subnet : 2256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2257 : IPv6 Attached Subnet : 2258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2259 : IPv6 Attached Subnet : 2260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2261 : IPv6 Attached Subnet : 2262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2263 : ...cont. | Prefix Len. | 2264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2266 Data Item Type: 11 2268 Length: 18 2270 Flags: Flags field, defined below. 2272 IPv6 Attached Subnet: The IPv6 subnet reachable at the destination. 2274 Prefix Length: Length of the prefix (0-128) for the IPv6 subnet. A 2275 prefix length outside the specified range MUST be considered as 2276 invalid. 2278 The Flags field is defined as: 2280 0 1 2 3 4 5 6 7 2281 +-+-+-+-+-+-+-+-+ 2282 | Reserved |A| 2283 +-+-+-+-+-+-+-+-+ 2285 A: Add/Drop flag, indicating whether this is a new or existing subnet 2286 address (1), or a withdrawal of a subnet address (0). 2288 Reserved: MUST be zero. Reserved for future use. 2290 11.11.1. IPv6 Attached Subnet Processing 2292 Processing of the IPv6 Attached Subnet Data Item MUST be done within 2293 the context of the DLEP Peer session on which it is presented. 2295 If the containing message is a Session Message, e.g., Session 2296 Initialization Message (Section 10.5), or Session Update Message 2297 (Section 10.7), the receiver of inconsistent information MUST issue a 2298 Session Termination Message (Section 10.9) containing a Status Data 2299 Item (Section 11.1) with status code set to 130 'Invalid Data', and 2300 transition to the Session Termination state. Examples of such 2301 conditions are: 2303 o A subnet Drop operation referencing a subnet that is not 2304 associated with the peer in the current session. 2306 o A subnet Add operation referencing a subnet that has already been 2307 added to the peer in the current session. 2309 If the containing message is a Destination Message, e.g., Destination 2310 Up Message (Section 10.11), or Destination Update Message 2311 (Section 10.17), the receiver of inconsistent information MAY issue 2312 the appropriate response message containing a Status Data Item, with 2313 status code set to 3 'Inconsistent Data', but MUST continue with 2314 session processing. Examples of such conditions are: 2316 o A subnet Add operation referencing a subnet that has already been 2317 added to the destination in the current session. 2319 o A subnet Add operation referencing a subnet that is associated 2320 with a different destination in the current session. 2322 o A subnet Drop operation referencing a subnet that is not 2323 associated with the destination in the current session. 2325 If no response message is appropriate, for example, the Destination 2326 Update Message, then the implementation MUST continue with session 2327 processing. 2329 Modems that do not track IPv6 subnets MUST silently ignore IPv4 2330 Attached Subnet Data Items. 2332 11.12. Maximum Data Rate (Receive) 2334 The Maximum Data Rate (Receive) (MDRR) Data Item is used to indicate 2335 the maximum theoretical data rate, in bits per second, that can be 2336 achieved while receiving data on the link. 2338 The Maximum Data Rate (Receive) Data Item contains the following 2339 fields: 2341 0 1 2 3 2342 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 2343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2344 | Data Item Type | Length | 2345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2346 | MDRR (bps) : 2347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2348 : MDRR (bps) | 2349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2351 Data Item Type: 12 2353 Length: 8 2355 Maximum Data Rate (Receive): A 64-bit unsigned integer, representing 2356 the maximum theoretical data rate, in bits per second (bps), that 2357 can be achieved while receiving on the link. 2359 11.13. Maximum Data Rate (Transmit) 2361 The Maximum Data Rate (Transmit) (MDRT) Data Item is used to indicate 2362 the maximum theoretical data rate, in bits per second, that can be 2363 achieved while transmitting data on the link. 2365 The Maximum Data Rate (Transmit) Data Item contains the following 2366 fields: 2368 0 1 2 3 2369 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 2370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2371 | Data Item Type | Length | 2372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2373 | MDRT (bps) : 2374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2375 : MDRT (bps) | 2376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2378 Data Item Type: 13 2380 Length: 8 2382 Maximum Data Rate (Transmit): A 64-bit unsigned integer, 2383 representing the maximum theoretical data rate, in bits per second 2384 (bps), that can be achieved while transmitting on the link. 2386 11.14. Current Data Rate (Receive) 2388 The Current Data Rate (Receive) (CDRR) Data Item is used to indicate 2389 the rate at which the link is currently operating for receiving 2390 traffic. 2392 When used in the Link Characteristics Request Message 2393 (Section 10.18), Current Data Rate (Receive) represents the desired 2394 receive rate, in bits per second, on the link. 2396 The Current Data Rate (Receive) Data Item contains the following 2397 fields: 2399 0 1 2 3 2400 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 2401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2402 | Data Item Type | Length | 2403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2404 | CDRR (bps) : 2405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2406 : CDRR (bps) | 2407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2409 Data Item Type: 14 2411 Length: 8 2413 Current Data Rate (Receive): A 64-bit unsigned integer, representing 2414 the current data rate, in bits per second, that can currently be 2415 achieved while receiving traffic on the link. 2417 If there is no distinction between Current Data Rate (Receive) and 2418 Maximum Data Rate (Receive) (Section 11.12), Current Data Rate 2419 (Receive) MUST be set equal to the Maximum Data Rate (Receive). The 2420 Current Data Rate (Receive) MUST NOT exceed the Maximum Data Rate 2421 (Receive). 2423 11.15. Current Data Rate (Transmit) 2425 The Current Data Rate (Transmit) (CDRT) Data Item is used to indicate 2426 the rate at which the link is currently operating for transmitting 2427 traffic. 2429 When used in the Link Characteristics Request Message 2430 (Section 10.18), Current Data Rate (Transmit) represents the desired 2431 transmit rate, in bits per second, on the link. 2433 The Current Data Rate (Transmit) Data Item contains the following 2434 fields: 2436 0 1 2 3 2437 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 2438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2439 | Data Item Type | Length | 2440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2441 | CDRT (bps) : 2442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2443 : CDRT (bps) | 2444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2446 Data Item Type: 15 2448 Length: 8 2450 Current Data Rate (Transmit): A 64-bit unsigned integer, 2451 representing the current data rate, in bits per second, that can 2452 currently be achieved while transmitting traffic on the link. 2454 If there is no distinction between Current Data Rate (Transmit) and 2455 Maximum Data Rate (Transmit) (Section 11.13), Current Data Rate 2456 (Transmit) MUST be set equal to the Maximum Data Rate (Transmit). 2457 The Current Data Rate (Transmit) MUST NOT exceed the Maximum Data 2458 Rate (Transmit). 2460 11.16. Latency 2462 The Latency Data Item is used to indicate the amount of latency, in 2463 microseconds, on the link. 2465 The Latency value is reported as transmission delay. The calculation 2466 of latency is implementation dependent. For example, the latency may 2467 be a running average calculated from the internal queuing. 2469 The Latency Data Item contains the following fields: 2471 0 1 2 3 2472 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 2473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2474 | Data Item Type | Length | 2475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2476 | Latency : 2477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2478 : Latency | 2479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2480 Data Item Type: 16 2482 Length: 8 2484 Latency: A 64-bit unsigned integer, representing the transmission 2485 delay, in microseconds, that a packet encounters as it is 2486 transmitted over the link. 2488 11.17. Resources 2490 The Resources (RES) Data Item is used to indicate the amount of 2491 finite resources available for data transmission and reception at the 2492 destination as a percentage, with 0 meaning 'no resources remaining', 2493 and 100 meaning 'a full supply', assuming that when Resources reaches 2494 0 data transmission and/or reception will cease. 2496 An example of such resources might be battery life, but could equally 2497 be magic beans. The list of resources that might be considered is 2498 beyond the scope of this document, and is left to implementations to 2499 decide. 2501 This Data Item is designed to be used as an indication of some 2502 capability of the modem and/or router at the destination. 2504 The Resources Data Item contains the following fields: 2506 0 1 2 3 2507 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 2508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2509 | Data Item Type | Length | 2510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2511 | RES | 2512 +-+-+-+-+-+-+-+-+ 2514 Data Item Type: 17 2516 Length: 1 2518 Resources: An 8-bit unsigned integer percentage, 0-100, representing 2519 the amount of resources available. Any value greater than 100 2520 MUST be considered as invalid. 2522 If a device cannot calculate Resources, this Data Item MUST NOT be 2523 issued. 2525 11.18. Relative Link Quality (Receive) 2527 The Relative Link Quality (Receive) (RLQR) Data Item is used to 2528 indicate the quality of the link to a destination for receiving 2529 traffic, with 0 meaning 'worst quality', and 100 meaning 'best 2530 quality'. 2532 Quality in this context is defined as an indication of the stability 2533 of a link for reception; a destination with high Relative Link 2534 Quality (Receive) is expected to have generally stable DLEP metrics, 2535 and the metrics of a destination with low Relative Link Quality 2536 (Receive) can be expected to rapidly fluctuate over a wide range. 2538 The Relative Link Quality (Receive) Data Item contains the following 2539 fields: 2541 0 1 2 3 2542 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 2543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2544 | Data Item Type | Length | 2545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2546 | RLQR | 2547 +-+-+-+-+-+-+-+-+ 2549 Data Item Type: 18 2551 Length: 1 2553 Relative Link Quality (Receive): A non-dimensional unsigned 8-bit 2554 integer, 0-100, representing relative quality of the link for 2555 receiving traffic. Any value greater than 100 MUST be considered 2556 as invalid. 2558 If a device cannot calculate the Relative Link Quality (Receive), 2559 this Data Item MUST NOT be issued. 2561 11.19. Relative Link Quality (Transmit) 2563 The Relative Link Quality (Transmit) (RLQT) Data Item is used to 2564 indicate the quality of the link to a destination for transmitting 2565 traffic, with 0 meaning 'worst quality', and 100 meaning 'best 2566 quality'. 2568 Quality in this context is defined as an indication of the stability 2569 of a link for transmission; a destination with high Relative Link 2570 Quality (Transmit) is expected to have generally stable DLEP metrics, 2571 and the metrics of a destination with low Relative Link Quality 2572 (Transmit) can be expected to rapidly fluctuate over a wide range. 2574 The Relative Link Quality (Transmit) Data Item contains the following 2575 fields: 2577 0 1 2 3 2578 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 2579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2580 | Data Item Type | Length | 2581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2582 | RLQT | 2583 +-+-+-+-+-+-+-+-+ 2585 Data Item Type: 19 2587 Length: 1 2589 Relative Link Quality (Transmit): A non-dimensional unsigned 8-bit 2590 integer, 0-100, representing relative quality of the link for 2591 transmitting traffic. Any value greater than 100 MUST be 2592 considered as invalid. 2594 If a device cannot calculate the Relative Link Quality (Transmit), 2595 this Data Item MUST NOT be issued. 2597 11.20. Maximum Transmission Unit (MTU) 2599 The Maximum Transmission Unit (MTU) Data Item is used to indicate the 2600 maximum size, in octets, of an IP packet that can be transmitted 2601 without fragmentation, including headers, but excluding any lower 2602 layer headers. 2604 The Maximum Transmission Unit Data Item contains the following 2605 fields: 2607 0 1 2 3 2608 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 2609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2610 | Data Item Type | Length | 2611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2612 | MTU | 2613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2615 Data Item Type: 20 2617 Length: 2 2619 Maximum Transmission Unit: The maximum size, in octets, of an IP 2620 packet that can be transmitted without fragmentation, including 2621 headers, but excluding any lower layer headers. 2623 If a device cannot calculate the Maximum Transmission Unit, this Data 2624 Item MUST NOT be issued. 2626 12. Security Considerations 2628 The potential security concerns when using DLEP are: 2630 1. An attacker might pretend to be a DLEP participant, either at 2631 DLEP session initialization, or by injection of DLEP Messages 2632 once a session has been established, and/or 2634 2. DLEP Data Items could be altered by an attacker, causing the 2635 receiving implementation to inappropriately alter its information 2636 base concerning network status. 2638 Since DLEP is restricted to operation over a single (possibly 2639 logical) hop at layer 2, implementations requiring authentication 2640 and/or encryption of traffic MUST take steps to secure the Layer 2 2641 link. Examples of technologies that can be deployed to secure the 2642 Layer 2 link include [IEEE-802.1AE] and [IEEE-802.1X]. 2644 To avoid potential denial of service attack, it is RECOMMENDED that 2645 implementations using the Peer Discovery mechanism maintain an 2646 information base of hosts that persistently fail Session 2647 Initialization having provided an acceptable Peer Discovery Signal, 2648 and ignore subsequent Peer Discovery Signals from such hosts. 2650 This specification does not address security of the data plane, as it 2651 (the data plane) is not affected, and standard security procedures 2652 can be employed. 2654 13. IANA Considerations 2656 13.1. Registrations 2658 Upon approval of this document, IANA is requested to create a new 2659 protocol registry for Dynamic Link Exchange Protocol (DLEP). The 2660 remainder of this section requests the creation of new DLEP specific 2661 registries. 2663 13.2. Signal Type Registration 2665 Upon approval of this document, IANA is requested to create a new 2666 DLEP registry, named "Signal Type Values". 2668 The following table provides initial registry values and the 2669 [RFC5226] defined policies that should apply to the registry: 2671 +--------------+-------------------------+ 2672 | Type Code | Description/Policy | 2673 +--------------+-------------------------+ 2674 | 0 | Reserved | 2675 | 1 | Peer Discovery Signal | 2676 | 2 | Peer Offer Signal | 2677 | 3-65519 | Specification Required | 2678 | 65520-65534 | Private Use | 2679 | 65535 | Reserved | 2680 +--------------+-------------------------+ 2682 13.3. Message Type Registration 2684 Upon approval of this document, IANA is requested to create a new 2685 DLEP registry, named "Message Type Values". 2687 The following table provides initial registry values and the 2688 [RFC5226] defined policies that should apply to the registry: 2690 +--------------+------------------------------------------+ 2691 | Type Code | Description/Policy | 2692 +--------------+------------------------------------------+ 2693 | 0 | Reserved | 2694 | 1 | Session Initialization Message | 2695 | 2 | Session Initialization Response Message | 2696 | 3 | Session Update Message | 2697 | 4 | Session Update Response Message | 2698 | 5 | Session Termination Message | 2699 | 6 | Session Termination Response Message | 2700 | 7 | Destination Up Message | 2701 | 8 | Destination Up Response Message | 2702 | 9 | Destination Announce Message | 2703 | 10 | Destination Announce Response Message | 2704 | 11 | Destination Down Message | 2705 | 12 | Destination Down Response Message | 2706 | 13 | Destination Update Message | 2707 | 14 | Link Characteristics Request Message | 2708 | 15 | Link Characteristics Response Message | 2709 | 16 | Heartbeat Message | 2710 | 17-65519 | Specification Required | 2711 | 65520-65534 | Private Use | 2712 | 65535 | Reserved | 2713 +--------------+------------------------------------------+ 2715 13.4. DLEP Data Item Registrations 2717 Upon approval of this document, IANA is requested to create a new 2718 DLEP registry, named "Data Item Values". 2720 The following table provides initial registry values and the 2721 [RFC5226] defined policies that should apply to the registry: 2723 +-------------------+------------------------------------------+ 2724 | Type Code | Description/Policy | 2725 +-------------------+------------------------------------------+ 2726 | 0 | Reserved | 2727 | 1 | Status | 2728 | 2 | IPv4 Connection Point | 2729 | 3 | IPv6 Connection Point | 2730 | 4 | Peer Type | 2731 | 5 | Heartbeat Interval | 2732 | 6 | Extensions Supported | 2733 | 7 | MAC Address | 2734 | 8 | IPv4 Address | 2735 | 9 | IPv6 Address | 2736 | 10 | IPv4 Attached Subnet | 2737 | 11 | IPv6 Attached Subnet | 2738 | 12 | Maximum Data Rate (Receive) (MDRR) | 2739 | 13 | Maximum Data Rate (Transmit) (MDRT) | 2740 | 14 | Current Data Rate (Receive) (CDRR) | 2741 | 15 | Current Data Rate (Transmit) (CDRT) | 2742 | 16 | Latency | 2743 | 17 | Resources (RES) | 2744 | 18 | Relative Link Quality (Receive) (RLQR) | 2745 | 19 | Relative Link Quality (Transmit) (RLQT) | 2746 | 20 | Maximum Transmission Unit (MTU) | 2747 | 21-65407 | Specification Required | 2748 | 65408-65534 | Private Use | 2749 | 65535 | Reserved | 2750 +-------------------+------------------------------------------+ 2752 13.5. DLEP Status Code Registrations 2754 Upon approval of this document, IANA is requested to create a new 2755 DLEP registry, named "Status Code Values". 2757 The following table provides initial registry values and the 2758 [RFC5226] defined policies that should apply to the registry: 2760 +--------------+---------------+-------------------------+ 2761 | Status Code | Failure Mode | Description/Policy | 2762 +--------------+---------------+-------------------------+ 2763 | 0 | Continue | Success | 2764 | 1 | Continue | Not Interested | 2765 | 2 | Continue | Request Denied | 2766 | 3 | Continue | Inconsistent Data | 2767 | 4-111 | Continue | Specification Required | 2768 | 112-127 | Continue | Private Use | 2769 | 128 | Terminate | Unknown Message | 2770 | 129 | Terminate | Unexpected Message | 2771 | 130 | Terminate | Invalid Data | 2772 | 131 | Terminate | Invalid Destination | 2773 | 132 | Terminate | Timed Out | 2774 | 133-239 | Terminate | Specification Required | 2775 | 240-254 | Terminate | Private Use | 2776 | 255 | Terminate | Reserved | 2777 +--------------+---------------+-------------------------+ 2779 13.6. DLEP Extensions Registrations 2781 Upon approval of this document, IANA is requested to create a new 2782 DLEP registry, named "Extension Type Values". 2784 The following table provides initial registry values and the 2785 [RFC5226] defined policies that should apply to the registry: 2787 +--------------+----------------------------+ 2788 | Code | Description/Policy | 2789 +--------------+----------------------------+ 2790 | 0 | Reserved | 2791 | 1 | Credit Windowing [CREDIT] | 2792 | 2-65519 | Specification Required | 2793 | 65520-65534 | Private Use | 2794 | 65535 | Reserved | 2795 +--------------+----------------------------+ 2797 Table 3: DLEP Extension types 2799 13.7. DLEP IPv4 Connection Point Flags 2801 Upon approval of this document, IANA is requested to create a new 2802 DLEP registry, named "IPv4 Connection Point Flags". 2804 The following table provides initial registry values and the 2805 [RFC5226] defined policies that should apply to the registry: 2807 +------------+----------------------------------+ 2808 | Bit | Description/Policy | 2809 +------------+----------------------------------+ 2810 | 0-7 | Reserved/Specification Required | 2811 +------------+----------------------------------+ 2813 13.8. DLEP IPv6 Connection Point Flags 2815 Upon approval of this document, IANA is requested to create a new 2816 DLEP registry, named "IPv6 Connection Point Flags". 2818 The following table provides initial registry values and the 2819 [RFC5226] defined policies that should apply to the registry: 2821 +------------+----------------------------------+ 2822 | Bit | Description/Policy | 2823 +------------+----------------------------------+ 2824 | 0-7 | Reserved/Specification Required | 2825 +------------+----------------------------------+ 2827 13.9. DLEP IPv4 Address Flag 2829 Upon approval of this document, IANA is requested to create a new 2830 DLEP registry, named "IPv4 Address Flags". 2832 The following table provides initial registry values and the 2833 [RFC5226] defined policies that should apply to the registry: 2835 +------------+----------------------------------+ 2836 | Bit | Description/Policy | 2837 +------------+----------------------------------+ 2838 | 0-6 | Reserved/Specification Required | 2839 | 7 | Add/Drop indicator | 2840 +------------+----------------------------------+ 2842 13.10. DLEP IPv6 Address Flag 2844 Upon approval of this document, IANA is requested to create a new 2845 DLEP registry, named "IPv6 Address Flags". 2847 The following table provides initial registry values and the 2848 [RFC5226] defined policies that should apply to the registry: 2850 +------------+----------------------------------+ 2851 | Bit | Description/Policy | 2852 +------------+----------------------------------+ 2853 | 0-6 | Reserved/Specification Required | 2854 | 7 | Add/Drop indicator | 2855 +------------+----------------------------------+ 2857 13.11. DLEP IPv4 Attached Subnet Flag 2859 Upon approval of this document, IANA is requested to create a new 2860 DLEP registry, named "IPv4 Attached Subnet Flags". 2862 The following table provides initial registry values and the 2863 [RFC5226] defined policies that should apply to the registry: 2865 +------------+----------------------------------+ 2866 | Bit | Description/Policy | 2867 +------------+----------------------------------+ 2868 | 0-6 | Reserved/Specification Required | 2869 | 7 | Add/Drop indicator | 2870 +------------+----------------------------------+ 2872 13.12. DLEP IPv6 Attached Subnet Flag 2874 Upon approval of this document, IANA is requested to create a new 2875 DLEP registry, named "IPv6 Attached Subnet Flags". 2877 The following table provides initial registry values and the 2878 [RFC5226] defined policies that should apply to the registry: 2880 +------------+----------------------------------+ 2881 | Bit | Description/Policy | 2882 +------------+----------------------------------+ 2883 | 0-6 | Reserved/Specification Required | 2884 | 7 | Add/Drop indicator | 2885 +------------+----------------------------------+ 2887 13.13. DLEP Well-known Port 2889 Upon approval of this document, IANA is requested to assign a single 2890 value in the "Service Name and Transport Protocol Port Number 2891 Registry" found at https://www.iana.org/assignments/service-names- 2892 port-numbers/service-names-port-numbers.xhtml for use by "DLEP", as 2893 defined in this document. This assignment should be valid for TCP 2894 and UDP. 2896 13.14. DLEP IPv4 Link-local Multicast Address 2898 Upon approval of this document, IANA is requested to assign an IPv4 2899 multicast address registry found at http://www.iana.org/assignments/ 2900 multicast-addresses for use as the "IPv4 DLEP Discovery Address". 2902 13.15. DLEP IPv6 Link-local Multicast Address 2904 Upon approval of this document, IANA is requested to assign an IPv6 2905 multicast address registry found at http://www.iana.org/assignments/ 2906 multicast-addresses for use as the "IPv6 DLEP Discovery Address". 2908 14. Acknowledgements 2910 We would like to acknowledge and thank the members of the DLEP design 2911 team, who have provided invaluable insight. The members of the 2912 design team are: Teco Boot, Bow-Nan Cheng, John Dowdell, and Henning 2913 Rogge. 2915 We would also like to acknowledge the influence and contributions of 2916 Greg Harrison, Chris Olsen, Martin Duke, Subir Das, Jaewon Kang, 2917 Vikram Kaul, Nelson Powell, Lou Berger, and Victoria Pritchard. 2919 15. References 2921 15.1. Normative References 2923 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2924 Requirement Levels", BCP 14, RFC 2119, 2925 DOI 10.17487/RFC2119, March 1997, 2926 . 2928 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2929 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2930 2003, . 2932 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 2933 Pignataro, "The Generalized TTL Security Mechanism 2934 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 2935 . 2937 15.2. Informative References 2939 [CREDIT] Ratliff, S., "Credit Windowing extension for DLEP", IETF 2940 draft draft-ietf-manet-credit-window-04, March 2016. 2942 [IEEE-802.1AE] 2943 "IEEE Standards for Local and Metropolitan Area Networks: 2944 Media Access Control (MAC) Security", 2945 DOI 10.1109/IEEESTD.2006.245590, August 2006. 2947 [IEEE-802.1X] 2948 "IEEE Standards for Local and Metropolitan Area Networks: 2949 Port based Network Access Control", 2950 DOI 10.1109/IEEESTD.2010.5409813, February 2010. 2952 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2953 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2954 DOI 10.17487/RFC5226, May 2008, 2955 . 2957 [RFC5578] Berry, B., Ed., Ratliff, S., Paradise, E., Kaiser, T., and 2958 M. Adams, "PPP over Ethernet (PPPoE) Extensions for Credit 2959 Flow and Link Metrics", RFC 5578, DOI 10.17487/RFC5578, 2960 February 2010, . 2962 Appendix A. Discovery Signal Flows 2964 Router Modem Signal Description 2965 ======================================================================== 2967 | Router initiates discovery, starts 2968 | a timer, send Peer Discovery 2969 |-------Peer Discovery---->X Signal. 2971 ~ ~ ~ ~ ~ ~ ~ Router discovery timer expires 2972 without receiving Peer Offer. 2974 | Router sends another Peer 2975 |-------Peer Discovery---------->| Discovery Signal. 2976 | 2977 | Modem receives Peer Discovery 2978 | Signal. 2979 | 2980 | Modem sends Peer Offer with 2981 |<--------Peer Offer-------------| Connection Point information. 2982 : 2983 : Router MAY cancel discovery timer 2984 : and stop sending Peer Discovery 2985 : Signals. 2987 Appendix B. Peer Level Message Flows 2989 B.1. Session Initialization 2991 Router Modem Message Description 2992 ======================================================================== 2994 | Router connects to discovered or 2995 | pre-configured Modem Connection 2996 |--TCP connection established---> Point. 2997 | 2998 | Router sends Session 2999 |----Session Initialization----->| Initialization Message. 3000 | 3001 | Modem receives Session 3002 | Initialization Message. 3003 | 3004 | Modem sends Session Initialization 3005 |<--Session Initialization Resp.-| Response, with Success Status Data 3006 | | Item. 3007 | | 3008 |<<============================>>| Session established. Heartbeats 3009 : : begin. 3011 B.2. Session Initialization - Refused 3012 Router Modem Message Description 3013 ======================================================================== 3015 | Router connects to discovered or 3016 | pre-configured Modem Connection 3017 |--TCP connection established---> Point. 3018 | 3019 | Router sends Session 3020 |-----Session Initialization---->| Initialization Message. 3021 | 3022 | Modem receives Session 3023 | Initialization Message, and will 3024 | not support the advertised 3025 | extensions. 3026 | 3027 | Modem sends Session Initialization 3028 | Response, with 'Request Denied' 3029 |<-Session Initialization Resp.--| Status Data Item. 3030 | 3031 | 3032 | Router receives negative Session 3033 | Initialization Response, closes 3034 ||---------TCP close------------|| TCP connection. 3036 B.3. Router Changes IP Addresses 3038 Router Modem Message Description 3039 ======================================================================== 3041 | Router sends Session Update 3042 |-------Session Update---------->| Message to announce change of IP 3043 | address 3044 | 3045 | Modem receives Session Update 3046 | Message and updates internal 3047 | state. 3048 | 3049 |<----Session Update Response----| Modem sends Session Update 3050 | Response. 3052 B.4. Modem Changes Session-wide Metrics 3053 Router Modem Message Description 3054 ======================================================================== 3056 | Modem sends Session Update Message 3057 | to announce change of modem-wide 3058 |<--------Session Update---------| metrics 3059 | 3060 | Router receives Session Update 3061 | Message and updates internal 3062 | state. 3063 | 3064 |----Session Update Response---->| Router sends Session Update 3065 | Response. 3067 B.5. Router Terminates Session 3069 Router Modem Message Description 3070 ======================================================================== 3072 | Router sends Session Termination 3073 |------Session Termination------>| Message with Status Data Item. 3074 | | 3075 |-------TCP shutdown (send)---> | Router stops sending Messages. 3076 | 3077 | Modem receives Session 3078 | Termination, stops counting 3079 | received heartbeats and stops 3080 | sending heartbeats. 3081 | 3082 | Modem sends Session Termination 3083 |<---Session Termination Resp.---| Response with Status 'Success'. 3084 | 3085 | Modem stops sending Messages. 3086 | 3087 ||---------TCP close------------|| Session terminated. 3089 B.6. Modem Terminates Session 3090 Router Modem Message Description 3091 ======================================================================== 3093 | Modem sends Session Termination 3094 |<----Session Termination--------| Message with Status Data Item. 3095 | 3096 | Modem stops sending Messages. 3097 | 3098 | Router receives Session 3099 | Termination, stops counting 3100 | received heartbeats and stops 3101 | sending heartbeats. 3102 | 3103 | Router sends Session Termination 3104 |---Session Termination Resp.--->| Response with Status 'Success'. 3105 | 3106 | Router stops sending Messages. 3107 | 3108 ||---------TCP close------------|| Session terminated. 3110 B.7. Session Heartbeats 3111 Router Modem Message Description 3112 ======================================================================== 3114 |----------Heartbeat------------>| Router sends heartbeat Message 3115 | 3116 | Modem resets heartbeats missed 3117 | counter. 3119 ~ ~ ~ ~ ~ ~ ~ 3121 |---------[Any Message]--------->| When the Modem receives any 3122 | Message from the Router. 3123 | 3124 | Modem resets heartbeats missed 3125 | counter. 3127 ~ ~ ~ ~ ~ ~ ~ 3129 |<---------Heartbeat-------------| Modem sends heartbeat Message 3130 | 3131 | Router resets heartbeats missed 3132 | counter. 3134 ~ ~ ~ ~ ~ ~ ~ 3136 |<--------[Any Message]----------| When the Router receives any 3137 | Message from the Modem. 3138 | 3139 | Modem resets heartbeats missed 3140 | counter. 3142 B.8. Router Detects a Heartbeat timeout 3144 Router Modem Message Description 3145 ======================================================================== 3147 X<----------------------| Router misses a heartbeat 3149 | X<----------------------| Router misses too many heartbeats 3150 | 3151 | 3152 |------Session Termination------>| Router sends Session Termination 3153 | Message with 'Timeout' Status 3154 | Data Item. 3155 : 3156 : Termination proceeds... 3158 B.9. Modem Detects a Heartbeat timeout 3160 Router Modem Message Description 3161 ======================================================================== 3163 |---------------------->X Modem misses a heartbeat 3165 |---------------------->X | Modem misses too many heartbeats 3166 | 3167 | 3168 |<-----Session Termination-------| Modem sends Session Termination 3169 | Message with 'Timeout' Status 3170 | Data Item. 3171 : 3172 : Termination proceeds... 3174 Appendix C. Destination Specific Message Flows 3176 C.1. Common Destination Notification 3177 Router Modem Message Description 3178 ======================================================================== 3180 | Modem detects a new logical 3181 | destination is reachable, and 3182 |<-------Destination Up----------| sends Destination Up Message. 3183 | 3184 |------Destination Up Resp.----->| Router sends Destination Up 3185 | Response. 3187 ~ ~ ~ ~ ~ ~ ~ 3188 | Modem detects change in logical 3189 | destination metrics, and sends 3190 |<-------Destination Update------| Destination Update Message. 3192 ~ ~ ~ ~ ~ ~ ~ 3193 | Modem detects change in logical 3194 | destination metrics, and sends 3195 |<-------Destination Update------| Destination Update Message. 3197 ~ ~ ~ ~ ~ ~ ~ 3198 | Modem detects logical destination 3199 | is no longer reachable, and sends 3200 |<-------Destination Down--------| Destination Down Message. 3201 | 3202 | Router receives Destination Down, 3203 | updates internal state, and sends 3204 |------Destination Down Resp.--->| Destination Down Response Message. 3206 C.2. Multicast Destination Notification 3207 Router Modem Message Description 3208 ======================================================================== 3210 | Router detects a new multicast 3211 | destination is in use, and sends 3212 |-----Destination Announce------>| Destination Announce Message. 3213 | 3214 | Modem updates internal state to 3215 | monitor multicast destination, and 3216 |<-----Dest. Announce Resp.------| sends Destination Announce 3217 Response. 3219 ~ ~ ~ ~ ~ ~ ~ 3220 | Modem detects change in multicast 3221 | destination metrics, and sends 3222 |<-------Destination Update------| Destination Update Message. 3224 ~ ~ ~ ~ ~ ~ ~ 3225 | Modem detects change in multicast 3226 | destination metrics, and sends 3227 |<-------Destination Update------| Destination Update Message. 3229 ~ ~ ~ ~ ~ ~ ~ 3230 | Router detects multicast 3231 | destination is no longer in use, 3232 |--------Destination Down------->| and sends Destination Down 3233 | Message. 3234 | 3235 | Modem receives Destination Down, 3236 | updates internal state, and sends 3237 |<-----Destination Down Resp.----| Destination Down Response Message. 3239 C.3. Link Characteristics Request 3240 Router Modem Message Description 3241 ======================================================================== 3243 Destination has already been 3244 ~ ~ ~ ~ ~ ~ ~ announced by either peer. 3246 | Router requires different 3247 | Characteristics for the 3248 | destination, and sends Link 3249 |--Link Characteristics Request->| Characteristics Request Message. 3250 | 3251 | Modem attempts to adjust link 3252 | properties to meet the received 3253 | request, and sends a Link 3254 | Characteristics Response 3255 |<---Link Characteristics Resp.--| Message with the new values. 3257 Authors' Addresses 3259 Stan Ratliff 3260 VT iDirect 3261 13861 Sunrise Valley Drive, Suite 300 3262 Herndon, VA 20171 3263 USA 3265 Email: sratliff@idirect.net 3267 Shawn Jury 3268 Cisco Systems 3269 170 West Tasman Drive 3270 San Jose, CA 95134 3271 USA 3273 Email: sjury@cisco.com 3275 Darryl Satterwhite 3276 Broadcom 3278 Email: dsatterw@broadcom.com 3279 Rick Taylor 3280 Airbus Defence & Space 3281 Quadrant House 3282 Celtic Springs 3283 Coedkernew 3284 Newport NP10 8FZ 3285 UK 3287 Email: rick.taylor@airbus.com 3289 Bo Berry