idnits 2.17.1 draft-kang-tcpm-fault-management-in-mptcp-session-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (9 August 2020) is 1354 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC0793' is defined on line 229, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance and Minor Extensions J. Kang, Ed. 3 Internet-Draft Q. Liang 4 Intended status: Informational Huawei 5 Expires: 10 February 2021 9 August 2020 7 Fault Management Mechanism in MPTCP Session 8 draft-kang-tcpm-fault-management-in-mptcp-session-00 10 Abstract 12 This document presents a mechanism for fault management during a 13 MPTCP session. It is used to convey subflow failure information from 14 client to server by other subflow running normally. It includes: 1) 15 a new Fault Announce Option for describing subflow failure, 2) 16 implementation and interoperability of this option during a MPTCP 17 session when one subflow suffers a failure. In fact, the server is 18 able to determine network problems accurately based on these fault 19 information reported from multiple clients for their connections. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 10 February 2021. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 56 2. Fault Announce Exchanges . . . . . . . . . . . . . . . . . . 3 57 3. Fault Announce option . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Option format . . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. Additional requirements to be considered . . . . . . . . 5 60 3.2.1. Scenario of middlebox failure . . . . . . . . . . . . 5 61 3.2.2. Scenario of distinguishing fault types . . . . . . . 5 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 6.1. Normative References . . . . . . . . . . . . . . . . . . 5 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 During data transmission in a MPTCP session, subflows may encounter 71 some problems, for example, port failure on one endpoint, network 72 failure, or middlebox working abnormally. Current MPTCP protocol 73 does not provide exchanges between client and server when a fault 74 happens on a subflow which will cause transmission failure or delay. 76 [RFC8684] introduces TCP RST Reason (MP_TCPRST) option to signal 77 reasons for sending a RST on a subflow which can help an 78 implementation decide whether to attempt later reconnection. TCP RST 79 Reason (MP_TCPRST) option only reports the reason for a specific 80 subflow that has been determined to be closed later. This solution 81 does not cover the case of abnormal termination of one ongoing 82 subflow. 84 1.1. Requirements Language 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in RFC 2119 [RFC2119]. 90 2. Fault Announce Exchanges 92 This document proposes a fault announce mechanism with a new option 93 that can be used to deliver failure information of abnormal subflow 94 between client and server via another subflow in the MPTCP session 95 that works properly. The flow is illustrated in Figure 1. 97 +--------+ +--------+ 98 | Client | | Server | 99 +--------+ +--------+ 100 | | 101 |<---MPTCP Session setup with subflows--->| 102 | | 103 Determine that one ongoing subflow | 104 is faulty | 105 | | 106 |-------Send Fault Announce option------->| 107 | indicating suflow failure via | 108 | another subflow | 109 | | 110 | | 111 | | 113 Figure 1: Client sends Fault Announce to server during a MPTCP 114 Session 116 The Fault Announce option is carried on SYN, ACK or data packets. 118 Client may detect a local fault, for example, local port or network 119 card failure, or an error in local protocol processing. In this way, 120 the client can determine the fault cause. 122 Client may actively detect subflow failure by a detecting task to 123 determine the fault cause. For example, the client may deploy a 124 detection task using a bidirectional forwarding detection (BFD) to 125 determine whether the subflow is faulty. 127 Client may send an ICMP request to server and determine the 128 exceptions by the duration of a response. Specifically, if the 129 client cannot receive a response within a preset time, it means that 130 this subflow is not working properly. 132 Another way for client to determine the fault reason is ICMP error 133 report. Client may receive an ICMP error report from a third device 134 (e.g., middlebox on the faulty subflow), in which indicates the fault 135 cause. 137 3. Fault Announce option 139 A new Fault Announce option is defined to describe the fault in 140 detail occurring on one subflow. If it is set, the faulty subflow is 141 identified by its source address ID (SrcAddressID) and destination 142 address ID (SrcAddressID). The mapping between IP addresses and 143 addresses IDs should be created on both client and server through the 144 process of ADD_ADDR defined in [RFC8684] and [RFC6824]. 146 3.1. Option format 148 The format of the Fault Announce option (FAULT_ANNOUNCE) is depicted 149 in Figure 2: 151 1 2 3 152 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 153 +---------------+---------------+-------+-------+---------------+ 154 | Kind | Length |Subtype| (rsv) | Cause | 155 +---------------+---------------+-------+-------+---------------+ 156 | DestAddressID | SrcAddressID | | 157 +---------------+---------------+-------------------------------+ 159 Figure 2: Fault Announce (FAULT_ANNOUNCE) Option 161 A new subtype should be allocated to indicate Fault Announce option. 163 "Cause" is an 8-bit field to describe the reason code for which 164 causes the subflow to malfunction. Client detects the fault and 165 determines the cause. Following values (partially mapped to the 166 Exception Code in ICMP error report) are defined in this document: 168 * 0x00~0x09 is reserved. It is compatible with "Reason" defined in 169 RFC8684. 171 * Network is unreachable (code 0x0A). 173 * Host is unreachable (code 0x0B). 175 * Routing is failed (code 0x0C). 177 * Server Suppression (code 0x0D). 179 * TTL equals zero (IP loops may occur) (code 0x0E). 181 "SrcAddressID" is used to identify source address ID for the faulty 182 subflow. 184 "DestAddressID" is used to identify destination address ID for the 185 faulty subflow. 187 3.2. Additional requirements to be considered 189 3.2.1. Scenario of middlebox failure 191 In some actual scenarios, it is the middlebox failure that causes 192 blocking of one subflow. So client should report to server the 193 information of the faulty middlebox by Fault Announce option so that 194 the server can quickly locate it. The information of a faulty 195 middlebox may include: 197 Middlebox IP: The IP address of the faulty middlebox. 199 IP protocol version: The IP protocol version adopted by the faulty 200 middlebox, i.e. IPv4 or IPv6. Server can use it to parse the field 201 of "Middlebox IP address". 203 Flag 'A': If "Middlebox IP address" is optional, this flag should be 204 defined to indicate whether the field of "Middlebox IP address" is 205 carried in Fault Announce option. 207 3.2.2. Scenario of distinguishing fault types 209 In some possible implementations, faults are classified into 210 transient fault and non-transitory fault. So a field of "fault type" 211 may be added to identify the type (transient fault or non-transitory 212 fault) for subsequent processing. 214 4. IANA Considerations 216 IANA is requested to assign a MPTCP option subtype for the Fault 217 Announce option. 219 5. Security Considerations 221 Fault Announce option is neither encrypted nor authenticated, so on- 222 path attackers and middleboxes could remove, add or modify this 223 option on observed Multipath TCP connections. 225 6. References 227 6.1. Normative References 229 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 230 RFC 793, DOI 10.17487/RFC0793, September 1981, 231 . 233 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 234 Requirement Levels", BCP 14, RFC 2119, 235 DOI 10.17487/RFC2119, March 1997, 236 . 238 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 239 "TCP Extensions for Multipath Operation with Multiple 240 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 241 . 243 [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 244 Paasch, "TCP Extensions for Multipath Operation with 245 Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 246 2020, . 248 Authors' Addresses 250 Jiao Kang (editor) 251 Huawei 252 D2-03,Huawei Industrial Base 253 Shenzhen 254 China 256 Phone: +86 18520828326 257 Email: kangjiao@huawei.com 259 Qiandeng Liang 260 Huawei 261 No. 207, Jiufeng 3rd Road, East Lake High-tech Development Zone 262 Wuhan 263 China 265 Phone: +86 18651640216 266 Email: liangqiandeng@huawei.com