idnits 2.17.00 (12 Aug 2021) /tmp/idnits27200/draft-ietf-manet-dlep-24.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 276 has weird spacing: '... Shared o ...' == Line 277 has weird spacing: '... Medium o ...' -- The document date (July 25, 2016) is 2126 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 2639, 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: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networks Working Group S. Ratliff 3 Internet-Draft VT iDirect 4 Intended status: Standards Track S. Jury 5 Expires: January 26, 2017 Cisco Systems 6 D. Satterwhite 7 Broadcom 8 R. Taylor 9 Airbus Defence & Space 10 B. Berry 11 July 25, 2016 13 Dynamic Link Exchange Protocol (DLEP) 14 draft-ietf-manet-dlep-24 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 26, 2017. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 64 2.1. Destinations . . . . . . . . . . . . . . . . . . . . . . 8 65 3. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 9 67 4. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 5. DLEP Session Flow . . . . . . . . . . . . . . . . . . . . . . 11 69 5.1. Peer Discovery State . . . . . . . . . . . . . . . . . . 11 70 5.2. Session Initialization State . . . . . . . . . . . . . . 12 71 5.3. In-Session State . . . . . . . . . . . . . . . . . . . . 13 72 5.3.1. Heartbeats . . . . . . . . . . . . . . . . . . . . . 13 73 5.4. Session Termination State . . . . . . . . . . . . . . . . 14 74 5.5. Session Reset state . . . . . . . . . . . . . . . . . . . 14 75 5.5.1. Unexpected TCP connection termination . . . . . . . . 14 76 6. Transaction Model . . . . . . . . . . . . . . . . . . . . . . 15 77 7. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 7.1. Experiments . . . . . . . . . . . . . . . . . . . . . . . 16 79 8. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 9. DLEP Signal and Message Structure . . . . . . . . . . . . . . 17 81 9.1. DLEP Signal Header . . . . . . . . . . . . . . . . . . . 17 82 9.2. DLEP Message Header . . . . . . . . . . . . . . . . . . . 18 83 9.3. DLEP Generic Data Item . . . . . . . . . . . . . . . . . 18 84 10. DLEP Signals and Messages . . . . . . . . . . . . . . . . . . 19 85 10.1. General Processing Rules . . . . . . . . . . . . . . . . 19 86 10.2. Status code processing . . . . . . . . . . . . . . . . . 20 87 10.3. Peer Discovery Signal . . . . . . . . . . . . . . . . . 20 88 10.4. Peer Offer Signal . . . . . . . . . . . . . . . . . . . 21 89 10.5. Session Initialization Message . . . . . . . . . . . . . 21 90 10.6. Session Initialization Response Message . . . . . . . . 22 91 10.7. Session Update Message . . . . . . . . . . . . . . . . . 24 92 10.8. Session Update Response Message . . . . . . . . . . . . 25 93 10.9. Session Termination Message . . . . . . . . . . . . . . 25 94 10.10. Session Termination Response Message . . . . . . . . . . 25 95 10.11. Destination Up Message . . . . . . . . . . . . . . . . . 26 96 10.12. Destination Up Response Message . . . . . . . . . . . . 27 97 10.13. Destination Announce Message . . . . . . . . . . . . . . 28 98 10.14. Destination Announce Response Message . . . . . . . . . 28 99 10.15. Destination Down Message . . . . . . . . . . . . . . . . 30 100 10.16. Destination Down Response Message . . . . . . . . . . . 30 101 10.17. Destination Update Message . . . . . . . . . . . . . . . 31 102 10.18. Link Characteristics Request Message . . . . . . . . . . 32 103 10.19. Link Characteristics Response Message . . . . . . . . . 33 104 10.20. Heartbeat Message . . . . . . . . . . . . . . . . . . . 34 105 11. DLEP Data Items . . . . . . . . . . . . . . . . . . . . . . . 34 106 11.1. Status . . . . . . . . . . . . . . . . . . . . . . . . . 35 107 11.2. IPv4 Connection Point . . . . . . . . . . . . . . . . . 37 108 11.3. IPv6 Connection Point . . . . . . . . . . . . . . . . . 38 109 11.4. Peer Type . . . . . . . . . . . . . . . . . . . . . . . 39 110 11.5. Heartbeat Interval . . . . . . . . . . . . . . . . . . . 40 111 11.6. Extensions Supported . . . . . . . . . . . . . . . . . . 41 112 11.7. MAC Address . . . . . . . . . . . . . . . . . . . . . . 41 113 11.8. IPv4 Address . . . . . . . . . . . . . . . . . . . . . . 42 114 11.9. IPv6 Address . . . . . . . . . . . . . . . . . . . . . . 43 115 11.10. IPv4 Attached Subnet . . . . . . . . . . . . . . . . . . 44 116 11.11. IPv6 Attached Subnet . . . . . . . . . . . . . . . . . . 45 117 11.12. Maximum Data Rate (Receive) . . . . . . . . . . . . . . 46 118 11.13. Maximum Data Rate (Transmit) . . . . . . . . . . . . . . 46 119 11.14. Current Data Rate (Receive) . . . . . . . . . . . . . . 47 120 11.15. Current Data Rate (Transmit) . . . . . . . . . . . . . . 48 121 11.16. Latency . . . . . . . . . . . . . . . . . . . . . . . . 48 122 11.17. Resources . . . . . . . . . . . . . . . . . . . . . . . 49 123 11.18. Relative Link Quality (Receive) . . . . . . . . . . . . 50 124 11.19. Relative Link Quality (Transmit) . . . . . . . . . . . . 51 125 11.20. Maximum Transmission Unit (MTU) . . . . . . . . . . . . 52 126 12. Security Considerations . . . . . . . . . . . . . . . . . . . 52 127 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 128 13.1. Registrations . . . . . . . . . . . . . . . . . . . . . 53 129 13.2. Signal Type Registration . . . . . . . . . . . . . . . . 53 130 13.3. Message Type Registration . . . . . . . . . . . . . . . 53 131 13.4. DLEP Data Item Registrations . . . . . . . . . . . . . . 54 132 13.5. DLEP Status Code Registrations . . . . . . . . . . . . . 55 133 13.6. DLEP Extensions Registrations . . . . . . . . . . . . . 56 134 13.7. DLEP Well-known Port . . . . . . . . . . . . . . . . . . 56 135 13.8. DLEP IPv4 Link-local Multicast Address . . . . . . . . . 57 136 13.9. DLEP IPv6 Link-local Multicast Address . . . . . . . . . 57 137 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57 138 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 139 15.1. Normative References . . . . . . . . . . . . . . . . . . 57 140 15.2. Informative References . . . . . . . . . . . . . . . . . 57 142 Appendix A. Discovery Signal Flows . . . . . . . . . . . . . . . 58 143 Appendix B. Peer Level Message Flows . . . . . . . . . . . . . . 59 144 B.1. Session Initialization . . . . . . . . . . . . . . . . . 59 145 B.2. Session Initialization - Refused . . . . . . . . . . . . 59 146 B.3. Router Changes IP Addresses . . . . . . . . . . . . . . . 60 147 B.4. Modem Changes Session-wide Metrics . . . . . . . . . . . 60 148 B.5. Router Terminates Session . . . . . . . . . . . . . . . . 61 149 B.6. Modem Terminates Session . . . . . . . . . . . . . . . . 61 150 B.7. Session Heartbeats . . . . . . . . . . . . . . . . . . . 62 151 B.8. Router Detects a Heartbeat timeout . . . . . . . . . . . 63 152 B.9. Modem Detects a Heartbeat timeout . . . . . . . . . . . . 64 153 Appendix C. Destination Specific Message Flows . . . . . . . . . 64 154 C.1. Common Destination Notification . . . . . . . . . . . . . 64 155 C.2. Multicast Destination Notification . . . . . . . . . . . 65 156 C.3. Link Characteristics Request . . . . . . . . . . . . . . 66 157 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 67 159 1. Introduction 161 There exist today a collection of modem devices that control links of 162 variable datarate and quality. Examples of these types of links 163 include line-of-sight (LOS) terrestrial radios, satellite terminals, 164 and broadband modems. Fluctuations in speed and quality of these 165 links can occur due to configuration, or on a moment-to-moment basis, 166 due to physical phenomena like multipath interference, obstructions, 167 rain fade, etc. It is also quite possible that link quality and 168 datarate vary with respect to individual destinations on a link, and 169 with the type of traffic being sent. As an example, consider the 170 case of an IEEE 802.11 access point, serving two associated laptop 171 computers. In this environment, the answer to the question "What is 172 the datarate on the 802.11 link?" is "It depends on which associated 173 laptop we're talking about, and on what kind of traffic is being 174 sent." While the first laptop, being physically close to the access 175 point, may have a datarate of 54Mbps for unicast traffic, the other 176 laptop, being relatively far away, or obstructed by some object, can 177 simultaneously have a datarate of only 32Mbps for unicast. However, 178 for multicast traffic sent from the access point, all traffic is sent 179 at the base transmission rate (which is configurable, but depending 180 on the model of the access point, is usually 24Mbps or less). 182 In addition to utilizing variable datarate links, mobile networks are 183 challenged by the notion that link connectivity will come and go over 184 time, without an effect on a router's interface state (Up or Down). 185 Effectively utilizing a relatively short-lived connection is 186 problematic in IP routed networks, as IP routing protocols tend to 187 rely on interface state and independent timers to maintain network 188 convergence (e.g., HELLO messages and/or recognition of DEAD routing 189 adjacencies). These dynamic connections can be better utilized with 190 an event-driven paradigm, where acquisition of a new neighbor (or 191 loss of an existing one) is signaled, as opposed to a paradigm driven 192 by timers and/or interface state. DLEP not only implements such an 193 event-driven paradigm, but does so over a local (1 hop) TCP session, 194 which guarantees delivery of the event messages. 196 Another complicating factor for mobile networks are the different 197 methods of physically connecting the modem devices to the router. 198 Modems can be deployed as an interface card in a router's chassis, or 199 as a standalone device connected to the router via Ethernet or serial 200 link. In the case of Ethernet attachment, with existing protocols 201 and techniques, routing software cannot be aware of convergence 202 events occurring on the radio link (e.g., acquisition or loss of a 203 potential routing neighbor), nor can the router be aware of the 204 actual capacity of the link. This lack of awareness, along with the 205 variability in datarate, leads to a situation where finding the 206 (current) best route through the network to a given node is difficult 207 to establish and properly maintain. This is especially true of 208 demand-based access schemes such as Demand Assigned Multiple Access 209 (DAMA) implementations used on some satellite systems. With a DAMA- 210 based system, additional datarate may be available, but will not be 211 used unless the network devices emit traffic at a rate higher than 212 the currently established rate. Increasing the traffic rate does not 213 guarantee additional datarate will be allocated; rather, it may 214 result in data loss and additional retransmissions on the link. 216 Addressing the challenges listed above, the Dynamic Link Exchange 217 Protocol, or DLEP, has been developed. The DLEP protocol runs 218 between a router and its attached modem devices, allowing the modem 219 to communicate link characteristics as they change, and convergence 220 events (acquisition and loss of potential routing next-hops). The 221 following diagrams are used to illustrate the scope of DLEP packets. 223 |-------Local Node-------| |-------Remote Node------| 224 | | | | 225 +--------+ +-------+ +-------+ +--------+ 226 | Router |=======| Modem |{~~~~~~~~}| Modem |=======| Router | 227 | | | Device| | Device| | | 228 +--------+ +-------+ +-------+ +--------+ 229 | | | Link | | | 230 |-DLEP--| | Protocol | |-DLEP--| 231 | | | (e.g. | | | 232 | | | 802.11) | | | 234 Figure 1: DLEP Network 236 In Figure 1, when the local modem detects the presence of a remote 237 node, it (the local modem) sends a message to its router via the DLEP 238 protocol. The message consists of an indication of what change has 239 occurred on the link (e.g., presence of a remote node detected), 240 along with a collection of DLEP-defined data items that further 241 describe the change. Upon receipt of the message, the local router 242 may take whatever action it deems appropriate, such as initiating 243 discovery protocols, and/or issuing HELLO messages to converge the 244 network. On a continuing, as-needed basis, the modem devices use 245 DLEP to report any characteristics of the link (datarate, latency, 246 etc.) that have changed. DLEP is independent of the link type and 247 topology supported by the modem. Note that the DLEP protocol is 248 specified to run only on the local link between router and modem. 249 Some over the air signaling may be necessary between the local and 250 remote modem in order to provide some parameters in DLEP messages 251 between the local modem and local router, but DLEP does not specify 252 how such over the air signaling is carried out. Over the air 253 signaling is purely a matter for the modem implementer. 255 Figure 2 shows how DLEP can support a configuration where routers are 256 connected with different link types. In this example, Modem A 257 implements a point-to-point link, and Modem B is connected via a 258 shared medium. In both cases, the DLEP protocol is used to report 259 the characteristics of the link (datarate, latency, etc.) to routers. 260 The modem is also able to use the DLEP session to notify the router 261 when the remote node is lost, shortening the time required to re- 262 converge the network. 264 +--------+ +--------+ 265 +----+ Modem | | Modem +---+ 266 | | Device | | Device | 267 | | Type A | <===== // ======> | Type A | | 268 | +--------+ P-2-P Link +--------+ | 269 +---+----+ +---+----+ 270 | Router | | Router | 271 | | | | 272 +---+----+ +---+----+ 273 | +--------+ +--------+ | 274 +-----+ Modem | | Modem | | 275 | Device | o o o o o o o o | Device +--+ 276 | Type B | o Shared o | Type B | 277 +--------+ o Medium o +--------+ 278 o o 279 o o 280 o o 281 o 282 +--------+ 283 | Modem | 284 | Device | 285 | Type B | 286 +---+----+ 287 | 288 | 289 +---+----+ 290 | Router | 291 | | 292 +--------+ 294 Figure 2: DLEP Network with Multiple Modem Devices 296 2. Protocol Overview 298 DLEP defines a set of Messages used by modems and their attached 299 routers to communicate events that occur on the physical link(s) 300 managed by the modem: for example, a remote node entering or leaving 301 the network, or that the link has changed. Associated with these 302 Messages are a set of Data Items - information that describes the 303 remote node (e.g., address information), and/or the characteristics 304 of the link to the remote node. Throughout this document, we refer 305 to a modems/routers participating in a DLEP session as 'DLEP 306 Participants', unless a specific distinction (e.g. modem or router) 307 is required. 309 DLEP uses a session-oriented paradigm between the modem device and 310 its associated router. If multiple modem devices are attached to a 311 router (as in Figure 2), or the modem supports multiple connections 312 (via multiple logical or physical interfaces), then separate DLEP 313 sessions exist for each modem or connection. A router and modem form 314 a session by completing the discovery and initialization process. 315 This router-modem session persists unless or until it either (1) 316 times out, based on the absence of DLEP traffic (including 317 heartbeats), or (2) is explicitly torn down by one of the DLEP 318 participants. 320 2.1. Destinations 322 The router/modem session provides a carrier for information exchange 323 concerning 'destinations' that are available via the modem device. 324 Destinations can be identified by either the router or the modem, and 325 represent a specific, addressable location that can be reached via 326 the link(s) managed by the modem. 328 The DLEP Messages concerning destinations thus become the way for 329 routers and modems to maintain, and notify each other about, an 330 information base representing the physical and logical destinations 331 accessible via the modem device, as well as the link characteristics 332 to those destinations. 334 A destination can be either physical or logical. The example of a 335 physical destination would be that of a remote, far-end router 336 attached via the variable-quality network. It should be noted that 337 for physical destinations the MAC address is the address of the far- 338 end router, not the modem. 340 The example of a logical destination is Multicast. Multicast traffic 341 destined for the variable-quality network (the network accessed via 342 the modem) is handled in IP networks by deriving a Layer 2 MAC 343 address based on the Layer 3 address. Leveraging on this scheme, 344 multicast traffic is supported in DLEP simply by treating the derived 345 MAC address as any other destination in the network. 347 To support these logical destinations, one of the DLEP participants 348 (typically, the router) informs the other as to the existence of the 349 logical destination. The modem, once it is aware of the existence of 350 this logical destination, reports link characteristics just as it 351 would for any other destination in the network. The specific 352 algorithms a modem would use to derive metrics on logical 353 destinations are outside the scope of this specification, and is left 354 to specific implementations to decide. 356 In all cases, when this specification uses the term destination, it 357 refers to the addressable locations, either logical or physical, that 358 are accessible by the radio link(s). 360 3. Extensions 362 While this document represents the best efforts of the working group 363 to be functionally complete, it is recognized that extensions to DLEP 364 will in all likelihood be necessary as more link types are used. 365 Such extensions are defined as additional Messages, Data Items and/or 366 status codes, and associated rules of behavior, that are not defined 367 in this document. DLEP contains a standard mechanism for router and 368 modem implementations to negotiate the available extensions to use on 369 a per-session basis. 371 3.1. Requirements 373 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 374 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 375 "OPTIONAL" in this document are to be interpreted as described in BCP 376 14, RFC 2119 [RFC2119]. 378 DLEP MUST be implemented on a single Layer 2 domain. The protocol 379 identifies next-hop destinations by using the MAC address for 380 delivering data traffic. No manipulation or substitution is 381 performed; the MAC address supplied in all DLEP Messages is used as 382 the Destination MAC address for frames emitted by the participating 383 router. MAC addresses MUST be unique within the context of router- 384 modem session. 386 DLEP specifies UDP multicast for single-hop discovery signaling, and 387 TCP for transport of the Messages. Modems and routers participating 388 in DLEP sessions MUST have topologically consistent IP addresses 389 assigned. It is RECOMMENDED that DLEP implementations utilize IPv6 390 link-local addresses to reduce the administrative burden of address 391 assignment. 393 To enforce the single Layer 2 domain for DLEP Messages, 394 implementations MUST adhere to the Generalized TTL Security Mechanism 395 documented in [RFC5082] for all TCP-based DLEP Messages. 397 In order to keep the DLEP discovery Signals, which are multicast UDP- 398 based, limited to the same Layer 2 domain, implementations MUST set 399 the TTL of all DLEP Signals to 1, and MUST check for TTL = 1 on 400 receipt of DLEP Signals. Any signal received with a TTL not equal to 401 1 MUST be discarded. 403 DLEP relies on the guaranteed delivery of its Messages between router 404 and modem, once the 1 hop discovery process is complete, hence, the 405 specification of TCP to carry the Messages. Other reliable 406 transports for the protocol are possible, but are outside the scope 407 of this document. 409 DLEP further requires that security of the implementations (e.g., 410 authentication of stations, encryption of traffic, or both) is dealt 411 with by utilizing Layer 2 security techniques. This reliance on 412 Layer 2 mechanisms secures all DLEP Messages - both the UDP discovery 413 Signals and the TCP control Messages. 415 4. Metrics 417 DLEP includes the ability for the router and modem to communicate 418 metrics that reflect the characteristics (e.g., datarate, latency) of 419 the variable-quality link in use. DLEP does not specify how a given 420 metric value is to be calculated, rather, the protocol assumes that 421 metrics have been calculated by a 'best effort', incorporating all 422 pertinent data that is available to the modem device. Metrics based 423 on large enough sample sizes will preclude short traffic bursts from 424 adversely skewing reported values. 426 DLEP allows for metrics to be sent within two contexts - metrics for 427 a specific destination within the network (e.g., a specific router), 428 and per-session (those that apply to all destinations accessed via 429 the modem). Most metrics can be further subdivided into transmit and 430 receive metrics. In cases where metrics are provided at session 431 level, the router propagates the metrics to all entries in its 432 information base for destinations that are accessed via the modem. 434 DLEP modems announce all metric Data Items that will be reported 435 during the session, and provide default values for those metrics, in 436 the Session Initialization Response Message (Section 10.6). In order 437 to use a metric type that was not included in the Session 438 Initialization Response Message, modem implementations terminate the 439 session with the router (via the Session Terminate Message 440 (Section 10.9)), and establish a new session. 442 A DLEP modem can send metrics both in a session context, via the 443 Session Update Message (Section 10.7), and a specific destination 444 context, via the Destination Update Message (Section 10.17), at any 445 time. The most recently received metric value takes precedence over 446 any earlier value, regardless of context - that is: 448 1. If the router receives metrics in a specific destination context 449 (via the Destination Update Message), then the specific 450 destination is updated with the new metric. 452 2. If the router receives metrics in a session-wide context (via the 453 Session Update Message), then the metrics for all destinations 454 accessed via the modem are updated with the new metric. 456 It is left to implementations to choose sensible default values based 457 on their specific characteristics. Modems having static (non- 458 changing) link metric characteristics can report metrics only once 459 for a given destination (or once on a session-wide basis, if all 460 connections via the modem are of this static nature). 462 In addition to communicating existing metrics about the link, DLEP 463 provides a Message allowing a router to request a different datarate 464 or latency from the modem. This Message is the Link Characteristics 465 Request Message (Section 10.18), and gives the router the ability to 466 deal with requisite increases (or decreases) of allocated datarate/ 467 latency in demand-based schemes in a more deterministic manner. 469 5. DLEP Session Flow 471 All DLEP participants of a session transition through a number of 472 distinct states during the lifetime of a DLEP session: 474 o Peer Discovery 476 o Session Initialization 478 o In-Session 480 o Session Termination 482 o Session Reset 484 Modems, and routers supporting DLEP discovery, transition through all 485 five (5) of the above states. Routers that rely on preconfigured TCP 486 address/port information start in the Session Initialization state. 488 Modems MUST support the Peer Discovery state. 490 5.1. Peer Discovery State 492 In the Peer Discovery state, routers that support DLEP discovery MUST 493 send Peer Discovery Signals (Section 10.3) to initiate modem 494 discovery. 496 The router implementation then waits for a Peer Offer Signal 497 (Section 10.4) response from a potential DLEP modem. While in the 498 Peer Discovery state, Peer Discovery Signals MUST be sent repeatedly 499 by a DLEP router, at regular intervals. The interval MUST be a 500 minimum of one second; it SHOULD be a configurable parameter. Note 501 that this operation (sending Peer Discovery and waiting for Peer 502 Offer) is outside the DLEP Transaction Model (Section 6), as the 503 Transaction Model only describes Messages on a TCP session. 505 Routers MUST use one or more of each of the modem address/port 506 combinations from the Peer Offer Signal or, when no Connection Point 507 Data Items are present, from a priori configuration to establish a 508 new TCP connection to the modem. If more than one modem address/port 509 combinations is provided, router implementations MAY use their own 510 heuristics to determine the order in which they are tried. If a TCP 511 connection cannot be achieved using any of the address/port 512 combinations and the Discovery mechanism is in use, then the router 513 SHOULD resume issuing Peer Discovery Signals. If no Connection Point 514 Data Items are included in the Peer Offer Signal, the router MUST use 515 the source address of the UDP packet containing the Peer Offer Signal 516 as the IP address, and the DLEP well-known port number. 518 In the Peer Discovery state, the modem implementation MUST listen for 519 incoming Peer Discovery Signals on the DLEP well-known IPv6 and/or 520 IPv4 link-local multicast address and port. On receipt of a valid 521 Peer Discovery Signal, it MUST reply with a Peer Offer Signal. 523 Modems MUST be prepared to accept a TCP connection from a router that 524 is not using the Discovery mechanism, i.e. a connection attempt that 525 occurs without a preceding Peer Discovery Signal. 527 Upon establishment of a TCP connection, both modem and router enter 528 the Session Initialization state. It is up to the router 529 implementation if Peer Discovery Signals continue to be sent after 530 the device has transitioned to the Session Initialization state. 531 Modem implementations MUST silently ignore Peer Discovery Signals 532 from a router with which it already has a TCP connection. 534 5.2. Session Initialization State 536 On entering the Session Initialization state, the router MUST send a 537 Session Initialization Message (Section 10.5) to the modem. The 538 router MUST then wait for receipt of a Session Initialization 539 Response Message (Section 10.6) from the modem. Receipt of the 540 Session Initialization Response Message containing a Status Data Item 541 (Section 11.1) with status code set to 0 'Success', see Table 2, 542 indicates that the modem has received and processed the Session 543 Initialization Message, and the router MUST transition to the In- 544 Session state. 546 On entering the Session Initialization state, the modem MUST wait for 547 receipt of a Session Initialization Message from the router. Upon 548 receipt of a Session Initialization Message, the modem MUST send a 549 Session Initialization Response Message, and the session MUST 550 transition to the In-Session state. If the modem receives any 551 Message other than Session Initialization, or it fails to parse the 552 received Message, it MUST NOT send any Message, and MUST terminate 553 the TCP connection and transition to the Session Reset state. 555 DLEP provides an extension negotiation capability to be used in the 556 Session Initialization state, see Section 3. Extensions supported by 557 an implementation MUST be declared to potential DLEP participants 558 using the Extensions Supported Data Item (Section 11.6). Once both 559 DLEP participants have exchanged initialization Messages, an 560 implementation MUST NOT emit any Message, Signal, Data Item or status 561 code associated with an extension that was not specified in the 562 received initialization Message from its peer. 564 5.3. In-Session State 566 In the In-Session state, Messages can flow in both directions between 567 DLEP participants, indicating changes to the session state, the 568 arrival or departure of reachable destinations, or changes of the 569 state of the links to the destinations. 571 The In-Session state is maintained until one of the following 572 conditions occur: 574 o The implementation terminates the session by sending a Session 575 Termination Message (Section 10.9), or, 577 o Its peer terminates the session, indicated by receiving a Session 578 Termination Message. 580 The implementation MUST then transition to the Session Termination 581 state. 583 5.3.1. Heartbeats 585 In order to maintain the In-Session state, periodic Heartbeat 586 Messages (Section 10.20) MUST be exchanged between router and modem. 587 These Messages are intended to keep the session alive, and to verify 588 bidirectional connectivity between the two DLEP participants. 590 Each DLEP participant is responsible for the creation of Heartbeat 591 Messages. 593 Receipt of any valid DLEP Message MUST reset the heartbeat interval 594 timer (i.e., valid DLEP Messages take the place of, and obviate the 595 need for, additional Heartbeat Messages). 597 Implementations MUST allow a minimum of two (2) heartbeat intervals 598 to expire with no Messages from its peer before terminating the 599 session. When terminating the session, a Session Termination Message 600 containing a Status Data Item (Section 11.1) with status code set to 601 132 'Timed Out', see Table 2, MUST be sent, and then the 602 implementation MUST transition to the Session Termination state. 604 5.4. Session Termination State 606 When an implementation enters the Session Termination state after 607 sending a Session Termination Message (Section 10.9) as the result of 608 an invalid Message or error, it MUST wait for a Session Termination 609 Response Message (Section 10.10) from its peer. Senders SHOULD allow 610 four (4) heartbeat intervals to expire before assuming that its peer 611 is unresponsive, and continuing with session termination. Any other 612 Message received while waiting MUST be silently ignored. 614 When the sender of the Session Termination Message receives a Session 615 Termination Response Message from its peer, or times out, it MUST 616 transition to the Session Reset state. 618 When an implementation receives a Session Termination Message from 619 its peer, it enters the Session Termination state and then it MUST 620 immediately send a Session Termination Response and transition to the 621 Session Reset state. 623 5.5. Session Reset state 625 In the Session Reset state the implementation MUST perform the 626 following actions: 628 o Release all resources allocated for the session. 630 o Eliminate all destinations in the information base represented by 631 the session. Destination Down Messages (Section 10.15) MUST NOT 632 be sent. 634 o Terminate the TCP connection. 636 Having completed these actions the implementation SHOULD return to 637 the relevant initial state: Peer Discovery for modems; either Peer 638 Discovery or Session Initialization for routers, depending on 639 configuration. 641 5.5.1. Unexpected TCP connection termination 643 If the TCP connection between DLEP participants is terminated when an 644 implementation is not in the Session Reset state, the implementation 645 MUST immediately transition to the Session Reset state. 647 6. Transaction Model 649 DLEP defines a simple Message transaction model: Only one request per 650 destination may be in progress at a time per session. A Message 651 transaction is considered complete when a response matching a 652 previously issued request is received. If a DLEP participant 653 receives a request for a destination for which there is already an 654 outstanding request, the implementation MUST terminate the session by 655 issuing a Session Termination Message (Section 10.9) containing a 656 Status Data Item (Section 11.1) with status code set to 129 657 'Unexpected Message', see Table 2, and transition to the Session 658 Termination state. There is no restriction to the total number of 659 Message transactions in progress at a time, as long as each 660 transaction refers to a different destination. 662 It should be noted that some requests may take a considerable amount 663 of time for some DLEP participants to complete, for example a modem 664 handling a multicast destination up request may have to perform a 665 complex network reconfiguration. A sending implementation MUST be 666 able to handle such long running transactions gracefully. 668 Additionally, only one session request, e.g. a Session Initialization 669 Message (Section 10.5), may be in progress at a time per session. As 670 above, a session transaction is considered complete when a response 671 matching a previously issued request is received. If a DLEP 672 participant receives a session request while there is already a 673 session request in progress, it MUST terminate the session by issuing 674 a Session Termination Message containing a Status Data Item with 675 status code set to 129 'Unexpected Message', and transition to the 676 Session Termination state. Only the Session Termination Message may 677 be issued when a session transaction is in progress. Heartbeat 678 Messages (Section 10.20) MUST NOT be considered part of a session 679 transaction. 681 DLEP transactions do not time out and are not cancellable. An 682 implementation can detect if its peer has failed in some way by use 683 of the session heartbeat mechanism during the In-Session state, see 684 Section 5.3. 686 7. Extensions 688 Extensions MUST be negotiated on a per-session basis during session 689 initialization via the Extensions Supported mechanism. 690 Implementations are not required to support any extension in order to 691 be considered DLEP compliant. An extension document, describing the 692 operation of a credit windowing scheme for flow control, is described 693 in [CREDIT]. 695 If interoperable protocol extensions are required, they will need to 696 be standardized either as an update to this document, or as an 697 additional stand-alone specification. The requests for IANA- 698 controlled registries in this document contain sufficient Reserved 699 space for DLEP Signals, Messages, Data Items and status codes to 700 accommodate future extensions to the protocol. 702 As multiple protocol extensions MAY be announced during session 703 initialization, authors of protocol extensions need to consider the 704 interaction of their extension with other published extensions, and 705 specify any incompatibilities. 707 7.1. Experiments 709 This document requests Private Use numbering space in the DLEP 710 Signal, Message, Data Item and status code registries for 711 experimental extensions. The intent is to allow for experimentation 712 with new Signals, Messages, Data Items, and/or status codes, while 713 still retaining the documented DLEP behavior. 715 Use of the Private Use Signals, Messages, Data Items, status codes, 716 or behaviors MUST be announced as DLEP Extensions, during session 717 initialization, using extension identifiers from the Private Use 718 space in the Extensions Supported registry (Table 3), with a value 719 agreed upon (a priori) between the participants. DLEP extensions 720 using the Private Use numbering space are commonly referred to as 721 Experiments. 723 Multiple experiments MAY be announced in the Session Initialization 724 Messages. However, use of multiple experiments in a single session 725 could lead to interoperability issues or unexpected results (e.g., 726 clashes of experimental Signals, Messages, Data Items and/or status 727 code types), and is therefore discouraged. It is left to 728 implementations to determine the correct processing path (e.g., a 729 decision on whether to terminate the session, or to establish a 730 precedence of the conflicting definitions) if such conflicts arise. 732 8. Scalability 734 The protocol is intended to support thousands of destinations on a 735 given modem/router pair. At large scale, implementations SHOULD 736 consider employing techniques to prevent flooding its peer with a 737 large number of Messages in a short time. For example, a dampening 738 algorithm could be employed to prevent a flapping device from 739 generating a large number of Destination Up/Destination Down 740 Messages. 742 Also, use of techniques such as a hysteresis can lessen the impact of 743 rapid, minor fluctuations in link quality. The specific algorithms 744 for handling flapping destinations and minor changes in link quality 745 are outside the scope of this specification. 747 9. DLEP Signal and Message Structure 749 DLEP defines two protocol units used in two different ways: Signals 750 and Messages. Signals are only used in the Discovery mechanism and 751 are carried in UDP datagrams. Messages are used bi-directionally 752 over a TCP connection between the participants, in the Session 753 Initialization, In-Session and Session Termination states. 755 Both Signals and Messages consist of a Header followed by an 756 unordered list of Data Items. Headers consist of Type and Length 757 information, while Data Items are encoded as TLV (Type-Length-Value) 758 structures. In this document, the Data Items following a Signal or 759 Message Header are described as being 'contained in' the Signal or 760 Message. 762 There is no restriction on the order of Data Items following a 763 Header, and the acceptability of duplicate Data Items is defined by 764 the definition of the Signal or Message declared by the type in the 765 Header. 767 All integers in Header fields and values MUST be in network byte- 768 order. 770 9.1. DLEP Signal Header 772 The DLEP Signal Header contains the following fields: 774 0 1 2 3 775 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 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | 'D' | 'L' | 'E' | 'P' | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Signal Type | Length | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 Figure 3: DLEP Signal Header 784 "DLEP": Every Signal MUST start with the characters: U+0044, U+004C, 785 U+0045, U+0050. 787 Signal Type: A 16-bit unsigned integer containing one of the DLEP 788 Signal Type values defined in this document. 790 Length: The length in octets, expressed as a 16-bit unsigned 791 integer, of all of the DLEP Data Items contained in this Signal. 792 This length MUST NOT include the length of the Signal Header 793 itself. 795 The DLEP Signal Header is immediately followed by zero or more DLEP 796 Data Items, encoded in TLVs, as defined in this document. 798 9.2. DLEP Message Header 800 The DLEP Message Header contains the following fields: 802 0 1 2 3 803 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 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | Message Type | Length | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 Figure 4: DLEP Message Header 810 Message Type: A 16-bit unsigned integer containing one of the DLEP 811 Message Type values defined in this document. 813 Length: The length in octets, expressed as a 16-bit unsigned 814 integer, of all of the DLEP Data Items contained in this Message. 815 This length MUST NOT include the length of the Message Header 816 itself. 818 The DLEP Message Header is immediately followed by zero or more DLEP 819 Data Items, encoded in TLVs, as defined in this document. 821 9.3. DLEP Generic Data Item 823 All DLEP Data Items contain the following fields: 825 0 1 2 3 826 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 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | Data Item Type | Length | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | Value... : 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 Figure 5: DLEP Generic Data Item 835 Data Item Type: A 16-bit unsigned integer field specifying the type 836 of Data Item being sent. 838 Length: The length in octets, expressed as a 16-bit unsigned 839 integer, of the Value field of the Data Item. This length MUST 840 NOT include the length of the Data Item Type and Length fields. 842 Value: A field of octets, which contains data specific to a 843 particular Data Item. 845 10. DLEP Signals and Messages 847 10.1. General Processing Rules 849 If an unrecognized, or unexpected Signal is received, or a received 850 Signal contains unrecognized, invalid, or disallowed duplicate Data 851 Items, the receiving implementation MUST ignore the Signal. 853 If a Signal is received with a TTL value that is NOT equal to 1, the 854 receiving implementation MUST ignore the Signal. 856 If an unrecognized Message is received, the receiving implementation 857 MUST issue a Session Termination Message (Section 10.9) containing a 858 Status Data Item (Section 11.1) with status code set to 128 'Unknown 859 Message', see Table 2, and transition to the Session Termination 860 state. 862 If an unexpected Message is received, the receiving implementation 863 MUST issue a Session Termination Message containing a Status Data 864 Item with status code set to 129 'Unexpected Message', and transition 865 to the Session Termination state. 867 If a received Message contains unrecognized, invalid, or disallowed 868 duplicate Data Items, the receiving implementation MUST issue a 869 Session Termination Message containing a Status Data Item with status 870 code set to 130 'Invalid Data', and transition to the Session 871 Termination state. 873 If a packet in the TCP stream is received with a TTL value other than 874 255, the receiving implementation MUST immediately transition to the 875 Session Reset state. 877 Prior to the exchange of Destination Up (Section 10.11) and 878 Destination Up Response (Section 10.12) Messages, or Destination 879 Announce (Section 10.13) and Destination Announce Response 880 (Section 10.14) Messages, no Messages concerning a destination may be 881 sent. An implementation receiving any Message with such an 882 unannounced destination MUST terminate the session by issuing a 883 Session Termination Message containing a Status Data Item with status 884 code set to 131 'Invalid Destination', and transition to the Session 885 Termination state. 887 After exchanging Destination Down (Section 10.15) and Destination 888 Down Response (Section 10.16) Messages, no Messages concerning a 889 destination may be a sent until a new Destination Up or Destination 890 Announce Message is sent. An implementation receiving a Message 891 about a destination previously announced as 'down' MUST terminate the 892 session by issuing a Session Termination Message with a Status Data 893 Item with status code set to 131 'Invalid Destination', and 894 transition to the Session Termination state. 896 10.2. Status code processing 898 The behaviour of a DLEP participant receiving a Message containing a 899 Status Data Item (Section 11.1) is defined by the failure mode 900 associated with the value of the status code field, see Table 2. All 901 status code values less than 100 have a failure mode of 'Continue', 902 all other status codes have a failure mode of 'Terminate'. 904 A DLEP participant receiving any Message apart from Session 905 Termination Message (Section 10.9) containing a Status Data Item with 906 a status code value with failure mode 'Terminate' MUST immediately 907 issue a Session Termination Message containing an identical Status 908 Data Item, and then transition to the Session Termination state. 910 A DLEP participant receiving a Message containing a Status Data Item 911 with a status code value with failure mode 'Continue' can continue 912 normal operation of the session. 914 10.3. Peer Discovery Signal 916 A Peer Discovery Signal SHOULD be sent by a DLEP router to discover 917 DLEP modems in the network, see Section 5.1. 919 A Peer Discovery Signal MUST be encoded within a UDP packet. The 920 destination MUST be set to the DLEP well-known address and port 921 number. For routers supporting both IPv4 and IPv6 DLEP operation, it 922 is RECOMMENDED that IPv6 be selected as the transport. The source IP 923 address MUST be set to the router IP address associated with the DLEP 924 interface. There is no DLEP-specific restriction on source port. 926 To construct a Peer Discovery Signal, the Signal Type value in the 927 Signal Header is set to 1 (see Signal Type Registration 928 (Section 13.2)). 930 The Peer Discovery Signal MAY contain a Peer Type Data Item 931 (Section 11.4). 933 10.4. Peer Offer Signal 935 A Peer Offer Signal MUST be sent by a DLEP modem in response to a 936 properly formatted and addressed Peer Discovery Signal 937 (Section 10.3). 939 A Peer Offer Signal MUST be encoded within a UDP packet. The IP 940 destination MUST be set to the IP address and port number received in 941 the corresponding Peer Discovery Signal. The source IP address MUST 942 be set to the modem's IP address associated with the DLEP interface. 943 The source port number MUST be set to the DLEP well-known port 944 number. The Peer Offer Signal completes the discovery process, see 945 Section 5.1. 947 To construct a Peer Offer Signal, the Signal Type value in the Signal 948 Header is set to 2 (see Signal Type Registration (Section 13.2)). 950 The Peer Offer Signal MAY contain a Peer Type Data Item 951 (Section 11.4). 953 The Peer Offer Signal MAY contain one or more of any of the following 954 Data Items, with different values: 956 o IPv4 Connection Point (Section 11.2) 958 o IPv6 Connection Point (Section 11.3) 960 The IP Connection Point Data Items indicate the unicast address the 961 router MUST use when connecting the DLEP TCP session. 963 10.5. Session Initialization Message 965 A Session Initialization Message MUST be sent by a DLEP router as the 966 first Message of the DLEP TCP session. It is sent by the router 967 after a TCP connect to an address/port combination that was obtained 968 either via receipt of a Peer Offer, or from a priori configuration. 970 To construct a Session Initialization Message, the Message Type value 971 in the Message Header is set to 1 (see Message Type Registration 972 (Section 13.3)). 974 The Session Initialization Message MUST contain a Heartbeat Interval 975 Data Item (Section 11.5). 977 The Session Initialization Message MAY contain one of each of the 978 following Data Items: 980 o Peer Type (Section 11.4) 981 o Extensions Supported (Section 11.6) 983 If any optional extensions are supported by the implementation, they 984 MUST be enumerated in the Extensions Supported Data Item. If an 985 Extensions Supported Data Item does not exist in a Session 986 Initialization Message, the modem MUST conclude that there is no 987 support for extensions in the router. 989 DLEP Heartbeats are not fully established until receipt of the 990 Session Initialization Response Message (Section 10.6), and therefore 991 implementations MUST use their own timeout and retry heuristics for 992 this Message. 994 As an exception to the general rule governing an implementation 995 receiving an unrecognized Data Item in a Message, see Section 10.1, 996 if a Session Initialization Message contains one or more Extension 997 Supported Data Items announcing support for extensions that the 998 implementation does not recognize, then the implementation MAY ignore 999 Data Items it does not recognize. 1001 10.6. Session Initialization Response Message 1003 A Session Initialization Response Message MUST be sent in response to 1004 a received Session Initialization Message (Section 10.5). 1006 To construct a Session Initialization Response Message, the Message 1007 Type value in the Message Header is set to 2 (see Message Type 1008 Registration (Section 13.3)). 1010 The Session Initialization Response Message MUST contain one of each 1011 of the following Data Items: 1013 o Status (Section 11.1) 1015 o Heartbeat Interval (Section 11.5) 1017 o Maximum Data Rate (Receive) (Section 11.12) 1019 o Maximum Data Rate (Transmit) (Section 11.13) 1021 o Current Data Rate (Receive) (Section 11.14) 1023 o Current Data Rate (Transmit) (Section 11.15) 1025 o Latency (Section 11.16) 1026 The Session Initialization Response Message MUST contain one of each 1027 of the following Data Items, if the Data Item will be used during the 1028 lifetime of the session: 1030 o Resources (Section 11.17) 1032 o Relative Link Quality (Receive) (Section 11.18) 1034 o Relative Link Quality (Transmit) (Section 11.19) 1036 o Maximum Transmission Unit (MTU) (Section 11.20) 1038 The Session Initialization Response Message MAY contain one of each 1039 of the following Data Items: 1041 o Peer Type (Section 11.4) 1043 o Extensions Supported (Section 11.6) 1045 The Session Initialization Response Message completes the DLEP 1046 session establishment; the modem should transition to the In-Session 1047 state when the Message is sent, and the router should transition to 1048 the In-Session state upon receipt of an acceptable Session 1049 Initialization Response Message. 1051 All supported metric Data Items MUST be included in the Session 1052 Initialization Response Message, with default values to be used on a 1053 session-wide basis. This can be viewed as the modem 'declaring' all 1054 supported metrics at DLEP session initialization. Receipt of any 1055 further DLEP Message containing a metric Data Item not included in 1056 the Session Initialization Response Message MUST be treated as an 1057 error, resulting in the termination of the DLEP session between 1058 router and modem. 1060 If any optional extensions are supported by the modem, they MUST be 1061 enumerated in the Extensions Supported Data Item. If an Extensions 1062 Supported Data Item does not exist in a Session Initialization 1063 Response Message, the router MUST conclude that there is no support 1064 for extensions in the modem. 1066 After the Session Initialization/Session Initialization Response 1067 Messages have been successfully exchanged, implementations MUST only 1068 use extensions that are supported by both DLEP participants, see 1069 Section 5.2. 1071 10.7. Session Update Message 1073 A Session Update Message MAY be sent by a DLEP participant to 1074 indicate local Layer 3 address changes, or metric changes on a 1075 session-wide basis. 1077 To construct a Session Update Message, the Message Type value in the 1078 Message Header is set to 3 (see Message Type Registration 1079 (Section 13.3)). 1081 The Session Update Message MAY contain one of each of the following 1082 Data Items: 1084 o Maximum Data Rate (Receive) (Section 11.12) 1086 o Maximum Data Rate (Transmit) (Section 11.13) 1088 o Current Data Rate (Receive) (Section 11.14) 1090 o Current Data Rate (Transmit) (Section 11.15) 1092 o Latency (Section 11.16) 1094 The Session Update Message MAY contain one of each of the following 1095 Data Items, if the Data Item is in use by the session: 1097 o Resources (Section 11.17) 1099 o Relative Link Quality (Receive) (Section 11.18) 1101 o Relative Link Quality (Transmit) (Section 11.19) 1103 o Maximum Transmission Unit (MTU) (Section 11.20) 1105 The Session Update Message MAY contain one or more of each of the 1106 following Data Items, with different values: 1108 o IPv4 Address (Section 11.8) 1110 o IPv6 Address (Section 11.9) 1112 If metrics are supplied with the Session Update Message (e.g., 1113 Maximum Data Rate), these metrics are considered to be session-wide, 1114 and therefore MUST be applied to all destinations in the information 1115 base associated with the DLEP session. This includes destinations 1116 for which metrics may have been stored based on received Destination 1117 Update messages. 1119 It should be noted that Session Update Messages can be sent by both 1120 routers and modems. For example, addition of an IPv4 address to the 1121 router MAY prompt a Session Update Message to its attached modems. 1122 Also, for example, a modem that changes its Maximum Data Rate 1123 (Receive) for all destinations MAY reflect that change via a Session 1124 Update Message to its attached router(s). 1126 Concerning Layer 3 addresses: If the modem is capable of 1127 understanding and forwarding this information (via proprietary 1128 mechanisms), the address update would prompt any remote DLEP modems 1129 (DLEP-enabled modems in a remote node) to issue a Destination Update 1130 Message (Section 10.17) to their local routers with the new (or 1131 deleted) addresses. Modems that do not track Layer 3 addresses 1132 SHOULD silently ignore Address Data Items. 1134 10.8. Session Update Response Message 1136 A Session Update Response Message MUST be sent by a DLEP participant 1137 when a Session Update Message (Section 10.7) is received. 1139 To construct a Session Update Response Message, the Message Type 1140 value in the Message Header is set to 4 (see Message Type 1141 Registration (Section 13.3)). 1143 The Session Update Response Message MUST contain a Status Data Item 1144 (Section 11.1). 1146 10.9. Session Termination Message 1148 A Session Termination Message MUST be sent by a DLEP participant when 1149 the DLEP session needs to be terminated. 1151 To construct a Session Termination Message, the Message Type value in 1152 the Message Header is set to 5 (see Message Type Registration 1153 (Section 13.3)). 1155 The Session Termination Message MUST contain Status Data Item 1156 (Section 11.1). 1158 It should be noted that Session Termination Messages can be sent by 1159 both routers and modems. 1161 10.10. Session Termination Response Message 1163 A Session Termination Response Message MUST be sent by a DLEP 1164 participant when a Session Termination Message (Section 10.9) is 1165 received. 1167 To construct a Session Termination Response Message, the Message Type 1168 value in the Message Header is set to 6 (see Message Type 1169 Registration (Section 13.3)). 1171 There are no valid Data Items for the Session Termination Response 1172 Message. 1174 Receipt of a Session Termination Response Message completes the tear- 1175 down of the DLEP session, see Section 5.4. 1177 10.11. Destination Up Message 1179 Destination Up Messages MAY be sent by a modem to inform its attached 1180 router of the presence of a new reachable destination. 1182 To construct a Destination Up Message, the Message Type value in the 1183 Message Header is set to 7 (see Message Type Registration 1184 (Section 13.3)). 1186 The Destination Up Message MUST contain a MAC Address Data Item 1187 (Section 11.7). 1189 The Destination Up Message SHOULD contain one or more of each of the 1190 following Data Items, with different values: 1192 o IPv4 Address (Section 11.8) 1194 o IPv6 Address (Section 11.9) 1196 The Destination Up Message MAY contain one of each of the following 1197 Data Items: 1199 o Maximum Data Rate (Receive) (Section 11.12) 1201 o Maximum Data Rate (Transmit) (Section 11.13) 1203 o Current Data Rate (Receive) (Section 11.14) 1205 o Current Data Rate (Transmit) (Section 11.15) 1207 o Latency (Section 11.16) 1209 The Destination Up Message MAY contain one of each of the following 1210 Data Items, if the Data Item is in use by the session: 1212 o Resources (Section 11.17) 1214 o Relative Link Quality (Receive) (Section 11.18) 1215 o Relative Link Quality (Transmit) (Section 11.19) 1217 o Maximum Transmission Unit (MTU) (Section 11.20) 1219 The Destination Up Message MAY contain one or more of each of the 1220 following Data Items, with different values: 1222 o IPv4 Attached Subnet (Section 11.10) 1224 o IPv6 Attached Subnet (Section 11.11) 1226 A router receiving a Destination Up Message allocates the necessary 1227 resources, creating an entry in the information base with the 1228 specifics (MAC Address, Latency, Data Rate, etc.) of the destination. 1229 The information about this destination will persist in the router's 1230 information base until a Destination Down Message (Section 10.15) is 1231 received, indicating that the modem has lost contact with the remote 1232 node, or the implementation transitions to the Session Termination 1233 state. 1235 10.12. Destination Up Response Message 1237 A router MUST send a Destination Up Response Message when a 1238 Destination Up Message (Section 10.11) is received. 1240 To construct a Destination Up Response Message, the Message Type 1241 value in the Message Header is set to 8 (see Message Type 1242 Registration (Section 13.3)). 1244 The Destination Up Response Message MUST contain one of each of the 1245 following Data Items: 1247 o MAC Address (Section 11.7) 1249 o Status (Section 11.1) 1251 A router that wishes to receive further information concerning the 1252 destination identified in the corresponding Destination Up Message 1253 MUST set the status code of the included Status Data Item to 0 1254 'Success', see Table 2. 1256 If the router has no interest in the destination identified in the 1257 corresponding Destination Up Message, then it MAY set the status code 1258 of the included Status Data Item to 1 'Not Interested'. 1260 A modem receiving a Destination Up Response Message containing a 1261 Status Data Item with status code of any value other than 0 'Success' 1262 MUST NOT send further Destination messages about the destination, 1263 e.g. Destination Down (Section 10.15) or Destination Update 1264 (Section 10.17) with the same MAC address. 1266 10.13. Destination Announce Message 1268 Usually a modem will discover the presence of one or more remote 1269 router/modem pairs and announce each destination's arrival by sending 1270 a corresponding Destination Up Message (Section 10.11) to the router. 1271 However, there may be times when a router wishes to express an 1272 interest in a destination that has yet to be announced, typically a 1273 multicast destination. Destination Announce Messages MAY be sent by 1274 a router to announce such an interest. 1276 A Destination Announce Message MAY also be sent by a router to 1277 request information concerning a destination in which it has 1278 previously declined interest, via the 1 'Not Interested' status code 1279 in a Destination Up Response Message (Section 10.12), see Table 2, or 1280 declared as 'down', via the Destination Down Message (Section 10.15). 1282 To construct a Destination Announce Message, the Message Type value 1283 in the Message Header is set to 9 (see Message Type Registration 1284 (Section 13.3)). 1286 The Destination Announce Message MUST contain a MAC Address Data Item 1287 (Section 11.7). 1289 The Destination Announce Message MAY contain zero or more of the 1290 following Data Items, with different values: 1292 o IPv4 Address (Section 11.8) 1294 o IPv6 Address (Section 11.9) 1296 One of the advantages of implementing DLEP is to leverage the modem's 1297 knowledge of the links between remote destinations allowing routers 1298 to avoid using probed neighbor discovery techniques, therefore modem 1299 implementations SHOULD announce available destinations via the 1300 Destination Up Message, rather than relying on Destination Announce 1301 Messages. 1303 10.14. Destination Announce Response Message 1305 A modem MUST send a Destination Announce Response Message when a 1306 Destination Announce Message (Section 10.13) is received. 1308 To construct a Destination Announce Response Message, the Message 1309 Type value in the Message Header is set to 10 (see Message Type 1310 Registration (Section 13.3)). 1312 The Destination Announce Response Message MUST contain one of each of 1313 the following Data Items: 1315 o MAC Address (Section 11.7) 1317 o Status (Section 11.1) 1319 The Destination Announce Response Message MAY contain one or more of 1320 each of the following Data Items, with different values: 1322 o IPv4 Address (Section 11.8) 1324 o IPv6 Address (Section 11.9) 1326 o IPv4 Attached Subnet (Section 11.10) 1328 o IPv6 Attached Subnet (Section 11.11) 1330 The Destination Announce Response Message MAY contain one of each of 1331 the following Data Items: 1333 o Maximum Data Rate (Receive) (Section 11.12) 1335 o Maximum Data Rate (Transmit) (Section 11.13) 1337 o Current Data Rate (Receive) (Section 11.14) 1339 o Current Data Rate (Transmit) (Section 11.15) 1341 o Latency (Section 11.16) 1343 The Destination Announce Response Message MAY contain one of each of 1344 the following Data Items, if the Data Item is in use by the session: 1346 o Resources (Section 11.17) 1348 o Relative Link Quality (Receive) (Section 11.18) 1350 o Relative Link Quality (Transmit) (Section 11.19) 1352 o Maximum Transmission Unit (MTU) (Section 11.20) 1354 If a modem is unable to report information immediately about the 1355 requested information, if the destination is not currently reachable, 1356 for example, the status code in the Status Data Item MUST be set to 2 1357 'Request Denied', see Table 2. 1359 After sending a Destination Announce Response Message containing a 1360 Status Data Item with status code of 0 'Success', a modem then 1361 announces changes to the link to the destination via Destination 1362 Update Messages. 1364 When a successful Destination Announce Response Message is received, 1365 the router should add knowledge of the available destination to its 1366 information base. 1368 10.15. Destination Down Message 1370 A modem MUST send a Destination Down Message to report when a 1371 destination (a remote node or a multicast group) is no longer 1372 reachable. 1374 A router MAY send a Destination Down Message to report when it no 1375 longer requires information concerning a destination. 1377 To construct a Destination Down Message, the Message Type value in 1378 the Message Header is set to 11 (see Message Type Registration 1379 (Section 13.3)). 1381 The Destination Down Message MUST contain a MAC Address Data Item 1382 (Section 11.7). 1384 It should be noted that both modem and router may send a Destination 1385 Down Message to their peer, regardless of which participant initially 1386 indicated the destination to be 'up'. 1388 10.16. Destination Down Response Message 1390 A Destination Down Response MUST be sent by the recipient of a 1391 Destination Down Message (Section 10.15) to confirm that the relevant 1392 data concerning the destination has been removed from the information 1393 base. 1395 To construct a Destination Down Response Message, the Message Type 1396 value in the Message Header is set to 12 (see Message Type 1397 Registration (Section 13.3)). 1399 The Destination Down Response Message MUST contain one of each of the 1400 following Data Items: 1402 o MAC Address (Section 11.7) 1404 o Status (Section 11.1) 1406 10.17. Destination Update Message 1408 A modem SHOULD send the Destination Update Message when it detects 1409 some change in the information base for a given destination (remote 1410 node or multicast group). Some examples of changes that would prompt 1411 a Destination Update Message are: 1413 o Change in link metrics (e.g., Data Rates) 1415 o Layer 3 addressing change 1417 To construct a Destination Update Message, the Message Type value in 1418 the Message Header is set to 13 (see Message Type Registration 1419 (Section 13.3)). 1421 The Destination Update Message MUST contain a MAC Address Data Item 1422 (Section 11.7). 1424 The Destination Update Message MAY contain one of each of the 1425 following Data Items: 1427 o Maximum Data Rate (Receive) (Section 11.12) 1429 o Maximum Data Rate (Transmit) (Section 11.13) 1431 o Current Data Rate (Receive) (Section 11.14) 1433 o Current Data Rate (Transmit) (Section 11.15) 1435 o Latency (Section 11.16) 1437 The Destination Update Message MAY contain one of each of the 1438 following Data Items, if the Data Item is in use by the session: 1440 o Resources (Section 11.17) 1442 o Relative Link Quality (Receive) (Section 11.18) 1444 o Relative Link Quality (Transmit) (Section 11.19) 1446 o Maximum Transmission Unit (MTU) (Section 11.20) 1448 The Destination Update Message MAY contain one or more of each of the 1449 following Data Items, with different values: 1451 o IPv4 Address (Section 11.8) 1453 o IPv6 Address (Section 11.9) 1454 o IPv4 Attached Subnet (Section 11.10) 1456 o IPv6 Attached Subnet (Section 11.11) 1458 If metrics are supplied with the Message (e.g., Resources), these 1459 metrics are MUST be applied to all destinations identified in the 1460 Message. Note that this may overwrite metrics provided in a 1461 previously received Session or Destination Up Messages. 1463 It should be noted that this Message has no corresponding response. 1465 10.18. Link Characteristics Request Message 1467 The Link Characteristics Request Message MAY be sent by a router to 1468 request that the modem initiate changes for specific characteristics 1469 of the link. The request can reference either a real destination 1470 (e.g., a remote node), or a logical destination (e.g., a multicast 1471 group) within the network. 1473 To construct a Link Characteristics Request Message, the Message Type 1474 value in the Message Header is set to 14 (see Message Type 1475 Registration (Section 13.3)). 1477 The Link Characteristics Request Message MUST contain one of the 1478 following Data Items: 1480 o MAC Address (Section 11.7) 1482 The Link Characteristics Request Message MUST contain at least one of 1483 each of the following Data Items: 1485 o Current Data Rate (Receive) (Section 11.14) 1487 o Current Data Rate (Transmit) (Section 11.15) 1489 o Latency (Section 11.16) 1491 The Link Characteristics Request Message MAY contain either a Current 1492 Data Rate (CDRR or CDRT) Data Item to request a different datarate 1493 than is currently allocated, a Latency Data Item to request that 1494 traffic delay on the link not exceed the specified value, or both. 1496 The router sending a Link Characteristics Request Message should be 1497 aware that a request may take an extended period of time to complete. 1499 10.19. Link Characteristics Response Message 1501 A modem MUST send a Link Characteristics Response Message when a Link 1502 Characteristics Request Message (Section 10.18) is received. 1504 To construct a Link Characteristics Response Message, the Message 1505 Type value in the Message Header is set to 15 (see Message Type 1506 Registration (Section 13.3)). 1508 The Link Characteristics Response Message MUST contain one of each of 1509 the following Data Items: 1511 o MAC Address (Section 11.7) 1513 o Status (Section 11.1) 1515 The Link Characteristics Response Message SHOULD contain one of each 1516 of the following Data Items: 1518 o Maximum Data Rate (Receive) (Section 11.12) 1520 o Maximum Data Rate (Transmit) (Section 11.13) 1522 o Current Data Rate (Receive) (Section 11.14) 1524 o Current Data Rate (Transmit) (Section 11.15) 1526 o Latency (Section 11.16) 1528 The Link Characteristics Response Message MAY contain one of each of 1529 the following Data Items, if the Data Item is in use by the session: 1531 o Resources (Section 11.17) 1533 o Relative Link Quality (Receive) (Section 11.18) 1535 o Relative Link Quality (Transmit) (Section 11.19) 1537 o Maximum Transmission Unit (MTU) (Section 11.20) 1539 The Link Characteristics Response Message MUST contain a complete set 1540 of metric Data Items, referencing all metrics declared in the Session 1541 Initialization Response Message (Section 10.6). The values in the 1542 metric Data Items in the Link Characteristics Response Message MUST 1543 reflect the link characteristics after the request has been 1544 processed. 1546 If an implementation is not able to alter the characteristics of the 1547 link in the manner requested, then the status code of the Status Data 1548 Item MUST be set to 2 'Request Denied', see Table 2. 1550 10.20. Heartbeat Message 1552 A Heartbeat Message MUST be sent by a DLEP participant every N 1553 milliseconds, where N is defined in the Heartbeat Interval Data Item 1554 (Section 11.5) of the Session Initialization Message (Section 10.5) 1555 or Session Initialization Response Message (Section 10.6). 1557 To construct a Heartbeat Message, the Message Type value in the 1558 Message Header is set to 16 (see Message Type Registration 1559 (Section 13.3)). 1561 There are no valid Data Items for the Heartbeat Message. 1563 The Message is used by DLEP participants to detect when a DLEP 1564 session peer (either the modem or the router) is no longer 1565 communicating, see Section 5.3.1. 1567 11. DLEP Data Items 1569 Following is the list of core Data Items that MUST be recognized by a 1570 DLEP compliant implementation. As mentioned before, not all Data 1571 Items need be used during a session, but an implementation MUST 1572 correctly process these Data Items when correctly associated with a 1573 Signal or Message. 1575 The core DLEP Data Items are: 1577 +-------------+-----------------------------------------------------+ 1578 | Type Code | Description | 1579 +-------------+-----------------------------------------------------+ 1580 | 0 | Reserved | 1581 | 1 | Status (Section 11.1) | 1582 | 2 | IPv4 Connection Point (Section 11.2) | 1583 | 3 | IPv6 Connection Point (Section 11.3) | 1584 | 4 | Peer Type (Section 11.4) | 1585 | 5 | Heartbeat Interval (Section 11.5) | 1586 | 6 | Extensions Supported (Section 11.6) | 1587 | 7 | MAC Address (Section 11.7) | 1588 | 8 | IPv4 Address (Section 11.8) | 1589 | 9 | IPv6 Address (Section 11.9) | 1590 | 10 | IPv4 Attached Subnet (Section 11.10) | 1591 | 11 | IPv6 Attached Subnet (Section 11.11) | 1592 | 12 | Maximum Data Rate (Receive) (MDRR) (Section 11.12) | 1593 | 13 | Maximum Data Rate (Transmit) (MDRT) (Section 11.13) | 1594 | 14 | Current Data Rate (Receive) (CDRR) (Section 11.14) | 1595 | 15 | Current Data Rate (Transmit) (CDRT) (Section 11.15) | 1596 | 16 | Latency (Section 11.16) | 1597 | 17 | Resources (RES) (Section 11.17) | 1598 | 18 | Relative Link Quality (Receive) (RLQR) (Section | 1599 | | 11.18) | 1600 | 19 | Relative Link Quality (Transmit) (RLQT) (Section | 1601 | | 11.19) | 1602 | 20 | Maximum Transmission Unit (MTU) (Section 11.20) | 1603 | 21-65407 | Reserved for future extensions | 1604 | 65408-65534 | Private Use. Available for experiments | 1605 | 65535 | Reserved | 1606 +-------------+-----------------------------------------------------+ 1608 Table 1: DLEP Data Item types 1610 11.1. Status 1612 For the Session Termination Message (Section 10.9), the Status Data 1613 Item indicates a reason for the termination. For all response 1614 Messages, the Status Data Item is used to indicate the success or 1615 failure of the previously received Message. 1617 The Status Data Item includes an optional Text field that can be used 1618 to provide a textual description of the status. The use of the Text 1619 field is entirely up to the receiving implementation, e.g., it could 1620 be output to a log file or discarded. If no Text field is supplied 1621 with the Status Data Item, the Length field MUST be set to 1. 1623 The Status Data Item contains the following fields: 1625 0 1 2 3 1626 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 1627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1628 | Data Item Type | Length | 1629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1630 | Code | Text... : 1631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1633 Data Item Type: 1 1635 Length: 1 + Length of text, in octets 1637 Status Code: One of the codes defined in Table 2 below. 1639 Text: UTF-8 encoded string of UNICODE [UNIV8] characters, describing 1640 the cause, used for implementation defined purposes. Since this 1641 field is used for description, implementations SHOULD limit 1642 characters in this field to printable characters. Implementations 1643 receiving this Data Item SHOULD check for printable characters in 1644 the field. 1646 An implementation MUST NOT assume the Text field is NUL-terminated. 1648 +----------+-------------+------------------+-----------------------+ 1649 | Status | Failure | Description | Reason | 1650 | Code | Mode | | | 1651 +----------+-------------+------------------+-----------------------+ 1652 | 0 | Continue | Success | The Message was | 1653 | | | | processed | 1654 | | | | successfully. | 1655 | 1 | Continue | Not Interested | The receiver is not | 1656 | | | | interested in this | 1657 | | | | Message subject, e.g. | 1658 | | | | in a Destination Up | 1659 | | | | Response Message | 1660 | | | | (Section 10.12) to | 1661 | | | | indicate no further | 1662 | | | | Messages about the | 1663 | | | | destination. | 1664 | 2 | Continue | Request Denied | The receiver refuses | 1665 | | | | to complete the | 1666 | | | | request. | 1667 | 3-111 | Continue | | Reserved for future | 1668 | | | | extensions. | 1669 | 112-127 | Continue | | Available for | 1670 | | | | experiments. | 1671 | 128 | Terminate | Unknown Message | The Message was not | 1672 | | | | recognized by the | 1673 | | | | implementation. | 1674 | 129 | Terminate | Unexpected | The Message was not | 1675 | | | Message | expected while the | 1676 | | | | device was in the | 1677 | | | | current state, e.g., | 1678 | | | | a Session | 1679 | | | | Initialization | 1680 | | | | Message (Section | 1681 | | | | 10.5) in the In- | 1682 | | | | Session state. | 1683 | 130 | Terminate | Invalid Data | One or more Data | 1684 | | | | Items in the Message | 1685 | | | | are invalid, | 1686 | | | | unexpected or | 1687 | | | | incorrectly | 1688 | | | | duplicated. | 1689 | 131 | Terminate | Invalid | The destination | 1690 | | | Destination | included in the | 1691 | | | | Message does not | 1692 | | | | match a previously | 1693 | | | | announced | 1694 | | | | destination. For | 1695 | | | | example, in the Link | 1696 | | | | Characteristic | 1697 | | | | Response Message | 1698 | | | | (Section 10.19). | 1699 | 132 | Terminate | Timed Out | The session has timed | 1700 | | | | out. | 1701 | 133-239 | Terminate | | Reserved for future | 1702 | | | | extensions. | 1703 | 240-254 | Terminate | | Available for | 1704 | | | | experiments. | 1705 | 255 | Terminate | | Reserved. | 1706 +----------+-------------+------------------+-----------------------+ 1708 Table 2: DLEP Status Codes 1710 11.2. IPv4 Connection Point 1712 The IPv4 Connection Point Data Item indicates the IPv4 address and, 1713 optionally, the TCP port number on the modem available for 1714 connections. If provided, the router MUST use this information to 1715 initiate the TCP connection to the modem. 1717 The IPv4 Connection Point Data Item contains the following fields: 1719 0 1 2 3 1720 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 1721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1722 | Data Item Type | Length | 1723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1724 | Flags | IPv4 Address... : 1725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1726 : ...cont. | TCP Port Number (optional) | 1727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1729 Data Item Type: 2 1731 Length: 5 (or 7 if TCP Port included) 1733 Flags: Flags field, defined below. 1735 IPv4 Address: The IPv4 address listening on the modem. 1737 TCP Port Number: TCP Port number on the modem. 1739 If the Length field is 7, the port number specified MUST be used to 1740 establish the TCP session. If the TCP Port Number is omitted, i.e. 1741 the Length field is 5, the router MUST use the DLEP well-known port 1742 number (Section 13.7) to establish the TCP connection. 1744 The Flags field is defined as: 1746 0 1 2 3 4 5 6 7 1747 +-+-+-+-+-+-+-+-+ 1748 | Reserved | 1749 +-+-+-+-+-+-+-+-+ 1751 Reserved: MUST be zero. Reserved for future use. 1753 11.3. IPv6 Connection Point 1755 The IPv6 Connection Point Data Item indicates the IPv6 address and, 1756 optionally, the TCP port number on the modem available for 1757 connections. If provided, the router MUST use this information to 1758 initiate the TCP connection to the modem. 1760 The IPv6 Connection Point Data Item contains the following fields: 1762 0 1 2 3 1763 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 1764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1765 | Data Item Type | Length | 1766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1767 | Flags | IPv6 Address : 1768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1769 : IPv6 Address : 1770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1771 : IPv6 Address : 1772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1773 : IPv6 Address : 1774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1775 : ...cont. | TCP Port Number (optional) | 1776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1778 Data Item Type: 3 1780 Length: 17 (or 19 if TCP Port included) 1782 Flags: Flags field, defined below. 1784 IPv6 Address: The IPv6 address listening on the modem. 1786 TCP Port Number: TCP Port number on the modem. 1788 If the Length field is 19, the port number specified MUST be used to 1789 establish the TCP session. If the TCP Port Number is omitted, i.e. 1790 the Length field is 17, the router MUST use the DLEP well-known port 1791 number (Section 13.7) to establish the TCP connection. 1793 The Flags field is defined as: 1795 0 1 2 3 4 5 6 7 1796 +-+-+-+-+-+-+-+-+ 1797 | Reserved | 1798 +-+-+-+-+-+-+-+-+ 1800 Reserved: MUST be zero. Reserved for future use. 1802 11.4. Peer Type 1804 The Peer Type Data Item is used by the router and modem to give 1805 additional information as to its type. The Peer Type is a string and 1806 is envisioned to be used for informational purposes (e.g., as output 1807 in a display command). 1809 The Peer Type Data Item contains the following fields: 1811 0 1 2 3 1812 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1814 | Data Item Type | Length | 1815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1816 | Peer Type... : 1817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1819 Data Item Type: 4 1821 Length: Length of Peer Type string, in octets. 1823 Peer Type: UTF-8 encoded string of UNICODE [UNIV8] characters. For 1824 example, a satellite modem might set this variable to "Satellite 1825 terminal". Since this Data Item is intended to provide additional 1826 information for display commands, sending implementations SHOULD 1827 limit the data to printable characters, and receiving 1828 implementations SHOULD check the data for printable characters. 1830 An implementation MUST NOT assume the Peer Type field is NUL- 1831 terminated. 1833 11.5. Heartbeat Interval 1835 The Heartbeat Interval Data Item is used to specify a period in 1836 milliseconds for Heartbeat Messages (Section 10.20). 1838 The Heartbeat Interval Data Item contains the following fields: 1840 0 1 2 3 1841 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1843 | Data Item Type | Length | 1844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1845 | Heartbeat Interval | 1846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1848 Data Item Type: 5 1850 Length: 4 1852 Heartbeat Interval: The interval in milliseconds, expressed as a 1853 32-bit unsigned integer, for Heartbeat Messages. This value MUST 1854 NOT be 0. 1856 11.6. Extensions Supported 1858 The Extensions Supported Data Item is used by the router and modem to 1859 negotiate additional optional functionality they are willing to 1860 support. The Extensions List is a concatenation of the types of each 1861 supported extension, found in the IANA DLEP Extensions repository. 1862 Each Extension Type definition includes which additional Signals and 1863 Data Items are supported. 1865 The Extensions Supported Data Item contains the following fields: 1867 0 1 2 3 1868 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1870 | Data Item Type | Length | 1871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1872 | Extensions List... 1873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1875 Data Item Type: 6 1877 Length: Length of the extensions list in octets. This is twice (2x) 1878 the number of extensions. 1880 Extension List: A list of extensions supported, identified by their 1881 2-octet value as listed in the extensions registry. 1883 11.7. MAC Address 1885 The MAC Address Data Item contains the address of the destination on 1886 the remote node. 1888 DLEP can support MAC addresses in either EUI-48 or EUI-64 format, 1889 with the restriction that all MAC addresses for a given DLEP session 1890 MUST be in the same format, and MUST be consistent with the MAC 1891 address format of the connected modem (e.g., if the modem is 1892 connected to the router with an EUI-48 MAC, all destination addresses 1893 via that modem MUST be expressed in EUI-48 format). 1895 Examples of a virtual destination would be a multicast MAC address, 1896 or the broadcast MAC (FF:FF:FF:FF:FF:FF). 1898 0 1 2 3 1899 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 1900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1901 | Data Item Type | Length | 1902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1903 | MAC Address : 1904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1905 : MAC Address : 1906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1907 : MAC Address : (if EUI-64 used) | 1908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1910 Data Item Type: 7 1912 Length: 6 for EUI-48 format, or 8 for EUI-64 format 1914 MAC Address: MAC Address of the destination. 1916 11.8. IPv4 Address 1918 When included in Destination Messages, this Data Item contains the 1919 IPv4 address of the destination. When included in the Session Update 1920 Message, this Data Item contains the IPv4 address of the peer. In 1921 either case, the Data Item also contains an indication of whether 1922 this is a new or existing address, or is a deletion of a previously 1923 known address. 1925 The IPv4 Address Data Item contains the following fields: 1927 0 1 2 3 1928 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 1929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1930 | Data Item Type | Length | 1931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1932 | Flags | IPv4 Address : 1933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1934 : ...cont. | 1935 +-+-+-+-+-+-+-+-+ 1937 Data Item Type: 8 1939 Length: 5 1941 Flags: Flags field, defined below. 1943 IPv4 Address: The IPv4 address of the destination or peer. 1945 The Flags field is defined as: 1947 0 1 2 3 4 5 6 7 1948 +-+-+-+-+-+-+-+-+ 1949 | Reserved |A| 1950 +-+-+-+-+-+-+-+-+ 1952 A: Add/Drop flag, indicating whether this is a new or existing 1953 address (1), or a withdrawal of an address (0). 1955 Reserved: MUST be zero. Reserved for future use. 1957 11.9. IPv6 Address 1959 When included in Destination Messages, this Data Item contains the 1960 IPv6 address of the destination. When included in the Session Update 1961 Message, this Data Item contains the IPv6 address of the peer. In 1962 either case, the Data Item also contains an indication of whether 1963 this is a new or existing address, or is a deletion of a previously 1964 known address. 1966 The IPv6 Address Data Item contains the following fields: 1968 0 1 2 3 1969 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 1970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1971 | Data Item Type | Length | 1972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1973 | Flags | IPv6 Address : 1974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1975 : IPv6 Address : 1976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1977 : IPv6 Address : 1978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1979 : IPv6 Address : 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1981 : IPv6 Address | 1982 +-+-+-+-+-+-+-+-+ 1984 Data Item Type: 9 1986 Length: 17 1988 Flags: Flags field, defined below. 1990 IPv6 Address: IPv6 Address of the destination or peer. 1992 The Flags field is defined as: 1994 0 1 2 3 4 5 6 7 1995 +-+-+-+-+-+-+-+-+ 1996 | Reserved |A| 1997 +-+-+-+-+-+-+-+-+ 1999 A: Add/Drop flag, indicating whether this is a new or existing 2000 address (1), or a withdrawal of an address (0). 2002 Reserved: MUST be zero. Reserved for future use. 2004 11.10. IPv4 Attached Subnet 2006 The DLEP IPv4 Attached Subnet allows a device to declare that it has 2007 an IPv4 subnet (e.g., a stub network) attached, that it has become 2008 aware of an IPv4 subnet being present at a remote destination, or 2009 that it has become aware of the loss of a subnet at the remote 2010 destination. 2012 The DLEP IPv4 Attached Subnet Data Item contains the following 2013 fields: 2015 0 1 2 3 2016 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 2017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2018 | Data Item Type | Length | 2019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2020 | Flags | IPv4 Attached Subnet : 2021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2022 : ...cont. |Prefix Length | 2023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2025 Data Item Type: 10 2027 Length: 6 2029 Flags: Flags field, defined below. 2031 IPv4 Subnet: The IPv4 subnet reachable at the destination. 2033 Prefix Length: Length of the prefix (0-32) for the IPv4 subnet. A 2034 prefix length outside the specified range MUST be considered as 2035 invalid. 2037 The Flags field is defined as: 2039 0 1 2 3 4 5 6 7 2040 +-+-+-+-+-+-+-+-+ 2041 | Reserved |A| 2042 +-+-+-+-+-+-+-+-+ 2044 A: Add/Drop flag, indicating whether this is a new or existing subnet 2045 address (1), or a withdrawal of a subnet address (0). 2047 Reserved: MUST be zero. Reserved for future use. 2049 11.11. IPv6 Attached Subnet 2051 The DLEP IPv6 Attached Subnet allows a device to declare that it has 2052 an IPv6 subnet (e.g., a stub network) attached, that it has become 2053 aware of an IPv6 subnet being present at a remote destination, or 2054 that it has become aware of the loss of a subnet at the remote 2055 destination. 2057 The DLEP IPv6 Attached Subnet Data Item contains the following 2058 fields: 2060 0 1 2 3 2061 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 2062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2063 | Data Item Type | Length | 2064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2065 | Flags | IPv6 Attached Subnet : 2066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2067 : IPv6 Attached Subnet : 2068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2069 : IPv6 Attached Subnet : 2070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2071 : IPv6 Attached Subnet : 2072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2073 : ...cont. | Prefix Len. | 2074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2076 Data Item Type: 11 2078 Length: 18 2080 Flags: Flags field, defined below. 2082 IPv6 Attached Subnet: The IPv6 subnet reachable at the destination. 2084 Prefix Length: Length of the prefix (0-128) for the IPv6 subnet. A 2085 prefix length outside the specified range MUST be considered as 2086 invalid. 2088 The Flags field is defined as: 2090 0 1 2 3 4 5 6 7 2091 +-+-+-+-+-+-+-+-+ 2092 | Reserved |A| 2093 +-+-+-+-+-+-+-+-+ 2095 A: Add/Drop flag, indicating whether this is a new or existing subnet 2096 address (1), or a withdrawal of a subnet address (0). 2098 Reserved: MUST be zero. Reserved for future use. 2100 11.12. Maximum Data Rate (Receive) 2102 The Maximum Data Rate (Receive) (MDRR) Data Item is used to indicate 2103 the maximum theoretical data rate, in bits per second, that can be 2104 achieved while receiving data on the link. 2106 The Maximum Data Rate (Receive) Data Item contains the following 2107 fields: 2109 0 1 2 3 2110 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 2111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2112 | Data Item Type | Length | 2113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2114 | MDRR (bps) : 2115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2116 : MDRR (bps) | 2117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2119 Data Item Type: 12 2121 Length: 8 2123 Maximum Data Rate (Receive): A 64-bit unsigned integer, representing 2124 the maximum theoretical data rate, in bits per second (bps), that 2125 can be achieved while receiving on the link. 2127 11.13. Maximum Data Rate (Transmit) 2129 The Maximum Data Rate (Transmit) (MDRT) Data Item is used to indicate 2130 the maximum theoretical data rate, in bits per second, that can be 2131 achieved while transmitting data on the link. 2133 The Maximum Data Rate (Transmit) Data Item contains the following 2134 fields: 2136 0 1 2 3 2137 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 2138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2139 | Data Item Type | Length | 2140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2141 | MDRT (bps) : 2142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2143 : MDRT (bps) | 2144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2146 Data Item Type: 13 2148 Length: 8 2150 Maximum Data Rate (Transmit): A 64-bit unsigned integer, 2151 representing the maximum theoretical data rate, in bits per second 2152 (bps), that can be achieved while transmitting on the link. 2154 11.14. Current Data Rate (Receive) 2156 The Current Data Rate (Receive) (CDRR) Data Item is used to indicate 2157 the rate at which the link is currently operating for receiving 2158 traffic. 2160 When used in the Link Characteristics Request Message 2161 (Section 10.18), Current Data Rate (Receive) represents the desired 2162 receive rate, in bits per second, on the link. 2164 The Current Data Rate (Receive) Data Item contains the following 2165 fields: 2167 0 1 2 3 2168 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 2169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2170 | Data Item Type | Length | 2171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2172 | CDRR (bps) : 2173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2174 : CDRR (bps) | 2175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2177 Data Item Type: 14 2179 Length: 8 2181 Current Data Rate (Receive): A 64-bit unsigned integer, representing 2182 the current data rate, in bits per second, that can currently be 2183 achieved while receiving traffic on the link. 2185 If there is no distinction between Current Data Rate (Receive) and 2186 Maximum Data Rate (Receive) (Section 11.12), Current Data Rate 2187 (Receive) MUST be set equal to the Maximum Data Rate (Receive). The 2188 Current Data Rate (Receive) MUST NOT exceed the Maximum Data Rate 2189 (Receive). 2191 11.15. Current Data Rate (Transmit) 2193 The Current Data Rate (Transmit) (CDRT) Data Item is used to indicate 2194 the rate at which the link is currently operating for transmitting 2195 traffic. 2197 When used in the Link Characteristics Request Message 2198 (Section 10.18), Current Data Rate (Transmit) represents the desired 2199 transmit rate, in bits per second, on the link. 2201 The Current Data Rate (Transmit) Data Item contains the following 2202 fields: 2204 0 1 2 3 2205 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 2206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2207 | Data Item Type | Length | 2208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2209 | CDRT (bps) : 2210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2211 : CDRT (bps) | 2212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2214 Data Item Type: 15 2216 Length: 8 2218 Current Data Rate (Transmit): A 64-bit unsigned integer, 2219 representing the current data rate, in bits per second, that can 2220 currently be achieved while transmitting traffic on the link. 2222 If there is no distinction between Current Data Rate (Transmit) and 2223 Maximum Data Rate (Transmit) (Section 11.13), Current Data Rate 2224 (Transmit) MUST be set equal to the Maximum Data Rate (Transmit). 2225 The Current Data Rate (Transmit) MUST NOT exceed the Maximum Data 2226 Rate (Transmit). 2228 11.16. Latency 2230 The Latency Data Item is used to indicate the amount of latency, in 2231 microseconds, on the link. 2233 The Latency value is reported as transmission delay. The calculation 2234 of latency is implementation dependent. For example, the latency may 2235 be a running average calculated from the internal queuing. 2237 The Latency Data Item contains the following fields: 2239 0 1 2 3 2240 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 2241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2242 | Data Item Type | Length | 2243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2244 | Latency : 2245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2246 : Latency | 2247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2249 Data Item Type: 16 2251 Length: 8 2253 Latency: A 64-bit unsigned integer, representing the transmission 2254 delay, in microseconds, that a packet encounters as it is 2255 transmitted over the link. 2257 11.17. Resources 2259 The Resources (RES) Data Item is used to indicate the amount of 2260 finite resources available for data transmission and reception at the 2261 destination as a percentage, with 0 meaning 'no resources remaining', 2262 and 100 meaning 'a full supply', assuming that when Resources reaches 2263 0 data transmission and/or reception will cease. 2265 An example of such resources might be battery life, but could equally 2266 be magic beans. The list of resources that might be considered is 2267 beyond the scope of this document, and is left to implementations to 2268 decide. 2270 This Data Item is designed to be used as an indication of some 2271 capability of the modem and/or router at the destination. 2273 The Resources Data Item contains the following fields: 2275 0 1 2 3 2276 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 2277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2278 | Data Item Type | Length | 2279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2280 | RES | 2281 +-+-+-+-+-+-+-+-+ 2283 Data Item Type: 17 2285 Length: 1 2287 Resources: An 8-bit unsigned integer percentage, 0-100, representing 2288 the amount of resources available. Any value greater than 100 2289 MUST be considered as invalid. 2291 If a device cannot calculate Resources, this Data Item MUST NOT be 2292 issued. 2294 11.18. Relative Link Quality (Receive) 2296 The Relative Link Quality (Receive) (RLQR) Data Item is used to 2297 indicate the quality of the link to a destination for receiving 2298 traffic, with 0 meaning 'worst quality', and 100 meaning 'best 2299 quality'. 2301 Quality in this context is defined as an indication of the stability 2302 of a link for reception; a destination with high Relative Link 2303 Quality (Receive) is expected to have generally stable DLEP metrics, 2304 and the metrics of a destination with low Relative Link Quality 2305 (Receive) can be expected to rapidly fluctuate over a wide range. 2307 The Relative Link Quality (Receive) Data Item contains the following 2308 fields: 2310 0 1 2 3 2311 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 2312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2313 | Data Item Type | Length | 2314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2315 | RLQR | 2316 +-+-+-+-+-+-+-+-+ 2318 Data Item Type: 18 2320 Length: 1 2321 Relative Link Quality (Receive): A non-dimensional unsigned 8-bit 2322 integer, 0-100, representing relative quality of the link for 2323 receiving traffic. Any value greater than 100 MUST be considered 2324 as invalid. 2326 If a device cannot calculate the Relative Link Quality (Receive), 2327 this Data Item MUST NOT be issued. 2329 11.19. Relative Link Quality (Transmit) 2331 The Relative Link Quality (Transmit) (RLQT) Data Item is used to 2332 indicate the quality of the link to a destination for transmitting 2333 traffic, with 0 meaning 'worst quality', and 100 meaning 'best 2334 quality'. 2336 Quality in this context is defined as an indication of the stability 2337 of a link for transmission; a destination with high Relative Link 2338 Quality (Transmit) is expected to have generally stable DLEP metrics, 2339 and the metrics of a destination with low Relative Link Quality 2340 (Transmit) can be expected to rapidly fluctuate over a wide range. 2342 The Relative Link Quality (Transmit) Data Item contains the following 2343 fields: 2345 0 1 2 3 2346 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 2347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2348 | Data Item Type | Length | 2349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2350 | RLQT | 2351 +-+-+-+-+-+-+-+-+ 2353 Data Item Type: 19 2355 Length: 1 2357 Relative Link Quality (Transmit): A non-dimensional unsigned 8-bit 2358 integer, 0-100, representing relative quality of the link for 2359 transmitting traffic. Any value greater than 100 MUST be 2360 considered as invalid. 2362 If a device cannot calculate the Relative Link Quality (Transmit), 2363 this Data Item MUST NOT be issued. 2365 11.20. Maximum Transmission Unit (MTU) 2367 The Maximum Transmission Unit (MTU) Data Item is used to indicate the 2368 maximum size, in octets, of an IP packet that can be transmitted 2369 without fragmentation, including headers, but excluding any lower 2370 layer headers. 2372 The Maximum Transmission Unit Data Item contains the following 2373 fields: 2375 0 1 2 3 2376 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 2377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2378 | Data Item Type | Length | 2379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2380 | MTU | 2381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2383 Data Item Type: 20 2385 Length: 2 2387 Maximum Transmission Unit: The maximum size, in octets, of an IP 2388 packet that can be transmitted without fragmentation, including 2389 headers, but excluding any lower layer headers. 2391 If a device cannot calculate the Maximum Transmission Unit, this Data 2392 Item MUST NOT be issued. 2394 12. Security Considerations 2396 The potential security concerns when using DLEP are: 2398 1. An attacker might pretend to be a DLEP participant, either at 2399 DLEP session initialization, or by injection of DLEP Messages 2400 once a session has been established, and/or 2402 2. DLEP Data Items could be altered by an attacker, causing the 2403 receiving implementation to inappropriately alter its information 2404 base concerning network status. 2406 Since DLEP is restricted to operation over a single (possibly 2407 logical) hop at layer 2, implementations requiring authentication 2408 and/or encryption of traffic MUST take steps to secure the Layer 2 2409 link. Examples of technologies that can be deployed to secure the 2410 Layer 2 link include [IEEE-802.1AE] and [IEEE-802.1X]. 2412 To avoid potential denial of service attack, it is RECOMMENDED that 2413 implementations using the Peer Discovery mechanism maintain an 2414 information base of hosts that persistently fail Session 2415 Initialization having provided an acceptable Peer Discovery Signal, 2416 and ignore subsequent Peer Discovery Signals from such hosts. 2418 This specification does not address security of the data plane, as it 2419 (the data plane) is not affected, and standard security procedures 2420 can be employed. 2422 13. IANA Considerations 2424 This section specifies requests to IANA. 2426 13.1. Registrations 2428 Upon approval of this document, IANA is requested to create a new 2429 protocol registry for Dynamic Link Exchange Protocol (DLEP). The 2430 remainder of this section requests the creation of new DLEP specific 2431 registries. 2433 13.2. Signal Type Registration 2435 Upon approval of this document, IANA is requested to create a new 2436 DLEP registry, named "Signal Type Values". 2438 The following table provides initial registry values and the 2439 [RFC5226] defined policies that should apply to the registry: 2441 +--------------+-------------------------+ 2442 | Type Code | Description/Policy | 2443 +--------------+-------------------------+ 2444 | 0 | Reserved | 2445 | 1 | Peer Discovery Signal | 2446 | 2 | Peer Offer Signal | 2447 | 3-65519 | Specification Required | 2448 | 65520-65534 | Private Use | 2449 | 65535 | Reserved | 2450 +--------------+-------------------------+ 2452 13.3. Message Type Registration 2454 Upon approval of this document, IANA is requested to create a new 2455 DLEP registry, named "Message Type Values". 2457 The following table provides initial registry values and the 2458 [RFC5226] defined policies that should apply to the registry: 2460 +--------------+------------------------------------------+ 2461 | Type Code | Description/Policy | 2462 +--------------+------------------------------------------+ 2463 | 0 | Reserved | 2464 | 1 | Session Initialization Message | 2465 | 2 | Session Initialization Response Message | 2466 | 3 | Session Update Message | 2467 | 4 | Session Update Response Message | 2468 | 5 | Session Termination Message | 2469 | 6 | Session Termination Response Message | 2470 | 7 | Destination Up Message | 2471 | 8 | Destination Up Response Message | 2472 | 9 | Destination Announce Message | 2473 | 10 | Destination Announce Response Message | 2474 | 11 | Destination Down Message | 2475 | 12 | Destination Down Response Message | 2476 | 13 | Destination Update Message | 2477 | 14 | Link Characteristics Request Message | 2478 | 15 | Link Characteristics Response Message | 2479 | 16 | Heartbeat Message | 2480 | 17-65519 | Specification Required | 2481 | 65520-65534 | Private Use | 2482 | 65535 | Reserved | 2483 +--------------+------------------------------------------+ 2485 13.4. DLEP Data Item Registrations 2487 Upon approval of this document, IANA is requested to create a new 2488 DLEP registry, named "Data Item Values". 2490 The following table provides initial registry values and the 2491 [RFC5226] defined policies that should apply to the registry: 2493 +-------------------+------------------------------------------+ 2494 | Type Code | Description/Policy | 2495 +-------------------+------------------------------------------+ 2496 | 0 | Reserved | 2497 | 1 | Status | 2498 | 2 | IPv4 Connection Point | 2499 | 3 | IPv6 Connection Point | 2500 | 4 | Peer Type | 2501 | 5 | Heartbeat Interval | 2502 | 6 | Extensions Supported | 2503 | 7 | MAC Address | 2504 | 8 | IPv4 Address | 2505 | 9 | IPv6 Address | 2506 | 10 | IPv4 Attached Subnet | 2507 | 11 | IPv6 Attached Subnet | 2508 | 12 | Maximum Data Rate (Receive) (MDRR) | 2509 | 13 | Maximum Data Rate (Transmit) (MDRT) | 2510 | 14 | Current Data Rate (Receive) (CDRR) | 2511 | 15 | Current Data Rate (Transmit) (CDRT) | 2512 | 16 | Latency | 2513 | 17 | Resources (RES) | 2514 | 18 | Relative Link Quality (Receive) (RLQR) | 2515 | 19 | Relative Link Quality (Transmit) (RLQT) | 2516 | 20 | Maximum Transmission Unit (MTU) | 2517 | 21-65407 | Specification Required | 2518 | 65408-65534 | Private Use | 2519 | 65535 | Reserved | 2520 +-------------------+------------------------------------------+ 2522 13.5. DLEP Status Code Registrations 2524 Upon approval of this document, IANA is requested to create a new 2525 DLEP registry, named "Status Code Values". 2527 The following table provides initial registry values and the 2528 [RFC5226] defined policies that should apply to the registry: 2530 +--------------+---------------+-------------------------+ 2531 | Status Code | Failure Mode | Description/Policy | 2532 +--------------+---------------+-------------------------+ 2533 | 0 | Continue | Success | 2534 | 1 | Continue | Not Interested | 2535 | 2 | Continue | Request Denied | 2536 | 3-111 | Continue | Specification Required | 2537 | 112-127 | Continue | Private Use | 2538 | 128 | Terminate | Unknown Message | 2539 | 129 | Terminate | Unexpected Message | 2540 | 130 | Terminate | Invalid Data | 2541 | 131 | Terminate | Invalid Destination | 2542 | 132 | Terminate | Timed Out | 2543 | 133-239 | Terminate | Specification Required | 2544 | 240-254 | Terminate | Private Use | 2545 | 255 | Terminate | Reserved | 2546 +--------------+---------------+-------------------------+ 2548 13.6. DLEP Extensions Registrations 2550 Upon approval of this document, IANA is requested to create a new 2551 DLEP registry, named "Extension Type Values". 2553 The following table provides initial registry values and the 2554 [RFC5226] defined policies that should apply to the registry: 2556 +--------------+----------------------------+ 2557 | Code | Description/Policy | 2558 +--------------+----------------------------+ 2559 | 0 | Reserved | 2560 | 1 | Credit Windowing [CREDIT] | 2561 | 2-65519 | Specification Required | 2562 | 65520-65534 | Private Use | 2563 | 65535 | Reserved | 2564 +--------------+----------------------------+ 2566 Table 3: DLEP Extension types 2568 13.7. DLEP Well-known Port 2570 Upon approval of this document, IANA is requested to assign a single 2571 value in the "Service Name and Transport Protocol Port Number 2572 Registry" found at https://www.iana.org/assignments/service-names- 2573 port-numbers/service-names-port-numbers.xhtml for use by "DLEP", as 2574 defined in this document. This assignment should be valid for TCP 2575 and UDP. 2577 13.8. DLEP IPv4 Link-local Multicast Address 2579 Upon approval of this document, IANA is requested to assign an IPv4 2580 multicast address registry found at http://www.iana.org/assignments/ 2581 multicast-addresses for use as the "IPv4 DLEP Discovery Address". 2583 13.9. DLEP IPv6 Link-local Multicast Address 2585 Upon approval of this document, IANA is requested to assign an IPv6 2586 multicast address registry found at http://www.iana.org/assignments/ 2587 multicast-addresses for use as the "IPv6 DLEP Discovery Address". 2589 14. Acknowledgements 2591 We would like to acknowledge and thank the members of the DLEP design 2592 team, who have provided invaluable insight. The members of the 2593 design team are: Teco Boot, Bow-Nan Cheng, John Dowdell, and Henning 2594 Rogge. 2596 We would also like to acknowledge the influence and contributions of 2597 Greg Harrison, Chris Olsen, Martin Duke, Subir Das, Jaewon Kang, 2598 Vikram Kaul, Nelson Powell, Lou Berger, and Victoria Pritchard. 2600 15. References 2602 15.1. Normative References 2604 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2605 Requirement Levels", BCP 14, RFC 2119, 2606 DOI 10.17487/RFC2119, March 1997, 2607 . 2609 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. 2610 Pignataro, "The Generalized TTL Security Mechanism 2611 (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, 2612 . 2614 [UNIV8] "The Unicode Consortium. The Unicode Standard, Version 2615 8.0.0, (Mountain View, CA: The Unicode Consortium, 2015. 2616 ISBN 978-1-936213-10-8)", 2617 http://www.unicode.org/versions/Unicode8.0.0/, June 2015. 2619 15.2. Informative References 2621 [CREDIT] Ratliff, S., "Credit Windowing extension for DLEP", IETF 2622 draft draft-ietf-manet-credit-window-04, March 2016. 2624 [IEEE-802.1AE] 2625 "IEEE Standards for Local and Metropolitan Area Networks: 2626 Media Access Control (MAC) Security", 2627 DOI 10.1109/IEEESTD.2006.245590, August 2006. 2629 [IEEE-802.1X] 2630 "IEEE Standards for Local and Metropolitan Area Networks: 2631 Port based Network Access Control", 2632 DOI 10.1109/IEEESTD.2010.5409813, February 2010. 2634 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2635 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2636 DOI 10.17487/RFC5226, May 2008, 2637 . 2639 [RFC5578] Berry, B., Ed., Ratliff, S., Paradise, E., Kaiser, T., and 2640 M. Adams, "PPP over Ethernet (PPPoE) Extensions for Credit 2641 Flow and Link Metrics", RFC 5578, DOI 10.17487/RFC5578, 2642 February 2010, . 2644 Appendix A. Discovery Signal Flows 2646 Router Modem Signal Description 2647 ======================================================================== 2649 | Router initiates discovery, starts 2650 | a timer, send Peer Discovery 2651 |-------Peer Discovery---->X Signal. 2653 ~ ~ ~ ~ ~ ~ ~ Router discovery timer expires 2654 without receiving Peer Offer. 2656 | Router sends another Peer 2657 |-------Peer Discovery---------->| Discovery Signal. 2658 | 2659 | Modem receives Peer Discovery 2660 | Signal. 2661 | 2662 | Modem sends Peer Offer with 2663 |<--------Peer Offer-------------| Connection Point information. 2664 : 2665 : Router MAY cancel discovery timer 2666 : and stop sending Peer Discovery 2667 : Signals. 2669 Appendix B. Peer Level Message Flows 2671 B.1. Session Initialization 2673 Router Modem Message Description 2674 ======================================================================== 2676 | Router connects to discovered or 2677 | pre-configured Modem Connection 2678 |--TCP connection established---> Point. 2679 | 2680 | Router sends Session 2681 |----Session Initialization----->| Initialization Message. 2682 | 2683 | Modem receives Session 2684 | Initialization Message. 2685 | 2686 | Modem sends Session Initialization 2687 |<--Session Initialization Resp.-| Response, with Success Status Data 2688 | | Item. 2689 | | 2690 |<<============================>>| Session established. Heartbeats 2691 : : begin. 2693 B.2. Session Initialization - Refused 2694 Router Modem Message Description 2695 ======================================================================== 2697 | Router connects to discovered or 2698 | pre-configured Modem Connection 2699 |--TCP connection established---> Point. 2700 | 2701 | Router sends Session 2702 |-----Session Initialization---->| Initialization Message. 2703 | 2704 | Modem receives Session 2705 | Initialization Message, and will 2706 | not support the advertised 2707 | extensions. 2708 | 2709 | Modem sends Session Initialization 2710 | Response, with 'Request Denied' 2711 |<-Session Initialization Resp.--| Status Data Item. 2712 | 2713 | 2714 | Router receives negative Session 2715 | Initialization Response, closes 2716 ||---------TCP close------------|| TCP connection. 2718 B.3. Router Changes IP Addresses 2720 Router Modem Message Description 2721 ======================================================================== 2723 | Router sends Session Update 2724 |-------Session Update---------->| Message to announce change of IP 2725 | address 2726 | 2727 | Modem receives Session Update 2728 | Message and updates internal 2729 | state. 2730 | 2731 |<----Session Update Response----| Modem sends Session Update 2732 | Response. 2734 B.4. Modem Changes Session-wide Metrics 2735 Router Modem Message Description 2736 ======================================================================== 2738 | Modem sends Session Update Message 2739 | to announce change of modem-wide 2740 |<--------Session Update---------| metrics 2741 | 2742 | Router receives Session Update 2743 | Message and updates internal 2744 | state. 2745 | 2746 |----Session Update Response---->| Router sends Session Update 2747 | Response. 2749 B.5. Router Terminates Session 2751 Router Modem Message Description 2752 ======================================================================== 2754 | Router sends Session Termination 2755 |------Session Termination------>| Message with Status Data Item. 2756 | | 2757 |-------TCP shutdown (send)---> | Router stops sending Messages. 2758 | 2759 | Modem receives Session 2760 | Termination, stops counting 2761 | received heartbeats and stops 2762 | sending heartbeats. 2763 | 2764 | Modem sends Session Termination 2765 |<---Session Termination Resp.---| Response with Status 'Success'. 2766 | 2767 | Modem stops sending Messages. 2768 | 2769 ||---------TCP close------------|| Session terminated. 2771 B.6. Modem Terminates Session 2772 Router Modem Message Description 2773 ======================================================================== 2775 | Modem sends Session Termination 2776 |<----Session Termination--------| Message with Status Data Item. 2777 | 2778 | Modem stops sending Messages. 2779 | 2780 | Router receives Session 2781 | Termination, stops counting 2782 | received heartbeats and stops 2783 | sending heartbeats. 2784 | 2785 | Router sends Session Termination 2786 |---Session Termination Resp.--->| Response with Status 'Success'. 2787 | 2788 | Router stops sending Messages. 2789 | 2790 ||---------TCP close------------|| Session terminated. 2792 B.7. Session Heartbeats 2793 Router Modem Message Description 2794 ======================================================================== 2796 |----------Heartbeat------------>| Router sends heartbeat Message 2797 | 2798 | Modem resets heartbeats missed 2799 | counter. 2801 ~ ~ ~ ~ ~ ~ ~ 2803 |---------[Any Message]--------->| When the Modem receives any 2804 | Message from the Router. 2805 | 2806 | Modem resets heartbeats missed 2807 | counter. 2809 ~ ~ ~ ~ ~ ~ ~ 2811 |<---------Heartbeat-------------| Modem sends heartbeat Message 2812 | 2813 | Router resets heartbeats missed 2814 | counter. 2816 ~ ~ ~ ~ ~ ~ ~ 2818 |<--------[Any Message]----------| When the Router receives any 2819 | Message from the Modem. 2820 | 2821 | Modem resets heartbeats missed 2822 | counter. 2824 B.8. Router Detects a Heartbeat timeout 2826 Router Modem Message Description 2827 ======================================================================== 2829 X<----------------------| Router misses a heartbeat 2831 | X<----------------------| Router misses too many heartbeats 2832 | 2833 | 2834 |------Session Termination------>| Router sends Session Termination 2835 | Message with 'Timeout' Status 2836 | Data Item. 2837 : 2838 : Termination proceeds... 2840 B.9. Modem Detects a Heartbeat timeout 2842 Router Modem Message Description 2843 ======================================================================== 2845 |---------------------->X Modem misses a heartbeat 2847 |---------------------->X | Modem misses too many heartbeats 2848 | 2849 | 2850 |<-----Session Termination-------| Modem sends Session Termination 2851 | Message with 'Timeout' Status 2852 | Data Item. 2853 : 2854 : Termination proceeds... 2856 Appendix C. Destination Specific Message Flows 2858 C.1. Common Destination Notification 2859 Router Modem Message Description 2860 ======================================================================== 2862 | Modem detects a new logical 2863 | destination is reachable, and 2864 |<-------Destination Up----------| sends Destination Up Message. 2865 | 2866 |------Destination Up Resp.----->| Router sends Destination Up 2867 | Response. 2869 ~ ~ ~ ~ ~ ~ ~ 2870 | Modem detects change in logical 2871 | destination metrics, and sends 2872 |<-------Destination Update------| Destination Update Message. 2874 ~ ~ ~ ~ ~ ~ ~ 2875 | Modem detects change in logical 2876 | destination metrics, and sends 2877 |<-------Destination Update------| Destination Update Message. 2879 ~ ~ ~ ~ ~ ~ ~ 2880 | Modem detects logical destination 2881 | is no longer reachable, and sends 2882 |<-------Destination Down--------| Destination Down Message. 2883 | 2884 | Router receives Destination Down, 2885 | updates internal state, and sends 2886 |------Destination Down Resp.--->| Destination Down Response Message. 2888 C.2. Multicast Destination Notification 2889 Router Modem Message Description 2890 ======================================================================== 2892 | Router detects a new multicast 2893 | destination is in use, and sends 2894 |-----Destination Announce------>| Destination Announce Message. 2895 | 2896 | Modem updates internal state to 2897 | monitor multicast destination, and 2898 |<-----Dest. Announce Resp.------| sends Destination Announce 2899 Response. 2901 ~ ~ ~ ~ ~ ~ ~ 2902 | Modem detects change in multicast 2903 | destination metrics, and sends 2904 |<-------Destination Update------| Destination Update Message. 2906 ~ ~ ~ ~ ~ ~ ~ 2907 | Modem detects change in multicast 2908 | destination metrics, and sends 2909 |<-------Destination Update------| Destination Update Message. 2911 ~ ~ ~ ~ ~ ~ ~ 2912 | Router detects multicast 2913 | destination is no longer in use, 2914 |--------Destination Down------->| and sends Destination Down 2915 | Message. 2916 | 2917 | Modem receives Destination Down, 2918 | updates internal state, and sends 2919 |<-----Destination Down Resp.----| Destination Down Response Message. 2921 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