idnits 2.17.1 draft-ietf-manet-dlep-22.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 275 has weird spacing: '... Shared o ...' == Line 276 has weird spacing: '... Medium o ...' -- The document date (April 7, 2016) is 2941 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) == Outdated reference: A later version (-07) exists of draft-ietf-manet-credit-window-04 -- Possible downref: Non-RFC (?) normative reference: ref. 'UNIV8' -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networks Working Group S. Ratliff 3 Internet-Draft VT iDirect 4 Intended status: Standards Track B. Berry 5 Expires: October 9, 2016 6 S. Jury 7 Cisco Systems 8 D. Satterwhite 9 Broadcom 10 R. Taylor 11 Airbus Defence & Space 12 April 7, 2016 14 Dynamic Link Exchange Protocol (DLEP) 15 draft-ietf-manet-dlep-22 17 Abstract 19 When routing devices rely on modems to effect communications over 20 wireless links, they need timely and accurate knowledge of the 21 characteristics of the link (speed, state, etc.) in order to make 22 routing decisions. In mobile or other environments where these 23 characteristics change frequently, manual configurations or the 24 inference of state through routing or transport protocols does not 25 allow the router to make the best decisions. A bidirectional, event- 26 driven communication channel between the router and the modem is 27 necessary. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on October 9, 2016. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 7 65 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 66 2.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 9 67 3. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 4. DLEP Session Flow . . . . . . . . . . . . . . . . . . . . . . 10 69 4.1. Peer Discovery State . . . . . . . . . . . . . . . . . . 11 70 4.2. Session Initialization State . . . . . . . . . . . . . . 12 71 4.3. In-Session State . . . . . . . . . . . . . . . . . . . . 12 72 4.3.1. Heartbeats . . . . . . . . . . . . . . . . . . . . . 13 73 4.4. Session Termination State . . . . . . . . . . . . . . . . 13 74 4.5. Session Reset state . . . . . . . . . . . . . . . . . . . 14 75 4.5.1. Unexpected TCP connection termination . . . . . . . . 14 76 5. Transaction Model . . . . . . . . . . . . . . . . . . . . . . 14 77 6. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 6.1. Experiments . . . . . . . . . . . . . . . . . . . . . . . 15 79 7. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 8. DLEP Signal and Message Structure . . . . . . . . . . . . . . 16 81 8.1. DLEP Signal Header . . . . . . . . . . . . . . . . . . . 17 82 8.2. DLEP Message Header . . . . . . . . . . . . . . . . . . . 17 83 8.3. DLEP Generic Data Item . . . . . . . . . . . . . . . . . 18 84 9. DLEP Signals and Messages . . . . . . . . . . . . . . . . . . 19 85 9.1. General Processing Rules . . . . . . . . . . . . . . . . 20 86 9.2. Status code processing . . . . . . . . . . . . . . . . . 21 87 9.3. Peer Discovery Signal . . . . . . . . . . . . . . . . . . 21 88 9.4. Peer Offer Signal . . . . . . . . . . . . . . . . . . . . 22 89 9.5. Session Initialization Message . . . . . . . . . . . . . 22 90 9.6. Session Initialization Response Message . . . . . . . . . 23 91 9.7. Session Update Message . . . . . . . . . . . . . . . . . 25 92 9.8. Session Update Response Message . . . . . . . . . . . . . 26 93 9.9. Session Termination Message . . . . . . . . . . . . . . . 26 94 9.10. Session Termination Response Message . . . . . . . . . . 27 95 9.11. Destination Up Message . . . . . . . . . . . . . . . . . 27 96 9.12. Destination Up Response Message . . . . . . . . . . . . . 28 97 9.13. Destination Announce Message . . . . . . . . . . . . . . 29 98 9.14. Destination Announce Response Message . . . . . . . . . . 29 99 9.15. Destination Down Message . . . . . . . . . . . . . . . . 31 100 9.16. Destination Down Response Message . . . . . . . . . . . . 31 101 9.17. Destination Update Message . . . . . . . . . . . . . . . 31 102 9.18. Link Characteristics Request Message . . . . . . . . . . 33 103 9.19. Link Characteristics Response Message . . . . . . . . . . 33 104 9.20. Heartbeat Message . . . . . . . . . . . . . . . . . . . . 34 105 10. DLEP Data Items . . . . . . . . . . . . . . . . . . . . . . . 35 106 10.1. Status . . . . . . . . . . . . . . . . . . . . . . . . . 36 107 10.2. IPv4 Connection Point . . . . . . . . . . . . . . . . . 38 108 10.3. IPv6 Connection Point . . . . . . . . . . . . . . . . . 39 109 10.4. Peer Type . . . . . . . . . . . . . . . . . . . . . . . 40 110 10.5. Heartbeat Interval . . . . . . . . . . . . . . . . . . . 40 111 10.6. Extensions Supported . . . . . . . . . . . . . . . . . . 41 112 10.7. MAC Address . . . . . . . . . . . . . . . . . . . . . . 41 113 10.8. IPv4 Address . . . . . . . . . . . . . . . . . . . . . . 42 114 10.9. IPv6 Address . . . . . . . . . . . . . . . . . . . . . . 43 115 10.10. IPv4 Attached Subnet . . . . . . . . . . . . . . . . . . 44 116 10.11. IPv6 Attached Subnet . . . . . . . . . . . . . . . . . . 45 117 10.12. Maximum Data Rate (Receive) . . . . . . . . . . . . . . 46 118 10.13. Maximum Data Rate (Transmit) . . . . . . . . . . . . . . 46 119 10.14. Current Data Rate (Receive) . . . . . . . . . . . . . . 47 120 10.15. Current Data Rate (Transmit) . . . . . . . . . . . . . . 48 121 10.16. Latency . . . . . . . . . . . . . . . . . . . . . . . . 48 122 10.17. Resources . . . . . . . . . . . . . . . . . . . . . . . 49 123 10.18. Relative Link Quality (Receive) . . . . . . . . . . . . 50 124 10.19. Relative Link Quality (Transmit) . . . . . . . . . . . . 51 125 10.20. Maximum Transmission Unit (MTU) . . . . . . . . . . . . 52 126 11. Security Considerations . . . . . . . . . . . . . . . . . . . 52 127 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 128 12.1. Registrations . . . . . . . . . . . . . . . . . . . . . 53 129 12.2. Signal Type Registration . . . . . . . . . . . . . . . . 53 130 12.3. Message Type Registration . . . . . . . . . . . . . . . 53 131 12.4. DLEP Data Item Registrations . . . . . . . . . . . . . . 54 132 12.5. DLEP Status Code Registrations . . . . . . . . . . . . . 55 133 12.6. DLEP Extensions Registrations . . . . . . . . . . . . . 56 134 12.7. DLEP Well-known Port . . . . . . . . . . . . . . . . . . 56 135 12.8. DLEP IPv4 Link-local Multicast Address . . . . . . . . . 57 136 12.9. DLEP IPv6 Link-local Multicast Address . . . . . . . . . 57 137 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57 138 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 139 14.1. Normative References . . . . . . . . . . . . . . . . . . 57 140 14.2. Informative References . . . . . . . . . . . . . . . . . 57 141 Appendix A. Discovery Signal Flows . . . . . . . . . . . . . . . 58 142 Appendix B. Peer Level Message Flows . . . . . . . . . . . . . . 58 143 B.1. Session Initialization . . . . . . . . . . . . . . . . . 58 144 B.2. Session Initialization - Refused . . . . . . . . . . . . 59 145 B.3. Router Changes IP Addresses . . . . . . . . . . . . . . . 60 146 B.4. Modem Changes Session-wide Metrics . . . . . . . . . . . 60 147 B.5. Router Terminates Session . . . . . . . . . . . . . . . . 60 148 B.6. Modem Terminates Session . . . . . . . . . . . . . . . . 61 149 B.7. Session Heartbeats . . . . . . . . . . . . . . . . . . . 61 150 B.8. Router Detects a Heartbeat timeout . . . . . . . . . . . 62 151 B.9. Modem Detects a Heartbeat timeout . . . . . . . . . . . . 63 152 Appendix C. Destination Specific Message Flows . . . . . . . . . 63 153 C.1. Common Destination Notification . . . . . . . . . . . . . 63 154 C.2. Multicast Destination Notification . . . . . . . . . . . 64 155 C.3. Link Characteristics Request . . . . . . . . . . . . . . 65 156 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 66 158 1. Introduction 160 There exist today a collection of modem devices that control links of 161 variable datarate and quality. Examples of these types of links 162 include line-of-sight (LOS) terrestrial radios, satellite terminals, 163 and broadband modems. Fluctuations in speed and quality of these 164 links can occur due to configuration, or on a moment-to-moment basis, 165 due to physical phenomena like multipath interference, obstructions, 166 rain fade, etc. It is also quite possible that link quality and 167 datarate vary with respect to individual destinations on a link, and 168 with the type of traffic being sent. As an example, consider the 169 case of an IEEE 802.11 access point, serving two associated laptop 170 computers. In this environment, the answer to the question "What is 171 the datarate on the 802.11 link?" is "It depends on which associated 172 laptop we're talking about, and on what kind of traffic is being 173 sent." While the first laptop, being physically close to the access 174 point, may have a datarate of 54Mbps for unicast traffic, the other 175 laptop, being relatively far away, or obstructed by some object, can 176 simultaneously have a datarate of only 32Mbps for unicast. However, 177 for multicast traffic sent from the access point, all traffic is sent 178 at the base transmission rate (which is configurable, but depending 179 on the model of the access point, is usually 24Mbps or less). 181 In addition to utilizing variable datarate links, mobile networks are 182 challenged by the notion that link connectivity will come and go over 183 time, without an effect on a router's interface state (Up or Down). 184 Effectively utilizing a relatively short-lived connection is 185 problematic in IP routed networks, as IP routing protocols tend to 186 rely on interface state and independent timers to maintain network 187 convergence (e.g., HELLO messages and/or recognition of DEAD routing 188 adjacencies). These dynamic connections can be better utilized with 189 an event-driven paradigm, where acquisition of a new neighbor (or 190 loss of an existing one) is signaled, as opposed to a paradigm driven 191 by timers and/or interface state. DLEP not only implements such an 192 event-driven paradigm, but does so over a local (1 hop) TCP session, 193 which guarantees delivery of the event messages. 195 Another complicating factor for mobile networks are the different 196 methods of physically connecting the modem devices to the router. 197 Modems can be deployed as an interface card in a router's chassis, or 198 as a standalone device connected to the router via Ethernet or serial 199 link. In the case of Ethernet attachment, with existing protocols 200 and techniques, routing software cannot be aware of convergence 201 events occurring on the radio link (e.g., acquisition or loss of a 202 potential routing neighbor), nor can the router be aware of the 203 actual capacity of the link. This lack of awareness, along with the 204 variability in datarate, leads to a situation where finding the 205 (current) best route through the network to a given destination is 206 difficult to establish and properly maintain. This is especially 207 true of demand-based access schemes such as Demand Assigned Multiple 208 Access (DAMA) implementations used on some satellite systems. With a 209 DAMA-based system, additional datarate may be available, but will not 210 be used unless the network devices emit traffic at a rate higher than 211 the currently established rate. Increasing the traffic rate does not 212 guarantee additional datarate will be allocated; rather, it may 213 result in data loss and additional retransmissions on the link. 215 Addressing the challenges listed above, the co-authors have developed 216 the Dynamic Link Exchange Protocol, or DLEP. The DLEP protocol runs 217 between a router and its attached modem devices, allowing the modem 218 to communicate link characteristics as they change, and convergence 219 events (acquisition and loss of potential routing destinations). The 220 following diagrams are used to illustrate the scope of DLEP packets. 222 |-------Local Node-------| |-------Remote Node------| 223 | | | | 224 +--------+ +-------+ +-------+ +--------+ 225 | Router |=======| Modem |{~~~~~~~~}| Modem |=======| Router | 226 | | | Device| | Device| | | 227 +--------+ +-------+ +-------+ +--------+ 228 | | | Link | | | 229 |-DLEP--| | Protocol | |-DLEP--| 230 | | | (e.g. | | | 231 | | | 802.11) | | | 233 Figure 1: DLEP Network 235 In Figure 1, when the local modem detects the presence of a remote 236 node, it (the local modem) sends a message to its router via the DLEP 237 protocol. The message consists of an indication of what change has 238 occurred on the link (e.g., presence of a remote node detected), 239 along with a collection of DLEP-defined data items that further 240 describe the change. Upon receipt of the message, the local router 241 may take whatever action it deems appropriate, such as initiating 242 discovery protocols, and/or issuing HELLO messages to converge the 243 network. On a continuing, as-needed basis, the modem devices use 244 DLEP to report any characteristics of the link (datarate, latency, 245 etc.) that have changed. DLEP is independent of the link type and 246 topology supported by the modem. Note that the DLEP protocol is 247 specified to run only on the local link between router and modem. 248 Some over the air signaling may be necessary between the local and 249 remote modem in order to provide some parameters in DLEP messages 250 between the local modem and local router, but DLEP does not specify 251 how such over the air signaling is carried out. Over the air 252 signaling is purely a matter for the modem implementer. 254 Figure 2 shows how DLEP can support a configuration where routers are 255 connected with different link types. In this example, Modem A 256 implements a point-to-point link, and Modem B is connected via a 257 shared medium. In both cases, the DLEP protocol is used to report 258 the characteristics of the link (datarate, latency, etc.) to routers. 259 The modem is also able to use the DLEP session to notify the router 260 when the remote node is lost, shortening the time required to re- 261 converge the network. 263 +--------+ +--------+ 264 +----+ Modem | | Modem +---+ 265 | | Device | | Device | 266 | | Type A | <===== // ======> | Type A | | 267 | +--------+ P-2-P Link +--------+ | 268 +---+----+ +---+----+ 269 | Router | | Router | 270 | | | | 271 +---+----+ +---+----+ 272 | +--------+ +--------+ | 273 +-----+ Modem | | Modem | | 274 | Device | o o o o o o o o | Device +--+ 275 | Type B | o Shared o | Type B | 276 +--------+ o Medium o +--------+ 277 o o 278 o o 279 o o 280 o 281 +--------+ 282 | Modem | 283 | Device | 284 | Type B | 285 +---+----+ 286 | 287 | 288 +---+----+ 289 | Router | 290 | | 291 +--------+ 293 Figure 2: DLEP Network with Multiple Modem Devices 295 1.1. Requirements 297 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 298 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 299 "OPTIONAL" in this document are to be interpreted as described in BCP 300 14, RFC 2119 [RFC2119]. 302 2. Protocol Overview 304 DLEP defines a set of Messages used by modems and their attached 305 routers to communicate events that occur on the physical link(s) 306 managed by the modem: for example, a remote node entering or leaving 307 the network, or that the link has changed. Associated with these 308 Messages are a set of Data Items - information that describes the 309 remote node (e.g., address information), and/or the characteristics 310 of the link to the remote node. Throughout this document, we refer 311 to a modems/routers participating in a DLEP session as 'DLEP 312 Participants', unless a specific distinction (e.g. modem or router) 313 is required. 315 DLEP uses a session-oriented paradigm between the modem device and 316 its associated router. If multiple modem devices are attached to a 317 router (as in Figure 2), or the modem supports multiple connections 318 (via multiple logical or physical interfaces), then separate DLEP 319 sessions exist for each modem or connection. A router and modem form 320 a session by completing the discovery and initialization process. 321 This router-modem session persists unless or until it either (1) 322 times out, based on the absence of DLEP traffic (including 323 heartbeats), or (2) is explicitly torn down by one of the DLEP 324 participants. 326 The router/modem session provides a carrier for information exchange 327 concerning 'destinations' that are available via the modem device. 328 Destinations can be identified by either the router or the modem, and 329 represent a specific, addressable location that can be reached via 330 the link(s) managed by the modem. 332 The DLEP Messages concerning destinations thus become the way for 333 routers and modems to maintain, and notify each other about, an 334 information base representing the physical and logical destinations 335 accessible via the modem device, as well as the link characteristics 336 to those destinations. 338 DLEP identifies destinations by using the MAC address for delivering 339 data traffic. No manipulation or substitution is performed; the MAC 340 address supplied in all destination Messages is used as the 341 Destination MAC address. DLEP therefore requires that MAC addresses 342 are unique within the context of a router-modem session. 344 The reliance on MAC addresses by DLEP forces the requirement that 345 DLEP participants are on a single segment (either physical or 346 logically, via tunneling protocols) at Layer 2. 348 A destination can be either physical or logical. The example of a 349 physical destination would be that of a remote, far-end router 350 attached via the variable-quality network. It should be noted that 351 for physical destinations the MAC address is the address of the far- 352 end router, not the modem. 354 The example of a logical destination is Multicast. Multicast traffic 355 destined for the variable-quality network (the network accessed via 356 the modem) is handled in IP networks by deriving a Layer 2 MAC 357 address based on the Layer 3 address. Leveraging on this scheme, 358 multicast traffic is supported in DLEP simply by treating the derived 359 MAC address as any other destination in the network. 361 To support these logical destinations, one of the DLEP participants 362 (typically, the router) informs the other as to the existence of the 363 logical destination. The modem, once it is aware of the existence of 364 this logical destination, reports link characteristics just as it 365 would for any other destination in the network. The specific 366 algorithms a modem would use to derive metrics on logical 367 destinations are outside the scope of this specification, and is left 368 to specific implementations to decide. 370 While this document represents the best efforts of the working group 371 to be functionally complete, it is recognized that extensions to DLEP 372 will in all likelihood be necessary as more link types are used. 373 Such extensions are defined as additional Messages, Data Items and/or 374 status codes, and associated rules of behavior, that are not defined 375 in this document. DLEP contains a standard mechanism for router and 376 modem implementations to negotiate the available extensions to use on 377 a per-session basis. 379 2.1. Assumptions 381 DLEP specifies UDP multicast for single-hop discovery signaling, and 382 TCP for transport of the Messages. Therefore, DLEP assumes that the 383 modem and router have topologically consistent IP addresses assigned. 384 It is RECOMMENDED that DLEP implementations utilize IPv6 link-local 385 addresses to reduce the administrative burden of address assignment. 386 DLEP relies on the guaranteed delivery of its Messages between router 387 and modem, once the 1 hop discovery process is complete, hence, the 388 specification of TCP to carry the Messages. Other reliable 389 transports for the protocol are possible, but are outside the scope 390 of this document. 392 DLEP further assumes that security of the implementations (e.g., 393 authentication of stations, encryption of traffic, or both) is dealt 394 with by utilizing Layer 2 security techniques. This reliance on 395 Layer 2 mechanisms secures all DLEP Messages - both the UDP discovery 396 Signals and the TCP control Messages. 398 3. Metrics 400 DLEP includes the ability for the router and modem to communicate 401 metrics that reflect the characteristics (e.g., datarate, latency) of 402 the variable-quality link in use. DLEP does not specify how a given 403 metric value is to be calculated, rather, the protocol assumes that 404 metrics have been calculated by a 'best effort', incorporating all 405 pertinent data that is available to the modem device. 407 DLEP allows for metrics to be sent within two contexts - metrics for 408 a specific destination within the network (e.g., a specific router), 409 and per-session (those that apply to all destinations accessed via 410 the modem). Most metrics can be further subdivided into transmit and 411 receive metrics. In cases where metrics are provided at session 412 level, the router propagates the metrics to all entries in its 413 information base for destinations that are accessed via the modem. 415 DLEP modems announce all metric Data Items that will be reported 416 during the session, and provide default values for those metrics, in 417 the Session Initialization Response Message (Section 9.6). In order 418 to use a metric type that was not included in the Session 419 Initialization Response Message, modem implementations terminate the 420 session with the router (via the Session Terminate Message 421 (Section 9.9)), and establish a new session. 423 A DLEP modem can send metrics both in a session context, via the 424 Session Update Message (Section 9.7), and a specific destination 425 context, via the Destination Update Message (Section 9.17), at any 426 time. The most recently received metric value takes precedence over 427 any earlier value, regardless of context - that is: 429 1. If the router receives metrics in a specific destination context 430 (via the Destination Update Message), then the specific 431 destination is updated with the new metric. 433 2. If the router receives metrics in a session-wide context (via the 434 Session Update Message), then the metrics for all destinations 435 accessed via the modem are updated with the new metric. 437 It is left to implementations to choose sensible default values based 438 on their specific characteristics. Modems having static (non- 439 changing) link metric characteristics can report metrics only once 440 for a given destination (or once on a session-wide basis, if all 441 connections via the modem are of this static nature). 443 In addition to communicating existing metrics about the link, DLEP 444 provides a Message allowing a router to request a different datarate 445 or latency from the modem. This Message is the Link Characteristics 446 Request Message (Section 9.18), and gives the router the ability to 447 deal with requisite increases (or decreases) of allocated datarate/ 448 latency in demand-based schemes in a more deterministic manner. 450 4. DLEP Session Flow 452 All DLEP participants of a session transition through a number of 453 distinct states during the lifetime of a DLEP session: 455 o Peer Discovery 457 o Session Initialization 459 o In-Session 461 o Session Termination 463 o Session Reset 465 Modems, and routers supporting DLEP discovery, transition through all 466 five (5) of the above states. Routers that rely on preconfigured TCP 467 address/port information start in the Session Initialization state. 469 Modems MUST support the Peer Discovery state. 471 4.1. Peer Discovery State 473 In the Peer Discovery state, routers that support DLEP discovery MUST 474 send Peer Discovery Signals (Section 9.3) to initiate modem 475 discovery. 477 The router implementation then waits for a Peer Offer Signal 478 (Section 9.4) response from a potential DLEP modem. While in the 479 Peer Discovery state, Peer Discovery Signals MUST be sent repeatedly 480 by a DLEP router, at regular intervals. The interval MUST be a 481 minimum of one second; it SHOULD be a configurable parameter. Note 482 that this operation (sending Peer Discovery and waiting for Peer 483 Offer) is outside the DLEP Transaction Model (Section 5), as the 484 Transaction Model only describes Messages on a TCP session. 486 Routers MUST use one or more of each of the modem address/port 487 combinations from the Peer Offer Signal or, when no Connection Point 488 Data Items are present, from a priori configuration to establish a 489 new TCP connection to the modem. If more than one modem address/port 490 combinations is provided, router implementations MAY use their own 491 heuristics to determine the order in which they are tried. If a TCP 492 connection cannot be achieved using any of the address/port 493 combinations and the Discovery mechanism is in use, then the router 494 SHOULD resume issuing Peer Discovery Signals. If no Connection Point 495 Data Items are included in the Peer Offer Signal, the router MUST use 496 the source address of the UDP packet containing the Signal as the IP 497 address, and the DLEP well-known port number. 499 In the Peer Discovery state, the modem implementation MUST listen for 500 incoming Peer Discovery Signals on the DLEP well-known IPv6 and/or 501 IPv4 link-local multicast address and port. On receipt of a valid 502 Peer Discovery Signal, it MUST reply with a Peer Offer Signal. 504 Modems MUST be prepared to accept a TCP connection from a router that 505 is not using the Discovery mechanism, i.e. a connection attempt that 506 occurs without a preceding Peer Discovery Signal. 508 Upon establishment of a TCP connection, both modem and router enter 509 the Session Initialization state. It is up to the router 510 implementation if Peer Discovery Signals continue to be sent after 511 the device has transitioned to the Session Initialization state. 512 Modem implementations MUST silently ignore Peer Discovery Signals 513 from a router with which it already has a TCP connection. 515 4.2. Session Initialization State 517 On entering the Session Initialization state, the router MUST send a 518 Session Initialization Message (Section 9.5) to the modem. The 519 router MUST then wait for receipt of a Session Initialization 520 Response Message (Section 9.6) from the modem. Receipt of the 521 Session Initialization Response Message containing a Status Data Item 522 (Section 10.1) with status code set to 0 'Success', see Table 4, 523 indicates that the modem has received and processed the Session 524 Initialization Message, and the router MUST transition to the In- 525 Session state. 527 On entering the Session Initialization state, the modem MUST wait for 528 receipt of a Session Initialization Message from the router. Upon 529 receipt of a Session Initialization Message, the modem MUST send a 530 Session Initialization Response Message, and the session MUST 531 transition to the In-Session state. If the modem receives any 532 Message other than Session Initialization, or it fails to parse the 533 received Message, it MUST NOT send any Message, and MUST terminate 534 the TCP connection and transition to the Session Reset state. 536 DLEP provides an extension negotiation capability to be used in the 537 Session Initialization state, see Section 6. Extensions supported by 538 an implementation MUST be declared to potential DLEP participants 539 using the Extensions Supported Data Item (Section 10.6). Once both 540 DLEP participants have exchanged initialization Messages, an 541 implementation MUST NOT emit any Message, Signal, Data Item or status 542 code associated with an extension that was not specified in the 543 received initialization Message from its peer. 545 4.3. In-Session State 547 In the In-Session state, Messages can flow in both directions between 548 DLEP participants, indicating changes to the session state, the 549 arrival or departure of reachable destinations, or changes of the 550 state of the links to the destinations. 552 The In-Session state is maintained until one of the following 553 conditions occur: 555 o The implementation terminates the session by sending a Session 556 Termination Message (Section 9.9), or, 558 o Its peer terminates the session, indicated by receiving a Session 559 Termination Message. 561 The implementation MUST then transition to the Session Termination 562 state. 564 4.3.1. Heartbeats 566 In order to maintain the In-Session state, periodic Heartbeat 567 Messages (Section 9.20) MUST be exchanged between router and modem. 568 These Messages are intended to keep the session alive, and to verify 569 bidirectional connectivity between the two DLEP participants. 571 Each DLEP participant is responsible for the creation of Heartbeat 572 Messages. 574 Receipt of any valid DLEP Message MUST reset the heartbeat interval 575 timer (i.e., valid DLEP Messages take the place of, and obviate the 576 need for, additional Heartbeat Messages). 578 Implementations MUST allow a minimum of two (2) heartbeat intervals 579 to expire with no Messages from its peer before terminating the 580 session. When terminating the session, a Session Termination Message 581 containing a Status Data Item (Section 10.1) with status code set to 582 132 'Timed Out', see Table 4, MUST be sent, and then the 583 implementation MUST transition to the Session Termination state. 585 4.4. Session Termination State 587 When an implementation enters the Session Termination state after 588 sending a Session Termination Message (Section 9.9) as the result of 589 an invalid Message or error, it MUST wait for a Session Termination 590 Response Message (Section 9.10) from its peer. Senders SHOULD allow 591 four (4) heartbeat intervals to expire before assuming that its peer 592 is unresponsive, and continuing with session termination. Any other 593 Message received while waiting MUST be silently ignored. 595 When the sender of the Session Termination Message receives a Session 596 Termination Response Message from its peer, or times out, it MUST 597 transition to the Session Reset state. 599 When an implementation receives a Session Termination Message from 600 its peer, it enters the Session Termination state and then it MUST 601 immediately send a Session Termination Response and transition to the 602 Session Reset state. 604 4.5. Session Reset state 606 In the Session Reset state the implementation MUST perform the 607 following actions: 609 o Release all resources allocated for the session. 611 o Eliminate all destinations in the information base represented by 612 the session. Destination Down Messages (Section 9.15) MUST NOT be 613 sent. 615 o Terminate the TCP connection. 617 Having completed these actions the implementation SHOULD return to 618 the relevant initial state: Peer Discovery for modems; either Peer 619 Discovery or Session Initialization for routers, depending on 620 configuration. 622 4.5.1. Unexpected TCP connection termination 624 If the TCP connection between DLEP participants is terminated when an 625 implementation is not in the Session Reset state, the implementation 626 MUST immediately transition to the Session Reset state. 628 5. Transaction Model 630 DLEP defines a simple Message transaction model: Only one request per 631 destination may be in progress at a time per session. A Message 632 transaction is considered complete when a response matching a 633 previously issued request is received. If a DLEP participant 634 receives a request for a destination for which there is already an 635 outstanding request, the implementation MUST terminate the session by 636 issuing a Session Termination Message (Section 9.9) containing a 637 Status Data Item (Section 10.1) with status code set to 129 638 'Unexpected Message', see Table 4, and transition to the Session 639 Termination state. There is no restriction to the total number of 640 Message transactions in progress at a time, as long as each 641 transaction refers to a different destination. 643 It should be noted that some requests may take a considerable amount 644 of time for some DLEP participants to complete, for example a modem 645 handling a multicast destination up request may have to perform a 646 complex network reconfiguration. A sending implementation MUST be 647 able to handle such long running transactions gracefully. 649 Additionally, only one session request, e.g. a Session Initialization 650 Message (Section 9.5), may be in progress at a time per session. As 651 above, a session transaction is considered complete when a response 652 matching a previously issued request is received. If a DLEP 653 participant receives a session request while there is already a 654 session request in progress, it MUST terminate the session by issuing 655 a Session Termination Message containing a Status Data Item with 656 status code set to 129 'Unexpected Message', and transition to the 657 Session Termination state. Only the Session Termination Message may 658 be issued when a session transaction is in progress. Heartbeat 659 Messages (Section 9.20) MUST NOT be considered part of a session 660 transaction. 662 DLEP transactions do not time out and are not cancellable. An 663 implementation can detect if its peer has failed in some way by use 664 of the session heartbeat mechanism during the In-Session state, see 665 Section 4.3. 667 6. Extensions 669 Extensions MUST be negotiated on a per-session basis during session 670 initialization via the Extensions Supported mechanism. 671 Implementations are not required to support any extension in order to 672 be considered DLEP compliant. An extension document, describing the 673 operation of a credit windowing scheme for flow control, is described 674 in [CREDIT]. 676 If interoperable protocol extensions are required, they will need to 677 be standardized either as an update to this document, or as an 678 additional stand-alone specification. The requests for IANA- 679 controlled registries in this document contain sufficient Reserved 680 space for DLEP Signals, Messages, Data Items and status codes to 681 accommodate future extensions to the protocol. 683 As multiple protocol extensions MAY be announced during session 684 initialization, authors of protocol extensions need to consider the 685 interaction of their extension with other published extensions, and 686 specify any incompatibilities. 688 6.1. Experiments 690 This document requests Private Use numbering space in the DLEP 691 Signal, Message, Data Item and status code registries for 692 experimental extensions. The intent is to allow for experimentation 693 with new Signals, Messages, Data Items, and/or status codes, while 694 still retaining the documented DLEP behavior. 696 Use of the Private Use Signals, Messages, Data Items, status codes, 697 or behaviors MUST be announced as DLEP Extensions, during session 698 initialization, using extension identifiers from the Private Use 699 space in the Extensions Supported registry (Table 5), with a value 700 agreed upon (a priori) between the participants. DLEP extensions 701 using the Private Use numbering space are commonly referred to as 702 Experiments. 704 Multiple experiments MAY be announced in the Session Initialization 705 Messages. However, use of multiple experiments in a single session 706 could lead to interoperability issues or unexpected results (e.g., 707 clashes of experimental Signals, Messages, Data Items and/or status 708 code types), and is therefore discouraged. It is left to 709 implementations to determine the correct processing path (e.g., a 710 decision on whether to terminate the session, or to establish a 711 precedence of the conflicting definitions) if such conflicts arise. 713 7. Scalability 715 The protocol is intended to support thousands of destinations on a 716 given modem/router pair. At large scale, implementations SHOULD 717 consider employing techniques to prevent flooding its peer with a 718 large number of Messages in a short time. It is RECOMMENDED that 719 implementations consider a dampening algorithm to prevent a flapping 720 device from generating a large number of Destination Up/Destination 721 Down Messages, for example. 723 Implementations SHOULD also consider techniques such as a hysteresis 724 to lessen the impact of rapid, minor fluctuations in link quality. 725 The specific algorithms to be used for handling flapping destinations 726 and minor changes in link quality are outside the scope of this 727 specification. 729 8. DLEP Signal and Message Structure 731 DLEP defines two protocol units used in two different ways: Signals 732 and Messages. Signals are only used in the Discovery mechanism and 733 are carried in UDP datagrams. Messages are used bi-directionally 734 over a TCP connection between the participants, in the Session 735 Initialization, In-Session and Session Termination states. 737 Both Signals and Messages consist of a Header followed by an 738 unordered list of Data Items. Headers consist of Type and Length 739 information, while Data Items are encoded as TLV (Type-Length-Value) 740 structures. In this document, the Data Items following a Signal or 741 Message Header are described as being 'contained in' the Signal or 742 Message. 744 There is no restriction on the order of Data Items following a 745 Header, and the acceptability of duplicate Data Items is defined by 746 the definition of the Signal or Message declared by the type in the 747 Header. 749 All integers in Header fields and values MUST be in network byte- 750 order. 752 8.1. DLEP Signal Header 754 The DLEP Signal Header contains the following fields: 756 0 1 2 3 757 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | 'D' | 'L' | 'E' | 'P' | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Signal Type | Length | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 Figure 3: DLEP Signal Header 766 "DLEP": Every Signal MUST start with the characters: U+0044, U+004C, 767 U+0045, U+0050. 769 Signal Type: A 16-bit unsigned integer containing one of the DLEP 770 Signal Type values defined in this document. 772 Length: The length in octets, expressed as a 16-bit unsigned 773 integer, of all of the DLEP Data Items contained in this Signal. 774 This length MUST NOT include the length of the Signal Header 775 itself. 777 The DLEP Signal Header is immediately followed by zero or more DLEP 778 Data Items, encoded in TLVs, as defined in this document. 780 8.2. DLEP Message Header 782 The DLEP Message Header contains the following fields: 784 0 1 2 3 785 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | Message Type | Length | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 Figure 4: DLEP Message Header 792 Message Type: A 16-bit unsigned integer containing one of the DLEP 793 Message Type values defined in this document. 795 Length: The length in octets, expressed as a 16-bit unsigned 796 integer, of all of the DLEP Data Items contained in this Message. 797 This length MUST NOT include the length of the Message Header 798 itself. 800 The DLEP Message Header is immediately followed by zero or more DLEP 801 Data Items, encoded in TLVs, as defined in this document. 803 8.3. DLEP Generic Data Item 805 All DLEP Data Items contain the following fields: 807 0 1 2 3 808 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | Data Item Type | Length | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | Value... : 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 Figure 5: DLEP Generic Data Item 817 Data Item Type: A 16-bit unsigned integer field specifying the type 818 of Data Item being sent. 820 Length: The length in octets, expressed as a 16-bit unsigned 821 integer, of the Value field of the Data Item. This length MUST 822 NOT include the length of the Data Item Type and Length fields. 824 Value: A field of octets, which contains data specific to a 825 particular Data Item. 827 9. DLEP Signals and Messages 829 Following is the set of core Signals and Messages that MUST be 830 recognized by a DLEP compliant implementation. As mentioned before, 831 not all Messages may be used during a session, but an implementation 832 MUST correctly process these Signals and Messages when received. 834 The core DLEP Signals are: 836 +--------------+-----------------------------------------+ 837 | Type Code | Description | 838 +--------------+-----------------------------------------+ 839 | 0 | Reserved | 840 | 1 | Peer Discovery Signal (Section 9.3) | 841 | 2 | Peer Offer Signal (Section 9.4) | 842 | 3-65519 | Reserved for future extensions | 843 | 65520-65534 | Private Use. Available for experiments | 844 | 65535 | Reserved | 845 +--------------+-----------------------------------------+ 847 Table 1: DLEP Signal types 849 The core DLEP Messages are: 851 +--------------+----------------------------------------------------+ 852 | Type Code | Description | 853 +--------------+----------------------------------------------------+ 854 | 0 | Reserved | 855 | 1 | Session Initialization Message (Section 9.5) | 856 | 2 | Session Initialization Response Message (Section | 857 | | 9.6) | 858 | 3 | Session Update Message (Section 9.7) | 859 | 4 | Session Update Response Message (Section 9.8) | 860 | 5 | Session Termination Message (Section 9.9) | 861 | 6 | Session Termination Response Message (Section | 862 | | 9.10) | 863 | 7 | Destination Up Message (Section 9.11) | 864 | 8 | Destination Up Response Message (Section 9.12) | 865 | 9 | Destination Announce Message (Section 9.13) | 866 | 10 | Destination Announce Response Message (Section | 867 | | 9.14) | 868 | 11 | Destination Down Message (Section 9.15) | 869 | 12 | Destination Down Response Message (Section 9.16) | 870 | 13 | Destination Update Message (Section 9.17) | 871 | 14 | Link Characteristics Request Message (Section | 872 | | 9.18) | 873 | 15 | Link Characteristics Response Message (Section | 874 | | 9.19) | 875 | 16 | Heartbeat Message (Section 9.20) | 876 | 17-65519 | Reserved for future extensions | 877 | 65520-65534 | Private Use. Available for experiments | 878 | 65535 | Reserved | 879 +--------------+----------------------------------------------------+ 881 Table 2: DLEP Message types 883 9.1. General Processing Rules 885 If an unrecognized, or unexpected Signal is received, or a received 886 Signal contains unrecognized, invalid, or disallowed duplicate Data 887 Items, the receiving implementation MUST ignore the Signal. 889 If an unrecognized Message is received, the receiving implementation 890 MUST issue a Session Termination Message (Section 9.9) containing a 891 Status Data Item (Section 10.1) with status code set to 128 'Unknown 892 Message', see Table 4, and transition to the Session Termination 893 state. 895 If an unexpected Message is received, the receiving implementation 896 MUST issue a Session Termination Message containing a Status Data 897 Item with status code set to 129 'Unexpected Message', and transition 898 to the Session Termination state. 900 If a received Message contains unrecognized, invalid, or disallowed 901 duplicate Data Items, the receiving implementation MUST issue a 902 Session Termination Message containing a Status Data Item with status 903 code set to 130 'Invalid Data', and transition to the Session 904 Termination state. 906 Prior to the exchange of Destination Up (Section 9.11) and 907 Destination Up Response (Section 9.12) Messages, or Destination 908 Announce (Section 9.13) and Destination Announce Response 909 (Section 9.14) Messages, no Messages concerning a destination may be 910 sent. An implementation receiving any Message with such an 911 unannounced destination MUST terminate the session by issuing a 912 Session Termination Message containing a Status Data Item with status 913 code set to 131 'Invalid Destination', and transition to the Session 914 Termination state. 916 After exchanging Destination Down (Section 9.15) and Destination Down 917 Response (Section 9.16) Messages, no Messages concerning a 918 destination may be a sent until a new Destination Up or Destination 919 Announce Message is sent. An implementation receiving a Message 920 about a destination previously announced as 'down' MUST terminate the 921 session by issuing a Session Termination Message with a Status Data 922 Item with status code set to 131 'Invalid Destination', and 923 transition to the Session Termination state. 925 9.2. Status code processing 927 The behaviour of a DLEP participant receiving a Message containing a 928 Status Data Item (Section 10.1) is defined by the failure mode 929 associated with the value of the status code field, see Table 4. All 930 status code values less than 100 have a failure mode of 'Continue', 931 all other status codes have a failure mode of 'Terminate'. 933 A DLEP participant receiving any Message apart from Session 934 Termination Message (Section 9.9) containing a Status Data Item with 935 a status code value with failure mode 'Terminate' MUST immediately 936 issue a Session Termination Message containing an identical Status 937 Data Item, and then transition to the Session Termination state. 939 A DLEP participant receiving a Message containing a Status Data Item 940 with a status code value with failure mode 'Continue' can continue 941 normal operation of the session. 943 9.3. Peer Discovery Signal 945 A Peer Discovery Signal SHOULD be sent by a DLEP router to discover 946 DLEP modems in the network, see Section 4.1. 948 A Peer Discovery Signal MUST be encoded within a UDP packet. The 949 destination MUST be set to the DLEP well-known address and port 950 number. For routers supporting both IPv4 and IPv6 DLEP operation, it 951 is RECOMMENDED that IPv6 be selected as the transport. The source IP 952 address MUST be set to the router IP address associated with the DLEP 953 interface. There is no DLEP-specific restriction on source port. 955 To construct a Peer Discovery Signal, the Signal Type value in the 956 Signal Header is set to 1, from Table 1. 958 The Peer Discovery Signal MAY contain a Peer Type Data Item 959 (Section 10.4). 961 9.4. Peer Offer Signal 963 A Peer Offer Signal MUST be sent by a DLEP modem in response to a 964 properly formatted and addressed Peer Discovery Signal (Section 9.3). 966 A Peer Offer Signal MUST be encoded within a UDP packet. The IP 967 destination MUST be set to the IP address and port number received in 968 the corresponding Peer Discovery Signal. The source IP address MUST 969 be set to the modem's IP address associated with the DLEP interface. 970 The source port number MUST be set to the DLEP well-known port 971 number. The Peer Offer Signal completes the discovery process, see 972 Section 4.1. 974 To construct a Peer Offer Signal, the Signal Type value in the Signal 975 Header is set to 2, from Table 1. 977 The Peer Offer Signal MAY contain a Peer Type Data Item 978 (Section 10.4). 980 The Peer Offer Signal MAY contain one or more of any of the following 981 Data Items, with different values: 983 o IPv4 Connection Point (Section 10.2) 985 o IPv6 Connection Point (Section 10.3) 987 The IP Connection Point Data Items indicate the unicast address the 988 router MUST use when connecting the DLEP TCP session. 990 9.5. Session Initialization Message 992 A Session Initialization Message MUST be sent by a DLEP router as the 993 first Message of the DLEP TCP session. It is sent by the router 994 after a TCP connect to an address/port combination that was obtained 995 either via receipt of a Peer Offer, or from a priori configuration. 997 To construct a Session Initialization Message, the Message Type value 998 in the Message Header is set to 1, from Table 2. 1000 The Session Initialization Message MUST contain a Heartbeat Interval 1001 Data Item (Section 10.5). 1003 The Session Initialization Message MAY contain one of each of the 1004 following Data Items: 1006 o Peer Type (Section 10.4) 1008 o Extensions Supported (Section 10.6) 1010 If any optional extensions are supported by the implementation, they 1011 MUST be enumerated in the Extensions Supported Data Item. If an 1012 Extensions Supported Data Item does not exist in a Session 1013 Initialization Message, the modem MUST conclude that there is no 1014 support for extensions in the router. 1016 DLEP Heartbeats are not fully established until receipt of the 1017 Session Initialization Response Message (Section 9.6), and therefore 1018 implementations MUST use their own timeout and retry heuristics for 1019 this Message. 1021 As an exception to the general rule governing an implementation 1022 receiving an unrecognized Data Item in a Message, see Section 9.1, if 1023 a Session Initialization Message contains one or more Extension 1024 Supported Data Items announcing support for extensions that the 1025 implementation does not recognize, then the implementation MAY ignore 1026 Data Items it does not recognize. 1028 9.6. Session Initialization Response Message 1030 A Session Initialization Response Message MUST be sent in response to 1031 a received Session Initialization Message (Section 9.5). 1033 To construct a Session Initialization Response Message, the Message 1034 Type value in the Message Header is set to 2, from Table 2. 1036 The Session Initialization Response Message MUST contain one of each 1037 of the following Data Items: 1039 o Status (Section 10.1) 1041 o Heartbeat Interval (Section 10.5) 1043 o Maximum Data Rate (Receive) (Section 10.12) 1044 o Maximum Data Rate (Transmit) (Section 10.13) 1046 o Current Data Rate (Receive) (Section 10.14) 1048 o Current Data Rate (Transmit) (Section 10.15) 1050 o Latency (Section 10.16) 1052 The Session Initialization Response Message MUST contain one of each 1053 of the following Data Items, if the Data Item will be used during the 1054 lifetime of the session: 1056 o Resources (Section 10.17) 1058 o Relative Link Quality (Receive) (Section 10.18) 1060 o Relative Link Quality (Transmit) (Section 10.19) 1062 o Maximum Transmission Unit (MTU) (Section 10.20) 1064 The Session Initialization Response Message MAY contain one of each 1065 of the following Data Items: 1067 o Peer Type (Section 10.4) 1069 o Extensions Supported (Section 10.6) 1071 The Session Initialization Response Message completes the DLEP 1072 session establishment; the modem should transition to the In-Session 1073 state when the Message is sent, and the router should transition to 1074 the In-Session state upon receipt of an acceptable Session 1075 Initialization Response Message. 1077 All supported metric Data Items MUST be included in the Session 1078 Initialization Response Message, with default values to be used on a 1079 session-wide basis. This can be viewed as the modem 'declaring' all 1080 supported metrics at DLEP session initialization. Receipt of any 1081 further DLEP Message containing a metric Data Item not included in 1082 the Session Initialization Response Message MUST be treated as an 1083 error, resulting in the termination of the DLEP session between 1084 router and modem. 1086 If any optional extensions are supported by the modem, they MUST be 1087 enumerated in the Extensions Supported Data Item. If an Extensions 1088 Supported Data Item does not exist in a Session Initialization 1089 Response Message, the router MUST conclude that there is no support 1090 for extensions in the modem. 1092 After the Session Initialization/Session Initialization Response 1093 Messages have been successfully exchanged, implementations MUST only 1094 use extensions that are supported by both DLEP participants, see 1095 Section 4.2. 1097 9.7. Session Update Message 1099 A Session Update Message MAY be sent by a DLEP participant to 1100 indicate local Layer 3 address changes, or metric changes on a 1101 session-wide basis. 1103 To construct a Session Update Message, the Message Type value in the 1104 Message Header is set to 3, from Table 2. 1106 The Session Update Message MAY contain one of each of the following 1107 Data Items: 1109 o Maximum Data Rate (Receive) (Section 10.12) 1111 o Maximum Data Rate (Transmit) (Section 10.13) 1113 o Current Data Rate (Receive) (Section 10.14) 1115 o Current Data Rate (Transmit) (Section 10.15) 1117 o Latency (Section 10.16) 1119 The Session Update Message MAY contain one of each of the following 1120 Data Items, if the Data Item is in use by the session: 1122 o Resources (Section 10.17) 1124 o Relative Link Quality (Receive) (Section 10.18) 1126 o Relative Link Quality (Transmit) (Section 10.19) 1128 o Maximum Transmission Unit (MTU) (Section 10.20) 1130 The Session Update Message MAY contain one or more of each of the 1131 following Data Items, with different values: 1133 o IPv4 Address (Section 10.8) 1135 o IPv6 Address (Section 10.9) 1137 If metrics are supplied with the Session Update Message (e.g., 1138 Maximum Data Rate), these metrics are considered to be session-wide, 1139 and therefore MUST be applied to all destinations in the information 1140 base associated with the DLEP session. This includes destinations 1141 for which metrics may have been stored based on received Destination 1142 Update messages. 1144 It should be noted that Session Update Messages can be sent by both 1145 routers and modems. For example, addition of an IPv4 address to the 1146 router MAY prompt a Session Update Message to its attached modems. 1147 Also, for example, a modem that changes its Maximum Data Rate 1148 (Receive) for all destinations MAY reflect that change via a Session 1149 Update Message to its attached router(s). 1151 Concerning Layer 3 addresses: If the modem is capable of 1152 understanding and forwarding this information (via proprietary 1153 mechanisms), the address update would prompt any remote DLEP modems 1154 (DLEP-enabled modems in a remote node) to issue a Destination Update 1155 Message (Section 9.17) to their local routers with the new (or 1156 deleted) addresses. Modems that do not track Layer 3 addresses 1157 SHOULD silently ignore Address Data Items. 1159 9.8. Session Update Response Message 1161 A Session Update Response Message MUST be sent by a DLEP participant 1162 when a Session Update Message (Section 9.7) is received. 1164 To construct a Session Update Response Message, the Message Type 1165 value in the Message Header is set to 4, from Table 2. 1167 The Session Update Response Message MUST contain a Status Data Item 1168 (Section 10.1). 1170 9.9. Session Termination Message 1172 A Session Termination Message MUST be sent by a DLEP participant when 1173 the DLEP session needs to be terminated. 1175 To construct a Session Termination Message, the Message Type value in 1176 the Message Header is set to 5, from Table 2. 1178 The Session Termination Message MUST contain Status Data Item 1179 (Section 10.1). 1181 It should be noted that Session Termination Messages can be sent by 1182 both routers and modems. 1184 9.10. Session Termination Response Message 1186 A Session Termination Response Message MUST be sent by a DLEP 1187 participant when a Session Termination Message (Section 9.9) is 1188 received. 1190 To construct a Session Termination Response Message, the Message Type 1191 value in the Message Header is set to 6, from Table 2. 1193 There are no valid Data Items for the Session Termination Response 1194 Message. 1196 Receipt of a Session Termination Response Message completes the tear- 1197 down of the DLEP session, see Section 4.4. 1199 9.11. Destination Up Message 1201 Destination Up Messages MAY be sent by a modem to inform its attached 1202 router of the presence of a new reachable destination. 1204 To construct a Destination Up Message, the Message Type value in the 1205 Message Header is set to 7, from Table 2. 1207 The Destination Up Message MUST contain a MAC Address Data Item 1208 (Section 10.7). 1210 The Destination Up Message SHOULD contain one or more of each of the 1211 following Data Items, with different values: 1213 o IPv4 Address (Section 10.8) 1215 o IPv6 Address (Section 10.9) 1217 The Destination Up Message MAY contain one of each of the following 1218 Data Items: 1220 o Maximum Data Rate (Receive) (Section 10.12) 1222 o Maximum Data Rate (Transmit) (Section 10.13) 1224 o Current Data Rate (Receive) (Section 10.14) 1226 o Current Data Rate (Transmit) (Section 10.15) 1228 o Latency (Section 10.16) 1230 The Destination Up Message MAY contain one of each of the following 1231 Data Items, if the Data Item is in use by the session: 1233 o Resources (Section 10.17) 1235 o Relative Link Quality (Receive) (Section 10.18) 1237 o Relative Link Quality (Transmit) (Section 10.19) 1239 o Maximum Transmission Unit (MTU) (Section 10.20) 1241 The Destination Up Message MAY contain one or more of each of the 1242 following Data Items, with different values: 1244 o IPv4 Attached Subnet (Section 10.10) 1246 o IPv6 Attached Subnet (Section 10.11) 1248 A router receiving a Destination Up Message allocates the necessary 1249 resources, creating an entry in the information base with the 1250 specifics (MAC Address, Latency, Data Rate, etc.) of the destination. 1251 The information about this destination will persist in the router's 1252 information base until a Destination Down Message (Section 9.15) is 1253 received, indicating that the modem has lost contact with the remote 1254 node, or the implementation transitions to the Session Termination 1255 state. 1257 9.12. Destination Up Response Message 1259 A router MUST send a Destination Up Response Message when a 1260 Destination Up Message (Section 9.11) is received. 1262 To construct a Destination Up Response Message, the Message Type 1263 value in the Message Header is set to 8, from Table 2. 1265 The Destination Up Response Message MUST contain one of each of the 1266 following Data Items: 1268 o MAC Address (Section 10.7) 1270 o Status (Section 10.1) 1272 A router that wishes to receive further information concerning the 1273 destination identified in the corresponding Destination Up Message 1274 MUST set the status code of the included Status Data Item to 0 1275 'Success', see Table 4. 1277 If the router has no interest in the destination identified in the 1278 corresponding Destination Up Message, then it MAY set the status code 1279 of the included Status Data Item to 1 'Not Interested'. 1281 A modem receiving a Destination Up Response Message containing a 1282 Status Data Item with status code of any value other than 0 'Success' 1283 MUST NOT send further Destination messages about the destination, 1284 e.g. Destination Down (Section 9.15) or Destination Update 1285 (Section 9.17) with the same MAC address. 1287 9.13. Destination Announce Message 1289 Usually a modem will discover the presence of one or more remote 1290 router/modem pairs and announce each destination's arrival by sending 1291 a corresponding Destination Up Message (Section 9.11) to the router. 1292 However, there may be times when a router wishes to express an 1293 interest in a destination that has yet to be announced, typically a 1294 multicast destination. Destination Announce Messages MAY be sent by 1295 a router to announce such an interest. 1297 A Destination Announce Message MAY also be sent by a router to 1298 request information concerning a destination in which it has 1299 previously declined interest, via the 1 'Not Interested' status code 1300 in a Destination Up Response Message (Section 9.12), see Table 4, or 1301 declared as 'down', via the Destination Down Message (Section 9.15). 1303 To construct a Destination Announce Message, the Message Type value 1304 in the Message Header is set to 9, from Table 2. 1306 The Destination Announce Message MUST contain a MAC Address Data Item 1307 (Section 10.7). 1309 The Destination Announce Message MAY contain zero or more of the 1310 following Data Items, with different values: 1312 o IPv4 Address (Section 10.8) 1314 o IPv6 Address (Section 10.9) 1316 One of the advantages of implementing DLEP is to leverage the modem's 1317 knowledge of the links between remote destinations allowing routers 1318 to avoid using probed neighbor discovery techniques, therefore modem 1319 implementations SHOULD announce available destinations via the 1320 Destination Up Message, rather than relying on Destination Announce 1321 Messages. 1323 9.14. Destination Announce Response Message 1325 A modem MUST send a Destination Announce Response Message when a 1326 Destination Announce Message (Section 9.13) is received. 1328 To construct a Destination Announce Response Message, the Message 1329 Type value in the Message Header is set to 10, from Table 2. 1331 The Destination Announce Response Message MUST contain one of each of 1332 the following Data Items: 1334 o MAC Address (Section 10.7) 1336 o Status (Section 10.1) 1338 The Destination Announce Response Message MAY contain one of each of 1339 the following Data Items: 1341 o Maximum Data Rate (Receive) (Section 10.12) 1343 o Maximum Data Rate (Transmit) (Section 10.13) 1345 o Current Data Rate (Receive) (Section 10.14) 1347 o Current Data Rate (Transmit) (Section 10.15) 1349 o Latency (Section 10.16) 1351 The Destination Announce Response Message MAY contain one of each of 1352 the following Data Items, if the Data Item is in use by the session: 1354 o Resources (Section 10.17) 1356 o Relative Link Quality (Receive) (Section 10.18) 1358 o Relative Link Quality (Transmit) (Section 10.19) 1360 o Maximum Transmission Unit (MTU) (Section 10.20) 1362 If a modem is unable to report information immediately about the 1363 requested information, if the destination is not currently reachable, 1364 for example, the status code in the Status Data Item MUST be set to 2 1365 'Request Denied', see Table 4. 1367 After sending a Destination Announce Response Message containing a 1368 Status Data Item with status code of 0 'Success', a modem then 1369 announces changes to the link to the destination via Destination 1370 Update Messages. 1372 When a successful Destination Announce Response Message is received, 1373 the router should add knowledge of the available destination to its 1374 information base. 1376 9.15. Destination Down Message 1378 A modem MUST send a Destination Down Message to report when a 1379 destination (a remote node or a multicast group) is no longer 1380 reachable. 1382 A router MAY send a Destination Down Message to report when it no 1383 longer requires information concerning a destination. 1385 To construct a Destination Down Message, the Message Type value in 1386 the Message Header is set to 11, from Table 2. 1388 The Destination Down Message MUST contain a MAC Address Data Item 1389 (Section 10.7). 1391 It should be noted that both modem and router may send a Destination 1392 Down Message to their peer, regardless of which participant initially 1393 indicated the destination to be 'up'. 1395 9.16. Destination Down Response Message 1397 A Destination Down Response MUST be sent by the recipient of a 1398 Destination Down Message (Section 9.15) to confirm that the relevant 1399 data concerning the destination has been removed from the information 1400 base. 1402 To construct a Destination Down Response Message, the Message Type 1403 value in the Message Header is set to 12, from Table 2. 1405 The Destination Down Response Message MUST contain one of each of the 1406 following Data Items: 1408 o MAC Address (Section 10.7) 1410 o Status (Section 10.1) 1412 9.17. Destination Update Message 1414 A modem SHOULD send the Destination Update Message when it detects 1415 some change in the information base for a given destination (remote 1416 node or multicast group). Some examples of changes that would prompt 1417 a Destination Update Message are: 1419 o Change in link metrics (e.g., Data Rates) 1421 o Layer 3 addressing change 1422 To construct a Destination Update Message, the Message Type value in 1423 the Message Header is set to 13, from Table 2. 1425 The Destination Update Message MUST contain a MAC Address Data Item 1426 (Section 10.7). 1428 The Destination Update Message MAY contain one of each of the 1429 following Data Items: 1431 o Maximum Data Rate (Receive) (Section 10.12) 1433 o Maximum Data Rate (Transmit) (Section 10.13) 1435 o Current Data Rate (Receive) (Section 10.14) 1437 o Current Data Rate (Transmit) (Section 10.15) 1439 o Latency (Section 10.16) 1441 The Destination Update Message MAY contain one of each of the 1442 following Data Items, if the Data Item is in use by the session: 1444 o Resources (Section 10.17) 1446 o Relative Link Quality (Receive) (Section 10.18) 1448 o Relative Link Quality (Transmit) (Section 10.19) 1450 o Maximum Transmission Unit (MTU) (Section 10.20) 1452 The Destination Update Message MAY contain one or more of each of the 1453 following Data Items, with different values: 1455 o IPv4 Address (Section 10.8) 1457 o IPv6 Address (Section 10.9) 1459 o IPv4 Attached Subnet (Section 10.10) 1461 o IPv6 Attached Subnet (Section 10.11) 1463 If metrics are supplied with the Message (e.g., Resources), these 1464 metrics are MUST be applied to all destinations identified in the 1465 Message. Note that this may overwrite metrics provided in a 1466 previously received Session or Destination Up Messages. 1468 It should be noted that this Message has no corresponding response. 1470 9.18. Link Characteristics Request Message 1472 The Link Characteristics Request Message MAY be sent by a router to 1473 request that the modem initiate changes for specific characteristics 1474 of the link. The request can reference either a real destination 1475 (e.g., a remote node), or a logical destination (e.g., a multicast 1476 group) within the network. 1478 To construct a Link Characteristics Request Message, the Message Type 1479 value in the Message Header is set to 14, from Table 2. 1481 The Link Characteristics Request Message MUST contain one of the 1482 following Data Items: 1484 o MAC Address (Section 10.7) 1486 The Link Characteristics Request Message MUST contain at least one of 1487 each of the following Data Items: 1489 o Current Data Rate (Receive) (Section 10.14) 1491 o Current Data Rate (Transmit) (Section 10.15) 1493 o Latency (Section 10.16) 1495 The Link Characteristics Request Message MAY contain either a Current 1496 Data Rate (CDRR or CDRT) Data Item to request a different datarate 1497 than is currently allocated, a Latency Data Item to request that 1498 traffic delay on the link not exceed the specified value, or both. 1500 The router sending a Link Characteristics Request Message should be 1501 aware that a request may take an extended period of time to complete. 1503 9.19. Link Characteristics Response Message 1505 A modem MUST send a Link Characteristics Response Message when a Link 1506 Characteristics Request Message (Section 9.18) is received. 1508 To construct a Link Characteristics Response Message, the Message 1509 Type value in the Message Header is set to 15, from Table 2. 1511 The Link Characteristics Response Message MUST contain one of each of 1512 the following Data Items: 1514 o MAC Address (Section 10.7) 1516 o Status (Section 10.1) 1517 The Link Characteristics Response Message SHOULD contain one of each 1518 of the following Data Items: 1520 o Maximum Data Rate (Receive) (Section 10.12) 1522 o Maximum Data Rate (Transmit) (Section 10.13) 1524 o Current Data Rate (Receive) (Section 10.14) 1526 o Current Data Rate (Transmit) (Section 10.15) 1528 o Latency (Section 10.16) 1530 The Link Characteristics Response Message MAY contain one of each of 1531 the following Data Items, if the Data Item is in use by the session: 1533 o Resources (Section 10.17) 1535 o Relative Link Quality (Receive) (Section 10.18) 1537 o Relative Link Quality (Transmit) (Section 10.19) 1539 o Maximum Transmission Unit (MTU) (Section 10.20) 1541 The Link Characteristics Response Message MUST contain a complete set 1542 of metric Data Items, referencing all metrics declared in the Session 1543 Initialization Response Message (Section 9.6). The values in the 1544 metric Data Items in the Link Characteristics Response Message MUST 1545 reflect the link characteristics after the request has been 1546 processed. 1548 If an implementation is not able to alter the characteristics of the 1549 link in the manner requested, then the status code of the Status Data 1550 Item MUST be set to 2 'Request Denied', see Table 4. 1552 9.20. Heartbeat Message 1554 A Heartbeat Message MUST be sent by a DLEP participant every N 1555 milliseconds, where N is defined in the Heartbeat Interval Data Item 1556 (Section 10.5) of the Session Initialization Message (Section 9.5) or 1557 Session Initialization Response Message (Section 9.6). 1559 To construct a Heartbeat Message, the Message Type value in the 1560 Message Header is set to 16, from Table 2. 1562 There are no valid Data Items for the Heartbeat Message. 1564 The Message is used by DLEP participants to detect when a DLEP 1565 session peer (either the modem or the router) is no longer 1566 communicating, see Section 4.3.1. 1568 10. DLEP Data Items 1570 Following is the list of core Data Items that MUST be recognized by a 1571 DLEP compliant implementation. As mentioned before, not all Data 1572 Items need be used during a session, but an implementation MUST 1573 correctly process these Data Items when correctly associated with a 1574 Signal or Message. 1576 The core DLEP Data Items are: 1578 +-------------+-----------------------------------------------------+ 1579 | Type Code | Description | 1580 +-------------+-----------------------------------------------------+ 1581 | 0 | Reserved | 1582 | 1 | Status (Section 10.1) | 1583 | 2 | IPv4 Connection Point (Section 10.2) | 1584 | 3 | IPv6 Connection Point (Section 10.3) | 1585 | 4 | Peer Type (Section 10.4) | 1586 | 5 | Heartbeat Interval (Section 10.5) | 1587 | 6 | Extensions Supported (Section 10.6) | 1588 | 7 | MAC Address (Section 10.7) | 1589 | 8 | IPv4 Address (Section 10.8) | 1590 | 9 | IPv6 Address (Section 10.9) | 1591 | 10 | IPv4 Attached Subnet (Section 10.10) | 1592 | 11 | IPv6 Attached Subnet (Section 10.11) | 1593 | 12 | Maximum Data Rate (Receive) (MDRR) (Section 10.12) | 1594 | 13 | Maximum Data Rate (Transmit) (MDRT) (Section 10.13) | 1595 | 14 | Current Data Rate (Receive) (CDRR) (Section 10.14) | 1596 | 15 | Current Data Rate (Transmit) (CDRT) (Section 10.15) | 1597 | 16 | Latency (Section 10.16) | 1598 | 17 | Resources (RES) (Section 10.17) | 1599 | 18 | Relative Link Quality (Receive) (RLQR) (Section | 1600 | | 10.18) | 1601 | 19 | Relative Link Quality (Transmit) (RLQT) (Section | 1602 | | 10.19) | 1603 | 20 | Maximum Transmission Unit (MTU) (Section 10.20) | 1604 | 21-65407 | Reserved for future extensions | 1605 | 65408-65534 | Private Use. Available for experiments | 1606 | 65535 | Reserved | 1607 +-------------+-----------------------------------------------------+ 1609 Table 3: DLEP Data Item types 1611 10.1. Status 1613 For the Session Termination Message (Section 9.9), the Status Data 1614 Item indicates a reason for the termination. For all response 1615 Messages, the Status Data Item is used to indicate the success or 1616 failure of the previously received Message. 1618 The Status Data Item includes an optional Text field that can be used 1619 to provide a textual description of the status. The use of the Text 1620 field is entirely up to the receiving implementation, e.g., it could 1621 be output to a log file or discarded. If no Text field is supplied 1622 with the Status Data Item, the Length field MUST be set to 1. 1624 The Status Data Item contains the following fields: 1626 0 1 2 3 1627 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1629 | Data Item Type | Length | 1630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1631 | Code | Text... : 1632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1634 Data Item Type: 1 1636 Length: 1 + Length of text, in octets 1638 Status Code: One of the codes defined in Table 4 below. 1640 Text: UTF-8 encoded string of UNICODE [UNIV8] characters, describing 1641 the cause, used for implementation defined purposes. Since this 1642 field is used for description, implementations SHOULD limit 1643 characters in this field to printable characters. Implementations 1644 receiving this Data Item SHOULD check for printable characters in 1645 the field. 1647 An implementation MUST NOT assume the Text field is NUL-terminated. 1649 +----------+-------------+------------------+-----------------------+ 1650 | Status | Failure | Description | Reason | 1651 | Code | Mode | | | 1652 +----------+-------------+------------------+-----------------------+ 1653 | 0 | Continue | Success | The Message was | 1654 | | | | processed | 1655 | | | | successfully. | 1656 | 1 | Continue | Not Interested | The receiver is not | 1657 | | | | interested in this | 1658 | | | | Message subject, e.g. | 1659 | | | | in a Destination Up | 1660 | | | | Response Message | 1661 | | | | (Section 9.12) to | 1662 | | | | indicate no further | 1663 | | | | Messages about the | 1664 | | | | destination. | 1665 | 2 | Continue | Request Denied | The receiver refuses | 1666 | | | | to complete the | 1667 | | | | request. | 1668 | 3-111 | Continue | | Reserved for future | 1669 | | | | extensions. | 1670 | 112-127 | Continue | | Available for | 1671 | | | | experiments. | 1672 | 128 | Terminate | Unknown Message | The Message was not | 1673 | | | | recognized by the | 1674 | | | | implementation. | 1675 | 129 | Terminate | Unexpected | The Message was not | 1676 | | | Message | expected while the | 1677 | | | | device was in the | 1678 | | | | current state, e.g., | 1679 | | | | a Session | 1680 | | | | Initialization | 1681 | | | | Message (Section 9.5) | 1682 | | | | in the In-Session | 1683 | | | | state. | 1684 | 130 | Terminate | Invalid Data | One or more Data | 1685 | | | | Items in the Message | 1686 | | | | are invalid, | 1687 | | | | unexpected or | 1688 | | | | incorrectly | 1689 | | | | duplicated. | 1690 | 131 | Terminate | Invalid | The destination | 1691 | | | Destination | included in the | 1692 | | | | Message does not | 1693 | | | | match a previously | 1694 | | | | announced | 1695 | | | | destination. For | 1696 | | | | example, in the Link | 1697 | | | | Characteristic | 1698 | | | | Response Message | 1699 | | | | (Section 9.19). | 1700 | 132 | Terminate | Timed Out | The session has timed | 1701 | | | | out. | 1702 | 133-239 | Terminate | | Reserved for future | 1703 | | | | extensions. | 1704 | 240-254 | Terminate | | Available for | 1705 | | | | experiments. | 1706 | 255 | Terminate | | Reserved. | 1707 +----------+-------------+------------------+-----------------------+ 1709 Table 4: DLEP Status Codes 1711 10.2. IPv4 Connection Point 1713 The IPv4 Connection Point Data Item indicates the IPv4 address and, 1714 optionally, the TCP port number on the modem available for 1715 connections. If provided, the router MUST use this information to 1716 initiate the TCP connection to the modem. 1718 The IPv4 Connection Point Data Item contains the following fields: 1720 0 1 2 3 1721 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 1722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1723 | Data Item Type | Length | 1724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1725 | Flags | IPv4 Address... : 1726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1727 : ...cont. | TCP Port Number (optional) | 1728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1730 Data Item Type: 2 1732 Length: 5 (or 7 if TCP Port included) 1734 Flags: Flags field, defined below. 1736 IPv4 Address: The IPv4 address listening on the modem. 1738 TCP Port Number: TCP Port number on the modem. 1740 If the Length field is 7, the port number specified MUST be used to 1741 establish the TCP session. If the TCP Port Number is omitted, i.e. 1742 the Length field is 5, the router MUST use the DLEP well-known port 1743 number (Section 12.7) to establish the TCP connection. 1745 The Flags field is defined as: 1747 0 1 2 3 4 5 6 7 1748 +-+-+-+-+-+-+-+-+ 1749 | Reserved | 1750 +-+-+-+-+-+-+-+-+ 1752 Reserved: MUST be zero. Reserved for future use. 1754 10.3. IPv6 Connection Point 1756 The IPv6 Connection Point Data Item indicates the IPv6 address and, 1757 optionally, the TCP port number on the modem available for 1758 connections. If provided, the router MUST use this information to 1759 initiate the TCP connection to the modem. 1761 The IPv6 Connection Point Data Item contains the following fields: 1763 0 1 2 3 1764 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 1765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1766 | Data Item Type | Length | 1767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1768 | Flags | IPv6 Address : 1769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1770 : IPv6 Address : 1771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1772 : IPv6 Address : 1773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1774 : IPv6 Address : 1775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1776 : ...cont. | TCP Port Number (optional) | 1777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1779 Data Item Type: 3 1781 Length: 17 (or 19 if TCP Port included) 1783 Flags: Flags field, defined below. 1785 IPv6 Address: The IPv6 address listening on the modem. 1787 TCP Port Number: TCP Port number on the modem. 1789 If the Length field is 19, the port number specified MUST be used to 1790 establish the TCP session. If the TCP Port Number is omitted, i.e. 1791 the Length field is 17, the router MUST use the DLEP well-known port 1792 number (Section 12.7) to establish the TCP connection. 1794 The Flags field is defined as: 1796 0 1 2 3 4 5 6 7 1797 +-+-+-+-+-+-+-+-+ 1798 | Reserved | 1799 +-+-+-+-+-+-+-+-+ 1800 Reserved: MUST be zero. Reserved for future use. 1802 10.4. Peer Type 1804 The Peer Type Data Item is used by the router and modem to give 1805 additional information as to its type. The Peer Type is a string and 1806 is envisioned to be used for informational purposes (e.g., as output 1807 in a display command). 1809 The Peer Type Data Item contains the following fields: 1811 0 1 2 3 1812 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 1813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1814 | Data Item Type | Length | 1815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1816 | Peer Type... : 1817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1819 Data Item Type: 4 1821 Length: Length of Peer Type string, in octets. 1823 Peer Type: UTF-8 encoded string of UNICODE [UNIV8] characters. For 1824 example, a satellite modem might set this variable to "Satellite 1825 terminal". Since this Data Item is intended to provide additional 1826 information for display commands, sending implementations SHOULD 1827 limit the data to printable characters, and receiving 1828 implementations SHOULD check the data for printable characters. 1830 An implementation MUST NOT assume the Peer Type field is NUL- 1831 terminated. 1833 10.5. Heartbeat Interval 1835 The Heartbeat Interval Data Item is used to specify a period in 1836 milliseconds for Heartbeat Messages (Section 9.20). 1838 The Heartbeat Interval Data Item contains the following fields: 1840 0 1 2 3 1841 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 1842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1843 | Data Item Type | Length | 1844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1845 | Heartbeat Interval | 1846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1847 Data Item Type: 5 1849 Length: 4 1851 Heartbeat Interval: The interval in milliseconds, expressed as a 1852 32-bit unsigned integer, for Heartbeat Messages. This value MUST 1853 NOT be 0. 1855 10.6. Extensions Supported 1857 The Extensions Supported Data Item is used by the router and modem to 1858 negotiate additional optional functionality they are willing to 1859 support. The Extensions List is a concatenation of the types of each 1860 supported extension, found in the IANA DLEP Extensions repository. 1861 Each Extension Type definition includes which additional Signals and 1862 Data Items are supported. 1864 The Extensions Supported Data Item contains the following fields: 1866 0 1 2 3 1867 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 1868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1869 | Data Item Type | Length | 1870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1871 | Extensions List... 1872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1874 Data Item Type: 6 1876 Length: Length of the extensions list in octets. This is twice (2x) 1877 the number of extensions. 1879 Extension List: A list of extensions supported, identified by their 1880 2-octet value as listed in the extensions registry. 1882 10.7. MAC Address 1884 The MAC Address Data Item contains the address of the destination on 1885 the remote node. 1887 DLEP can support MAC addresses in either EUI-48 or EUI-64 format, 1888 with the restriction that all MAC addresses for a given DLEP session 1889 MUST be in the same format, and MUST be consistent with the MAC 1890 address format of the connected modem (e.g., if the modem is 1891 connected to the router with an EUI-48 MAC, all destination addresses 1892 via that modem MUST be expressed in EUI-48 format). 1894 Examples of a virtual destination would be a multicast MAC address, 1895 or the broadcast MAC (FF:FF:FF:FF:FF:FF). 1897 0 1 2 3 1898 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1900 | Data Item Type | Length | 1901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1902 | MAC Address : 1903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1904 : MAC Address : 1905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1906 : MAC Address : (if EUI-64 used) | 1907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1909 Data Item Type: 7 1911 Length: 6 for EUI-48 format, or 8 for EUI-64 format 1913 MAC Address: MAC Address of the destination. 1915 10.8. IPv4 Address 1917 When included in Destination Messages, this Data Item contains the 1918 IPv4 address of the destination. When included in the Session Update 1919 Message, this Data Item contains the IPv4 address of the peer. In 1920 either case, the Data Item also contains an indication of whether 1921 this is a new or existing address, or is a deletion of a previously 1922 known address. 1924 The IPv4 Address 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 | Flags | IPv4 Address : 1932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1933 : ...cont. | 1934 +-+-+-+-+-+-+-+-+ 1936 Data Item Type: 8 1938 Length: 5 1940 Flags: Flags field, defined below. 1942 IPv4 Address: The IPv4 address of the destination or peer. 1944 The Flags field is defined as: 1946 0 1 2 3 4 5 6 7 1947 +-+-+-+-+-+-+-+-+ 1948 | Reserved |A| 1949 +-+-+-+-+-+-+-+-+ 1951 A: Add/Drop flag, indicating whether this is a new or existing 1952 address (1), or a withdrawal of an address (0). 1954 Reserved: MUST be zero. Reserved for future use. 1956 10.9. IPv6 Address 1958 When included in Destination Messages, this Data Item contains the 1959 IPv6 address of the destination. When included in the Session Update 1960 Message, this Data Item contains the IPv6 address of the peer. In 1961 either case, the Data Item also contains an indication of whether 1962 this is a new or existing address, or is a deletion of a previously 1963 known address. 1965 The IPv6 Address Data Item contains the following fields: 1967 0 1 2 3 1968 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 1969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1970 | Data Item Type | Length | 1971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1972 | Flags | IPv6 Address : 1973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1974 : IPv6 Address : 1975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1976 : IPv6 Address : 1977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1978 : IPv6 Address : 1979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1980 : IPv6 Address | 1981 +-+-+-+-+-+-+-+-+ 1983 Data Item Type: 9 1985 Length: 17 1987 Flags: Flags field, defined below. 1989 IPv6 Address: IPv6 Address of the destination or peer. 1991 The Flags field is defined as: 1993 0 1 2 3 4 5 6 7 1994 +-+-+-+-+-+-+-+-+ 1995 | Reserved |A| 1996 +-+-+-+-+-+-+-+-+ 1998 A: Add/Drop flag, indicating whether this is a new or existing 1999 address (1), or a withdrawal of an address (0). 2001 Reserved: MUST be zero. Reserved for future use. 2003 10.10. IPv4 Attached Subnet 2005 The DLEP IPv4 Attached Subnet allows a device to declare that it has 2006 an IPv4 subnet (e.g., a stub network) attached, that it has become 2007 aware of an IPv4 subnet being present at a remote destination, or 2008 that it has become aware of the loss of a subnet at the remote 2009 destination. 2011 The DLEP IPv4 Attached Subnet Data Item contains the following 2012 fields: 2014 0 1 2 3 2015 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 2016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2017 | Data Item Type | Length | 2018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2019 | Flags | IPv4 Attached Subnet : 2020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2021 : ...cont. |Prefix Length | 2022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2024 Data Item Type: 10 2026 Length: 6 2028 Flags: Flags field, defined below. 2030 IPv4 Subnet: The IPv4 subnet reachable at the destination. 2032 Prefix Length: Length of the prefix (0-32) for the IPv4 subnet. A 2033 prefix length outside the specified range MUST be considered as 2034 invalid. 2036 The Flags field is defined as: 2038 0 1 2 3 4 5 6 7 2039 +-+-+-+-+-+-+-+-+ 2040 | Reserved |A| 2041 +-+-+-+-+-+-+-+-+ 2043 A: Add/Drop flag, indicating whether this is a new or existing subnet 2044 address (1), or a withdrawal of a subnet address (0). 2046 Reserved: MUST be zero. Reserved for future use. 2048 10.11. IPv6 Attached Subnet 2050 The DLEP IPv6 Attached Subnet allows a device to declare that it has 2051 an IPv6 subnet (e.g., a stub network) attached, that it has become 2052 aware of an IPv6 subnet being present at a remote destination, or 2053 that it has become aware of the loss of a subnet at the remote 2054 destination. 2056 The DLEP IPv6 Attached Subnet Data Item contains the following 2057 fields: 2059 0 1 2 3 2060 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 2061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2062 | Data Item Type | Length | 2063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2064 | Flags | IPv6 Attached Subnet : 2065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2066 : IPv6 Attached Subnet : 2067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2068 : IPv6 Attached Subnet : 2069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2070 : IPv6 Attached Subnet : 2071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2072 : ...cont. | Prefix Len. | 2073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2075 Data Item Type: 11 2077 Length: 18 2079 Flags: Flags field, defined below. 2081 IPv6 Attached Subnet: The IPv6 subnet reachable at the destination. 2083 Prefix Length: Length of the prefix (0-128) for the IPv6 subnet. A 2084 prefix length outside the specified range MUST be considered as 2085 invalid. 2087 The Flags field is defined as: 2089 0 1 2 3 4 5 6 7 2090 +-+-+-+-+-+-+-+-+ 2091 | Reserved |A| 2092 +-+-+-+-+-+-+-+-+ 2094 A: Add/Drop flag, indicating whether this is a new or existing subnet 2095 address (1), or a withdrawal of a subnet address (0). 2097 Reserved: MUST be zero. Reserved for future use. 2099 10.12. Maximum Data Rate (Receive) 2101 The Maximum Data Rate (Receive) (MDRR) Data Item is used to indicate 2102 the maximum theoretical data rate, in bits per second, that can be 2103 achieved while receiving data on the link. 2105 The Maximum Data Rate (Receive) Data Item contains the following 2106 fields: 2108 0 1 2 3 2109 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 2110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2111 | Data Item Type | Length | 2112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2113 | MDRR (bps) : 2114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2115 : MDRR (bps) | 2116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2118 Data Item Type: 12 2120 Length: 8 2122 Maximum Data Rate (Receive): A 64-bit unsigned integer, representing 2123 the maximum theoretical data rate, in bits per second (bps), that 2124 can be achieved while receiving on the link. 2126 10.13. Maximum Data Rate (Transmit) 2128 The Maximum Data Rate (Transmit) (MDRT) Data Item is used to indicate 2129 the maximum theoretical data rate, in bits per second, that can be 2130 achieved while transmitting data on the link. 2132 The Maximum Data Rate (Transmit) Data Item contains the following 2133 fields: 2135 0 1 2 3 2136 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 2137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2138 | Data Item Type | Length | 2139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2140 | MDRT (bps) : 2141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2142 : MDRT (bps) | 2143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2145 Data Item Type: 13 2147 Length: 8 2149 Maximum Data Rate (Transmit): A 64-bit unsigned integer, 2150 representing the maximum theoretical data rate, in bits per second 2151 (bps), that can be achieved while transmitting on the link. 2153 10.14. Current Data Rate (Receive) 2155 The Current Data Rate (Receive) (CDRR) Data Item is used to indicate 2156 the rate at which the link is currently operating for receiving 2157 traffic. 2159 When used in the Link Characteristics Request Message (Section 9.18), 2160 Current Data Rate (Receive) represents the desired receive rate, in 2161 bits per second, on the link. 2163 The Current Data Rate (Receive) Data Item contains the following 2164 fields: 2166 0 1 2 3 2167 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 2168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2169 | Data Item Type | Length | 2170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2171 | CDRR (bps) : 2172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2173 : CDRR (bps) | 2174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2176 Data Item Type: 14 2178 Length: 8 2180 Current Data Rate (Receive): A 64-bit unsigned integer, representing 2181 the current data rate, in bits per second, that can currently be 2182 achieved while receiving traffic on the link. 2184 If there is no distinction between Current Data Rate (Receive) and 2185 Maximum Data Rate (Receive) (Section 10.12), Current Data Rate 2186 (Receive) MUST be set equal to the Maximum Data Rate (Receive). The 2187 Current Data Rate (Receive) MUST NOT exceed the Maximum Data Rate 2188 (Receive). 2190 10.15. Current Data Rate (Transmit) 2192 The Current Data Rate (Transmit) (CDRT) Data Item is used to indicate 2193 the rate at which the link is currently operating for transmitting 2194 traffic. 2196 When used in the Link Characteristics Request Message (Section 9.18), 2197 Current Data Rate (Transmit) represents the desired transmit rate, in 2198 bits per second, on the link. 2200 The Current Data Rate (Transmit) Data Item contains the following 2201 fields: 2203 0 1 2 3 2204 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 2205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2206 | Data Item Type | Length | 2207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2208 | CDRT (bps) : 2209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2210 : CDRT (bps) | 2211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2213 Data Item Type: 15 2215 Length: 8 2217 Current Data Rate (Transmit): A 64-bit unsigned integer, 2218 representing the current data rate, in bits per second, that can 2219 currently be achieved while transmitting traffic on the link. 2221 If there is no distinction between Current Data Rate (Transmit) and 2222 Maximum Data Rate (Transmit) (Section 10.13), Current Data Rate 2223 (Transmit) MUST be set equal to the Maximum Data Rate (Transmit). 2224 The Current Data Rate (Transmit) MUST NOT exceed the Maximum Data 2225 Rate (Transmit). 2227 10.16. Latency 2229 The Latency Data Item is used to indicate the amount of latency, in 2230 microseconds, on the link. 2232 The Latency value is reported as transmission delay. The calculation 2233 of latency is implementation dependent. For example, the latency may 2234 be a running average calculated from the internal queuing. 2236 The Latency Data Item contains the following fields: 2238 0 1 2 3 2239 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 2240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2241 | Data Item Type | Length | 2242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2243 | Latency : 2244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2245 : Latency | 2246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2248 Data Item Type: 16 2250 Length: 8 2252 Latency: A 64-bit unsigned integer, representing the transmission 2253 delay, in microseconds, that a packet encounters as it is 2254 transmitted over the link. 2256 10.17. Resources 2258 The Resources (RES) Data Item is used to indicate the amount of 2259 finite resources available for data transmission and reception at the 2260 destination as a percentage, with 0 meaning 'no resources remaining', 2261 and 100 meaning 'a full supply', assuming that when Resources reaches 2262 0 data transmission and/or reception will cease. 2264 An example of such resources might be battery life, but could equally 2265 be magic beans. The list of resources that might be considered is 2266 beyond the scope of this document, and is left to implementations to 2267 decide. 2269 This Data Item is designed to be used as an indication of some 2270 capability of the modem and/or router at the destination. 2272 The Resources Data Item contains the following fields: 2274 0 1 2 3 2275 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 2276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2277 | Data Item Type | Length | 2278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2279 | RES | 2280 +-+-+-+-+-+-+-+-+ 2282 Data Item Type: 17 2284 Length: 1 2286 Resources: An 8-bit unsigned integer percentage, 0-100, representing 2287 the amount of resources available. Any value greater than 100 2288 MUST be considered as invalid. 2290 If a device cannot calculate Resources, this Data Item MUST NOT be 2291 issued. 2293 10.18. Relative Link Quality (Receive) 2295 The Relative Link Quality (Receive) (RLQR) Data Item is used to 2296 indicate the quality of the link to a destination for receiving 2297 traffic, with 0 meaning 'worst quality', and 100 meaning 'best 2298 quality'. 2300 Quality in this context is defined as an indication of the stability 2301 of a link for reception; a destination with high Relative Link 2302 Quality (Receive) is expected to have generally stable DLEP metrics, 2303 and the metrics of a destination with low Relative Link Quality 2304 (Receive) can be expected to rapidly fluctuate over a wide range. 2306 The Relative Link Quality (Receive) Data Item contains the following 2307 fields: 2309 0 1 2 3 2310 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 2311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2312 | Data Item Type | Length | 2313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2314 | RLQR | 2315 +-+-+-+-+-+-+-+-+ 2317 Data Item Type: 18 2319 Length: 1 2320 Relative Link Quality (Receive): A non-dimensional unsigned 8-bit 2321 integer, 0-100, representing relative quality of the link for 2322 receiving traffic. Any value greater than 100 MUST be considered 2323 as invalid. This is analogous to [RFC5578]. 2325 If a device cannot calculate the Relative Link Quality (Receive), 2326 this Data Item MUST NOT be issued. 2328 10.19. Relative Link Quality (Transmit) 2330 The Relative Link Quality (Transmit) (RLQT) Data Item is used to 2331 indicate the quality of the link to a destination for transmitting 2332 traffic, with 0 meaning 'worst quality', and 100 meaning 'best 2333 quality'. 2335 Quality in this context is defined as an indication of the stability 2336 of a link for transmission; a destination with high Relative Link 2337 Quality (Transmit) is expected to have generally stable DLEP metrics, 2338 and the metrics of a destination with low Relative Link Quality 2339 (Transmit) can be expected to rapidly fluctuate over a wide range. 2341 The Relative Link Quality (Transmit) Data Item contains the following 2342 fields: 2344 0 1 2 3 2345 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2347 | Data Item Type | Length | 2348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2349 | RLQT | 2350 +-+-+-+-+-+-+-+-+ 2352 Data Item Type: 19 2354 Length: 1 2356 Relative Link Quality (Transmit): A non-dimensional unsigned 8-bit 2357 integer, 0-100, representing relative quality of the link for 2358 transmitting traffic. Any value greater than 100 MUST be 2359 considered as invalid. 2361 If a device cannot calculate the Relative Link Quality (Transmit), 2362 this Data Item MUST NOT be issued. 2364 10.20. Maximum Transmission Unit (MTU) 2366 The Maximum Transmission Unit (MTU) Data Item is used to indicate the 2367 maximum size, in octets, of an IP packet that can be transmitted 2368 without fragmentation, including headers, but excluding any lower 2369 layer headers. 2371 The Maximum Transmission Unit Data Item contains the following 2372 fields: 2374 0 1 2 3 2375 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 2376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2377 | Data Item Type | Length | 2378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2379 | MTU | 2380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2382 Data Item Type: 20 2384 Length: 2 2386 Maximum Transmission Unit: The maximum size, in octets, of an IP 2387 packet that can be transmitted without fragmentation, including 2388 headers, but excluding any lower layer headers. 2390 If a device cannot calculate the Maximum Transmission Unit, this Data 2391 Item MUST NOT be issued. 2393 11. Security Considerations 2395 The potential security concerns when using DLEP are: 2397 1. An attacker might pretend to be a DLEP participant, either at 2398 DLEP session initialization, or by injection of DLEP Messages 2399 once a session has been established, and/or 2401 2. DLEP Data Items could be altered by an attacker, causing the 2402 receiving implementation to inappropriately alter its information 2403 base concerning network status. 2405 Since DLEP is restricted to operation over a single (possibly 2406 logical) hop at layer 2, implementations requiring authentication 2407 and/or encryption of traffic MUST take steps to secure the Layer 2 2408 link. Examples of technologies that can be deployed to secure the 2409 Layer 2 link include [IEEE-802.1AE] and [IEEE-802.1X]. 2411 To avoid potential denial of service attack, it is RECOMMENDED that 2412 implementations using the Peer Discovery mechanism maintain an 2413 information base of hosts that persistently fail Session 2414 Initialization having provided an acceptable Peer Discovery Signal, 2415 and ignore subsequent Peer Discovery Signals from such hosts. 2417 This specification does not address security of the data plane, as it 2418 (the data plane) is not affected, and standard security procedures 2419 can be employed. 2421 12. IANA Considerations 2423 This section specifies requests to IANA. 2425 12.1. Registrations 2427 Upon approval of this document, IANA is requested to create a new 2428 protocol registry for Dynamic Link Exchange Protocol (DLEP). The 2429 remainder of this section requests the creation of new DLEP specific 2430 registries. 2432 12.2. Signal Type Registration 2434 Upon approval of this document, IANA is requested to create a new 2435 DLEP registry, named "Signal Type Values". 2437 The following table provides initial registry values and the 2438 [RFC5226] defined policies that should apply to the registry: 2440 +--------------+-------------------------+ 2441 | Type Code | Description/Policy | 2442 +--------------+-------------------------+ 2443 | 0 | Reserved | 2444 | 1 | Peer Discovery Signal | 2445 | 2 | Peer Offer Signal | 2446 | 3-65519 | Specification Required | 2447 | 65520-65534 | Private Use | 2448 | 65535 | Reserved | 2449 +--------------+-------------------------+ 2451 12.3. Message Type Registration 2453 Upon approval of this document, IANA is requested to create a new 2454 DLEP registry, named "Message Type Values". 2456 The following table provides initial registry values and the 2457 [RFC5226] defined policies that should apply to the registry: 2459 +--------------+------------------------------------------+ 2460 | Type Code | Description/Policy | 2461 +--------------+------------------------------------------+ 2462 | 0 | Reserved | 2463 | 1 | Session Initialization Message | 2464 | 2 | Session Initialization Response Message | 2465 | 3 | Session Update Message | 2466 | 4 | Session Update Response Message | 2467 | 5 | Session Termination Message | 2468 | 6 | Session Termination Response Message | 2469 | 7 | Destination Up Message | 2470 | 8 | Destination Up Response Message | 2471 | 9 | Destination Announce Message | 2472 | 10 | Destination Announce Response Message | 2473 | 11 | Destination Down Message | 2474 | 12 | Destination Down Response Message | 2475 | 13 | Destination Update Message | 2476 | 14 | Link Characteristics Request Message | 2477 | 15 | Link Characteristics Response Message | 2478 | 16 | Heartbeat Message | 2479 | 17-65519 | Specification Required | 2480 | 65520-65534 | Private Use | 2481 | 65535 | Reserved | 2482 +--------------+------------------------------------------+ 2484 12.4. DLEP Data Item Registrations 2486 Upon approval of this document, IANA is requested to create a new 2487 DLEP registry, named "Data Item Values". 2489 The following table provides initial registry values and the 2490 [RFC5226] defined policies that should apply to the registry: 2492 +-------------------+------------------------------------------+ 2493 | Type Code | Description/Policy | 2494 +-------------------+------------------------------------------+ 2495 | 0 | Reserved | 2496 | 1 | Status | 2497 | 2 | IPv4 Connection Point | 2498 | 3 | IPv6 Connection Point | 2499 | 4 | Peer Type | 2500 | 5 | Heartbeat Interval | 2501 | 6 | Extensions Supported | 2502 | 7 | MAC Address | 2503 | 8 | IPv4 Address | 2504 | 9 | IPv6 Address | 2505 | 10 | IPv4 Attached Subnet | 2506 | 11 | IPv6 Attached Subnet | 2507 | 12 | Maximum Data Rate (Receive) (MDRR) | 2508 | 13 | Maximum Data Rate (Transmit) (MDRT) | 2509 | 14 | Current Data Rate (Receive) (CDRR) | 2510 | 15 | Current Data Rate (Transmit) (CDRT) | 2511 | 16 | Latency | 2512 | 17 | Resources (RES) | 2513 | 18 | Relative Link Quality (Receive) (RLQR) | 2514 | 19 | Relative Link Quality (Transmit) (RLQT) | 2515 | 20 | Maximum Transmission Unit (MTU) | 2516 | 21-65407 | Specification Required | 2517 | 65408-65534 | Private Use | 2518 | 65535 | Reserved | 2519 +-------------------+------------------------------------------+ 2521 12.5. DLEP Status Code Registrations 2523 Upon approval of this document, IANA is requested to create a new 2524 DLEP registry, named "Status Code Values". 2526 The following table provides initial registry values and the 2527 [RFC5226] defined policies that should apply to the registry: 2529 +--------------+---------------+-------------------------+ 2530 | Status Code | Failure Mode | Description/Policy | 2531 +--------------+---------------+-------------------------+ 2532 | 0 | Continue | Success | 2533 | 1 | Continue | Not Interested | 2534 | 2 | Continue | Request Denied | 2535 | 3-111 | Continue | Specification Required | 2536 | 112-127 | Continue | Private Use | 2537 | 128 | Terminate | Unknown Message | 2538 | 129 | Terminate | Unexpected Message | 2539 | 130 | Terminate | Invalid Data | 2540 | 131 | Terminate | Invalid Destination | 2541 | 132 | Terminate | Timed Out | 2542 | 133-239 | Terminate | Specification Required | 2543 | 240-254 | Terminate | Private Use | 2544 | 255 | Terminate | Reserved | 2545 +--------------+---------------+-------------------------+ 2547 12.6. DLEP Extensions Registrations 2549 Upon approval of this document, IANA is requested to create a new 2550 DLEP registry, named "Extension Type Values". 2552 The following table provides initial registry values and the 2553 [RFC5226] defined policies that should apply to the registry: 2555 +--------------+----------------------------+ 2556 | Code | Description/Policy | 2557 +--------------+----------------------------+ 2558 | 0 | Reserved | 2559 | 1 | Credit Windowing [CREDIT] | 2560 | 2-65519 | Specification Required | 2561 | 65520-65534 | Private Use | 2562 | 65535 | Reserved | 2563 +--------------+----------------------------+ 2565 Table 5: DLEP Extension types 2567 12.7. DLEP Well-known Port 2569 Upon approval of this document, IANA is requested to assign a single 2570 value in the "Service Name and Transport Protocol Port Number 2571 Registry" found at https://www.iana.org/assignments/service-names- 2572 port-numbers/service-names-port-numbers.xhtml for use by "DLEP", as 2573 defined in this document. This assignment should be valid for TCP 2574 and UDP. SCTP port allocation is not required. 2576 12.8. DLEP IPv4 Link-local Multicast Address 2578 Upon approval of this document, IANA is requested to assign an IPv4 2579 multicast address registry found at http://www.iana.org/assignments/ 2580 multicast-addresses for use as the "IPv4 DLEP Discovery Address". 2582 12.9. DLEP IPv6 Link-local Multicast Address 2584 Upon approval of this document, IANA is requested to assign an IPv6 2585 multicast address registry found at http://www.iana.org/assignments/ 2586 multicast-addresses for use as the "IPv6 DLEP Discovery Address". 2588 13. Acknowledgements 2590 We would like to acknowledge and thank the members of the DLEP design 2591 team, who have provided invaluable insight. The members of the 2592 design team are: Teco Boot, Bow-Nan Cheng, John Dowdell, and Henning 2593 Rogge. 2595 We would also like to acknowledge the influence and contributions of 2596 Greg Harrison, Chris Olsen, Martin Duke, Subir Das, Jaewon Kang, 2597 Vikram Kaul, Nelson Powell, Lou Berger, and Victoria Mercieca. 2599 14. References 2601 14.1. Normative References 2603 [CREDIT] Ratliff, S., "Credit Windowing extension for DLEP", IETF 2604 draft draft-ietf-manet-credit-window-04, March 2016. 2606 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2607 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 2608 RFC2119, March 1997, 2609 . 2611 [UNIV8] "The Unicode Consortium. The Unicode Standard, Version 2612 8.0.0, (Mountain View, CA: The Unicode Consortium, 2015. 2613 ISBN 978-1-936213-10-8)", 2614 http://www.unicode.org/versions/Unicode8.0.0/, June 2015. 2616 14.2. Informative References 2618 [IEEE-802.1AE] 2619 "IEEE Standards for Local and Metropolitan Area Networks: 2620 Media Access Control (MAC) Security", DOI 10.1109/ 2621 IEEESTD.2006.245590, August 2006. 2623 [IEEE-802.1X] 2624 "IEEE Standards for Local and Metropolitan Area Networks: 2625 Port based Network Access Control", DOI 10.1109/ 2626 IEEESTD.2010.5409813, February 2010. 2628 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2629 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2630 DOI 10.17487/RFC5226, May 2008, 2631 . 2633 [RFC5578] Berry, B., Ed., Ratliff, S., Paradise, E., Kaiser, T., and 2634 M. Adams, "PPP over Ethernet (PPPoE) Extensions for Credit 2635 Flow and Link Metrics", RFC 5578, DOI 10.17487/RFC5578, 2636 February 2010, . 2638 Appendix A. Discovery Signal Flows 2640 Router Modem Signal Description 2641 ======================================================================== 2643 | Router initiates discovery, starts 2644 | a timer, send Peer Discovery 2645 |-------Peer Discovery---->X Signal. 2647 ~ ~ ~ ~ ~ ~ ~ Router discovery timer expires 2648 without receiving Peer Offer. 2650 | Router sends another Peer 2651 |-------Peer Discovery---------->| Discovery Signal. 2652 | 2653 | Modem receives Peer Discovery 2654 | Signal. 2655 | 2656 | Modem sends Peer Offer with 2657 |<--------Peer Offer-------------| Connection Point information. 2658 : 2659 : Router MAY cancel discovery timer 2660 : and stop sending Peer Discovery 2661 : Signals. 2663 Appendix B. Peer Level Message Flows 2665 B.1. Session Initialization 2666 Router Modem Message Description 2667 ======================================================================== 2669 | Router connects to discovered or 2670 | pre-configured Modem Connection 2671 |--TCP connection established---> Point. 2672 | 2673 | Router sends Session 2674 |----Session Initialization----->| Initialization Message. 2675 | 2676 | Modem receives Session 2677 | Initialization Message. 2678 | 2679 | Modem sends Session Initialization 2680 |<--Session Initialization Resp.-| Response, with Success Status Data 2681 | | Item. 2682 | | 2683 |<<============================>>| Session established. Heartbeats 2684 : : begin. 2686 B.2. Session Initialization - Refused 2688 Router Modem Message Description 2689 ======================================================================== 2691 | Router connects to discovered or 2692 | pre-configured Modem Connection 2693 |--TCP connection established---> Point. 2694 | 2695 | Router sends Session 2696 |-----Session Initialization---->| Initialization Message. 2697 | 2698 | Modem receives Session 2699 | Initialization Message, and will 2700 | not support the advertised 2701 | extensions. 2702 | 2703 | Modem sends Session Initialization 2704 | Response, with 'Request Denied' 2705 |<-Session Initialization Resp.--| Status Data Item. 2706 | 2707 | 2708 | Router receives negative Session 2709 | Initialization Response, closes 2710 ||---------TCP close------------|| TCP connection. 2712 B.3. Router Changes IP Addresses 2714 Router Modem Message Description 2715 ======================================================================== 2717 | Router sends Session Update 2718 |-------Session Update---------->| Message to announce change of IP 2719 | address 2720 | 2721 | Modem receives Session Update 2722 | Message and updates internal 2723 | state. 2724 | 2725 |<----Session Update Response----| Modem sends Session Update 2726 | Response. 2728 B.4. Modem Changes Session-wide Metrics 2730 Router Modem Message Description 2731 ======================================================================== 2733 | Modem sends Session Update Message 2734 | to announce change of modem-wide 2735 |<--------Session Update---------| metrics 2736 | 2737 | Router receives Session Update 2738 | Message and updates internal 2739 | state. 2740 | 2741 |----Session Update Response---->| Router sends Session Update 2742 | Response. 2744 B.5. Router Terminates Session 2745 Router Modem Message Description 2746 ======================================================================== 2748 | Router sends Session Termination 2749 |------Session Termination------>| Message with Status Data Item. 2750 | | 2751 |-------TCP shutdown (send)---> | Router stops sending Messages. 2752 | 2753 | Modem receives Session 2754 | Termination, stops counting 2755 | received heartbeats and stops 2756 | sending heartbeats. 2757 | 2758 | Modem sends Session Termination 2759 |<---Session Termination Resp.---| Response with Status 'Success'. 2760 | 2761 | Modem stops sending Messages. 2762 | 2763 ||---------TCP close------------|| Session terminated. 2765 B.6. Modem Terminates Session 2767 Router Modem Message Description 2768 ======================================================================== 2770 | Modem sends Session Termination 2771 |<----Session Termination--------| Message with Status Data Item. 2772 | 2773 | Modem stops sending Messages. 2774 | 2775 | Router receives Session 2776 | Termination, stops counting 2777 | received heartbeats and stops 2778 | sending heartbeats. 2779 | 2780 | Router sends Session Termination 2781 |---Session Termination Resp.--->| Response with Status 'Success'. 2782 | 2783 | Router stops sending Messages. 2784 | 2785 ||---------TCP close------------|| Session terminated. 2787 B.7. Session Heartbeats 2788 Router Modem Message Description 2789 ======================================================================== 2791 |----------Heartbeat------------>| Router sends heartbeat Message 2792 | 2793 | Modem resets heartbeats missed 2794 | counter. 2796 ~ ~ ~ ~ ~ ~ ~ 2798 |---------[Any Message]--------->| When the Modem receives any 2799 | Message from the Router. 2800 | 2801 | Modem resets heartbeats missed 2802 | counter. 2804 ~ ~ ~ ~ ~ ~ ~ 2806 |<---------Heartbeat-------------| Modem sends heartbeat Message 2807 | 2808 | Router resets heartbeats missed 2809 | counter. 2811 ~ ~ ~ ~ ~ ~ ~ 2813 |<--------[Any Message]----------| When the Router receives any 2814 | Message from the Modem. 2815 | 2816 | Modem resets heartbeats missed 2817 | counter. 2819 B.8. Router Detects a Heartbeat timeout 2821 Router Modem Message Description 2822 ======================================================================== 2824 X<----------------------| Router misses a heartbeat 2826 | X<----------------------| Router misses too many heartbeats 2827 | 2828 | 2829 |------Session Termination------>| Router sends Session Termination 2830 | Message with 'Timeout' Status 2831 | Data Item. 2832 : 2833 : Termination proceeds... 2835 B.9. Modem Detects a Heartbeat timeout 2837 Router Modem Message Description 2838 ======================================================================== 2840 |---------------------->X Modem misses a heartbeat 2842 |---------------------->X | Modem misses too many heartbeats 2843 | 2844 | 2845 |<-----Session Termination-------| Modem sends Session Termination 2846 | Message with 'Timeout' Status 2847 | Data Item. 2848 : 2849 : Termination proceeds... 2851 Appendix C. Destination Specific Message Flows 2853 C.1. Common Destination Notification 2854 Router Modem Message Description 2855 ======================================================================== 2857 | Modem detects a new logical 2858 | destination is reachable, and 2859 |<-------Destination Up----------| sends Destination Up Message. 2860 | 2861 |------Destination Up Resp.----->| Router sends Destination Up 2862 | Response. 2864 ~ ~ ~ ~ ~ ~ ~ 2865 | Modem detects change in logical 2866 | destination metrics, and sends 2867 |<-------Destination Update------| Destination Update Message. 2869 ~ ~ ~ ~ ~ ~ ~ 2870 | Modem detects change in logical 2871 | destination metrics, and sends 2872 |<-------Destination Update------| Destination Update Message. 2874 ~ ~ ~ ~ ~ ~ ~ 2875 | Modem detects logical destination 2876 | is no longer reachable, and sends 2877 |<-------Destination Down--------| Destination Down Message. 2878 | 2879 | Router receives Destination Down, 2880 | updates internal state, and sends 2881 |------Destination Down Resp.--->| Destination Down Response Message. 2883 C.2. Multicast Destination Notification 2884 Router Modem Message Description 2885 ======================================================================== 2887 | Router detects a new multicast 2888 | destination is in use, and sends 2889 |-----Destination Announce------>| Destination Announce Message. 2890 | 2891 | Modem updates internal state to 2892 | monitor multicast destination, and 2893 |<-----Dest. Announce Resp.------| sends Destination Announce 2894 Response. 2896 ~ ~ ~ ~ ~ ~ ~ 2897 | Modem detects change in multicast 2898 | destination metrics, and sends 2899 |<-------Destination Update------| Destination Update Message. 2901 ~ ~ ~ ~ ~ ~ ~ 2902 | Modem detects change in multicast 2903 | destination metrics, and sends 2904 |<-------Destination Update------| Destination Update Message. 2906 ~ ~ ~ ~ ~ ~ ~ 2907 | Router detects multicast 2908 | destination is no longer in use, 2909 |--------Destination Down------->| and sends Destination Down 2910 | Message. 2911 | 2912 | Modem receives Destination Down, 2913 | updates internal state, and sends 2914 |<-----Destination Down Resp.----| Destination Down Response Message. 2916 C.3. Link Characteristics Request 2917 Router Modem Message Description 2918 ======================================================================== 2920 Destination has already been 2921 ~ ~ ~ ~ ~ ~ ~ announced by either peer. 2923 | Router requires different 2924 | Characteristics for the 2925 | destination, and sends Link 2926 |--Link Characteristics Request->| Characteristics Request Message. 2927 | 2928 | Modem attempts to adjust link 2929 | properties to meet the received 2930 | request, and sends a Link 2931 | Characteristics Response 2932 |<---Link Characteristics Resp.--| Message with the new values. 2934 Authors' Addresses 2936 Stan Ratliff 2937 VT iDirect 2938 13861 Sunrise Valley Drive, Suite 300 2939 Herndon, VA 20171 2940 USA 2942 Email: sratliff@idirect.net 2944 Bo Berry 2946 Shawn Jury 2947 Cisco Systems 2948 170 West Tasman Drive 2949 San Jose, CA 95134 2950 USA 2952 Email: sjury@cisco.com 2954 Darryl Satterwhite 2955 Broadcom 2957 Email: dsatterw@broadcom.com 2958 Rick Taylor 2959 Airbus Defence & Space 2960 Quadrant House 2961 Celtic Springs 2962 Coedkernew 2963 Newport NP10 8FZ 2964 UK 2966 Email: rick.taylor@airbus.com