idnits 2.17.1 draft-ietf-manet-dlep-02.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 52 longer pages, the longest (page 33) being 64 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 52 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 15 instances of too long lines in the document, the longest one being 2 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 238 has weird spacing: '... Shared o ...' == Line 239 has weird spacing: '... Medium o...' -- The document date (February 6, 2012) is 4461 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) ** Downref: Normative reference to an Informational RFC: RFC 5578 -- Obsolete informational reference (is this intentional?): RFC 4347 (ref. 'DTLS') (Obsoleted by RFC 6347) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile Ad hoc Networks Working S. Ratliff 2 Group B. Berry 3 Internet-Draft G. Harrison 4 Intended status: Standards Track D. Satterwhite 5 Expires: August 10, 2012 Cisco Systems 6 S. Jury 7 NetApp 8 February 6, 2012 10 Dynamic Link Exchange Protocol (DLEP) 11 draft-ietf-manet-dlep-02 13 Abstract 15 When routing devices rely on modems to effect communications over 16 wireless links, they need timely and accurate knowledge of the 17 characteristics of the link (speed, state, etc.) in order to make 18 forwarding decisions. In mobile or other environments where these 19 characteristics change frequently, manual configurations or the 20 inference of state through routing or transport protocols does not 21 allow the router to make the best decisions. A bidirectional, event- 22 driven communication channel between the router and the modem is 23 necessary. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on August 10, 2012 . 48 Copyright Notice 50 Copyright (c) 2012 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 67 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3. Credits . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 4. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 5. Extensions to DLEP . . . . . . . . . . . . . . . . . . . . . . 8 71 6. Normal Session Flow . . . . . . . . . . . . . . . . . . . . . 8 72 7. Generic DLEP Packet Definition . . . . . . . . . . . . . . . . 9 73 8. Message Header Format . . . . . . . . . . . . . . . . . . . . 10 74 9. Message TLV Block Format . . . . . . . . . . . . . . . . . . . 10 75 10. DLEP Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 11 76 10.1. Identification Sub-TLV. . . . . . . . . . . . . . . . . . 12 77 10.2. DLEP Version Sub-TLV. . . . . . . . . . . . . . . . . . . 13 78 10.3. Peer Type Sub-TLV . . . . . . . . . . . . . . . . . . . . 14 79 10.4. MAC Address Sub-TLV . . . . . . . . . . . . . . . . . . . 14 80 10.5. IPv4 Address Sub-TLV. . . . . . . . . . . . . . . . . . . 15 81 10.6. IPv6 Address Sub-TLV. . . . . . . . . . . . . . . . . . . 16 82 10.7. Maximum Data Rate Sub-TLV . . . . . . . . . . . . . . . . 16 83 10.8. Current Data Rate Sub-TLV . . . . . . . . . . . . . . . . 17 84 10.9. Latency Sub-TLV . . . . . . . . . . . . . . . . . . . . . 18 85 10.10. Resources Sub-TLV . . . . . . . . . . . . . . . . . . . . 18 86 10.11. Expected Forwarding Time Sub-TLV. . . . . . . . . . . . . 19 87 10.12. Relative Link Quality Sub-TLV . . . . . . . . . . . . . . 20 88 10.13. Peer Termination Sub-TLV. . . . . . . . . . . . . . . . . 20 89 10.14. Heartbeat Interval Sub-TLV. . . . . . . . . . . . . . . . 21 90 10.15. Heartbeat Threshold Sub-TLV . . . . . . . . . . . . . . . 21 91 10.16. Link Characteristics ACK Timer Sub-TLV. . . . . . . . . . 22 92 10.17. Credit Window Status Sub-TLV. . . . . . . . . . . . . . . 23 93 10.18. Credit Grant Sub-TLV. . . . . . . . . . . . . . . . . . . 24 94 10.19. Credit Request Sub-TLV. . . . . . . . . . . . . . . . . . 24 95 11. DLEP Protocol Messages . . . . . . . . . . . . . . . . . . . 25 96 11.1. Message Block TLV Values . . . . . . . . . . . . . . . . 25 97 12. Peer Discovery Messages . . . . . . . . . . . . . . . . . . . 26 98 12.1. Attached Peer Discovery Message . . . . . . . . . . . . . 26 99 12.2. Detached Peer Discovery Message . . . . . . . . . . . . . 27 100 13. Peer Offer Message . . . . . . . . . . . . . . . . . . . . . . 29 101 14. Peer Update Message. . . . . . . . . . . . . . . . . . . . . . 30 102 15. Peer Update ACK Message. . . . . . . . . . . . . . . . . . . . 31 103 16. Peer Termination Message . . . . . . . . . . . . . . . . . . . 32 104 17. Peer Termination ACK Message . . . . . . . . . . . . . . . . . 33 105 18. Neighbor Up Message . . . . . . . . . . . . . . . . . . . . . 33 106 19. Neighbor Up ACK Message. . . . . . . . . . . . . . . . . . . . 35 107 20. Neighbor Down Message . . . . . . . . . . . . . . . . . . . . 35 108 21. Neighbor Down ACK Message. . . . . . . . . . . . . . . . . . . 36 109 22. Neighbor Update Message . . . . . . . . . . . . . . . . . . . 37 110 23. Neighbor Address Update Message. . . . . . . . . . . . . . . . 38 111 24. Neighbor Address Update ACK Message. . . . . . . . . . . . . . 39 112 25. Heartbeat Message . . . . . . . . . . . . . . . . . . . . . . 40 113 26. Link Characteristics Message . . . . . . . . . . . . . . . . . 40 114 27. Link Characteristics ACK Message . . . . . . . . . . . . . . . 42 115 28. Security Considerations. . . . . . . . . . . . . . . . . . . . 43 116 29. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 43 117 29.1 TLV Registrations. . . . . . . . . . . . . . . . . . . . . 43 118 29.2 Expert Review: Evaluation Guidelines . . . . . . . . . . . 43 119 29.3 Message TLV Type Registrations . . . . . . . . . . . . . . 43 120 29.4 DLEP Order Registrations . . . . . . . . . . . . . . . . . 44 121 29.5 DLEP Sub-TLV Type Registrations. . . . . . . . . . . . . . 44 122 30. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 45 124 1. Introduction 126 There exist today a collection of modem devices that control links of 127 variable bandwidth and quality. Examples of these types of links 128 include line-of-sight (LOS) radios, satellite terminals, and cable/ 129 DSL modems. Fluctuations in speed and quality of these links can 130 occur due to configuration (in the case of cable/DSL modems), or on a 131 moment-to-moment basis, due to physical phenomena like multipath 132 interference, obstructions, rain fade, etc. It is also quite possible 133 that link quality and bandwidth varies with respect to individual 134 neighbors on a link, and with the type of traffic being sent. As an 135 example, consider the case of an 802.11g access point, serving 2 136 associated laptop computers. In this environment, the answer to the 137 question "What is the bandwidth on the 802.11g link?" is "It depends 138 on which associated laptop we're talking about, and on what kind of 139 traffic is being sent." While the first laptop, being physically 140 close to the access point, may have a bandwidth of 54Mbps for 141 unicast traffic, the other laptop, being relatively far away, or 142 obstructed by some object, can simultaneously have a bandwidth of 143 only 32Mbps for unicast. However, for multicast traffic sent from the 144 access point, all traffic is sent at the base transmission rate 145 (which is configurable, but depending on the model of the access 146 point, is usually 24Mbps or less). 148 In addition to utilizing variable bandwidth links, mobile networks 149 are challenged by the notion that link connectivity will come and go 150 over time. Effectively utilizing a relatively short-lived connection 151 is problematic in IP routed networks, as routing protocols tend to 152 rely on independent timers at OSI Layer 3 to maintain network 153 convergence (e.g. HELLO messages and/or recognition of DEAD routing 154 adjacencies). These short-lived connections can be better utilized 155 with an event-driven paradigm, where acquisition of a new neighbor 156 (or loss of an existing one) is somehow signaled, as opposed to a 157 timer-driven paradigm. 159 Another complicating factor for mobile networks are the different 160 methods of physically connecting the modem devices to the router. 161 Modems can be deployed as an interface card in a router's 162 chassis, or as a standalone device connected to the router via 163 Ethernet, USB, or even a serial link. In the case of Ethernet or 164 serial attachment, with existing protocols and techniques, routing 165 software cannot be aware of convergence events occurring on the 166 radio link (e.g. acquisition or loss of a potential routing 167 neighbor), nor can the router be aware of the actual capacity of 168 the link. This lack of awareness, along with the variability in 169 bandwidth, leads to a situation where quality of service (QoS) 170 profiles are extremely difficult to establish and properly 171 maintain. This is especially true of demand-based access schemes 172 such as Demand Assigned Multiple Access (DAMA) implementations 173 used on some satellite systems. With a DAMA-based system, 174 additional bandwidth may be available, but will not be used 175 unless the network devices emit traffic at rate higher than the 176 currently established rate. Increasing the traffic rate does not 177 guarantee additional bandwidth will be allocated; rather, it may 178 result in data loss and additional retransmissions on the link. 180 In attempting to address the challenges listed above, the authors 181 have developed the Data Link Exchange Protocol, or DLEP. The DLEP 182 protocol runs between a router and its attached modem devices, 183 allowing the modem to communicate link characteristics as they 184 change, and convergence events (acquisition and loss of potential 185 routing neighbors). The following diagrams are used to illustrate 186 the scope of DLEP sessions. 188 |-----Local Neighbor-----| |-----Remote Neighbor----| 189 | | | (far-end device) | 191 +--------+ +-------+ +-------+ +--------+ 192 | Router |=======| Modem |{~~~~~~~~}| Modem |=======| Router | 193 | | | Device| | Device| | | 194 +--------+ +-------+ +-------+ +--------+ 196 | | | Link | | | 197 |-DLEP--| | Protocol | |-DLEP--| 198 | | | (e.g. | | | 199 | | | 802.11) | | | 201 Figure 1: DLEP Network 203 In Figure 1, when a local client (Modem device) detects the 204 presence of a remote neighbor, it sends an indication to its 205 local router via the DLEP session. Upon receipt of the indication, 206 the local router would take appropriate action (e.g. initiation 207 of discovery or HELLO protocols) to converge the network. After 208 notification of the new neighbor, the modem device utilizes the 209 DLEP session to report the characteristics of the link (bandwidth, 210 latency, etc) to the router on an as-needed basis. 212 DLEP is independent of the underlying link type and topology. 213 Figure 2 shows how DLEP can support a configuration whereby 214 routers are connected with different link types and with different 215 network configurations. In this setup, the routers are connected 216 with two different devices (Modem device A and Modem device B). 217 Modem A is connected via a point-to-point link, whereas Modem B 218 is connected via a shared medium. In both cases, the DLEP session 219 is used to report the characteristics of the link (bandwidth, 220 latency, etc.) to network neighbors on an as-needed basis. The 221 modem is also able to use the DLEP session to notify the router 222 when the remote neighbor is lost, shortening the time required to 223 re-converge the network. 225 +--------+ +--------+ 226 +------+ Modem A| | Modem A+-----+ 227 | | Device | <===== // ======> | Device | | 228 | +--------+ P-t-P Link +--------+ | 229 | Protocol | 230 +---+----+ +---+----+ 231 | Router | | Router | 232 | | | | 233 +---+----+ +---+----+ 234 | + 235 | +--------+ +--------+ | 236 +------+ Modem B| | Modem B| | 237 | Device | o o o o o o o o | Device +-----+ 238 +--------+ o Shared o +--------+ 239 o Medium o 240 o o 241 o o 242 o o 243 o 244 +--------+ 245 | Modem B| 246 | Device | 247 +---+----+ 248 | 249 | 250 +---+----+ 251 | Router | 252 | | 253 +--------+ 255 Figure 2: DLEP Network with Multiple Modem Devices 257 DLEP exists as a collection of type-length-value (TLV) based messages 258 using [RFC5444] formatting. The protocol can be used for both Ethernet 259 attached modems (utilizing, for example, a UDP socket for transport 260 of the RFC 5444 packets), or in environments where the modem is an 261 interface card in a chassis (via a message passing scheme). DLEP 262 utilizes a session paradigm between the modem device and its 263 associated router. If multiple modem devices are attached to a 264 router (as in FIgure 2), a separate DLEP session MUST exist for each 265 modem. If a modem device supports multiple connections to a router 266 (via multiple logical or physical interfaces), or supports 267 connections to multiple routers, a separate DLEP session MUST exist 268 for each connection. 270 1.1 Requirements 272 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 273 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 274 document are to be interpreted as described in BCP 14, RFC 2119 275 [RFC2119]. 277 2. Assumptions 279 In order to implement discovery in the DLEP protocol (thereby 280 avoiding some configuration), we have defined a first-speaker and a 281 passive-listener scheme. Borrowing from existing terminology, this 282 document refers to the first-speaker as the 'client', and the passive 283 listener as the 'server', even though there is no client/server 284 relationship in the classic sense. In a typical deployment, a router 285 would appear as the DLEP 'server', and an attached modem device would 286 act as the 'client' (e.g. the initiator for discovery). 288 DLEP assumes that participating clients appear to the server as a 289 transparent bridge - specifically, the assumption is that the 290 destination MAC address for data traffic in any frame emitted by 291 the server should be the MAC address of the next-hop router or end- 292 device, and not the MAC address of any of the intervening clients. 294 DLEP assumes that security on the session (e.g. authentication of 295 session partners, encryption of traffic, or both) is dealt with by 296 the underlying transport mechanism for the RFC 5444 packets (e.g. by 297 using a transport such as DTLS [DTLS]). 299 DLEP utilizes a session-oriented paradigm. There are two classes 300 of sessions - the first is identified as a 'peer session'. The 301 peer session exists between a DLEP server and a DLEP client. All 302 DLEP messages between client and server are transmitted within the 303 context of the peer session. 305 The other type of DLEP session is referred to as a 'neighbor session'. 306 Neighbor sessions can be instantiated by either the DLEP server or 307 client, and represent an identifiable destination (i.e. an address) 308 within the network. Examples of a destination would be a unicast 309 address (for either a next-hop router, or for an end-station), or 310 a multicast address. A DLEP neighbor session MUST exist for every 311 destination that exists in the network. 313 The optional [RFC5444] message header Sequence Number MUST be 314 included in all DLEP packets. Sequence Numbers start at 1 and are 315 incremented by one for each original and retransmitted message. The 316 unsigned 16-bit Sequence Number rolls over at 65535 to 1. A 317 Sequence Number of 0 is not valid. Sequence Numbers are unique 318 within the context of a DLEP session. Sequence numbers are used in 319 DLEP to correlate a response to a request. 321 3. Credits 323 DLEP includes an OPTIONAL credit-windowing scheme analogous to the 324 one documented in [RFC5578]. In this scheme, traffic between the 325 DLEP client and the DLEP server is treated as two unidirectional 326 windows. This document identifies these windows as the "Client 327 Receive Window", or CRW, and the "Server Receive Window", or SRW. 329 If credits are used, they MUST be granted by the receiver on a 330 given window - that is, on the "Client Receive Window" (CRW), 331 the DLEP client is responsible for granting credits to the server, 332 allowing it (the server) to send data to the client. Likewise, 333 the DLEP server is responsible for granting credits on the SRW, 334 which allows the client to send data to the server. 336 DLEP expresses all credit data in number of octets. The total number 337 of credits on a window, and the increment to add to a grant, are 338 always expressed as a 64-bit unsigned quantity. 340 If used, credits are managed on a neighbor session basis; that is, 341 separate credit counts are maintained for each neighbor session 342 requiring the service. Credits do not apply to DLEP peer sessions. 344 4. Metrics 346 DLEP includes the ability for the client and server to communicate 347 metrics that reflect the characteristics (e.g. bandwidth, latency) 348 of the variable-quality link in use. As mentioned in the 349 introduction section of this document, metrics have to be used 350 within a context - for example, metrics to a unicast address in 351 the network. DLEP allows for metrics to be sent within two 352 contexts - neighbor session context (those for a given destination 353 within the network), and peer session context (those that apply 354 to all destinations accessed via the DLEP client). Metrics 355 supplied on DLEP Peer messages are, by definition, in the context 356 of a peer session; metrics supplied on Neighbor messages are, by 357 definition, used in the context of a neighbor session. 359 Supplying metrics in a peer session context gives clients the 360 ability to supply default metrics on a 'device-wide' basis. It is 361 left to implementations to choose sensible default values based on 362 their specific characteristics. Additionally, the metrics (either 363 at a peer or neighbor session context) MAY be used to report non- 364 changing, or static, metrics. Clients having static link metric 365 characteristics SHOULD report metrics only once for a given 366 neighbor session (or peer session, if all connections via the client 367 are of this static nature). 369 The approach of allowing for different contexts for metric data 370 increases both the flexibility and the complexity of using metric 371 data. This document details the mechanism whereby the data is 372 transmitted, however, the specific algorithms for utilizing the 373 dual-context metrics is out of scope and not addressed by this 374 document. 376 5. Extensions to DLEP 378 While this draft represents the best efforts of the co-authors, and 379 the working group, to be functionally complete, it is recognized 380 that extensions to DLEP will in all likelihood be necessary as more 381 link types are utilized. To allow for future innovation, the draft 382 allocates numbering space for experimental orders and sub-TLVs. DLEP 383 implementations MUST be capable of parsing and acting on the orders 384 and sub-TLVs as documented in this specification. DLEP orders/sub-TLVs 385 in the experimental numbering range SHOULD be silently dropped by an 386 implementation if they are not understood. The intent of the 387 experimental numbering space is to allow for further development of 388 DLEP protocol features and function. If subsequent development yields 389 new features with sufficient applicability, those features should be 390 either included in an update of this specification, or documented in 391 a standalone specification. 393 6. Normal Session Flow 395 A session between a client and a server is established by exchanging 396 the "Peer Discovery" and "Peer Offer" messages described below. 398 The flows described in this document create a state-full protocol 399 between client and server. Both client and server initialize in a 400 "discovery" state, and the client issues a "Peer Discovery" message. 401 When the server receives a Peer Discovery, it responds with a "Peer 402 Offer" message, and enters an "in session" state with the client. 403 Receipt of the Peer Offer at the client causes it (the client) to 404 transition into the "in session" state. 406 Once that exchange has successfully occurred, messages transferred 407 in the context of the peer session will consist of 408 o Periodic 'Heartbeat' messages, intended to keep the peer session 409 alive, and to verify bidirectional connectivity, and/or 410 o Peer Update messages, indicating some change in status that one 411 of the peers needs to communicate to the other. 413 In addition to the messages above, the peers will transmit DLEP 414 messages concerning destinations in the network. These messages 415 trigger creation/maintenance/termination of 'neighbor sessions'. For 416 example, a peer will inform its DLEP partner of the presence of a 417 new destination via the "Neighbor Up" message. Receipt of a Neighbor 418 Up causes the receiving peer to allocate the necessary resources, 419 creating a neighbor session, and transition to an "in session" state 420 on the newly created neighbor session. The in-session state persists 421 until notification of neighbor loss is received, or by optional 422 timeout due to inactivity. 424 The loss of a destination is communicated via the "Neighbor Down" 425 message, and changes in status to the destination (e.g. varying 426 link quality, or addressing changes) are communicated via a 427 "Neighbor Update" message. 429 Again, metrics can be expressed within the context of a neighbor 430 session via the Neighbor Update message, or within the context of 431 a peer session (reflecting the link as a whole) via the Peer Update 432 message. In cases where metrics are provided on the peer session, the 433 receiving peer MUST propagate the metrics to all neighbor sessions 434 accessed via the peer. A DLEP peer MAY send metrics both in a peer 435 session context (via the Peer Update message) and a neighbor session 436 context (via Neighbor Update) at any time. The heuristics for 437 applying received peer session and neighbor session metrics is left 438 to implementations. 440 In addition to receiving metrics about the link, DLEP provides for 441 the ability for a server to request a different amount of bandwidth, 442 or latency, from the client via the Link Characteristics Message. 443 This allows the server to deal with requisite increases (or decreases) 444 of allocated bandwidth/latency in demand-based schemes in a more 445 deterministic manner. 447 7. Generic DLEP Packet Definition 449 The Generic DLEP Packet Definition follows the format for packets 450 defined in [RFC5444]. 452 The Generic DLEP Packet Definition contains the following fields: 454 0 1 2 3 455 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 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 |Version| Flags | Packet Sequence Number | Packet TLV | 458 | | | | Block... | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | Message (Contains DLEP message)... | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 Version - Version of RFC 5444 specification on 464 which the packet/messages/TLVs are 465 constructed. 467 Flags - 4 bit field. All bits MUST be ignored 468 by DLEP implementations. 470 Packet Sequence Number - If present, the packet sequence number 471 is parsed and ignored. DLEP does NOT 472 use or generate packet sequence numbers. 474 Packet TLV block - A TLV block which contains packet level 475 TLV information. DLEP implementations 476 MUST NOT use this TLV block. 478 Message - The packet MAY contain zero or more 479 messages, however, DLEP messages are 480 encoded within an RFC 5444 Message 481 TLV Block. 483 8. Message Header Format 485 DLEP utilizes the following format for the RFC 5444 message header 487 0 1 2 3 488 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 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Msg Type |Msg Flg|AddrLen| Message Size | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | Message Seq Num | TLV Block... | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 Message Type - An 8-bit field which specifies the type 496 of the message. For DLEP, this field 497 contains DLEP_MESSAGE (value TBD) 499 Message Flags - Set to 0x1 (bit 3, mhasseqnum bit is 500 set). All other bits are unused and MUST 501 be set to '0'. 503 Message Address Length - A 4-bit unsigned integer field encoding the 504 length of all addresses included in this 505 message. DLEP implementations do not use 506 this field; contents SHOULD be ignored. 508 Message Size - A 16-bit unsigned integer field which 509 specifies the number of octets that make up 510 the message including the message header. 512 Message Sequence Number - A 16-bit unsigned integer field that 513 contains a sequence number, generated by 514 the originator of the message. Sequence 515 numbers range from 1 to 65535. Sequence 516 numbers roll over at 65535 to 1; 0 is 517 invalid. 519 TLV Block - TLV Block included in the message. 521 9. Message TLV Block Format 523 The DLEP protocol is organized as a set of orders, each with a 524 collection of Sub-TLVs. The Sub-TLVs carry information needed 525 to process and/or establish context (e.g. the MAC address of a 526 far-end router), and the 'tlv-type' field in the message TLV 527 block carries the DLEP order itself. The DLEP orders are 528 enumerated in section 11.1 of this document, and the messages 529 created using these orders are documented in sections 12 through 530 27. 532 DLEP uses the following settings for an RFC 5444 Message TLV 533 block: 535 0 1 2 3 536 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 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | TLVs Length | TLV Type | TLV Flags | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Length | Value... | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 TLVs Length - A 16-bit unsigned integer field that contains the total 544 number of octets in all of the immediately following 545 TLV elements (tlvs-length not included). 547 TLV Type - An 8-bit unsigned integer field specifying the type 548 of the TLV. DLEP uses this field to specify the DLEP 549 order. Valid DLEP orders are defined in section 11.1 550 of this document. 552 TLV Flags - An 8-bit flags bit field. Bit 3 (thasvalue) MUST be 553 set; all other bits are not used and MUST be set 554 to '0'. 556 Length - Length of the 'Value' field of the TLV 558 Value - A field of length which contains data 559 specific to a particular TLV type. In the DLEP 560 case, this field will consist of a collection of 561 DLEP sub-TLVs appropriate for the DLEP action 562 specified in the TLV type field. 564 10. DLEP sub-TLVs 566 DLEP protocol messages are transported in an RFC 5444 message TLV. 567 All DLEP messages use the RFC 5444 DLEP_MESSAGE value (TBD). The 568 protocol messages consist of a DLEP order, encoded in the 'tlv-type' 569 field in the message TLV block, with the 'value' field of the TLV 570 block containing a collection (1 or more) DLEP sub-TLVs. 572 The format of DLEP Sub-TLVs is consistent with RFC 5444 in that the 573 Sub-TLVs contain a flag field in addition to the type, length, and 574 value fields. Valid DLEP Sub-TLVs are: 576 TLV TLV 577 Value Description 578 ========================================= 579 TBD Identification sub-TLV 580 TBD DLEP Version sub-TLV 581 TBD Peer Type sub-TLV 582 TBD MAC Address sub-TLV 583 TBD IPv4 Address sub-TLV 584 TBD IPv6 Address sub-TLV 585 TBD Maximum Data Rate (MDR) sub-TLV 586 TBD Current Data Rate (CDR) sub-TLV 587 TBD Latency sub-TLV 588 TBD Resources sub-TLV 589 TBD Expected Forwarding Time (ETX) sub-TLV 590 TBD Relative Link Quality (RLQ) sub-TLV 591 TBD Status sub-TLV 592 TBD Heartbeat Interval sub-TLV 593 TBD Heartbeat Threshold sub-TLV 594 TBD Neighbor down ACK timer sub-TLV 595 TBD Link Characteristics ACK timer sub-TLV 596 TBD Credit Window Status sub-TLV 597 TBD Credit Grant sub-TLV 598 TBD Credit Request sub-TLV 600 DLEP sub-TLVs contain the following fields: 602 0 1 2 3 603 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 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | TLV Type |TLV Flags=0x10 | Length | Value... | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 TLV Type - An 8-bit unsigned integer field specifying the type 609 of the sub-TLV. 611 TLV Flags - An 8-bit flags bit field. Bit 3 (thasvalue) MUST be 612 set, all other bits are not used and MUST be set to 613 '0'. 615 Length - An 8-bit length of the value field of the sub-TLV 617 Value - A field of length which contains data 618 specific to a particular sub-TLV. 620 10.1 Identification Sub-TLV 622 This Sub-TLV MUST exist in the TLV Block for all DLEP messages, and 623 MUST be the first Sub-TLV of the message. Further, there MUST be ONLY 624 one Identification Sub-TLV in an RFC 5444 message TLV block. The 625 Identification sub-TLV contains client and server identification 626 information used to establish the proper context for processing DLEP 627 protocol messages. 629 The Identification sub-TLV contains the following fields: 631 0 1 2 3 632 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 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 |TLV Type = TBD |TLV Flags=0x10 |Length = 8 | Server ID | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | Server ID | Client ID | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Client ID | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 TLV Type - Value TBD 643 TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other bits are 644 unused and MUST be set to '0'. 646 Length - 8 648 Server ID - Indicates the Server ID of the DLEP session. 650 Client ID - indicates the Client ID of the DLEP session. 652 When the client initiates discovery (via the Peer Discovery message), 653 it MUST set the Client ID to a 32-bit quantity that will be used to 654 uniquely identify this session from the client-side. The client MUST 655 set the Server ID to '0'. When responding to the Peer Discovery 656 message, the server MUST echo the Client ID, and MUST supply its own 657 unique 32-bit quantity to identify the session from the server's 658 perspective. After the Peer Discovery/Peer Offer exchange, both the 659 Client ID and the Server ID MUST be set to the values obtained from 660 the Peer DIscovery/Peer Offer sequence. 662 10.2 DLEP Version Sub-TLV 664 The DLEP Version Sub-TLV is an OPTIONAL TLV in both the Peer 665 Discovery and Peer Offer messages. The Version Sub-TLV is used to 666 indicate the client or server version of the protocol. The client 667 and server MAY use this information to decide if the peer is running 668 at a supported level. 670 The DLEP Version Sub-TLV contains the following fields: 672 0 1 2 3 673 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 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 |TLV Type =TBD |TLV Flags=0x10 |Length=4 | Major Version | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | Major Version | Minor Version | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 TLV Type - TBD 681 TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other bits are 682 not used and MUST be set to '0'. 684 Length - Length is 4 686 Major Version - Major version of the client or router protocol. 688 Minor Version - Minor version of the client or router protocol. 690 Support of this draft is indicated by setting the Major Version 691 to '1', and the Minor Version to '2' (e.g. Version 1.2). 693 10.3 Peer Type Sub-TLV 695 The Peer Type Sub-TLV is used by the server and client to give 696 additional information as to its type. It is an OPTIONAL sub-TLV in 697 both the Peer Discovery Message and the Peer Offer message. The peer 698 type is a string and is envisioned to be used for informational 699 purposes (e.g. as output in a display command). 701 The Peer Type sub-TLV contains the following fields: 703 0 1 2 3 704 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 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 |TLV Type =TBD |TLV Flags=0x10 |Length= peer |Peer Type Str | 707 | | |type string len|Max Len = 80 | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 TLV Type - TBD 712 TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other bits 713 are not used and MUST be set to '0'. 715 Length - Length of peer type string (80 bytes maximum). 717 Peer Type String - Non-Null terminated peer type string, maximum 718 length of 80 bytes. For example, a satellite 719 modem might set this variable to 'Satellite 720 terminal'. 722 10.4 MAC Address Sub-TLV 724 The MAC address Sub-TLV MUST appear in all neighbor-oriented 725 messages (e.g. Neighbor Up, Neighbor Up ACK, Neighbor Down, Neighbor 726 Down ACK, Neighbor Update, Link Characteristics Request, and Link 727 Characteristics ACK). The MAC Address sub-TLV contains the address 728 of the far-end (neighbor) destination, and may be either a physical 729 or a virtual destination. Examples of a virtual destination would 730 be a multicast MAC address, or the broadcast MAC (0xFFFFFFFFFFFF). 732 The MAC Address sub-TLV contains the following fields: 734 0 1 2 3 735 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 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 |TLV Type =TBD |TLV Flags=0x10 |Length = 6 |MAC Address | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | MAC Address | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | MAC Address | 742 +-+-+-+-+-+-+-+-+ 744 TLV Type - TBD 746 TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other bits are not 747 used and MUST be set to '0'. 749 Length - 6 751 MAC Address - MAC Address of the destination (either physical or 752 virtual). 754 10.5 IPv4 Address Sub-TLV 756 The IPv4 Address Sub-TLV MAY be used in Neighbor Up, Neighbor 757 Update, and Peer Update Messages, if the client is aware of the 758 Layer 3 address. When included in Neighbor messages, the IPv4 759 Address sub-TLV contains the IPv4 address of the far-end neighbor. 760 In the Peer Update message, it contains the IPv4 address of the 761 sending peer. In either case, the sub-TLV also contains an 762 indication of whether this is a new or existing address, or is a 763 deletion of a previously known address. 765 The IPv4 Address Sub-TLV contains the following fields: 767 0 1 2 3 768 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 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 |TLV Type =TBD |TLV Flags=0x10 |Length = 5 | Add/Drop | 771 | | | | Indicator | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | IPv4 Address | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 TLV Type - TBD 778 TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other bits are not 779 used and MUST be set to '0'. 781 Length - 5 783 Add/Drop - Value indicating whether this is a new or existing 784 Indicator address (0x01), or a withdrawal of an address (0x02). 786 IPv4 Address - IPv4 Address of the far-end neighbor or peer. 788 10.6 IPv6 Address Sub-TLV 790 The IPv6 Address Sub-TLV MAY be used in Neighbor Up, Neighbor 791 Update, and Peer Update Messages, if the client is aware of the 792 Layer 3 address. When included in Neighbor messages, the IPv6 793 Address sub-TLV contains the IPv6 address of the far-end neighbor. 794 In the Peer Update, it contains the IPv6 address of the 795 originating peer. In either case, the sub-TLV also contains an 796 indication of whether this is a new or existing address, or is a 797 deletion of a previously known address. 799 The IPv6 Address sub-TLV contains the following fields: 801 0 1 2 3 802 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 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 |TLV Type =TBD |TLV Flags=0x10 |Length = 17 | Add/Drop | 805 | | | | Indicator | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | IPv6 Address | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | IPv6 Address | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | IPv6 Address | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | IPv6 Address | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 TLV Type - TBD 818 TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other bits are not 819 used and MUST be set to '0'. 821 Length - 17 823 Add/Drop - Value indicating whether this is a new or 824 Indicator existing address (0x01), or a withdrawal of 825 an address (0x02). 827 IPv6 Address - IPv6 Address of the far-end neighbor or peer. 829 10.7 Maximum Data Rate Sub-TLV 831 The Maximum Data Rate (MDR) Sub-TLV is used in Neighbor Up, Neighbor 832 Update, Peer Discovery, Peer Update, and Link Characteristics ACK 833 Messages to indicate the maximum theoretical data rate, in bits per 834 second, that can be achieved on the link. When metrics are reported 835 via the messages listed above, the maximum data rate MUST be reported. 837 The Maximum Data Rate sub-TLV contains the following fields: 839 0 1 2 3 840 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 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 |TLV Type =TBD |TLV Flags=0x10 |Length = 8 | MDR (bps) | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | MDR (bps) | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | MDR (bps) | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 TLV Type - TBD 851 TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other 852 bits are not used and MUST be set to '0'. 854 Length - 8 856 Maximum Data Rate - A 64-bit unsigned number, representing the 857 maximum theoretical data rate, in bits per 858 second (bps), that can be achieved on the 859 link. 861 10.8 Current Data Rate Sub-TLV 863 The Current Data Rate (CDR) Sub-TLV is used in Neighbor Up, Neighbor 864 Update, Peer Discovery, Peer Update, Link Characteristics Request, 865 and Link Characteristics ACK messages to indicate the rate at which 866 the link is currently operating, or in the case of the Link 867 Characteristics Request, the desired data rate for the link. 869 The Current Data Rate sub-TLV contains the following fields: 871 0 1 2 3 872 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 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 |TLV Type =TBD |TLV Flags=0x10 |Length = 8 |CDR (bps) | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | CDR (bps) | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 | CDR (bps) | 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 TLV Type - TBD 883 TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other 884 bits are not used and MUST be set to '0'. 886 Length - 8 888 Current Data Rate - A 64-bit unsigned number, representing the 889 current rate, in bits per second (bps), 890 on the link. When reporting metrics (e.g, 891 in Neighbor Up, Neighbor Down, Peer 892 Discovery, Peer Update, or Link 893 Characteristics ACK), if there is no 894 distinction between current and maximum 895 data rates, current data rate SHOULD be 896 set equal to the maximum data rate. 898 10.9 Expected Forwarding Time Sub-TLV 900 The Expected Forwarding Time (EFT) Sub-TLV is used in Neighbor Up, 901 Neighbor Update, Peer Discovery, and Peer Update messages to indicate 902 the typical latency between the arrival of a given packet at the 903 transmitting device and the reception of the packet at the other end 904 of the link. EFT combines transmission time, idle time, waiting time, 905 freezing time, and queuing time to the degree that those values are 906 meaningful to a given transmission medium. 908 The Expected Forwarding Time sub-TLV contains the following fields: 910 0 1 2 3 911 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 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 |TLV Type =TBD |TLV Flags=0x10 |Length = 4 | EFT (ms) | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | EFT | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 TLV Type - TBD 920 TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other 921 bits are not used and MUST be set to '0'. 923 Length - 4 925 Current Data Rate - A 32-bit unsigned number, representing the 926 expected forwarding time, in milliseconds, 927 on the link. 929 10.10 Latency Sub-TLV 931 The Latency Sub-TLV is used in Neighbor Up, Neighbor Update, Peer 932 Discovery, Peer Update, Link Characteristics Request, and Link 933 Characteristics ACK messages to indicate the amount of latency on 934 the link, or in the case of the Link Characteristics Request, to 935 indicate the maximum latency required (e.g. a should-not-exeed value) 936 on the link. 938 The Latency Sub-TLV contains the following fields: 940 0 1 2 3 941 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 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 |TLV Type =TBD |TLV Flags=0x10 |Length = 2 |Latency (ms) | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 |Latency (ms) | 946 +-+-+-+-+-+-+-+-+ 948 TLV Type - TBD 950 TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other 951 bits are not used and MUST be set to '0'. 953 Length - 2 955 Latency - The transmission delay that a packet 956 encounters as it is transmitted over the 957 link. In Neighbor Up, Neighbor Update, 958 and Link Characteristics ACK, this value 959 is reported in absolute delay, in 960 milliseconds. The calculation of latency 961 is implementation dependent. For example, 962 the latency may be a running average 963 calculated from the internal queuing. If 964 a device cannot calculate latency, it 965 SHOULD be reported as 0. In the Link 966 Characteristics Request Message, this value 967 represents the maximum delay, in 968 milliseconds, expected on the link. 970 10.11 Resources Sub-TLV 972 The Resources Sub-TLV is used in Neighbor Up, Neighbor Update, Peer 973 Discovery, Peer Update, and Link Characteristics ACK messages to 974 indicate a percentage (0-100) amount of resources (e.g. battery 975 power) remaining on the originating peer. 977 The Resources TLV contains the following fields: 978 0 1 2 3 979 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 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 |TLV Type =TBD |TLV Flags=0x10 |Length = 1 | Resources | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 TLV Type - TBD 986 TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other 987 bits are not used and MUST be set to '0'. 989 Length - 1 990 Resources - A percentage, 0-100, representing the 991 amount of remaining resources, such as 992 battery power. If resources cannot be 993 calculated, a value of 100 SHOULD be 994 reported. 996 10.12 Relative Link Quality Sub-TLV 998 The Relative Link Quality (RLQ) Sub-TLV is used in Neighbor Up, 999 Neighbor Update, Peer Discovery, Peer Update, and Link 1000 Characteristics ACK messages to indicate the quality of the link 1001 as calculated by the originating peer. 1003 The Relative Link Quality sub-TLV contains the following fields: 1005 0 1 2 3 1006 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 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 |TLV Type =TBD |TLV Flags=0x10 |Length = 1 |Relative Link | 1009 | | | |Quality (RLQ) | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 TLV Type - TBD 1014 TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other 1015 bits are not used and MUST be set to '0'. 1017 Length - 1 1019 Relative Link Quality - A non-dimensional number, 0-100, 1020 representing relative link quality. A value 1021 of 100 represents a link of the highest 1022 quality. If the RLQ cannot be calculated, a 1023 value of 100 SHOULD be reported. 1025 10.13 Status Sub-TLV 1027 The Status Sub-TLV is sent from either the client or server to 1028 indicate the success or failure of a given request 1030 The Status Sub-TLV contains the following fields: 1032 0 1 2 3 1033 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 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 |TLV Type =TBD |TLV Flags=0x10 |Length = 1 | Code | 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 TLV Type - TBD 1040 TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other bits 1041 are not used and MUST be set to '0'. 1043 Length - 1 1045 Termination Code - 0 = Success 1046 Non-zero = Failure. Specific values of a non- 1047 zero termination code depend on the operation 1048 requested (e.g. Neighbor Up, Neighbor Down, etc). 1050 10.14 Heartbeat Interval Sub-TLV 1052 The Heartbeat Interval Sub-TLV MAY be sent from the client during 1053 Peer Discovery to indicate the desired Heartbeat timeout window. 1054 If included in the Peer Discovery, the server MUST either accept the 1055 timeout interval, or reject the Peer Discovery. Failing to include 1056 the Heartbeat Interval Sub-TLV in Peer Discovery indicates a 1057 desire to establish the peer-to-peer DLEP session without an 1058 activity timeout (e.g. an infinite timeout value). 1060 The Heartbeat Interval Sub-TLV contains the following fields: 1062 0 1 2 3 1063 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 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 |TLV Type =TBD |TLV Flags=0x10 |Length = 1 | Interval | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 TLV Type - TBD 1070 TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other bits are 1071 not used and MUST be set to '0'. 1073 Length - 1 1075 Interval - 0 = Do NOT use heartbeats on this peer-to-peer 1076 session. Non-zero = Interval, in seconds, for 1077 heartbeat messages. 1079 10.15 Heartbeat Threshold Sub-TLV 1081 The Heartbeat Threshold Sub-TLV MAY be sent from the client during 1082 Peer Discovery to indicate the desired number of windows, of time 1083 (Heartbeat Interval) seconds, to wait before either peer declares 1084 the peer session lost. In this case, the overall amount of time 1085 before a peer session is declared lost is expressed as 1086 (Interval * Threshold), where 'Interval' is the value in the 1087 Heartbeat Interval sub-TLV, documented above. If this sub-TLV is 1088 included by the client in the Peer Discovery, the client MUST also 1089 specify the Heartbeat Interval sub-TLV with a non-zero interval. If 1090 this sub-TLV is received during Peer Discovery, the server MUST 1091 either accept the threshold, or reject the Peer Discovery. If the 1092 Heartbeat Interval Sub-TLV is included, but this Sub-TLV is 1093 omitted, then a threshold of '1' is assumed. 1095 The Heartbeat Threshold Sub-TLV contains the following fields: 1097 0 1 2 3 1098 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 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 |TLV Type =TBD |TLV Flags=0x10 |Length = 1 | Threshold | 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 TLV Type - TBD 1105 TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other bits are 1106 not used and MUST be set to '0'. 1108 Length - 1 1110 Threshold - 0 = Do NOT use heartbeats on this peer-to-peer 1111 session. Non-zero = Number of windows, of 1112 Heartbeat Interval seconds, to wait before 1113 declaring a peer-to-peer session to be lost. 1115 10.16 Link Characteristics ACK Timer Sub-TLV 1117 The Link Characteristic ACK Timer Sub-TLV MAY be sent from the 1118 client during Peer Discovery to indicate the desired number of 1119 seconds the server should wait for a response to a Link 1120 Characteristics Request. If this sub-TLV is received during Peer 1121 Discovery, the server MUST either accept the timeout value, or 1122 reject the Peer Discovery. If this Sub-TLV is omitted, 1123 implementations SHOULD choose a default value. 1125 The Link Characteristics ACK Timer Sub-TLV contains the 1126 following fields: 1128 0 1 2 3 1129 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 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 |TLV Type =TBD |TLV Flags=0x10 |Length = 1 | Interval | 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 TLV Type - TBD 1136 TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other bits are 1137 not used and MUST be set to '0'. 1139 Length - 1 1141 Interval - 0 = Do NOT use timeouts for Link Characteristics 1142 requests on this peer-to-peer session. 1143 Non-zero = Interval, in seconds, to wait before 1144 considering a Link Characteristics Request has 1145 been lost. 1147 10.17 Credit Window Status Sub-TLV 1149 The Credit Window Status Sub-TLV MUST be sent by the DLEP peer 1150 originating a Neighbor Up message when use of credits is desired 1151 for a given session. In the Neighbor Up message, when credits 1152 are desired, the originating peer MUST set the value of the 1153 window it controls (e.g. the Client Receive Window, or Server 1154 Receive Window) to an initial, non-zero value. The peer receiving 1155 a Neighbor Up message with a Credit Window Status Sub-TLV MUST 1156 either reject the use of credits, via a Neighbor Up ACK response 1157 with the correct Status Sub-TLV, or set the initial value from 1158 the data contained in the Credit Window Status Sub-TLV. If the 1159 initialization completes successfully, the receiving peer MUST 1160 respond to the Neighbor Up message with a Neighbor Up ACK message 1161 that contains a Credit Window Status Sub-TLV, initializing its 1162 receive window. 1164 The Credit Window Status Sub-TLV contains the following fields: 1166 0 1 2 3 1167 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 1168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1169 |TLV Type =TBD |TLV Flags=0x10 |Length = 16 | Client Receive| 1170 | | | | Window value | 1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1172 | Client Receive Window Value | 1173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1174 | Client Receive Window Value | Server Receive| 1175 | | Window Value | 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1177 | Server Receive Window Value | 1178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1179 | Server Receive Window Value | 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1182 TLV Type - TBD 1184 TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other bits 1185 are not used and MUST be set to '0'. 1187 Length - 16 1189 Client Receive - A 64-bit unsigned number, indicating the 1190 Window value current (or initial) number of credits 1191 available on the Client Receive Window. 1193 Server Receive - A 64-bit unsigned number, indicating the 1194 Window Value current (or initial) number of credits 1195 available on the Server Receive Window. 1197 10.18 Credit Grant Sub-TLV 1199 The Credit Grant Request Sub-TLV MAY be sent from either DLEP 1200 peer to grant an increment to credits on a window. The Credit 1201 Grant Sub-TLV is sent as part of a Neighbor Update message. The 1202 value in a Credit Grant Sub-TLV represents an increment to be 1203 added to any existing credits available on the window. Upon 1204 successful receipt and processing of a Credit Grant Sub-TLV, the 1205 receiving peer SHOULD respond with a DLEP Neighbor Update message 1206 containing a Credit Window Status Sub-TLV to report the updated 1207 aggregate values for synchronization purposes. 1209 The Credit Grant Sub-TLV contains the following fields: 1211 0 1 2 3 1212 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 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1214 |TLV Type =TBD |TLV Flags=0x10 |Length = 8 | Credit | 1215 | | | | Increment | 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 | Credit Increment | 1218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1219 | Credit Increment | 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 TLV Type - TBD 1224 TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other bits 1225 are not used and MUST be set to '0'. 1227 Length - 0 1229 Reserved - A 64-bit unsigned number representing the 1230 additional credits to be assigned to the 1231 credit window. Since credits can only be 1232 granted by the receiver on a window, the 1233 applicable credit window (either the CRW or 1234 the SRW) is derived from the sender of the 1235 grant. The Credit Increment MUST NOT cause 1236 the window to overflow; if this condition 1237 occurs, implementations MUST set the credit 1238 window to the maximum value contained in a 1239 64-bit quantity. 1241 10.19 Credit Request Sub-TLV 1243 The Credit Request Sub-TLV MAY be sent from either DLEP peer, via 1244 a Neighbor Update order, to indicate the desire for the partner to 1245 grant additional credits in order for data transfer to proceed on 1246 the session. If the corresponding Neighbor Up message for this 1247 session did NOT contain a Credit Window Status Sub-TLV, indicating 1248 that credits are to be used on the session, then the Credit Request 1249 Sub-TLV MUST be rejected, by sending a Neighbor Update ACK containing 1250 a Status Sub-TLV, by the receiving peer. If credits are in use on 1251 the session, then the receiving peer MAY respond with a DLEP 1252 Neighbor Update message containing a Credit Grant Sub-TLV with 1253 an increment of credits for the session. 1255 The Credit Request Sub-TLV contains the following fields: 1257 0 1 2 3 1258 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 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 |TLV Type =TBD |TLV Flags=0x10 |Length = 0 | Reserved, MUST| 1261 | | | | be set to 0 | 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 TLV Type - TBD 1266 TLV Flags - 0x10, Bit 3 (thasvalue) is set, all other bits 1267 are not used and MUST be set to '0'. 1269 Length - 0 1271 Reserved - 0 = This field is currently unused and MUST be 1272 set to 0. 1274 11. DLEP Protocol Messages 1276 DLEP places no additional requirements on the RFC 5444 Packet 1277 formats, or the packet header. DLEP does require that the optional 1278 'msg-seq-num' in the message header exist, and defines a set of 1279 values for the 'tlv-type' field in the RFC 5444 TLV block. Therefore, 1280 a DLEP message, starting from the RFC 5444 Message header, would 1281 appear as follows: 1283 0 1 2 3 1284 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 1285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1286 | Msg Type = |Msg Flg|AddrLen| Message Size | 1287 | DLEP_MESSAGE | 0x1 | 0x0 | | 1288 | (value TBD) | | | | 1289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1290 | Message Seq Num | TLV block length (length of | 1291 | | DLEP order + Sub-TLVs) | 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 | DLEP Message |TLV Flags=0x10 | Length | Start of DLEP | 1294 | Block value | | | Sub-TLVs... | 1295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1297 11.1 Message Block TLV Values 1299 As mentioned above, all DLEP messages utilize a single RFC 5444 1300 message type, the DLEP_MESSAGE (TBD). DLEP further identifies 1301 protocol messages by using the 'tlv-type' field in the RFC 5444 1302 message TLV block. DLEP defines the following Message-Type- 1303 specific values for the tlv-type field: 1305 TLV TLV 1306 Value Description 1307 ========================================= 1308 TBD Attached Peer Discovery 1309 TBD Detached Peer Discovery 1310 TBD Peer Offer 1311 TBD Peer Update 1312 TBD Peer Update ACK 1313 TBD Peer Termination 1314 TBD Peer Termination ACK 1315 TBD Neighbor Up 1316 TBD Neighbor Up ACK 1317 TBD Neighbor Down 1318 TBD Neighbor Down ACK 1319 TBD Neighbor Update 1320 TBD Neighbor Address Update 1321 TBD Neighbor Address Update ACK 1322 TBD Heartbeat 1323 TBD Link Characteristics Request 1324 TBD Link Characteristics ACK 1326 In all of the diagrams following, the message layouts begin with the 1327 RFC 5444 message header. 1329 12. Peer Discovery Messages 1331 There are two different types of Peer Discovery Messages, Attached 1332 and Detached. Attached Peer Discovery Messages are sent by the 1333 client when it is directly attached to the server (e.g. the client 1334 exists as a card in the chassis, or it is connected via Ethernet with 1335 no intervening devices). The Detached Peer Discovery message, on the 1336 other hand, is sent by a "remote" client -- for example, a client at 1337 a satellite hub system might use a Detached Discovery Message in 1338 order to act as a proxy for remote ground terminals. To explain in 1339 another way, a detached client uses the variable link itself (the 1340 radio or satellite link) to establish a DLEP session with a remote 1341 server. 1343 12.1 Attached Peer Discovery Message 1345 The Attached Peer Discovery Message is sent by an attached client 1346 to a server to begin a new DLEP association. The Peer Offer message 1347 is required to complete the discovery process. The client MAY 1348 implement its own retry heuristics in the event it (the client) 1349 determines the Attached Peer Discovery Message has timed out. An 1350 Attached Peer Discovery Message received from a peer that is already 1351 in session MUST be processed as if a Peer Termination Message had 1352 been received. An implementation MAY then process the received 1353 Attached Peer Discovery Message. 1355 Note that metric Sub-TLVs MAY be supplied with the Peer Discovery 1356 order. If metric Sub-TLVs are supplied, they MUST be used as a 1357 default value for all neighbor sessions established via this peer. 1359 The Attached Peer Discovery Message contains the following fields: 1361 0 1 2 3 1362 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 1363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1364 | Msg Type = |Msg Flg|AddrLen| Message Size | 1365 | DLEP_MESSAGE | 0x1 | 0x0 | 22 + size of opt | 1366 | (value TBD) | | | sub-TLV | 1367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1368 | Message Seq Num |TLVs Length =14 + opt sub-TLVs | 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 | DLEP Attached |TLV Flags=0x10 | Length =11 + | Sub-TLVs | 1371 | Peer Discovery| | opt sub-TLVs | as noted below| 1372 | (Value TDB) | | | | 1373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 Message Type - DLEP_MESSAGE (value TBD) 1377 Message Flags - Set to 0x1 (bit 3, mhasseqnum 1378 bit is set). No other bits are 1379 used and MUST be set to '0'. 1381 Message Address Length - 0x0 1383 Message Size - 22 + size of optional sub-TLVs 1385 Message Sequence Number - A 16-bit unsigned integer field 1386 containing a sequence number 1387 generated by the message 1388 originator. 1390 TLV Block - TLVs Length: 14 + size of optional 1391 sub-TLVs. 1393 Sub-TLVs: 1394 Identification (MANDATORY) 1395 Version (OPTIONAL) 1396 Peer Type (OPTIONAL) 1397 Heartbeat Interval (OPTIONAL) 1398 Heartbeat Threshold (OPTIONAL) 1399 Link Characteristics ACK Timer 1400 (OPTIONAL) 1401 Maximum Data Rate (OPTIONAL) 1402 Current Data Rate (OPTIONAL) 1403 Latency (OPTIONAL) 1404 Expected Forwarding Time (OPTIONAL) 1405 Resources (OPTIONAL) 1406 Relative Link Quality (OPTIONAL) 1408 12.2 Detached Peer Discovery Message 1410 The Detached Peer Discovery Message is sent by a detached client 1411 proxy to a server to begin a new DLEP session. The Peer Offer 1412 message is required to complete the discovery process. The client 1413 MAY implement its own retry heuristics in the event it (the client) 1414 determines the Detached Peer Discovery Message has timed out. When 1415 a DLEP implementation responds to a Detached Discovery Message with 1416 a Peer Offer, the implementation MUST enter an "in session" state 1417 with the peer. Any subsequent discovery message received from the 1418 peer MUST be processed as if a Peer Termination Message had been 1419 received (e.g. the existing peer session MUST be terminated). An 1420 implementation MAY then process the received discovery message. 1422 If metric sub-TLVs (e.g. Maximum Data Rate) are supplied with the 1423 Detached Peer Discovery message, these metrics MUST be used as the 1424 initial values for all far-end sessions (neighbors) established via 1425 the peer. 1427 The Detached Peer Discovery Message contains the following fields: 1429 0 1 2 3 1430 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 1431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 | Msg Type = |Msg Flg|AddrLen| Message Size | 1433 | DLEP_MESSAGE | 0x1 | 0x0 | 22 + size of opt | 1434 | (value TBD) | | | sub-TLV | 1435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1436 | Message Seq Num |TLVs Length =14 + opt sub-TLVs | 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1438 | DLEP Detached |TLV Flags=0x10 | Length = 11 + | Sub-TLVs as | 1439 | Peer Discovery| | opt sub-TLVs | noted below | 1440 | (Value TDB) | | | | 1441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1443 Message Type - DLEP_MESSAGE (value TBD) 1445 Message Flags - Set to 0x1 (bit 3, 1446 mhasseqnum bit is set). 1447 All other bits are not used 1448 and MUST be set to '0'. 1450 Message Address Length - 0x0 1452 Message Size - 22 + size of optional 1453 sub-TLVs 1455 Message Sequence Number - A 16-bit unsigned integer 1456 field containing a sequence 1457 number, generated by the 1458 message originator. 1460 TLV Block - TLVs Length: 14 + size of 1461 optional sub-TLVs. 1463 Sub-TLVs 1464 Identification (MANDATORY) 1465 Version (OPTIONAL) 1466 Peer Type (OPTIONAL) 1467 Heartbeat Interval (OPTIONAL) 1468 Heartbeat Threshold (OPTIONAL) 1469 Link Char. ACK Timer (OPTIONAL) 1470 Maximum Data Rate (OPTIONAL) 1471 Current Data Rate (OPTIONAL) 1472 Latency (OPTIONAL) 1473 Expected Forwarding Time (OPTIONAL) 1474 Resources (OPTIONAL) 1475 Relative Link Quality (OPTIONAL) 1477 As in the Attached Peer Discovery, the client MAY include metric 1478 sub-TLVs. If included, the router SHOULD use these values as defaults 1479 that will apply to all sessions established via this client. 1481 13. Peer Offer Message 1483 The Peer Offer Message is sent by a server to a client in response 1484 to a Peer Discovery Message. The Peer Offer Message is the response 1485 to either of the Peer Discovery messages (Attached or Detached), 1486 and completes the DLEP peer session establishment. Upon sending the 1487 Peer Offer Message, the server then enters an "in session" state 1488 with the client. From the client perspective, receipt and successful 1489 parsing of a Peer Offer order MUST cause the client to enter the "in 1490 session" state. Any subsequent Discovery messages sent or received 1491 on this session MUST be considered an error, and the session MUST be 1492 terminated as if a Peer Termination Message had been received. 1494 The Peer Offer Message contains the following fields: 1496 0 1 2 3 1497 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 1498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1499 | Msg Type = |Msg Flg|AddrLen| Message Size | 1500 | DLEP_MESSAGE | 0x1 | 0x0 | 22 + size of opt | 1501 | (value TBD) | | | sub-TLV | 1502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 | Message Seq Num |TLVs Length =14 + opt sub-TLVs | 1504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1505 |DLEP Peer Offer|TLV Flags=0x10 | Length = 11 + | Sub-TLVs as | 1506 | (Value TBD) | | opt sub-TLVs | indicated | 1507 | | | | below | 1508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1510 Message Type - DLEP_MESSAGE (Value TBD) 1512 Message Flags - Set to 0x1 (bit 3, mhasseqnum bit 1513 is set). All other bits are unused and 1514 MUST be set to '0'. 1516 Message Address Length - 0x0 1518 Message Size - 22 + size of optional sub-TLVs 1520 Message Sequence Number - A 16-bit unsigned integer field containing 1521 a sequence number, generated by the message 1522 originator. 1524 TLV Block - TLV Length: 14 + size of optional sub-TLVs 1526 Sub TLVs 1527 Identification (MANDATORY) 1528 Version (OPTIONAL) 1529 Peer Type (OPTIONAL) 1530 IPv4 Address (OPTIONAL) 1531 IPv6 Address (OPTIONAL) 1532 Status (OPTIONAL) 1533 Heartbeat Interval (OPTIONAL) 1534 Heartbeat Threshold (OPTIONAL) 1535 Link Characteristics ACK Timer (OPTIONAL) 1537 14. Peer Update Message 1539 The Peer Update message is sent by a DLEP peer to indicate local 1540 Layer 3 address changes, or for metric changes on a device-wide 1541 basis. For example, addition of an IPv4 address to the server would 1542 prompt a Peer Update message to its attached DLEP clients. Also, a 1543 client that changes its Maximum Data Rate for all destinations MAY 1544 reflect that change via a Peer Update Message to its attached server. 1546 With Layer 3 address changes, if the client is capable of 1547 understanding and forwarding this information, the address update 1548 would prompt any remote DLEP clients (DLEP clients that are on the 1549 far-end of the variable link) to issue a "Neighbor Update" message to 1550 their local servers with the new (or deleted) addresses. Clients that 1551 do not track Layer 3 addresses MUST silently parse and ignore the Peer 1552 Update Message. Clients that track Layer 3 addresses MUST acknowledge 1553 the Peer Update with a Peer Update ACK message. Servers receiving a 1554 Peer Update with metric changes MUST apply the new metric to all 1555 neighbor sessions established via the client. Peers MAY employ 1556 heuristics to retransmit Peer Update messages. The sending of Peer 1557 Update Messages for Layer 3 address changes SHOULD cease when a server 1558 implementation determines that a client does NOT support Layer 3 1559 address tracking. 1561 If metric Sub-TLVs are supplied with the Peer Update message (e.g. 1562 Maximum Data Rate), these metrics MUST be applied to all neighbor 1563 sessions accessible via the peer. 1565 The Peer Update Message contains the following fields: 1567 0 1 2 3 1568 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 1569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1570 | Msg Type = |Msg Flg|AddrLen| Message Size | 1571 | DLEP_MESSAGE | 0x1 | 0x0 | 22 + size of opt | 1572 | (value TBD) | | | sub-TLVs | 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1574 | Message Seq Num |TLVs Length =14 + opt sub-TLVs | 1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 | DLEP Peer |TLV Flags=0x10 | Length = 11 + | Sub-TLVs as | 1577 | Update | | opt sub-TLVs | noted below | 1578 | (Value TDB) | | | | 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 Message Type - DLEP_MESSAGE (Value TBD) 1582 Message Flags - Set to 0x1 (bit 3, mhasseqnum bit 1583 is set). All other bits are unused and 1584 MUST be set to '0'. 1586 Message Address Length - 0x0 1588 Message Size - 22 + optional Sub-TLVs 1590 Message Sequence Number - A 16-bit unsigned integer containing a 1591 sequence number (generated by originator). 1593 TLV Block - TLV Length: 14 + length of optional 1594 sub-TLVs. 1595 Sub TLVs 1596 Identification (MANDATORY) 1597 IPv4 Address (OPTIONAL) 1598 IPv6 Address (OPTIONAL) 1599 Maximum Data Rate (OPTIONAL) 1600 Current Data Rate (OPTIONAL) 1601 Latency (OPTIONAL) 1602 Expected Forwarding Time (OPTIONAL) 1603 Resources (OPTIONAL) 1604 Relative Link Quality (OPTIONAL) 1606 15. Peer Update ACK Message 1608 A peer sends the Peer Update ACK Message to indicate whether a 1609 Peer Update Message was successfully processed. 1611 The Peer Update ACK message contains the following fields: 1613 0 1 2 3 1614 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 1615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1616 | Msg Type = |Msg Flg|AddrLen| Message Size | 1617 | DLEP_MESSAGE | 0x1 | 0x0 | 22 + size of opt | 1618 | (value TBD) | | | sub-TLVs | 1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1620 | Message Seq Num |TLVs Length =14 + opt sub-TLVs | 1621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1622 | DLEP Peer |TLV Flags=0x10 | Length = 11 + | Sub-TLVs as | 1623 | Update ACK | | opt sub-TLVs | noted below | 1624 | (Value TDB) | | | | 1625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1627 Message Type - DLEP_MESSAGE (Value TBD) 1629 Message Flags - Set to 0x1 (bit 3, mhasseqnum bit 1630 is set). All other bits are unused and 1631 MUST be set to '0'. 1633 Message Address Length - 0x0 1634 Message Size - 22 + size of optional sub-TLVs. 1636 Message Sequence Number - A 16-bit unsigned integer field containing 1637 the sequence number from the Neighbor Up 1638 Message that is being acknowledged. 1640 TLV Block - TLV Length: 14 + optional sub-TLVs 1642 Sub TLVs 1643 Identification (MANDATORY) 1644 Status (OPTIONAL) 1646 16. Peer Termination Message 1648 The Peer Termination Message is sent by either the client or the 1649 server when a session needs to be terminated. Transmission of a 1650 Peer Termination ACK message is required to confirm the 1651 termination process. The sender of the Peer Termination message 1652 is free to define its heuristics in event of a timeout. The 1653 receiver of a Peer Termination Message MUST terminate all 1654 neighbor sessions and release associated resources. State 1655 machines are returned to the "discovery" state. No Neighbor Down 1656 messages are sent. 1658 The Peer Termination Message contains the following fields: 1660 0 1 2 3 1661 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 1662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1663 | Msg Type = |Msg Flg|AddrLen| Message Size | 1664 | DLEP_MESSAGE | 0x1 | 0x0 | 22 + size of opt | 1665 | (value TBD) | | | sub-TLVs | 1666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1667 | Message Seq Num |TLVs Length =14 + opt sub-TLVs | 1668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1669 | DLEP Peer |TLV Flags=0x10 | Length = 11 + | Sub-TLVs as | 1670 | Termination | | opt sub-TLVs | noted below | 1671 | (Value TDB) | | | | 1672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1674 Message Type - DLEP_MESSAGE (Value TBD) 1676 Message Flags - Set to 0x1 (bit 3, mhasseqnum 1677 bit is set). All other bits are 1678 unused and MUST be set to '0'. 1680 Message Address Length - 0x0 1682 Message Size - 22 + size of optional sub-TLVs. 1684 Message Sequence Number - A 16-bit unsigned integer field 1685 containing a sequence number 1686 generated by the message originator. 1688 TLV Block - TLV Length = 14 + optional sub-TLVs 1690 Sub TLVs 1691 Identification (MANDATORY) 1692 Status (OPTIONAL) 1694 17. Peer Termination ACK Message 1696 The Peer Termination Message ACK is sent by a DLEP peer in response 1697 to a received Peer Termination order. 1699 The Peer Termination ACK Message contains the following fields: 1701 0 1 2 3 1702 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 1703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1704 | Msg Type = |Msg Flg|AddrLen| Message Size | 1705 | DLEP_MESSAGE | 0x1 | 0x0 | 22 + size of opt | 1706 | (value TBD) | | | sub-TLVs | 1707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1708 | Message Seq Num |TLVs Length =14 + opt sub-TLVs | 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1710 | DLEP Peer Term|TLV Flags=0x10 | Length = 11 + | Sub-TLVs as | 1711 | ACK | | opt sub-TLVs | noted below | 1712 | (Value TBD) | | | | 1713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1715 Message Type - DLEP_MESSAGE (Value TBD) 1717 Message Flags - Set to 0x1 (bit 3, mhasseqnum 1718 bit is set). All other bits are 1719 unused and MUST be set to '0'. 1721 Message Address Length - 0x0 1723 Message Size - 22 + optional sub-TLVs. 1725 Message Sequence Number - A 16-bit unsigned integer field 1726 containing the sequence number in 1727 the corresponding Peer Termination 1728 Message being acknowledged. 1730 TLV Block - TLV Length = 14 + optional Sub-TLVs 1732 Sub-TLVs 1733 Identification (MANDATORY) 1734 Status (OPTIONAL) 1736 18. Neighbor Up Message 1738 A peer sends the Neighbor Up message to report that a new 1739 potential routing neighbor, or a new destination within the 1740 network, has been detected. A Neighbor Up ACK Message is required 1742 to confirm a received Neighbor Up. A Neighbor Up message can be 1743 sent by a client to signal that it (the client) has detected a new 1744 neighbor, or by the server to indicate that new destinations 1745 (e.g. Multicast groups) exist within the network. 1747 The sender of the Neighbor Up Message is free to define its 1748 retry heuristics in event of a timeout. When a Neighbor Up 1749 message is received and successfully parsed, the receiver 1750 should enter an "in session" state with regard to the far-end 1751 destination, and send an acknowledgement to the originating peer. 1753 The Neighbor Up Message 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 | Msg Type = |Msg Flg|AddrLen| Message Size | 1759 | DLEP_MESSAGE | 0x1 | 0x0 | 31 + size of opt | 1760 | (value TBD) | | | sub-TLVs | 1761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1762 | Message Seq Num |TLVs Length =23 + opt sub-TLVs | 1763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1764 | DLEP Neighbor |TLV Flags=0x10 | Length =20 + | Sub-TLVs as | 1765 | Up (TBD) | | opt sub-TLVs | noted below | 1766 | | | | | 1767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1769 Message Type - DLEP_MESSAGE (Value TBD) 1771 Message Flags - Set to 0x1 (bit 3, mhasseqnum bit 1772 is set). All other bits are unused and 1773 MUST be set to '0'. 1775 Message Address Length - 0x0 1777 Message Size - 31 + optional Sub-TLVs 1779 Message Sequence Number - A 16-bit unsigned integer field containing 1780 a sequence number generated by the message 1781 originator. 1783 TLV Block - TLV Length: 23 + optional Sub-TLVs. 1785 Sub-TLVs 1786 Identification (MANDATORY) 1787 MAC Address (MANDATORY) 1788 IPv4 Address (OPTIONAL) 1789 IPv6 Address (OPTIONAL) 1790 Maximum Data Rate (OPTIONAL) 1791 Current Data Rate (OPTIONAL) 1792 Latency (OPTIONAL) 1793 Expected Forwarding Time (OPTIONAL) 1794 Resources (OPTIONAL) 1795 Relative Link Factor (OPTIONAL) 1796 Credit Window Status (OPTIONAL) 1798 19. Neighbor Up ACK Message 1800 A peer sends the Neighbor Up ACK Message to indicate whether a 1801 Neighbor Up Message was successfully processed. When a peer 1802 receives a Neighbor Up ACK message containing a Status Sub-TLV 1803 with a status code of 0, the receiving peer should enter an "in 1804 session" state with respect to the far-end destination. 1806 The Neighbor Up ACK message contains the following fields: 1808 0 1 2 3 1809 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 1810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1811 | Msg Type = |Msg Flg|AddrLen| Message Size | 1812 | DLEP_MESSAGE | 0x1 | 0x0 | 35 | 1813 | (value TBD) | | | | 1814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1815 | Message Seq Num |TLVs Length = 27 | 1816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1817 | DLEP Neighbor |TLV Flags=0x10 | Length = 24 | Sub-TLVs as | 1818 | Up ACK (TBD) | | | noted below | 1819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1821 Message Type - DLEP_MESSAGE (Value TBD) 1823 Message Flags - Set to 0x1 (bit 3, mhasseqnum bit 1824 is set). All other bits are unused and 1825 MUST be set to '0'. 1827 Message Address Length - 0x0 1829 Message Size - 35 1831 Message Sequence Number - A 16-bit unsigned integer field containing 1832 the sequence number from the Neighbor Down 1833 Message that is being acknowledged. 1835 TLV Block - TLV Length: 27 1837 Sub-TLVs - Identification (MANDATORY) 1838 MAC Address Sub-TLV (MANDATORY) 1839 Status Sub-TLV (MANDATORY) 1840 Credit Window Status (OPTIONAL) 1842 20. Neighbor Down Message 1844 A DLEP peer sends the Neighbor Down message to report when a 1845 destination (a routing peer or a multicast group) is no longer 1846 reachable. The Neighbor Down message MUST contain a MAC Address TLV. 1847 Any other TLVs present MAY be ignored. A Neighbor Down ACK Message is 1848 required to confirm the process. The sender of the Neighbor Down 1849 message is free to define its retry heuristics in event of a timeout. 1850 Upon successful receipt and parsing of a Neighbor Down message, the 1851 receiving peer MUST remove all state information for the destination, 1852 and send a Neighbor Down ACK message to the originating peer. 1854 The Neighbor Down Message contains the following fields: 1856 0 1 2 3 1857 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 1858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1859 | Msg Type = |Msg Flg|AddrLen| Message Size | 1860 | DLEP_MESSAGE | 0x1 | 0x0 | 31 + optional | 1861 | (value TBD) | | | sub-TLV | 1862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1863 | Message Seq Num | TLVs Length = 23 + optional | 1864 | | Sub-TLV | 1865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1866 | TLV Type = |TLV Flags=0x10 | Length = 20 + | Sub-TLVs as | 1867 | DLEP Neighbor | | optional Sub- | noted below | 1868 | Down (TBD) | | TLV | | 1869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1871 Message Type - DLEP_MESSAGE (Value TBD) 1873 Message Flags - Set to 0x1 (bit 3, mhasseqnum bit 1874 is set). All other bits are unused and 1875 MUST be set to '0'. 1877 Message Address Length - 0x0 1879 Message Size - 31 + optional TLVs 1881 Message Sequence Number - A 16-bit unsigned integer field 1882 containing a sequence number generated 1883 by the message originator. 1885 TLV Block - TLV Length: 23 + optional Sub-TLVs 1887 Sub TLVs 1888 Identification (MANDATORY) 1889 MAC Address (MANDATORY) 1890 Status (OPTIONAL) 1892 21. Neighbor Down ACK Message 1894 A peer sends the Neighbor Down ACK Message to indicate whether 1895 a received Neighbor Down Message was successfully processed. If 1896 successfully processed, the sending peer MUST remove all state 1897 information on the referenced neighbor session. 1899 The Neighbor Down ACK message contains the following fields: 1901 0 1 2 3 1902 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 1903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1904 | Msg Type = |Msg Flg|AddrLen| Message Size | 1905 | DLEP_MESSAGE | 0x1 | 0x0 | 35 | 1906 | (value TBD) | | | | 1907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1908 | Message Seq Num |TLVs Length = 27 | 1909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1910 | DLEP Neighbor |TLV Flags=0x10 | Length = 24 | Sub-TLVs as | 1911 | Down ACK (TBD)| | | noted below | 1912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1914 Message Type - DLEP_MESSAGE (Value TBD) 1916 Message Flags - Set to 0x1 (bit 3, mhasseqnum bit 1917 is set). All other bits are unused and 1918 MUST be set to '0'. 1920 Message Address Length - 0x0 1922 Message Size - 35 1924 Message Sequence Number - A 16-bit unsigned integer field containing 1925 the sequence number from the Neighbor Down 1926 Message that is being acknowledged. 1928 TLV Block - TLV Length: 27 1930 Sub-TLVs - Identification (MANDATORY) 1931 MAC Address (MANDATORY) 1932 Status (MANDATORY) 1934 22. Neighbor Update Message 1936 The client sends the Neighbor Update message when a change in link 1937 metric parameters is detected for a destination. 1939 The Neighbor Update Message contains the following fields: 1941 0 1 2 3 1942 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 1943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1944 | Msg Type = |Msg Flg|AddrLen| Message Size | 1945 | DLEP_MESSAGE | 0x1 | 0x0 | 31 + optional | 1946 | (value TBD) | | | sub-TLV | 1947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1948 | Message Seq Num | TLVs Length = 23 + optional | 1949 | | Sub-TLVs | 1950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1951 |TLV Type = |TLV Flags=0x10 |Length = 20 + |Sub-TLVs as | 1952 |DLEP Neighbor | |optional Sub- |noted below | 1953 |Update (TBD) | |TLVs | | 1954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1955 Message Type - DLEP_MESSAGE (Value TBD) 1957 Message Flags - Set to 0x1 (bit 3, mhasseqnum 1958 bit is set). All other bits are 1959 unused and MUST be set to '0'. 1961 Message Address Length - 0x0 1963 Message Size - 31 + optional TLVs 1965 Message Sequence Number - A 16-bit unsigned integer field 1966 containing a sequence number, 1967 generated by the message originator. 1969 TLV Block - TLVs Length - 23 + optional Sub-TLVs. 1971 Sub TLVs 1972 Identification (MANDATORY) 1973 MAC Address (MANDATORY) 1974 Maximum Data Rate (OPTIONAL) 1975 Current Data Rate (OPTIONAL) 1976 Latency (OPTIONAL) 1977 Resources (OPTIONAL) 1978 Relative Link Quality (OPTIONAL) 1979 Credit Window Status (OPTIONAL) 1980 Credit Grant (OPTIONAL) 1981 Credit Request (OPTIONAL) 1983 23. Neighbor Address Update Message 1985 The client sends the Neighbor Address Update message when a change 1986 in Layer 3 addressing is detected for a neighbor session. 1988 The Neighbor Address Update Message contains the following fields: 1990 0 1 2 3 1991 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 1992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1993 | Msg Type = |Msg Flg|AddrLen| Message Size | 1994 | DLEP_MESSAGE | 0x1 | 0x0 | 31 + size of opt | 1995 | (value TBD) | | | sub-TLVs | 1996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1997 | Message Seq Num |TLVs Length =23 + opt sub-TLVs | 1998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1999 | DLEP Neighbor |TLV Flags=0x10 | Length =20 + | Sub-TLVs as | 2000 | Address Update| | opt sub-TLVs | noted below | 2001 |(TBD) | | | | 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2004 Message Type - DLEP_MESSAGE (Value TBD) 2006 Message Flags - Set to 0x1 (bit 3, mhasseqnum bit is 2007 set). All other bits are unused and 2008 MUST be set to '0'. 2010 Message Address Length - 0x0 2012 Message Size - 31 + optional TLVs 2014 Message Sequence Number - A 16-bit unsigned integer field 2015 containing a sequence number, 2016 generated by the message originator. 2018 TLV Block - TLVs Length - 23 + optional Sub-TLVs. 2019 Sub TLVs 2020 Identification Sub-TLV (MANDATORY) 2021 MAC Address Sub-TLV (MANDATORY) 2022 IPv4 Address Sub-TLV (OPTIONAL) 2023 IPv6 Address Sub-TLV (OPTIONAL) 2025 24. Neighbor Address Update ACK Message 2027 The server sends the Neighbor Address Update ACK Message to 2028 indicate whether a Neighbor Address Update Message was 2029 successfully processed. 2031 The Neighbor Address Update ACK message contains the following 2032 fields: 2034 0 1 2 3 2035 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 2036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2037 | Msg Type = |Msg Flg|AddrLen| Message Size | 2038 | DLEP_MESSAGE | 0x1 | 0x0 | 35 | 2039 | (value TBD) | | | | 2040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2041 | Message Seq Num |TLVs Length = 27 | 2042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2043 | DLEP Neighbor |TLV Flags=0x10 | Length = 24 | Sub-TLVs as | 2044 | Address Update| | | noted below | 2045 | ACK (TBD) | | | | 2046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2048 Message Type - DLEP_MESSAGE (Value TBD) 2050 Message Flags - Set to 0x1 (bit 3, mhasseqnum bit 2051 is set). All other bits are unused and 2052 MUST be set to '0'. 2054 Message Address Length - 0x0 2056 Message Size - 35 2058 Message Sequence Number - A 16-bit unsigned integer field containing 2059 the sequence number from the Neighbor Down 2060 Message that is being acknowledged. 2062 TLV Block - TLV Length: 27 2063 Sub TLVs 2064 Identification Sub-TLV (MANDATORY) 2065 MAC Address Sub-TLV (MANDATORY) 2066 Status Sub-TLV (MANDATORY) 2068 25. Heartbeat Message 2070 A Heartbeat Message is sent by a peer every N seconds, where N is 2071 defined in the "Heartbeat Interval" field of the discovery message. 2072 The message is used by peers to detect when a DLEP session partner 2073 is no longer communicating. Peers SHOULD allow some integral number 2074 of heartbeat intervals (default 4) to expire with no traffic on the 2075 session before initiating DLEP session termination procedures. 2077 The Heartbeat Message contains the following fields: 2079 0 1 2 3 2080 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 2081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2082 | Msg Type = |Msg Flg|AddrLen| Message Size | 2083 | DLEP_MESSAGE | 0x1 | 0x0 | 22 | 2084 | (value TBD) | | | | 2085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2086 | Message Seq Num |TLVs Length = 14 | 2087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2088 | DLEP Heartbeat|TLV Flags=0x10 | Length = 11 | Sub-TLVs as | 2089 | (TBD) | | | noted below | 2090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2092 Message Type - DLEP_MESSAGE (Value TBD) 2094 Message Flags - Set to 0x1 (bit 3, mhasseqnum bit is 2095 set). All other bits are unused and SHOULD 2096 be set to '0'. 2098 Message Address Length - 0x0 2100 Message Size - 22 2102 Message Sequence Number - A 16-bit unsigned integer field containing 2103 a sequence number generated by the message 2104 originator. 2106 TLV Block - TLV Length = 14 2108 Sub TLVs - 2109 Identification Sub-TLV (MANDATORY) 2111 26. Link Characteristics Request Message 2113 The Link Characteristics Request Message is sent by the server to 2114 the client when the server detects that a different set of 2115 transmission characteristics is necessary (or desired) for the 2116 type of traffic that is flowing on the link. It is important to 2117 note that the link can be a logical link for a multicast session 2118 where more than one remote neighbor participates. The request 2119 contains either a Current Data Rate (CDR) TLV to request a different 2120 amount of bandwidth than what is currently allocated, a Latency 2121 TLV to request that traffic delay on the link not exceed the 2122 specified value, or both. A Link Characteristics ACK Message is 2123 required to complete the request. Implementations are free to 2124 define their retry heuristics in event of a timeout. Issuing a 2125 Link Characteristics Request with ONLY the MAC Address TLV is a 2126 mechanism a peer MAY use to request metrics (via the Link 2127 Characteristics ACK) from its partner. 2129 The Link Characteristics Request Message contains the following 2130 fields: 2132 0 1 2 3 2133 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 2134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2135 | Msg Type = |Msg Flg|AddrLen| Message Size | 2136 | DLEP_MESSAGE | 0x1 | 0x0 | 31 + size of opt | 2137 | (value TBD) | | | sub-TLVs | 2138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2139 | Message Seq Num |TLVs Length =23 + opt sub-TLVs | 2140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2141 | DLEP Link Char|TLV Flags=0x10 | Length =20 + | Sub-TLVs as | 2142 | Request (TBD) | | opt sub-TLVs | noted below | 2143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2145 Message Type - DLEP_MESSAGE (Value TBD) 2147 Message Flags - Set to 0x1 (bit 3, mhasseqnum bit 2148 is set). All other bits are unused and 2149 MUST be set to '0'. 2151 Message Address Length - 0x0 2153 Message Size - 31 + length of optional (Current Data 2154 Rate and/or Latency) Sub-TLVs 2156 Message Sequence Number - A 16-bit unsigned integer field containing 2157 a sequence number generated by the message 2158 originator. 2160 TLV Block - Length: 23 + optional Sub-TLVs 2162 Sub TLVs 2163 Identification Sub-TLV (MANDATORY) 2164 MAC Address Sub-TLV (MANDATORY) 2165 Current Data Rate Sub-TLV - if present, 2166 this value represents the requested data 2167 rate in bits per second (bps). (OPTIONAL) 2168 Latency TLV - if present, this value 2169 represents the maximum latency, in 2170 milliseconds, desired on the link. 2171 (OPTIONAL) 2173 27. Link Characteristics ACK Message 2175 The Link Characteristics ACK Message is sent by the client to the 2176 server letting the server know the success (or failure) of the 2177 requested change in link characteristics. The Link Characteristics 2178 ACK message SHOULD contain a complete set of metric TLVs. It MUST 2179 contain the same TLV types as the request. The values in the 2180 metric TLVs in the Link Characteristics ACK message MUST reflect 2181 the link characteristics after the request has been processed. 2183 The Link Characteristics ACK Message contains the following fields: 2185 0 1 2 3 2186 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 2187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2188 | Msg Type = |Msg Flg|AddrLen| Message Size | 2189 | DLEP_MESSAGE | 0x1 | 0x0 | 31 + size of opt | 2190 | (value TBD) | | | sub-TLVs | 2191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2192 | Message Seq Num |TLVs Length =23 + opt sub-TLVs | 2193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2194 | DLEP Link Char|TLV Flags=0x10 | Length =20 + | Sub-TLVs as | 2195 | ACK (TBD) | | opt sub-TLVs | noted below | 2196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2198 Message Type - DLEP_MESSAGE (Value TBD) 2200 Message Flags - Set to 0x1 (bit 3, mhasseqnum bit 2201 is set). All other bits are unused and 2202 MUST be set to '0'. 2204 Message Address Length - 0x0 2206 Message Size - 31 + length of optional (Current Data 2207 Rate and/or Latency) TLVs 2209 Message Sequence Number - A 16-bit unsigned integer field containing 2210 the sequence number that appeared on the 2211 corresponding Link Characteristics Request 2212 message. 2214 TLV Block - TLVs Length = 23 + Optional TLVs 2216 Sub TLVs 2217 Identification Sub-TLV (MANDATORY) 2218 MAC Address Sub-TLV (MANDATORY) 2219 Maximum Data Rate Sub-TLV (OPTIONAL) 2221 Current Data Rate Sub-TLV - if present, 2222 this value represents the NEW (or 2223 unchanged, if the request is denied) 2224 Current Data Rate in bits per second (bps). 2225 (OPTIONAL) 2226 Latency Sub-TLV - if present, this value 2227 represents the NEW maximum latency (or 2228 unchanged, if the request is denied), 2229 expressed in milliseconds, on the link. 2230 (OPTIONAL) 2232 Resources Sub-TLV (OPTIONAL) 2234 Relative Link Quality Sub-TLV (OPTIONAL) 2236 28. Security Considerations 2238 The protocol does not contain any mechanisms for security (e.g. 2239 authentication or encryption). The protocol assumes that any 2240 security would be implemented in the underlying transport (for 2241 example, by use of DTLS or some other mechanism), and is 2242 therefore outside the scope of this document. 2244 29. IANA Considerations 2246 This section specifies requests to IANA. 2248 29.1 TLV Registrations 2250 This specification defines: 2252 o One TLV types which must be allocated from the 0-223 range 2253 of the "Assigned Message TLV Types" repository of [RFC5444]. 2255 o A new repository for DLEP orders, with seventeen values currently 2256 assigned. 2258 o A new repository for DLEP Sub-TLV assignments with nineteen values 2259 currently assigned. 2261 29.2 Expert Review: Evaluation Guidelines 2263 For the registries for TLV type extensions where an Expert Review is 2264 required, the designated expert SHOULD take the same general 2265 recommendations into consideration as are specified by [RFC5444]. 2267 29.3 Message TLV Type Registration 2269 The Message TLV specified below must be allocated from the "Message 2270 TLV Types" namespace of [RFC5444]. 2272 o DLEP_MESSAGE 2274 29.4 DLEP Order Registration 2276 A new repository must be created with the values of the DLEP orders. 2277 Valid orders are: 2279 o Attached Peer Discovery Message 2280 o Detached Peer Discovery Message 2281 o Peer Offer Message 2282 o Peer Update Message 2283 o Peer Update ACK Message 2284 o Peer Termination Message 2285 o Peer Termination ACK Message 2286 o Neighbor Up Message 2287 o Neighbor Up ACK Message 2288 o Neighbor Down Message 2289 o Neighbor Down ACK Message 2290 o Neighbor Update Message 2291 o Neighbor Address Update Message 2292 o Neighbor Address Update ACK Message 2293 o Heartbeat Message 2294 o Link Characteristics Request Message 2295 o Link Characteristics ACK Message 2297 This registry should be created according to the guidelines for 2298 'Message-Type-Specific TLV' registration as specified in section 2299 6.2.1 of [RFC5444]. 2301 29.5 DLEP Sub-TLV Type Registrations 2303 A new repository for DLEP Sub-TLVs must be created. Valid Sub-TLVs are: 2305 o Identification Sub-TLV 2306 o DLEP Version Sub-TLV 2307 o Peer Type Sub-TLV 2308 o MAC Address Sub-TLV 2309 o IPv4 Address Sub-TLV 2310 o IPv6 Address Sub-TLV 2311 o Maximum Data Rate Sub-TLV 2312 o Current Data Rate Sub-TLV 2313 o Latency Sub-TLV 2314 o Expected Forwarding Time Sub-TLV 2315 o Resources Sub-TLV 2316 o Relative Link Quality Sub-TLV 2317 o Status Sub-TLV 2318 o Heartbeat Interval Sub-TLV 2319 o Heartbeat Threshold Sub-TLV 2320 o Link Characteristics ACK Timer Sub-TLV 2321 o Credit Window Status Sub-TLV 2322 o Credit Grant Sub-TLV 2323 o Credit Request Sub-TLV 2325 It is also requested that the registry allocation contain space 2326 reserved for experimental sub-TLVs. 2328 30. Appendix A. 2330 Peer Level Message Flows 2332 *Modem Device (Client) Restarts Discovery 2334 Server Client Message Description 2335 ==================================================================== 2337 <-------Peer Discovery--------- Client initiates discovery 2339 ---------Peer Offer-----------> Server detects a problem, sends 2340 w/ Non-zero Status TLV Peer Offer w/ Status TLV indicating 2341 the error. 2343 Client accepts failure, restarts 2344 discovery process. 2346 <-------Peer Discovery--------- Client initiates discovery 2348 ---------Peer Offer-----------> Server accepts, sends Peer Offer 2349 w/ Zero Status TLV w/ Status TLV indicating success. 2351 Discovery completed. 2353 *Modem Device Detects Peer Offer Timeout 2355 Server Client Message Description 2356 ==================================================================== 2358 <-------Peer Discovery--------- Client initiates discovery, 2359 starts a guard timer. 2361 Client guard timer expires. 2362 Client restarts discovery process. 2364 <-------Peer Discovery--------- Client initiates discovery, 2365 starts a guard timer. 2367 ---------Peer Offer-----------> Server accepts, sends Peer Offer 2368 w/ Zero Status TLV w/ Status TLV indicating success. 2370 Discovery completed. 2372 *Server Peer Offer Lost 2374 Server Client Message Description 2375 ==================================================================== 2377 <-------Peer Discovery--------- Client initiates discovery, 2378 starts a guard timer. 2380 ---------Peer Offer-------|| Server offers availability 2382 Client times out on Peer Offer, 2383 restarts discovery process. 2385 <-------Peer Discovery--------- Client initiates discovery 2387 ---------Peer Offer-----------> Server detects subsequent discovery, 2388 internally terminates the previous, 2389 accepts the new association, sends 2390 Peer Offer w/ Status TLV indicating 2391 success. 2393 Discovery completed. 2395 *Discovery Success 2397 Server Client Message Description 2398 ==================================================================== 2400 <-------Peer Discovery--------- Client initiates discovery 2402 ---------Peer Offer-----------> Server offers availability 2404 -------Peer Heartbeat---------> 2406 <-------Peer Heartbeat--------- 2408 -------Peer Heartbeat---------> 2410 <==============================> Neighbor Sessions 2412 <-------Peer Heartbeat--------- 2414 -------Peer Heartbeat---------> 2416 --------Peer Term Req---------> Terminate Request 2418 <--------Peer Term Res--------- Terminate Response 2420 *Server Detects a Heartbeat timeout 2422 Server Client Message Description 2423 ==================================================================== 2425 <-------Peer Heartbeat--------- 2427 -------Peer Heartbeat---------> 2429 ||---Peer Heartbeat--------- 2431 ~ ~ ~ ~ ~ ~ ~ 2433 -------Peer Heartbeat---------> 2435 ||---Peer Heartbeat--------- 2436 Server Heartbeat Timer expires, 2437 detects missing heartbeats. Server 2438 takes down all neighbor sessions 2439 and terminates the Peer association. 2441 ------Peer Terminate ---------> Peer Terminate Request 2443 Client takes down all neighbor 2444 sessions, then acknowledges the 2445 Peer Terminate 2447 <----Peer Terminate ACK--------- Peer Terminate ACK 2449 *Client Detects a Heartbeat timeout 2451 Server Client Message Description 2452 ==================================================================== 2454 <-------Peer Heartbeat--------- 2456 -------Peer Heartbeat------|| 2458 <-------Peer Heartbeat--------- 2460 ~ ~ ~ ~ ~ ~ ~ 2462 -------Peer Heartbeat------|| 2464 <-------Peer Heartbeat--------- 2465 Client Heartbeat Timer expires, 2466 detects missing heartbeats. Modem 2467 takes down all neighbor sessions 2468 and terminates the Peer association. 2470 <-------Peer Terminate-------- Peer Terminate Request 2472 Server takes down all neighbor 2473 sessions, then acknowledges the 2474 Peer Terminate 2476 ------Peer Terminate ACK-----> Peer Terminate ACK 2478 *Peer Terminate (from Client) Lost 2480 Server Client Message Description 2481 ==================================================================== 2483 ||------Peer Terminate-------- Client Peer Terminate Request 2485 Server Heartbeat times out, 2486 terminates association. 2488 --------Peer Terminate-------> Server Peer Terminate 2490 <-----Peer Terminate ACK------ Client sends Peer Terminate ACK 2492 *Peer Terminate (from server) Lost 2494 Server Client Message Description 2495 ==================================================================== 2497 -------Peer Terminate--------> Server Peer Terminate Request 2499 Client HB times out, 2500 terminates association. 2502 <------Peer Terminate-------- Client Peer Terminate 2504 ------Peer Terminate ACK-----> Peer Terminate ACK 2506 Neighbor Level Message Flows 2508 *Client Neighbor Up Lost 2510 Server Client Message Description 2511 ==================================================================== 2513 ||-----Neighbor Up ------------ Client sends Neighbor Up 2515 Client timesout on ACK 2517 <------Neighbor Up ------------ Client sends Neighbor Up 2519 ------Neighbor Up ACK---------> Server accepts the neighbor 2520 session 2522 <------Neighbor Update--------- Client Neighbor Metrics 2523 . . . . . . . . 2524 <------Neighbor Update--------- Client Neighbor Metrics 2526 *Server Detects Duplicate Neighbor Ups 2528 Server Client Message Description 2529 ==================================================================== 2531 <------Neighbor Up ------------ Client sends Neighbor Up 2533 ------Neighbor Up ACK-------|| Server accepts the neighbor 2534 session 2536 Client timesout on ACK 2538 <------Neighbor Up ------------ Client resends Neighbor Up 2540 Server detects duplicate 2541 Neighbor, takes down the 2542 previous, accepts the new 2543 Neighbor. 2545 ------Neighbor Up ACK---------> Server accepts the neighbor 2546 session 2548 <------Neighbor Update--------- Client Neighbor Metrics 2549 . . . . . . . . 2550 <------Neighbor Update--------- Client Neighbor Metrics 2552 *Neighbor Up, No Layer 3 Addresses 2554 Server Client Message Description 2555 ==================================================================== 2557 <------Neighbor Up ------------ Client sends Neighbor Up 2559 ------Neighbor Up ACK---------> Server accepts the neighbor 2560 session 2562 Server ARPs for IPv4 if defined. 2563 Server drives ND for IPv6 if 2564 defined. 2566 <------Neighbor Update--------- Client Neighbor Metrics 2567 . . . . . . . . 2568 <------Neighbor Update--------- Client Neighbor Metrics 2570 *Neighbor Up with IPv4, No IPv6 2572 Server Client Message Description 2573 ==================================================================== 2575 <------Neighbor Up ------------ Client sends Neighbor Up with 2576 the IPv4 TLV 2578 ------Neighbor Up ACK---------> Server accepts the neighbor 2579 session 2581 Server drives ND for IPv6 if 2582 defined. 2584 <------Neighbor Update--------- Client Neighbor Metrics 2585 . . . . . . . . 2586 <------Neighbor Update--------- Client Neighbor Metrics 2588 *Neighbor Up with IPv4 and IPv6 2590 Server Client Message Description 2591 ==================================================================== 2593 <------Neighbor Up ------------ Client sends Neighbor Up with 2594 the IPv4 and IPv6 TLVs 2596 ------Neighbor Up ACK---------> Server accepts the neighbor 2597 session 2599 <------Neighbor Update--------- Client Neighbor Metrics 2600 . . . . . . . . 2601 <------Neighbor Update--------- Client Neighbor Metrics 2603 *Neighbor Session Success 2605 Server Client Message Description 2606 ==================================================================== 2608 ---------Peer Offer-----------> Server offers availability 2610 -------Peer Heartbeat---------> 2612 <------Neighbor Up ----------- Client 2614 ------Neighbor Up ACK--------> Server 2616 <------Neighbor Update--------- Client 2617 . . . . . . . . 2618 <------Neighbor Update--------- Client 2620 Client initiates the terminate 2622 <------Neighbor Down ---------- Client 2624 ------Neighbor Down ACK-------> Server 2626 or 2628 Server initiates the terminate 2630 ------Neighbor Down ----------> Server 2632 <------Neighbor Down ACK------- Client 2634 Acknowledgements 2636 The authors would like to acknowledge the influence and contributions 2637 of Chris Olsen, Teco Boot, Subir Das, Jaewon Kang, Vikram Kaul, Rick 2638 Taylor, and John Dowdell. 2640 Normative References 2642 [RFC5444] Clausen, T., Ed,. "Generalized Mobile Ad Hoc Network (MANET) 2643 Packet/Message Format", RFC 5444, Februar, 2009. 2645 [RFC5578] Berry, B., Ed., "PPPoE with Credit Flow and Metrics", 2646 RFC 5578, February 2010. 2648 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2649 Requirement Levels", RFC 2119, March 1997. 2651 Informative References 2653 [DTLS] Rescorla, E., Ed,. "Datagram Transport Layer Security", 2654 RFC 4347, April 2006. 2656 Author's Addresses 2658 Stan Ratliff 2659 Cisco 2660 170 West Tasman Drive 2661 San Jose, CA 95134 2662 USA 2663 EMail: sratliff@cisco.com 2665 Bo Berry 2666 Cisco 2667 170 West Tasman Drive 2668 San Jose, CA 95134 2669 USA 2670 EMail: boberry@cisco.com 2672 Greg Harrison 2673 Cisco 2674 170 West Tasman Drive 2675 San Jose, CA 95134 2676 USA 2677 EMail: greharri@cisco.com 2679 Shawn Jury 2680 NetApp 2681 7301 Kit Creek Road, Building 2 2682 Research Triangle Park, NC 27709 2683 USA 2684 Email: shawn.jury@netapp.com 2686 Darryl Satterwhite 2687 Cisco 2688 170 West Tasman Drive 2689 San Jose, CA 95134 2690 USA 2691 Email: dsatterw@cisco.com