idnits 2.17.1 draft-rogge-manet-dlep-channel-utilization-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (7 March 2022) is 774 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Manet H.R. Rogge 3 Internet-Draft Fraunhofer FKIE 4 Intended status: Standards Track 7 March 2022 5 Expires: 8 September 2022 7 DLEP Radio Channel Utilization Extension 8 draft-rogge-manet-dlep-channel-utilization-02 10 Abstract 12 This document defines an extension to the Dynamic Link Exchange 13 Protocol (DLEP) to provide the utilization of a radio channel. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on 8 September 2022. 32 Copyright Notice 34 Copyright (c) 2022 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 39 license-info) in effect on the date of publication of this document. 40 Please review these documents carefully, as they describe your rights 41 and restrictions with respect to this document. Code Components 42 extracted from this document must include Revised BSD License text as 43 described in Section 4.e of the Trust Legal Provisions and are 44 provided without warranty as described in the Revised BSD License. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 50 2. Extension Usage and Identification . . . . . . . . . . . . . 3 51 3. Data Items . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3.1. Radio Channel Active Data Item . . . . . . . . . . . . . 4 53 3.2. Radio Channel Busy Data Item . . . . . . . . . . . . . . 4 54 3.3. Radio Channel Rx Data Item . . . . . . . . . . . . . . . 5 55 3.4. Radio Channel Tx Data Item . . . . . . . . . . . . . . . 6 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 58 5.1. Extension Type Value . . . . . . . . . . . . . . . . . . 6 59 5.2. Data Item Value . . . . . . . . . . . . . . . . . . . . . 7 60 6. Normative References . . . . . . . . . . . . . . . . . . . . 7 61 7. Informative References . . . . . . . . . . . . . . . . . . . 7 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 64 1. Introduction 66 The Dynamic Link Exchange Protocol (DLEP) is defined in [RFC8175]. 67 It provides the exchange of link-related control information between 68 DLEP peers. DLEP peers are comprised of a modem and a router. DLEP 69 defines a base set of mechanisms as well as support for possible 70 extensions. This document defines one such extension. Radio channel 71 utilization provides a packet/frame independent measurement how a 72 radio channel is used and how much resources are still available. 73 While incoming and outgoing traffic can be easily measured on the 74 router, the amount of airtime used by management traffic of the radio 75 is invisible to the router, as is unicast traffic between two 76 adjecant radios (unless the radio supports promiscous mode). This 77 could present the a fully utilized radio channel to the router as 78 totally empty. Getting a direct radio level information how much 79 time on the radio channel has been used up by incoming or outgoing 80 data or control frames allows a router to calculate a better routing 81 metric or allows management agents to detect a channel being unusable 82 for communication because of external jamming. 84 1.1. Requirements Language 86 In many IETF documents, several words, when they are in all capitals 87 as shown below, are used to signify the requirements in the 88 specification. These capitalized words can bring significant clarity 89 and consistency to documents because their meanings are well defined. 90 This document defines how those words are interpreted in IETF 91 documents when the words are in all capitals. 93 * These words can be used as defined here, but using them is not 94 required. Specifically, normative text does not require the use 95 of these key words. They are used for clarity and consistency 96 when that is what's wanted, but a lot of normative text does not 97 use them and is still normative. 99 * The words have the meanings specified herein only when they are in 100 all capitals. 102 * When these words are not capitalized, they have their normal 103 English meanings and are not affected by this document. 105 Authors who follow these guidelines should incorporate this phrase 106 near the beginning of their document: The key words "MUST", "MUST 107 NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 108 "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in BCP 14 [RFC2119] 110 [RFC8174] when, and only when, they appear in all capitals, as shown 111 here. 113 2. Extension Usage and Identification 115 The use of the Channel Utilization Extension SHOULD be configurable. 116 To indicate that the Channel Utilization Extension is to be used, an 117 implementation MUST include the Radio Channel Utilization Extension 118 ID in the Extensions Supported Data Item. The Extensions Supported 119 Data Item is sent and processed according to [RFC8175]. 121 All four Data Items are time measurements in nanoseconds since an 122 arbitrary starting point, e.g. the radio bootup. They are never 123 reseted and will just increase monotonic. 125 The first Data Item (Radio Channel Active) announces the channels 126 livetime of the radio channel while the other three provide the 127 amount of time the channel has been used in different ways. Radio 128 Channel Rx provides the time the radio is receiving data, Radio 129 Channel Tx the time the radio is sending data and Radio Channel Busy 130 the time the radio channel is blocked for any unknown reason. 132 A radio that doesn't track the time for receiving and transmitting 133 data explicitly can just add all times the radio channel is not free 134 into the Radio Channel Busy Data Item. 136 The time the radio channel has been free can be calculated by 137 substracting the values of Busy, Rx and Tx from the value provided by 138 the Radio Active Channel Data Item. By tracking these values over 139 time The router can calculate statistics on the channel usage for 140 routing metrics or report the received value to a management layer. 142 3. Data Items 144 All four Data Items of this extension can be used both as Session 145 specific and Destination specific metrics. If the radio is only 146 tracking channel usage on interface level, the Data Items are used in 147 SessionInitResponse and SessionUpdate messages. If the radio also is 148 tracking channel usage for each Destination, they are also used in 149 DestinationUp, DestinationUpdate and DestinationAnnounceResponse 150 messages. 152 3.1. Radio Channel Active Data Item 154 Radio Channel Active Item contains information how long the radio 155 channel has been active. This provides the router with a reference 156 to interpret the values provided by the other three Data Items. 157 Because of this the value in this item must be larger than the values 158 in the other three Data Items this extensions defines together. 160 This Data Item is mandatory for SessionInitResponse messages. 162 The format of the Radio Channel Active Data Item is: 164 0 1 2 3 165 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 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Data Item Type | Length | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Active Time | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Active Time | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 Figure 1 176 Data Item Type: TBD 178 Length: 8 180 Active Time: Time in nanoseconds since the channel has been active. 182 3.2. Radio Channel Busy Data Item 184 Radio Channel Busy Item contains information how much time the radio 185 channel has been busy, not including the time provided in the Channel 186 Rx and Chanel Tx Data Item. 188 The format of the Radio Channel Busy Data Item is: 190 0 1 2 3 191 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 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Data Item Type | Length | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Busy Time | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Busy Time | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 Figure 2 202 Data Item Type: TBD 204 Length: 8 206 Busy Time: Time in nanoseconds the channel was busy during its 207 active time. 209 3.3. Radio Channel Rx Data Item 211 Radio Channel Rx Item contains information how much time the local 212 radio has been receiving data from other radios. 214 The format of the Radio Channel Rx Data Item is: 216 0 1 2 3 217 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 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Data Item Type | Length | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Rx Time | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Rx Time | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 Figure 3 228 Data Item Type: TBD 230 Length: 8 232 Rx Time: Time in nanoseconds the local radio was receiving data from 233 other radios during its active time. 235 3.4. Radio Channel Tx Data Item 237 Radio Channel Tx Item contains information how much time the local 238 radio has been transmitting data to other radios. 240 The format of the Radio Channel Tx Data Item is: 242 0 1 2 3 243 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 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Data Item Type | Length | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Tx Time | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Tx Time | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 Figure 4 254 Data Item Type: TBD 256 Length: 8 258 Tx Time: Time in nanoseconds the local radio was transmitting data 259 to other radios during its active time. 261 4. Security Considerations 263 The extension introduces a new Data Item for DLEP. The extension 264 does not inherently introduce any additional vulnerabilities above 265 those documented in [RFC8175]. The approach taken to security in 266 that document applies equally when running the extension defined in 267 this document. 269 5. IANA Considerations 271 As described below, IANA has assigned two values per this document. 272 Both assignments are to registries defined by [RFC8175]. 274 5.1. Extension Type Value 276 IANA has assigned the following value in the "Extension Type Values" 277 registry within the "Dynamic Link Exchange Protocol (DLEP) 278 Parameters" registry. The new value is in the range with the 279 "Specification Required" [RFC8126] policy: 281 +------+---------------------------+ 282 | Code | Description | 283 +------+---------------------------+ 284 | TBD | Radio Channel Utilization | 285 +------+---------------------------+ 287 Table 1: New Extension Type Value 289 5.2. Data Item Value 291 IANA has assigned the following value in the "Data Item Type Values" 292 registry within the "Dynamic Link Exchange Protocol (DLEP) 293 Parameters" registry. The new value is in the range with the 294 "Specification Required" [RFC8126] policy: 296 +-----------+----------------------+ 297 | Type Code | Description | 298 +-----------+----------------------+ 299 | TBD | Radio Channel Active | 300 +-----------+----------------------+ 301 | TBD | Radio Channel Busy | 302 +-----------+----------------------+ 303 | TBD | Radio Channel Rx | 304 +-----------+----------------------+ 305 | TBD | Radio Channel Tx | 306 +-----------+----------------------+ 308 Table 2: New Data Item Value 310 6. Normative References 312 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 313 Requirement Levels", BCP 14, RFC 2119, 314 DOI 10.17487/RFC2119, March 1997, 315 . 317 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 318 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 319 May 2017, . 321 [RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. 322 Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, 323 DOI 10.17487/RFC8175, June 2017, 324 . 326 7. Informative References 328 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 329 Writing an IANA Considerations Section in RFCs", BCP 26, 330 RFC 8126, DOI 10.17487/RFC8126, June 2017, 331 . 333 Author's Address 335 Henning Rogge 336 Fraunhofer FKIE 337 Fraunhofer Strasse 20 338 53343 Wachtberg 339 Germany 340 Email: henning.rogge@fkie.fraunhofer.de