idnits 2.17.1 draft-ietf-manet-dlep-23.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 44 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 274 has weird spacing: '... Shared o ...' == Line 275 has weird spacing: '... Medium o ...' -- The document date (July 18, 2016) is 2839 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5578' is defined on line 2632, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'UNIV8' == Outdated reference: A later version (-07) exists of draft-ietf-manet-credit-window-04 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile Ad hoc Networks Working Group S. Ratliff 2 Internet-Draft VT iDirect 3 Intended status: Standards Track S. Jury 4 Expires: January 19, 2017 Cisco Systems 5 D. Satterwhite 6 Broadcom 7 R. Taylor 8 Airbus Defence & Space 9 B. Berry 11 July 18, 2016 13 Dynamic Link Exchange Protocol (DLEP) 14 draft-ietf-manet-dlep-23 16 Abstract 18 When routing devices rely on modems to effect communications over 19 wireless links, they need timely and accurate knowledge of the 20 characteristics of the link (speed, state, etc.) in order to make 21 routing decisions. In mobile or other environments where these 22 characteristics change frequently, manual configurations or the 23 inference of state through routing or transport protocols does not 24 allow the router to make the best decisions. A bidirectional, event- 25 driven communication channel between the router and the modem is 26 necessary. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 19, 2017. 45 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 63 2.1. Destinations . . . . . . . . . . . . . . . . . . . . . . 7 64 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 8 66 4. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 5. DLEP Session Flow . . . . . . . . . . . . . . . . . . . . . . 11 68 5.1. Peer Discovery State . . . . . . . . . . . . . . . . . . 11 69 5.2. Session Initialization State . . . . . . . . . . . . . . 12 70 5.3. In-Session State . . . . . . . . . . . . . . . . . . . . 12 71 5.3.1. Heartbeats . . . . . . . . . . . . . . . . . . . . . 13 72 5.4. Session Termination State . . . . . . . . . . . . . . . . 13 73 5.5. Session Reset state . . . . . . . . . . . . . . . . . . . 14 74 5.5.1. Unexpected TCP connection termination . . . . . . . . 14 75 6. Transaction Model . . . . . . . . . . . . . . . . . . . . . . 14 76 7. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 7.1. Experiments . . . . . . . . . . . . . . . . . . . . . . . 15 78 8. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 9. DLEP Signal and Message Structure . . . . . . . . . . . . . . 16 80 9.1. DLEP Signal Header . . . . . . . . . . . . . . . . . . . 17 81 9.2. DLEP Message Header . . . . . . . . . . . . . . . . . . . 17 82 9.3. DLEP Generic Data Item . . . . . . . . . . . . . . . . . 18 83 10. DLEP Signals and Messages . . . . . . . . . . . . . . . . . . 18 84 10.1. General Processing Rules . . . . . . . . . . . . . . . . 19 85 10.2. Status code processing . . . . . . . . . . . . . . . . . 20 86 10.3. Peer Discovery Signal . . . . . . . . . . . . . . . . . 20 87 10.4. Peer Offer Signal . . . . . . . . . . . . . . . . . . . 20 88 10.5. Session Initialization Message . . . . . . . . . . . . . 21 89 10.6. Session Initialization Response Message . . . . . . . . 22 90 10.7. Session Update Message . . . . . . . . . . . . . . . . . 23 91 10.8. Session Update Response Message . . . . . . . . . . . . 25 92 10.9. Session Termination Message . . . . . . . . . . . . . . 25 93 10.10. Session Termination Response Message . . . . . . . . . . 25 94 10.11. Destination Up Message . . . . . . . . . . . . . . . . . 26 95 10.12. Destination Up Response Message . . . . . . . . . . . . 27 96 10.13. Destination Announce Message . . . . . . . . . . . . . . 27 97 10.14. Destination Announce Response Message . . . . . . . . . 28 98 10.15. Destination Down Message . . . . . . . . . . . . . . . . 30 99 10.16. Destination Down Response Message . . . . . . . . . . . 30 100 10.17. Destination Update Message . . . . . . . . . . . . . . . 30 101 10.18. Link Characteristics Request Message . . . . . . . . . . 32 102 10.19. Link Characteristics Response Message . . . . . . . . . 32 103 10.20. Heartbeat Message . . . . . . . . . . . . . . . . . . . 33 104 11. DLEP Data Items . . . . . . . . . . . . . . . . . . . . . . . 34 105 11.1. Status . . . . . . . . . . . . . . . . . . . . . . . . . 35 106 11.2. IPv4 Connection Point . . . . . . . . . . . . . . . . . 37 107 11.3. IPv6 Connection Point . . . . . . . . . . . . . . . . . 37 108 11.4. Peer Type . . . . . . . . . . . . . . . . . . . . . . . 39 109 11.5. Heartbeat Interval . . . . . . . . . . . . . . . . . . . 39 110 11.6. Extensions Supported . . . . . . . . . . . . . . . . . . 40 111 11.7. MAC Address . . . . . . . . . . . . . . . . . . . . . . 40 112 11.8. IPv4 Address . . . . . . . . . . . . . . . . . . . . . . 41 113 11.9. IPv6 Address . . . . . . . . . . . . . . . . . . . . . . 42 114 11.10. IPv4 Attached Subnet . . . . . . . . . . . . . . . . . . 43 115 11.11. IPv6 Attached Subnet . . . . . . . . . . . . . . . . . . 44 116 11.12. Maximum Data Rate (Receive) . . . . . . . . . . . . . . 45 117 11.13. Maximum Data Rate (Transmit) . . . . . . . . . . . . . . 45 118 11.14. Current Data Rate (Receive) . . . . . . . . . . . . . . 46 119 11.15. Current Data Rate (Transmit) . . . . . . . . . . . . . . 47 120 11.16. Latency . . . . . . . . . . . . . . . . . . . . . . . . 48 121 11.17. Resources . . . . . . . . . . . . . . . . . . . . . . . 48 122 11.18. Relative Link Quality (Receive) . . . . . . . . . . . . 49 123 11.19. Relative Link Quality (Transmit) . . . . . . . . . . . . 50 124 11.20. Maximum Transmission Unit (MTU) . . . . . . . . . . . . 50 125 12. Security Considerations . . . . . . . . . . . . . . . . . . . 51 126 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 127 13.1. Registrations . . . . . . . . . . . . . . . . . . . . . 52 128 13.2. Signal Type Registration . . . . . . . . . . . . . . . . 52 129 13.3. Message Type Registration . . . . . . . . . . . . . . . 52 130 13.4. DLEP Data Item Registrations . . . . . . . . . . . . . . 53 131 13.5. DLEP Status Code Registrations . . . . . . . . . . . . . 54 132 13.6. DLEP Extensions Registrations . . . . . . . . . . . . . 55 133 13.7. DLEP Well-known Port . . . . . . . . . . . . . . . . . . 55 134 13.8. DLEP IPv4 Link-local Multicast Address . . . . . . . . . 55 135 13.9. DLEP IPv6 Link-local Multicast Address . . . . . . . . . 55 136 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 55 137 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 138 15.1. Normative References . . . . . . . . . . . . . . . . . . 56 139 15.2. Informative References . . . . . . . . . . . . . . . . . 56 140 Appendix A. Discovery Signal Flows . . . . . . . . . . . . . . . 57 141 Appendix B. Peer Level Message Flows . . . . . . . . . . . . . . 57 142 B.1. Session Initialization . . . . . . . . . . . . . . . . . 57 143 B.2. Session Initialization - Refused . . . . . . . . . . . . 58 144 B.3. Router Changes IP Addresses . . . . . . . . . . . . . . . 58 145 B.4. Modem Changes Session-wide Metrics . . . . . . . . . . . 58 146 B.5. Router Terminates Session . . . . . . . . . . . . . . . . 59 147 B.6. Modem Terminates Session . . . . . . . . . . . . . . . . 59 148 B.7. Session Heartbeats . . . . . . . . . . . . . . . . . . . 60 149 B.8. Router Detects a Heartbeat timeout . . . . . . . . . . . 60 150 B.9. Modem Detects a Heartbeat timeout . . . . . . . . . . . . 61 151 Appendix C. Destination Specific Message Flows . . . . . . . . . 61 152 C.1. Common Destination Notification . . . . . . . . . . . . . 61 153 C.2. Multicast Destination Notification . . . . . . . . . . . 62 154 C.3. Link Characteristics Request . . . . . . . . . . . . . . 63 155 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63 157 1. Introduction 159 There exist today a collection of modem devices that control links of 160 variable datarate and quality. Examples of these types of links 161 include line-of-sight (LOS) terrestrial radios, satellite terminals, 162 and broadband modems. Fluctuations in speed and quality of these 163 links can occur due to configuration, or on a moment-to-moment basis, 164 due to physical phenomena like multipath interference, obstructions, 165 rain fade, etc. It is also quite possible that link quality and 166 datarate vary with respect to individual destinations on a link, and 167 with the type of traffic being sent. As an example, consider the 168 case of an IEEE 802.11 access point, serving two associated laptop 169 computers. In this environment, the answer to the question "What is 170 the datarate on the 802.11 link?" is "It depends on which associated 171 laptop we're talking about, and on what kind of traffic is being 172 sent." While the first laptop, being physically close to the access 173 point, may have a datarate of 54Mbps for unicast traffic, the other 174 laptop, being relatively far away, or obstructed by some object, can 175 simultaneously have a datarate of only 32Mbps for unicast. However, 176 for multicast traffic sent from the access point, all traffic is sent 177 at the base transmission rate (which is configurable, but depending 178 on the model of the access point, is usually 24Mbps or less). 180 In addition to utilizing variable datarate links, mobile networks are 181 challenged by the notion that link connectivity will come and go over 182 time, without an effect on a router's interface state (Up or Down). 183 Effectively utilizing a relatively short-lived connection is 184 problematic in IP routed networks, as IP routing protocols tend to 185 rely on interface state and independent timers to maintain network 186 convergence (e.g., HELLO messages and/or recognition of DEAD routing 187 adjacencies). These dynamic connections can be better utilized with 188 an event-driven paradigm, where acquisition of a new neighbor (or 189 loss of an existing one) is signaled, as opposed to a paradigm driven 190 by timers and/or interface state. DLEP not only implements such an 191 event-driven paradigm, but does so over a local (1 hop) TCP session, 192 which guarantees delivery of the event messages. 194 Another complicating factor for mobile networks are the different 195 methods of physically connecting the modem devices to the router. 196 Modems can be deployed as an interface card in a router's chassis, or 197 as a standalone device connected to the router via Ethernet or serial 198 link. In the case of Ethernet attachment, with existing protocols 199 and techniques, routing software cannot be aware of convergence 200 events occurring on the radio link (e.g., acquisition or loss of a 201 potential routing neighbor), nor can the router be aware of the 202 actual capacity of the link. This lack of awareness, along with the 203 variability in datarate, leads to a situation where finding the 204 (current) best route through the network to a given node is difficult 205 to establish and properly maintain. This is especially true of 206 demand-based access schemes such as Demand Assigned Multiple Access 207 (DAMA) implementations used on some satellite systems. With a DAMA- 208 based system, additional datarate may be available, but will not be 209 used unless the network devices emit traffic at a rate higher than 210 the currently established rate. Increasing the traffic rate does not 211 guarantee additional datarate will be allocated; rather, it may 212 result in data loss and additional retransmissions on the link. 214 Addressing the challenges listed above, the Dynamic Link Exchange 215 Protocol, or DLEP, has been developed. The DLEP protocol runs 216 between a router and its attached modem devices, allowing the modem 217 to communicate link characteristics as they change, and convergence 218 events (acquisition and loss of potential routing next-hops). The 219 following diagrams are used to illustrate the scope of DLEP packets. 221 |-------Local Node-------| |-------Remote Node------| 222 | | | | 223 +--------+ +-------+ +-------+ +--------+ 224 | Router |=======| Modem |{~~~~~~~~}| Modem |=======| Router | 225 | | | Device| | Device| | | 226 +--------+ +-------+ +-------+ +--------+ 227 | | | Link | | | 228 |-DLEP--| | Protocol | |-DLEP--| 229 | | | (e.g. | | | 230 | | | 802.11) | | | 232 Figure 1: DLEP Network 234 In Figure 1, when the local modem detects the presence of a remote 235 node, it (the local modem) sends a message to its router via the DLEP 236 protocol. The message consists of an indication of what change has 237 occurred on the link (e.g., presence of a remote node detected), 238 along with a collection of DLEP-defined data items that further 239 describe the change. Upon receipt of the message, the local router 240 may take whatever action it deems appropriate, such as initiating 241 discovery protocols, and/or issuing HELLO messages to converge the 242 network. On a continuing, as-needed basis, the modem devices use 243 DLEP to report any characteristics of the link (datarate, latency, 244 etc.) that have changed. DLEP is independent of the link type and 245 topology supported by the modem. Note that the DLEP protocol is 246 specified to run only on the local link between router and modem. 247 Some over the air signaling may be necessary between the local and 248 remote modem in order to provide some parameters in DLEP messages 249 between the local modem and local router, but DLEP does not specify 250 how such over the air signaling is carried out. Over the air 251 signaling is purely a matter for the modem implementer. 253 Figure 2 shows how DLEP can support a configuration where routers are 254 connected with different link types. In this example, Modem A 255 implements a point-to-point link, and Modem B is connected via a 256 shared medium. In both cases, the DLEP protocol is used to report 257 the characteristics of the link (datarate, latency, etc.) to routers. 258 The modem is also able to use the DLEP session to notify the router 259 when the remote node is lost, shortening the time required to re- 260 converge the network. 262 +--------+ +--------+ 263 +----+ Modem | | Modem +---+ 264 | | Device | | Device | 265 | | Type A | <===== // ======> | Type A | | 266 | +--------+ P-2-P Link +--------+ | 267 +---+----+ +---+----+ 268 | Router | | Router | 269 | | | | 270 +---+----+ +---+----+ 271 | +--------+ +--------+ | 272 +-----+ Modem | | Modem | | 273 | Device | o o o o o o o o | Device +--+ 274 | Type B | o Shared o | Type B | 275 +--------+ o Medium o +--------+ 276 o o 277 o o 278 o o 279 o 280 +--------+ 281 | Modem | 282 | Device | 283 | Type B | 284 +---+----+ 285 | 286 | 287 +---+----+ 288 | Router | 289 | | 290 +--------+ 292 Figure 2: DLEP Network with Multiple Modem Devices 294 2. Protocol Overview 296 DLEP defines a set of Messages used by modems and their attached 297 routers to communicate events that occur on the physical link(s) 298 managed by the modem: for example, a remote node entering or leaving 299 the network, or that the link has changed. Associated with these 300 Messages are a set of Data Items - information that describes the 301 remote node (e.g., address information), and/or the characteristics 302 of the link to the remote node. Throughout this document, we refer 303 to a modems/routers participating in a DLEP session as 'DLEP 304 Participants', unless a specific distinction (e.g. modem or router) 305 is required. 307 DLEP uses a session-oriented paradigm between the modem device and 308 its associated router. If multiple modem devices are attached to a 309 router (as in Figure 2), or the modem supports multiple connections 310 (via multiple logical or physical interfaces), then separate DLEP 311 sessions exist for each modem or connection. A router and modem form 312 a session by completing the discovery and initialization process. 313 This router-modem session persists unless or until it either (1) 314 times out, based on the absence of DLEP traffic (including 315 heartbeats), or (2) is explicitly torn down by one of the DLEP 316 participants. 318 2.1. Destinations 320 The router/modem session provides a carrier for information exchange 321 concerning 'destinations' that are available via the modem device. 322 Destinations can be identified by either the router or the modem, and 323 represent a specific, addressable location that can be reached via 324 the link(s) managed by the modem. 326 The DLEP Messages concerning destinations thus become the way for 327 routers and modems to maintain, and notify each other about, an 328 information base representing the physical and logical destinations 329 accessible via the modem device, as well as the link characteristics 330 to those destinations. 332 A destination can be either physical or logical. The example of a 333 physical destination would be that of a remote, far-end router 334 attached via the variable-quality network. It should be noted that 335 for physical destinations the MAC address is the address of the far- 336 end router, not the modem. 338 The example of a logical destination is Multicast. Multicast traffic 339 destined for the variable-quality network (the network accessed via 340 the modem) is handled in IP networks by deriving a Layer 2 MAC 341 address based on the Layer 3 address. Leveraging on this scheme, 342 multicast traffic is supported in DLEP simply by treating the derived 343 MAC address as any other destination in the network. 345 To support these logical destinations, one of the DLEP participants 346 (typically, the router) informs the other as to the existence of the 347 logical destination. The modem, once it is aware of the existence of 348 this logical destination, reports link characteristics just as it 349 would for any other destination in the network. The specific 350 algorithms a modem would use to derive metrics on logical 351 destinations are outside the scope of this specification, and is left 352 to specific implementations to decide. 354 In all cases, when this specification uses the term destination, it 355 refers to the addressable locations, either logical or physical, that 356 are accessible by the radio link(s). 358 3. Extensions 360 While this document represents the best efforts of the working group 361 to be functionally complete, it is recognized that extensions to DLEP 362 will in all likelihood be necessary as more link types are used. 363 Such extensions are defined as additional Messages, Data Items and/or 364 status codes, and associated rules of behavior, that are not defined 365 in this document. DLEP contains a standard mechanism for router and 366 modem implementations to negotiate the available extensions to use on 367 a per-session basis. 369 3.1. Requirements 371 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 372 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 373 "OPTIONAL" in this document are to be interpreted as described in BCP 374 14, RFC 2119 [RFC2119]. 376 DLEP MUST be implemented on a single Layer 2 domain. The protocol 377 identifies next-hop destinations by using the MAC address for 378 delivering data traffic. No manipulation or substitution is 379 performed; the MAC address supplied in all DLEP Messages is used as 380 the Destination MAC address for frames emitted by the participating 381 router. MAC addresses MUST be unique within the context of router- 382 modem session. 384 To enforce the single Layer 2 domain, implementations MUST support 385 The Generalized TTL Security Mechanism [RFC5082]. 387 DLEP specifies UDP multicast for single-hop discovery signaling, and 388 TCP for transport of the Messages. Modems and routers participating 389 in DLEP sessions MUST have topologically consistent IP addresses 390 assigned. It is RECOMMENDED that DLEP implementations utilize IPv6 391 link-local addresses to reduce the administrative burden of address 392 assignment. Implementations MUST adhere to the procedure documented 393 in [RFC5082] for all DLEP Messages (TCP traffic). 395 In order to keep the DLEP discovery Signals, which are multicast UDP- 396 based, limited to the same Layer 2 domain, implementations MUST set 397 the TTL of all DLEP Signals to 1, and MUST check for TTL = 1 on 398 receipt of DLEP Signals. Any signal received with a TTL not equal to 399 1 MUST be discarded. 401 DLEP relies on the guaranteed delivery of its Messages between router 402 and modem, once the 1 hop discovery process is complete, hence, the 403 specification of TCP to carry the Messages. Other reliable 404 transports for the protocol are possible, but are outside the scope 405 of this document. 407 DLEP further requires that security of the implementations (e.g., 408 authentication of stations, encryption of traffic, or both) is dealt 409 with by utilizing Layer 2 security techniques. This reliance on 410 Layer 2 mechanisms secures all DLEP Messages - both the UDP discovery 411 Signals and the TCP control Messages. 413 4. Metrics 415 DLEP includes the ability for the router and modem to communicate 416 metrics that reflect the characteristics (e.g., datarate, latency) of 417 the variable-quality link in use. DLEP does not specify how a given 418 metric value is to be calculated, rather, the protocol assumes that 419 metrics have been calculated by a 'best effort', incorporating all 420 pertinent data that is available to the modem device. Metrics based 421 on large enough sample sizes will preclude short traffic bursts from 422 adversely skewing reported values. 424 DLEP allows for metrics to be sent within two contexts - metrics for 425 a specific destination within the network (e.g., a specific router), 426 and per-session (those that apply to all destinations accessed via 427 the modem). Most metrics can be further subdivided into transmit and 428 receive metrics. In cases where metrics are provided at session 429 level, the router propagates the metrics to all entries in its 430 information base for destinations that are accessed via the modem. 432 DLEP modems announce all metric Data Items that will be reported 433 during the session, and provide default values for those metrics, in 434 the Session Initialization Response Message (Section 10.6). In order 435 to use a metric type that was not included in the Session 436 Initialization Response Message, modem implementations terminate the 437 session with the router (via the Session Terminate Message 438 (Section 10.9)), and establish a new session. 440 A DLEP modem can send metrics both in a session context, via the 441 Session Update Message (Section 10.7), and a specific destination 442 context, via the Destination Update Message (Section 10.17), at any 443 time. The most recently received metric value takes precedence over 444 any earlier value, regardless of context - that is: 446 1. If the router receives metrics in a specific destination context 447 (via the Destination Update Message), then the specific 448 destination is updated with the new metric. 450 2. If the router receives metrics in a session-wide context (via the 451 Session Update Message), then the metrics for all destinations 452 accessed via the modem are updated with the new metric. 454 It is left to implementations to choose sensible default values based 455 on their specific characteristics. Modems having static (non- 456 changing) link metric characteristics can report metrics only once 457 for a given destination (or once on a session-wide basis, if all 458 connections via the modem are of this static nature). 460 In addition to communicating existing metrics about the link, DLEP 461 provides a Message allowing a router to request a different datarate 462 or latency from the modem. This Message is the Link Characteristics 463 Request Message (Section 10.18), and gives the router the ability to 464 deal with requisite increases (or decreases) of allocated datarate/ 465 latency in demand-based schemes in a more deterministic manner. 467 5. DLEP Session Flow 469 All DLEP participants of a session transition through a number of 470 distinct states during the lifetime of a DLEP session: 472 o Peer Discovery 474 o Session Initialization 476 o In-Session 478 o Session Termination 480 o Session Reset 482 Modems, and routers supporting DLEP discovery, transition through all 483 five (5) of the above states. Routers that rely on preconfigured TCP 484 address/port information start in the Session Initialization state. 486 Modems MUST support the Peer Discovery state. 488 5.1. Peer Discovery State 490 In the Peer Discovery state, routers that support DLEP discovery MUST 491 send Peer Discovery Signals (Section 10.3) to initiate modem 492 discovery. 494 The router implementation then waits for a Peer Offer Signal 495 (Section 10.4) response from a potential DLEP modem. While in the 496 Peer Discovery state, Peer Discovery Signals MUST be sent repeatedly 497 by a DLEP router, at regular intervals. The interval MUST be a 498 minimum of one second; it SHOULD be a configurable parameter. Note 499 that this operation (sending Peer Discovery and waiting for Peer 500 Offer) is outside the DLEP Transaction Model (Section 6), as the 501 Transaction Model only describes Messages on a TCP session. 503 Routers MUST use one or more of each of the modem address/port 504 combinations from the Peer Offer Signal or, when no Connection Point 505 Data Items are present, from a priori configuration to establish a 506 new TCP connection to the modem. If more than one modem address/port 507 combinations is provided, router implementations MAY use their own 508 heuristics to determine the order in which they are tried. If a TCP 509 connection cannot be achieved using any of the address/port 510 combinations and the Discovery mechanism is in use, then the router 511 SHOULD resume issuing Peer Discovery Signals. If no Connection Point 512 Data Items are included in the Peer Offer Signal, the router MUST use 513 the source address of the UDP packet containing the Peer Offer Signal 514 as the IP address, and the DLEP well-known port number. 516 In the Peer Discovery state, the modem implementation MUST listen for 517 incoming Peer Discovery Signals on the DLEP well-known IPv6 and/or 518 IPv4 link-local multicast address and port. On receipt of a valid 519 Peer Discovery Signal, it MUST reply with a Peer Offer Signal. 521 Modems MUST be prepared to accept a TCP connection from a router that 522 is not using the Discovery mechanism, i.e. a connection attempt that 523 occurs without a preceding Peer Discovery Signal. 525 Upon establishment of a TCP connection, both modem and router enter 526 the Session Initialization state. It is up to the router 527 implementation if Peer Discovery Signals continue to be sent after 528 the device has transitioned to the Session Initialization state. 529 Modem implementations MUST silently ignore Peer Discovery Signals 530 from a router with which it already has a TCP connection. 532 5.2. Session Initialization State 534 On entering the Session Initialization state, the router MUST send a 535 Session Initialization Message (Section 10.5) to the modem. The 536 router MUST then wait for receipt of a Session Initialization 537 Response Message (Section 10.6) from the modem. Receipt of the 538 Session Initialization Response Message containing a Status Data Item 539 (Section 11.1) with status code set to 0 'Success', see Table 2, 540 indicates that the modem has received and processed the Session 541 Initialization Message, and the router MUST transition to the In- 542 Session state. 544 On entering the Session Initialization state, the modem MUST wait for 545 receipt of a Session Initialization Message from the router. Upon 546 receipt of a Session Initialization Message, the modem MUST send a 547 Session Initialization Response Message, and the session MUST 548 transition to the In-Session state. If the modem receives any 549 Message other than Session Initialization, or it fails to parse the 550 received Message, it MUST NOT send any Message, and MUST terminate 551 the TCP connection and transition to the Session Reset state. 553 DLEP provides an extension negotiation capability to be used in the 554 Session Initialization state, see Section 3. Extensions supported by 555 an implementation MUST be declared to potential DLEP participants 556 using the Extensions Supported Data Item (Section 11.6). Once both 557 DLEP participants have exchanged initialization Messages, an 558 implementation MUST NOT emit any Message, Signal, Data Item or status 559 code associated with an extension that was not specified in the 560 received initialization Message from its peer. 562 5.3. In-Session State 563 In the In-Session state, Messages can flow in both directions between 564 DLEP participants, indicating changes to the session state, the 565 arrival or departure of reachable destinations, or changes of the 566 state of the links to the destinations. 568 The In-Session state is maintained until one of the following 569 conditions occur: 571 o The implementation terminates the session by sending a Session 572 Termination Message (Section 10.9), or, 574 o Its peer terminates the session, indicated by receiving a Session 575 Termination Message. 577 The implementation MUST then transition to the Session Termination 578 state. 580 5.3.1. Heartbeats 582 In order to maintain the In-Session state, periodic Heartbeat 583 Messages (Section 10.20) MUST be exchanged between router and modem. 584 These Messages are intended to keep the session alive, and to verify 585 bidirectional connectivity between the two DLEP participants. 587 Each DLEP participant is responsible for the creation of Heartbeat 588 Messages. 590 Receipt of any valid DLEP Message MUST reset the heartbeat interval 591 timer (i.e., valid DLEP Messages take the place of, and obviate the 592 need for, additional Heartbeat Messages). 594 Implementations MUST allow a minimum of two (2) heartbeat intervals 595 to expire with no Messages from its peer before terminating the 596 session. When terminating the session, a Session Termination Message 597 containing a Status Data Item (Section 11.1) with status code set to 598 132 'Timed Out', see Table 2, MUST be sent, and then the 599 implementation MUST transition to the Session Termination state. 601 5.4. Session Termination State 603 When an implementation enters the Session Termination state after 604 sending a Session Termination Message (Section 10.9) as the result of 605 an invalid Message or error, it MUST wait for a Session Termination 606 Response Message (Section 10.10) from its peer. Senders SHOULD allow 607 four (4) heartbeat intervals to expire before assuming that its peer 608 is unresponsive, and continuing with session termination. Any other 609 Message received while waiting MUST be silently ignored. 611 When the sender of the Session Termination Message receives a Session 612 Termination Response Message from its peer, or times out, it MUST 613 transition to the Session Reset state. 615 When an implementation receives a Session Termination Message from 616 its peer, it enters the Session Termination state and then it MUST 617 immediately send a Session Termination Response and transition to the 618 Session Reset state. 620 5.5. Session Reset state 622 In the Session Reset state the implementation MUST perform the 623 following actions: 625 o Release all resources allocated for the session. 627 o Eliminate all destinations in the information base represented by 628 the session. Destination Down Messages (Section 10.15) MUST NOT 629 be sent. 631 o Terminate the TCP connection. 633 Having completed these actions the implementation SHOULD return to 634 the relevant initial state: Peer Discovery for modems; either Peer 635 Discovery or Session Initialization for routers, depending on 636 configuration. 638 5.5.1. Unexpected TCP connection termination 640 If the TCP connection between DLEP participants is terminated when an 641 implementation is not in the Session Reset state, the implementation 642 MUST immediately transition to the Session Reset state. 644 6. Transaction Model 646 DLEP defines a simple Message transaction model: Only one request per 647 destination may be in progress at a time per session. A Message 648 transaction is considered complete when a response matching a 649 previously issued request is received. If a DLEP participant 650 receives a request for a destination for which there is already an 651 outstanding request, the implementation MUST terminate the session by 652 issuing a Session Termination Message (Section 10.9) containing a 653 Status Data Item (Section 11.1) with status code set to 129 654 'Unexpected Message', see Table 2, and transition to the Session 655 Termination state. There is no restriction to the total number of 656 Message transactions in progress at a time, as long as each 657 transaction refers to a different destination. 659 It should be noted that some requests may take a considerable amount 660 of time for some DLEP participants to complete, for example a modem 661 handling a multicast destination up request may have to perform a 662 complex network reconfiguration. A sending implementation MUST be 663 able to handle such long running transactions gracefully. 665 Additionally, only one session request, e.g. a Session Initialization 666 Message (Section 10.5), may be in progress at a time per session. As 667 above, a session transaction is considered complete when a response 668 matching a previously issued request is received. If a DLEP 669 participant receives a session request while there is already a 670 session request in progress, it MUST terminate the session by issuing 671 a Session Termination Message containing a Status Data Item with 672 status code set to 129 'Unexpected Message', and transition to the 673 Session Termination state. Only the Session Termination Message may 674 be issued when a session transaction is in progress. Heartbeat 675 Messages (Section 10.20) MUST NOT be considered part of a session 676 transaction. 678 DLEP transactions do not time out and are not cancellable. An 679 implementation can detect if its peer has failed in some way by use 680 of the session heartbeat mechanism during the In-Session state, see 681 Section 5.3. 683 7. Extensions 685 Extensions MUST be negotiated on a per-session basis during session 686 initialization via the Extensions Supported mechanism. 687 Implementations are not required to support any extension in order to 688 be considered DLEP compliant. An extension document, describing the 689 operation of a credit windowing scheme for flow control, is described 690 in [CREDIT]. 692 If interoperable protocol extensions are required, they will need to 693 be standardized either as an update to this document, or as an 694 additional stand-alone specification. The requests for IANA- 695 controlled registries in this document contain sufficient Reserved 696 space for DLEP Signals, Messages, Data Items and status codes to 697 accommodate future extensions to the protocol. 699 As multiple protocol extensions MAY be announced during session 700 initialization, authors of protocol extensions need to consider the 701 interaction of their extension with other published extensions, and 702 specify any incompatibilities. 704 7.1. Experiments 705 This document requests Private Use numbering space in the DLEP 706 Signal, Message, Data Item and status code registries for 707 experimental extensions. The intent is to allow for experimentation 708 with new Signals, Messages, Data Items, and/or status codes, while 709 still retaining the documented DLEP behavior. 711 Use of the Private Use Signals, Messages, Data Items, status codes, 712 or behaviors MUST be announced as DLEP Extensions, during session 713 initialization, using extension identifiers from the Private Use 714 space in the Extensions Supported registry (Table 3), with a value 715 agreed upon (a priori) between the participants. DLEP extensions 716 using the Private Use numbering space are commonly referred to as 717 Experiments. 719 Multiple experiments MAY be announced in the Session Initialization 720 Messages. However, use of multiple experiments in a single session 721 could lead to interoperability issues or unexpected results (e.g., 722 clashes of experimental Signals, Messages, Data Items and/or status 723 code types), and is therefore discouraged. It is left to 724 implementations to determine the correct processing path (e.g., a 725 decision on whether to terminate the session, or to establish a 726 precedence of the conflicting definitions) if such conflicts arise. 728 8. Scalability 730 The protocol is intended to support thousands of destinations on a 731 given modem/router pair. At large scale, implementations SHOULD 732 consider employing techniques to prevent flooding its peer with a 733 large number of Messages in a short time. For example, a dampening 734 algorithm could be employed to prevent a flapping device from 735 generating a large number of Destination Up/Destination Down 736 Messages. 738 Also, use of techniques such as a hysteresis can lessen the impact of 739 rapid, minor fluctuations in link quality. The specific algorithms 740 for handling flapping destinations and minor changes in link quality 741 are outside the scope of this specification. 743 9. DLEP Signal and Message Structure 745 DLEP defines two protocol units used in two different ways: Signals 746 and Messages. Signals are only used in the Discovery mechanism and 747 are carried in UDP datagrams. Messages are used bi-directionally 748 over a TCP connection between the participants, in the Session 749 Initialization, In-Session and Session Termination states. 751 Both Signals and Messages consist of a Header followed by an 752 unordered list of Data Items. Headers consist of Type and Length 753 information, while Data Items are encoded as TLV (Type-Length-Value) 754 structures. In this document, the Data Items following a Signal or 755 Message Header are described as being 'contained in' the Signal or 756 Message. 758 There is no restriction on the order of Data Items following a 759 Header, and the acceptability of duplicate Data Items is defined by 760 the definition of the Signal or Message declared by the type in the 761 Header. 763 All integers in Header fields and values MUST be in network byte- 764 order. 766 9.1. DLEP Signal Header 768 The DLEP Signal Header contains the following fields: 770 0 1 2 3 771 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 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | 'D' | 'L' | 'E' | 'P' | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | Signal Type | Length | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 Figure 3: DLEP Signal Header 780 "DLEP": Every Signal MUST start with the characters: U+0044, U+004C, 781 U+0045, U+0050. 783 Signal Type: A 16-bit unsigned integer containing one of the DLEP 784 Signal Type values defined in this document. 786 Length: The length in octets, expressed as a 16-bit unsigned 787 integer, of all of the DLEP Data Items contained in this Signal. 788 This length MUST NOT include the length of the Signal Header 789 itself. 791 The DLEP Signal Header is immediately followed by zero or more DLEP 792 Data Items, encoded in TLVs, as defined in this document. 794 9.2. DLEP Message Header 796 The DLEP Message Header contains the following fields: 798 0 1 2 3 799 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 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | Message Type | Length | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 Figure 4: DLEP Message Header 806 Message Type: A 16-bit unsigned integer containing one of the DLEP 807 Message Type values defined in this document. 809 Length: The length in octets, expressed as a 16-bit unsigned 810 integer, of all of the DLEP Data Items contained in this Message. 811 This length MUST NOT include the length of the Message Header 812 itself. 814 The DLEP Message Header is immediately followed by zero or more DLEP 815 Data Items, encoded in TLVs, as defined in this document. 817 9.3. DLEP Generic Data Item 819 All DLEP Data Items contain the following fields: 821 0 1 2 3 822 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 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 | Data Item Type | Length | 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | Value... : 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 Figure 5: DLEP Generic Data Item 831 Data Item Type: A 16-bit unsigned integer field specifying the type 832 of Data Item being sent. 834 Length: The length in octets, expressed as a 16-bit unsigned 835 integer, of the Value field of the Data Item. This length MUST 836 NOT include the length of the Data Item Type and Length fields. 838 Value: A field of octets, which contains data specific to a 839 particular Data Item. 841 10. DLEP Signals and Messages 842 10.1. General Processing Rules 844 If an unrecognized, or unexpected Signal is received, or a received 845 Signal contains unrecognized, invalid, or disallowed duplicate Data 846 Items, the receiving implementation MUST ignore the Signal. 848 If a Signal is received with a TTL value that is NOT equal to 1, the 849 receiving implementation MUST ignore the Signal. 851 If a received Message contains a TTL value other than 255, the 852 receiving implementation MUST close the session, and transition to 853 the Session Termination state. 855 If an unrecognized Message is received, the receiving implementation 856 MUST issue a Session Termination Message (Section 10.9) containing a 857 Status Data Item (Section 11.1) with status code set to 128 'Unknown 858 Message', see Table 2, and transition to the Session Termination 859 state. 861 If an unexpected Message is received, the receiving implementation 862 MUST issue a Session Termination Message containing a Status Data 863 Item with status code set to 129 'Unexpected Message', and transition 864 to the Session Termination state. 866 If a received Message contains unrecognized, invalid, or disallowed 867 duplicate Data Items, the receiving implementation MUST issue a 868 Session Termination Message containing a Status Data Item with status 869 code set to 130 'Invalid Data', and transition to the Session 870 Termination state. 872 Prior to the exchange of Destination Up (Section 10.11) and 873 Destination Up Response (Section 10.12) Messages, or Destination 874 Announce (Section 10.13) and Destination Announce Response 875 (Section 10.14) Messages, no Messages concerning a destination may be 876 sent. An implementation receiving any Message with such an 877 unannounced destination MUST terminate the session by issuing a 878 Session Termination Message containing a Status Data Item with status 879 code set to 131 'Invalid Destination', and transition to the Session 880 Termination state. 882 After exchanging Destination Down (Section 10.15) and Destination 883 Down Response (Section 10.16) Messages, no Messages concerning a 884 destination may be a sent until a new Destination Up or Destination 885 Announce Message is sent. An implementation receiving a Message 886 about a destination previously announced as 'down' MUST terminate the 887 session by issuing a Session Termination Message with a Status Data 888 Item with status code set to 131 'Invalid Destination', and 889 transition to the Session Termination state. 891 10.2. Status code processing 893 The behaviour of a DLEP participant receiving a Message containing a 894 Status Data Item (Section 11.1) is defined by the failure mode 895 associated with the value of the status code field, see Table 2. All 896 status code values less than 100 have a failure mode of 'Continue', 897 all other status codes have a failure mode of 'Terminate'. 899 A DLEP participant receiving any Message apart from Session 900 Termination Message (Section 10.9) containing a Status Data Item with 901 a status code value with failure mode 'Terminate' MUST immediately 902 issue a Session Termination Message containing an identical Status 903 Data Item, and then transition to the Session Termination state. 905 A DLEP participant receiving a Message containing a Status Data Item 906 with a status code value with failure mode 'Continue' can continue 907 normal operation of the session. 909 10.3. Peer Discovery Signal 911 A Peer Discovery Signal SHOULD be sent by a DLEP router to discover 912 DLEP modems in the network, see Section 5.1. 914 A Peer Discovery Signal MUST be encoded within a UDP packet. The 915 destination MUST be set to the DLEP well-known address and port 916 number. For routers supporting both IPv4 and IPv6 DLEP operation, it 917 is RECOMMENDED that IPv6 be selected as the transport. The source IP 918 address MUST be set to the router IP address associated with the DLEP 919 interface. There is no DLEP-specific restriction on source port. 921 To construct a Peer Discovery Signal, the Signal Type value in the 922 Signal Header is set to 1 (see Signal Type Registration 923 (Section 13.2)). 925 The Peer Discovery Signal MAY contain a Peer Type Data Item 926 (Section 11.4). 928 10.4. Peer Offer Signal 930 A Peer Offer Signal MUST be sent by a DLEP modem in response to a 931 properly formatted and addressed Peer Discovery Signal 932 (Section 10.3). 934 A Peer Offer Signal MUST be encoded within a UDP packet. The IP 935 destination MUST be set to the IP address and port number received in 936 the corresponding Peer Discovery Signal. The source IP address MUST 937 be set to the modem's IP address associated with the DLEP interface. 938 The source port number MUST be set to the DLEP well-known port 939 number. The Peer Offer Signal completes the discovery process, see 940 Section 5.1. 942 To construct a Peer Offer Signal, the Signal Type value in the Signal 943 Header is set to 2 (see Signal Type Registration (Section 13.2)). 945 The Peer Offer Signal MAY contain a Peer Type Data Item 946 (Section 11.4). 948 The Peer Offer Signal MAY contain one or more of any of the following 949 Data Items, with different values: 951 o IPv4 Connection Point (Section 11.2) 953 o IPv6 Connection Point (Section 11.3) 955 The IP Connection Point Data Items indicate the unicast address the 956 router MUST use when connecting the DLEP TCP session. 958 10.5. Session Initialization Message 960 A Session Initialization Message MUST be sent by a DLEP router as the 961 first Message of the DLEP TCP session. It is sent by the router 962 after a TCP connect to an address/port combination that was obtained 963 either via receipt of a Peer Offer, or from a priori configuration. 965 To construct a Session Initialization Message, the Message Type value 966 in the Message Header is set to 1 (see Message Type Registration 967 (Section 13.3)). 969 The Session Initialization Message MUST contain a Heartbeat Interval 970 Data Item (Section 11.5). 972 The Session Initialization Message MAY contain one of each of the 973 following Data Items: 975 o Peer Type (Section 11.4) 977 o Extensions Supported (Section 11.6) 979 If any optional extensions are supported by the implementation, they 980 MUST be enumerated in the Extensions Supported Data Item. If an 981 Extensions Supported Data Item does not exist in a Session 982 Initialization Message, the modem MUST conclude that there is no 983 support for extensions in the router. 985 DLEP Heartbeats are not fully established until receipt of the 986 Session Initialization Response Message (Section 10.6), and therefore 987 implementations MUST use their own timeout and retry heuristics for 988 this Message. 990 As an exception to the general rule governing an implementation 991 receiving an unrecognized Data Item in a Message, see Section 10.1, 992 if a Session Initialization Message contains one or more Extension 993 Supported Data Items announcing support for extensions that the 994 implementation does not recognize, then the implementation MAY ignore 995 Data Items it does not recognize. 997 10.6. Session Initialization Response Message 999 A Session Initialization Response Message MUST be sent in response to 1000 a received Session Initialization Message (Section 10.5). 1002 To construct a Session Initialization Response Message, the Message 1003 Type value in the Message Header is set to 2 (see Message Type 1004 Registration (Section 13.3)). 1006 The Session Initialization Response Message MUST contain one of each 1007 of the following Data Items: 1009 o Status (Section 11.1) 1011 o Heartbeat Interval (Section 11.5) 1013 o Maximum Data Rate (Receive) (Section 11.12) 1015 o Maximum Data Rate (Transmit) (Section 11.13) 1017 o Current Data Rate (Receive) (Section 11.14) 1019 o Current Data Rate (Transmit) (Section 11.15) 1021 o Latency (Section 11.16) 1023 The Session Initialization Response Message MUST contain one of each 1024 of the following Data Items, if the Data Item will be used during the 1025 lifetime of the session: 1027 o Resources (Section 11.17) 1029 o Relative Link Quality (Receive) (Section 11.18) 1031 o Relative Link Quality (Transmit) (Section 11.19) 1033 o Maximum Transmission Unit (MTU) (Section 11.20) 1034 The Session Initialization Response Message MAY contain one of each 1035 of the following Data Items: 1037 o Peer Type (Section 11.4) 1039 o Extensions Supported (Section 11.6) 1041 The Session Initialization Response Message completes the DLEP 1042 session establishment; the modem should transition to the In-Session 1043 state when the Message is sent, and the router should transition to 1044 the In-Session state upon receipt of an acceptable Session 1045 Initialization Response Message. 1047 All supported metric Data Items MUST be included in the Session 1048 Initialization Response Message, with default values to be used on a 1049 session-wide basis. This can be viewed as the modem 'declaring' all 1050 supported metrics at DLEP session initialization. Receipt of any 1051 further DLEP Message containing a metric Data Item not included in 1052 the Session Initialization Response Message MUST be treated as an 1053 error, resulting in the termination of the DLEP session between 1054 router and modem. 1056 If any optional extensions are supported by the modem, they MUST be 1057 enumerated in the Extensions Supported Data Item. If an Extensions 1058 Supported Data Item does not exist in a Session Initialization 1059 Response Message, the router MUST conclude that there is no support 1060 for extensions in the modem. 1062 After the Session Initialization/Session Initialization Response 1063 Messages have been successfully exchanged, implementations MUST only 1064 use extensions that are supported by both DLEP participants, see 1065 Section 5.2. 1067 10.7. Session Update Message 1069 A Session Update Message MAY be sent by a DLEP participant to 1070 indicate local Layer 3 address changes, or metric changes on a 1071 session-wide basis. 1073 To construct a Session Update Message, the Message Type value in the 1074 Message Header is set to 3 (see Message Type Registration 1075 (Section 13.3)). 1077 The Session Update Message MAY contain one of each of the following 1078 Data Items: 1080 o Maximum Data Rate (Receive) (Section 11.12) 1081 o Maximum Data Rate (Transmit) (Section 11.13) 1083 o Current Data Rate (Receive) (Section 11.14) 1085 o Current Data Rate (Transmit) (Section 11.15) 1087 o Latency (Section 11.16) 1089 The Session Update Message MAY contain one of each of the following 1090 Data Items, if the Data Item is in use by the session: 1092 o Resources (Section 11.17) 1094 o Relative Link Quality (Receive) (Section 11.18) 1096 o Relative Link Quality (Transmit) (Section 11.19) 1098 o Maximum Transmission Unit (MTU) (Section 11.20) 1100 The Session Update Message MAY contain one or more of each of the 1101 following Data Items, with different values: 1103 o IPv4 Address (Section 11.8) 1105 o IPv6 Address (Section 11.9) 1107 If metrics are supplied with the Session Update Message (e.g., 1108 Maximum Data Rate), these metrics are considered to be session-wide, 1109 and therefore MUST be applied to all destinations in the information 1110 base associated with the DLEP session. This includes destinations 1111 for which metrics may have been stored based on received Destination 1112 Update messages. 1114 It should be noted that Session Update Messages can be sent by both 1115 routers and modems. For example, addition of an IPv4 address to the 1116 router MAY prompt a Session Update Message to its attached modems. 1117 Also, for example, a modem that changes its Maximum Data Rate 1118 (Receive) for all destinations MAY reflect that change via a Session 1119 Update Message to its attached router(s). 1121 Concerning Layer 3 addresses: If the modem is capable of 1122 understanding and forwarding this information (via proprietary 1123 mechanisms), the address update would prompt any remote DLEP modems 1124 (DLEP-enabled modems in a remote node) to issue a Destination Update 1125 Message (Section 10.17) to their local routers with the new (or 1126 deleted) addresses. Modems that do not track Layer 3 addresses 1127 SHOULD silently ignore Address Data Items. 1129 10.8. Session Update Response Message 1131 A Session Update Response Message MUST be sent by a DLEP participant 1132 when a Session Update Message (Section 10.7) is received. 1134 To construct a Session Update Response Message, the Message Type 1135 value in the Message Header is set to 4 (see Message Type 1136 Registration (Section 13.3)). 1138 The Session Update Response Message MUST contain a Status Data Item 1139 (Section 11.1). 1141 10.9. Session Termination Message 1143 A Session Termination Message MUST be sent by a DLEP participant when 1144 the DLEP session needs to be terminated. 1146 To construct a Session Termination Message, the Message Type value in 1147 the Message Header is set to 5 (see Message Type Registration 1148 (Section 13.3)). 1150 The Session Termination Message MUST contain Status Data Item 1151 (Section 11.1). 1153 It should be noted that Session Termination Messages can be sent by 1154 both routers and modems. 1156 10.10. Session Termination Response Message 1158 A Session Termination Response Message MUST be sent by a DLEP 1159 participant when a Session Termination Message (Section 10.9) is 1160 received. 1162 To construct a Session Termination Response Message, the Message Type 1163 value in the Message Header is set to 6 (see Message Type 1164 Registration (Section 13.3)). 1166 There are no valid Data Items for the Session Termination Response 1167 Message. 1169 Receipt of a Session Termination Response Message completes the tear- 1170 down of the DLEP session, see Section 5.4. 1172 10.11. Destination Up Message 1174 Destination Up Messages MAY be sent by a modem to inform its attached 1175 router of the presence of a new reachable destination. 1177 To construct a Destination Up Message, the Message Type value in the 1178 Message Header is set to 7 (see Message Type Registration 1179 (Section 13.3)). 1181 The Destination Up Message MUST contain a MAC Address Data Item 1182 (Section 11.7). 1184 The Destination Up Message SHOULD contain one or more of each of the 1185 following Data Items, with different values: 1187 o IPv4 Address (Section 11.8) 1189 o IPv6 Address (Section 11.9) 1191 The Destination Up Message MAY contain one of each of the following 1192 Data Items: 1194 o Maximum Data Rate (Receive) (Section 11.12) 1196 o Maximum Data Rate (Transmit) (Section 11.13) 1198 o Current Data Rate (Receive) (Section 11.14) 1200 o Current Data Rate (Transmit) (Section 11.15) 1202 o Latency (Section 11.16) 1204 The Destination Up Message MAY contain one of each of the following 1205 Data Items, if the Data Item is in use by the session: 1207 o Resources (Section 11.17) 1209 o Relative Link Quality (Receive) (Section 11.18) 1211 o Relative Link Quality (Transmit) (Section 11.19) 1213 o Maximum Transmission Unit (MTU) (Section 11.20) 1215 The Destination Up Message MAY contain one or more of each of the 1216 following Data Items, with different values: 1218 o IPv4 Attached Subnet (Section 11.10) 1219 o IPv6 Attached Subnet (Section 11.11) 1221 A router receiving a Destination Up Message allocates the necessary 1222 resources, creating an entry in the information base with the 1223 specifics (MAC Address, Latency, Data Rate, etc.) of the destination. 1224 The information about this destination will persist in the router's 1225 information base until a Destination Down Message (Section 10.15) is 1226 received, indicating that the modem has lost contact with the remote 1227 node, or the implementation transitions to the Session Termination 1228 state. 1230 10.12. Destination Up Response Message 1232 A router MUST send a Destination Up Response Message when a 1233 Destination Up Message (Section 10.11) is received. 1235 To construct a Destination Up Response Message, the Message Type 1236 value in the Message Header is set to 8 (see Message Type 1237 Registration (Section 13.3)). 1239 The Destination Up Response Message MUST contain one of each of the 1240 following Data Items: 1242 o MAC Address (Section 11.7) 1244 o Status (Section 11.1) 1246 A router that wishes to receive further information concerning the 1247 destination identified in the corresponding Destination Up Message 1248 MUST set the status code of the included Status Data Item to 0 1249 'Success', see Table 2. 1251 If the router has no interest in the destination identified in the 1252 corresponding Destination Up Message, then it MAY set the status code 1253 of the included Status Data Item to 1 'Not Interested'. 1255 A modem receiving a Destination Up Response Message containing a 1256 Status Data Item with status code of any value other than 0 'Success' 1257 MUST NOT send further Destination messages about the destination, 1258 e.g. Destination Down (Section 10.15) or Destination Update 1259 (Section 10.17) with the same MAC address. 1261 10.13. Destination Announce Message 1263 Usually a modem will discover the presence of one or more remote 1264 router/modem pairs and announce each destination's arrival by sending 1265 a corresponding Destination Up Message (Section 10.11) to the router. 1266 However, there may be times when a router wishes to express an 1267 interest in a destination that has yet to be announced, typically a 1268 multicast destination. Destination Announce Messages MAY be sent by 1269 a router to announce such an interest. 1271 A Destination Announce Message MAY also be sent by a router to 1272 request information concerning a destination in which it has 1273 previously declined interest, via the 1 'Not Interested' status code 1274 in a Destination Up Response Message (Section 10.12), see Table 2, or 1275 declared as 'down', via the Destination Down Message (Section 10.15). 1277 To construct a Destination Announce Message, the Message Type value 1278 in the Message Header is set to 9 (see Message Type Registration 1279 (Section 13.3)). 1281 The Destination Announce Message MUST contain a MAC Address Data Item 1282 (Section 11.7). 1284 The Destination Announce Message MAY contain zero or more of the 1285 following Data Items, with different values: 1287 o IPv4 Address (Section 11.8) 1289 o IPv6 Address (Section 11.9) 1291 One of the advantages of implementing DLEP is to leverage the modem's 1292 knowledge of the links between remote destinations allowing routers 1293 to avoid using probed neighbor discovery techniques, therefore modem 1294 implementations SHOULD announce available destinations via the 1295 Destination Up Message, rather than relying on Destination Announce 1296 Messages. 1298 10.14. Destination Announce Response Message 1300 A modem MUST send a Destination Announce Response Message when a 1301 Destination Announce Message (Section 10.13) is received. 1303 To construct a Destination Announce Response Message, the Message 1304 Type value in the Message Header is set to 10 (see Message Type 1305 Registration (Section 13.3)). 1307 The Destination Announce Response Message MUST contain one of each of 1308 the following Data Items: 1310 o MAC Address (Section 11.7) 1312 o Status (Section 11.1) 1313 The Destination Announce Response Message MAY contain one or more of 1314 each of the following Data Items, with different values: 1316 o IPv4 Address (Section 11.8) 1318 o IPv6 Address (Section 11.9) 1320 o IPv4 Attached Subnet (Section 11.10) 1322 o IPv6 Attached Subnet (Section 11.11) 1324 The Destination Announce Response Message MAY contain one of each of 1325 the following Data Items: 1327 o Maximum Data Rate (Receive) (Section 11.12) 1329 o Maximum Data Rate (Transmit) (Section 11.13) 1331 o Current Data Rate (Receive) (Section 11.14) 1333 o Current Data Rate (Transmit) (Section 11.15) 1335 o Latency (Section 11.16) 1337 The Destination Announce Response Message MAY contain one of each of 1338 the following Data Items, if the Data Item is in use by the session: 1340 o Resources (Section 11.17) 1342 o Relative Link Quality (Receive) (Section 11.18) 1344 o Relative Link Quality (Transmit) (Section 11.19) 1346 o Maximum Transmission Unit (MTU) (Section 11.20) 1348 If a modem is unable to report information immediately about the 1349 requested information, if the destination is not currently reachable, 1350 for example, the status code in the Status Data Item MUST be set to 2 1351 'Request Denied', see Table 2. 1353 After sending a Destination Announce Response Message containing a 1354 Status Data Item with status code of 0 'Success', a modem then 1355 announces changes to the link to the destination via Destination 1356 Update Messages. 1358 When a successful Destination Announce Response Message is received, 1359 the router should add knowledge of the available destination to its 1360 information base. 1362 10.15. Destination Down Message 1364 A modem MUST send a Destination Down Message to report when a 1365 destination (a remote node or a multicast group) is no longer 1366 reachable. 1368 A router MAY send a Destination Down Message to report when it no 1369 longer requires information concerning a destination. 1371 To construct a Destination Down Message, the Message Type value in 1372 the Message Header is set to 11 (see Message Type Registration 1373 (Section 13.3)). 1375 The Destination Down Message MUST contain a MAC Address Data Item 1376 (Section 11.7). 1378 It should be noted that both modem and router may send a Destination 1379 Down Message to their peer, regardless of which participant initially 1380 indicated the destination to be 'up'. 1382 10.16. Destination Down Response Message 1384 A Destination Down Response MUST be sent by the recipient of a 1385 Destination Down Message (Section 10.15) to confirm that the relevant 1386 data concerning the destination has been removed from the information 1387 base. 1389 To construct a Destination Down Response Message, the Message Type 1390 value in the Message Header is set to 12 (see Message Type 1391 Registration (Section 13.3)). 1393 The Destination Down Response Message MUST contain one of each of the 1394 following Data Items: 1396 o MAC Address (Section 11.7) 1398 o Status (Section 11.1) 1400 10.17. Destination Update Message 1402 A modem SHOULD send the Destination Update Message when it detects 1403 some change in the information base for a given destination (remote 1404 node or multicast group). Some examples of changes that would prompt 1405 a Destination Update Message are: 1407 o Change in link metrics (e.g., Data Rates) 1409 o Layer 3 addressing change 1410 To construct a Destination Update Message, the Message Type value in 1411 the Message Header is set to 13 (see Message Type Registration 1412 (Section 13.3)). 1414 The Destination Update Message MUST contain a MAC Address Data Item 1415 (Section 11.7). 1417 The Destination Update Message MAY contain one of each of the 1418 following Data Items: 1420 o Maximum Data Rate (Receive) (Section 11.12) 1422 o Maximum Data Rate (Transmit) (Section 11.13) 1424 o Current Data Rate (Receive) (Section 11.14) 1426 o Current Data Rate (Transmit) (Section 11.15) 1428 o Latency (Section 11.16) 1430 The Destination Update Message MAY contain one of each of the 1431 following Data Items, if the Data Item is in use by the session: 1433 o Resources (Section 11.17) 1435 o Relative Link Quality (Receive) (Section 11.18) 1437 o Relative Link Quality (Transmit) (Section 11.19) 1439 o Maximum Transmission Unit (MTU) (Section 11.20) 1441 The Destination Update Message MAY contain one or more of each of the 1442 following Data Items, with different values: 1444 o IPv4 Address (Section 11.8) 1446 o IPv6 Address (Section 11.9) 1448 o IPv4 Attached Subnet (Section 11.10) 1450 o IPv6 Attached Subnet (Section 11.11) 1452 If metrics are supplied with the Message (e.g., Resources), these 1453 metrics are MUST be applied to all destinations identified in the 1454 Message. Note that this may overwrite metrics provided in a 1455 previously received Session or Destination Up Messages. 1457 It should be noted that this Message has no corresponding response. 1459 10.18. Link Characteristics Request Message 1461 The Link Characteristics Request Message MAY be sent by a router to 1462 request that the modem initiate changes for specific characteristics 1463 of the link. The request can reference either a real destination 1464 (e.g., a remote node), or a logical destination (e.g., a multicast 1465 group) within the network. 1467 To construct a Link Characteristics Request Message, the Message Type 1468 value in the Message Header is set to 14 (see Message Type 1469 Registration (Section 13.3)). 1471 The Link Characteristics Request Message MUST contain one of the 1472 following Data Items: 1474 o MAC Address (Section 11.7) 1476 The Link Characteristics Request Message MUST contain at least one of 1477 each of the following Data Items: 1479 o Current Data Rate (Receive) (Section 11.14) 1481 o Current Data Rate (Transmit) (Section 11.15) 1483 o Latency (Section 11.16) 1485 The Link Characteristics Request Message MAY contain either a Current 1486 Data Rate (CDRR or CDRT) Data Item to request a different datarate 1487 than is currently allocated, a Latency Data Item to request that 1488 traffic delay on the link not exceed the specified value, or both. 1490 The router sending a Link Characteristics Request Message should be 1491 aware that a request may take an extended period of time to complete. 1493 10.19. Link Characteristics Response Message 1495 A modem MUST send a Link Characteristics Response Message when a Link 1496 Characteristics Request Message (Section 10.18) is received. 1498 To construct a Link Characteristics Response Message, the Message 1499 Type value in the Message Header is set to 15 (see Message Type 1500 Registration (Section 13.3)). 1502 The Link Characteristics Response Message MUST contain one of each of 1503 the following Data Items: 1505 o MAC Address (Section 11.7) 1506 o Status (Section 11.1) 1508 The Link Characteristics Response Message SHOULD contain one of each 1509 of the following Data Items: 1511 o Maximum Data Rate (Receive) (Section 11.12) 1513 o Maximum Data Rate (Transmit) (Section 11.13) 1515 o Current Data Rate (Receive) (Section 11.14) 1517 o Current Data Rate (Transmit) (Section 11.15) 1519 o Latency (Section 11.16) 1521 The Link Characteristics Response Message MAY contain one of each of 1522 the following Data Items, if the Data Item is in use by the session: 1524 o Resources (Section 11.17) 1526 o Relative Link Quality (Receive) (Section 11.18) 1528 o Relative Link Quality (Transmit) (Section 11.19) 1530 o Maximum Transmission Unit (MTU) (Section 11.20) 1532 The Link Characteristics Response Message MUST contain a complete set 1533 of metric Data Items, referencing all metrics declared in the Session 1534 Initialization Response Message (Section 10.6). The values in the 1535 metric Data Items in the Link Characteristics Response Message MUST 1536 reflect the link characteristics after the request has been 1537 processed. 1539 If an implementation is not able to alter the characteristics of the 1540 link in the manner requested, then the status code of the Status Data 1541 Item MUST be set to 2 'Request Denied', see Table 2. 1543 10.20. Heartbeat Message 1545 A Heartbeat Message MUST be sent by a DLEP participant every N 1546 milliseconds, where N is defined in the Heartbeat Interval Data Item 1547 (Section 11.5) of the Session Initialization Message (Section 10.5) 1548 or Session Initialization Response Message (Section 10.6). 1550 To construct a Heartbeat Message, the Message Type value in the 1551 Message Header is set to 16 (see Message Type Registration 1552 (Section 13.3)). 1554 There are no valid Data Items for the Heartbeat Message. 1556 The Message is used by DLEP participants to detect when a DLEP 1557 session peer (either the modem or the router) is no longer 1558 communicating, see Section 5.3.1. 1560 11. DLEP Data Items 1562 Following is the list of core Data Items that MUST be recognized by a 1563 DLEP compliant implementation. As mentioned before, not all Data 1564 Items need be used during a session, but an implementation MUST 1565 correctly process these Data Items when correctly associated with a 1566 Signal or Message. 1568 The core DLEP Data Items are: 1570 +--------------------+----------------------------------------------+ 1571 | Type Code | Description | 1572 +--------------------+----------------------------------------------+ 1573 | 0 | Reserved | 1574 | 1 | Status (Section 11.1) | 1575 | 2 | IPv4 Connection Point (Section 11.2) | 1576 | 3 | IPv6 Connection Point (Section 11.3) | 1577 | 4 | Peer Type (Section 11.4) | 1578 | 5 | Heartbeat Interval (Section 11.5) | 1579 | 6 | Extensions Supported (Section 11.6) | 1580 | 7 | MAC Address (Section 11.7) | 1581 | 8 | IPv4 Address (Section 11.8) | 1582 | 9 | IPv6 Address (Section 11.9) | 1583 | 10 | IPv4 Attached Subnet (Section 11.10) | 1584 | 11 | IPv6 Attached Subnet (Section 11.11) | 1585 | 12 | Maximum Data Rate (Receive) (MDRR) (Section | 1586 | | 11.12) | 1587 | 13 | Maximum Data Rate (Transmit) (MDRT) (Section | 1588 | | 11.13) | 1589 | 14 | Current Data Rate (Receive) (CDRR) (Section | 1590 | | 11.14) | 1591 | 15 | Current Data Rate (Transmit) (CDRT) (Section | 1592 | | 11.15) | 1593 | 16 | Latency (Section 11.16) | 1594 | 17 | Resources (RES) (Section 11.17) | 1595 | 18 | Relative Link Quality (Receive) (RLQR) | 1596 | | (Section 11.18) | 1597 | 19 | Relative Link Quality (Transmit) (RLQT) | 1598 | | (Section 11.19) | 1599 | 20 | Maximum Transmission Unit (MTU) (Section | 1600 | | 11.20) | 1601 | 21-65407 | Reserved for future extensions | 1602 | 65408-65534 | Private Use. Available for experiments | 1603 | 65535 | Reserved | 1604 +--------------------+----------------------------------------------+ 1606 Table 1: DLEP Data Item types 1608 11.1. Status 1610 For the Session Termination Message (Section 10.9), the Status Data 1611 Item indicates a reason for the termination. For all response 1612 Messages, the Status Data Item is used to indicate the success or 1613 failure of the previously received Message. 1615 The Status Data Item includes an optional Text field that can be used 1616 to provide a textual description of the status. The use of the Text 1617 field is entirely up to the receiving implementation, e.g., it could 1618 be output to a log file or discarded. If no Text field is supplied 1619 with the Status Data Item, the Length field MUST be set to 1. 1621 The Status Data Item contains the following fields: 1623 0 1 2 3 1624 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 1625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1626 | Data Item Type | Length | 1627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1628 | Code | Text... : 1629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1631 Data Item Type: 1 1633 Length: 1 + Length of text, in octets 1635 Status Code: One of the codes defined in Table 2 below. 1637 Text: UTF-8 encoded string of UNICODE [UNIV8] characters, describing 1638 the cause, used for implementation defined purposes. Since this 1639 field is used for description, implementations SHOULD limit 1640 characters in this field to printable characters. Implementations 1641 receiving this Data Item SHOULD check for printable characters in 1642 the field. 1644 An implementation MUST NOT assume the Text field is NUL-terminated. 1646 +---------+-----------+---------------+-----------------------------+ 1647 | Status | Failure | Description | Reason | 1648 | Code | Mode | | | 1649 +---------+-----------+---------------+-----------------------------+ 1650 | 0 | Continue | Success | The Message was processed | 1651 | | | | successfully. | 1652 | 1 | Continue | Not | The receiver is not | 1653 | | | Interested | interested in this Message | 1654 | | | | subject, e.g. in a | 1655 | | | | Destination Up Response | 1656 | | | | Message (Section 10.12) to | 1657 | | | | indicate no further | 1658 | | | | Messages about the | 1659 | | | | destination. | 1660 | 2 | Continue | Request | The receiver refuses to | 1661 | | | Denied | complete the request. | 1662 | 3-111 | Continue | | Reserved for future | 1663 | | | | extensions. | 1664 | 112-127 | Continue | | Available for experiments. | 1665 | 128 | Terminate | Unknown | The Message was not | 1666 | | | Message | recognized by the | 1667 | | | | implementation. | 1668 | 129 | Terminate | Unexpected | The Message was not | 1669 | | | Message | expected while the device | 1670 | | | | was in the current state, | 1671 | | | | e.g., a Session | 1672 | | | | Initialization Message | 1673 | | | | (Section 10.5) in the In- | 1674 | | | | Session state. | 1675 | 130 | Terminate | Invalid Data | One or more Data Items in | 1676 | | | | the Message are invalid, | 1677 | | | | unexpected or incorrectly | 1678 | | | | duplicated. | 1679 | 131 | Terminate | Invalid | The destination included in | 1680 | | | Destination | the Message does not match | 1681 | | | | a previously announced | 1682 | | | | destination. For example, | 1683 | | | | in the Link Characteristic | 1684 | | | | Response Message (Section | 1685 | | | | 10.19). | 1686 | 132 | Terminate | Timed Out | The session has timed out. | 1687 | 133 | Terminate | Invalid TTL | Message received with a TTL | 1688 | | | | other than 255. | 1689 | 134-239 | Terminate | | Reserved for future | 1690 | | | | extensions. | 1691 | 240-254 | Terminate | | Available for experiments. | 1692 | 255 | Terminate | | Reserved. | 1693 +---------+-----------+---------------+-----------------------------+ 1695 Table 2: DLEP Status Codes 1697 11.2. IPv4 Connection Point 1699 The IPv4 Connection Point Data Item indicates the IPv4 address and, 1700 optionally, the TCP port number on the modem available for 1701 connections. If provided, the router MUST use this information to 1702 initiate the TCP connection to the modem. 1704 The IPv4 Connection Point Data Item contains the following fields: 1706 0 1 2 3 1707 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1709 | Data Item Type | Length | 1710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 | Flags | IPv4 Address... : 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 : ...cont. | TCP Port Number (optional) | 1714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1716 Data Item Type: 2 1718 Length: 5 (or 7 if TCP Port included) 1720 Flags: Flags field, defined below. 1722 IPv4 Address: The IPv4 address listening on the modem. 1724 TCP Port Number: TCP Port number on the modem. 1726 If the Length field is 7, the port number specified MUST be used to 1727 establish the TCP session. If the TCP Port Number is omitted, i.e. 1728 the Length field is 5, the router MUST use the DLEP well-known port 1729 number (Section 13.7) to establish the TCP connection. 1731 The Flags field is defined as: 1733 0 1 2 3 4 5 6 7 1734 +-+-+-+-+-+-+-+-+ 1735 | Reserved | 1736 +-+-+-+-+-+-+-+-+ 1738 Reserved: MUST be zero. Reserved for future use. 1740 11.3. IPv6 Connection Point 1741 The IPv6 Connection Point Data Item indicates the IPv6 address and, 1742 optionally, the TCP port number on the modem available for 1743 connections. If provided, the router MUST use this information to 1744 initiate the TCP connection to the modem. 1746 The IPv6 Connection Point Data Item contains the following fields: 1748 0 1 2 3 1749 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 1750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1751 | Data Item Type | Length | 1752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1753 | Flags | IPv6 Address : 1754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1755 : IPv6 Address : 1756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1757 : IPv6 Address : 1758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1759 : IPv6 Address : 1760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1761 : ...cont. | TCP Port Number (optional) | 1762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1764 Data Item Type: 3 1766 Length: 17 (or 19 if TCP Port included) 1768 Flags: Flags field, defined below. 1770 IPv6 Address: The IPv6 address listening on the modem. 1772 TCP Port Number: TCP Port number on the modem. 1774 If the Length field is 19, the port number specified MUST be used to 1775 establish the TCP session. If the TCP Port Number is omitted, i.e. 1776 the Length field is 17, the router MUST use the DLEP well-known port 1777 number (Section 13.7) to establish the TCP connection. 1779 The Flags field is defined as: 1781 0 1 2 3 4 5 6 7 1782 +-+-+-+-+-+-+-+-+ 1783 | Reserved | 1784 +-+-+-+-+-+-+-+-+ 1786 Reserved: MUST be zero. Reserved for future use. 1788 11.4. Peer Type 1790 The Peer Type Data Item is used by the router and modem to give 1791 additional information as to its type. The Peer Type is a string and 1792 is envisioned to be used for informational purposes (e.g., as output 1793 in a display command). 1795 The Peer Type Data Item contains the following fields: 1797 0 1 2 3 1798 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 1799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1800 | Data Item Type | Length | 1801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1802 | Peer Type... : 1803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1805 Data Item Type: 4 1807 Length: Length of Peer Type string, in octets. 1809 Peer Type: UTF-8 encoded string of UNICODE [UNIV8] characters. For 1810 example, a satellite modem might set this variable to "Satellite 1811 terminal". Since this Data Item is intended to provide additional 1812 information for display commands, sending implementations SHOULD 1813 limit the data to printable characters, and receiving 1814 implementations SHOULD check the data for printable characters. 1816 An implementation MUST NOT assume the Peer Type field is NUL- 1817 terminated. 1819 11.5. Heartbeat Interval 1821 The Heartbeat Interval Data Item is used to specify a period in 1822 milliseconds for Heartbeat Messages (Section 10.20). 1824 The Heartbeat Interval Data Item contains the following fields: 1826 0 1 2 3 1827 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 1828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1829 | Data Item Type | Length | 1830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1831 | Heartbeat Interval | 1832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1834 Data Item Type: 5 1835 Length: 4 1837 Heartbeat Interval: The interval in milliseconds, expressed as a 1838 32-bit unsigned integer, for Heartbeat Messages. 1839 This value MUST NOT be 0. 1841 11.6. Extensions Supported 1843 The Extensions Supported Data Item is used by the router and modem to 1844 negotiate additional optional functionality they are willing to 1845 support. The Extensions List is a concatenation of the types of each 1846 supported extension, found in the IANA DLEP Extensions repository. 1847 Each Extension Type definition includes which additional Signals and 1848 Data Items are supported. 1850 The Extensions Supported Data Item contains the following fields: 1852 0 1 2 3 1853 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 1854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1855 | Data Item Type | Length | 1856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1857 | Extensions List... 1858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1860 Data Item Type: 6 1862 Length: Length of the extensions list in octets. This is twice (2x) 1863 the number of extensions. 1865 Extension List: A list of extensions supported, identified by their 1866 2-octet value as listed in the extensions registry. 1868 11.7. MAC Address 1870 The MAC Address Data Item contains the address of the destination on 1871 the remote node. 1873 DLEP can support MAC addresses in either EUI-48 or EUI-64 format, 1874 with the restriction that all MAC addresses for a given DLEP session 1875 MUST be in the same format, and MUST be consistent with the MAC 1876 address format of the connected modem (e.g., if the modem is 1877 connected to the router with an EUI-48 MAC, all destination addresses 1878 via that modem MUST be expressed in EUI-48 format). 1880 Examples of a virtual destination would be a multicast MAC address, 1881 or the broadcast MAC (FF:FF:FF:FF:FF:FF). 1883 0 1 2 3 1884 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 1885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1886 | Data Item Type | Length | 1887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1888 | MAC Address : 1889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1890 : MAC Address : 1891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1892 : MAC Address : (if EUI-64 used) | 1893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1895 Data Item Type: 7 1897 Length: 6 for EUI-48 format, or 8 for EUI-64 format 1899 MAC Address: MAC Address of the destination. 1901 11.8. IPv4 Address 1903 When included in Destination Messages, this Data Item contains the 1904 IPv4 address of the destination. When included in the Session Update 1905 Message, this Data Item contains the IPv4 address of the peer. In 1906 either case, the Data Item also contains an indication of whether 1907 this is a new or existing address, or is a deletion of a previously 1908 known address. 1910 The IPv4 Address Data Item contains the following fields: 1912 0 1 2 3 1913 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 1914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1915 | Data Item Type | Length | 1916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1917 | Flags | IPv4 Address : 1918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1919 : ...cont. | 1920 +-+-+-+-+-+-+-+-+ 1922 Data Item Type: 8 1924 Length: 5 1926 Flags: Flags field, defined below. 1928 IPv4 Address: The IPv4 address of the destination or peer. 1930 The Flags field is defined as: 1932 0 1 2 3 4 5 6 7 1933 +-+-+-+-+-+-+-+-+ 1934 | Reserved |A| 1935 +-+-+-+-+-+-+-+-+ 1937 A: Add/Drop flag, indicating whether this is a new or existing 1938 address (1), or a withdrawal of an address (0). 1940 Reserved: MUST be zero. Reserved for future use. 1942 11.9. IPv6 Address 1944 When included in Destination Messages, this Data Item contains the 1945 IPv6 address of the destination. When included in the Session Update 1946 Message, this Data Item contains the IPv6 address of the peer. In 1947 either case, the Data Item also contains an indication of whether 1948 this is a new or existing address, or is a deletion of a previously 1949 known address. 1951 The IPv6 Address Data Item contains the following fields: 1953 0 1 2 3 1954 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 1955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1956 | Data Item Type | Length | 1957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1958 | Flags | IPv6 Address : 1959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1960 : IPv6 Address : 1961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1962 : IPv6 Address : 1963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1964 : IPv6 Address : 1965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1966 : IPv6 Address | 1967 +-+-+-+-+-+-+-+-+ 1969 Data Item Type: 9 1971 Length: 17 1973 Flags: Flags field, defined below. 1975 IPv6 Address: IPv6 Address of the destination or peer. 1977 The Flags field is defined as: 1979 0 1 2 3 4 5 6 7 1980 +-+-+-+-+-+-+-+-+ 1981 | Reserved |A| 1982 +-+-+-+-+-+-+-+-+ 1984 A: Add/Drop flag, indicating whether this is a new or existing 1985 address (1), or a withdrawal of an address (0). 1987 Reserved: MUST be zero. Reserved for future use. 1989 11.10. IPv4 Attached Subnet 1991 The DLEP IPv4 Attached Subnet allows a device to declare that it has 1992 an IPv4 subnet (e.g., a stub network) attached, that it has become 1993 aware of an IPv4 subnet being present at a remote destination, or 1994 that it has become aware of the loss of a subnet at the remote 1995 destination. 1997 The DLEP IPv4 Attached Subnet Data Item contains the following 1998 fields: 2000 0 1 2 3 2001 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 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2003 | Data Item Type | Length | 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2005 | Flags | IPv4 Attached Subnet : 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2007 : ...cont. |Prefix Length | 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2010 Data Item Type: 10 2012 Length: 6 2014 Flags: Flags field, defined below. 2016 IPv4 Subnet: The IPv4 subnet reachable at the destination. 2018 Prefix Length: Length of the prefix (0-32) for the IPv4 subnet. A 2019 prefix length outside the specified range MUST be considered as 2020 invalid. 2022 The Flags field is defined as: 2024 0 1 2 3 4 5 6 7 2025 +-+-+-+-+-+-+-+-+ 2026 | Reserved |A| 2027 +-+-+-+-+-+-+-+-+ 2029 A: Add/Drop flag, indicating whether this is a new or existing subnet 2030 address (1), or a withdrawal of a subnet address (0). 2032 Reserved: MUST be zero. Reserved for future use. 2034 11.11. IPv6 Attached Subnet 2036 The DLEP IPv6 Attached Subnet allows a device to declare that it has 2037 an IPv6 subnet (e.g., a stub network) attached, that it has become 2038 aware of an IPv6 subnet being present at a remote destination, or 2039 that it has become aware of the loss of a subnet at the remote 2040 destination. 2042 The DLEP IPv6 Attached Subnet Data Item contains the following 2043 fields: 2045 0 1 2 3 2046 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 2047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2048 | Data Item Type | Length | 2049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2050 | Flags | IPv6 Attached Subnet : 2051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2052 : IPv6 Attached Subnet : 2053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2054 : IPv6 Attached Subnet : 2055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2056 : IPv6 Attached Subnet : 2057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2058 : ...cont. | Prefix Len. | 2059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2061 Data Item Type: 11 2063 Length: 18 2065 Flags: Flags field, defined below. 2067 IPv6 Attached Subnet: The IPv6 subnet reachable at the destination. 2069 Prefix Length: Length of the prefix (0-128) for the IPv6 subnet. A 2070 prefix length outside the specified range MUST be considered as 2071 invalid. 2073 The Flags field is defined as: 2075 0 1 2 3 4 5 6 7 2076 +-+-+-+-+-+-+-+-+ 2077 | Reserved |A| 2078 +-+-+-+-+-+-+-+-+ 2080 A: Add/Drop flag, indicating whether this is a new or existing subnet 2081 address (1), or a withdrawal of a subnet address (0). 2083 Reserved: MUST be zero. Reserved for future use. 2085 11.12. Maximum Data Rate (Receive) 2087 The Maximum Data Rate (Receive) (MDRR) Data Item is used to indicate 2088 the maximum theoretical data rate, in bits per second, that can be 2089 achieved while receiving data on the link. 2091 The Maximum Data Rate (Receive) Data Item contains the following 2092 fields: 2094 0 1 2 3 2095 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2097 | Data Item Type | Length | 2098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2099 | MDRR (bps) : 2100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2101 : MDRR (bps) | 2102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2104 Data Item Type: 12 2106 Length: 8 2108 Maximum Data Rate (Receive): A 64-bit unsigned integer, representing 2109 the maximum theoretical data rate, in bits per second (bps), that 2110 can be achieved while receiving on the link. 2112 11.13. Maximum Data Rate (Transmit) 2114 The Maximum Data Rate (Transmit) (MDRT) Data Item is used to indicate 2115 the maximum theoretical data rate, in bits per second, that can be 2116 achieved while transmitting data on the link. 2118 The Maximum Data Rate (Transmit) Data Item contains the following 2119 fields: 2121 0 1 2 3 2122 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 2123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2124 | Data Item Type | Length | 2125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2126 | MDRT (bps) : 2127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2128 : MDRT (bps) | 2129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2131 Data Item Type: 13 2133 Length: 8 2135 Maximum Data Rate (Transmit): A 64-bit unsigned integer, 2136 representing the maximum theoretical data rate, in bits per second 2137 (bps), that can be achieved while transmitting on the link. 2139 11.14. Current Data Rate (Receive) 2141 The Current Data Rate (Receive) (CDRR) Data Item is used to indicate 2142 the rate at which the link is currently operating for receiving 2143 traffic. 2145 When used in the Link Characteristics Request Message 2146 (Section 10.18), Current Data Rate (Receive) represents the desired 2147 receive rate, in bits per second, on the link. 2149 The Current Data Rate (Receive) Data Item contains the following 2150 fields: 2152 0 1 2 3 2153 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 2154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2155 | Data Item Type | Length | 2156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2157 | CDRR (bps) : 2158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2159 : CDRR (bps) | 2160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2162 Data Item Type: 14 2164 Length: 8 2166 Current Data Rate (Receive): A 64-bit unsigned integer, representing 2167 the current data rate, in bits per second, that can currently be 2168 achieved while receiving traffic on the link. 2170 If there is no distinction between Current Data Rate (Receive) and 2171 Maximum Data Rate (Receive) (Section 11.12), Current Data Rate 2172 (Receive) MUST be set equal to the Maximum Data Rate (Receive). The 2173 Current Data Rate (Receive) MUST NOT exceed the Maximum Data Rate 2174 (Receive). 2176 11.15. Current Data Rate (Transmit) 2178 The Current Data Rate (Transmit) (CDRT) Data Item is used to indicate 2179 the rate at which the link is currently operating for transmitting 2180 traffic. 2182 When used in the Link Characteristics Request Message 2183 (Section 10.18), Current Data Rate (Transmit) represents the desired 2184 transmit rate, in bits per second, on the link. 2186 The Current Data Rate (Transmit) Data Item contains the following 2187 fields: 2189 0 1 2 3 2190 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 2191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2192 | Data Item Type | Length | 2193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2194 | CDRT (bps) : 2195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2196 : CDRT (bps) | 2197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2199 Data Item Type: 15 2201 Length: 8 2203 Current Data Rate (Transmit): A 64-bit unsigned integer, 2204 representing the current data rate, in bits per second, that can 2205 currently be achieved while transmitting traffic on the link. 2207 If there is no distinction between Current Data Rate (Transmit) and 2208 Maximum Data Rate (Transmit) (Section 11.13), Current Data Rate 2209 (Transmit) MUST be set equal to the Maximum Data Rate (Transmit). 2210 The Current Data Rate (Transmit) MUST NOT exceed the Maximum Data 2211 Rate (Transmit). 2213 11.16. Latency 2215 The Latency Data Item is used to indicate the amount of latency, in 2216 microseconds, on the link. 2218 The Latency value is reported as transmission delay. The calculation 2219 of latency is implementation dependent. For example, the latency may 2220 be a running average calculated from the internal queuing. 2222 The Latency Data Item contains the following fields: 2224 0 1 2 3 2225 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 2226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2227 | Data Item Type | Length | 2228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2229 | Latency : 2230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2231 : Latency | 2232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2234 Data Item Type: 16 2236 Length: 8 2238 Latency: A 64-bit unsigned integer, representing the transmission 2239 delay, in microseconds, that a packet encounters as it is 2240 transmitted over the link. 2242 11.17. Resources 2244 The Resources (RES) Data Item is used to indicate the amount of 2245 finite resources available for data transmission and reception at the 2246 destination as a percentage, with 0 meaning 'no resources remaining', 2247 and 100 meaning 'a full supply', assuming that when Resources reaches 2248 0 data transmission and/or reception will cease. 2250 An example of such resources might be battery life, but could equally 2251 be magic beans. The list of resources that might be considered is 2252 beyond the scope of this document, and is left to implementations to 2253 decide. 2255 This Data Item is designed to be used as an indication of some 2256 capability of the modem and/or router at the destination. 2258 The Resources Data Item contains the following fields: 2260 0 1 2 3 2261 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 2262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2263 | Data Item Type | Length | 2264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2265 | RES | 2266 +-+-+-+-+-+-+-+-+ 2268 Data Item Type: 17 2270 Length: 1 2272 Resources: An 8-bit unsigned integer percentage, 0-100, representing 2273 the amount of resources available. Any value greater than 100 2274 MUST be considered as invalid. 2276 If a device cannot calculate Resources, this Data Item MUST NOT be 2277 issued. 2279 11.18. Relative Link Quality (Receive) 2281 The Relative Link Quality (Receive) (RLQR) Data Item is used to 2282 indicate the quality of the link to a destination for receiving 2283 traffic, with 0 meaning 'worst quality', and 100 meaning 'best 2284 quality'. 2286 Quality in this context is defined as an indication of the stability 2287 of a link for reception; a destination with high Relative Link 2288 Quality (Receive) is expected to have generally stable DLEP metrics, 2289 and the metrics of a destination with low Relative Link Quality 2290 (Receive) can be expected to rapidly fluctuate over a wide range. 2292 The Relative Link Quality (Receive) Data Item contains the following 2293 fields: 2295 0 1 2 3 2296 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 2297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2298 | Data Item Type | Length | 2299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2300 | RLQR | 2301 +-+-+-+-+-+-+-+-+ 2303 Data Item Type: 18 2305 Length: 1 2306 Relative Link Quality (Receive): A non-dimensional unsigned 8-bit 2307 integer, 0-100, representing relative quality of the link for 2308 receiving traffic. Any value greater than 100 MUST be considered 2309 as invalid. 2311 If a device cannot calculate the Relative Link Quality (Receive), 2312 this Data Item MUST NOT be issued. 2314 11.19. Relative Link Quality (Transmit) 2316 The Relative Link Quality (Transmit) (RLQT) Data Item is used to 2317 indicate the quality of the link to a destination for transmitting 2318 traffic, with 0 meaning 'worst quality', and 100 meaning 'best 2319 quality'. 2321 Quality in this context is defined as an indication of the stability 2322 of a link for transmission; a destination with high Relative Link 2323 Quality (Transmit) is expected to have generally stable DLEP metrics, 2324 and the metrics of a destination with low Relative Link Quality 2325 (Transmit) can be expected to rapidly fluctuate over a wide range. 2327 The Relative Link Quality (Transmit) Data Item contains the following 2328 fields: 2330 0 1 2 3 2331 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 2332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2333 | Data Item Type | Length | 2334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2335 | RLQT | 2336 +-+-+-+-+-+-+-+-+ 2338 Data Item Type: 19 2340 Length: 1 2342 Relative Link Quality (Transmit): A non-dimensional unsigned 8-bit 2343 integer, 0-100, representing relative quality of the link for 2344 transmitting traffic. Any value greater than 100 MUST be 2345 considered as invalid. 2347 If a device cannot calculate the Relative Link Quality (Transmit), 2348 this Data Item MUST NOT be issued. 2350 11.20. Maximum Transmission Unit (MTU) 2352 The Maximum Transmission Unit (MTU) Data Item is used to indicate the 2353 maximum size, in octets, of an IP packet that can be transmitted 2354 without fragmentation, including headers, but excluding any lower 2355 layer headers. 2357 The Maximum Transmission Unit Data Item contains the following 2358 fields: 2360 0 1 2 3 2361 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 2362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2363 | Data Item Type | Length | 2364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2365 | MTU | 2366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2368 Data Item Type: 20 2370 Length: 2 2372 Maximum Transmission Unit: The maximum size, in octets, of an IP 2373 packet that can be transmitted without fragmentation, including 2374 headers, but excluding any lower layer headers. 2376 If a device cannot calculate the Maximum Transmission Unit, this Data 2377 Item MUST NOT be issued. 2379 12. Security Considerations 2381 The potential security concerns when using DLEP are: 2383 1. An attacker might pretend to be a DLEP participant, either at 2384 DLEP session initialization, or by injection of DLEP Messages 2385 once a session has been established, and/or 2387 2. DLEP Data Items could be altered by an attacker, causing the 2388 receiving implementation to inappropriately alter its information 2389 base concerning network status. 2391 Since DLEP is restricted to operation over a single (possibly 2392 logical) hop at layer 2, implementations requiring authentication and 2393 /or encryption of traffic MUST take steps to secure the Layer 2 link. 2394 Examples of technologies that can be deployed to secure the Layer 2 2395 link include [IEEE-802.1AE] and [IEEE-802.1X]. 2397 To avoid potential denial of service attack, it is RECOMMENDED that 2398 implementations using the Peer Discovery mechanism maintain an 2399 information base of hosts that persistently fail Session 2400 Initialization having provided an acceptable Peer Discovery Signal, 2401 and ignore subsequent Peer Discovery Signals from such hosts. 2403 When using DLEP discovery, it is possible that an attacker who is not 2404 in the layer 2 domain could successfully spoof a DLEP Discovery 2405 signal, causing it to arrive at a mode with TTL=1. However, the 2406 corresponding Peer Offer signal will also be sent with TTL=1, keeping 2407 the Peer Offer from reaching the attacker. This attack can be 2408 mitigated by using the information base described in the previous 2409 paragraph to ignore subsequent attempts. 2411 This specification does not address security of the data plane, as it 2412 (the data plane) is not affected, and standard security procedures 2413 can be employed. 2415 13. IANA Considerations 2417 This section specifies requests to IANA. 2419 13.1. Registrations 2421 Upon approval of this document, IANA is requested to create a new 2422 protocol registry for Dynamic Link Exchange Protocol (DLEP). The 2423 remainder of this section requests the creation of new DLEP specific 2424 registries. 2426 13.2. Signal Type Registration 2428 Upon approval of this document, IANA is requested to create a new 2429 DLEP registry, named "Signal Type Values". 2431 The following table provides initial registry values and the 2432 [RFC5226] defined policies that should apply to the registry: 2434 +--------------+-------------------------+ 2435 | Type Code | Description/Policy | 2436 +--------------+-------------------------+ 2437 | 0 | Reserved | 2438 | 1 | Peer Discovery Signal | 2439 | 2 | Peer Offer Signal | 2440 | 3-65519 | Specification Required | 2441 | 65520-65534 | Private Use | 2442 | 65535 | Reserved | 2443 +--------------+-------------------------+ 2445 13.3. Message Type Registration 2447 Upon approval of this document, IANA is requested to create a new 2448 DLEP registry, named "Message Type Values". 2450 The following table provides initial registry values and the 2451 [RFC5226] defined policies that should apply to the registry: 2453 +--------------+------------------------------------------+ 2454 | Type Code | Description/Policy | 2455 +--------------+------------------------------------------+ 2456 | 0 | Reserved | 2457 | 1 | Session Initialization Message | 2458 | 2 | Session Initialization Response Message | 2459 | 3 | Session Update Message | 2460 | 4 | Session Update Response Message | 2461 | 5 | Session Termination Message | 2462 | 6 | Session Termination Response Message | 2463 | 7 | Destination Up Message | 2464 | 8 | Destination Up Response Message | 2465 | 9 | Destination Announce Message | 2466 | 10 | Destination Announce Response Message | 2467 | 11 | Destination Down Message | 2468 | 12 | Destination Down Response Message | 2469 | 13 | Destination Update Message | 2470 | 14 | Link Characteristics Request Message | 2471 | 15 | Link Characteristics Response Message | 2472 | 16 | Heartbeat Message | 2473 | 17-65519 | Specification Required | 2474 | 65520-65534 | Private Use | 2475 | 65535 | Reserved | 2476 +--------------+------------------------------------------+ 2478 13.4. DLEP Data Item Registrations 2480 Upon approval of this document, IANA is requested to create a new 2481 DLEP registry, named "Data Item Values". 2483 The following table provides initial registry values and the 2484 [RFC5226] defined policies that should apply to the registry: 2486 +--------------+------------------------------------------+ 2487 | Type Code | Description/Policy | 2488 +--------------+------------------------------------------+ 2489 | 0 | Reserved | 2490 | 1 | Status | 2491 | 2 | IPv4 Connection Point | 2492 | 3 | IPv6 Connection Point | 2493 | 4 | Peer Type | 2494 | 5 | Heartbeat Interval | 2495 | 6 | Extensions Supported | 2496 | 7 | MAC Address | 2497 | 8 | IPv4 Address | 2498 | 9 | IPv6 Address | 2499 | 10 | IPv4 Attached Subnet | 2500 | 11 | IPv6 Attached Subnet | 2501 | 12 | Maximum Data Rate (Receive) (MDRR) | 2502 | 13 | Maximum Data Rate (Transmit) (MDRT) | 2503 | 14 | Current Data Rate (Receive) (CDRR) | 2504 | 15 | Current Data Rate (Transmit) (CDRT) | 2505 | 16 | Latency | 2506 | 17 | Resources (RES) | 2507 | 18 | Relative Link Quality (Receive) (RLQR) | 2508 | 19 | Relative Link Quality (Transmit) (RLQT) | 2509 | 20 | Maximum Transmission Unit (MTU) | 2510 | 21-65407 | Specification Required | 2511 | 65408-65534 | Private Use | 2512 | 65535 | Reserved | 2513 +--------------+------------------------------------------+ 2515 13.5. DLEP Status Code Registrations 2517 Upon approval of this document, IANA is requested to create a new 2518 DLEP registry, named "Status Code Values". 2520 The following table provides initial registry values and the 2521 [RFC5226] defined policies that should apply to the registry: 2523 +--------------+---------------+-------------------------+ 2524 | Status Code | Failure Mode | Description/Policy | 2525 +--------------+---------------+-------------------------+ 2526 | 0 | Continue | Success | 2527 | 1 | Continue | Not Interested | 2528 | 2 | Continue | Request Denied | 2529 | 3-111 | Continue | Specification Required | 2530 | 112-127 | Continue | Private Use | 2531 | 128 | Terminate | Unknown Message | 2532 | 129 | Terminate | Unexpected Message | 2533 | 130 | Terminate | Invalid Data | 2534 | 131 | Terminate | Invalid Destination | 2535 | 132 | Terminate | Timed Out | 2536 | 133-239 | Terminate | Specification Required | 2537 | 240-254 | Terminate | Private Use | 2538 | 255 | Terminate | Reserved | 2539 +--------------+---------------+-------------------------+ 2541 13.6. DLEP Extensions Registrations 2543 Upon approval of this document, IANA is requested to create a new 2544 DLEP registry, named "Extension Type Values". 2546 The following table provides initial registry values and the 2547 [RFC5226] defined policies that should apply to the registry: 2549 +--------------+----------------------------+ 2550 | Code | Description/Policy | 2551 +--------------+----------------------------+ 2552 | 0 | Reserved | 2553 | 1 | Credit Windowing [CREDIT] | 2554 | 2-65519 | Specification Required | 2555 | 65520-65534 | Private Use | 2556 | 65535 | Reserved | 2557 +--------------+----------------------------+ 2559 Table 3: DLEP Extension types 2561 13.7. DLEP Well-known Port 2563 Upon approval of this document, IANA is requested to assign a single 2564 value in the "Service Name and Transport Protocol Port Number 2565 Registry" found at https://www.iana.org/assignments/service-names- 2566 port-numbers/service-names-port-numbers.xhtml for use by "DLEP", as 2567 defined in this document. This assignment should be valid for TCP 2568 and UDP. 2570 13.8. DLEP IPv4 Link-local Multicast Address 2572 Upon approval of this document, IANA is requested to assign an IPv4 2573 multicast address registry found at http://www.iana.org/assignments/ 2574 multicast-addresses for use as the "IPv4 DLEP Discovery Address". 2576 13.9. DLEP IPv6 Link-local Multicast Address 2578 Upon approval of this document, IANA is requested to assign an IPv6 2579 multicast address registry found at http://www.iana.org/assignments/ 2580 multicast-addresses for use as the "IPv6 DLEP Discovery Address". 2582 14. Acknowledgements 2584 We would like to acknowledge and thank the members of the DLEP design 2585 team, who have provided invaluable insight. The members of the 2586 design team are: Teco Boot, Bow-Nan Cheng, John Dowdell, and Henning 2587 Rogge. 2589 We would also like to acknowledge the influence and contributions of 2590 Greg Harrison, Chris Olsen, Martin Duke, Subir Das, Jaewon Kang, 2591 Vikram Kaul, Nelson Powell, Lou Berger, and Victoria Mercieca. 2593 15. References 2595 15.1. Normative References 2597 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2598 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 2599 RFC2119, March 1997, 2600 . 2602 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 2603 Pignataro, "The Generalized TTL Security Mechanism 2604 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 2605 . 2607 [UNIV8] , "The Unicode Consortium. The Unicode Standard, Version 2608 8.0.0, (Mountain View, CA: The Unicode Consortium, 2015. 2609 ISBN 978-1-936213-10-8)", 2610 http://www.unicode.org/versions/Unicode8.0.0/, June 2015. 2612 15.2. Informative References 2614 [CREDIT] Ratliff, S., "Credit Windowing extension for DLEP", IETF 2615 draft draft-ietf-manet-credit-window-04, March 2016. 2617 [IEEE-802.1AE] 2618 , "IEEE Standards for Local and Metropolitan Area 2619 Networks: Media Access Control (MAC) Security", DOI 2620 10.1109/IEEESTD.2006.245590, August 2006. 2622 [IEEE-802.1X] 2623 , "IEEE Standards for Local and Metropolitan Area 2624 Networks: Port based Network Access Control", DOI 10.1109/ 2625 IEEESTD.2010.5409813, February 2010. 2627 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2628 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2629 DOI 10.17487/RFC5226, May 2008, 2630 . 2632 [RFC5578] Berry, B., Ed., Ratliff, S., Paradise, E., Kaiser, T., and 2633 M. Adams, "PPP over Ethernet (PPPoE) Extensions for Credit 2634 Flow and Link Metrics", RFC 5578, DOI 10.17487/RFC5578, 2635 February 2010, . 2637 Appendix A. Discovery Signal Flows 2639 Router Modem Signal Description 2640 ======================================================================== 2642 | Router initiates discovery, starts 2643 | a timer, send Peer Discovery 2644 |-------Peer Discovery---->X Signal. 2646 ~ ~ ~ ~ ~ ~ ~ Router discovery timer expires 2647 without receiving Peer Offer. 2649 | Router sends another Peer 2650 |-------Peer Discovery---------->| Discovery Signal. 2651 | 2652 | Modem receives Peer Discovery 2653 | Signal. 2654 | 2655 | Modem sends Peer Offer with 2656 |<--------Peer Offer-------------| Connection Point information. 2657 : 2658 : Router MAY cancel discovery timer 2659 : and stop sending Peer Discovery 2660 : Signals. 2662 Appendix B. Peer Level Message Flows 2664 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 2746 Router Modem Message Description 2747 ======================================================================== 2749 | Router sends Session Termination 2750 |------Session Termination------>| Message with Status Data Item. 2751 | | 2752 |-------TCP shutdown (send)---> | Router stops sending Messages. 2753 | 2754 | Modem receives Session 2755 | Termination, stops counting 2756 | received heartbeats and stops 2757 | sending heartbeats. 2758 | 2759 | Modem sends Session Termination 2760 |<---Session Termination Resp.---| Response with Status 'Success'. 2761 | 2762 | Modem stops sending Messages. 2763 | 2764 ||---------TCP close------------|| Session terminated. 2766 B.6. Modem Terminates Session 2768 Router Modem Message Description 2769 ======================================================================== 2771 | Modem sends Session Termination 2772 |<----Session Termination--------| Message with Status Data Item. 2773 | 2774 | Modem stops sending Messages. 2775 | 2776 | Router receives Session 2777 | Termination, stops counting 2778 | received heartbeats and stops 2779 | sending heartbeats. 2780 | 2781 | Router sends Session Termination 2782 |---Session Termination Resp.--->| Response with Status 'Success'. 2783 | 2784 | Router stops sending Messages. 2785 | 2786 ||---------TCP close------------|| Session terminated. 2788 B.7. Session Heartbeats 2790 Router Modem Message Description 2791 ======================================================================== 2793 |----------Heartbeat------------>| Router sends heartbeat Message 2794 | 2795 | Modem resets heartbeats missed 2796 | counter. 2798 ~ ~ ~ ~ ~ ~ ~ 2800 |---------[Any Message]--------->| When the Modem receives any 2801 | Message from the Router. 2802 | 2803 | Modem resets heartbeats missed 2804 | counter. 2806 ~ ~ ~ ~ ~ ~ ~ 2808 |<---------Heartbeat-------------| Modem sends heartbeat Message 2809 | 2810 | Router resets heartbeats missed 2811 | counter. 2813 ~ ~ ~ ~ ~ ~ ~ 2815 |<--------[Any Message]----------| When the Router receives any 2816 | Message from the Modem. 2817 | 2818 | Modem resets heartbeats missed 2819 | counter. 2821 B.8. Router Detects a Heartbeat timeout 2823 Router Modem Message Description 2824 ======================================================================== 2826 X<----------------------| Router misses a heartbeat 2828 | X<----------------------| Router misses too many heartbeats 2829 | 2830 | 2831 |------Session Termination------>| Router sends Session Termination 2832 | Message with 'Timeout' Status 2833 | Data Item. 2834 : 2835 : Termination proceeds... 2837 B.9. Modem Detects a Heartbeat timeout 2839 Router Modem Message Description 2840 ======================================================================== 2842 |---------------------->X Modem misses a heartbeat 2844 |---------------------->X | Modem misses too many heartbeats 2845 | 2846 | 2847 |<-----Session Termination-------| Modem sends Session Termination 2848 | Message with 'Timeout' Status 2849 | Data Item. 2850 : 2851 : Termination proceeds... 2853 Appendix C. Destination Specific Message Flows 2855 C.1. Common Destination Notification 2857 Router Modem Message Description 2858 ======================================================================== 2860 | Modem detects a new logical 2861 | destination is reachable, and 2862 |<-------Destination Up----------| sends Destination Up Message. 2863 | 2864 |------Destination Up Resp.----->| Router sends Destination Up 2865 | Response. 2867 ~ ~ ~ ~ ~ ~ ~ 2868 | Modem detects change in logical 2869 | destination metrics, and sends 2870 |<-------Destination Update------| Destination Update Message. 2872 ~ ~ ~ ~ ~ ~ ~ 2873 | Modem detects change in logical 2874 | destination metrics, and sends 2875 |<-------Destination Update------| Destination Update Message. 2877 ~ ~ ~ ~ ~ ~ ~ 2878 | Modem detects logical destination 2879 | is no longer reachable, and sends 2880 |<-------Destination Down--------| Destination Down Message. 2881 | 2882 | Router receives Destination Down, 2883 | updates internal state, and sends 2884 |------Destination Down Resp.--->| Destination Down Response Message. 2886 C.2. Multicast Destination Notification 2888 Router Modem Message Description 2889 ======================================================================== 2891 | Router detects a new multicast 2892 | destination is in use, and sends 2893 |-----Destination Announce------>| Destination Announce Message. 2894 | 2895 | Modem updates internal state to 2896 | monitor multicast destination, and 2897 |<-----Dest. Announce Resp.------| sends Destination Announce 2898 Response. 2900 ~ ~ ~ ~ ~ ~ ~ 2901 | Modem detects change in multicast 2902 | destination metrics, and sends 2903 |<-------Destination Update------| Destination Update Message. 2905 ~ ~ ~ ~ ~ ~ ~ 2906 | Modem detects change in multicast 2907 | destination metrics, and sends 2908 |<-------Destination Update------| Destination Update Message. 2910 ~ ~ ~ ~ ~ ~ ~ 2911 | Router detects multicast 2912 | destination is no longer in use, 2913 |--------Destination Down------->| and sends Destination Down 2914 | Message. 2915 | 2916 | Modem receives Destination Down, 2917 | updates internal state, and sends 2918 |<-----Destination Down Resp.----| Destination Down Response Message. 2920 C.3. Link Characteristics Request 2922 Router Modem Message Description 2923 ======================================================================== 2925 Destination has already been 2926 ~ ~ ~ ~ ~ ~ ~ announced by either peer. 2928 | Router requires different 2929 | Characteristics for the 2930 | destination, and sends Link 2931 |--Link Characteristics Request->| Characteristics Request Message. 2932 | 2933 | Modem attempts to adjust link 2934 | properties to meet the received 2935 | request, and sends a Link 2936 | Characteristics Response 2937 |<---Link Characteristics Resp.--| Message with the new values. 2939 Authors' Addresses 2941 Stan Ratliff 2942 VT iDirect 2943 13861 Sunrise Valley Drive, Suite 300 2944 Herndon, VA 20171 2945 USA 2947 Email: sratliff@idirect.net 2949 Shawn Jury 2950 Cisco Systems 2951 170 West Tasman Drive 2952 San Jose, CA 95134 2953 USA 2955 Email: sjury@cisco.com 2957 Darryl Satterwhite 2958 Broadcom 2960 Email: dsatterw@broadcom.com 2961 Rick Taylor 2962 Airbus Defence & Space 2963 Quadrant House 2964 Celtic Springs 2965 Coedkernew 2966 Newport NP10 8FZ 2967 UK 2969 Email: rick.taylor@airbus.com 2971 Bo Berry