Internet-Draft DLEP Channel Utilization August 2021
Rogge Expires 11 February 2022 [Page]
Workgroup:
Manet
Internet-Draft:
draft-rogge-manet-dlep-channel-utilization-01
Published:
Intended Status:
Standards Track
Expires:
Author:
H.R. Rogge
Fraunhofer FKIE

DLEP Radio Channel Utilization Extension

Abstract

This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) to provide the utilization of a radio channel.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 11 February 2022.

1. Introduction

The Dynamic Link Exchange Protocol (DLEP) is defined in [RFC8175]. It provides the exchange of link-related control information between DLEP peers. DLEP peers are comprised of a modem and a router. DLEP defines a base set of mechanisms as well as support for possible extensions. This document defines one such extension. Radio channel utilization provides a packet/frame independent measurement how a radio channel is used and how much resources are still available. This allows a router to calculate a better routing metric or allows management agents to detect a channel being unusable for communication because of external jamming.

1.1. Requirements Language

In many IETF documents, several words, when they are in all capitals as shown below, are used to signify the requirements in the specification. These capitalized words can bring significant clarity and consistency to documents because their meanings are well defined. This document defines how those words are interpreted in IETF documents when the words are in all capitals.

  • These words can be used as defined here, but using them is not required. Specifically, normative text does not require the use of these key words. They are used for clarity and consistency when that is what's wanted, but a lot of normative text does not use them and is still normative.
  • The words have the meanings specified herein only when they are in all capitals.
  • When these words are not capitalized, they have their normal English meanings and are not affected by this document.

Authors who follow these guidelines should incorporate this phrase near the beginning of their document: 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.

2. Extension Usage and Identification

The use of the Channel Utilization Extension SHOULD be configurable. To indicate that the Channel Utilization Extension is to be used, an implementation MUST include the Radio Channel Utilization Extension ID in the Extensions Supported Data Item. The Extensions Supported Data Item is sent and processed according to [RFC8175].

All four Data Items are time measurements in nanoseconds since an arbitrary starting point, e.g. the radio bootup. They are never reseted and will just increase monotonic.

The first Data Item (Radio Channel Active) announces the channels livetime of the radio channel while the other three provide the amount of time the channel has been used in different ways. Radio Channel Rx provides the time the radio is receiving data, Radio Channel Tx the time the radio is sending data and Radio Channel Busy the time the radio channel is blocked for any unknown reason.

A radio that doesn't track the time for receiving and transmitting data explicitly can just add all times the radio channel is not free into the Radio Channel Busy Data Item.

The time the radio channel has been free can be calculated by substracting the values of Busy, Rx and Tx from the value provided by the Radio Active Channel Data Item.

3. Data Items

All four Data Items of this extension can be used both as Session specific and Destination specific metrics. If the radio is only tracking channel usage on interface level, the Data Items are used in SessionInitResponse and SessionUpdate messages. If the radio also is tracking channel usage for each Destination, they are also used in DestinationUp, DestinationUpdate and DestinationAnnounceResponse messages.

3.1. Radio Channel Active Data Item

Radio Channel Active Item contains information how long the radio channel has been active. This provides the router with a reference to interpret the values provided by the other three Data Items. Because of this the value in this item must be larger than the values in the other three Data Items this extensions defines together.

This Data Item is mandatory for SessionInitResponse and SessionUpdate messages.

The format of the Radio Channel Active Data Item is:

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                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Active Time                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Active Time                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
Data Item Type:
TBD
Length:
8
Active Time:
Time in nanoseconds since the channel has been active.

3.2. Radio Channel Busy Data Item

Radio Channel Busy Item contains information how much time the radio channel has been busy, not including the time provided in the Channel Rx and Chanel Tx Data Item.

This Data Item is mandatory for SessionInitResponse and SessionUpdate messages.

The format of the Radio Channel Busy Data Item is:

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                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Busy Time                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Busy Time                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
Data Item Type:
TBD
Length:
8
Busy Time:
Time in nanoseconds the channel was busy during its active time.

3.3. Radio Channel Rx Data Item

Radio Channel Rx Item contains information how much time the local radio has been receiving data from other radios.

The format of the Radio Channel Rx Data Item is:

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                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Rx Time                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Rx Time                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3
Data Item Type:
TBD
Length:
8
Rx Time:
Time in nanoseconds the local radio was receiving data from other radios during its active time.

3.4. Radio Channel Tx Data Item

Radio Channel Tx Item contains information how much time the local radio has been transmitting data to other radios.

The format of the Radio Channel Tx Data Item is:

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                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Tx Time                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Tx Time                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4
Data Item Type:
TBD
Length:
8
Tx Time:
Time in nanoseconds the local radio was transmitting data to other radios during its active time.

4. Security Considerations

The extension introduces a new Data Item for DLEP. The extension does not inherently introduce any additional vulnerabilities above those documented in [RFC8175]. The approach taken to security in that document applies equally when running the extension defined in this document.

5. IANA Considerations

As described below, IANA has assigned two values per this document. Both assignments are to registries defined by [RFC8175].

5.1. Extension Type Value

IANA has assigned the following value in the "Extension Type Values" registry within the "Dynamic Link Exchange Protocol (DLEP) Parameters" registry. The new value is in the range with the "Specification Required" [RFC8126] policy:

Table 1: New Extension Type Value
Code Description
TBD Radio Channel Utilization

5.2. Data Item Value

IANA has assigned the following value in the "Data Item Type Values" registry within the "Dynamic Link Exchange Protocol (DLEP) Parameters" registry. The new value is in the range with the "Specification Required" [RFC8126] policy:

Table 2: New Data Item Value
Type Code Description
TBD Radio Channel Active
TBD Radio Channel Busy
TBD Radio Channel Rx
TBD Radio Channel Tx

6. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8175]
Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, DOI 10.17487/RFC8175, , <https://www.rfc-editor.org/info/rfc8175>.

7. Informative References

[RFC8126]
Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <https://www.rfc-editor.org/info/rfc8126>.

Author's Address

Henning Rogge
Fraunhofer FKIE
Fraunhofer Strasse 20
53343 Wachtberg
Germany