| DetNet | D. Huang |
| Internet-Draft | ZTE |
| Intended status: Standards Track | June 12, 2018 |
| Expires: December 14, 2018 |
Single-path PREF
draft-huang-detnet-single-path-pref-01
This document specifies PREF on the single path for low-rate traffic, and illustrates in details the implementation solutions as well as the impacts on the data plane specified in [I-D.ietf-detnet-dp-alt].
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 December 14, 2018.
Copyright (c) 2018 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.
PREF is designed to protect the Detnet traffic against path or node failures in [I-D.ietf-detnet-architecture] by directing multiple copies of the traffic into multiple paths. Lost packets would be recovered at the converging node (or terminating node) from the undamaged traffic in other path. Nevertheless, path and node failure always result in disastrous consequences for the ongoing service, large blocks of data loss or even total service breakdown, while PREF with multiple paths protection would also provide good cross-check for the minor packet loss which guarantees the data integrity as well as latency benefits (retransmission reduced significantly). When it comes to the latter scenario, PREF on the single path will do the better job particularly for the low-rate traffic.
Packet replication is executed in edge node, what's significantly different from the multi-path PREF is the copies would be arranged in the same traffic flow rather than delivering along different paths, either transport or forwarding nodes do not have to execute PREF which should only be done at the terminating node. The rationale is that if packet loss occurs at any intermediary nodes, the multiple packet copies could execute cross-checking and rebuild the damaged data flow, and make the usual retransmission unnecessary to a large degree. Two major benefits follow, intermediary network nodes do not need support PREF, and if the node is a PREF node, it does not execute PREF. Secondly, no or reduced buffer reservation should be required in the nodes along the routing path.
Multiple copies in the same data traffic put bandwidth pressure upon the network without appropriate constraints. Low-rate traffic services such as blockchain, IoT etc. from the use cases in [I-D.ietf-detnet-use-cases] are proper for PREF on the single path to provide service protection as well as latency reduction.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
The lowercase forms with an initial capital "Must", "Must Not","Shall", "Shall Not", "Should", "Should Not", "May", and "Optional"in this document are to be interpreted in the sense defined in [RFC2119], but are used where the normative behavior is defined in documents published by SDOs other than the IETF.
This document uses the terms defined in [I-D.ietf-detnet-architecture] and [I-D.ietf-detnet-dp-alt].
From detnet processing point of view, PREF in the single path for low-rate traffic is not intrinsically different from PREF in multiple paths as it is defined in [I-D.ietf-detnet-dp-alt]. Both flow ID and control word are needed to identify the specific detnet flow as well as packets. Therefore this document will try to reuse the encapsulation mechanism in [I-D.ietf-detnet-dp-alt] with minor optional modification to make PREF in the single path run as designed.
Under the mechanism of PREF in multiple paths, flow label also works as an indicator to the DA-*-PE that PREF be executed other than identifying the specific detnet flow. Nonetheless, PREF in the single path involves simply the initiating and terminating side of the detnet service, while the intermediary nodes execute neither replication nor elimination. One bit indicator in the flow ID to announce whether or not the ongoing detnet traffic has multiple copies in the same stream is necessary. As Figure 1 shows, the bit 'R' represents the indicator for which the default value should be '0' indicating no more than 1 copy of the packets in the current stream, while '1' setting indicates that the current stream has more than one copies of the packets.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Reserved |R|D| 24 bit Flow ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 1: DetNet Flow ID word
The latest data plane working group draft removes the original flow ID definition, and instead leverages service label in MPLS PW and flow label in IPv6 respectively. Maybe further extensions as designed above in detnet label definitions in PW and IPv6 are necessary. Detailed solutions would be provided upon expert feedback.
Definitions of control word in both MPLS PW and IPv6 will be reused for PREF in the single path, and revisions should be made according to the latest development of the [I-D.ietf-detnet-dp-alt].
However, control word would be another opportunity to make the PREF-in-the-single-path indication as an alternative solution against the Flow label solution. The intrinsic mechanism would be pretty much the same as in Flow label. One reserved bit is used to announce whether or not the ongoing detnet traffic has multiple copies in the same stream. '0' should be the default value indicating 'no PREF in the single path', while '1' indicates yes as is shown in the Figure 2 and Figure 3.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|0 0 0 0 Reserved |R| 16 bit sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 2: DetNet PW control word
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| 16 bit sequence number | Reserved |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 3: DetNet IPv6 Destination Option
Low-rate traffic consists of both continuous (constant rate or invariable rate) and discontinuous traffic, so roughly there are two solutions to make the replication of the traffic.
The burst data should be taken as one unit upon which the replication is executed. The whole burst data block would be replicated in the pre-routed traffic.
Whether or not the traffic is constant, continuous traffic first has to be truncated evenly into units upon which the replication is executed. The truncation criteria could both be unit size (100Kbytes etc) and unit time (1 second etc.).
PREF in the single path proposed in this document is a sub-part of the PREF in the multiple paths defined in [I-D.ietf-detnet-dp-alt]. Upon receiving the DetNet flow packet, 'R' bit which is set to be '1' should initiate PREF-in-the-single-path processing in the relay or edge nodes.
The output of the single-path PREF elimination function is always a single packet, and the output of the single-path replication is always one or more packets. The replicated packets MUST share the same DetNet control word sequence number.
Also as specified in the multiple-paths PREF data plane document, edge node extended forwarder is responsible to push DetNet header (flow label and control word etc.) into the packets (if not already present) before forwarding to other nodes.
The terminating edge node should execute the singple-path PREF elimination which receives a specific packet while ignoring the other copies with the same control word sequence numbers.
Upon receiving the DetNet flow packets, relay node check if it's single-path PREF replications, namely whether or not 'R' is set to be '1'. if it is single-path PREF replications, the relay node simply forwards the packet as usual and executes no more processing. If the boolean multiple-path PREF switch is on, the corresponding PREF processing is executed normally.
The single-path PREF is designed to address the low-rate traffic. The traffic rate limit should be subject to the service providers. The rate limit could be configured in both application level and network management level.