| Internet-Draft | IPv6 Carries Traffic Shaping Mechanism | October 2023 |
| Yu & Zhang | Expires 10 April 2024 | [Page] |
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.¶
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.¶
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 10 April 2024.¶
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.¶
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 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.¶
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.¶
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¶
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.¶
An applicable time-sensitive traffic shaping network communication model is given in Figure 1 and illustrates the network elements in it.¶
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.¶
Figure 2 gives the communication flow of the network system.¶
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 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¶
The F identifiers is a flag bit. The value of this field specifies:¶
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.¶
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.¶
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¶
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.¶
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.¶
HBH Processing draft should define the HBH processing.¶
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.¶
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.¶
Integrity of data is to prevent data from being tampered with during transmission and to ensure that the outgoing and incoming data are identical.¶
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.¶
This document has no IANA actions.¶
TODO acknowledge.¶