idnits 2.17.1 draft-rogge-manet-dlep-channel-utilization-01.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 (10 August 2021) is 990 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 10 August 2021 5 Expires: 11 February 2022 7 DLEP Radio Channel Utilization Extension 8 draft-rogge-manet-dlep-channel-utilization-01 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 11 February 2022. 32 Copyright Notice 34 Copyright (c) 2021 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 Simplified BSD License text 43 as described in Section 4.e of the Trust Legal Provisions and are 44 provided without warranty as described in the Simplified 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 This allows a router to calculate a better routing metric or allows 74 management agents to detect a channel being unusable for 75 communication because of external jamming. 77 1.1. Requirements Language 79 In many IETF documents, several words, when they are in all capitals 80 as shown below, are used to signify the requirements in the 81 specification. These capitalized words can bring significant clarity 82 and consistency to documents because their meanings are well defined. 83 This document defines how those words are interpreted in IETF 84 documents when the words are in all capitals. 86 * These words can be used as defined here, but using them is not 87 required. Specifically, normative text does not require the use 88 of these key words. They are used for clarity and consistency 89 when that is what's wanted, but a lot of normative text does not 90 use them and is still normative. 92 * The words have the meanings specified herein only when they are in 93 all capitals. 95 * When these words are not capitalized, they have their normal 96 English meanings and are not affected by this document. 98 Authors who follow these guidelines should incorporate this phrase 99 near the beginning of their document: The key words "MUST", "MUST 100 NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 101 "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in BCP 14 [RFC2119] 103 [RFC8174] when, and only when, they appear in all capitals, as shown 104 here. 106 2. Extension Usage and Identification 108 The use of the Channel Utilization Extension SHOULD be configurable. 109 To indicate that the Channel Utilization Extension is to be used, an 110 implementation MUST include the Radio Channel Utilization Extension 111 ID in the Extensions Supported Data Item. The Extensions Supported 112 Data Item is sent and processed according to [RFC8175]. 114 All four Data Items are time measurements in nanoseconds since an 115 arbitrary starting point, e.g. the radio bootup. They are never 116 reseted and will just increase monotonic. 118 The first Data Item (Radio Channel Active) announces the channels 119 livetime of the radio channel while the other three provide the 120 amount of time the channel has been used in different ways. Radio 121 Channel Rx provides the time the radio is receiving data, Radio 122 Channel Tx the time the radio is sending data and Radio Channel Busy 123 the time the radio channel is blocked for any unknown reason. 125 A radio that doesn't track the time for receiving and transmitting 126 data explicitly can just add all times the radio channel is not free 127 into the Radio Channel Busy Data Item. 129 The time the radio channel has been free can be calculated by 130 substracting the values of Busy, Rx and Tx from the value provided by 131 the Radio Active Channel Data Item. 133 3. Data Items 135 All four Data Items of this extension can be used both as Session 136 specific and Destination specific metrics. If the radio is only 137 tracking channel usage on interface level, the Data Items are used in 138 SessionInitResponse and SessionUpdate messages. If the radio also is 139 tracking channel usage for each Destination, they are also used in 140 DestinationUp, DestinationUpdate and DestinationAnnounceResponse 141 messages. 143 3.1. Radio Channel Active Data Item 145 Radio Channel Active Item contains information how long the radio 146 channel has been active. This provides the router with a reference 147 to interpret the values provided by the other three Data Items. 148 Because of this the value in this item must be larger than the values 149 in the other three Data Items this extensions defines together. 151 This Data Item is mandatory for SessionInitResponse and SessionUpdate 152 messages. 154 The format of the Radio Channel Active Data Item is: 156 0 1 2 3 157 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 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Data Item Type | Length | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Active Time | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Active Time | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 Figure 1 168 Data Item Type: TBD 170 Length: 8 172 Active Time: Time in nanoseconds since the channel has been active. 174 3.2. Radio Channel Busy Data Item 176 Radio Channel Busy Item contains information how much time the radio 177 channel has been busy, not including the time provided in the Channel 178 Rx and Chanel Tx Data Item. 180 This Data Item is mandatory for SessionInitResponse and SessionUpdate 181 messages. 183 The format of the Radio Channel Busy Data Item is: 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Data Item Type | Length | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Busy Time | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Busy Time | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 Figure 2 197 Data Item Type: TBD 199 Length: 8 201 Busy Time: Time in nanoseconds the channel was busy during its 202 active time. 204 3.3. Radio Channel Rx Data Item 206 Radio Channel Rx Item contains information how much time the local 207 radio has been receiving data from other radios. 209 The format of the Radio Channel Rx Data Item is: 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Data Item Type | Length | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Rx Time | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Rx Time | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 Figure 3 223 Data Item Type: TBD 225 Length: 8 227 Rx Time: Time in nanoseconds the local radio was receiving data from 228 other radios during its active time. 230 3.4. Radio Channel Tx Data Item 232 Radio Channel Tx Item contains information how much time the local 233 radio has been transmitting data to other radios. 235 The format of the Radio Channel Tx Data Item is: 237 0 1 2 3 238 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 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Data Item Type | Length | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Tx Time | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Tx Time | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 Figure 4 249 Data Item Type: TBD 251 Length: 8 253 Tx Time: Time in nanoseconds the local radio was transmitting data 254 to other radios during its active time. 256 4. Security Considerations 258 The extension introduces a new Data Item for DLEP. The extension 259 does not inherently introduce any additional vulnerabilities above 260 those documented in [RFC8175]. The approach taken to security in 261 that document applies equally when running the extension defined in 262 this document. 264 5. IANA Considerations 266 As described below, IANA has assigned two values per this document. 267 Both assignments are to registries defined by [RFC8175]. 269 5.1. Extension Type Value 271 IANA has assigned the following value in the "Extension Type Values" 272 registry within the "Dynamic Link Exchange Protocol (DLEP) 273 Parameters" registry. The new value is in the range with the 274 "Specification Required" [RFC8126] policy: 276 +------+---------------------------+ 277 | Code | Description | 278 +------+---------------------------+ 279 | TBD | Radio Channel Utilization | 280 +------+---------------------------+ 282 Table 1: New Extension Type Value 284 5.2. Data Item Value 286 IANA has assigned the following value in the "Data Item Type Values" 287 registry within the "Dynamic Link Exchange Protocol (DLEP) 288 Parameters" registry. The new value is in the range with the 289 "Specification Required" [RFC8126] policy: 291 +-----------+----------------------+ 292 | Type Code | Description | 293 +-----------+----------------------+ 294 | TBD | Radio Channel Active | 295 +-----------+----------------------+ 296 | TBD | Radio Channel Busy | 297 +-----------+----------------------+ 298 | TBD | Radio Channel Rx | 299 +-----------+----------------------+ 300 | TBD | Radio Channel Tx | 301 +-----------+----------------------+ 303 Table 2: New Data Item Value 305 6. Normative References 307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 308 Requirement Levels", BCP 14, RFC 2119, 309 DOI 10.17487/RFC2119, March 1997, 310 . 312 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 313 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 314 May 2017, . 316 [RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. 317 Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, 318 DOI 10.17487/RFC8175, June 2017, 319 . 321 7. Informative References 323 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 324 Writing an IANA Considerations Section in RFCs", BCP 26, 325 RFC 8126, DOI 10.17487/RFC8126, June 2017, 326 . 328 Author's Address 330 Henning Rogge 331 Fraunhofer FKIE 332 Fraunhofer Strasse 20 333 53343 Wachtberg 334 Germany 336 Email: henning.rogge@fkie.fraunhofer.de