idnits 2.17.1 draft-huang-detnet-single-path-pref-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([I-D.ietf-detnet-dp-alt]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 12, 2018) is 2144 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC6003' is defined on line 269, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-03 ** Downref: Normative reference to an Informational draft: draft-ietf-detnet-dp-alt (ref. 'I-D.ietf-detnet-dp-alt') == Outdated reference: A later version (-20) exists of draft-ietf-detnet-use-cases-13 ** Downref: Normative reference to an Informational draft: draft-ietf-detnet-use-cases (ref. 'I-D.ietf-detnet-use-cases') Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DetNet D. Huang 3 Internet-Draft ZTE 4 Intended status: Standards Track June 12, 2018 5 Expires: December 14, 2018 7 Single-path PREF 8 draft-huang-detnet-single-path-pref-01 10 Abstract 12 This document specifies PREF on the single path for low-rate traffic, 13 and illustrates in details the implementation solutions as well as 14 the impacts on the data plane specified in [I-D.ietf-detnet-dp-alt]. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on December 14, 2018. 33 Copyright Notice 35 Copyright (c) 2018 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Convention used in this document . . . . . . . . . . . . . . 3 52 3. Terminology and definitions . . . . . . . . . . . . . . . . . 3 53 4. Encapsulation impacts . . . . . . . . . . . . . . . . . . . . 3 54 4.1. Flow ID/Label . . . . . . . . . . . . . . . . . . . . . . 3 55 4.2. Control word . . . . . . . . . . . . . . . . . . . . . . 4 56 5. Replication solutions . . . . . . . . . . . . . . . . . . . . 4 57 5.1. Discontinuous traffic . . . . . . . . . . . . . . . . . . 5 58 5.2. Continuous traffic . . . . . . . . . . . . . . . . . . . 5 59 6. Forwarder clarifications . . . . . . . . . . . . . . . . . . 5 60 6.1. Edge node clarifications . . . . . . . . . . . . . . . . 5 61 6.2. Relay node clarification . . . . . . . . . . . . . . . . 5 62 7. Traffic rate limit . . . . . . . . . . . . . . . . . . . . . 6 63 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 PREF is designed to protect the Detnet traffic against path or node 69 failures in [I-D.ietf-detnet-architecture] by directing multiple 70 copies of the traffic into multiple paths. Lost packets would be 71 recovered at the converging node (or terminating node) from the 72 undamaged traffic in other path. Nevertheless, path and node failure 73 always result in disastrous consequences for the ongoing service, 74 large blocks of data loss or even total service breakdown, while PREF 75 with multiple paths protection would also provide good cross-check 76 for the minor packet loss which guarantees the data integrity as well 77 as latency benefits (retransmission reduced significantly). When it 78 comes to the latter scenario, PREF on the single path will do the 79 better job particularly for the low-rate traffic. 81 Packet replication is executed in edge node, what's significantly 82 different from the multi-path PREF is the copies would be arranged in 83 the same traffic flow rather than delivering along different paths, 84 either transport or forwarding nodes do not have to execute PREF 85 which should only be done at the terminating node. The rationale is 86 that if packet loss occurs at any intermediary nodes, the multiple 87 packet copies could execute cross-checking and rebuild the damaged 88 data flow, and make the usual retransmission unnecessary to a large 89 degree. Two major benefits follow, intermediary network nodes do not 90 need support PREF, and if the node is a PREF node, it does not 91 execute PREF. Secondly, no or reduced buffer reservation should be 92 required in the nodes along the routing path. 94 Multiple copies in the same data traffic put bandwidth pressure upon 95 the network without appropriate constraints. Low-rate traffic 96 services such as blockchain, IoT etc. from the use cases in 97 [I-D.ietf-detnet-use-cases] are proper for PREF on the single path to 98 provide service protection as well as latency reduction. 100 2. Convention used in this document 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 103 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 104 this document are to be interpreted as described in [RFC2119]. 106 The lowercase forms with an initial capital "Must", "Must 107 Not","Shall", "Shall Not", "Should", "Should Not", "May", and 108 "Optional"in this document are to be interpreted in the sense defined 109 in [RFC2119], but are used where the normative behavior is defined in 110 documents published by SDOs other than the IETF. 112 3. Terminology and definitions 114 This document uses the terms defined in 115 [I-D.ietf-detnet-architecture] and [I-D.ietf-detnet-dp-alt]. 117 4. Encapsulation impacts 119 From detnet processing point of view, PREF in the single path for 120 low-rate traffic is not intrinsically different from PREF in multiple 121 paths as it is defined in [I-D.ietf-detnet-dp-alt]. Both flow ID and 122 control word are needed to identify the specific detnet flow as well 123 as packets. Therefore this document will try to reuse the 124 encapsulation mechanism in [I-D.ietf-detnet-dp-alt] with minor 125 optional modification to make PREF in the single path run as 126 designed. 128 4.1. Flow ID/Label 130 Under the mechanism of PREF in multiple paths, flow label also works 131 as an indicator to the DA-*-PE that PREF be executed other than 132 identifying the specific detnet flow. Nonetheless, PREF in the 133 single path involves simply the initiating and terminating side of 134 the detnet service, while the intermediary nodes execute neither 135 replication nor elimination. One bit indicator in the flow ID to 136 announce whether or not the ongoing detnet traffic has multiple 137 copies in the same stream is necessary. As Figure 1 shows, the bit 138 'R' represents the indicator for which the default value should be 139 '0' indicating no more than 1 copy of the packets in the current 140 stream, while '1' setting indicates that the current stream has more 141 than one copies of the packets. 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 144 | Reserved |R|D| 24 bit Flow ID | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 147 Figure 1: DetNet Flow ID word 149 The latest data plane working group draft removes the original flow 150 ID definition, and instead leverages service label in MPLS PW and 151 flow label in IPv6 respectively. Maybe further extensions as 152 designed above in detnet label definitions in PW and IPv6 are 153 necessary. Detailed solutions would be provided upon expert 154 feedback. 156 4.2. Control word 158 Definitions of control word in both MPLS PW and IPv6 will be reused 159 for PREF in the single path, and revisions should be made according 160 to the latest development of the [I-D.ietf-detnet-dp-alt]. 162 However, control word would be another opportunity to make the PREF- 163 in-the-single-path indication as an alternative solution against the 164 Flow label solution. The intrinsic mechanism would be pretty much 165 the same as in Flow label. One reserved bit is used to announce 166 whether or not the ongoing detnet traffic has multiple copies in the 167 same stream. '0' should be the default value indicating 'no PREF in 168 the single path', while '1' indicates yes as is shown in the Figure 2 169 and Figure 3. 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 172 |0 0 0 0 Reserved |R| 16 bit sequence number | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 175 Figure 2: DetNet PW control word 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 178 | 16 bit sequence number | Reserved |R| 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 181 Figure 3: DetNet IPv6 Destination Option 183 5. Replication solutions 185 Low-rate traffic consists of both continuous (constant rate or 186 invariable rate) and discontinuous traffic, so roughly there are two 187 solutions to make the replication of the traffic. 189 5.1. Discontinuous traffic 191 The burst data should be taken as one unit upon which the replication 192 is executed. The whole burst data block would be replicated in the 193 pre-routed traffic. 195 5.2. Continuous traffic 197 Whether or not the traffic is constant, continuous traffic first has 198 to be truncated evenly into units upon which the replication is 199 executed. The truncation criteria could both be unit size (100Kbytes 200 etc) and unit time (1 second etc.). 202 6. Forwarder clarifications 204 PREF in the single path proposed in this document is a sub-part of 205 the PREF in the multiple paths defined in [I-D.ietf-detnet-dp-alt]. 206 Upon receiving the DetNet flow packet, 'R' bit which is set to be '1' 207 should initiate PREF-in-the-single-path processing in the relay or 208 edge nodes. 210 The output of the single-path PREF elimination function is always a 211 single packet, and the output of the single-path replication is 212 always one or more packets. The replicated packets MUST share the 213 same DetNet control word sequence number. 215 6.1. Edge node clarifications 217 Also as specified in the multiple-paths PREF data plane document, 218 edge node extended forwarder is responsible to push DetNet header 219 (flow label and control word etc.) into the packets (if not already 220 present) before forwarding to other nodes. 222 The terminating edge node should execute the singple-path PREF 223 elimination which receives a specific packet while ignoring the other 224 copies with the same control word sequence numbers. 226 6.2. Relay node clarification 228 Upon receiving the DetNet flow packets, relay node check if it's 229 single-path PREF replications, namely whether or not 'R' is set to be 230 '1'. if it is single-path PREF replications, the relay node simply 231 forwards the packet as usual and executes no more processing. If the 232 boolean multiple-path PREF switch is on, the corresponding PREF 233 processing is executed normally. 235 7. Traffic rate limit 237 The single-path PREF is designed to address the low-rate traffic. 238 The traffic rate limit should be subject to the service providers. 239 The rate limit could be configured in both application level and 240 network management level. 242 8. Normative References 244 [I-D.ietf-detnet-architecture] 245 Finn, N., Thubert, P., Varga, B., and J. Farkas, 246 "Deterministic Networking Architecture", draft-ietf- 247 detnet-architecture-03 (work in progress), August 2017. 249 [I-D.ietf-detnet-dp-alt] 250 Korhonen, J., Farkas, J., Mirsky, G., Thubert, P., 251 Zhuangyan, Z., and L. Berger, "DetNet Data Plane Protocol 252 and Solution Alternatives", draft-ietf-detnet-dp-alt-00 253 (work in progress), October 2016. 255 [I-D.ietf-detnet-use-cases] 256 Grossman, E., Gunther, C., Thubert, P., Wetterwald, P., 257 Raymond, J., Korhonen, J., Kaneko, Y., Das, S., Zha, Y., 258 Varga, B., Farkas, J., Goetz, F., Schmitt, J., Vilajosana, 259 X., Mahmoodi, T., Spirou, S., Vizarreta, P., Huang, D., 260 Geng, X., Dujovne, D., and M. Seewald, "Deterministic 261 Networking Use Cases", draft-ietf-detnet-use-cases-13 262 (work in progress), September 2017. 264 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 265 Requirement Levels", BCP 14, RFC 2119, 266 DOI 10.17487/RFC2119, March 1997, 267 . 269 [RFC6003] Papadimitriou, D., "Ethernet Traffic Parameters", 270 RFC 6003, DOI 10.17487/RFC6003, October 2010, 271 . 273 Author's Address 275 Daniel Huang 276 ZTE corporation, Inc. 277 No.50 Software Avenue 278 Nanjing, Jiangsu 210012 279 P.R.China 281 Email: huang.guangping@zte.com.cn 282 URI: http://www.zte.com.cn