Network Working Group H. Yu Internet-Draft China Future Internet Engineering Center Intended status: Informational K. Zhang Expires: 10 April 2024University of Electronic Science and Technology of China 8 October 2023 Carrying Traffic Shaping Mechanism in IPv6 Extension Header draft-yu-traffic-shaping-00 Abstract Starting from the traffic shaping mechanism, one of the core technologies of network deterministic assurance, we summarize the characteristics of different traffic scheduling and shaping methods and propose a solution design for IPv6 to carry these traffic scheduling and shaping methods, taking into account deterministic and security factors. At the same time, the network scope of practical applications is becoming larger and larger, and the demand for deterministic network services will no longer be restricted to LANs, but will require deterministic forwarding beyond LAN boundaries, extending the deterministic assurance capability previously provided in LANs to WANs through network layer technologies. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://z- Endeavor.github.io/Internet-Draft/draft-ietf-traffic-shaping.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-traffic-shaping/. Source for this draft and an issue tracker can be found at https://github.com/z-Endeavor/Internet-Draft. 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/. Yu & Zhang Expires 10 April 2024 [Page 1] Internet-Draft IPv6 Carries Traffic Shaping Mechanism October 2023 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 10 April 2024. Copyright Notice Copyright (c) 2023 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. Abbreviations in This Document . . . . . . . . . . . . . . . 4 4. Network Communication System . . . . . . . . . . . . . . . . 4 4.1. General Model of Network Transmission . . . . . . . . . . 4 4.2. Network Node Description . . . . . . . . . . . . . . . . 5 4.3. Network Communication Process . . . . . . . . . . . . . . 5 5. Definition of Carrying Traffic Shaping Mechanism . . . . . . 5 6. Specification in Hop-by-Hop Options . . . . . . . . . . . . . 7 6.1. Format in Hop-by-Hop Option . . . . . . . . . . . . . . . 7 6.2. Hop-by-Hop processing definition . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7.1. Replay Protection . . . . . . . . . . . . . . . . . . . . 8 7.2. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 9 7.3. Confidentiality . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Yu & Zhang Expires 10 April 2024 [Page 2] Internet-Draft IPv6 Carries Traffic Shaping Mechanism October 2023 1. Introduction Time Sensitive Network (TSN) is a network that guarantees the quality of service for delay-sensitive flows, achieving low latency, low jitter and zero packet loss. Time-sensitive streams can be divided into periodic time-sensitive streams (PTS), such as cyclic control instructions in the plant, synchronization information, and non- periodic/sporadic time-sensitive streams (STS), such as event alarm information. For periodic time-sensitive flows, traffic synchronous scheduling shaping mechanisms are generally used, requiring precise nanosecond clock synchronization of network-wide devices. Current mechanisms studied include Time-Triggered Ethernet (TTE), Time-Aware Shaping (TAS), Cyclic Queuing and Forwarding (CQF) and Credit-Based Shaping (CBS). Scheduling and shaping mechanisms are two quality of service assurance mechanisms in the switch. Scheduling refers to queue scheduling, which is generally implemented at the outgoing port of the switch and consists of three parts: entering the queue, selecting the sending queue according to the scheduling algorithm, and exiting the transmission; shaping refers to traffic shaping, which prevents congestion within the switch or at the next hop by limiting the forwarding rate of the port. "IPv6 Hop-by-Hop Options Processing Procedures" [HbH-UPDT] further specifies the procedures for how IPv6 Hop-by-Hop options are processed to make their processing even more practical and increase their use in the Internet. In that context, it makes sense to consider Hop-by-Hop Options to transport the information that is relevant to carry traffic shaping mechanism. Since the asynchronous scheduling and shaping mechanism cannot guarantee that the worst delay of the packet meets a certain threshold, it can only guarantee that the average delay of the packet is comparable to the synchronous method, and the delay jitter is relatively large, and the delay-sensitive stream is prone to packet loss in the case of network congestion, the current asynchronous mechanism is not mature, and in order to better elucidate the nature of the delay-sensitive network, this document of using the synchronous mechanism to transmit periodic time-sensitive stream (PTS) is mainly discussed. For the traffic shaping mechanism, one of the core technologies of network deterministic assurance, we summarize the characteristics of different traffic scheduling and shaping methods and propose a solution design for IPv6 to carry these traffic scheduling and Yu & Zhang Expires 10 April 2024 [Page 3] Internet-Draft IPv6 Carries Traffic Shaping Mechanism October 2023 shaping methods, taking into account deterministic and security factors. At the same time, the network scope of practical applications is becoming larger and larger, and the demand for deterministic network services will no longer be restricted to LANs, but will require deterministic forwarding beyond LAN boundaries, extending the deterministic assurance capability previously provided in LANs to WANs through network layer technologies. This document gives a description of the design of the IPv6 carrying traffic shaping mechanism and specifies the technical requirements and security specifications of the IPv6 carrying traffic shaping mechanism. This document applies to deterministic data communication of IPv6 networks that have implemented traffic synchronous scheduling shaping mechanism. 2. Conventions and Definitions 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. Abbreviations in This Document TSN Time Sensitive Network PTS Periodic Time-sensitive Streams TTE Time-Triggered Ethernet TAS Time-Aware Shaping CQF Cyclic Queuing and Forwarding CBS Credit-Based Shaping 4. Network Communication System Based on the premise of deterministic requirements, this document only considers the design of synchronization schemes where the network uses synchronization mechanisms to transmit PTS, while requiring accurate nanosecond time synchronization of devices within the entire network communication scenario. 4.1. General Model of Network Transmission An applicable time-sensitive traffic shaping network communication model is given in Figure 1 and illustrates the network elements in it. Yu & Zhang Expires 10 April 2024 [Page 4] Internet-Draft IPv6 Carries Traffic Shaping Mechanism October 2023 4.2. Network Node Description It is expected to be deployed in a variety of IPv6 devices and situations. Therefore, It is important to specify IPv6 node requirements will allow traffic shaping mechanisms to work well and interoperate over IPv6 in a large number of situations and deployments. 4.3. Network Communication Process Figure 2 gives the communication flow of the network system. * Collect the corresponding network topology information, traffic period, traffic size, end-to-end delay jitter requirement information and corresponding security requirements from various deterministic services, complete the centralized user configuration, and send it down to the network controller through the network user interface (UNI). * The network controller receives the network deterministic and security requirements and calculates the route scheduling control information for the traffic according to the corresponding algorithm. If the calculation is successful, the gating list is automatically synthesized and sent down through the southbound interface, and then the packet start time is returned to the sender; if the calculation fails, the orchestrator is told that the sender flow is not available for scheduling. * Centralized collaborative scheduling of switches to achieve traffic scheduling shaping and complete deterministic transmission by planning routes or dividing time slots, etc. 5. Definition of Carrying Traffic Shaping Mechanism Carrying traffic shaping mechanism in IPv6 extension header is in the form of a field on the extended header that specifies the basic traffic scheduling shaping protocol interface options for resolving the semantics of the scheduling shaping mechanism in the packet, allowing the network determinism to be transmitted through the extended header as well as for the adaptation of the upper layer protocols and network functions for use. This field information can be examined and processed by each node of the packet transmission path. The requirements for the use of scheduling shaping include the scheduling shaping technical solution options and the control information necessary of specific solution. The definition format consists of four fields, including options, flag bits, fill bit Yu & Zhang Expires 10 April 2024 [Page 5] Internet-Draft IPv6 Carries Traffic Shaping Mechanism October 2023 length, and control information. The definition format is shown in Figure 1. The technical scheme here mainly specifies the synchronous scheduling and shaping mechanism option, and the asynchronous scheduling and shaping mechanism information is not transmitted through this design. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Options|F| FBL | | +-+-+-+-+-+-+-+-+ + | | ~ Control Information (variable length) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Definition of Carrying Traffic Shaping Mechanism where * Options: 4-bits. Indicating the synchronous traffic scheduling shaping technology scheme used. * F: 1-bit. Used as a flag bit to record whether the protocol content has reached its maximum length. * FBL: 3-bit. The number of bits used to record the padding at the end of the protocol is 0 to 7 bits to ensure that the total length of the definition content is an integer multiple of 8 bits. * Control Information: Variable length. Used to carry the network control information necessary for the use of a specific scheduling and shaping mechanism, in a format and content determined by the specific scheduling and shaping mechanism. The F identifiers is a flag bit. The value of this field specifies: * 0 - the length of the protocol content has not exceeded the maximum value and the information has been read completely. * 1 - the length of the protocol content exceeds the maximum value and needs to be read further. FBL indicates Fill Bit Length which is for compatibility with subsequent adaptations in the IPv6 extension header. The actual length of the control information is obtained by parsing the length of the padding bits to facilitate the reading and processing of the network control device. The padding method is to set all the padding bits at the end to 0. Yu & Zhang Expires 10 April 2024 [Page 6] Internet-Draft IPv6 Carries Traffic Shaping Mechanism October 2023 The Control Information contains standard control frame format of each specific scheduling shaping mechanism, which is used to ensure the integrity of the control information to complete the standard adaptation to various network devices. 6. Specification in Hop-by-Hop Options 6.1. Format in Hop-by-Hop Option The definition of carrying traffic shaping mechanism shall conform to the relevant specifications in [RFC8200] for extended headers. The content in Section 3 should be placed in a Hop-by-Hop option header in the extended header to carry information that will not be inserted or removed and that can be examined or processed by each node in the packet transmission path until the packet reaches the node identified in the destination address field of the IPv6 header(or in the case of multicast, each of a group of nodes). The definition populates one or more sub-options of the TLV encoding format into the option field of the hop-by-hop option header, where the TLV encoding format is shown in Figure 2. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | Option Type | Opt Data Len | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - Figure 2: TLV Encoding Format where * Option Type: 8-bit identifier of the type of option. * Opt Data Len: 8-bit unsigned integer. Length of the Option Data field of this option, in octets. * Option Data: Variable-length field. Option-Type-specific data. In the definition above, some specific instructions are required: The Option Type identifiers are internally encoded such that their highest-order 2 bits specify the action that must be taken if the processing IPv6 node does not recognize the Option Type. Actions are selected by the controller in the network, refer to [RFC8200] for specific action definitions. Yu & Zhang Expires 10 April 2024 [Page 7] Internet-Draft IPv6 Carries Traffic Shaping Mechanism October 2023 The third-highest-order bit of the Option Type specifies whether or not the Option Data of that option can change en route to the packet’s final destination. The option data is changed during packet forwarding with traffice shaping information so that this bit needs to be set to 1. The low-order 5 bits of the Option Type should not conflict with the Option Type field already defined by IPv6. Option Data is used to carry the definition content of Section 3. In addition, the length of the protocol defined in Section 3 exceeds the maximum length of an option, the F identifiers should be set to 1 and the protocol will continue to be stored in the next option. The protocol content in Section 3 is split into at most two options. 6.2. Hop-by-Hop processing definition HBH Processing draft should define the HBH processing. 7. Security Considerations Security issues with IPv6 Hop-by-Hop options are well known and have been documented in several places, including [RFC6398], [RFC6192], and [RFC9098]. Security Considerations in IPv6 are composed of a number of different pieces. These are mainly required to provide the three characteristics of replay protection, integrity and confidentiality. 7.1. Replay Protection Replay Protection requires ensuring the uniqueness of each IP packet to ensure that the information cannot be reused in the event that it is intercepted and copied. * It should be ensured that access cannot be regained using the same packets to prevent attackers from intercepting deciphered information and then impersonating illegal access. * A secret key based on algorithm independent exchange should be set at the host side by the customer and the service provider, and when each packet is transmitted, a checksum is generated based on the secret key and the packet, and the checksum is recalculated and compared at the data receiving side. * Authentication data should be included in the transmission to protect the fields that cannot be changed during IP packet transmission. Yu & Zhang Expires 10 April 2024 [Page 8] Internet-Draft IPv6 Carries Traffic Shaping Mechanism October 2023 * The cache data should be cleared and guaranteed to be unrecoverable. 7.2. Integrity Integrity of data is to prevent data from being tampered with during transmission and to ensure that the outgoing and incoming data are identical. * Two-way authentication mechanism for shared data information components should be provided. * Encrypted transmission channels should be used to prevent data from being eavesdropped during network transmission. * Should have the ability to test the integrity of the data and provide the corresponding recovery control measures. 7.3. Confidentiality Confidentiality is used to prevent attackers from accessing packet headers or content, ensuring that information cannot be read during transmission, even if IP packets are intercepted. * Encryption policy of terminal data should be established to ensure the confidentiality of sensitive data output and shared at the terminal. * A cryptographic checksum should be generated for each packet, and the receiver should calculate the checksum before opening the packet; if the packet is tampered with and the checksum does not match, the packet is discarded. 8. IANA Considerations This document has no IANA actions. 9. References 9.1. Normative References [HbH-UPDT] Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options Processing Procedures", Work in Progress, Internet-Draft, draft-hinden-6man-hbh-processing-01, 2 June 2021, . Yu & Zhang Expires 10 April 2024 [Page 9] Internet-Draft IPv6 Carries Traffic Shaping Mechanism October 2023 [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, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 9.2. Informative References [RFC5409] Martin, L. and M. Schertler, "Using the Boneh-Franklin and Boneh-Boyen Identity-Based Encryption Algorithms with the Cryptographic Message Syntax (CMS)", RFC 5409, DOI 10.17487/RFC5409, January 2009, . [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, March 2011, . [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 2011, . [RFC9098] Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston, G., and W. Liu, "Operational Implications of IPv6 Packets with Extension Headers", RFC 9098, DOI 10.17487/RFC9098, September 2021, . Acknowledgments TODO acknowledge. Authors' Addresses Haisheng Yu China Future Internet Engineering Center Email: hsyu@cfiec.net Kaicheng Zhang University of Electronic Science and Technology of China Yu & Zhang Expires 10 April 2024 [Page 10] Internet-Draft IPv6 Carries Traffic Shaping Mechanism October 2023 Email: 457642057@qq.com Yu & Zhang Expires 10 April 2024 [Page 11]