idnits 2.17.1 draft-geng-6man-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 (February 20, 2021) is 1155 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) 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 IPv6 Maintenance Working Group X. Geng 3 Internet-Draft M. Chen 4 Intended status: Standards Track F. Yang 5 Expires: August 24, 2021 Huawei Technologies 6 February 20, 2021 8 SRH Extension for Redundancy Protection 9 draft-geng-6man-redundancy-protection-srh-00 11 Abstract 13 Redundancy protection is a method of service protection by sending 14 copies of the same packets of one flow over multiple paths, which 15 includes packet replication, elimination and ordering. This document 16 defines SRv6 header (SRH) extensions to support redundancy 17 protection. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in . 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 24, 2021. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 2 61 3. Redundancy Protection over SRv6 Scenario . . . . . . . . . . 3 62 4. SRH Extension for Redundancy Protection . . . . . . . . . . . 3 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 66 8. Normative References . . . . . . . . . . . . . . . . . . . . 4 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 69 1. Introduction 71 Redundancy protection is a method of providing 1+1 protection by 72 sending copies of the same packets of one flow over multiple paths, 73 which includes packet replication, elimination and ordering. This 74 document defines SRv6 header (SRH) extensions to support redundancy 75 protection. 77 2. Terminology and Conventions 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in [RFC2119]. 83 Redundancy Node: the start point of redundancy protection, which is a 84 network device that could implement packet replication. 86 Merging Node: the end point of redundancy protection, which is a 87 network node that could implement packet elimination and ordering 88 (optionally). 90 Flow Identification: information in SR data service to indicate one 91 flow. 93 Sequence Number: information in SR data service to indicate the 94 packet sequence of one flow. 96 Editor's Note: Similar mechanism is defined as "Service Protection" 97 in the [RFC8655]. In this document, we define a new term "Redundancy 98 Protection" to distinguish with other service protection method. 99 Some of the terms are the similar as [RFC8655]. 101 3. Redundancy Protection over SRv6 Scenario 103 The figure shows how to provide redundancy protection over SRv6. 105 | | 106 ----IPv6--->|<---------------SRv6 Domain------------>|<----IPv6--- 107 | | 108 | +------+R1+----+ | 109 +---+ +---+ +-+-+ +-+-+ +---+ +---+ 110 |E1 +----+In +-------+Red| |Mer+--------+Eg +----+E2 | 111 +---+ +---+ +-+-+ +-+-+ +---+ +---+ 112 +------+R2+----+ 114 As the figure shows, an IPv6 flow is sent out from the end station 115 E1. The packet of the flow is encapsulated in an outer IPv6+SRH 116 header in the Ingress(In) and transported through an SRv6 domain. In 117 the Egress(Eg), the outer IPv6+SRH header of packet is popped, and 118 the packet is sent to the destination E2. 120 The process of redundancy protection is as follows: 1) The flow is 121 replicated in Red (Redundancy Node); 2) Two replicated flows go 122 through different paths till Mer (Merging Node); When there is any 123 failures happened in one the path, the service continues to deliver 124 through the other path without break; 3) The first received packet of 125 the flow is transmitted from Mer (Merging Node) to Eg(Egress), and 126 the redundant packets are eliminated; 4) Sometimes, the packet will 127 arrive out of order because of redundancy protection, the function of 128 reordering may be necessary in the Merging Node. 130 This document defines Flow Identification and Sequence Number in 131 Segment Routing Header(SRH) as an extension of [RFC8754] to support 132 redundancy protection. 134 Flow Identification is used to distinguish flows, and Sequence Number 135 is used to distinguish packets in the same flow when doing packet 136 merging and ordering. 138 4. SRH Extension for Redundancy Protection 140 Flow Identification and Sequence Number could be defined in SRH 141 optional TLV. 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 | Flow Identification | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Sequence Number | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 where: 155 o Type: 8 bits, indicates the use of redundancy protection, to be 156 assigned by IANA. 158 o Length: 8 bits. 160 o Reserved: 16 bits. MUST be 0 on transmission and ignored on 161 receipt. 163 o Flow Identification: 32 bits, which is used for identifying the 164 redundant protection flow. 166 o Sequence Number: 32 bits, which is used for indicating sequence 167 number of the redundant protection flow. 169 5. IANA Considerations 171 This document requires registration of a specific type of TLV used 172 for redundancy protection in "Segment Routing Header TLVs" registry. 174 6. Security Considerations 176 TBD 178 7. Acknowledgements 180 Thanks for the valuable comments from James Guichard and Andrew 181 Malis. 183 8. Normative References 185 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 186 Requirement Levels", BCP 14, RFC 2119, 187 DOI 10.17487/RFC2119, March 1997, 188 . 190 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 191 "Deterministic Networking Architecture", RFC 8655, 192 DOI 10.17487/RFC8655, October 2019, 193 . 195 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 196 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 197 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 198 . 200 Authors' Addresses 202 Xuesong Geng 203 Huawei Technologies 204 Beijing 205 China 207 Email: gengxuesong@huawei.com 209 Mach(Guoyi) Chen 210 Huawei Technologies 211 Beijing 212 China 214 Email: mach.chen@huawei.com 216 Fan Yang 217 Huawei Technologies 218 Beijing 219 China 221 Email: shirley.yangfan@huawei.com