diff options
Diffstat (limited to 'doc/rfc/rfc8175.txt')
| -rw-r--r-- | doc/rfc/rfc8175.txt | 4595 |
1 files changed, 4595 insertions, 0 deletions
diff --git a/doc/rfc/rfc8175.txt b/doc/rfc/rfc8175.txt new file mode 100644 index 0000000..2247684 --- /dev/null +++ b/doc/rfc/rfc8175.txt @@ -0,0 +1,4595 @@ + + + + + + +Internet Engineering Task Force (IETF) S. Ratliff +Request for Comments: 8175 VT iDirect +Category: Standards Track S. Jury +ISSN: 2070-1721 Cisco Systems + D. Satterwhite + Broadcom + R. Taylor + Airbus Defence & Space + B. Berry + June 2017 + + + Dynamic Link Exchange Protocol (DLEP) + +Abstract + + When routing devices rely on modems to effect communications over + wireless links, they need timely and accurate knowledge of the + characteristics of the link (speed, state, etc.) in order to make + routing decisions. In mobile or other environments where these + characteristics change frequently, manual configurations or the + inference of state through routing or transport protocols does not + allow the router to make the best decisions. This document + introduces a new protocol called the Dynamic Link Exchange Protocol + (DLEP), which provides a bidirectional, event-driven communication + channel between the router and the modem to facilitate communication + of changing link characteristics. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc8175. + + + + + + + + + + +Ratliff, et al. Standards Track [Page 1] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + +Copyright Notice + + Copyright (c) 2017 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................4 + 2. Protocol Overview ...............................................7 + 2.1. Destinations ...............................................8 + 2.2. Conventions and Terminology ................................9 + 3. Requirements ....................................................9 + 4. Implementation Scenarios .......................................10 + 5. Assumptions ....................................................10 + 6. Metrics ........................................................11 + 7. DLEP Session Flow ..............................................12 + 7.1. Peer Discovery State ......................................12 + 7.2. Session Initialization State ..............................14 + 7.3. In-Session State ..........................................14 + 7.3.1. Heartbeats .........................................15 + 7.4. Session Termination State .................................15 + 7.5. Session Reset State .......................................16 + 7.5.1. Unexpected TCP Connection Termination ..............16 + 8. Transaction Model ..............................................16 + 9. Extensions .....................................................17 + 9.1. Experiments ...............................................18 + 10. Scalability ...................................................18 + 11. DLEP Signal and Message Structure .............................18 + 11.1. DLEP Signal Header .......................................19 + 11.2. DLEP Message Header ......................................20 + 11.3. DLEP Generic Data Item ...................................20 + 12. DLEP Signals and Messages .....................................21 + 12.1. General Processing Rules .................................21 + 12.2. Status Code Processing ...................................22 + 12.3. Peer Discovery Signal ....................................22 + 12.4. Peer Offer Signal ........................................23 + 12.5. Session Initialization Message ...........................23 + + + + +Ratliff, et al. Standards Track [Page 2] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + 12.6. Session Initialization Response Message ..................24 + 12.7. Session Update Message ...................................26 + 12.8. Session Update Response Message ..........................27 + 12.9. Session Termination Message ..............................28 + 12.10. Session Termination Response Message ....................28 + 12.11. Destination Up Message ..................................28 + 12.12. Destination Up Response Message .........................30 + 12.13. Destination Announce Message ............................30 + 12.14. Destination Announce Response Message ...................31 + 12.15. Destination Down Message ................................32 + 12.16. Destination Down Response Message .......................33 + 12.17. Destination Update Message ..............................33 + 12.18. Link Characteristics Request Message ....................35 + 12.19. Link Characteristics Response Message ...................35 + 12.20. Heartbeat Message .......................................36 + 13. DLEP Data Items ...............................................37 + 13.1. Status ...................................................38 + 13.2. IPv4 Connection Point ....................................41 + 13.3. IPv6 Connection Point ....................................42 + 13.4. Peer Type ................................................43 + 13.5. Heartbeat Interval .......................................45 + 13.6. Extensions Supported .....................................45 + 13.7. MAC Address ..............................................46 + 13.8. IPv4 Address .............................................47 + 13.8.1. IPv4 Address Processing ...........................48 + 13.9. IPv6 Address .............................................49 + 13.9.1. IPv6 Address Processing ...........................50 + 13.10. IPv4 Attached Subnet ....................................51 + 13.10.1. IPv4 Attached Subnet Processing ..................52 + 13.11. IPv6 Attached Subnet ....................................53 + 13.11.1. IPv6 Attached Subnet Processing ..................54 + 13.12. Maximum Data Rate (Receive) .............................55 + 13.13. Maximum Data Rate (Transmit) ............................56 + 13.14. Current Data Rate (Receive) .............................56 + 13.15. Current Data Rate (Transmit) ............................57 + 13.16. Latency .................................................58 + 13.17. Resources ...............................................59 + 13.18. Relative Link Quality (Receive) .........................60 + 13.19. Relative Link Quality (Transmit) ........................60 + 13.20. Maximum Transmission Unit (MTU) .........................61 + 14. Security Considerations .......................................62 + 15. IANA Considerations ...........................................63 + 15.1. Registrations ............................................63 + 15.2. Signal Type Registrations ................................63 + 15.3. Message Type Registrations ...............................64 + 15.4. DLEP Data Item Registrations .............................65 + 15.5. DLEP Status Code Registrations ...........................66 + + + + +Ratliff, et al. Standards Track [Page 3] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + 15.6. DLEP Extension Registrations .............................67 + 15.7. DLEP IPv4 Connection Point Flags .........................68 + 15.8. DLEP IPv6 Connection Point Flags .........................68 + 15.9. DLEP Peer Type Flags .....................................68 + 15.10. DLEP IPv4 Address Flags .................................69 + 15.11. DLEP IPv6 Address Flags .................................69 + 15.12. DLEP IPv4 Attached Subnet Flags .........................69 + 15.13. DLEP IPv6 Attached Subnet Flags .........................70 + 15.14. DLEP Well-Known Port ....................................70 + 15.15. DLEP IPv4 Link-Local Multicast Address ..................70 + 15.16. DLEP IPv6 Link-Local Multicast Address ..................70 + 16. References ....................................................71 + 16.1. Normative References .....................................71 + 16.2. Informative References ...................................71 + Appendix A. Discovery Signal Flows ................................73 + Appendix B. Peer-Level Message Flows ..............................73 + B.1. Session Initialization .....................................73 + B.2. Session Initialization - Refused ...........................74 + B.3. Router Changes IP Addresses ................................74 + B.4. Modem Changes Session-Wide Metrics .........................75 + B.5. Router Terminates Session ..................................75 + B.6. Modem Terminates Session ...................................76 + B.7. Session Heartbeats .........................................77 + B.8. Router Detects a Heartbeat Timeout .........................78 + B.9. Modem Detects a Heartbeat Timeout ..........................78 + Appendix C. Destination-Specific Message Flows ....................79 + C.1. Common Destination Notification ............................79 + C.2. Multicast Destination Notification .........................80 + C.3. Link Characteristics Request ...............................81 + Acknowledgments ...................................................82 + Authors' Addresses ................................................82 + +1. Introduction + + There exist today a collection of modem devices that control links of + variable data rate and quality. Examples of these types of links + include line-of-sight (LOS) terrestrial radios, satellite terminals, + and broadband modems. Fluctuations in speed and quality of these + links can occur due to configuration, or on a moment-to-moment basis, + due to physical phenomena like multipath interference, obstructions, + rain fade, etc. It is also quite possible that link quality and + data rate vary with respect to individual destinations on a link and + with the type of traffic being sent. As an example, consider the + case of an IEEE 802.11 access point serving two associated laptop + computers. In this environment, the answer to the question "What is + the data rate on the 802.11 link?" is "It depends on which associated + laptop we're talking about and on what kind of traffic is being + sent." While the first laptop, being physically close to the access + + + +Ratliff, et al. Standards Track [Page 4] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + point, may have a data rate of 54 Mbps for unicast traffic, the other + laptop, being relatively far away or obstructed by some object, can + simultaneously have a data rate of only 32 Mbps for unicast. + However, for multicast traffic sent from the access point, all + traffic is sent at the base transmission rate (which is configurable + but, depending on the model of the access point, is usually 24 Mbps + or less). + + In addition to utilizing links that have variable data rates, mobile + networks are challenged by the notion that link connectivity will + come and go over time, without an effect on a router's interface + state (Up or Down). Effectively utilizing a relatively short-lived + connection is problematic in IP routed networks, as IP routing + protocols tend to rely on interface state and independent timers to + maintain network convergence (e.g., HELLO messages and/or recognition + of DEAD routing adjacencies). These dynamic connections can be + better utilized with an event-driven paradigm, where acquisition of a + new neighbor (or loss of an existing one) is signaled, as opposed to + a paradigm driven by timers and/or interface state. DLEP not only + implements such an event-driven paradigm but does so over a local + (1-hop) TCP session, which guarantees delivery of the event messages. + + Another complicating factor for mobile networks are the different + methods of physically connecting the modem devices to the router. + Modems can be deployed as an interface card in a router's chassis, or + as a standalone device connected to the router via Ethernet or serial + link. In the case of Ethernet attachment, with existing protocols + and techniques, routing software cannot be aware of convergence + events occurring on the radio link (e.g., acquisition or loss of a + potential routing neighbor), nor can the router be aware of the + actual capacity of the link. This lack of awareness, along with the + variability in data rate, leads to a situation where finding the + (current) best route through the network to a given node is difficult + to establish and properly maintain. This is especially true of + demand-based access schemes such as Demand Assigned Multiple Access + (DAMA) implementations used on some satellite systems. With a + DAMA-based system, additional data rate may be available but will not + be used unless the network devices emit traffic at a rate higher than + the currently established rate. Increasing the traffic rate does not + guarantee that additional data rate will be allocated; rather, it may + result in data loss and additional retransmissions on the link. + + + + + + + + + + +Ratliff, et al. Standards Track [Page 5] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + Addressing the challenges listed above, the Dynamic Link Exchange + Protocol, or DLEP, has been developed. DLEP runs between a router + and its attached modem devices, allowing the modem devices to + communicate (1) link characteristics as they change and + (2) convergence events (acquisition and loss of potential routing + next hops). Figures 1 and 2 illustrate the scope of DLEP packets. + + |-------Local Node-------| |-------Remote Node------| + | | | | + +--------+ +-------+ +-------+ +--------+ + | Router |=======| Modem |{~~~~~~~~}| Modem |=======| Router | + | | | Device| | Device| | | + +--------+ +-------+ +-------+ +--------+ + | | | Link | | | + |-DLEP--| | Protocol | |-DLEP--| + | | | (e.g., | | | + | | | 802.11) | | | + + Figure 1: DLEP Network + + In Figure 1, when the local modem detects the presence of a remote + node, it (the local modem) sends a message to its router via DLEP. + The message consists of an indication of what change has occurred on + the link (e.g., the presence of a remote node detected), along with a + collection of DLEP-defined Data Items that further describe the + change. Upon receipt of the message, the local router may take + whatever action it deems appropriate, such as initiating discovery + protocols and/or issuing HELLO messages to converge the network. On + a continuing, as-needed basis, the modem devices use DLEP to report + any characteristics of the link (data rate, latency, etc.) that have + changed. DLEP is independent of the link type and topology supported + by the modem. Note that DLEP is specified to run only on the local + link between router and modem. Some over-the-air signaling may be + necessary between the local and remote modem in order to provide some + parameters in DLEP Messages between the local modem and local router, + but DLEP does not specify how such over-the-air signaling is carried + out. Over-the-air signaling is purely a matter for the modem + implementer. + + Figure 2 shows how DLEP can support a configuration where routers are + connected with different link types. In this example, Modem Device + Type A implements a point-to-point link, and Modem Device Type B is + connected via a shared medium. In both cases, DLEP is used to report + the characteristics of the link (data rate, latency, etc.) to + routers. The modem is also able to use the DLEP session to notify + the router when the remote node is lost, shortening the time required + to reconverge the network. + + + + +Ratliff, et al. Standards Track [Page 6] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + +--------+ +--------+ + +----+ Modem | | Modem +---+ + | | Device | | Device | | + | | Type A | <===== // ======> | Type A | | + | +--------+ Point-to-Point Link +--------+ | + +---+----+ +---+----+ + | Router | | Router | + | | | | + +---+----+ +---+----+ + | +--------+ +--------+ | + +-----+ Modem | | Modem | | + | Device | o o o o o o o o | Device +--+ + | Type B | o Shared o | Type B | + +--------+ o Medium o +--------+ + o o + o o + o o + o + +--------+ + | Modem | + | Device | + | Type B | + +---+----+ + | + | + +---+----+ + | Router | + | | + +--------+ + + Figure 2: DLEP Network with Multiple Modem Devices + +2. Protocol Overview + + DLEP defines a set of Messages used by modems and their attached + routers to communicate events that occur on the physical link(s) + managed by the modem: for example, a remote node entering or leaving + the network, or that the link has changed. Associated with these + Messages are a set of Data Items -- information that describes the + remote node (e.g., address information) and/or the characteristics of + the link to the remote node. Throughout this document, we refer to + modems/routers participating in a DLEP session as "DLEP + Participants", unless a specific distinction (e.g., modem or router) + is required. + + DLEP uses a session-oriented paradigm between the modem device and + its associated router. If multiple modem devices are attached to a + router (as in Figure 2) or the modem supports multiple connections + + + +Ratliff, et al. Standards Track [Page 7] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + (via multiple logical or physical interfaces), then separate DLEP + sessions exist for each modem or connection. A router and modem form + a session by completing the discovery and initialization process. + This router-modem session persists unless or until it either + (1) times out, based on the absence of DLEP traffic (including + heartbeats) or (2) is explicitly torn down by one of the DLEP + participants. + + While this document represents the best efforts of the working group + to be functionally complete, it is recognized that extensions to DLEP + will in all likelihood be necessary as more link types are used. + Such extensions are defined as additional Messages, Data Items, + and/or status codes, and associated rules of behavior, that are not + defined in this document. DLEP contains a standard mechanism for + router and modem implementations to negotiate the available + extensions to use on a per-session basis. + +2.1. Destinations + + The router-modem session provides a carrier for information exchange + concerning "destinations" that are available via the modem device. + Destinations can be identified by either the router or the modem and + represent a specific, addressable location that can be reached via + the link(s) managed by the modem. + + The DLEP Messages concerning destinations thus become the way for + routers and modems to maintain, and notify each other about, an + information base representing the physical and logical destinations + accessible via the modem device, as well as the link characteristics + to those destinations. + + A destination can be either physical or logical. The example of a + physical destination would be that of a remote, far-end router + attached via the variable-quality network. It should be noted that + for physical destinations the Media Access Control (MAC) address is + the address of the far-end router, not the modem. + + The example of a logical destination is Multicast. Multicast traffic + destined for the variable-quality network (the network accessed via + the modem) is handled in IP networks by deriving a Layer 2 MAC + address based on the Layer 3 address. Leveraging on this scheme, + multicast traffic is supported in DLEP simply by treating the derived + MAC address as any other destination in the network. + + To support these logical destinations, one of the DLEP participants + (typically, the router) informs the other as to the existence of the + logical destination. The modem, once it is aware of the existence of + this logical destination, reports link characteristics just as it + + + +Ratliff, et al. Standards Track [Page 8] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + would for any other destination in the network. The specific + algorithms a modem would use to derive metrics on logical + destinations are outside the scope of this specification; these + algorithms are left to specific implementations to decide. + + In all cases, when this specification uses the term "destination", it + refers to the addressable locations, either logical or physical, that + are accessible by the radio link(s). + +2.2. Conventions and Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +3. Requirements + + DLEP MUST be implemented on a single Layer 2 domain. The protocol + identifies next-hop destinations by using the MAC address for + delivering data traffic. No manipulation or substitution is + performed; the MAC address supplied in all DLEP Messages is used as + the Destination MAC address for frames emitted by the participating + router. MAC addresses MUST be unique within the context of the + router-modem session. + + To enforce the single Layer 2 domain, implementations MUST support + the Generalized TTL Security Mechanism [RFC5082], and implementations + MUST adhere to this specification for all DLEP Messages. + + DLEP specifies UDP multicast for single-hop discovery signaling and + TCP for transport of the Messages. Modems and routers participating + in DLEP sessions MUST have topologically consistent IP addresses + assigned. It is RECOMMENDED that DLEP implementations utilize IPv6 + link-local addresses to reduce the administrative burden of address + assignment. + + DLEP relies on the guaranteed delivery of its Messages between router + and modem, once the 1-hop discovery process is complete -- hence, the + specification of TCP to carry the Messages. Other reliable + transports for the protocol are possible but are outside the scope of + this document. + + + + + + + + +Ratliff, et al. Standards Track [Page 9] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + +4. Implementation Scenarios + + During development of this specification, two types of deployments + were discussed. + + The first can be viewed as a "dedicated deployment". In this mode, + DLEP routers and modems are either directly connected (e.g., using + crossover cables to connect interfaces) or connected to a dedicated + switch. An example of this type of deployment would be a router with + a line-of-sight radio connected into one interface, with a satellite + modem connected into another interface. In mobile environments, the + router and the connected modem (or modems) are placed into a mobile + platform (e.g., a vehicle, boat, or airplane). In this mode, when a + switch is used, it is possible that a small number of ancillary + devices (e.g., a laptop) are also plugged into the switch. But in + either event, the resulting network segment is constrained to a small + number of devices and is not generally accessible from anywhere else + in the network. + + The other type of deployment envisioned can be viewed as a "networked + deployment". In this type of scenario, the DLEP router and modem + (or modems) are placed on a segment that is accessible from other + points in the network. In this scenario, not only are the DLEP + router and modem(s) accessible from other points in the network; the + router and a given modem could be multiple physical hops away from + each other. This scenario necessitates the use of Layer 2 tunneling + technology to enforce the single-hop requirement of DLEP. + +5. Assumptions + + DLEP assumes that a signaling protocol exists between modems + participating in a network. This specification does not define the + character or behavior of this over-the-air signaling but does expect + some information to be carried (or derived) by the signaling, + such as the arrival and departure of modems from this network, + and the variation of the link characteristics between modems. + This information is then assumed to be used by the modem to + implement DLEP. + + This specification assumes that the link between router and modem is + static with respect to data rate and latency and that this link is + not likely to be the cause of a performance bottleneck. In + deployments where the router and modem are physically separated by + multiple network hops, served by Layer 2 tunneling technology, DLEP + statistics on the RF links could be insufficient for routing + protocols to make appropriate routing decisions. This would + + + + + +Ratliff, et al. Standards Track [Page 10] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + especially become an issue in cases where the Layer 2 tunnel between + router and modem is itself served in part (or in total) with a + wireless backhaul link. + +6. Metrics + + DLEP includes the ability for the router and modem to communicate + metrics that reflect the characteristics (e.g., data rate, latency) + of the variable-quality link in use. DLEP does not specify how a + given metric value is to be calculated; rather, the protocol assumes + that metrics have been calculated by a "best effort", incorporating + all pertinent data that is available to the modem device. Metrics + based on large-enough sample sizes will preclude short traffic bursts + from adversely skewing reported values. + + DLEP allows for metrics to be sent within two contexts -- metrics for + a specific destination within the network (e.g., a specific router), + and "per session" (those that apply to all destinations accessed via + the modem). Most metrics can be further subdivided into transmit and + receive metrics. In cases where metrics are provided at the session + level, the router propagates the metrics to all entries in its + information base for destinations that are accessed via the modem. + + DLEP modems announce all metric Data Items that will be reported + during the session, and provide default values for those metrics, in + the Session Initialization Response Message (Section 12.6). In order + to use a metric type that was not included in the Session + Initialization Response Message, modem implementations terminate the + session with the router (via the Session Termination Message + (Section 12.9)) and establish a new session. + + A DLEP modem can send metrics in both (1) a session context, via the + Session Update Message (Section 12.7) and (2) a specific destination + context, via the Destination Update Message (Section 12.17), at any + time. The most recently received metric value takes precedence over + any earlier value, regardless of context -- that is: + + 1. If the router receives metrics in a specific destination context + (via the Destination Update Message), then the specific + destination is updated with the new metric. + + 2. If the router receives metrics in a session-wide context (via the + Session Update Message), then the metrics for all destinations + accessed via the modem are updated with the new metric. + + + + + + + +Ratliff, et al. Standards Track [Page 11] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + It is left to implementations to choose sensible default values based + on their specific characteristics. Modems having static + (non-changing) link metric characteristics can report metrics only + once for a given destination (or once on a session-wide basis, if all + connections via the modem are of this static nature). + + In addition to communicating existing metrics about the link, DLEP + provides a Message allowing a router to request a different data rate + or latency from the modem. This Message is the Link Characteristics + Request Message (Section 12.18); it gives the router the ability to + deal with requisite increases (or decreases) of allocated + data rate/latency in demand-based schemes in a more deterministic + manner. + +7. DLEP Session Flow + + All DLEP participants of a session transition through a number of + distinct states during the lifetime of a DLEP session: + + o Peer Discovery + + o Session Initialization + + o In-Session + + o Session Termination + + o Session Reset + + Modems, and routers supporting DLEP discovery, transition through all + five of the above states. Routers that rely on preconfigured TCP + address/port information start in the Session Initialization state. + + Modems MUST support the Peer Discovery state. + +7.1. Peer Discovery State + + Modems MUST support DLEP Peer Discovery; routers MAY support the + discovery signals or rely on a priori configuration to locate modems. + If a router chooses to support DLEP discovery, all signals MUST be + supported. + + In the Peer Discovery state, routers that support DLEP discovery MUST + send Peer Discovery Signals (Section 12.3) to initiate modem + discovery. + + + + + + +Ratliff, et al. Standards Track [Page 12] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + The router implementation then waits for a Peer Offer Signal + (Section 12.4) response from a potential DLEP modem. While in the + Peer Discovery state, Peer Discovery Signals MUST be sent repeatedly + by a DLEP router, at regular intervals. It is RECOMMENDED that this + interval be set to 60 seconds. The interval MUST be a minimum of + 1 second; it SHOULD be a configurable parameter. Note that this + operation (sending Peer Discovery and waiting for Peer Offer) is + outside the DLEP transaction model (Section 8), as the transaction + model only describes Messages on a TCP session. + + Routers receiving a Peer Offer Signal MUST use one of the modem + address/port combinations from the Peer Offer Signal to establish a + TCP connection to the modem, even if a priori configuration exists. + If multiple Connection Point Data Items exist in the received Peer + Offer Signal, routers SHOULD prioritize IPv6 connection points over + IPv4 connection points. If multiple connection points exist with the + same transport (e.g., IPv6 or IPv4), implementations MAY use their + own heuristics to determine the order in which they are tried. If a + TCP connection cannot be achieved using any of the address/port + combinations and the Discovery mechanism is in use, then the router + SHOULD resume issuing Peer Discovery Signals. If no Connection Point + Data Items are included in the Peer Offer Signal, the router MUST use + the source address of the UDP packet containing the Peer Offer Signal + as the IP address, and the DLEP well-known port number. + + In the Peer Discovery state, the modem implementation MUST listen for + incoming Peer Discovery Signals on the DLEP well-known IPv6 and/or + IPv4 link-local multicast address and port. On receipt of a valid + Peer Discovery Signal, it MUST reply with a Peer Offer Signal. + + Modems MUST be prepared to accept a TCP connection from a router that + is not using the Discovery mechanism, i.e., a connection attempt that + occurs without a preceding Peer Discovery Signal. + + Implementations of DLEP SHOULD implement, and use, Transport Layer + Security (TLS) [RFC5246] to protect the TCP session. The "dedicated + deployments" discussed in "Implementation Scenarios" (Section 4) MAY + consider the use of DLEP without TLS. For all "networked + deployments" (again, discussed in "Implementation Scenarios"), the + implementation and use of TLS are STRONGLY RECOMMENDED. If TLS is to + be used, then the TLS session MUST be established before any Messages + are passed between peers. Routers supporting TLS MUST prioritize + connection points using TLS over those that do not. + + Upon establishment of a TCP connection, and the establishment of a + TLS session if TLS is in use, both modem and router enter the Session + Initialization state. It is up to the router implementation if Peer + Discovery Signals continue to be sent after the device has + + + +Ratliff, et al. Standards Track [Page 13] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + transitioned to the Session Initialization state. Modem + implementations MUST silently ignore Peer Discovery Signals from a + router with which a given implementation already has a TCP + connection. + +7.2. Session Initialization State + + On entering the Session Initialization state, the router MUST send a + Session Initialization Message (Section 12.5) to the modem. The + router MUST then wait for receipt of a Session Initialization + Response Message (Section 12.6) from the modem. Receipt of the + Session Initialization Response Message containing a Status Data Item + (Section 13.1) with status code set to 0 'Success' (see Table 2 in + Section 13.1) indicates that the modem has received and processed the + Session Initialization Message, and the router MUST transition to the + In-Session state. + + On entering the Session Initialization state, the modem MUST wait for + receipt of a Session Initialization Message from the router. Upon + receipt of a Session Initialization Message, the modem MUST send a + Session Initialization Response Message, and the session MUST + transition to the In-Session state. If the modem receives any + Message other than Session Initialization or it fails to parse the + received Message, it MUST NOT send any Message, and it MUST terminate + the TCP connection and transition to the Session Reset state. + + DLEP provides an extension negotiation capability to be used in the + Session Initialization state; see Section 9. Extensions supported by + an implementation MUST be declared to potential DLEP participants + using the Extensions Supported Data Item (Section 13.6). Once both + DLEP participants have exchanged initialization Messages, an + implementation MUST NOT emit any Message, Signal, Data Item, or + status code associated with an extension that was not specified in + the received initialization Message from its peer. + +7.3. In-Session State + + In the In-Session state, Messages can flow in both directions between + DLEP participants, indicating changes to the session state, the + arrival or departure of reachable destinations, or changes of the + state of the links to the destinations. + + + + + + + + + + +Ratliff, et al. Standards Track [Page 14] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + The In-Session state is maintained until one of the following + conditions occurs: + + o The implementation terminates the session by sending a Session + Termination Message (Section 12.9), or + + o Its peer terminates the session, indicated by receiving a Session + Termination Message. + + The implementation MUST then transition to the Session Termination + state. + +7.3.1. Heartbeats + + In order to maintain the In-Session state, periodic Heartbeat + Messages (Section 12.20) MUST be exchanged between router and modem. + These Messages are intended to keep the session alive and to verify + bidirectional connectivity between the two DLEP participants. It is + RECOMMENDED that the interval timer between Heartbeat Messages be set + to 60 seconds. The interval MUST be a minimum of 1 second; it SHOULD + be a configurable parameter. + + Each DLEP participant is responsible for the creation of Heartbeat + Messages. + + Receipt of any valid DLEP Message MUST reset the heartbeat interval + timer (i.e., valid DLEP Messages take the place of, and obviate the + need for, additional Heartbeat Messages). + + An implementation MUST allow a minimum of 2 heartbeat intervals to + expire with no Messages from its peer before terminating the session. + When terminating the session, a Session Termination Message + containing a Status Data Item (Section 13.1) with status code set to + 132 'Timed Out' (see Table 2) MUST be sent, and then the + implementation MUST transition to the Session Termination state. + +7.4. Session Termination State + + When an implementation enters the Session Termination state after + sending a Session Termination Message (Section 12.9) as the result of + an invalid Message or error, it MUST wait for a Session Termination + Response Message (Section 12.10) from its peer. A sender SHOULD + allow 4 heartbeat intervals to expire before assuming that its peer + is unresponsive and before continuing with session termination. Any + other Message received while waiting MUST be silently ignored. + + + + + + +Ratliff, et al. Standards Track [Page 15] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + When the sender of the Session Termination Message receives a Session + Termination Response Message from its peer or times out, it MUST + transition to the Session Reset state. + + When an implementation receives a Session Termination Message from + its peer, it enters the Session Termination state, and then it MUST + immediately send a Session Termination Response and transition to the + Session Reset state. + +7.5. Session Reset State + + In the Session Reset state, the implementation MUST perform the + following actions: + + o Release all resources allocated for the session. + + o Eliminate all destinations in the information base represented by + the session. Destination Down Messages (Section 12.15) MUST NOT + be sent. + + o Terminate the TCP connection. + + Having completed these actions, the implementation SHOULD return to + the relevant initial state: + + o For modems: Peer Discovery. + + o For routers: either Peer Discovery or Session Initialization, + depending on configuration. + +7.5.1. Unexpected TCP Connection Termination + + If the TCP connection between DLEP participants is terminated when an + implementation is not in the Session Reset state, the implementation + MUST immediately transition to the Session Reset state. + +8. Transaction Model + + DLEP defines a simple Message transaction model: only one request per + destination may be in progress at a time per session. A Message + transaction is considered complete when a response matching a + previously issued request is received. If a DLEP participant + receives a request for a destination for which there is already an + outstanding request, the implementation MUST terminate the session by + issuing a Session Termination Message (Section 12.9) containing a + Status Data Item (Section 13.1) with status code set to + 129 'Unexpected Message' (see Table 2) and transition to the Session + + + + +Ratliff, et al. Standards Track [Page 16] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + Termination state. There is no restriction on the total number of + Message transactions in progress at a time, as long as each + transaction refers to a different destination. + + It should be noted that some requests may take a considerable amount + of time for some DLEP participants to complete; for example, a modem + handling a multicast Destination Up request may have to perform a + complex network reconfiguration. A sending implementation MUST be + able to handle such long-running transactions gracefully. + + Additionally, only one session request, e.g., a Session + Initialization Message (Section 12.5), may be in progress at a time + per session. As noted above for Message transactions, a session + transaction is considered complete when a response matching a + previously issued request is received. If a DLEP participant + receives a session request while there is already a session request + in progress, it MUST terminate the session by issuing a Session + Termination Message containing a Status Data Item with status code + set to 129 'Unexpected Message' and transition to the Session + Termination state. Only the Session Termination Message may be + issued when a session transaction is in progress. Heartbeat Messages + (Section 12.20) MUST NOT be considered part of a session transaction. + + DLEP transactions do not time out and are not cancellable, except for + transactions in flight when the DLEP session is reset. If the + session is terminated, canceling transactions in progress MUST be + performed as part of resetting the state machine. An implementation + can detect if its peer has failed in some way by use of the session + heartbeat mechanism during the In-Session state; see Section 7.3. + +9. Extensions + + Extensions MUST be negotiated on a per-session basis during session + initialization via the Extensions Supported mechanism. + Implementations are not required to support any extensions in order + to be considered DLEP compliant. + + If interoperable protocol extensions are required, they will need to + be standardized as either (1) an update to this document or (2) an + additional standalone specification. The IANA registries defined in + Section 15 of this document contain sufficient unassigned space for + DLEP Signals, Messages, Data Items, and status codes to accommodate + future extensions to the protocol. + + As multiple protocol extensions MAY be announced during session + initialization, authors of protocol extensions need to consider the + interaction of their extensions with other published extensions and + specify any incompatibilities. + + + +Ratliff, et al. Standards Track [Page 17] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + +9.1. Experiments + + This document registers Private Use [RFC5226] numbering space in the + DLEP Signal, Message, Data Item, and status code registries for + experimental extensions. The intent is to allow for experimentation + with new Signals, Messages, Data Items, and/or status codes while + still retaining the documented DLEP behavior. + + During session initialization, the use of the Private Use Signals, + Messages, Data Items, status codes, or behaviors MUST be announced as + DLEP extensions, using extension identifiers from the Private Use + space in the "Extension Type Values" registry (Table 3), with a value + agreed upon (a priori) between the participants. DLEP extensions + using the Private Use numbering space are commonly referred to as + "experiments". + + Multiple experiments MAY be announced in the Session Initialization + Messages. However, the use of multiple experiments in a single + session could lead to interoperability issues or unexpected results + (e.g., clashes of experimental Signals, Messages, Data Items, and/or + status code types) and is therefore discouraged. It is left to + implementations to determine the correct processing path (e.g., a + decision on whether to terminate the session or establish a + precedence of the conflicting definitions) if such conflicts arise. + +10. Scalability + + The protocol is intended to support thousands of destinations on a + given modem/router pair. On a large scale, an implementation should + consider employing techniques to prevent flooding its peer with a + large number of Messages in a short time. For example, a dampening + algorithm could be employed to prevent a flapping device from + generating a large number of Destination Up / Destination Down + Messages. + + Also, the use of techniques such as a hysteresis can lessen the + impact of rapid, minor fluctuations in link quality. The specific + algorithms for handling flapping destinations and minor changes in + link quality are outside the scope of this specification. + +11. DLEP Signal and Message Structure + + DLEP defines two protocol units used in two different ways: Signals + and Messages. Signals are only used in the Discovery mechanism and + are carried in UDP datagrams. Messages are used bidirectionally over + a TCP connection between the participants, in the Session + Initialization, In-Session, and Session Termination states. + + + + +Ratliff, et al. Standards Track [Page 18] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + Both Signals and Messages consist of a Header followed by an + unordered list of Data Items. Headers consist of Type and Length + information, while Data Items are encoded as TLV (Type-Length-Value) + structures. In this document, the Data Items following a Signal or + Message Header are described as being "contained in" the Signal or + Message. + + There is no restriction on the order of Data Items following a + Header, and the acceptability of duplicate Data Items is defined by + the definition of the Signal or Message declared by the type in the + Header. + + All integers in Header fields and values MUST be in network byte + order. + +11.1. DLEP Signal Header + + The DLEP Signal Header contains the following fields: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 'D' | 'L' | 'E' | 'P' | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Signal Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: DLEP Signal Header + + "DLEP": Every Signal MUST start with the following characters: + U+0044, U+004C, U+0045, U+0050. + + Signal Type: A 16-bit unsigned integer containing one of the DLEP + Signal Type values defined in this document. + + Length: The length in octets, expressed as a 16-bit unsigned + integer, of all of the DLEP Data Items contained in this Signal. + This length MUST NOT include the length of the Signal Header + itself. + + The DLEP Signal Header is immediately followed by zero or more DLEP + Data Items, encoded in TLVs, as defined in this document. + + + + + + + + + +Ratliff, et al. Standards Track [Page 19] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + +11.2. DLEP Message Header + + The DLEP Message Header contains the following fields: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 4: DLEP Message Header + + Message Type: A 16-bit unsigned integer containing one of the DLEP + Message Type values defined in this document. + + Length: The length in octets, expressed as a 16-bit unsigned + integer, of all of the DLEP Data Items contained in this Message. + This length MUST NOT include the length of the Message Header + itself. + + The DLEP Message Header is immediately followed by zero or more DLEP + Data Items, encoded in TLVs, as defined in this document. + +11.3. DLEP Generic Data Item + + All DLEP Data Items contain the following fields: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data Item Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value... : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 5: DLEP Generic Data Item + + Data Item Type: A 16-bit unsigned integer field specifying the type + of Data Item being sent. + + Length: The length in octets, expressed as a 16-bit unsigned + integer, of the Value field of the Data Item. This length + MUST NOT include the length of the Data Item Type and Length + fields. + + Value: A field of <Length> octets that contains data specific to a + particular Data Item. + + + + +Ratliff, et al. Standards Track [Page 20] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + +12. DLEP Signals and Messages + +12.1. General Processing Rules + + If an unrecognized or unexpected Signal is received or if a received + Signal contains unrecognized, invalid, or disallowed duplicate Data + Items, the receiving implementation MUST ignore the Signal. + + If a Signal is received with a TTL value that is NOT equal to 255, + the receiving implementation MUST ignore the Signal. + + If an unrecognized Message is received, the receiving implementation + MUST issue a Session Termination Message (Section 12.9) containing a + Status Data Item (Section 13.1) with status code set to 128 'Unknown + Message' (see Table 2) and transition to the Session Termination + state. + + If an unexpected Message is received, the receiving implementation + MUST issue a Session Termination Message containing a Status Data + Item with status code set to 129 'Unexpected Message' and transition + to the Session Termination state. + + If a received Message contains unrecognized, invalid, or disallowed + duplicate Data Items, the receiving implementation MUST issue a + Session Termination Message containing a Status Data Item with status + code set to 130 'Invalid Data' and transition to the Session + Termination state. + + If a packet in the TCP stream is received with a TTL value other than + 255, the receiving implementation MUST immediately transition to the + Session Reset state. + + Prior to the exchange of Destination Up (Section 12.11) and + Destination Up Response (Section 12.12) Messages, or Destination + Announce (Section 12.13) and Destination Announce Response + (Section 12.14) Messages, no Messages concerning a destination may be + sent. An implementation receiving any Message with such an + unannounced destination MUST terminate the session by issuing a + Session Termination Message containing a Status Data Item with status + code set to 131 'Invalid Destination' and transition to the Session + Termination state. + + After exchanging Destination Down (Section 12.15) and Destination + Down Response (Section 12.16) Messages, no Messages concerning a + destination may be sent until a new Destination Up or Destination + Announce Message is sent. An implementation receiving a Message + about a destination previously announced as 'down' MUST terminate the + + + + +Ratliff, et al. Standards Track [Page 21] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + session by issuing a Session Termination Message containing a Status + Data Item with status code set to 131 'Invalid Destination' and + transition to the Session Termination state. + +12.2. Status Code Processing + + The behavior of a DLEP participant receiving a Message containing a + Status Data Item (Section 13.1) is defined by the failure mode + associated with the value of the status code field; see Table 2. All + status code values less than 100 have a failure mode of 'Continue'; + all other status codes have a failure mode of 'Terminate'. + + A DLEP participant receiving any Message apart from a Session + Termination Message (Section 12.9) containing a Status Data Item with + a status code value with failure mode 'Terminate' MUST immediately + issue a Session Termination Message echoing the received Status Data + Item and then transition to the Session Termination state. + + A DLEP participant receiving a Message containing a Status Data Item + with a status code value with failure mode 'Continue' can continue + normal operation of the session. + +12.3. Peer Discovery Signal + + A Peer Discovery Signal SHOULD be sent by a DLEP router to discover + DLEP modems in the network; see Section 7.1. + + A Peer Discovery Signal MUST be encoded within a UDP packet. The + destination MUST be set to the DLEP well-known address and port + number. For routers supporting both IPv4 and IPv6 DLEP operation, it + is RECOMMENDED that IPv6 be selected as the transport. The source IP + address MUST be set to the router IP address associated with the DLEP + interface. There is no DLEP-specific restriction on source port. + + To construct a Peer Discovery Signal, the Signal Type value in the + Signal Header is set to 1 (see "Signal Type Registration" + (Section 15.2)). + + The Peer Discovery Signal MAY contain a Peer Type Data Item + (Section 13.4). + + + + + + + + + + + +Ratliff, et al. Standards Track [Page 22] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + +12.4. Peer Offer Signal + + A Peer Offer Signal MUST be sent by a DLEP modem in response to a + properly formatted and addressed Peer Discovery Signal + (Section 12.3). + + A Peer Offer Signal MUST be encoded within a UDP packet. The IP + source and destination fields in the packet MUST be set by swapping + the values received in the Peer Discovery Signal. The Peer Offer + Signal completes the discovery process; see Section 7.1. + + To construct a Peer Offer Signal, the Signal Type value in the Signal + Header is set to 2 (see "Signal Type Registration" (Section 15.2)). + + The Peer Offer Signal MAY contain a Peer Type Data Item + (Section 13.4). + + The Peer Offer Signal MAY contain one or more of any of the following + Data Items, with different values: + + o IPv4 Connection Point (Section 13.2) + + o IPv6 Connection Point (Section 13.3) + + The IPv4 and IPv6 Connection Point Data Items indicate the unicast + address the router MUST use when connecting the DLEP TCP session. + +12.5. Session Initialization Message + + A Session Initialization Message MUST be sent by a DLEP router as the + first Message of the DLEP TCP session. It is sent by the router + after a TCP connect to an address/port combination that was obtained + either via receipt of a Peer Offer or from a priori configuration. + + To construct a Session Initialization Message, the Message Type value + in the Message Header is set to 1 (see "Message Type Registration" + (Section 15.3)). + + The Session Initialization Message MUST contain one of each of the + following Data Items: + + o Heartbeat Interval (Section 13.5) + + o Peer Type (Section 13.4) + + If DLEP extensions are supported, the Session Initialization Message + MUST contain an Extensions Supported Data Item (Section 13.6). + + + + +Ratliff, et al. Standards Track [Page 23] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + The Session Initialization Message MAY contain one or more of each of + the following Data Items, with different values and with the Add/Drop + (A) flag (Section 13) set to 1: + + o IPv4 Address (Section 13.8) + + o IPv6 Address (Section 13.9) + + o IPv4 Attached Subnet (Section 13.10) + + o IPv6 Attached Subnet (Section 13.11) + + If any optional extensions are supported by the implementation, they + MUST be enumerated in the Extensions Supported Data Item. If an + Extensions Supported Data Item does not exist in a Session + Initialization Message, the modem MUST conclude that there is no + support for extensions in the router. + + DLEP Heartbeats are not started until receipt of the Session + Initialization Response Message (Section 12.6), and therefore + implementations MUST use their own timeout heuristics for this + Message. + + As an exception to the general rule governing an implementation + receiving an unrecognized Data Item in a Message (see Section 12.1), + if a Session Initialization Message contains one or more Extensions + Supported Data Items announcing support for extensions that the + implementation does not recognize, then the implementation MAY ignore + Data Items it does not recognize. + +12.6. Session Initialization Response Message + + A Session Initialization Response Message MUST be sent by a DLEP + modem in response to a received Session Initialization Message + (Section 12.5). + + To construct a Session Initialization Response Message, the Message + Type value in the Message Header is set to 2 (see "Message Type + Registration" (Section 15.3)). + + The Session Initialization Response Message MUST contain one of each + of the following Data Items: + + o Status (Section 13.1) + + o Peer Type (Section 13.4) + + o Heartbeat Interval (Section 13.5) + + + +Ratliff, et al. Standards Track [Page 24] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + o Maximum Data Rate (Receive) (Section 13.12) + + o Maximum Data Rate (Transmit) (Section 13.13) + + o Current Data Rate (Receive) (Section 13.14) + + o Current Data Rate (Transmit) (Section 13.15) + + o Latency (Section 13.16) + + The Session Initialization Response Message MUST contain one of each + of the following Data Items, if the Data Item will be used during the + lifetime of the session: + + o Resources (Section 13.17) + + o Relative Link Quality (Receive) (Section 13.18) + + o Relative Link Quality (Transmit) (Section 13.19) + + o Maximum Transmission Unit (MTU) (Section 13.20) + + If DLEP extensions are supported, the Session Initialization Response + Message MUST contain an Extensions Supported Data Item + (Section 13.6). + + The Session Initialization Response Message MAY contain one or more + of each of the following Data Items, with different values and with + the Add/Drop (A) flag (Section 13) set to 1: + + o IPv4 Address (Section 13.8) + + o IPv6 Address (Section 13.9) + + o IPv4 Attached Subnet (Section 13.10) + + o IPv6 Attached Subnet (Section 13.11) + + The Session Initialization Response Message completes the DLEP + session establishment; the modem should transition to the In-Session + state when the Message is sent, and the router should transition to + the In-Session state upon receipt of an acceptable Session + Initialization Response Message. + + All supported metric Data Items MUST be included in the Session + Initialization Response Message, with default values to be used on a + session-wide basis. This can be viewed as the modem "declaring" all + supported metrics at DLEP session initialization. Receipt of any + + + +Ratliff, et al. Standards Track [Page 25] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + further DLEP Message containing a metric Data Item not included in + the Session Initialization Response Message MUST be treated as an + error, resulting in the termination of the DLEP session between + router and modem. + + If any optional extensions are supported by the modem, they MUST be + enumerated in the Extensions Supported Data Item. If an Extensions + Supported Data Item does not exist in a Session Initialization + Response Message, the router MUST conclude that there is no support + for extensions in the modem. + + After the Session Initialization / Session Initialization Response + Messages have been successfully exchanged, implementations MUST only + use extensions that are supported by both DLEP participants; see + Section 7.2. + +12.7. Session Update Message + + A Session Update Message MAY be sent by a DLEP participant, on a + session-wide basis, to indicate local Layer 3 address changes and/or + metric changes. + + To construct a Session Update Message, the Message Type value in the + Message Header is set to 3 (see "Message Type Registration" + (Section 15.3)). + + The Session Update Message MAY contain one or more of each of the + following Data Items, with different values: + + o IPv4 Address (Section 13.8) + + o IPv6 Address (Section 13.9) + + o IPv4 Attached Subnet (Section 13.10) + + o IPv6 Attached Subnet (Section 13.11) + + When sent by a modem, the Session Update Message MAY contain one of + each of the following Data Items: + + o Maximum Data Rate (Receive) (Section 13.12) + + o Maximum Data Rate (Transmit) (Section 13.13) + + o Current Data Rate (Receive) (Section 13.14) + + + + + + +Ratliff, et al. Standards Track [Page 26] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + o Current Data Rate (Transmit) (Section 13.15) + + o Latency (Section 13.16) + + When sent by a modem, the Session Update Message MAY contain one of + each of the following Data Items, if the Data Item is in use by the + session: + + o Resources (Section 13.17) + + o Relative Link Quality (Receive) (Section 13.18) + + o Relative Link Quality (Transmit) (Section 13.19) + + o Maximum Transmission Unit (MTU) (Section 13.20) + + If metrics are supplied with the Session Update Message (e.g., + Maximum Data Rate), these metrics are considered to be session-wide + and therefore MUST be applied to all destinations in the information + base associated with the DLEP session. This includes destinations + for which metrics may have been stored based on received Destination + Update messages. + + It should be noted that Session Update Messages can be sent by both + routers and modems. For example, the addition of an IPv4 address on + the router MAY prompt a Session Update Message to its attached + modems. Also, for example, a modem that changes its Maximum Data + Rate (Receive) for all destinations MAY reflect that change via a + Session Update Message to its attached router(s). + + Concerning Layer 3 addresses and subnets: if the modem is capable of + understanding and forwarding this information (via mechanisms not + defined by DLEP), the update would prompt any remote DLEP-enabled + modems to issue a Destination Update Message (Section 12.17) to their + local routers with the new (or deleted) addresses and subnets. + +12.8. Session Update Response Message + + A Session Update Response Message MUST be sent by a DLEP participant + when a Session Update Message (Section 12.7) is received. + + To construct a Session Update Response Message, the Message Type + value in the Message Header is set to 4 (see "Message Type + Registration" (Section 15.3)). + + The Session Update Response Message MUST contain a Status Data Item + (Section 13.1). + + + + +Ratliff, et al. Standards Track [Page 27] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + +12.9. Session Termination Message + + When a DLEP participant determines that the DLEP session needs to be + terminated, the participant MUST send (or attempt to send) a Session + Termination Message. + + To construct a Session Termination Message, the Message Type value in + the Message Header is set to 5 (see "Message Type Registration" + (Section 15.3)). + + The Session Termination Message MUST contain a Status Data Item + (Section 13.1). + + It should be noted that Session Termination Messages can be sent by + both routers and modems. + +12.10. Session Termination Response Message + + A Session Termination Response Message MUST be sent by a DLEP + participant when a Session Termination Message (Section 12.9) is + received. + + To construct a Session Termination Response Message, the Message Type + value in the Message Header is set to 6 (see "Message Type + Registration" (Section 15.3)). + + There are no valid Data Items for the Session Termination Response + Message. + + Receipt of a Session Termination Response Message completes the + teardown of the DLEP session; see Section 7.4. + +12.11. Destination Up Message + + Destination Up Messages MAY be sent by a modem to inform its attached + router of the presence of a new reachable destination. + + To construct a Destination Up Message, the Message Type value in the + Message Header is set to 7 (see "Message Type Registration" + (Section 15.3)). + + The Destination Up Message MUST contain a MAC Address Data Item + (Section 13.7). + + + + + + + + +Ratliff, et al. Standards Track [Page 28] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + The Destination Up Message SHOULD contain one or more of each of the + following Data Items, with different values: + + o IPv4 Address (Section 13.8) + + o IPv6 Address (Section 13.9) + + The Destination Up Message MAY contain one of each of the following + Data Items: + + o Maximum Data Rate (Receive) (Section 13.12) + + o Maximum Data Rate (Transmit) (Section 13.13) + + o Current Data Rate (Receive) (Section 13.14) + + o Current Data Rate (Transmit) (Section 13.15) + + o Latency (Section 13.16) + + The Destination Up Message MAY contain one of each of the following + Data Items, if the Data Item is in use by the session: + + o Resources (Section 13.17) + + o Relative Link Quality (Receive) (Section 13.18) + + o Relative Link Quality (Transmit) (Section 13.19) + + o Maximum Transmission Unit (MTU) (Section 13.20) + + The Destination Up Message MAY contain one or more of each of the + following Data Items, with different values: + + o IPv4 Attached Subnet (Section 13.10) + + o IPv6 Attached Subnet (Section 13.11) + + A router receiving a Destination Up Message allocates the necessary + resources, creating an entry in the information base with the + specifics (MAC Address, Latency, Data Rate, etc.) of the destination. + The information about this destination will persist in the router's + information base until a Destination Down Message (Section 12.15) is + received, indicating that the modem has lost contact with the remote + node or that the implementation transitions to the Session + Termination state. + + + + + +Ratliff, et al. Standards Track [Page 29] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + +12.12. Destination Up Response Message + + A router MUST send a Destination Up Response Message when a + Destination Up Message (Section 12.11) is received. + + To construct a Destination Up Response Message, the Message Type + value in the Message Header is set to 8 (see "Message Type + Registration" (Section 15.3)). + + The Destination Up Response Message MUST contain one of each of the + following Data Items: + + o MAC Address (Section 13.7) + + o Status (Section 13.1) + + A router that wishes to receive further information concerning the + destination identified in the corresponding Destination Up Message + MUST set the status code of the included Status Data Item to + 0 'Success'; see Table 2. + + If the router has no interest in the destination identified in the + corresponding Destination Up Message, then it MAY set the status code + of the included Status Data Item to 1 'Not Interested'. + + A modem receiving a Destination Up Response Message containing a + Status Data Item with a status code of any value other than + 0 'Success' MUST NOT send further Destination Messages about the + destination, e.g., Destination Down (Section 12.15) or Destination + Update (Section 12.17) with the same MAC address. + +12.13. Destination Announce Message + + Usually, a modem will discover the presence of one or more remote + router/modem pairs and announce each destination's arrival by sending + a corresponding Destination Up Message (Section 12.11) to the router. + However, there may be times when a router wishes to express an + interest in a destination that has yet to be announced, typically a + multicast destination. Destination Announce Messages MAY be sent by + a router to announce such an interest. + + A Destination Announce Message MAY also be sent by a router to + request information concerning a destination (1) in which the router + has previously declined interest, via the 1 'Not Interested' status + code in a Destination Up Response Message (Section 12.12) (see + Table 2) or (2) that was previously declared as 'down', via the + Destination Down Message (Section 12.15). + + + + +Ratliff, et al. Standards Track [Page 30] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + To construct a Destination Announce Message, the Message Type value + in the Message Header is set to 9 (see "Message Type Registration" + (Section 15.3)). + + The Destination Announce Message MUST contain a MAC Address Data Item + (Section 13.7). + + The Destination Announce Message MAY contain zero or more of the + following Data Items, with different values: + + o IPv4 Address (Section 13.8) + + o IPv6 Address (Section 13.9) + + One of the advantages of implementing DLEP is to leverage the modem's + knowledge of the links between remote destinations, allowing routers + to avoid using probed neighbor discovery techniques; therefore, modem + implementations SHOULD announce available destinations via the + Destination Up Message, rather than relying on Destination Announce + Messages. + +12.14. Destination Announce Response Message + + A modem MUST send a Destination Announce Response Message when a + Destination Announce Message (Section 12.13) is received. + + To construct a Destination Announce Response Message, the Message + Type value in the Message Header is set to 10 (see "Message Type + Registration" (Section 15.3)). + + The Destination Announce Response Message MUST contain one of each of + the following Data Items: + + o MAC Address (Section 13.7) + + o Status (Section 13.1) + + The Destination Announce Response Message MAY contain one or more of + each of the following Data Items, with different values: + + o IPv4 Address (Section 13.8) + + o IPv6 Address (Section 13.9) + + o IPv4 Attached Subnet (Section 13.10) + + o IPv6 Attached Subnet (Section 13.11) + + + + +Ratliff, et al. Standards Track [Page 31] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + The Destination Announce Response Message MAY contain one of each of + the following Data Items: + + o Maximum Data Rate (Receive) (Section 13.12) + + o Maximum Data Rate (Transmit) (Section 13.13) + + o Current Data Rate (Receive) (Section 13.14) + + o Current Data Rate (Transmit) (Section 13.15) + + o Latency (Section 13.16) + + The Destination Announce Response Message MAY contain one of each of + the following Data Items, if the Data Item is in use by the session: + + o Resources (Section 13.17) + + o Relative Link Quality (Receive) (Section 13.18) + + o Relative Link Quality (Transmit) (Section 13.19) + + o Maximum Transmission Unit (MTU) (Section 13.20) + + If a modem is unable to report information immediately about the + requested information -- for example, if the destination is not + currently reachable -- the status code in the Status Data Item MUST + be set to 2 'Request Denied'; see Table 2. + + After sending a Destination Announce Response Message containing a + Status Data Item with a status code of 0 'Success', a modem then + announces changes to the link to the destination via Destination + Update Messages. + + When a successful Destination Announce Response Message is received, + the router should add knowledge of the available destination to its + information base. + +12.15. Destination Down Message + + A modem MUST send a Destination Down Message to report when a + destination (a remote node or a multicast group) is no longer + reachable. + + A router MAY send a Destination Down Message to report when it + no longer requires information concerning a destination. + + + + + +Ratliff, et al. Standards Track [Page 32] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + To construct a Destination Down Message, the Message Type value in + the Message Header is set to 11 (see "Message Type Registration" + (Section 15.3)). + + The Destination Down Message MUST contain a MAC Address Data Item + (Section 13.7). + + It should be noted that both modem and router may send a Destination + Down Message to their peer, regardless of which participant initially + indicated the destination to be 'up'. + +12.16. Destination Down Response Message + + A Destination Down Response Message MUST be sent by the recipient of + a Destination Down Message (Section 12.15) to confirm that the + relevant data concerning the destination has been removed from the + information base. + + To construct a Destination Down Response Message, the Message Type + value in the Message Header is set to 12 (see "Message Type + Registration" (Section 15.3)). + + The Destination Down Response Message MUST contain one of each of the + following Data Items: + + o MAC Address (Section 13.7) + + o Status (Section 13.1) + +12.17. Destination Update Message + + A modem SHOULD send a Destination Update Message when it detects some + change in the information base for a given destination (remote node + or multicast group). Some examples of changes that would prompt a + Destination Update Message are as follows: + + o Change in link metrics (e.g., data rates) + + o Layer 3 addressing change + + To construct a Destination Update Message, the Message Type value in + the Message Header is set to 13 (see "Message Type Registration" + (Section 15.3)). + + The Destination Update Message MUST contain a MAC Address Data Item + (Section 13.7). + + + + + +Ratliff, et al. Standards Track [Page 33] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + The Destination Update Message MAY contain one of each of the + following Data Items: + + o Maximum Data Rate (Receive) (Section 13.12) + + o Maximum Data Rate (Transmit) (Section 13.13) + + o Current Data Rate (Receive) (Section 13.14) + + o Current Data Rate (Transmit) (Section 13.15) + + o Latency (Section 13.16) + + The Destination Update Message MAY contain one of each of the + following Data Items, if the Data Item is in use by the session: + + o Resources (Section 13.17) + + o Relative Link Quality (Receive) (Section 13.18) + + o Relative Link Quality (Transmit) (Section 13.19) + + o Maximum Transmission Unit (MTU) (Section 13.20) + + The Destination Update Message MAY contain one or more of each of the + following Data Items, with different values: + + o IPv4 Address (Section 13.8) + + o IPv6 Address (Section 13.9) + + o IPv4 Attached Subnet (Section 13.10) + + o IPv6 Attached Subnet (Section 13.11) + + Metrics supplied in this Message overwrite metrics provided in a + previously received Session Message, Destination Message, or Link + Characteristics Message (e.g., Session Initialization, + Destination Up, Link Characteristics Response). + + It should be noted that this Message has no corresponding response. + + + + + + + + + + +Ratliff, et al. Standards Track [Page 34] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + +12.18. Link Characteristics Request Message + + The Link Characteristics Request Message MAY be sent by a router to + request that the modem initiate changes for specific characteristics + of the link. The request can reference either a real destination + (e.g., a remote node) or a logical destination (e.g., a multicast + group) within the network. + + To construct a Link Characteristics Request Message, the Message Type + value in the Message Header is set to 14 (see "Message Type + Registration" (Section 15.3)). + + The Link Characteristics Request Message MUST contain a MAC Address + Data Item (Section 13.7). + + The Link Characteristics Request Message MUST also contain at least + one of each of the following Data Items: + + o Current Data Rate (Receive) (Section 13.14) + + o Current Data Rate (Transmit) (Section 13.15) + + o Latency (Section 13.16) + + The Link Characteristics Request Message MAY contain either a Current + Data Rate (Receive) (CDRR) or Current Data Rate (Transmit) (CDRT) + Data Item to request a different data rate than is currently + allocated, a Latency Data Item to request that traffic delay on the + link not exceed the specified value, or both. + + The router sending a Link Characteristics Request Message should be + aware that a request may take an extended period of time to complete. + +12.19. Link Characteristics Response Message + + A modem MUST send a Link Characteristics Response Message when a Link + Characteristics Request Message (Section 12.18) is received. + + To construct a Link Characteristics Response Message, the Message + Type value in the Message Header is set to 15 (see "Message Type + Registration" (Section 15.3)). + + The Link Characteristics Response Message MUST contain one of each of + the following Data Items: + + o MAC Address (Section 13.7) + + o Status (Section 13.1) + + + +Ratliff, et al. Standards Track [Page 35] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + The Link Characteristics Response Message SHOULD contain one of each + of the following Data Items: + + o Maximum Data Rate (Receive) (Section 13.12) + + o Maximum Data Rate (Transmit) (Section 13.13) + + o Current Data Rate (Receive) (Section 13.14) + + o Current Data Rate (Transmit) (Section 13.15) + + o Latency (Section 13.16) + + The Link Characteristics Response Message MAY contain one of each of + the following Data Items, if the Data Item is in use by the session: + + o Resources (Section 13.17) + + o Relative Link Quality (Receive) (Section 13.18) + + o Relative Link Quality (Transmit) (Section 13.19) + + o Maximum Transmission Unit (MTU) (Section 13.20) + + The Link Characteristics Response Message MUST contain a complete set + of metric Data Items, referencing all metrics declared in the Session + Initialization Response Message (Section 12.6). The values in the + metric Data Items in the Link Characteristics Response Message MUST + reflect the link characteristics after the request has been + processed. + + If an implementation is not able to alter the characteristics of the + link in the manner requested, then the status code of the Status Data + Item MUST be set to 2 'Request Denied'; see Table 2. + +12.20. Heartbeat Message + + A Heartbeat Message MUST be sent by a DLEP participant every + N milliseconds, where N is defined in the Heartbeat Interval Data + Item (Section 13.5) of the Session Initialization Message + (Section 12.5) or Session Initialization Response Message + (Section 12.6). + + To construct a Heartbeat Message, the Message Type value in the + Message Header is set to 16 (see "Message Type Registration" + (Section 15.3)). + + There are no valid Data Items for the Heartbeat Message. + + + +Ratliff, et al. Standards Track [Page 36] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + The Heartbeat Message is used by DLEP participants to detect when a + DLEP session peer (either the modem or the router) is no longer + communicating; see Section 7.3.1. + +13. DLEP Data Items + + The core DLEP Data Items are as follows: + + +-------------+-----------------------------------------------------+ + | Type Code | Description | + +-------------+-----------------------------------------------------+ + | 0 | Reserved | + | | | + | 1 | Status (Section 13.1) | + | | | + | 2 | IPv4 Connection Point (Section 13.2) | + | | | + | 3 | IPv6 Connection Point (Section 13.3) | + | | | + | 4 | Peer Type (Section 13.4) | + | | | + | 5 | Heartbeat Interval (Section 13.5) | + | | | + | 6 | Extensions Supported (Section 13.6) | + | | | + | 7 | MAC Address (Section 13.7) | + | | | + | 8 | IPv4 Address (Section 13.8) | + | | | + | 9 | IPv6 Address (Section 13.9) | + | | | + | 10 | IPv4 Attached Subnet (Section 13.10) | + | | | + | 11 | IPv6 Attached Subnet (Section 13.11) | + | | | + | 12 | Maximum Data Rate (Receive) (MDRR) (Section 13.12) | + | | | + | 13 | Maximum Data Rate (Transmit) (MDRT) (Section 13.13) | + | | | + | 14 | Current Data Rate (Receive) (CDRR) (Section 13.14) | + | | | + | 15 | Current Data Rate (Transmit) (CDRT) (Section 13.15) | + | | | + | 16 | Latency (Section 13.16) | + | | | + | 17 | Resources (RES) (Section 13.17) | + | | | + + + + +Ratliff, et al. Standards Track [Page 37] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + | 18 | Relative Link Quality (Receive) (RLQR) | + | | (Section 13.18) | + | | | + | 19 | Relative Link Quality (Transmit) (RLQT) | + | | (Section 13.19) | + | | | + | 20 | Maximum Transmission Unit (MTU) (Section 13.20) | + | | | + | 21-65407 | Unassigned (available for future extensions) | + | | | + | 65408-65534 | Reserved for Private Use (available for | + | | experiments) | + | | | + | 65535 | Reserved | + +-------------+-----------------------------------------------------+ + + Table 1: DLEP Data Item Types + +13.1. Status + + For the Session Termination Message (Section 12.9), the Status Data + Item indicates a reason for the termination. For all response + messages, the Status Data Item is used to indicate the success or + failure of the previously received Message. + + The Status Data Item includes an optional Text field that can be used + to provide a textual description of the status. The use of the Text + field is entirely up to the receiving implementation, e.g., it could + be output to a log file or discarded. If no Text field is supplied + with the Status Data Item, the Length field MUST be set to 1. + + The Status Data Item contains the following fields: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data Item Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Status Code | Text... : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Data Item Type: 1 + + Length: 1 + Length of Text, in octets. + + Status Code: One of the status codes defined in Table 2 below. + + + + + +Ratliff, et al. Standards Track [Page 38] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + Text: UTF-8 encoded string of Unicode [RFC3629] characters, + describing the cause, used for implementation-defined purposes. + Since this field is used for description purposes, implementations + SHOULD limit characters in this field to printable characters. + + An implementation MUST NOT assume that the Text field is a + NUL-terminated string of printable characters. + + +----------+-------------+------------------+-----------------------+ + | Status | Failure | Description | Reason | + | Code | Mode | | | + +----------+-------------+------------------+-----------------------+ + | 0 | Continue | Success | The Message was | + | | | | processed | + | | | | successfully. | + | | | | | + | 1 | Continue | Not Interested | The receiver is not | + | | | | interested in this | + | | | | Message subject, | + | | | | e.g., in a | + | | | | Destination Up | + | | | | Response Message | + | | | | (Section 12.12) to | + | | | | indicate no further | + | | | | Messages about the | + | | | | destination. | + | | | | | + | 2 | Continue | Request Denied | The receiver refuses | + | | | | to complete the | + | | | | request. | + | | | | | + | 3 | Continue | Inconsistent | One or more Data | + | | | Data | Items in the Message | + | | | | describe a logically | + | | | | inconsistent state in | + | | | | the network -- for | + | | | | example, in the | + | | | | Destination Up | + | | | | Message | + | | | | (Section 12.11) when | + | | | | an announced subnet | + | | | | clashes with an | + | | | | existing destination | + | | | | subnet. | + | | | | | + + + + + + +Ratliff, et al. Standards Track [Page 39] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + | 4-111 | Continue | <Unassigned> | Available for future | + | | | | extensions. | + | | | | | + | 112-127 | Continue | <Reserved for | Available for | + | | | Private Use> | experiments. | + | | | | | + | 128 | Terminate | Unknown Message | The Message was not | + | | | | recognized by the | + | | | | implementation. | + | | | | | + | 129 | Terminate | Unexpected | The Message was not | + | | | Message | expected while the | + | | | | device was in the | + | | | | current state, e.g., | + | | | | a Session | + | | | | Initialization | + | | | | Message | + | | | | (Section 12.5) in | + | | | | the In-Session state. | + | | | | | + | 130 | Terminate | Invalid Data | One or more Data | + | | | | Items in the Message | + | | | | are invalid, | + | | | | unexpected, or | + | | | | incorrectly | + | | | | duplicated. | + | | | | | + | 131 | Terminate | Invalid | The destination | + | | | Destination | included in the | + | | | | Message does not | + | | | | match a previously | + | | | | announced destination | + | | | | -- for example, in | + | | | | the Link | + | | | | Characteristics | + | | | | Response Message | + | | | | (Section 12.19). | + | | | | | + | 132 | Terminate | Timed Out | The session has | + | | | | timed out. | + | | | | | + | 133-239 | Terminate | <Unassigned> | Available for future | + | | | | extensions. | + | | | | | + + + + + + + +Ratliff, et al. Standards Track [Page 40] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + | 240-254 | Terminate | <Reserved for | Available for | + | | | Private Use> | experiments. | + | | | | | + | 255 | Terminate | Shutting Down | The peer is | + | | | | terminating the | + | | | | session, as it is | + | | | | shutting down. | + +----------+-------------+------------------+-----------------------+ + + Table 2: DLEP Status Codes + +13.2. IPv4 Connection Point + + The IPv4 Connection Point Data Item indicates the IPv4 address and, + optionally, the TCP port number on the modem available for + connections. If provided, the router MUST use this information to + initiate the TCP connection to the modem. + + The IPv4 Connection Point Data Item contains the following fields: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data Item Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | IPv4 Address... : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : ...cont. | TCP Port Number (optional) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Data Item Type: 2 + + Length: 5 (or 7 if TCP Port Number included). + + Flags: Flags field, defined below. + + IPv4 Address: The IPv4 address listening on the modem. + + TCP Port Number: TCP port number on the modem. + + If the Length field is 7, the port number specified MUST be used to + establish the TCP session. If the TCP Port Number is omitted, i.e., + the Length field is 5, the router MUST use the DLEP well-known port + number (Section 15.14) to establish the TCP connection. + + + + + + + +Ratliff, et al. Standards Track [Page 41] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + The Flags field is defined as: + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + | Reserved |T| + +-+-+-+-+-+-+-+-+ + + T: Use TLS flag, indicating whether the TCP connection to the given + address and port requires the use of TLS [RFC5246] (1) or + not (0). + + Reserved: MUST be zero. Left for future assignment. + +13.3. IPv6 Connection Point + + The IPv6 Connection Point Data Item indicates the IPv6 address and, + optionally, the TCP port number on the modem available for + connections. If provided, the router MUST use this information to + initiate the TCP connection to the modem. + + The IPv6 Connection Point Data Item contains the following fields: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data Item Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | IPv6 Address : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : IPv6 Address : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : IPv6 Address : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : IPv6 Address : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : ...cont. | TCP Port Number (optional) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Data Item Type: 3 + + Length: 17 (or 19 if TCP Port Number included). + + Flags: Flags field, defined below. + + IPv6 Address: The IPv6 address listening on the modem. + + TCP Port Number: TCP port number on the modem. + + + + +Ratliff, et al. Standards Track [Page 42] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + If the Length field is 19, the port number specified MUST be used to + establish the TCP session. If the TCP Port Number is omitted, i.e., + the Length field is 17, the router MUST use the DLEP well-known port + number (Section 15.14) to establish the TCP connection. + + The Flags field is defined as: + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + | Reserved |T| + +-+-+-+-+-+-+-+-+ + + T: Use TLS flag, indicating whether the TCP connection to the given + address and port requires the use of TLS [RFC5246] (1) or + not (0). + + Reserved: MUST be zero. Left for future assignment. + +13.4. Peer Type + + The Peer Type Data Item is used by the router and modem to give + additional information as to its type and the properties of the + over-the-air control plane. + + With some devices, access to the shared RF medium is strongly + controlled. One example of this would be satellite modems -- where + protocols, proprietary in nature, have been developed to ensure that + a given modem has authorization to connect to the shared medium. + Another example of this class of modems is governmental/military + devices, where elaborate mechanisms have been developed to ensure + that only authorized devices can connect to the shared medium. + Contrasting with the above, there are modems where no such access + control is used. An example of this class of modem would be one that + supports the 802.11 ad hoc mode of operation. The Secured Medium (S) + flag is used to indicate if access control is in place. + + The Peer Type Data Item includes a textual description of the peer; + it is envisioned that the text will be used for informational + purposes (e.g., as output in a display command). + + + + + + + + + + + + +Ratliff, et al. Standards Track [Page 43] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + The Peer Type Data Item contains the following fields: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data Item Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | Description... : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Data Item Type: 4 + + Length: 1 + Length of Description, in octets. + + Flags: Flags field, defined below. + + Description: UTF-8 encoded string of Unicode [RFC3629] characters. + For example, a satellite modem might set this variable to + "Satellite terminal". Since this Data Item is intended to provide + additional information for display commands, sending + implementations SHOULD limit the data to printable characters. + + An implementation MUST NOT assume that the Description field is a + NUL-terminated string of printable characters. + + The Flags field is defined as: + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + | Reserved |S| + +-+-+-+-+-+-+-+-+ + + S: Secured Medium flag, used by a modem to indicate whether the + shared RF medium implements access control (1) or not (0). The + Secured Medium flag only has meaning in Signals and Messages sent + by a modem. + + Reserved: MUST be zero. Left for future assignment. + + + + + + + + + + + + + +Ratliff, et al. Standards Track [Page 44] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + +13.5. Heartbeat Interval + + The Heartbeat Interval Data Item is used to specify a period in + milliseconds for Heartbeat Messages (Section 12.20). + + The Heartbeat Interval Data Item contains the following fields: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data Item Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Heartbeat Interval | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Data Item Type: 5 + + Length: 4 + + Heartbeat Interval: The interval in milliseconds, expressed as a + 32-bit unsigned integer, for Heartbeat Messages. This value + MUST NOT be 0. + + As mentioned before, receipt of any valid DLEP Message MUST reset the + heartbeat interval timer (i.e., valid DLEP Messages take the place + of, and obviate the need for, additional Heartbeat Messages). + +13.6. Extensions Supported + + The Extensions Supported Data Item is used by the router and modem to + negotiate additional optional functionality they are willing to + support. The Extensions List is a concatenation of the types of each + supported extension, found in the IANA registry titled "Extension + Type Values". Each Extension Type definition includes which + additional Signals and Data Items are supported. + + + + + + + + + + + + + + + + +Ratliff, et al. Standards Track [Page 45] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + The Extensions Supported Data Item contains the following fields: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data Item Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Extensions List... : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Data Item Type: 6 + + Length: Length of the Extensions List in octets. This is twice (2x) + the number of extensions. + + Extensions List: A list of extensions supported, identified by their + 2-octet values as listed in the "Extension Type Values" registry. + +13.7. MAC Address + + The MAC Address Data Item contains the address of the destination on + the remote node. + + DLEP can support MAC addresses in either EUI-48 or EUI-64 format + ("EUI" stands for "Extended Unique Identifier"), with the restriction + that all MAC addresses for a given DLEP session MUST be in the same + format and MUST be consistent with the MAC address format of the + connected modem (e.g., if the modem is connected to the router with + an EUI-48 MAC, all destination addresses via that modem MUST be + expressed in EUI-48 format). + + Examples of a virtual destination would be (1) a multicast MAC + address or (2) the broadcast MAC address (FF:FF:FF:FF:FF:FF). + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data Item Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MAC Address : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : MAC Address : (if EUI-64 used) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + +Ratliff, et al. Standards Track [Page 46] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + Data Item Type: 7 + + Length: 6 for EUI-48 format or 8 for EUI-64 format. + + MAC Address: MAC address of the destination. + +13.8. IPv4 Address + + When included in the Session Update Message, this Data Item contains + the IPv4 address of the peer. When included in Destination Messages, + this Data Item contains the IPv4 address of the destination. In + either case, the Data Item also contains an indication of whether + this is (1) a new or existing address or (2) a deletion of a + previously known address. + + The IPv4 Address Data Item contains the following fields: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data Item Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | IPv4 Address : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : ...cont. | + +-+-+-+-+-+-+-+-+ + + Data Item Type: 8 + + Length: 5 + + Flags: Flags field, defined below. + + IPv4 Address: The IPv4 address of the destination or peer. + + The Flags field is defined as: + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + | Reserved |A| + +-+-+-+-+-+-+-+-+ + + A: Add/Drop flag, indicating whether this is a new or existing + address (1) or a withdrawal of an address (0). + + Reserved: MUST be zero. Reserved for future use. + + + + + +Ratliff, et al. Standards Track [Page 47] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + +13.8.1. IPv4 Address Processing + + Processing of the IPv4 Address Data Item MUST be done within the + context of the DLEP peer session on which it is presented. + + The handling of erroneous or logically inconsistent conditions + depends upon the type of the message that contains the Data Item, + as follows: + + If the containing message is a Session Message, e.g., a Session + Initialization Message (Section 12.5) or Session Update Message + (Section 12.7), the receiver of inconsistent information MUST issue a + Session Termination Message (Section 12.9) containing a Status Data + Item (Section 13.1) with status code set to 130 'Invalid Data' and + transition to the Session Termination state. Examples of such + conditions are: + + o An address Drop operation referencing an address that is not + associated with the peer in the current session. + + o An address Add operation referencing an address that has already + been added to the peer in the current session. + + If the containing message is a Destination Message, e.g., a + Destination Up Message (Section 12.11) or Destination Update Message + (Section 12.17), the receiver of inconsistent information MAY issue + the appropriate response message containing a Status Data Item with + status code set to 3 'Inconsistent Data' but MUST continue with + session processing. Examples of such conditions are: + + o An address Add operation referencing an address that has already + been added to the destination in the current session. + + o An address Add operation referencing an address that is associated + with a different destination or the peer in the current session. + + o An address Add operation referencing an address that makes no + sense -- for example, defined as not forwardable in [RFC6890]. + + o An address Drop operation referencing an address that is not + associated with the destination in the current session. + + If no response message is appropriate -- for example, the Destination + Update Message -- then the implementation MUST continue with session + processing. + + Modems that do not track IPv4 addresses MUST silently ignore IPv4 + Address Data Items. + + + +Ratliff, et al. Standards Track [Page 48] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + +13.9. IPv6 Address + + When included in the Session Update Message, this Data Item contains + the IPv6 address of the peer. When included in Destination Messages, + this Data Item contains the IPv6 address of the destination. In + either case, the Data Item also contains an indication of whether + this is (1) a new or existing address or (2) a deletion of a + previously known address. + + The IPv6 Address Data Item contains the following fields: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data Item Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | IPv6 Address : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : IPv6 Address : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : IPv6 Address : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : IPv6 Address : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : IPv6 Address | + +-+-+-+-+-+-+-+-+ + + Data Item Type: 9 + + Length: 17 + + Flags: Flags field, defined below. + + IPv6 Address: The IPv6 address of the destination or peer. + + The Flags field is defined as: + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + | Reserved |A| + +-+-+-+-+-+-+-+-+ + + A: Add/Drop flag, indicating whether this is a new or existing + address (1) or a withdrawal of an address (0). + + Reserved: MUST be zero. Reserved for future use. + + + + + +Ratliff, et al. Standards Track [Page 49] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + +13.9.1. IPv6 Address Processing + + Processing of the IPv6 Address Data Item MUST be done within the + context of the DLEP peer session on which it is presented. + + The handling of erroneous or logically inconsistent conditions + depends upon the type of the message that contains the Data Item, + as follows: + + If the containing message is a Session Message, e.g., a Session + Initialization Message (Section 12.5) or Session Update Message + (Section 12.7), the receiver of inconsistent information MUST issue a + Session Termination Message (Section 12.9) containing a Status Data + Item (Section 13.1) with status code set to 130 'Invalid Data' and + transition to the Session Termination state. Examples of such + conditions are: + + o An address Drop operation referencing an address that is not + associated with the peer in the current session. + + o An address Add operation referencing an address that has already + been added to the peer in the current session. + + If the containing message is a Destination Message, e.g., a + Destination Up Message (Section 12.11) or Destination Update Message + (Section 12.17), the receiver of inconsistent information MAY issue + the appropriate response message containing a Status Data Item with + status code set to 3 'Inconsistent Data' but MUST continue with + session processing. Examples of such conditions are: + + o An address Add operation referencing an address that has already + been added to the destination in the current session. + + o An address Add operation referencing an address that is associated + with a different destination or the peer in the current session. + + o An address Add operation referencing an address that makes no + sense -- for example, defined as not forwardable in [RFC6890]. + + o An address Drop operation referencing an address that is not + associated with the destination in the current session. + + If no response message is appropriate -- for example, the Destination + Update Message -- then the implementation MUST continue with session + processing. + + Modems that do not track IPv6 addresses MUST silently ignore IPv6 + Address Data Items. + + + +Ratliff, et al. Standards Track [Page 50] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + +13.10. IPv4 Attached Subnet + + The DLEP IPv4 Attached Subnet Data Item allows a device to declare + that it has an IPv4 subnet (e.g., a stub network) attached, that it + has become aware of an IPv4 subnet being present at a remote + destination, or that it has become aware of the loss of a subnet at + the remote destination. + + The DLEP IPv4 Attached Subnet Data Item contains the following + fields: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data Item Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | IPv4 Attached Subnet : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : ...cont. |Prefix Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Data Item Type: 10 + + Length: 6 + + Flags: Flags field, defined below. + + IPv4 Attached Subnet: The IPv4 subnet reachable at the destination. + + Prefix Length: Length of the prefix (0-32) for the IPv4 subnet. A + prefix length outside the specified range MUST be considered as + invalid. + + The Flags field is defined as: + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + | Reserved |A| + +-+-+-+-+-+-+-+-+ + + A: Add/Drop flag, indicating whether this is a new or existing + subnet address (1) or a withdrawal of a subnet address (0). + + Reserved: MUST be zero. Reserved for future use. + + + + + + + +Ratliff, et al. Standards Track [Page 51] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + +13.10.1. IPv4 Attached Subnet Processing + + Processing of the IPv4 Attached Subnet Data Item MUST be done within + the context of the DLEP peer session on which it is presented. + + If the containing message is a Session Message, e.g., a Session + Initialization Message (Section 12.5) or Session Update Message + (Section 12.7), the receiver of inconsistent information MUST issue a + Session Termination Message (Section 12.9) containing a Status Data + Item (Section 13.1) with status code set to 130 'Invalid Data' and + transition to the Session Termination state. Examples of such + conditions are: + + o A subnet Drop operation referencing a subnet that is not + associated with the peer in the current session. + + o A subnet Add operation referencing a subnet that has already been + added to the peer in the current session. + + If the containing message is a Destination Message, e.g., a + Destination Up Message (Section 12.11) or Destination Update Message + (Section 12.17), the receiver of inconsistent information MAY issue + the appropriate response message containing a Status Data Item with + status code set to 3 'Inconsistent Data' but MUST continue with + session processing. Examples of such conditions are: + + o A subnet Add operation referencing a subnet that has already been + added to the destination in the current session. + + o A subnet Add operation referencing a subnet that is associated + with a different destination in the current session. + + o A subnet Add operation referencing a subnet that makes no sense -- + for example, defined as not forwardable in [RFC6890]. + + o A subnet Drop operation referencing a subnet that is not + associated with the destination in the current session. + + If no response message is appropriate -- for example, the Destination + Update Message -- then the implementation MUST continue with session + processing. + + Modems that do not track IPv4 subnets MUST silently ignore IPv4 + Attached Subnet Data Items. + + + + + + + +Ratliff, et al. Standards Track [Page 52] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + +13.11. IPv6 Attached Subnet + + The DLEP IPv6 Attached Subnet Data Item allows a device to declare + that it has an IPv6 subnet (e.g., a stub network) attached, that it + has become aware of an IPv6 subnet being present at a remote + destination, or that it has become aware of the loss of a subnet at + the remote destination. + + The DLEP IPv6 Attached Subnet Data Item contains the following + fields: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data Item Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | IPv6 Attached Subnet : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : IPv6 Attached Subnet : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : IPv6 Attached Subnet : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : IPv6 Attached Subnet : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : ...cont. | Prefix Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Data Item Type: 11 + + Length: 18 + + Flags: Flags field, defined below. + + IPv6 Attached Subnet: The IPv6 subnet reachable at the destination. + + Prefix Length: Length of the prefix (0-128) for the IPv6 subnet. A + prefix length outside the specified range MUST be considered as + invalid. + + + + + + + + + + + + + +Ratliff, et al. Standards Track [Page 53] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + The Flags field is defined as: + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + | Reserved |A| + +-+-+-+-+-+-+-+-+ + + A: Add/Drop flag, indicating whether this is a new or existing + subnet address (1) or a withdrawal of a subnet address (0). + + Reserved: MUST be zero. Reserved for future use. + +13.11.1. IPv6 Attached Subnet Processing + + Processing of the IPv6 Attached Subnet Data Item MUST be done within + the context of the DLEP peer session on which it is presented. + + If the containing message is a Session Message, e.g., a Session + Initialization Message (Section 12.5) or Session Update Message + (Section 12.7), the receiver of inconsistent information MUST issue a + Session Termination Message (Section 12.9) containing a Status Data + Item (Section 13.1) with status code set to 130 'Invalid Data' and + transition to the Session Termination state. Examples of such + conditions are: + + o A subnet Drop operation referencing a subnet that is not + associated with the peer in the current session. + + o A subnet Add operation referencing a subnet that has already been + added to the peer in the current session. + + If the containing message is a Destination Message, e.g., a + Destination Up Message (Section 12.11) or Destination Update Message + (Section 12.17), the receiver of inconsistent information MAY issue + the appropriate response message containing a Status Data Item with + status code set to 3 'Inconsistent Data' but MUST continue with + session processing. Examples of such conditions are: + + o A subnet Add operation referencing a subnet that has already been + added to the destination in the current session. + + o A subnet Add operation referencing a subnet that is associated + with a different destination in the current session. + + + + + + + + +Ratliff, et al. Standards Track [Page 54] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + o A subnet Add operation referencing a subnet that makes no sense -- + for example, defined as not forwardable in [RFC6890]. + + o A subnet Drop operation referencing a subnet that is not + associated with the destination in the current session. + + If no response message is appropriate -- for example, the Destination + Update Message -- then the implementation MUST continue with session + processing. + + Modems that do not track IPv6 subnets MUST silently ignore IPv6 + Attached Subnet Data Items. + +13.12. Maximum Data Rate (Receive) + + The Maximum Data Rate (Receive) (MDRR) Data Item is used to indicate + the maximum theoretical data rate, in bits per second (bps), that can + be achieved while receiving data on the link. + + The Maximum Data Rate (Receive) Data Item contains the following + fields: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data Item Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MDRR (bps) : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : MDRR (bps) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Data Item Type: 12 + + Length: 8 + + Maximum Data Rate (Receive): A 64-bit unsigned integer, representing + the maximum theoretical data rate, in bits per second, that can be + achieved while receiving on the link. + + + + + + + + + + + + +Ratliff, et al. Standards Track [Page 55] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + +13.13. Maximum Data Rate (Transmit) + + The Maximum Data Rate (Transmit) (MDRT) Data Item is used to indicate + the maximum theoretical data rate, in bits per second, that can be + achieved while transmitting data on the link. + + The Maximum Data Rate (Transmit) Data Item contains the following + fields: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data Item Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MDRT (bps) : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : MDRT (bps) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Data Item Type: 13 + + Length: 8 + + Maximum Data Rate (Transmit): A 64-bit unsigned integer, + representing the maximum theoretical data rate, in bits per + second, that can be achieved while transmitting on the link. + +13.14. Current Data Rate (Receive) + + The Current Data Rate (Receive) (CDRR) Data Item is used to indicate + the rate at which the link is currently operating for receiving + traffic. + + When used in the Link Characteristics Request Message + (Section 12.18), Current Data Rate (Receive) represents the desired + receive rate, in bits per second, on the link. + + + + + + + + + + + + + + + +Ratliff, et al. Standards Track [Page 56] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + The Current Data Rate (Receive) Data Item contains the following + fields: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data Item Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | CDRR (bps) : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : CDRR (bps) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Data Item Type: 14 + + Length: 8 + + Current Data Rate (Receive): A 64-bit unsigned integer, representing + the current data rate, in bits per second, that can currently be + achieved while receiving traffic on the link. + + If there is no distinction between Current Data Rate (Receive) and + Maximum Data Rate (Receive) (Section 13.12), Current Data Rate + (Receive) MUST be set equal to Maximum Data Rate (Receive). Current + Data Rate (Receive) MUST NOT exceed Maximum Data Rate (Receive). + +13.15. Current Data Rate (Transmit) + + The Current Data Rate (Transmit) (CDRT) Data Item is used to indicate + the rate at which the link is currently operating for transmitting + traffic. + + When used in the Link Characteristics Request Message + (Section 12.18), Current Data Rate (Transmit) represents the desired + transmit rate, in bits per second, on the link. + + The Current Data Rate (Transmit) Data Item contains the following + fields: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data Item Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | CDRT (bps) : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : CDRT (bps) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + +Ratliff, et al. Standards Track [Page 57] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + Data Item Type: 15 + + Length: 8 + + Current Data Rate (Transmit): A 64-bit unsigned integer, + representing the current data rate, in bits per second, that can + currently be achieved while transmitting traffic on the link. + + If there is no distinction between Current Data Rate (Transmit) and + Maximum Data Rate (Transmit) (Section 13.13), Current Data Rate + (Transmit) MUST be set equal to Maximum Data Rate (Transmit). + Current Data Rate (Transmit) MUST NOT exceed Maximum Data Rate + (Transmit). + +13.16. Latency + + The Latency Data Item is used to indicate the amount of latency, in + microseconds, on the link. + + The Latency value is reported as transmission delay. The calculation + of latency is implementation dependent. For example, the latency may + be a running average calculated from the internal queuing. + + The Latency Data Item contains the following fields: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data Item Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Latency : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : Latency | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Data Item Type: 16 + + Length: 8 + + Latency: A 64-bit unsigned integer, representing the transmission + delay, in microseconds, that a packet encounters as it is + transmitted over the link. + + + + + + + + + +Ratliff, et al. Standards Track [Page 58] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + +13.17. Resources + + The Resources (RES) Data Item is used to indicate the amount of + finite resources available for data transmission and reception at the + destination as a percentage, with 0 meaning 'no resources remaining' + and 100 meaning 'a full supply', assuming that when Resources reaches + 0 data transmission and/or reception will cease. + + An example of such resources is battery life, but this could also + include resources such as available memory for queuing, or CPU idle + percentage. The specific criteria to be used for this metric is out + of scope for this specification and is implementation specific. + + This Data Item is designed to be used as an indication of some + capability of the modem and/or router at the destination. + + The Resources Data Item contains the following fields: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data Item Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RES | + +-+-+-+-+-+-+-+-+ + + Data Item Type: 17 + + Length: 1 + + Resources: An 8-bit unsigned integer percentage, 0-100, representing + the amount of resources available. Any value greater than 100 + MUST be considered as invalid. + + If a device cannot calculate Resources, this Data Item MUST NOT + be issued. + + + + + + + + + + + + + + + +Ratliff, et al. Standards Track [Page 59] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + +13.18. Relative Link Quality (Receive) + + The Relative Link Quality (Receive) (RLQR) Data Item is used to + indicate the quality of the link to a destination for receiving + traffic, with 0 meaning 'worst quality' and 100 meaning 'best + quality'. + + Quality in this context is defined as an indication of the stability + of a link for reception; a destination with high Relative Link + Quality (Receive) is expected to have generally stable DLEP metrics, + and the metrics of a destination with low Relative Link Quality + (Receive) can be expected to rapidly fluctuate over a wide range. + + The Relative Link Quality (Receive) Data Item contains the following + fields: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data Item Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RLQR | + +-+-+-+-+-+-+-+-+ + + Data Item Type: 18 + + Length: 1 + + Relative Link Quality (Receive): A non-dimensional unsigned 8-bit + integer, 0-100, representing relative quality of the link for + receiving traffic. Any value greater than 100 MUST be considered + as invalid. + + If a device cannot calculate Relative Link Quality (Receive), this + Data Item MUST NOT be issued. + +13.19. Relative Link Quality (Transmit) + + The Relative Link Quality (Transmit) (RLQT) Data Item is used to + indicate the quality of the link to a destination for transmitting + traffic, with 0 meaning 'worst quality' and 100 meaning 'best + quality'. + + Quality in this context is defined as an indication of the stability + of a link for transmission; a destination with high Relative Link + Quality (Transmit) is expected to have generally stable DLEP metrics, + and the metrics of a destination with low Relative Link Quality + (Transmit) can be expected to rapidly fluctuate over a wide range. + + + +Ratliff, et al. Standards Track [Page 60] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + The Relative Link Quality (Transmit) Data Item contains the following + fields: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data Item Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | RLQT | + +-+-+-+-+-+-+-+-+ + + Data Item Type: 19 + + Length: 1 + + Relative Link Quality (Transmit): A non-dimensional unsigned 8-bit + integer, 0-100, representing relative quality of the link for + transmitting traffic. Any value greater than 100 MUST be + considered as invalid. + + If a device cannot calculate Relative Link Quality (Transmit), this + Data Item MUST NOT be issued. + +13.20. Maximum Transmission Unit (MTU) + + The Maximum Transmission Unit (MTU) Data Item is used to indicate the + maximum size, in octets, of an IP packet that can be transmitted + without fragmentation, including headers, but excluding any + lower-layer headers. + + The Maximum Transmission Unit Data Item contains the following + fields: + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data Item Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MTU | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Data Item Type: 20 + + Length: 2 + + Maximum Transmission Unit: The maximum size, in octets, of an + IP packet that can be transmitted without fragmentation, including + headers, but excluding any lower-layer headers. + + + +Ratliff, et al. Standards Track [Page 61] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + If a device cannot calculate Maximum Transmission Unit, this Data + Item MUST NOT be issued. + +14. Security Considerations + + The potential security concerns when using DLEP are as follows: + + 1. An attacker might pretend to be a DLEP participant, either at + DLEP session initialization or by injection of DLEP Messages once + a session has been established. + + 2. DLEP Data Items could be altered by an attacker, causing the + receiving implementation to inappropriately alter its information + base concerning network status. + + 3. An attacker could join an unsecured radio network and inject + over-the-air signals that maliciously influence the information + reported by a DLEP modem, causing a router to forward traffic to + an inappropriate destination. + + The implications of attacks on DLEP peers are directly proportional + to the extent to which DLEP data is used within the control plane. + While the use of DLEP data in other control-plane components is out + of scope for this document, as an example, if DLEP statistics are + incorporated into route cost calculations, adversaries masquerading + as a DLEP peer and injecting malicious data via DLEP could cause + suboptimal route selection, adversely impacting network performance. + Similar issues can arise if DLEP data is used as an input to policing + algorithms -- injection of malicious data via DLEP can cause those + policing algorithms to make incorrect decisions, degrading network + throughput. + + For these reasons, security of the DLEP transport must be considered + at both the transport layer and Layer 2. + + At the transport layer, when TLS is in use, each peer SHOULD check + the validity of credentials presented by the other peer during TLS + session establishment. Implementations following the "dedicated + deployments" model attempting to use TLS MAY (1) need to consider the + use of pre-shared keys for credentials, (2) provide specialized + techniques for peer identity validation, and (3) refer to [RFC5487] + for additional details. Implementations following the "networked + deployment" model described in "Implementation Scenarios" (Section 4) + SHOULD refer to [RFC7525] for additional details. + + + + + + + +Ratliff, et al. Standards Track [Page 62] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + At Layer 2, since DLEP is restricted to operation over a single + (possibly logical) hop, implementations SHOULD also secure the + Layer 2 link. Examples of technologies that can be deployed to + secure the Layer 2 link include [IEEE-802.1AE] and [IEEE-802.1X]. + + By examining the Secured Medium flag in the Peer Type Data Item + (Section 13.4), a router can decide if it is able to trust the + information supplied via a DLEP modem. If this is not the case, then + the router SHOULD consider restricting the size of attached subnets, + announced in IPv4 Attached Subnet Data Items (Section 13.10) and/or + IPv6 Attached Subnet Data Items (Section 13.11), that are considered + for route selection. + + To avoid potential denial-of-service attacks, it is RECOMMENDED that + implementations using the Peer Discovery mechanism (1) maintain an + information base of hosts that persistently fail Session + Initialization, even though those hosts have provided an acceptable + Peer Discovery Signal and (2) ignore any subsequent Peer Discovery + Signals from such hosts. + + This specification does not address security of the data plane, as it + (the data plane) is not affected, and standard security procedures + can be employed. + +15. IANA Considerations + +15.1. Registrations + + IANA has created a new protocol registry for the Dynamic Link + Exchange Protocol (DLEP). The remainder of this section details the + new DLEP-specific registries. + +15.2. Signal Type Registrations + + IANA has created a new DLEP registry, named "Signal Type Values". + + + + + + + + + + + + + + + + +Ratliff, et al. Standards Track [Page 63] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + The following table provides initial registry values and the + policies, as defined by [RFC5226], that apply to the registry: + + +--------------+--------------------------------------+ + | Type Code | Description/Policy | + +--------------+--------------------------------------+ + | 0 | Reserved | + | 1 | Peer Discovery Signal | + | 2 | Peer Offer Signal | + | 3-65519 | Unassigned / Specification Required | + | 65520-65534 | Reserved for Private Use | + | 65535 | Reserved | + +--------------+--------------------------------------+ + +15.3. Message Type Registrations + + IANA has created a new DLEP registry, named "Message Type Values". + + The following table provides initial registry values and the + policies, as defined by [RFC5226], that apply to the registry: + + +--------------+------------------------------------------+ + | Type Code | Description/Policy | + +--------------+------------------------------------------+ + | 0 | Reserved | + | | | + | 1 | Session Initialization Message | + | | | + | 2 | Session Initialization Response Message | + | | | + | 3 | Session Update Message | + | | | + | 4 | Session Update Response Message | + | | | + | 5 | Session Termination Message | + | | | + | 6 | Session Termination Response Message | + | | | + | 7 | Destination Up Message | + | | | + | 8 | Destination Up Response Message | + | | | + | 9 | Destination Announce Message | + | | | + | 10 | Destination Announce Response Message | + | | | + | 11 | Destination Down Message | + | | | + + + +Ratliff, et al. Standards Track [Page 64] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + | 12 | Destination Down Response Message | + | | | + | 13 | Destination Update Message | + | | | + | 14 | Link Characteristics Request Message | + | | | + | 15 | Link Characteristics Response Message | + | | | + | 16 | Heartbeat Message | + | | | + | 17-65519 | Unassigned / Specification Required | + | | | + | 65520-65534 | Reserved for Private Use | + | | | + | 65535 | Reserved | + +--------------+------------------------------------------+ + +15.4. DLEP Data Item Registrations + + IANA has created a new DLEP registry, named "Data Item Type Values". + + The following table provides initial registry values and the + policies, as defined by [RFC5226], that apply to the registry: + + +-------------------+------------------------------------------+ + | Type Code | Description/Policy | + +-------------------+------------------------------------------+ + | 0 | Reserved | + | | | + | 1 | Status | + | | | + | 2 | IPv4 Connection Point | + | | | + | 3 | IPv6 Connection Point | + | | | + | 4 | Peer Type | + | | | + | 5 | Heartbeat Interval | + | | | + | 6 | Extensions Supported | + | | | + | 7 | MAC Address | + | | | + | 8 | IPv4 Address | + | | | + | 9 | IPv6 Address | + | | | + | 10 | IPv4 Attached Subnet | + + + +Ratliff, et al. Standards Track [Page 65] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + | | | + | 11 | IPv6 Attached Subnet | + | | | + | 12 | Maximum Data Rate (Receive) (MDRR) | + | | | + | 13 | Maximum Data Rate (Transmit) (MDRT) | + | | | + | 14 | Current Data Rate (Receive) (CDRR) | + | | | + | 15 | Current Data Rate (Transmit) (CDRT) | + | | | + | 16 | Latency | + | | | + | 17 | Resources (RES) | + | | | + | 18 | Relative Link Quality (Receive) (RLQR) | + | | | + | 19 | Relative Link Quality (Transmit) (RLQT) | + | | | + | 20 | Maximum Transmission Unit (MTU) | + | | | + | 21-65407 | Unassigned / Specification Required | + | | | + | 65408-65534 | Reserved for Private Use | + | | | + | 65535 | Reserved | + +-------------------+------------------------------------------+ + +15.5. DLEP Status Code Registrations + + IANA has created a new DLEP registry, named "Status Code Values". + + The following table provides initial registry values and the + policies, as defined by [RFC5226], that apply to the registry: + + +--------------+---------------+------------------------------------+ + | Status Code | Failure Mode | Description/Policy | + +--------------+---------------+------------------------------------+ + | 0 | Continue | Success | + | | | | + | 1 | Continue | Not Interested | + | | | | + | 2 | Continue | Request Denied | + | | | | + | 3 | Continue | Inconsistent Data | + | | | | + | 4-111 | Continue | Unassigned / Specification | + | | | Required | + + + +Ratliff, et al. Standards Track [Page 66] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + | | | | + | 112-127 | Continue | Private Use | + | | | | + | 128 | Terminate | Unknown Message | + | | | | + | 129 | Terminate | Unexpected Message | + | | | | + | 130 | Terminate | Invalid Data | + | | | | + | 131 | Terminate | Invalid Destination | + | | | | + | 132 | Terminate | Timed Out | + | | | | + | 133-239 | Terminate | Unassigned / Specification | + | | | Required | + | | | | + | 240-254 | Terminate | Reserved for Private Use | + | | | | + | 255 | Terminate | Shutting Down | + +--------------+---------------+------------------------------------+ + +15.6. DLEP Extension Registrations + + IANA has created a new DLEP registry, named "Extension Type Values". + + The following table provides initial registry values and the + policies, as defined by [RFC5226], that apply to the registry: + + +--------------+--------------------------------------+ + | Code | Description/Policy | + +--------------+--------------------------------------+ + | 0 | Reserved | + | 1-65519 | Unassigned / Specification Required | + | 65520-65534 | Reserved for Private Use | + | 65535 | Reserved | + +--------------+--------------------------------------+ + + Table 3: DLEP Extension Types + + + + + + + + + + + + + +Ratliff, et al. Standards Track [Page 67] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + +15.7. DLEP IPv4 Connection Point Flags + + IANA has created a new DLEP registry, named "IPv4 Connection Point + Flags". + + The following table provides initial registry values and the + policies, as defined by [RFC5226], that apply to the registry: + + +------------+--------------------------------------+ + | Bit | Description/Policy | + +------------+--------------------------------------+ + | 0-6 | Unassigned / Specification Required | + | 7 | Use TLS [RFC5246] indicator | + +------------+--------------------------------------+ + +15.8. DLEP IPv6 Connection Point Flags + + IANA has created a new DLEP registry, named "IPv6 Connection Point + Flags". + + The following table provides initial registry values and the + policies, as defined by [RFC5226], that apply to the registry: + + +------------+--------------------------------------+ + | Bit | Description/Policy | + +------------+--------------------------------------+ + | 0-6 | Unassigned / Specification Required | + | 7 | Use TLS [RFC5246] indicator | + +------------+--------------------------------------+ + +15.9. DLEP Peer Type Flags + + IANA has created a new DLEP registry, named "Peer Type Flags". + + The following table provides initial registry values and the + policies, as defined by [RFC5226], that apply to the registry: + + +------------+--------------------------------------+ + | Bit | Description/Policy | + +------------+--------------------------------------+ + | 0-6 | Unassigned / Specification Required | + | 7 | Secured Medium indicator | + +------------+--------------------------------------+ + + + + + + + + +Ratliff, et al. Standards Track [Page 68] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + +15.10. DLEP IPv4 Address Flags + + IANA has created a new DLEP registry, named "IPv4 Address Flags". + + The following table provides initial registry values and the + policies, as defined by [RFC5226], that apply to the registry: + + +------------+--------------------------------------+ + | Bit | Description/Policy | + +------------+--------------------------------------+ + | 0-6 | Unassigned / Specification Required | + | 7 | Add/Drop indicator | + +------------+--------------------------------------+ + +15.11. DLEP IPv6 Address Flags + + IANA has created a new DLEP registry, named "IPv6 Address Flags". + + The following table provides initial registry values and the + policies, as defined by [RFC5226], that apply to the registry: + + +------------+--------------------------------------+ + | Bit | Description/Policy | + +------------+--------------------------------------+ + | 0-6 | Unassigned / Specification Required | + | 7 | Add/Drop indicator | + +------------+--------------------------------------+ + +15.12. DLEP IPv4 Attached Subnet Flags + + IANA has created a new DLEP registry, named "IPv4 Attached Subnet + Flags". + + The following table provides initial registry values and the + policies, as defined by [RFC5226], that apply to the registry: + + +------------+--------------------------------------+ + | Bit | Description/Policy | + +------------+--------------------------------------+ + | 0-6 | Unassigned / Specification Required | + | 7 | Add/Drop indicator | + +------------+--------------------------------------+ + + + + + + + + + +Ratliff, et al. Standards Track [Page 69] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + +15.13. DLEP IPv6 Attached Subnet Flags + + IANA has created a new DLEP registry, named "IPv6 Attached Subnet + Flags". + + The following table provides initial registry values and the + policies, as defined by [RFC5226], that apply to the registry: + + +------------+--------------------------------------+ + | Bit | Description/Policy | + +------------+--------------------------------------+ + | 0-6 | Unassigned / Specification Required | + | 7 | Add/Drop indicator | + +------------+--------------------------------------+ + +15.14. DLEP Well-Known Port + + IANA has assigned the value 854 in the "Service Name and Transport + Protocol Port Number Registry" found at + <http://www.iana.org/assignments/service-names-port-numbers/> for use + by "DLEP", as defined in this document. This assignment is valid for + TCP and UDP. + +15.15. DLEP IPv4 Link-Local Multicast Address + + IANA has assigned the IPv4 multicast address 224.0.0.117 in the + registry found at + <http://www.iana.org/assignments/multicast-addresses> for use as + "DLEP Discovery". + +15.16. DLEP IPv6 Link-Local Multicast Address + + IANA has assigned the IPv6 multicast address FF02:0:0:0:0:0:1:7 in + the registry found at + <http://www.iana.org/assignments/ipv6-multicast-addresses> for use as + "DLEP Discovery". + + + + + + + + + + + + + + + +Ratliff, et al. Standards Track [Page 70] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + +16. References + +16.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of + ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, + November 2003, <http://www.rfc-editor.org/info/rfc3629>. + + [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. + Pignataro, "The Generalized TTL Security Mechanism + (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, + <http://www.rfc-editor.org/info/rfc5082>. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, + DOI 10.17487/RFC5246, August 2008, + <http://www.rfc-editor.org/info/rfc5246>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in + RFC 2119 Key Words", BCP 14, RFC 8174, + DOI 10.17487/RFC8174, May 2017, + <http://www.rfc-editor.org/info/rfc8174>. + +16.2. Informative References + + [IEEE-802.1AE] + "IEEE Standards for Local and Metropolitan Area Networks: + Media Access Control (MAC) Security", + DOI 10.1109/IEEESTD.2006.245590, + <http://ieeexplore.ieee.org/document/1678345/>. + + [IEEE-802.1X] + "IEEE Standards for Local and metropolitan area networks-- + Port-Based Network Access Control", + DOI 10.1109/IEEESTD.2010.5409813, + <http://ieeexplore.ieee.org/document/5409813/>. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + DOI 10.17487/RFC5226, May 2008, + <http://www.rfc-editor.org/info/rfc5226>. + + + + + +Ratliff, et al. Standards Track [Page 71] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + + [RFC5487] Badra, M., "Pre-Shared Key Cipher Suites for TLS with + SHA-256/384 and AES Galois Counter Mode", RFC 5487, + DOI 10.17487/RFC5487, March 2009, + <http://www.rfc-editor.org/info/rfc5487>. + + [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, + "Special-Purpose IP Address Registries", BCP 153, + RFC 6890, DOI 10.17487/RFC6890, April 2013, + <http://www.rfc-editor.org/info/rfc6890>. + + [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, + "Recommendations for Secure Use of Transport Layer + Security (TLS) and Datagram Transport Layer Security + (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, + May 2015, <http://www.rfc-editor.org/info/rfc7525>. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ratliff, et al. Standards Track [Page 72] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + +Appendix A. Discovery Signal Flows + +Router Modem Signal Description +======================================================================== + +| Router initiates discovery, +| starts a timer, sends Peer +|-------Peer Discovery---->X Discovery Signal. + + ~ ~ ~ ~ ~ ~ ~ Router discovery timer expires + without receiving Peer Offer. + +| Router sends another Peer +|-------Peer Discovery---------->| Discovery Signal. + | + | Modem receives Peer Discovery + | Signal. + | + | Modem sends Peer Offer with +|<--------Peer Offer-------------| Connection Point information. +: +: Router MAY cancel discovery timer +: and stop sending Peer Discovery +: Signals. + +Appendix B. Peer-Level Message Flows + +B.1. Session Initialization + +Router Modem Message Description +======================================================================== + +| Router connects to discovered or +| preconfigured Modem Connection +|--TCP connection established---> Point. +| +| Router sends Session +|----Session Initialization----->| Initialization Message. + | + | Modem receives Session + | Initialization Message. + | + | Modem sends Session Initialization +|<--Session Initialization Resp.-| Response with 'Success' Status +| | Data Item. +| | +|<<============================>>| Session established. +: : Heartbeats begin. + + + +Ratliff, et al. Standards Track [Page 73] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + +B.2. Session Initialization - Refused + +Router Modem Message Description +======================================================================== + +| Router connects to discovered or +| preconfigured Modem Connection +|--TCP connection established---> Point. +| +| Router sends Session +|-----Session Initialization---->| Initialization Message. + | + | Modem receives Session + | Initialization Message and + | will not support the advertised + | extensions. + | + | Modem sends Session Initialization + | Response with 'Request Denied' +|<-Session Initialization Resp.--| Status Data Item. +| +| +| Router receives negative Session +| Initialization Response, closes +||---------TCP close------------|| TCP connection. + +B.3. Router Changes IP Addresses + +Router Modem Message Description +======================================================================== + +| Router sends Session Update +|-------Session Update---------->| Message to announce change of + | IP address. + | + | Modem receives Session Update + | Message and updates internal + | state. + | +|<----Session Update Response----| Modem sends Session Update + | Response. + + + + + + + + + + +Ratliff, et al. Standards Track [Page 74] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + +B.4. Modem Changes Session-Wide Metrics + +Router Modem Message Description +======================================================================== + + | Modem sends Session Update Message + | to announce change of session-wide +|<--------Session Update---------| metrics. +| +| Router receives Session Update +| Message and updates internal +| state. +| +|----Session Update Response---->| Router sends Session Update + | Response. + +B.5. Router Terminates Session + +Router Modem Message Description +======================================================================== + +| Router sends Session Termination +|------Session Termination------>| Message with Status Data Item. +| | +|-------TCP shutdown (send)---> | Router stops sending Messages. + | + | Modem receives Session + | Termination, stops counting + | received heartbeats, and stops + | sending heartbeats. + | + | Modem sends Session Termination +|<---Session Termination Resp.---| Response with Status 'Success'. +| +| Modem stops sending Messages. +| +||---------TCP close------------|| Session terminated. + + + + + + + + + + + + + + +Ratliff, et al. Standards Track [Page 75] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + +B.6. Modem Terminates Session + +Router Modem Message Description +======================================================================== + + | Modem sends Session Termination +|<----Session Termination--------| Message with Status Data Item. +| +| Modem stops sending Messages. +| +| Router receives Session +| Termination, stops counting +| received heartbeats, and stops +| sending heartbeats. +| +| Router sends Session Termination +|---Session Termination Resp.--->| Response with Status 'Success'. + | + | Router stops sending Messages. + | +||---------TCP close------------|| Session terminated. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ratliff, et al. Standards Track [Page 76] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + +B.7. Session Heartbeats + +Router Modem Message Description +======================================================================== + +|----------Heartbeat------------>| Router sends Heartbeat Message. + | + | Modem resets heartbeats missed + | counter. + + ~ ~ ~ ~ ~ ~ ~ + +|---------[Any Message]--------->| When the Modem receives any + | Message from the Router. + | + | Modem resets heartbeats missed + | counter. + + ~ ~ ~ ~ ~ ~ ~ + +|<---------Heartbeat-------------| Modem sends Heartbeat Message. +| +| Router resets heartbeats missed +| counter. + + ~ ~ ~ ~ ~ ~ ~ + +|<--------[Any Message]----------| When the Router receives any +| Message from the Modem. +| +| Modem resets heartbeats missed +| counter. + + + + + + + + + + + + + + + + + + + +Ratliff, et al. Standards Track [Page 77] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + +B.8. Router Detects a Heartbeat Timeout + +Router Modem Message Description +======================================================================== + + X<----------------------| Router misses a heartbeat. + + +| X<----------------------| Router misses too many +| heartbeats. +| +| +|------Session Termination------>| Router sends Session Termination +| Message with 'Timeout' Status +| Data Item. +: +: Termination proceeds... + +B.9. Modem Detects a Heartbeat Timeout + +Router Modem Message Description +======================================================================== + +|---------------------->X Modem misses a heartbeat. + + +|---------------------->X | Modem misses too many + | heartbeats. + | + | +|<-----Session Termination-------| Modem sends Session Termination + | Message with 'Timeout' Status + | Data Item. + : + : Termination proceeds... + + + + + + + + + + + + + + + + +Ratliff, et al. Standards Track [Page 78] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + +Appendix C. Destination-Specific Message Flows + +C.1. Common Destination Notification + +Router Modem Message Description +======================================================================== + + | Modem detects a new logical + | destination is reachable and +|<-------Destination Up----------| sends Destination Up Message. +| +|------Destination Up Resp.----->| Router sends Destination Up + | Response. + + ~ ~ ~ ~ ~ ~ ~ + | Modem detects change in logical + | destination metrics and sends +|<-------Destination Update------| Destination Update Message. + + ~ ~ ~ ~ ~ ~ ~ + | Modem detects change in logical + | destination metrics and sends +|<-------Destination Update------| Destination Update Message. + + ~ ~ ~ ~ ~ ~ ~ + | Modem detects logical destination + | is no longer reachable and sends +|<-------Destination Down--------| Destination Down Message. +| +| Router receives Destination Down, +| updates internal state, and sends +|------Destination Down Resp.--->| Destination Down Response Message. + + + + + + + + + + + + + + + + + + + +Ratliff, et al. Standards Track [Page 79] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + +C.2. Multicast Destination Notification + +Router Modem Message Description +======================================================================== + +| Router detects a new multicast +| destination is in use and sends +|-----Destination Announce------>| Destination Announce Message. + | + | Modem updates internal state to + | monitor multicast destination and +|<-----Dest. Announce Resp.------| sends Destination Announce + Response. + + ~ ~ ~ ~ ~ ~ ~ + | Modem detects change in multicast + | destination metrics and sends +|<-------Destination Update------| Destination Update Message. + + ~ ~ ~ ~ ~ ~ ~ + | Modem detects change in multicast + | destination metrics and sends +|<-------Destination Update------| Destination Update Message. + + ~ ~ ~ ~ ~ ~ ~ +| Router detects multicast +| destination is no longer in use +|--------Destination Down------->| and sends Destination Down + | Message. + | + | Modem receives Destination Down, + | updates internal state, and sends +|<-----Destination Down Resp.----| Destination Down Response Message. + + + + + + + + + + + + + + + + + + +Ratliff, et al. Standards Track [Page 80] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + +C.3. Link Characteristics Request + +Router Modem Message Description +======================================================================== + + Destination has already been + ~ ~ ~ ~ ~ ~ ~ announced by either peer. + +| Router requires different +| characteristics for the +| destination and sends Link +|--Link Characteristics Request->| Characteristics Request Message. + | + | Modem attempts to adjust link + | properties to meet the received + | request and sends a Link + | Characteristics Response +|<---Link Characteristics Resp.--| Message with the new values. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ratliff, et al. Standards Track [Page 81] + +RFC 8175 Dynamic Link Exchange Protocol (DLEP) June 2017 + + +Acknowledgments + + We would like to acknowledge and thank the members of the DLEP design + team, who have provided invaluable insight. The members of the + design team are Teco Boot, Bow-Nan Cheng, John Dowdell, and Henning + Rogge. + + We would also like to acknowledge the influence and contributions of + Greg Harrison, Chris Olsen, Martin Duke, Subir Das, Jaewon Kang, + Vikram Kaul, Nelson Powell, Lou Berger, and Victoria Pritchard. + +Authors' Addresses + + Stan Ratliff + VT iDirect + 13861 Sunrise Valley Drive, Suite 300 + Herndon, VA 20171 + United States of America + Email: sratliff@idirect.net + + Shawn Jury + Cisco Systems + 170 West Tasman Drive + San Jose, CA 95134 + United States of America + Email: sjury@cisco.com + + Darryl Satterwhite + Broadcom + Email: dsatterw@broadcom.com + + Rick Taylor + Airbus Defence & Space + Quadrant House + Celtic Springs + Coedkernew + Newport NP10 8FZ + United Kingdom + Email: rick.taylor@airbus.com + + Bo Berry + + + + + + + + + + +Ratliff, et al. Standards Track [Page 82] + |