From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8757.txt | 240 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 240 insertions(+) create mode 100644 doc/rfc/rfc8757.txt (limited to 'doc/rfc/rfc8757.txt') diff --git a/doc/rfc/rfc8757.txt b/doc/rfc/rfc8757.txt new file mode 100644 index 0000000..2c1316f --- /dev/null +++ b/doc/rfc/rfc8757.txt @@ -0,0 +1,240 @@ + + + + +Internet Engineering Task Force (IETF) B. Cheng +Request for Comments: 8757 MIT Lincoln Laboratory +Category: Standards Track L. Berger, Ed. +ISSN: 2070-1721 LabN Consulting, L.L.C. + March 2020 + + + Dynamic Link Exchange Protocol (DLEP) Latency Range Extension + +Abstract + + This document defines an extension to the Dynamic Link Exchange + Protocol (DLEP) to provide the range of latency that can be + experienced on a link. + +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 + https://www.rfc-editor.org/info/rfc8757. + +Copyright Notice + + Copyright (c) 2020 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 + (https://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 + 1.1. Key Words + 2. Extension Usage and Identification + 3. Latency Range Data Item + 4. Security Considerations + 5. IANA Considerations + 5.1. Extension Type Value + 5.2. Data Item Value + 6. References + 6.1. Normative References + 6.2. Informative References + Acknowledgments + Authors' Addresses + +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. + + The base DLEP specification includes the Latency Data Item, which + provides a single, implementation-dependent latency value on a link. + This document adds the ability to relay the minimum and maximum + latency range seen on a link. The extension defined in this document + is referred to as "Latency Range". + + This document defines a new DLEP Extension Type Value that is used to + indicate the use of the extension; see Section 2. A new DLEP Data + Item is defined in Section 3. + +1.1. Key Words + + 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 Latency Range Extension SHOULD be configurable. To + indicate that the Latency Range Extension is to be used, an + implementation MUST include the Latency Range Extension Type Value in + the Extensions Supported Data Item. The Extensions Supported Data + Item is sent and processed according to [RFC8175]. + + Note: The usage of the extension defined in this document does not + impact processing associated with the Latency Data Item defined in + [RFC8175]. + + The Latency Range Extension Type Value is 4; see Section 5. + +3. Latency Range Data Item + + The Latency Range Data Item serves much the same purpose as the + Latency Data Item defined in [RFC8175] with the addition of being + able to communicate the latency range that can be experienced by + traffic on a link. The Latency Range Data Item MUST be included in + the Session Initialization Response Message, with default values to + be used on a session-wide basis. The Latency Range Data Item also + MAY be carried in any message where the Latency Data Item [RFC8175] + is allowed and is carried as an additional data item. When present, + the Latency Range Data Item MUST be processed according to the same + rules as the Latency Data Item defined in [RFC8175]. + + The format of the Latency Range 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Maximum Latency : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : Maximum Latency | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Minimum Latency : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + : Minimum Latency | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Data Item Type: + 28 + + Length: + 16 + + Maximum Latency: + A 64-bit unsigned integer, representing the longest transmission + delay, in microseconds, that a packet encounters as it is + transmitted over the link. + + Minimum Latency: + A 64-bit unsigned integer, representing the shortest transmission + delay, in microseconds, that a packet can encounter as it is + transmitted over the link. + +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: + + +------+---------------+ + | Code | Description | + +======+===============+ + | 4 | Latency Range | + +------+---------------+ + + Table 1: New Extension + Type Value + +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: + + +-----------+---------------+ + | Type Code | Description | + +===========+===============+ + | 28 | Latency Range | + +-----------+---------------+ + + Table 2: New Data Item Value + +6. References + +6.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, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. + Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, + DOI 10.17487/RFC8175, June 2017, + . + +6.2. 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, June 2017, + . + +Acknowledgments + + Helpful comments were received from members of the MANET working + group, including Ronald in 't Velt, Henning Rogge, and Victoria + Pritchard. + +Authors' Addresses + + Bow-Nan Cheng + MIT Lincoln Laboratory + Massachusetts Institute of Technology + 244 Wood Street + Lexington, MA 02421-6426 + United States of America + + Email: bcheng@ll.mit.edu + + + Lou Berger (editor) + LabN Consulting, L.L.C. + + Email: lberger@labn.net -- cgit v1.2.3