idnits 2.17.1 draft-geng-spring-redundancy-protection-srh-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 date (March 09, 2020) is 1502 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Geng 3 Internet-Draft M. Chen 4 Intended status: Experimental Huawei 5 Expires: September 10, 2020 March 09, 2020 7 SRH Extension for Redundancy Protection 8 draft-geng-spring-redundancy-protection-srh-00 10 Abstract 12 Redundancy protection is a method of service protection by sending 13 copies of the same packets of one flow over multiple paths, which 14 includes packet replicaiton, elimination and ordering. This document 15 defines SRv6 header(SRH) extensions to support redundancy protection. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in . 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 10, 2020. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 2 59 3. Redundancy Protection Requirement Analysis . . . . . . . . . 3 60 4. SRH Extensions for Redundancy Protection . . . . . . . . . . 3 61 4.1. Option 1: seperated TLVs for flow identification and 62 sequence number . . . . . . . . . . . . . . . . . . . . . 4 63 4.2. Option 2 unified TLV for flow identification and sequence 64 number . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 67 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 68 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Introduction 73 Redundancy protection is a method of providing 1+1 protection by 74 sending copies of the same packets of one flow over multiple paths, 75 which includes packet replicaiton, elimination and ordering. This 76 document defines SRv6 header(SRH) extensions to support redundancy 77 protection. 79 2. Terminology and Conventions 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 Redundancy Node: the start point of redudancy protection, which is a 86 network device that could implement packet replication. 88 Merging Node: the end point of redudancy protection, which is a 89 network node that could implement packet elimination and 90 ordering(optionally). 92 Editor's Note: Similar mechanism is defined as "Service Protection" 93 in the [RFC8655]. In this document, we define a new term "Redundancy 94 Protection" to distinguish with other service protection method. 95 Some of the terms are the similar as [RFC8655]. 97 3. Redundancy Protection Requirement Analysis 99 The figure shows how to provide redundancy protection over SRv6. 101 | | 102 ----IPv6--->|<---------------SRv6 Domain------------->|<----IPv6--- 103 | | 104 | +------+T2+----+ | 105 +---+ +---+ +-+-+ +-+-+ +---+ +---+ 106 | E1+----| In|--+T1+--+Red| |Mer|--+T4+--| Eg+----+ E2| 107 +---+ +---+ +-+-+ +-+-+ +---+ +---+ 108 +-----+T3+-----+ 110 As the figure shows, an IPv6 flow is sent out from the end station 111 E1. The packet of the flow is encapsulated in an outer IPv6+SRH 112 header in the Ingress(In) and transported through an SRv6 domain. In 113 the Egress(Eg), the outer IPv6 header+SR of the packet is popped, and 114 the packet is sent to the destination E2. 116 The process of redundancy protection is as follows: 1) The flow is 117 replicated in Rep(Redundancy Node); 2) Tow replicated flows go 118 through different paths till Mer (Merging Node); When there is any 119 failures happened in one the path, the service continues to deliver 120 through the other path without break; 3) The first received packet of 121 the flow is transmitted from Mer (Merging Node) to Eg(Egress), and 122 the redundant packets are eliminated. 4) Sometimes, the packet will 123 arrive out of order because of redundancy protection, the function of 124 reordering may be necessary in the Merging Node. 126 This document defines Flow Identification and Sequence Number in 127 Segment Routing Header(SRH) as an extension of the current 128 draft[I-D.ietf-6man-segment-routing-header] to support redundancy 129 protection. 131 Flow Identification is used to distinguish flows and Sequence Number 132 is used to distinguish packets in the same flow when doing packet 133 merging and ordering. 135 4. SRH Extensions for Redundancy Protection 137 Flow Identification and Sequence Number could be defined in SRH 138 optional TLV. 140 4.1. Option 1: seperated TLVs for flow identification and sequence 141 number 143 0 1 2 3 144 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 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Type | Length | RESERVED | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | RESERVED | Flow Identification | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 where: 153 o Type: 8bits, to be assigned by IONA. 155 o Length: 8 octets. 157 o RESERVED: 28 bits, MUST be 0 on transmission and ignored on 158 receipt. 160 o Flow Identification: 20 bits, which is used for identifying 161 redundant protection flow. 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Type | Length | RESERVED | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 |RESERVED| Sequence Number | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 where: 173 o Type: 8 bits, to be assigned by IONA. 175 o Length: 8. 177 o RESERVED: 20 bits. MUST be 0 on transmission and ignored on 178 receipt. 180 o Sequence Number: 28 bits, which is used for indicating sequence 181 number of the redundant protection flow. 183 4.2. Option 2 unified TLV for flow identification and sequence number 184 0 1 2 3 185 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 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Type | Length | Flow Identification | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | | Sequence Number | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | RESERVED | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 where: 196 o Type: 8bits, to be assigned by IANA. 198 o Length: 8 octets. 200 o Flow Identification: 20 bits, which is used for identifying the 201 redundant protection flow. 203 o Sequence Number: 28 bits, which is used for indicating sequence 204 number of the redundant protection flow. 206 o Reserved: 32 bits. MUST be 0 on transmission and ignored on 207 receipt. 209 5. IANA Considerations 211 TBD 213 6. Security Considerations 215 TBD 217 7. Acknowledgements 219 Thank you for valuable comments from James Guichard and Andrew Mail 221 8. Normative References 223 [I-D.ietf-6man-segment-routing-header] 224 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 225 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 226 (SRH)", draft-ietf-6man-segment-routing-header-26 (work in 227 progress), October 2019. 229 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 230 Requirement Levels", BCP 14, RFC 2119, 231 DOI 10.17487/RFC2119, March 1997, 232 . 234 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 235 "Deterministic Networking Architecture", RFC 8655, 236 DOI 10.17487/RFC8655, October 2019, 237 . 239 Authors' Addresses 241 Xuesong Geng 242 Huawei 244 Email: gengxuesong@huawei.com 246 Mach(Guoyi) Chen 247 Huawei 249 Email: mach.chen@huawei.com