idnits 2.17.1 draft-ietf-manet-dlep-21.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 44 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 273 has weird spacing: '... Shared o ...' == Line 274 has weird spacing: '... Medium o ...' -- The document date (March 21, 2016) is 2957 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 2626, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-manet-credit-window-02 -- Possible downref: Non-RFC (?) normative reference: ref. 'UNIV8' -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile Ad hoc Networks Working Group S. Ratliff 2 Internet-Draft VT iDirect 3 Intended status: Standards Track B. Berry 4 Expires: September 22, 2016 5 S. Jury 6 Cisco Systems 7 D. Satterwhite 8 Broadcom 9 R. Taylor 10 Airbus Defence & Space 11 March 21, 2016 13 Dynamic Link Exchange Protocol (DLEP) 14 draft-ietf-manet-dlep-21 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 September 22, 2016. 45 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 7 63 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 64 2.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 9 65 3. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 4. DLEP Session Flow . . . . . . . . . . . . . . . . . . . . . . 10 67 4.1. Peer Discovery State . . . . . . . . . . . . . . . . . . 11 68 4.2. Session Initialization State . . . . . . . . . . . . . . 11 69 4.3. In-Session State . . . . . . . . . . . . . . . . . . . . 12 70 4.3.1. Heartbeats . . . . . . . . . . . . . . . . . . . . . 12 71 4.4. Session Termination State . . . . . . . . . . . . . . . . 13 72 4.5. Session Reset state . . . . . . . . . . . . . . . . . . . 13 73 4.5.1. Unexpected TCP connection termination . . . . . . . . 14 74 5. Transaction Model . . . . . . . . . . . . . . . . . . . . . . 14 75 6. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 6.1. Experiments . . . . . . . . . . . . . . . . . . . . . . . 15 77 7. Scalability . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 8. DLEP Signal and Message Structure . . . . . . . . . . . . . . 16 79 8.1. DLEP Signal Header . . . . . . . . . . . . . . . . . . . 16 80 8.2. DLEP Message Header . . . . . . . . . . . . . . . . . . . 17 81 8.3. DLEP Generic Data Item . . . . . . . . . . . . . . . . . 17 82 9. DLEP Signals and Messages . . . . . . . . . . . . . . . . . . 18 83 9.1. General Processing Rules . . . . . . . . . . . . . . . . 19 84 9.2. Status code processing . . . . . . . . . . . . . . . . . 20 85 9.3. Peer Discovery Signal . . . . . . . . . . . . . . . . . . 21 86 9.4. Peer Offer Signal . . . . . . . . . . . . . . . . . . . . 21 87 9.5. Session Initialization Message . . . . . . . . . . . . . 22 88 9.6. Session Initialization Response Message . . . . . . . . . 22 89 9.7. Session Update Message . . . . . . . . . . . . . . . . . 24 90 9.8. Session Update Response Message . . . . . . . . . . . . . 25 91 9.9. Session Termination Message . . . . . . . . . . . . . . . 25 92 9.10. Session Termination Response Message . . . . . . . . . . 26 93 9.11. Destination Up Message . . . . . . . . . . . . . . . . . 26 94 9.12. Destination Up Response Message . . . . . . . . . . . . . 27 95 9.13. Destination Announce Message . . . . . . . . . . . . . . 28 96 9.14. Destination Announce Response Message . . . . . . . . . . 28 97 9.15. Destination Down Message . . . . . . . . . . . . . . . . 30 98 9.16. Destination Down Response Message . . . . . . . . . . . . 30 99 9.17. Destination Update Message . . . . . . . . . . . . . . . 30 100 9.18. Link Characteristics Request Message . . . . . . . . . . 32 101 9.19. Link Characteristics Response Message . . . . . . . . . . 32 102 9.20. Heartbeat Message . . . . . . . . . . . . . . . . . . . . 33 103 10. DLEP Data Items . . . . . . . . . . . . . . . . . . . . . . . 34 104 10.1. Status . . . . . . . . . . . . . . . . . . . . . . . . . 35 105 10.2. IPv4 Connection Point . . . . . . . . . . . . . . . . . 37 106 10.3. IPv6 Connection Point . . . . . . . . . . . . . . . . . 37 107 10.4. Peer Type . . . . . . . . . . . . . . . . . . . . . . . 39 108 10.5. Heartbeat Interval . . . . . . . . . . . . . . . . . . . 39 109 10.6. Extensions Supported . . . . . . . . . . . . . . . . . . 40 110 10.7. MAC Address . . . . . . . . . . . . . . . . . . . . . . 40 111 10.8. IPv4 Address . . . . . . . . . . . . . . . . . . . . . . 41 112 10.9. IPv6 Address . . . . . . . . . . . . . . . . . . . . . . 42 113 10.10. IPv4 Attached Subnet . . . . . . . . . . . . . . . . . . 43 114 10.11. IPv6 Attached Subnet . . . . . . . . . . . . . . . . . . 44 115 10.12. Maximum Data Rate (Receive) . . . . . . . . . . . . . . 45 116 10.13. Maximum Data Rate (Transmit) . . . . . . . . . . . . . . 45 117 10.14. Current Data Rate (Receive) . . . . . . . . . . . . . . 46 118 10.15. Current Data Rate (Transmit) . . . . . . . . . . . . . . 47 119 10.16. Latency . . . . . . . . . . . . . . . . . . . . . . . . 48 120 10.17. Resources . . . . . . . . . . . . . . . . . . . . . . . 48 121 10.18. Relative Link Quality (Receive) . . . . . . . . . . . . 49 122 10.19. Relative Link Quality (Transmit) . . . . . . . . . . . . 50 123 10.20. Maximum Transmission Unit (MTU) . . . . . . . . . . . . 50 124 11. Security Considerations . . . . . . . . . . . . . . . . . . . 51 125 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 126 12.1. Registrations . . . . . . . . . . . . . . . . . . . . . 52 127 12.2. Signal Type Registration . . . . . . . . . . . . . . . . 52 128 12.3. Message Type Registration . . . . . . . . . . . . . . . 52 129 12.4. DLEP Data Item Registrations . . . . . . . . . . . . . . 53 130 12.5. DLEP Status Code Registrations . . . . . . . . . . . . . 54 131 12.6. DLEP Extensions Registrations . . . . . . . . . . . . . 54 132 12.7. DLEP Well-known Port . . . . . . . . . . . . . . . . . . 55 133 12.8. DLEP IPv4 Link-local Multicast Address . . . . . . . . . 55 134 12.9. DLEP IPv6 Link-local Multicast Address . . . . . . . . . 55 135 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 55 136 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 137 14.1. Normative References . . . . . . . . . . . . . . . . . . 55 138 14.2. Informative References . . . . . . . . . . . . . . . . . 56 139 Appendix A. Discovery Signal Flows . . . . . . . . . . . . . . . 56 140 Appendix B. Peer Level Message Flows . . . . . . . . . . . . . . 57 141 B.1. Session Initialization . . . . . . . . . . . . . . . . . 57 142 B.2. Session Initialization - Refused . . . . . . . . . . . . 57 143 B.3. Router Changes IP Addresses . . . . . . . . . . . . . . . 58 144 B.4. Modem Changes Session-wide Metrics . . . . . . . . . . . 58 145 B.5. Router Terminates Session . . . . . . . . . . . . . . . . 59 146 B.6. Modem Terminates Session . . . . . . . . . . . . . . . . 59 147 B.7. Session Heartbeats . . . . . . . . . . . . . . . . . . . 59 148 B.8. Router Detects a Heartbeat timeout . . . . . . . . . . . 60 149 B.9. Modem Detects a Heartbeat timeout . . . . . . . . . . . . 60 150 Appendix C. Destination Specific Message Flows . . . . . . . . . 61 151 C.1. Common Destination Notification . . . . . . . . . . . . . 61 152 C.2. Multicast Destination Notification . . . . . . . . . . . 62 153 C.3. Link Characteristics Request . . . . . . . . . . . . . . 62 154 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63 156 1. Introduction 158 There exist today a collection of modem devices that control links of 159 variable datarate and quality. Examples of these types of links 160 include line-of-sight (LOS) terrestrial radios, satellite terminals, 161 and broadband modems. Fluctuations in speed and quality of these 162 links can occur due to configuration, or on a moment-to-moment basis, 163 due to physical phenomena like multipath interference, obstructions, 164 rain fade, etc. It is also quite possible that link quality and 165 datarate vary with respect to individual destinations on a link, and 166 with the type of traffic being sent. As an example, consider the 167 case of an IEEE 802.11 access point, serving two associated laptop 168 computers. In this environment, the answer to the question "What is 169 the datarate on the 802.11 link?" is "It depends on which associated 170 laptop we're talking about, and on what kind of traffic is being 171 sent." While the first laptop, being physically close to the access 172 point, may have a datarate of 54Mbps for unicast traffic, the other 173 laptop, being relatively far away, or obstructed by some object, can 174 simultaneously have a datarate of only 32Mbps for unicast. However, 175 for multicast traffic sent from the access point, all traffic is sent 176 at the base transmission rate (which is configurable, but depending 177 on the model of the access point, is usually 24Mbps or less). 179 In addition to utilizing variable datarate links, mobile networks are 180 challenged by the notion that link connectivity will come and go over 181 time, without an effect on a router's interface state (Up or Down). 182 Effectively utilizing a relatively short-lived connection is 183 problematic in IP routed networks, as IP routing protocols tend to 184 rely on interface state and independent timers to maintain network 185 convergence (e.g., HELLO messages and/or recognition of DEAD routing 186 adjacencies). These dynamic connections can be better utilized with 187 an event-driven paradigm, where acquisition of a new neighbor (or 188 loss of an existing one) is signaled, as opposed to a paradigm driven 189 by timers and/or interface state. DLEP not only implements such an 190 event-driven paradigm, but does so over a local (1 hop) TCP session, 191 which guarantees delivery of the event messages. 193 Another complicating factor for mobile networks are the different 194 methods of physically connecting the modem devices to the router. 195 Modems can be deployed as an interface card in a router's chassis, or 196 as a standalone device connected to the router via Ethernet or serial 197 link. In the case of Ethernet attachment, with existing protocols 198 and techniques, routing software cannot be aware of convergence 199 events occurring on the radio link (e.g., acquisition or loss of a 200 potential routing neighbor), nor can the router be aware of the 201 actual capacity of the link. This lack of awareness, along with the 202 variability in datarate, leads to a situation where finding the 203 (current) best route through the network to a given destination is 204 difficult to establish and properly maintain. This is especially 205 true of demand-based access schemes such as Demand Assigned Multiple 206 Access (DAMA) implementations used on some satellite systems. With a 207 DAMA-based system, additional datarate may be available, but will not 208 be used unless the network devices emit traffic at a rate higher than 209 the currently established rate. Increasing the traffic rate does not 210 guarantee additional datarate will be allocated; rather, it may 211 result in data loss and additional retransmissions on the link. 213 Addressing the challenges listed above, the co-authors have developed 214 the Dynamic Link Exchange Protocol, or DLEP. The DLEP protocol runs 215 between a router and its attached modem devices, allowing the modem 216 to communicate link characteristics as they change, and convergence 217 events (acquisition and loss of potential routing destinations). The 218 following diagrams are used to illustrate the scope of DLEP packets. 220 |-------Local Node-------| |-------Remote Node------| 221 | | | | 222 +--------+ +-------+ +-------+ +--------+ 223 | Router |=======| Modem |{~~~~~~~~}| Modem |=======| Router | 224 | | | Device| | Device| | | 225 +--------+ +-------+ +-------+ +--------+ 226 | | | Link | | | 227 |-DLEP--| | Protocol | |-DLEP--| 228 | | | (e.g. | | | 229 | | | 802.11) | | | 231 Figure 1: DLEP Network 233 In Figure 1, when the local modem detects the presence of a remote 234 node, it (the local modem) sends a message to its router via the DLEP 235 protocol. The message consists of an indication of what change has 236 occurred on the link (e.g., presence of a remote node detected), 237 along with a collection of DLEP-defined data items that further 238 describe the change. Upon receipt of the message, the local router 239 may take whatever action it deems appropriate, such as initiating 240 discovery protocols, and/or issuing HELLO messages to converge the 241 network. On a continuing, as-needed basis, the modem devices use 242 DLEP to report any characteristics of the link (datarate, latency, 243 etc.) that have changed. DLEP is independent of the link type and 244 topology supported by the modem. Note that the DLEP protocol is 245 specified to run only on the local link between router and modem. 246 Some over the air signaling may be necessary between the local and 247 remote modem in order to provide some parameters in DLEP messages 248 between the local modem and local router, but DLEP does not specify 249 how such over the air signaling is carried out. Over the air 250 signaling is purely a matter for the modem implementer. 252 Figure 2 shows how DLEP can support a configuration where routers are 253 connected with different link types. In this example, Modem A 254 implements a point-to-point link, and Modem B is connected via a 255 shared medium. In both cases, the DLEP protocol is used to report 256 the characteristics of the link (datarate, latency, etc.) to routers. 257 The modem is also able to use the DLEP session to notify the router 258 when the remote node is lost, shortening the time required to re- 259 converge the network. 261 +--------+ +--------+ 262 +----+ Modem | | Modem +---+ 263 | | Device | | Device | 264 | | Type A | <===== // ======> | Type A | | 265 | +--------+ P-2-P Link +--------+ | 266 +---+----+ +---+----+ 267 | Router | | Router | 268 | | | | 269 +---+----+ +---+----+ 270 | +--------+ +--------+ | 271 +-----+ Modem | | Modem | | 272 | Device | o o o o o o o o | Device +--+ 273 | Type B | o Shared o | Type B | 274 +--------+ o Medium o +--------+ 275 o o 276 o o 277 o o 278 o 279 +--------+ 280 | Modem | 281 | Device | 282 | Type B | 283 +---+----+ 284 | 285 | 287 +---+----+ 288 | Router | 289 | | 290 +--------+ 292 Figure 2: DLEP Network with Multiple Modem Devices 294 1.1. Requirements 296 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 297 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 298 "OPTIONAL" in this document are to be interpreted as described in BCP 299 14, RFC 2119 [RFC2119]. 301 2. Protocol Overview 303 DLEP defines a set of Messages used by modems and their attached 304 routers to communicate events that occur on the physical link(s) 305 managed by the modem: for example, a remote node entering or leaving 306 the network, or that the link has changed. Associated with these 307 Messages are a set of Data Items - information that describes the 308 remote node (e.g., address information), and/or the characteristics 309 of the link to the remote node. Throughout this document, we refer 310 to a modems/routers participating in a DLEP session as 'DLEP 311 Participants', unless a specific distinction (e.g. modem or router) 312 is required. 314 DLEP uses a session-oriented paradigm between the modem device and 315 its associated router. If multiple modem devices are attached to a 316 router (as in Figure 2), or the modem supports multiple connections 317 (via multiple logical or physical interfaces), then separate DLEP 318 sessions exist for each modem or connection. A router and modem form 319 a session by completing the discovery and initialization process. 320 This router-modem session persists unless or until it either (1) 321 times out, based on the absence of DLEP traffic (including 322 heartbeats), or (2) is explicitly torn down by one of the DLEP 323 participants. 325 The router/modem session provides a carrier for information exchange 326 concerning 'destinations' that are available via the modem device. 327 Destinations can be identified by either the router or the modem, and 328 represent a specific, addressable location that can be reached via 329 the link(s) managed by the modem. 331 The DLEP Messages concerning destinations thus become the way for 332 routers and modems to maintain, and notify each other about, an 333 information base representing the physical and logical destinations 334 accessible via the modem device, as well as the link characteristics 335 to those destinations. 337 DLEP identifies destinations by using the MAC address for delivering 338 data traffic. No manipulation or substitution is performed; the MAC 339 address supplied in all destination Messages is used as the 340 Destination MAC address. DLEP therefore requires that MAC addresses 341 are unique within the context of a router-modem session. 343 The reliance on MAC addresses by DLEP forces the requirement that 344 DLEP participants are on a single segment (either physical or 345 logically, via tunneling protocols) at Layer 2. 347 A destination can be either physical or logical. The example of a 348 physical destination would be that of a remote, far-end router 349 attached via the variable-quality network. It should be noted that 350 for physical destinations the MAC address is the address of the far- 351 end router, not the modem. 353 The example of a logical destination is Multicast. Multicast traffic 354 destined for the variable-quality network (the network accessed via 355 the modem) is handled in IP networks by deriving a Layer 2 MAC 356 address based on the Layer 3 address. Leveraging on this scheme, 357 multicast traffic is supported in DLEP simply by treating the derived 358 MAC address as any other destination in the network. 360 To support these logical destinations, one of the DLEP participants 361 (typically, the router) informs the other as to the existence of the 362 logical destination. The modem, once it is aware of the existence of 363 this logical destination, reports link characteristics just as it 364 would for any other destination in the network. The specific 365 algorithms a modem would use to derive metrics on logical 366 destinations are outside the scope of this specification, and is left 367 to specific implementations to decide. 369 While this document represents the best efforts of the working group 370 to be functionally complete, it is recognized that extensions to DLEP 371 will in all likelihood be necessary as more link types are used. 372 Such extensions are defined as additional Messages, Data Items and/or 373 status codes, and associated rules of behavior, that are not defined 374 in this document. DLEP contains a standard mechanism for router and 375 modem implementations to negotiate the available extensions to use on 376 a per-session basis. 378 2.1. Assumptions 380 DLEP specifies UDP multicast for single-hop discovery signaling, and 381 TCP for transport of the Messages. Therefore, DLEP assumes that the 382 modem and router have topologically consistent IP addresses assigned. 383 It is RECOMMENDED that DLEP implementations utilize IPv6 link-local 384 addresses to reduce the administrative burden of address assignment. 385 DLEP relies on the guaranteed- delivery of its Messages between 386 router and modem, once the 1 hop discovery process is complete, 387 hence, the specification of TCP to carry the Messages. Other 388 reliable transports for the protocol are possible, but are outside 389 the scope of this document. 391 DLEP further assumes that security of the implementations (e.g., 392 authentication of stations, encryption of traffic, or both) is dealt 393 with by utilizing Layer 2 security techniques. This reliance on 394 Layer 2 mechanisms secures all DLEP Messages - both the UDP discovery 395 Signals and the TCP control Messages. 397 3. Metrics 399 DLEP includes the ability for the router and modem to communicate 400 metrics that reflect the characteristics (e.g., datarate, latency) of 401 the variable-quality link in use. DLEP does not specify how a given 402 metric value is to be calculated, rather, the protocol assumes that 403 metrics have been calculated by a 'best effort', incorporating all 404 pertinent data that is available to the modem device. 406 DLEP allows for metrics to be sent within two contexts - metrics for 407 a specific destination within the network (e.g., a specific router), 408 and per-session (those that apply to all destinations accessed via 409 the modem). Most metrics can be further subdivided into transmit and 410 receive metrics. In cases where metrics are provided at session 411 level, the router propagates the metrics to all entries in its 412 information base for destinations that are accessed via the modem. 414 DLEP modems announce all metric Data Items that will be reported 415 during the session, and provide default values for those metrics, in 416 the Session Initialization Response Message (Section 9.6). In order 417 to use a metric type that was not included in the Session 418 Initialization Response Message, modem implementations terminate the 419 session with the router (via the Session Terminate Message 420 (Section 9.9)), and establish a new session. 422 A DLEP modem can send metrics both in a session context, via the 423 Session Update Message (Section 9.7), and a specific destination 424 context, via the Destination Update Message (Section 9.17), at any 425 time. The most recently received metric value takes precedence over 426 any earlier value, regardless of context - that is: 428 1. If the router receives metrics in a specific destination context 429 (via the Destination Update Message), then the specific 430 destination is updated with the new metric. 432 2. If the router receives metrics in a session-wide context (via the 433 Session Update Message), then the metrics for all destinations 434 accessed via the modem are updated with the new metric. 436 It is left to implementations to choose sensible default values based 437 on their specific characteristics. Modems having static (non- 438 changing) link metric characteristics can report metrics only once 439 for a given destination (or once on a session-wide basis, if all 440 connections via the modem are of this static nature). 442 In addition to communicating existing metrics about the link, DLEP 443 provides a Message allowing a router to request a different datarate 444 or latency from the modem. This Message is the Link Characteristics 445 Request Message (Section 9.18), and gives the router the ability to 446 deal with requisite increases (or decreases) of allocated datarate/ 447 latency in demand-based schemes in a more deterministic manner. 449 4. DLEP Session Flow 451 All DLEP participants of a session transition through a number of 452 distinct states during the lifetime of a DLEP session: 454 o Peer Discovery 456 o Session Initialization 458 o In-Session 460 o Session Termination 462 o Session Reset 464 Modems, and routers supporting DLEP discovery, transition through all 465 five (5) of the above states. Routers that rely on preconfigured TCP 466 address/port information start in the Session Initialization state. 468 Modems MUST support the Peer Discovery state. 470 4.1. Peer Discovery State 472 In the Peer Discovery state, routers that support DLEP discovery MUST 473 send Peer Discovery Signals (Section 9.3) to initiate modem 474 discovery. 476 The router implementation then waits for a Peer Offer Signal 477 (Section 9.4) response from a potential DLEP modem. While in the 478 Peer Discovery state, Peer Discovery Signals MUST be sent repeatedly 479 by a DLEP router, at regular intervals. The interval MUST be a 480 minimum of one second; it SHOULD be a configurable parameter. Note 481 that this operation (sending Peer Discovery and waiting for Peer 482 Offer) is outside the DLEP Transaction Model (Section 5), as the 483 Transaction Model only describes Messages on a TCP session. 485 Routers MUST use one or more of each of the modem address/port 486 combinations from the Peer Offer Signal or, when no Connection Point 487 Data Items are present, from a priori configuration to establish a 488 new TCP connection to the modem. If more than one modem address/port 489 combinations is provided, router implementations MAY use their own 490 heuristics to determine the order in which they are tried. If a TCP 491 connection cannot be achieved using any of the address/port 492 combinations and the Discovery mechanism is in use, then the router 493 SHOULD resume issuing Peer Discovery Signals. If no Connection Point 494 Data Items are included in the Peer Offer Signal, the router MUST use 495 the source address of the UDP packet containing the Signal as the IP 496 address, and the DLEP well-known port number. 498 In the Peer Discovery state, the modem implementation MUST listen for 499 incoming Peer Discovery Signals on the DLEP well-known IPv6 and/or 500 IPv4 link-local multicast address and port. On receipt of a valid 501 Peer Discovery Signal, it MUST reply with a Peer Offer Signal. 503 Modems MUST be prepared to accept a TCP connection from a router that 504 is not using the Discovery mechanism, i.e. a connection attempt that 505 occurs without a preceding Peer Discovery Signal. 507 Upon establishment of a TCP connection, both modem and router enter 508 the Session Initialization state. It is up to the router 509 implementation if Peer Discovery Signals continue to be sent after 510 the device has transitioned to the Session Initialization state. 511 Modem implementations MUST silently ignore Peer Discovery Signals 512 from a router with which it already has a TCP connection. 514 4.2. Session Initialization State 516 On entering the Session Initialization state, the router MUST send a 517 Session Initialization Message (Section 9.5) to the modem. The 518 router MUST then wait for receipt of a Session Initialization 519 Response Message (Section 9.6) from the modem. Receipt of the 520 Session Initialization Response Message containing a Status Data Item 521 (Section 10.1) with status code set to 0 'Success', see Table 4, 522 indicates that the modem has received and processed the Session 523 Initialization Message, and the router MUST transition to the In- 524 Session state. 526 On entering the Session Initialization state, the modem MUST wait for 527 receipt of a Session Initialization Message from the router. Upon 528 receipt of a Session Initialization Message, the modem MUST send a 529 Session Initialization Response Message, and the session MUST 530 transition to the In-Session state. If the modem receives any 531 Message other than Session Initialization, or it fails to parse the 532 received Message, it MUST NOT send any Message, and MUST terminate 533 the TCP connection and transition to the Session Reset state. 535 DLEP provides an extension negotiation capability to be used in the 536 Session Initialization state, see Section 6. Extensions supported by 537 an implementation MUST be declared to potential DLEP participants 538 using the Extensions Supported Data Item (Section 10.6). Once both 539 DLEP participants have exchanged initialization Messages, an 540 implementation MUST NOT emit any Message, Signal, Data Item or status 541 code associated with an extension that was not specified in the 542 received initialization Message from its peer. 544 4.3. In-Session State 546 In the In-Session state, Messages can flow in both directions between 547 DLEP participants, indicating changes to the session state, the 548 arrival or departure of reachable destinations, or changes of the 549 state of the links to the destinations. 551 The In-Session state is maintained until one of the following 552 conditions occur: 554 o The implementation terminates the session by sending a Session 555 Termination Message (Section 9.9), or, 557 o Its peer terminates the session, indicated by receiving a Session 558 Termination Message. 560 The implementation MUST then transition to the Session Termination 561 state. 563 4.3.1. Heartbeats 564 In order to maintain the In-Session state, periodic Heartbeat 565 Messages (Section 9.20) MUST be exchanged between router and modem. 566 These Messages are intended to keep the session alive, and to verify 567 bidirectional connectivity between the two DLEP participants. 569 Each DLEP participant is responsible for the creation of Heartbeat 570 Messages. 572 Receipt of any valid DLEP Message MUST reset the heartbeat interval 573 timer (i.e., valid DLEP Messages take the place of, and obviate the 574 need for, additional Heartbeat Messages). 576 Implementations MUST allow a minimum of two (2) heartbeat intervals 577 to expire with no Messages from its peer before terminating the 578 session. When terminating the session, a Session Termination Message 579 containing a Status Data Item (Section 10.1) with status code set to 580 132 'Timed Out', see Table 4, MUST be sent, and then the 581 implementation MUST transition to the Session Termination state. 583 4.4. Session Termination State 585 When an implementation enters the Session Termination state after 586 sending a Session Termination Message (Section 9.9) as the result of 587 an invalid Message or error, it MUST wait for a Session Termination 588 Response Message (Section 9.10) from its peer. Senders SHOULD allow 589 four (4) heartbeat intervals to expire before assuming that its peer 590 is unresponsive, and continuing with session termination. Any other 591 Message received while waiting MUST be silently ignored. 593 When the sender of the Session Termination Message receives a Session 594 Termination Response Message from its peer, or times out, it MUST 595 transition to the Session Reset state. 597 When an implementation receives a Session Termination Message from 598 its peer, it enters the Session Termination state and then it MUST 599 immediately send a Session Termination Response and transition to the 600 Session Reset state. 602 4.5. Session Reset state 604 In the Session Reset state the implementation MUST perform the 605 following actions: 607 o Release all resources allocated for the session. 609 o Eliminate all destinations in the information base represented by 610 the session. Destination Down Messages (Section 9.15) MUST NOT be 611 sent. 613 o Terminate the TCP connection. 615 Having completed these actions the implementation SHOULD return to 616 the relevant initial state: Peer Discovery for modems; either Peer 617 Discovery or Session Initialization for routers, depending on 618 configuration. 620 4.5.1. Unexpected TCP connection termination 622 If the TCP connection between DLEP participants is terminated when an 623 implementation is not in the Session Reset state, the implementation 624 MUST immediately transition to the Session Reset state. 626 5. Transaction Model 628 DLEP defines a simple Message transaction model: Only one request per 629 destination may be in progress at a time per session. A Message 630 transaction is considered complete when a response matching a 631 previously issued request is received. If a DLEP participant 632 receives a request for a destination for which there is already an 633 outstanding request, the implementation MUST terminate the session by 634 issuing a Session Termination Message (Section 9.9) containing a 635 Status Data Item (Section 10.1) with status code set to 129 636 'Unexpected Message', see Table 4, and transition to the Session 637 Termination state. There is no restriction to the total number of 638 Message transactions in progress at a time, as long as each 639 transaction refers to a different destination. 641 It should be noted that some requests may take a considerable amount 642 of time for some DLEP participants to complete, for example a modem 643 handling a multicast destination up request may have to perform a 644 complex network reconfiguration. A sending implementation MUST be 645 able to handle such long running transactions gracefully. 647 Additionally, only one session request, e.g. a Session Initialization 648 Message (Section 9.5), may be in progress at a time per session. As 649 above, a session transaction is considered complete when a response 650 matching a previously issued request is received. If a DLEP 651 participant receives a session request while there is already a 652 session request in progress, it MUST terminate the session by issuing 653 a Session Termination Message containing a Status Data Item with 654 status code set to 129 'Unexpected Message', and transition to the 655 Session Termination state. Only the Session Termination Message may 656 be issued when a session transaction is in progress. Heartbeat 657 Messages (Section 9.20) MUST NOT be considered part of a session 658 transaction. 660 DLEP transactions do not time out and are not cancellable. An 661 implementation can detect if its peer has failed in some way by use 662 of the session heartbeat mechanism during the In-Session state, see 663 Section 4.3. 665 6. Extensions 667 Extensions MUST be negotiated on a per-session basis during session 668 initialization via the Extensions Supported mechanism. 669 Implementations are not required to support any extension in order to 670 be considered DLEP compliant. An extension document, describing the 671 operation of a credit windowing scheme for flow control, is described 672 in [CREDIT]. 674 If interoperable protocol extensions are required, they will need to 675 be standardized either as an update to this document, or as an 676 additional stand-alone specification. The requests for IANA- 677 controlled registries in this document contain sufficient Reserved 678 space for DLEP Signals, Messages, Data Items and status codes to 679 accommodate future extensions to the protocol. 681 As multiple protocol extensions MAY be announced during session 682 initialization, authors of protocol extensions need to consider the 683 interaction of their extension with other published extensions, and 684 specify any incompatibilities. 686 6.1. Experiments 688 This document requests Private Use numbering space in the DLEP 689 Signal, Message, Data Item and status code registries for 690 experimental extensions. The intent is to allow for experimentation 691 with new Signals, Messages, Data Items, and/or status codes, while 692 still retaining the documented DLEP behavior. 694 Use of the Private Use Signals, Messages, Data Items, status codes, 695 or behaviors MUST be announced as DLEP Extensions, during session 696 initialization, using extension identifiers from the Private Use 697 space in the Extensions Supported registry (Table 5), with a value 698 agreed upon (a priori) between the participants. DLEP extensions 699 using the Private Use numbering space are commonly referred to as 700 Experiments. 702 Multiple experiments MAY be announced in the Session Initialization 703 Messages. However, use of multiple experiments in a single session 704 could lead to interoperability issues or unexpected results (e.g., 705 clashes of experimental Signals, Messages, Data Items and/or status 706 code types), and is therefore discouraged. It is left to 707 implementations to determine the correct processing path (e.g., a 708 decision on whether to terminate the session, or to establish a 709 precedence of the conflicting definitions) if such conflicts arise. 711 7. Scalability 713 The protocol is intended to support thousands of destinations on a 714 given modem/router pair. At large scale, implementations SHOULD 715 consider employing techniques to prevent flooding its peer with a 716 large number of Messages in a short time. It is RECOMMENDED that 717 implementations consider a dampening algorithm to prevent a flapping 718 device from generating a large number of Destination Up/Destination 719 Down Messages, for example. 721 Implementations SHOULD also consider techniques such as a hysteresis 722 to lessen the impact of rapid, minor fluctuations in link quality. 723 The specific algorithms to be used for handling flapping destinations 724 and minor changes in link quality are outside the scope of this 725 specification. 727 8. DLEP Signal and Message Structure 729 DLEP defines two protocol units used in two different ways: Signals 730 and Messages. Signals are only used in the Discovery mechanism and 731 are carried in UDP datagrams. Messages are used bi-directionally 732 over a TCP connection between the participants, in the Session 733 Initialization, In-Session and Session Termination states. 735 Both Signals and Messages consist of a Header followed by an 736 unordered list of Data Items. Headers consist of Type and Length 737 information, while Data Items are encoded as TLV (Type-Length-Value) 738 structures. In this document, the Data Items following a Signal or 739 Message Header are described as being 'contained in' the Signal or 740 Message. 742 There is no restriction on the order of Data Items following a 743 Header, and the acceptability of duplicate Data Items is defined by 744 the definition of the Signal or Message declared by the type in the 745 Header. 747 All integers in Header fields and values MUST be in network byte- 748 order. 750 8.1. DLEP Signal Header 752 The DLEP Signal Header contains the following fields: 754 0 1 2 3 755 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 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | 'D' | 'L' | 'E' | 'P' | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Signal Type | Length | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 Figure 3: DLEP Signal Header 765 "DLEP": Every Signal MUST start with the characters: U+0044, U+004C, 766 U+0045, U+0050. 768 Signal Type: A 16-bit unsigned integer containing one of the DLEP 769 Signal Type values defined in this document. 771 Length: The length in octets, expressed as a 16-bit unsigned 772 integer, of all of the DLEP Data Items contained in this Signal. 773 This length MUST NOT include the length of the Signal Header 774 itself. 776 The DLEP Signal Header is immediately followed by zero or more DLEP 777 Data Items, encoded in TLVs, as defined in this document. 779 8.2. DLEP Message Header 781 The DLEP Message Header contains the following fields: 783 0 1 2 3 784 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 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | Message Type | Length | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 Figure 4: DLEP Message Header 791 Message Type: A 16-bit unsigned integer containing one of the DLEP 792 Message Type values defined in this document. 794 Length: The length in octets, expressed as a 16-bit unsigned 795 integer, of all of the DLEP Data Items contained in this Message. 796 This length MUST NOT include the length of the Message Header 797 itself. 799 The DLEP Message Header is immediately followed by zero or more DLEP 800 Data Items, encoded in TLVs, as defined in this document. 802 8.3. DLEP Generic Data Item 804 All DLEP Data Items contain the following fields: 806 0 1 2 3 807 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 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | Data Item Type | Length | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | Value... : 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 Figure 5: DLEP Generic Data Item 816 Data Item Type: A 16-bit unsigned integer field specifying the type 817 of Data Item being sent. 819 Length: The length in octets, expressed as a 16-bit unsigned 820 integer, of the Value field of the Data Item. This length MUST 821 NOT include the length of the Data Item Type and Length fields. 823 Value: A field of octets, which contains data specific to a 824 particular Data Item. 826 9. DLEP Signals and Messages 828 Following is the set of core Signals and Messages that MUST be 829 recognized by a DLEP compliant implementation. As mentioned before, 830 not all Messages may be used during a session, but an implementation 831 MUST correctly process these Signals and Messages when received. 833 The core DLEP Signals are: 835 +--------------+-----------------------------------------+ 836 | Type Code | Description | 837 +--------------+-----------------------------------------+ 838 | 0 | Reserved | 839 | 1 | Peer Discovery Signal (Section 9.3) | 840 | 2 | Peer Offer Signal (Section 9.4) | 841 | 3-65519 | Reserved for future extensions | 842 | 65520-65534 | Private Use. Available for experiments | 843 | 65535 | Reserved | 844 +--------------+-----------------------------------------+ 846 Table 1: DLEP Signal types 848 The core DLEP Messages are: 850 +-------------------+-----------------------------------------------+ 851 | Type Code | Description | 852 +-------------------+-----------------------------------------------+ 853 | 0 | Reserved | 854 | 1 | Session Initialization Message (Section 9.5) | 855 | 2 | Session Initialization Response Message | 856 | | (Section 9.6) | 857 | 3 | Session Update Message (Section 9.7) | 858 | 4 | Session Update Response Message (Section 9.8) | 859 | 5 | Session Termination Message (Section 9.9) | 860 | 6 | Session Termination Response Message (Section | 861 | | 9.10) | 862 | 7 | Destination Up Message (Section 9.11) | 863 | 8 | Destination Up Response Message (Section | 864 | | 9.12) | 865 | 9 | Destination Announce Message (Section 9.13) | 866 | 10 | Destination Announce Response Message | 867 | | (Section 9.14) | 868 | 11 | Destination Down Message (Section 9.15) | 869 | 12 | Destination Down Response Message (Section | 870 | | 9.16) | 871 | 13 | Destination Update Message (Section 9.17) | 872 | 14 | Link Characteristics Request Message (Section | 873 | | 9.18) | 874 | 15 | Link Characteristics Response Message | 875 | | (Section 9.19) | 876 | 16 | Heartbeat Message (Section 9.20) | 877 | 17-65519 | Reserved for future extensions | 878 | 65520-65534 | Private Use. Available for experiments | 879 | 65535 | Reserved | 880 +-------------------+-----------------------------------------------+ 882 Table 2: DLEP Message types 884 9.1. General Processing Rules 886 If an unrecognized, or unexpected Signal is received, or a received 887 Signal contains unrecognized, invalid, or disallowed duplicate Data 888 Items, the receiving implementation MUST ignore the Signal. 890 If an unrecognized Message is received, the receiving implementation 891 MUST issue a Session Termination Message (Section 9.9) containing a 892 Status Data Item (Section 10.1) with status code set to 128 'Unknown 893 Message', see Table 4, and transition to the Session Termination 894 state. 896 If an unexpected Message is received, the receiving implementation 897 MUST issue a Session Termination Message containing a Status Data 898 Item with status code set to 129 'Unexpected Message', and transition 899 to the Session Termination state. 901 If a received Message contains unrecognized, invalid, or disallowed 902 duplicate Data Items, the receiving implementation MUST issue a 903 Session Termination Message containing a Status Data Item with status 904 code set to 130 'Invalid Data', and transition to the Session 905 Termination state. 907 Prior to the exchange of Destination Up (Section 9.11) and 908 Destination Up Response (Section 9.12) Messages, or Destination 909 Announce (Section 9.13) and Destination Announce Response 910 (Section 9.14) Messages, no Messages concerning a destination may be 911 sent. An implementation receiving any Message with such an 912 unannounced destination MUST terminate the session by issuing a 913 Session Termination Message containing a Status Data Item with status 914 code set to 131 'Invalid Destination', and transition to the Session 915 Termination state. 917 After exchanging Destination Down (Section 9.15) and Destination Down 918 Response (Section 9.16) Messages, no Messages concerning a 919 destination may be a sent until a new Destination Up or Destination 920 Announce Message is sent. An implementation receiving a Message 921 about a destination previously announced as 'down' MUST terminate the 922 session by issuing a Session Termination Message with a Status Data 923 Item with status code set to 131 'Invalid Destination', and 924 transition to the Session Termination state. 926 9.2. Status code processing 928 The behaviour of a DLEP participant receiving a Message containing a 929 Status Data Item (Section 10.1) is defined by the failure mode 930 associated with the value of the status code field, see Table 4. All 931 status code values less than 100 have a failure mode of 'Continue', 932 all other status codes have a failure mode of 'Terminate'. 934 A DLEP participant receiving any Message apart from Session 935 Termination Message (Section 9.9) containing a Status Data Item with 936 a status code value with failure mode 'Terminate' MUST immediately 937 issue a Session Termination Message containing an identical Status 938 Data Item, and then transition to the Session Termination state. 940 A DLEP participant receiving a Message containing a Status Data Item 941 with a status code value with failure mode 'Continue' can continue 942 normal operation of the session. 944 9.3. Peer Discovery Signal 946 A Peer Discovery Signal SHOULD be sent by a DLEP router to discover 947 DLEP modems in the network Section 4.1. 949 A Peer Discovery Signal MUST be encoded within a UDP packet. The 950 destination MUST be set to the DLEP well-known address and port 951 number. For routers supporting both IPv4 and IPv6 DLEP operation, it 952 is RECOMMENDED that IPv6 be selected as the transport. The source IP 953 address MUST be set to the router IP address associated with the DLEP 954 interface. There is no DLEP-specific restriction on source port. 956 To construct a Peer Discovery Signal, the Signal Type value in the 957 Signal Header is set to 1, from Table 1. 959 The Peer Discovery Signal MAY contain a Peer Type Data Item 960 (Section 10.4). 962 9.4. Peer Offer Signal 964 A Peer Offer Signal MUST be sent by a DLEP modem in response to a 965 properly formatted and addressed Peer Discovery Signal (Section 9.3). 967 A Peer Offer Signal MUST be encoded within a UDP packet. The IP 968 destination MUST be set to the IP address and port number received in 969 the corresponding Peer Discovery Signal. The source IP address MUST 970 be set to the modem's IP address associated with the DLEP interface. 971 The source port number MUST be set to the DLEP well-known port 972 number. The Peer Offer Signal completes the discovery process 973 Section 4.1. 975 To construct a Peer Offer Signal, the Signal Type value in the Signal 976 Header is set to 2, from Table 1. 978 The Peer Offer Signal MAY contain a Peer Type Data Item 979 (Section 10.4). 981 The Peer Offer Signal MAY contain one or more of any of the following 982 Data Items, with different values: 984 o IPv4 Connection Point (Section 10.2) 986 o IPv6 Connection Point (Section 10.3) 988 The IP Connection Point Data Items indicate the unicast address the 989 router MUST use when connecting the DLEP TCP session. 991 9.5. Session Initialization Message 993 A Session Initialization Message MUST be sent by a DLEP router as the 994 first Message of the DLEP TCP session. It is sent by the router 995 after a TCP connect to an address/port combination that was obtained 996 either via receipt of a Peer Offer, or from a priori configuration. 998 To construct a Session Initialization Message, the Message Type value 999 in the Message Header is set to 1, from Table 2. 1001 The Session Initialization Message MUST contain a Heartbeat Interval 1002 Data Item (Section 10.5). 1004 The Session Initialization Message MAY contain one of each of the 1005 following Data Items: 1007 o Peer Type (Section 10.4) 1009 o Extensions Supported (Section 10.6) 1011 If any optional extensions are supported by the implementation, they 1012 MUST be enumerated in the Extensions Supported Data Item. If an 1013 Extensions Supported Data Item does not exist in a Session 1014 Initialization Message, the modem MUST conclude that there is no 1015 support for extensions in the router. 1017 DLEP Heartbeats are not fully established until receipt of the 1018 Session Initialization Response Message (Section 9.6), and therefore 1019 implementations MUST use their own timeout and retry heuristics for 1020 this Message. 1022 As an exception to the general rule governing an implementation 1023 receiving an unrecognized Data Item in a Message, see Section 9.1, if 1024 a Session Initialization Message contains one or more Extension 1025 Supported Data Items announcing support for extensions that the 1026 implementation does not recognize, then the implementation MAY ignore 1027 Data Items it does not recognize. 1029 9.6. Session Initialization Response Message 1031 A Session Initialization Response Message MUST be sent in response to 1032 a received Session Initialization Message (Section 9.5). 1034 To construct a Session Initialization Response Message, the Message 1035 Type value in the Message Header is set to 2, from Table 2. 1037 The Session Initialization Response Message MUST contain one of each 1038 of the following Data Items: 1040 o Status (Section 10.1) 1042 o Heartbeat Interval (Section 10.5) 1044 o Maximum Data Rate (Receive) (Section 10.12) 1046 o Maximum Data Rate (Transmit) (Section 10.13) 1048 o Current Data Rate (Receive) (Section 10.14) 1050 o Current Data Rate (Transmit) (Section 10.15) 1052 o Latency (Section 10.16) 1054 The Session Initialization Response Message MUST contain one of each 1055 of the following Data Items, if the Data Item will be used during the 1056 lifetime of the session: 1058 o Resources (Section 10.17) 1060 o Relative Link Quality (Receive) (Section 10.18) 1062 o Relative Link Quality (Transmit) (Section 10.19) 1064 o Maximum Transmission Unit (MTU) (Section 10.20) 1066 The Session Initialization Response Message MAY contain one of each 1067 of the following Data Items: 1069 o Peer Type (Section 10.4) 1071 o Extensions Supported (Section 10.6) 1073 The Session Initialization Response Message completes the DLEP 1074 session establishment; the modem should transition to the In-Session 1075 state when the Message is sent, and the router should transition to 1076 the In-Session state upon receipt of an acceptable Session 1077 Initialization Response Message. 1079 All supported metric Data Items MUST be included in the Session 1080 Initialization Response Message, with default values to be used on a 1081 session-wide basis. This can be viewed as the modem 'declaring' all 1082 supported metrics at DLEP session initialization. Receipt of any 1083 further DLEP Message containing a metric Data Item not included in 1084 the Session Initialization Response Message MUST be treated as an 1085 error, resulting in the termination of the DLEP session between 1086 router and modem. 1088 If any optional extensions are supported by the modem, they MUST be 1089 enumerated in the Extensions Supported Data Item. If an Extensions 1090 Supported Data Item does not exist in a Session Initialization 1091 Response Message, the router MUST conclude that there is no support 1092 for extensions in the modem. 1094 After the Session Initialization/Session Initialization Response 1095 Messages have been successfully exchanged, implementations MUST only 1096 use extensions that are supported by both DLEP participants 1097 Section 4.2. 1099 9.7. Session Update Message 1101 A Session Update Message MAY be sent by a DLEP participant to 1102 indicate local Layer 3 address changes, or metric changes on a 1103 session-wide basis. 1105 To construct a Session Update Message, the Message Type value in the 1106 Message Header is set to 3, from Table 2. 1108 The Session Update Message MAY contain one of each of the following 1109 Data Items: 1111 o Maximum Data Rate (Receive) (Section 10.12) 1113 o Maximum Data Rate (Transmit) (Section 10.13) 1115 o Current Data Rate (Receive) (Section 10.14) 1117 o Current Data Rate (Transmit) (Section 10.15) 1119 o Latency (Section 10.16) 1121 The Session Update Message MAY contain one of each of the following 1122 Data Items, if the Data Item is in use by the session: 1124 o Resources (Section 10.17) 1126 o Relative Link Quality (Receive) (Section 10.18) 1128 o Relative Link Quality (Transmit) (Section 10.19) 1130 o Maximum Transmission Unit (MTU) (Section 10.20) 1132 The Session Update Message MAY contain one or more of each of the 1133 following Data Items, with different values: 1135 o IPv4 Address (Section 10.8) 1136 o IPv6 Address (Section 10.9) 1138 If metrics are supplied with the Session Update Message (e.g., 1139 Maximum Data Rate), these metrics are considered to be session-wide, 1140 and therefore MUST be applied to all destinations in the information 1141 base associated with the DLEP session. This includes destinations 1142 for which metrics may have been stored based on received Destination 1143 Update messages. 1145 It should be noted that Session Update Messages can be sent by both 1146 routers and modems. For example, addition of an IPv4 address to the 1147 router MAY prompt a Session Update Message to its attached modems. 1148 Also, for example, a modem that changes its Maximum Data Rate 1149 (Receive) for all destinations MAY reflect that change via a Session 1150 Update Message to its attached router(s). 1152 Concerning Layer 3 addresses: If the modem is capable of 1153 understanding and forwarding this information (via proprietary 1154 mechanisms), the address update would prompt any remote DLEP modems 1155 (DLEP-enabled modems in a remote node) to issue a Destination Update 1156 Message (Section 9.17) to their local routers with the new (or 1157 deleted) addresses. Modems that do not track Layer 3 addresses 1158 SHOULD silently ignore Address Data Items. 1160 9.8. Session Update Response Message 1162 A Session Update Response Message MUST be sent by a DLEP participant 1163 when a Session Update Message (Section 9.7) is received. 1165 To construct a Session Update Response Message, the Message Type 1166 value in the Message Header is set to 4, from Table 2. 1168 The Session Update Response Message MUST contain a Status Data Item 1169 (Section 10.1). 1171 9.9. Session Termination Message 1173 A Session Termination Message MUST be sent by a DLEP participant when 1174 the DLEP session needs to be terminated. 1176 To construct a Session Termination Message, the Message Type value in 1177 the Message Header is set to 5, from Table 2. 1179 The Session Termination Message MUST contain Status Data Item 1180 (Section 10.1). 1182 It should be noted that Session Termination Messages can be sent by 1183 both routers and modems. 1185 9.10. Session Termination Response Message 1187 A Session Termination Response Message MUST be sent by a DLEP 1188 participant when a Session Termination Message (Section 9.9) is 1189 received. 1191 To construct a Session Termination Response Message, the Message Type 1192 value in the Message Header is set to 6, from Table 2. 1194 There are no valid Data Items for the Session Termination Response 1195 Message. 1197 Receipt of a Session Termination Response Message completes the tear- 1198 down of the DLEP session Section 4.4. 1200 9.11. Destination Up Message 1202 Destination Up Messages MAY be sent by a modem to inform its attached 1203 router of the presence of a new reachable destination. 1205 To construct a Destination Up Message, the Message Type value in the 1206 Message Header is set to 7, from Table 2. 1208 The Destination Up Message MUST contain a MAC Address Data Item 1209 (Section 10.7). 1211 The Destination Up Message SHOULD contain one or more of each of the 1212 following Data Items, with different values: 1214 o IPv4 Address (Section 10.8) 1216 o IPv6 Address (Section 10.9) 1218 The Destination Up Message MAY contain one of each of the following 1219 Data Items: 1221 o Maximum Data Rate (Receive) (Section 10.12) 1223 o Maximum Data Rate (Transmit) (Section 10.13) 1225 o Current Data Rate (Receive) (Section 10.14) 1227 o Current Data Rate (Transmit) (Section 10.15) 1229 o Latency (Section 10.16) 1231 The Destination Up Message MAY contain one of each of the following 1232 Data Items, if the Data Item is in use by the session: 1234 o Resources (Section 10.17) 1236 o Relative Link Quality (Receive) (Section 10.18) 1238 o Relative Link Quality (Transmit) (Section 10.19) 1240 o Maximum Transmission Unit (MTU) (Section 10.20) 1242 The Destination Up Message MAY contain one or more of each of the 1243 following Data Items, with different values: 1245 o IPv4 Attached Subnet (Section 10.10) 1247 o IPv6 Attached Subnet (Section 10.11) 1249 A router receiving a Destination Up Message allocates the necessary 1250 resources, creating an entry in the information base with the 1251 specifics (MAC Address, Latency, Data Rate, etc.) of the destination. 1252 The information about this destination will persist in the router's 1253 information base until a Destination Down Message (Section 9.15) is 1254 received, indicating that the modem has lost contact with the remote 1255 node, or the implementation transitions to the Session Termination 1256 state. 1258 9.12. Destination Up Response Message 1260 A router MUST send a Destination Up Response Message when a 1261 Destination Up Message (Section 9.11) is received. 1263 To construct a Destination Up Response Message, the Message Type 1264 value in the Message Header is set to 8, from Table 2. 1266 The Destination Up Response Message MUST contain one of each of the 1267 following Data Items: 1269 o MAC Address (Section 10.7) 1271 o Status (Section 10.1) 1273 A router that wishes to receive further information concerning the 1274 destination identified in the corresponding Destination Up Message 1275 MUST set the status code of the included Status Data Item to 0 1276 'Success', see Table 4. 1278 If the router has no interest in the destination identified in the 1279 corresponding Destination Up Message, then it MAY set the status code 1280 of the included Status Data Item to 1 'Not Interested'. 1282 A modem receiving a Destination Up Response Message containing a 1283 Status Data Item with status code of any value other than 0 'Success' 1284 MUST NOT send further Destination messages about the destination, 1285 e.g. Destination Down (Section 9.15) or Destination Update 1286 (Section 9.17) with the same MAC address. 1288 9.13. Destination Announce Message 1290 Usually a modem will discover the presence of one or more remote 1291 router/modem pairs and announce each destination's arrival by sending 1292 a corresponding Destination Up Message (Section 9.11) to the router. 1293 However, there may be times when a router wishes to express an 1294 interest in a destination that has yet to be announced, typically a 1295 multicast destination. Destination Announce Messages MAY be sent by 1296 a router to announce such an interest. 1298 A Destination Announce Message MAY also be sent by a router to 1299 request information concerning a destination in which it has 1300 previously declined interest, via the 1 'Not Interested' status code 1301 in a Destination Up Response Message (Section 9.12), see Table 4, or 1302 declared as 'down', via the Destination Down Message (Section 9.15). 1304 To construct a Destination Announce Message, the Message Type value 1305 in the Message Header is set to 9, from Table 2. 1307 The Destination Announce Message MUST contain a MAC Address Data Item 1308 (Section 10.7). 1310 The Destination Announce Message MAY contain zero or more of the 1311 following Data Items, with different values: 1313 o IPv4 Address (Section 10.8) 1315 o IPv6 Address (Section 10.9) 1317 One of the advantages of implementing DLEP is to leverage the modem's 1318 knowledge of the links between remote destinations allowing routers 1319 to avoid using probed neighbor discovery techniques, therefore modem 1320 implementations SHOULD announce available destinations via the 1321 Destination Up Message, rather than relying on Destination Announce 1322 Messages. 1324 9.14. Destination Announce Response Message 1326 A modem MUST send a Destination Announce Response Message when a 1327 Destination Announce Message (Section 9.13) is received. 1329 To construct a Destination Announce Response Message, the Message 1330 Type value in the Message Header is set to 10, from Table 2. 1332 The Destination Announce Response Message MUST contain one of each of 1333 the following Data Items: 1335 o MAC Address (Section 10.7) 1337 o Status (Section 10.1) 1339 The Destination Announce Response Message MAY contain one of each of 1340 the following Data Items: 1342 o Maximum Data Rate (Receive) (Section 10.12) 1344 o Maximum Data Rate (Transmit) (Section 10.13) 1346 o Current Data Rate (Receive) (Section 10.14) 1348 o Current Data Rate (Transmit) (Section 10.15) 1350 o Latency (Section 10.16) 1352 The Destination Announce Response Message MAY contain one of each of 1353 the following Data Items, if the Data Item is in use by the session: 1355 o Resources (Section 10.17) 1357 o Relative Link Quality (Receive) (Section 10.18) 1359 o Relative Link Quality (Transmit) (Section 10.19) 1361 o Maximum Transmission Unit (MTU) (Section 10.20) 1363 If a modem is unable to report information immediately about the 1364 requested information, if the destination is not currently reachable, 1365 for example, the status code in the Status Data Item MUST be set to 2 1366 'Request Denied', see Table 4. 1368 After sending a Destination Announce Response Message containing a 1369 Status Data Item with status code of 0 'Success', a modem then 1370 announces changes to the link to the destination via Destination 1371 Update Messages. 1373 When a successful Destination Announce Response Message is received, 1374 the router should add knowledge of the available destination to its 1375 information base. 1377 9.15. Destination Down Message 1379 A modem MUST send a Destination Down Message to report when a 1380 destination (a remote node or a multicast group) is no longer 1381 reachable. 1383 A router MAY send a Destination Down Message to report when it no 1384 longer requires information concerning a destination. 1386 To construct a Destination Down Message, the Message Type value in 1387 the Message Header is set to 11, from Table 2. 1389 The Destination Down Message MUST contain a MAC Address Data Item 1390 (Section 10.7). 1392 It should be noted that both modem and router may send a Destination 1393 Down Message to their peer, regardless of which participant initially 1394 indicated the destination to be 'up'. 1396 9.16. Destination Down Response Message 1398 A Destination Down Response MUST be sent by the recipient of a 1399 Destination Down Message (Section 9.15) to confirm that the relevant 1400 data concerning the destination has been removed from the information 1401 base. 1403 To construct a Destination Down Response Message, the Message Type 1404 value in the Message Header is set to 12, from Table 2. 1406 The Destination Down Response Message MUST contain one of each of the 1407 following Data Items: 1409 o MAC Address (Section 10.7) 1411 o Status (Section 10.1) 1413 9.17. Destination Update Message 1415 A modem SHOULD send the Destination Update Message when it detects 1416 some change in the information base for a given destination (remote 1417 node or multicast group). Some examples of changes that would prompt 1418 a Destination Update Message are: 1420 o Change in link metrics (e.g., Data Rates) 1422 o Layer 3 addressing change 1423 To construct a Destination Update Message, the Message Type value in 1424 the Message Header is set to 13, from Table 2. 1426 The Destination Update Message MUST contain a MAC Address Data Item 1427 (Section 10.7). 1429 The Destination Update Message MAY contain one of each of the 1430 following Data Items: 1432 o Maximum Data Rate (Receive) (Section 10.12) 1434 o Maximum Data Rate (Transmit) (Section 10.13) 1436 o Current Data Rate (Receive) (Section 10.14) 1438 o Current Data Rate (Transmit) (Section 10.15) 1440 o Latency (Section 10.16) 1442 The Destination Update Message MAY contain one of each of the 1443 following Data Items, if the Data Item is in use by the session: 1445 o Resources (Section 10.17) 1447 o Relative Link Quality (Receive) (Section 10.18) 1449 o Relative Link Quality (Transmit) (Section 10.19) 1451 o Maximum Transmission Unit (MTU) (Section 10.20) 1453 The Destination Update Message MAY contain one or more of each of the 1454 following Data Items, with different values: 1456 o IPv4 Address (Section 10.8) 1458 o IPv6 Address (Section 10.9) 1460 o IPv4 Attached Subnet (Section 10.10) 1462 o IPv6 Attached Subnet (Section 10.11) 1464 If metrics are supplied with the Message (e.g., Resources), these 1465 metrics are MUST be applied to all destinations identified in the 1466 Message. Note that this may overwrite metrics provided in a 1467 previously received Session or Destination Up Messages. 1469 It should be noted that this Message has no corresponding response. 1471 9.18. Link Characteristics Request Message 1473 The Link Characteristics Request Message MAY be sent by a router to 1474 request that the modem initiate changes for specific characteristics 1475 of the link. The request can reference either a real destination 1476 (e.g., a remote node), or a logical destination (e.g., a multicast 1477 group) within the network. 1479 To construct a Link Characteristics Request Message, the Message Type 1480 value in the Message Header is set to 14, from Table 2. 1482 The Link Characteristics Request Message MUST contain one of the 1483 following Data Items: 1485 o MAC Address (Section 10.7) 1487 The Link Characteristics Request Message MUST contain at least one of 1488 each of the following Data Items: 1490 o Current Data Rate (Receive) (Section 10.14) 1492 o Current Data Rate (Transmit) (Section 10.15) 1494 o Latency (Section 10.16) 1496 The Link Characteristics Request Message MAY contain either a Current 1497 Data Rate (CDRR or CDRT) Data Item to request a different datarate 1498 than is currently allocated, a Latency Data Item to request that 1499 traffic delay on the link not exceed the specified value, or both. 1501 The router sending a Link Characteristics Request Message should be 1502 aware that a request may take an extended period of time to complete. 1504 9.19. Link Characteristics Response Message 1506 A modem MUST send a Link Characteristics Response Message when a Link 1507 Characteristics Request Message (Section 9.18) is received. 1509 To construct a Link Characteristics Response Message, the Message 1510 Type value in the Message Header is set to 15, from Table 2. 1512 The Link Characteristics Response Message MUST contain one of each of 1513 the following Data Items: 1515 o MAC Address (Section 10.7) 1517 o Status (Section 10.1) 1518 The Link Characteristics Response Message SHOULD contain one of each 1519 of the following Data Items: 1521 o Maximum Data Rate (Receive) (Section 10.12) 1523 o Maximum Data Rate (Transmit) (Section 10.13) 1525 o Current Data Rate (Receive) (Section 10.14) 1527 o Current Data Rate (Transmit) (Section 10.15) 1529 o Latency (Section 10.16) 1531 The Link Characteristics Response Message MAY contain one of each of 1532 the following Data Items, if the Data Item is in use by the session: 1534 o Resources (Section 10.17) 1536 o Relative Link Quality (Receive) (Section 10.18) 1538 o Relative Link Quality (Transmit) (Section 10.19) 1540 o Maximum Transmission Unit (MTU) (Section 10.20) 1542 The Link Characteristics Response Message MUST contain a complete set 1543 of metric Data Items, referencing all metrics declared in the Session 1544 Initialization Response Message (Section 9.6). The values in the 1545 metric Data Items in the Link Characteristics Response Message MUST 1546 reflect the link characteristics after the request has been 1547 processed. 1549 If an implementation is not able to alter the characteristics of the 1550 link in the manner requested, then the status code of the Status Data 1551 Item MUST be set to 2 'Request Denied', see Table 4. 1553 9.20. Heartbeat Message 1555 A Heartbeat Message MUST be sent by a DLEP participant every N 1556 milliseconds, where N is defined in the Heartbeat Interval Data Item 1557 (Section 10.5) of the Session Initialization Message (Section 9.5) or 1558 Session Initialization Response Message (Section 9.6). 1560 To construct a Heartbeat Message, the Message Type value in the 1561 Message Header is set to 16, from Table 2. 1563 There are no valid Data Items for the Heartbeat Message. 1565 The Message is used by DLEP participants to detect when a DLEP 1566 session peer (either the modem or the router) is no longer 1567 communicating Section 4.3.1. 1569 10. DLEP Data Items 1571 Following is the list of core Data Items that MUST be recognized by a 1572 DLEP compliant implementation. As mentioned before, not all Data 1573 Items need be used during a session, but an implementation MUST 1574 correctly process these Data Items when correctly associated with a 1575 Signal or Message. 1577 The core DLEP Data Items are: 1579 +--------------------+----------------------------------------------+ 1580 | Type Code | Description | 1581 +--------------------+----------------------------------------------+ 1582 | 0 | Reserved | 1583 | 1 | Status (Section 10.1) | 1584 | 2 | IPv4 Connection Point (Section 10.2) | 1585 | 3 | IPv6 Connection Point (Section 10.3) | 1586 | 4 | Peer Type (Section 10.4) | 1587 | 5 | Heartbeat Interval (Section 10.5) | 1588 | 6 | Extensions Supported (Section 10.6) | 1589 | 7 | MAC Address (Section 10.7) | 1590 | 8 | IPv4 Address (Section 10.8) | 1591 | 9 | IPv6 Address (Section 10.9) | 1592 | 10 | IPv4 Attached Subnet (Section 10.10) | 1593 | 11 | IPv6 Attached Subnet (Section 10.11) | 1594 | 12 | Maximum Data Rate (Receive) (MDRR) (Section | 1595 | | 10.12) | 1596 | 13 | Maximum Data Rate (Transmit) (MDRT) (Section | 1597 | | 10.13) | 1598 | 14 | Current Data Rate (Receive) (CDRR) (Section | 1599 | | 10.14) | 1600 | 15 | Current Data Rate (Transmit) (CDRT) (Section | 1601 | | 10.15) | 1602 | 16 | Latency (Section 10.16) | 1603 | 17 | Resources (RES) (Section 10.17) | 1604 | 18 | Relative Link Quality (Receive) (RLQR) | 1605 | | (Section 10.18) | 1606 | 19 | Relative Link Quality (Transmit) (RLQT) | 1607 | | (Section 10.19) | 1608 | 20 | Maximum Transmission Unit (MTU) (Section | 1609 | | 10.20) | 1610 | 21-65407 | Reserved for future extensions | 1611 | 65408-65534 | Private Use. Available for experiments | 1612 | 65535 | Reserved | 1613 +--------------------+----------------------------------------------+ 1615 Table 3: DLEP Data Item types 1617 10.1. Status 1619 For the Session Termination Message (Section 9.9), the Status Data 1620 Item indicates a reason for the termination. For all response 1621 Messages, the Status Data Item is used to indicate the success or 1622 failure of the previously received Message. 1624 The Status Data Item includes an optional Text field that can be used 1625 to provide a textual description of the status. The use of the Text 1626 field is entirely up to the receiving implementation, e.g., it could 1627 be output to a log file or discarded. If no Text field is supplied 1628 with the Status Data Item, the Length field MUST be set to 1. 1630 The Status Data Item contains the following fields: 1632 0 1 2 3 1633 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 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 | Data Item Type | Length | 1636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1637 | Code | Text... : 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 Data Item Type: 1 1642 Length: 1 + Length of text, in octets 1644 Status Code: One of the codes defined in Table 4 below. 1646 Text: UTF-8 encoded string of UNICODE [UNIV8] characters, describing 1647 the cause, used for implementation defined purposes. Since this 1648 field is used for description, implementations SHOULD limit 1649 characters in this field to printable characters. Implementations 1650 receiving this Data Item SHOULD check for printable characters in 1651 the field. 1653 An implementation MUST NOT assume the Text field is NUL-terminated. 1655 +---------+-----------+---------------+-----------------------------+ 1656 | Status | Failure | Description | Reason | 1657 | Code | Mode | | | 1658 +---------+-----------+---------------+-----------------------------+ 1659 | 0 | Continue | Success | The Message was processed | 1660 | | | | successfully. | 1661 | 1 | Continue | Not | The receiver is not | 1662 | | | Interested | interested in this Message | 1663 | | | | subject, e.g. in a | 1664 | | | | Destination Up Response | 1665 | | | | Message (Section 9.12) to | 1666 | | | | indicate no further | 1667 | | | | Messages about the | 1668 | | | | destination. | 1669 | 2 | Continue | Request | The receiver refuses to | 1670 | | | Denied | complete the request. | 1671 | 3-111 | Continue | | Reserved for future | 1672 | | | | extensions. | 1673 | 112-127 | Continue | | Available for experiments. | 1674 | 128 | Terminate | Unknown | The Message was not | 1675 | | | Message | recognized by the | 1676 | | | | implementation. | 1677 | 129 | Terminate | Unexpected | The Message was not | 1678 | | | Message | expected while the device | 1679 | | | | was in the current state, | 1680 | | | | e.g., a Session | 1681 | | | | Initialization Message | 1682 | | | | (Section 9.5) in the In- | 1683 | | | | Session state. | 1684 | 130 | Terminate | Invalid Data | One or more Data Items in | 1685 | | | | the Message are invalid, | 1686 | | | | unexpected or incorrectly | 1687 | | | | duplicated. | 1688 | 131 | Terminate | Invalid | The destination included in | 1689 | | | Destination | the Message does not match | 1690 | | | | a previously announced | 1691 | | | | destination. For example, | 1692 | | | | in the Link Characteristic | 1693 | | | | Response Message (Section | 1694 | | | | 9.19). | 1695 | 132 | Terminate | Timed Out | The session has timed out. | 1696 | 133-239 | Terminate | | Reserved for future | 1697 | | | | extensions. | 1698 | 240-254 | Terminate | | Available for experiments. | 1699 | 255 | Terminate | | Reserved. | 1700 +---------+-----------+---------------+-----------------------------+ 1702 Table 4: DLEP Status Codes 1704 10.2. IPv4 Connection Point 1706 The IPv4 Connection Point Data Item indicates the IPv4 address and, 1707 optionally, the TCP port number on the modem available for 1708 connections. If provided, the router MUST use this information to 1709 initiate the TCP connection to the modem. 1711 The IPv4 Connection Point Data Item contains the following fields: 1713 0 1 2 3 1714 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 1715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1716 | Data Item Type | Length | 1717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1718 | Flags | IPv4 Address... : 1719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1720 : ...cont. | TCP Port Number (optional) | 1721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1723 Data Item Type: 2 1725 Length: 5 (or 7 if TCP Port included) 1727 Flags: Flags field, defined below. 1729 IPv4 Address: The IPv4 address listening on the modem. 1731 TCP Port Number: TCP Port number on the modem. 1733 If the Length field is 7, the port number specified MUST be used to 1734 establish the TCP session. If the TCP Port Number is omitted, i.e. 1735 the Length field is 5, the router MUST use the DLEP well-known port 1736 number (Section 12.7) to establish the TCP connection. 1738 The Flags field is defined as: 1740 0 1 2 3 4 5 6 7 1741 +-+-+-+-+-+-+-+-+ 1742 | Reserved | 1743 +-+-+-+-+-+-+-+-+ 1745 Reserved: MUST be zero. Reserved for future use. 1747 10.3. IPv6 Connection Point 1748 The IPv6 Connection Point Data Item indicates the IPv6 address and, 1749 optionally, the TCP port number on the modem available for 1750 connections. If provided, the router MUST use this information to 1751 initiate the TCP connection to the modem. 1753 The IPv6 Connection Point Data Item contains the following fields: 1755 0 1 2 3 1756 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 1757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1758 | Data Item Type | Length | 1759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1760 | Flags | IPv6 Address : 1761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1762 : IPv6 Address : 1763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1764 : IPv6 Address : 1765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1766 : IPv6 Address : 1767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1768 : ...cont. | TCP Port Number (optional) | 1769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1771 Data Item Type: 3 1773 Length: 17 (or 19 if TCP Port included) 1775 Flags: Flags field, defined below. 1777 IPv6 Address: The IPv6 address listening on the modem. 1779 TCP Port Number: TCP Port number on the modem. 1781 If the Length field is 19, the port number specified MUST be used to 1782 establish the TCP session. If the TCP Port Number is omitted, i.e. 1783 the Length field is 17, the router MUST use the DLEP well-known port 1784 number (Section 12.7) to establish the TCP connection. 1786 The Flags field is defined as: 1788 0 1 2 3 4 5 6 7 1789 +-+-+-+-+-+-+-+-+ 1790 | Reserved | 1791 +-+-+-+-+-+-+-+-+ 1793 Reserved: MUST be zero. Reserved for future use. 1795 10.4. Peer Type 1797 The Peer Type Data Item is used by the router and modem to give 1798 additional information as to its type. The Peer Type is a string and 1799 is envisioned to be used for informational purposes (e.g., as output 1800 in a display command). 1802 The Peer Type Data Item contains the following fields: 1804 0 1 2 3 1805 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 1806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1807 | Data Item Type | Length | 1808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1809 | Peer Type... : 1810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1812 Data Item Type: 4 1814 Length: Length of Peer Type string, in octets. 1816 Peer Type: UTF-8 encoded string of UNICODE [UNIV8] characters. For 1817 example, a satellite modem might set this variable to "Satellite 1818 terminal". Since this Data Item is intended to provide additional 1819 information for display commands, sending implementations SHOULD 1820 limit the data to printable characters, and receiving 1821 implementations SHOULD check the data for printable characters. 1823 An implementation MUST NOT assume the Peer Type field is NUL- 1824 terminated. 1826 10.5. Heartbeat Interval 1828 The Heartbeat Interval Data Item is used to specify a period in 1829 milliseconds for Heartbeat Messages (Section 9.20). 1831 The Heartbeat Interval Data Item contains the following fields: 1833 0 1 2 3 1834 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 1835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1836 | Data Item Type | Length | 1837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1838 | Heartbeat Interval | 1839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1841 Data Item Type: 5 1842 Length: 4 1844 Heartbeat Interval: The interval in milliseconds, expressed as a 1845 32-bit unsigned integer, for Heartbeat Messages. 1846 This value MUST NOT be 0. 1848 10.6. Extensions Supported 1850 The Extensions Supported Data Item is used by the router and modem to 1851 negotiate additional optional functionality they are willing to 1852 support. The Extensions List is a concatenation of the types of each 1853 supported extension, found in the IANA DLEP Extensions repository. 1854 Each Extension Type definition includes which additional Signals and 1855 Data Items are supported. 1857 The Extensions Supported Data Item contains the following fields: 1859 0 1 2 3 1860 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 1861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1862 | Data Item Type | Length | 1863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1864 | Extensions List... 1865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1867 Data Item Type: 6 1869 Length: Length of the extensions list in octets. This is twice (2x) 1870 the number of extensions. 1872 Extension List: A list of extensions supported, identified by their 1873 2-octet value as listed in the extensions registry. 1875 10.7. MAC Address 1877 The MAC Address Data Item contains the address of the destination on 1878 the remote node. 1880 DLEP can support MAC addresses in either EUI-48 or EUI-64 format, 1881 with the restriction that all MAC addresses for a given DLEP session 1882 MUST be in the same format, and MUST be consistent with the MAC 1883 address format of the connected modem (e.g., if the modem is 1884 connected to the router with an EUI-48 MAC, all destination addresses 1885 via that modem MUST be expressed in EUI-48 format). 1887 Examples of a virtual destination would be a multicast MAC address, 1888 or the broadcast MAC (FF:FF:FF:FF:FF:FF). 1890 0 1 2 3 1891 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 1892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1893 | Data Item Type | Length | 1894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1895 | MAC Address : 1896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1897 : MAC Address : 1898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1899 : MAC Address : (if EUI-64 used) | 1900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1902 Data Item Type: 7 1904 Length: 6 for EUI-48 format, or 8 for EUI-64 format 1906 MAC Address: MAC Address of the destination. 1908 10.8. IPv4 Address 1910 When included in Destination Messages, this Data Item contains the 1911 IPv4 address of the destination. When included in the Session Update 1912 Message, this Data Item contains the IPv4 address of the peer. In 1913 either case, the Data Item also contains an indication of whether 1914 this is a new or existing address, or is a deletion of a previously 1915 known address. 1917 The IPv4 Address Data Item contains the following fields: 1919 0 1 2 3 1920 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 1921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1922 | Data Item Type | Length | 1923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1924 | Flags | IPv4 Address : 1925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1926 : ...cont. | 1927 +-+-+-+-+-+-+-+-+ 1929 Data Item Type: 8 1931 Length: 5 1933 Flags: Flags field, defined below. 1935 IPv4 Address: The IPv4 address of the destination or peer. 1937 The Flags field is defined as: 1939 0 1 2 3 4 5 6 7 1940 +-+-+-+-+-+-+-+-+ 1941 | Reserved |A| 1942 +-+-+-+-+-+-+-+-+ 1944 A: Add/Drop flag, indicating whether this is a new or existing 1945 address (1), or a withdrawal of an address (0). 1947 Reserved: MUST be zero. Reserved for future use. 1949 10.9. IPv6 Address 1951 When included in Destination Messages, this Data Item contains the 1952 IPv6 address of the destination. When included in the Session Update 1953 Message, this Data Item contains the IPv6 address of the peer. In 1954 either case, the Data Item also contains an indication of whether 1955 this is a new or existing address, or is a deletion of a previously 1956 known address. 1958 The IPv6 Address Data Item contains the following fields: 1960 0 1 2 3 1961 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 1962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1963 | Data Item Type | Length | 1964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1965 | Flags | IPv6 Address : 1966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1967 : IPv6 Address : 1968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1969 : IPv6 Address : 1970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1971 : IPv6 Address : 1972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1973 : IPv6 Address | 1974 +-+-+-+-+-+-+-+-+ 1976 Data Item Type: 9 1978 Length: 17 1980 Flags: Flags field, defined below. 1982 IPv6 Address: IPv6 Address of the destination or peer. 1984 The Flags field is defined as: 1986 0 1 2 3 4 5 6 7 1987 +-+-+-+-+-+-+-+-+ 1988 | Reserved |A| 1989 +-+-+-+-+-+-+-+-+ 1991 A: Add/Drop flag, indicating whether this is a new or existing 1992 address (1), or a withdrawal of an address (0). 1994 Reserved: MUST be zero. Reserved for future use. 1996 10.10. IPv4 Attached Subnet 1998 The DLEP IPv4 Attached Subnet allows a device to declare that it has 1999 an IPv4 subnet (e.g., a stub network) attached, that it has become 2000 aware of an IPv4 subnet being present at a remote destination, or 2001 that it has become aware of the loss of a subnet at the remote 2002 destination. 2004 The DLEP IPv4 Attached Subnet Data Item contains the following 2005 fields: 2007 0 1 2 3 2008 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 2009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2010 | Data Item Type | Length | 2011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2012 | Flags | IPv4 Attached Subnet : 2013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2014 : ...cont. |Prefix Length | 2015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2017 Data Item Type: 10 2019 Length: 6 2021 Flags: Flags field, defined below. 2023 IPv4 Subnet: The IPv4 subnet reachable at the destination. 2025 Prefix Length: Length of the prefix (0-32) for the IPv4 subnet. A 2026 prefix length outside the specified range MUST be considered as 2027 invalid. 2029 The Flags field is defined as: 2031 0 1 2 3 4 5 6 7 2032 +-+-+-+-+-+-+-+-+ 2033 | Reserved |A| 2034 +-+-+-+-+-+-+-+-+ 2036 A: Add/Drop flag, indicating whether this is a new or existing subnet 2037 address (1), or a withdrawal of a subnet address (0). 2039 Reserved: MUST be zero. Reserved for future use. 2041 10.11. IPv6 Attached Subnet 2043 The DLEP IPv6 Attached Subnet allows a device to declare that it has 2044 an IPv6 subnet (e.g., a stub network) attached, that it has become 2045 aware of an IPv6 subnet being present at a remote destination, or 2046 that it has become aware of the loss of a subnet at the remote 2047 destination. 2049 The DLEP IPv6 Attached Subnet Data Item contains the following 2050 fields: 2052 0 1 2 3 2053 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 2054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2055 | Data Item Type | Length | 2056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2057 | Flags | IPv6 Attached Subnet : 2058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2059 : IPv6 Attached Subnet : 2060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2061 : IPv6 Attached Subnet : 2062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2063 : IPv6 Attached Subnet : 2064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2065 : ...cont. | Prefix Len. | 2066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2068 Data Item Type: 11 2070 Length: 18 2072 Flags: Flags field, defined below. 2074 IPv6 Attached Subnet: The IPv6 subnet reachable at the destination. 2076 Prefix Length: Length of the prefix (0-128) for the IPv6 subnet. A 2077 prefix length outside the specified range MUST be considered as 2078 invalid. 2080 The Flags field is defined as: 2082 0 1 2 3 4 5 6 7 2083 +-+-+-+-+-+-+-+-+ 2084 | Reserved |A| 2085 +-+-+-+-+-+-+-+-+ 2087 A: Add/Drop flag, indicating whether this is a new or existing subnet 2088 address (1), or a withdrawal of a subnet address (0). 2090 Reserved: MUST be zero. Reserved for future use. 2092 10.12. Maximum Data Rate (Receive) 2094 The Maximum Data Rate (Receive) (MDRR) Data Item is used to indicate 2095 the maximum theoretical data rate, in bits per second, that can be 2096 achieved while receiving data on the link. 2098 The Maximum Data Rate (Receive) Data Item contains the following 2099 fields: 2101 0 1 2 3 2102 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 2103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2104 | Data Item Type | Length | 2105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2106 | MDRR (bps) : 2107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2108 : MDRR (bps) | 2109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2111 Data Item Type: 12 2113 Length: 8 2115 Maximum Data Rate (Receive): A 64-bit unsigned integer, representing 2116 the maximum theoretical data rate, in bits per second (bps), that 2117 can be achieved while receiving on the link. 2119 10.13. Maximum Data Rate (Transmit) 2121 The Maximum Data Rate (Transmit) (MDRT) Data Item is used to indicate 2122 the maximum theoretical data rate, in bits per second, that can be 2123 achieved while transmitting data on the link. 2125 The Maximum Data Rate (Transmit) Data Item contains the following 2126 fields: 2128 0 1 2 3 2129 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 2130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2131 | Data Item Type | Length | 2132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2133 | MDRT (bps) : 2134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2135 : MDRT (bps) | 2136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2138 Data Item Type: 13 2140 Length: 8 2142 Maximum Data Rate (Transmit): A 64-bit unsigned integer, 2143 representing the maximum theoretical data rate, in bits per second 2144 (bps), that can be achieved while transmitting on the link. 2146 10.14. Current Data Rate (Receive) 2148 The Current Data Rate (Receive) (CDRR) Data Item is used to indicate 2149 the rate at which the link is currently operating for receiving 2150 traffic. 2152 When used in the Link Characteristics Request Message (Section 9.18), 2153 Current Data Rate (Receive) represents the desired receive rate, in 2154 bits per second, on the link. 2156 The Current Data Rate (Receive) Data Item contains the following 2157 fields: 2159 0 1 2 3 2160 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 2161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2162 | Data Item Type | Length | 2163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2164 | CDRR (bps) : 2165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2166 : CDRR (bps) | 2167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2169 Data Item Type: 14 2171 Length: 8 2173 Current Data Rate (Receive): A 64-bit unsigned integer, representing 2174 the current data rate, in bits per second, that can currently be 2175 achieved while receiving traffic on the link. 2177 If there is no distinction between Current Data Rate (Receive) and 2178 Maximum Data Rate (Receive) (Section 10.12), Current Data Rate 2179 (Receive) MUST be set equal to the Maximum Data Rate (Receive). The 2180 Current Data Rate (Receive) MUST NOT exceed the Maximum Data Rate 2181 (Receive). 2183 10.15. Current Data Rate (Transmit) 2185 The Current Data Rate (Transmit) (CDRT) Data Item is used to indicate 2186 the rate at which the link is currently operating for transmitting 2187 traffic. 2189 When used in the Link Characteristics Request Message (Section 9.18), 2190 Current Data Rate (Transmit) represents the desired transmit rate, in 2191 bits per second, on the link. 2193 The Current Data Rate (Transmit) Data Item contains the following 2194 fields: 2196 0 1 2 3 2197 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 2198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2199 | Data Item Type | Length | 2200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2201 | CDRT (bps) : 2202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2203 : CDRT (bps) | 2204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2206 Data Item Type: 15 2208 Length: 8 2210 Current Data Rate (Transmit): A 64-bit unsigned integer, 2211 representing the current data rate, in bits per second, that can 2212 currently be achieved while transmitting traffic on the link. 2214 If there is no distinction between Current Data Rate (Transmit) and 2215 Maximum Data Rate (Transmit) (Section 10.13), Current Data Rate 2216 (Transmit) MUST be set equal to the Maximum Data Rate (Transmit). 2217 The Current Data Rate (Transmit) MUST NOT exceed the Maximum Data 2218 Rate (Transmit). 2220 10.16. Latency 2222 The Latency Data Item is used to indicate the amount of latency, in 2223 microseconds, on the link. 2225 The Latency value is reported as transmission delay. The calculation 2226 of latency is implementation dependent. For example, the latency may 2227 be a running average calculated from the internal queuing. 2229 The Latency Data Item contains the following fields: 2231 0 1 2 3 2232 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 2233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2234 | Data Item Type | Length | 2235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2236 | Latency : 2237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2238 : Latency | 2239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2241 Data Item Type: 16 2243 Length: 8 2245 Latency: A 64-bit unsigned integer, representing the transmission 2246 delay, in microseconds, that a packet encounters as it is 2247 transmitted over the link. 2249 10.17. Resources 2251 The Resources (RES) Data Item is used to indicate the amount of 2252 finite resources available for data transmission and reception at the 2253 destination as a percentage, with 0 meaning 'no resources remaining', 2254 and 100 meaning 'a full supply', assuming that when Resources reaches 2255 0 data transmission and/or reception will cease. 2257 An example of such resources might be battery life, but could equally 2258 be magic beans. The list of resources that might be considered is 2259 beyond the scope of this document, and is left to implementations to 2260 decide. 2262 This Data Item is designed to be used as an indication of some 2263 capability of the modem and/or router at the destination. 2265 The Resources Data Item contains the following fields: 2267 0 1 2 3 2268 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 2269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2270 | Data Item Type | Length | 2271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2272 | RES | 2273 +-+-+-+-+-+-+-+-+ 2275 Data Item Type: 17 2277 Length: 1 2279 Resources: An 8-bit unsigned integer percentage, 0-100, representing 2280 the amount of resources available. Any value greater than 100 2281 MUST be considered as invalid. 2283 If a device cannot calculate Resources, this Data Item MUST NOT be 2284 issued. 2286 10.18. Relative Link Quality (Receive) 2288 The Relative Link Quality (Receive) (RLQR) Data Item is used to 2289 indicate the quality of the link to a destination for receiving 2290 traffic, with 0 meaning 'worst quality', and 100 meaning 'best 2291 quality'. 2293 Quality in this context is defined as an indication of the stability 2294 of a link for reception; a destination with high Relative Link 2295 Quality (Receive) is expected to have generally stable DLEP metrics, 2296 and the metrics of a destination with low Relative Link Quality 2297 (Receive) can be expected to rapidly fluctuate over a wide range. 2299 The Relative Link Quality (Receive) Data Item contains the following 2300 fields: 2302 0 1 2 3 2303 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 2304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2305 | Data Item Type | Length | 2306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2307 | RLQR | 2308 +-+-+-+-+-+-+-+-+ 2310 Data Item Type: 18 2312 Length: 1 2313 Relative Link Quality (Receive): A non-dimensional unsigned 8-bit 2314 integer, 0-100, representing relative quality of the link for 2315 receiving traffic. Any value greater than 100 MUST be considered 2316 as invalid. 2318 If a device cannot calculate the Relative Link Quality (Receive), 2319 this Data Item MUST NOT be issued. 2321 10.19. Relative Link Quality (Transmit) 2323 The Relative Link Quality (Transmit) (RLQT) Data Item is used to 2324 indicate the quality of the link to a destination for transmitting 2325 traffic, with 0 meaning 'worst quality', and 100 meaning 'best 2326 quality'. 2328 Quality in this context is defined as an indication of the stability 2329 of a link for transmission; a destination with high Relative Link 2330 Quality (Transmit) is expected to have generally stable DLEP metrics, 2331 and the metrics of a destination with low Relative Link Quality 2332 (Transmit) can be expected to rapidly fluctuate over a wide range. 2334 The Relative Link Quality (Transmit) Data Item contains the following 2335 fields: 2337 0 1 2 3 2338 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 2339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2340 | Data Item Type | Length | 2341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2342 | RLQT | 2343 +-+-+-+-+-+-+-+-+ 2345 Data Item Type: 19 2347 Length: 1 2349 Relative Link Quality (Transmit): A non-dimensional unsigned 8-bit 2350 integer, 0-100, representing relative quality of the link for 2351 transmitting traffic. Any value greater than 100 MUST be 2352 considered as invalid. 2354 If a device cannot calculate the Relative Link Quality (Transmit), 2355 this Data Item MUST NOT be issued. 2357 10.20. Maximum Transmission Unit (MTU) 2359 The Maximum Transmission Unit (MTU) Data Item is used to indicate the 2360 maximum size, in octets, of an IP packet that can be transmitted 2361 without fragmentation, including headers, but excluding any lower 2362 layer headers. 2364 The Maximum Transmission Unit Data Item contains the following 2365 fields: 2367 0 1 2 3 2368 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2370 | Data Item Type | Length | 2371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2372 | MTU | 2373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2375 Data Item Type: 20 2377 Length: 2 2379 Maximum Transmission Unit: The maximum size, in octets, of an IP 2380 packet that can be transmitted without fragmentation, including 2381 headers, but excluding any lower layer headers. 2383 If a device cannot calculate the Maximum Transmission Unit, this Data 2384 Item MUST NOT be issued. 2386 11. Security Considerations 2388 The potential security concerns when using DLEP are: 2390 1. An attacker might pretend to be a DLEP participant, either at 2391 DLEP session initialization, or by injection of DLEP Messages 2392 once a session has been established, and/or 2394 2. DLEP Data Items could be altered by an attacker, causing the 2395 receiving implementation to inappropriately alter its information 2396 base concerning network status. 2398 Since DLEP is restricted to operation over a single (possibly 2399 logical) hop at layer 2, implementations requiring authentication and 2400 /or encryption of traffic MUST take steps to secure the Layer 2 link. 2401 Examples of technologies that can be deployed to secure the Layer 2 2402 link include [IEEE-802.1AE] and [IEEE-802.1X]. 2404 To avoid potential denial of service attack, it is RECOMMENDED that 2405 implementations using the Peer Discovery mechanism maintain an 2406 information base of hosts that persistently fail Session 2407 Initialization having provided an acceptable Peer Discovery Signal, 2408 and ignore subsequent Peer Discovery Signals from such hosts. 2410 This specification does not address security of the data plane, as it 2411 (the data plane) is not affected, and standard security procedures 2412 can be employed. 2414 12. IANA Considerations 2416 This section specifies requests to IANA. 2418 12.1. Registrations 2420 Upon approval of this document, IANA is requested to create a new 2421 protocol registry for Dynamic Link Event Protocol (DLEP). The 2422 remainder of this section requests the creation of new DLEP specific 2423 registries. 2425 12.2. Signal Type Registration 2427 Upon approval of this document, IANA is requested to create a new 2428 DLEP registry, named "Signal Type Values". 2430 The following table provides initial registry values and the 2431 [RFC5226] defined policies that should apply to the registry: 2433 +--------------+-------------------------+ 2434 | Type Code | Description/Policy | 2435 +--------------+-------------------------+ 2436 | 0 | Reserved | 2437 | 1 | Peer Discovery Signal | 2438 | 2 | Peer Offer Signal | 2439 | 3-65519 | Specification Required | 2440 | 65520-65534 | Private Use | 2441 | 65535 | Reserved | 2442 +--------------+-------------------------+ 2444 12.3. Message Type Registration 2446 Upon approval of this document, IANA is requested to create a new 2447 DLEP registry, named "Message Type Values". 2449 The following table provides initial registry values and the 2450 [RFC5226] defined policies that should apply to the registry: 2452 +--------------+------------------------------------------+ 2453 | Type Code | Description/Policy | 2454 +--------------+------------------------------------------+ 2455 | 0 | Reserved | 2456 | 1 | Session Initialization Message | 2457 | 2 | Session Initialization Response Message | 2458 | 3 | Session Update Message | 2459 | 4 | Session Update Response Message | 2460 | 5 | Session Termination Message | 2461 | 6 | Session Termination Response Message | 2462 | 7 | Destination Up Message | 2463 | 8 | Destination Up Response Message | 2464 | 9 | Destination Announce Message | 2465 | 10 | Destination Announce Response Message | 2466 | 11 | Destination Down Message | 2467 | 12 | Destination Down Response Message | 2468 | 13 | Destination Update Message | 2469 | 14 | Link Characteristics Request Message | 2470 | 15 | Link Characteristics Response Message | 2471 | 16 | Heartbeat Message | 2472 | 17-65519 | Specification Required | 2473 | 65520-65534 | Private Use | 2474 | 65535 | Reserved | 2475 +--------------+------------------------------------------+ 2477 12.4. DLEP Data Item Registrations 2479 Upon approval of this document, IANA is requested to create a new 2480 DLEP registry, named "Data Item Values". 2482 The following table provides initial registry values and the 2483 [RFC5226] defined policies that should apply to the registry: 2485 +--------------+------------------------------------------+ 2486 | Type Code | Description/Policy | 2487 +--------------+------------------------------------------+ 2488 | 0 | Reserved | 2489 | 1 | Status | 2490 | 2 | IPv4 Connection Point | 2491 | 3 | IPv6 Connection Point | 2492 | 4 | Peer Type | 2493 | 5 | Heartbeat Interval | 2494 | 6 | Extensions Supported | 2495 | 7 | MAC Address | 2496 | 8 | IPv4 Address | 2497 | 9 | IPv6 Address | 2498 | 10 | IPv4 Attached Subnet | 2499 | 11 | IPv6 Attached Subnet | 2500 | 12 | Maximum Data Rate (Receive) (MDRR) | 2501 | 13 | Maximum Data Rate (Transmit) (MDRT) | 2502 | 14 | Current Data Rate (Receive) (CDRR) | 2503 | 15 | Current Data Rate (Transmit) (CDRT) | 2504 | 16 | Latency | 2505 | 17 | Resources (RES) | 2506 | 18 | Relative Link Quality (Receive) (RLQR) | 2507 | 19 | Relative Link Quality (Transmit) (RLQT) | 2508 | 20 | Maximum Transmission Unit (MTU) | 2509 | 21-65407 | Specification Required | 2510 | 65408-65534 | Private Use | 2511 | 65535 | Reserved | 2512 +--------------+------------------------------------------+ 2514 12.5. DLEP Status Code Registrations 2516 Upon approval of this document, IANA is requested to create a new 2517 DLEP registry, named "Status Code Values". 2519 The following table provides initial registry values and the 2520 [RFC5226] defined policies that should apply to the registry: 2522 +--------------+---------------+-------------------------+ 2523 | Status Code | Failure Mode | Description/Policy | 2524 +--------------+---------------+-------------------------+ 2525 | 0 | Continue | Success | 2526 | 1 | Continue | Not Interested | 2527 | 2 | Continue | Request Denied | 2528 | 3-111 | Continue | Specification Required | 2529 | 112-127 | Continue | Private Use | 2530 | 128 | Terminate | Unknown Message | 2531 | 129 | Terminate | Unexpected Message | 2532 | 130 | Terminate | Invalid Data | 2533 | 131 | Terminate | Invalid Destination | 2534 | 132 | Terminate | Timed Out | 2535 | 132-239 | Terminate | Specification Required | 2536 | 240-254 | Terminate | Private Use | 2537 | 255 | Terminate | Reserved | 2538 +--------------+---------------+-------------------------+ 2540 12.6. DLEP Extensions Registrations 2542 Upon approval of this document, IANA is requested to create a new 2543 DLEP registry, named "Extension Type Values". 2545 The following table provides initial registry values and the 2546 [RFC5226] defined policies that should apply to the registry: 2548 +--------------+----------------------------+ 2549 | Code | Description/Policy | 2550 +--------------+----------------------------+ 2551 | 0 | Reserved | 2552 | 1 | Credit Windowing [CREDIT] | 2553 | 2-65519 | Specification Required | 2554 | 65520-65534 | Private Use | 2555 | 65535 | Reserved | 2556 +--------------+----------------------------+ 2558 Table 5: DLEP Extension types 2560 12.7. DLEP Well-known Port 2562 Upon approval of this document, IANA is requested to assign a single 2563 value in the "Service Name and Transport Protocol Port Number 2564 Registry" found at https://www.iana.org/assignments/service-names- 2565 port-numbers/service-names-port-numbers.xhtml for use by "DLEP", as 2566 defined in this document. This assignment should be valid for TCP 2567 and UDP. SCTP port allocation is not required. 2569 12.8. DLEP IPv4 Link-local Multicast Address 2571 Upon approval of this document, IANA is requested to assign a IPv4 2572 multicast address registry found at http://www.iana.org/assignments/ 2573 multicast-addresses for use as the "IPv4 DLEP Discovery Address". 2575 12.9. DLEP IPv6 Link-local Multicast Address 2577 Upon approval of this document, IANA is requested to assign a IPv6 2578 multicast address registry found at http://www.iana.org/assignments/ 2579 multicast-addresses for use as the "IPv6 DLEP Discovery Address". 2581 13. Acknowledgements 2583 We would like to acknowledge and thank the members of the DLEP design 2584 team, who have provided invaluable insight. The members of the 2585 design team are: Teco Boot, Bow-Nan Cheng, John Dowdell, and Henning 2586 Rogge. 2588 We would also like to acknowledge the influence and contributions of 2589 Greg Harrison, Chris Olsen, Martin Duke, Subir Das, Jaewon Kang, 2590 Vikram Kaul, Nelson Powell, Lou Berger, and Victoria Mercieca. 2592 14. References 2594 14.1. Normative References 2596 [CREDIT] Ratliff, S., "Credit Windowing extension for DLEP", IETF 2597 draft draft-ietf-manet-credit-window-02, March 2016. 2599 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2600 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 2601 RFC2119, March 1997, 2602 . 2604 [UNIV8] , "The Unicode Consortium. The Unicode Standard, Version 2605 8.0.0, (Mountain View, CA: The Unicode Consortium, 2015. 2606 ISBN 978-1-936213-10-8)", 2607 http://www.unicode.org/versions/Unicode8.0.0/, June 2015. 2609 14.2. Informative References 2611 [IEEE-802.1AE] 2612 , "IEEE Standards for Local and Metropolitan Area 2613 Networks: Media Access Control (MAC) Security", DOI 2614 10.1109/IEEESTD.2006.245590, August 2006. 2616 [IEEE-802.1X] 2617 , "IEEE Standards for Local and Metropolitan Area 2618 Networks: Port based Network Access Control", DOI 10.1109/ 2619 IEEESTD.2010.5409813, February 2010. 2621 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2622 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2623 DOI 10.17487/RFC5226, May 2008, 2624 . 2626 [RFC5578] Berry, B., Ed., Ratliff, S., Paradise, E., Kaiser, T., and 2627 M. Adams, "PPP over Ethernet (PPPoE) Extensions for Credit 2628 Flow and Link Metrics", RFC 5578, DOI 10.17487/RFC5578, 2629 February 2010, . 2631 Appendix A. Discovery Signal Flows 2633 Router Modem Signal Description 2634 ======================================================================== 2636 | Router initiates discovery, starts 2637 | a timer, send Peer Discovery 2638 |-------Peer Discovery---->X Signal. 2640 ~ ~ ~ ~ ~ ~ ~ Router discovery timer expires 2641 without receiving Peer Offer. 2643 | Router sends another Peer 2644 |-------Peer Discovery---------->| Discovery Signal. 2645 | 2646 | Modem receives Peer Discovery 2647 | Signal. 2648 | 2649 | Modem sends Peer Offer with 2650 |<--------Peer Offer-------------| Connection Point information. 2651 : 2652 : Router MAY cancel discovery timer 2653 : and stop sending Peer Discovery 2654 : Signals. 2656 Appendix B. Peer Level Message Flows 2658 B.1. Session Initialization 2660 Router Modem Message Description 2661 ======================================================================== 2663 | Router connects to discovered or 2664 | pre-configured Modem Connection 2665 |--TCP connection established---> Point. 2666 | 2667 | Router sends Session 2668 |----Session Initialization----->| Initialization Message. 2669 | 2670 | Modem receives Session 2671 | Initialization Message. 2672 | 2673 | Modem sends Session Initialization 2674 |<--Session Initialization Resp.-| Response, with Success Status Data 2675 | | Item. 2676 | | 2677 |<<============================>>| Session established. Heartbeats 2678 : : begin. 2680 B.2. Session Initialization - Refused 2682 Router Modem Message Description 2683 ======================================================================== 2685 | Router connects to discovered or 2686 | pre-configured Modem Connection 2687 |--TCP connection established---> Point. 2688 | 2689 | Router sends Session 2690 |-----Session Initialization---->| Initialization Message. 2691 | 2692 | Modem receives Session 2693 | Initialization Message, and will 2694 | not support the advertised 2695 | extensions. 2696 | 2697 | Modem sends Session Initialization 2698 | Response, with 'Request Denied' 2699 |<-Session Initialization Resp.--| Status Data Item. 2700 | 2701 | 2702 | Router receives negative Session 2703 | Initialization Response, closes 2704 ||---------TCP close------------|| TCP connection. 2706 B.3. Router Changes IP Addresses 2708 Router Modem Message Description 2709 ======================================================================== 2711 | Router sends Session Update 2712 |-------Session Update---------->| Message to announce change of IP 2713 | address 2714 | 2715 | Modem receives Session Update 2716 | Message and updates internal 2717 | state. 2718 | 2719 |<----Session Update Response----| Modem sends Session Update 2720 | Response. 2722 B.4. Modem Changes Session-wide Metrics 2724 Router Modem Message Description 2725 ======================================================================== 2727 | Modem sends Session Update Message 2728 | to announce change of modem-wide 2729 |<--------Session Update---------| metrics 2730 | 2731 | Router receives Session Update 2732 | Message and updates internal 2733 | state. 2734 | 2735 |----Session Update Response---->| Router sends Session Update 2736 | Response. 2738 B.5. Router Terminates Session 2740 Router Modem Message Description 2741 ======================================================================== 2743 | Router sends Session Termination 2744 |------Session Termination------>| Message with Status Data Item. 2745 | | 2746 |-------TCP shutdown (send)---> | Router stops sending Messages. 2747 | 2748 | Modem receives Session 2749 | Termination, stops counting 2750 | received heartbeats and stops 2751 | sending heartbeats. 2752 | 2753 | Modem sends Session Termination 2754 |<---Session Termination Resp.---| Response with Status 'Success'. 2755 | 2756 | Modem stops sending Messages. 2757 | 2758 ||---------TCP close------------|| Session terminated. 2760 B.6. Modem Terminates Session 2762 Router Modem Message Description 2763 ======================================================================== 2765 | Modem sends Session Termination 2766 |<----Session Termination--------| Message with Status Data Item. 2767 | 2768 | Modem stops sending Messages. 2769 | 2770 | Router receives Session 2771 | Termination, stops counting 2772 | received heartbeats and stops 2773 | sending heartbeats. 2774 | 2775 | Router sends Session Termination 2776 |---Session Termination Resp.--->| Response with Status 'Success'. 2777 | 2778 | Router stops sending Messages. 2779 | 2780 ||---------TCP close------------|| Session terminated. 2782 B.7. Session Heartbeats 2784 Router Modem Message Description 2785 ======================================================================== 2786 |----------Heartbeat------------>| Router sends heartbeat Message 2787 | 2788 | Modem resets heartbeats missed 2789 | counter. 2791 ~ ~ ~ ~ ~ ~ ~ 2793 |---------[Any Message]--------->| When the Modem receives any 2794 | Message from the Router. 2795 | 2796 | Modem resets heartbeats missed 2797 | counter. 2799 ~ ~ ~ ~ ~ ~ ~ 2801 |<---------Heartbeat-------------| Modem sends heartbeat Message 2802 | 2803 | Router resets heartbeats missed 2804 | counter. 2806 ~ ~ ~ ~ ~ ~ ~ 2808 |<--------[Any Message]----------| When the Router receives any 2809 | Message from the Modem. 2810 | 2811 | Modem resets heartbeats missed 2812 | counter. 2814 B.8. Router Detects a Heartbeat timeout 2816 Router Modem Message Description 2817 ======================================================================== 2819 X<----------------------| Router misses a heartbeat 2821 | X<----------------------| Router misses too many heartbeats 2822 | 2823 | 2824 |------Session Termination------>| Router sends Session Termination 2825 | Message with 'Timeout' Status 2826 | Data Item. 2827 : 2828 : Termination proceeds... 2830 B.9. Modem Detects a Heartbeat timeout 2831 Router Modem Message Description 2832 ======================================================================== 2834 |---------------------->X Modem misses a heartbeat 2836 |---------------------->X | Modem misses too many heartbeats 2837 | 2838 | 2839 |<-----Session Termination-------| Modem sends Session Termination 2840 | Message with 'Timeout' Status 2841 | Data Item. 2842 : 2843 : Termination proceeds... 2845 Appendix C. Destination Specific Message Flows 2847 C.1. Common Destination Notification 2849 Router Modem Message Description 2850 ======================================================================== 2852 | Modem detects a new logical 2853 | destination is reachable, and 2854 |<-------Destination Up----------| sends Destination Up Message. 2855 | 2856 |------Destination Up Resp.----->| Router sends Destination Up 2857 | Response. 2859 ~ ~ ~ ~ ~ ~ ~ 2860 | Modem detects change in logical 2861 | destination metrics, and sends 2862 |<-------Destination Update------| Destination Update Message. 2864 ~ ~ ~ ~ ~ ~ ~ 2865 | Modem detects change in logical 2866 | destination metrics, and sends 2867 |<-------Destination Update------| Destination Update Message. 2869 ~ ~ ~ ~ ~ ~ ~ 2870 | Modem detects logical destination 2871 | is no longer reachable, and sends 2872 |<-------Destination Down--------| Destination Down Message. 2873 | 2874 | Router receives Destination Down, 2875 | updates internal state, and sends 2876 |------Destination Down Resp.--->| Destination Down Response Message. 2878 C.2. Multicast Destination Notification 2880 Router Modem Message Description 2881 ======================================================================== 2883 | Router detects a new multicast 2884 | destination is in use, and sends 2885 |-----Destination Announce------>| Destination Announce Message. 2886 | 2887 | Modem updates internal state to 2888 | monitor multicast destination, and 2889 |<-----Dest. Announce Resp.------| sends Destination Announce 2890 Response. 2892 ~ ~ ~ ~ ~ ~ ~ 2893 | Modem detects change in multicast 2894 | destination metrics, and sends 2895 |<-------Destination Update------| Destination Update Message. 2897 ~ ~ ~ ~ ~ ~ ~ 2898 | Modem detects change in multicast 2899 | destination metrics, and sends 2900 |<-------Destination Update------| Destination Update Message. 2902 ~ ~ ~ ~ ~ ~ ~ 2903 | Router detects multicast 2904 | destination is no longer in use, 2905 |--------Destination Down------->| and sends Destination Down 2906 | Message. 2907 | 2908 | Modem receives Destination Down, 2909 | updates internal state, and sends 2910 |<-----Destination Down Resp.----| Destination Down Response Message. 2912 C.3. Link Characteristics Request 2914 Router Modem Message Description 2915 ======================================================================== 2917 Destination has already been 2918 ~ ~ ~ ~ ~ ~ ~ announced by either peer. 2920 | Router requires different 2921 | Characteristics for the 2922 | destination, and sends Link 2923 |--Link Characteristics Request->| Characteristics Request Message. 2924 | 2925 | Modem attempts to adjust link 2926 | properties to meet the received 2927 | request, and sends a Link 2928 | Characteristics Response 2929 |<---Link Characteristics Resp.--| Message with the new values. 2931 Authors' Addresses 2933 Stan Ratliff 2934 VT iDirect 2935 13861 Sunrise Valley Drive, Suite 300 2936 Herndon, VA 20171 2937 USA 2939 Email: sratliff@idirect.net 2941 Bo Berry 2943 Shawn Jury 2944 Cisco Systems 2945 170 West Tasman Drive 2946 San Jose, CA 95134 2947 USA 2949 Email: sjury@cisco.com 2951 Darryl Satterwhite 2952 Broadcom 2954 Email: dsatterw@broadcom.com 2956 Rick Taylor 2957 Airbus Defence & Space 2958 Quadrant House 2959 Celtic Springs 2960 Coedkernew 2961 Newport NP10 8FZ 2962 UK 2964 Email: rick.taylor@airbus.com