idnits 2.17.1 draft-han-mpls-sdi-sr-02.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 : ---------------------------------------------------------------------------- ** There are 2 instances of lines with control characters in the document. 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 (August 16, 2021) is 977 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) == Missing Reference: 'ITU-T G.8113.1' is mentioned on line 199, but not defined Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group L. Han 3 Internet-Draft China Mobile 4 Intended status: Standards Track F. Yang 5 Expires: February 17, 2022 Huawei Technologies 6 J. Zhao 7 CAICT 8 August 16, 2021 10 Signal Degrade Indication in Segment Routing over MPLS Network 11 draft-han-mpls-sdi-sr-02 13 Abstract 15 This document describes a typical use case of MPLS-TP, where signal 16 degrade defect needs to be correctly detected and transmitted via OAM 17 messages within network. When MPLS-TP evolves to Segment Routing 18 MPLS, transit node has no knowledge of labels to be encapsulated in 19 MPLS label stack. Transit node cannot spread OAM messages with 20 signal degrade defect indication. Thus, a solution is proposed in 21 this draft. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on February 17, 2022. 46 Copyright Notice 48 Copyright (c) 2021 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1. Defect Triggered Procedure . . . . . . . . . . . . . . . 4 67 3.2. MPLS-TP Solution . . . . . . . . . . . . . . . . . . . . 4 68 3.3. Problem in SR-MPLS . . . . . . . . . . . . . . . . . . . 6 69 4. Solution in SR-MPLS . . . . . . . . . . . . . . . . . . . . . 6 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 75 8.2. Informative References . . . . . . . . . . . . . . . . . 8 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 78 1. Background 80 In early era of telecommunication, transport network is set up to 81 provide voice service. The connection in network is always 82 connection-oriented and circuit switching. With the rapid increasing 83 bandwidth brought by Ethernet, transport network transforms into the 84 packet-switched transport network. Technologies like MPLS/PWE3 85 perfectly meet the requirements of supporting both packet-transport 86 and circuit-transport. It led to the work of MPLS Transport Profile 87 (MPLS-TP), collaborated between ITU-T and IETF at the first decade of 88 the 21st century. 90 MPLS-TP is a subset of MPLS. Features that are not applicable to 91 transport network are excluded, and features to meet the requirements 92 of transport network, e.g., bidirectional path, deterministic control 93 and management, etc., are strictly required. According to the Joint 94 Working Team consensus, any extension of MPLS-TP would be included in 95 MPLS field. 97 With the emerge of Segment Routing (SR) and Software Defined Network 98 (SDN), MPLS-TP network technologies are adapted as well. In this 99 draft, we recognize one use case where the signal degrade defect can 100 be correctly detected and transmitted via MPLS-TP OAM in MPLS-TP, but 101 not fulfilled in SR-MPLS. To fix this problem is the motivation of 102 this draft. 104 Editor's note: This section gives a historical introduction of MPLS- 105 TP, since it has been extensively deployed in packet switched 106 transport networks for years. The intention of this section is to 107 help readers understand the unique of requirements from packet 108 transport network. Once the draft becomes RFC, part of this section 109 can be moved to Appendix. 111 2. Terminology 113 MPLS: MultiProtocol Label Switching 115 PWE3: Pseudo Wire Emulation Edge to Edge 117 MPLS-TP: MultiProtocol Label Switching - Transport Profile 119 SR: Segment Routing 121 SDN: Software Defined Network 123 OAM: Operation, Administration and Maintenance 125 SD: Signal Degrade 127 BER: Bit Error Rate 129 WDM: Wavelength Division Multiplexing 131 NMS: Network Management System 133 G-ACh: Generic Associated Channel 135 PDU: Protocol Data Unit 137 CCM: Continuity Check Message 139 MEP: Maintenance Entity Group End Point 141 MIP: Maintenance Entity Group Intermediate Point 142 AIS: Alarm Indication Signal 144 3. Problem Statement 146 3.1. Defect Triggered Procedure 148 Signal Degrade (SD) describes a status of signal associated data has 149 degraded and a degraded defect is active. Signal degrade of a 150 physical link is usually measured and represented by Bit Error Rate 151 (BER) value. Fiber aging, impairment and pollution, optical module 152 mismatch or WDM transmission error are the reasons to lead to signal 153 degrade. More information about signal degrade can be found 154 in[I-D.yang-mpls-ps-sdi-sr]. 156 In practice, when physical link degrades in network, signal degrade 157 defect is firstly detected and reported by the node. A specific type 158 of alarm is generated and sent to Network Management System (NMS) or 159 a SDN controller. It is a report to management plane and strongly 160 required from perspective of network management. However, the 161 problem is the notification to management plane is usually not fast 162 enough to assist the network recovery. It may result in hour or even 163 day level of service interruption time. 165 As mentioned in [RFC6372], defect may trigger system to perform a 166 survivability action, when notification of an issue is reported from 167 equipment in a lower layer, system fails to receive an OAM continuity 168 check message, or receives of an OAM message reporting a failure 169 condition. Similarly, when signal degrade defect is reported from 170 the lower layer, e.g. physical layer, local protection mechanism can 171 be triggered within the internal system of nodez. In case of 172 protection switchover selector is at the source or destination node, 173 while the signal degrade is happened at intermediate node, an OAM 174 message should be transmitted to notify the degrade condition to the 175 nodes actually perform the protection switchover. This action is 176 preferred to be triggered by events in the data plane [RFC6372]. 178 3.2. MPLS-TP Solution 180 Generic Associated Channel (G-ACh) [RFC5586] is defined to carry OAM 181 messages for MPLS pseudowires, LSPs and sections. The Generic 182 Associated Channel format used in MPLS is shown in Figure 1. By 183 using the generic associated channel and indication of channel type, 184 different OAM mechanisms with different formats can be encapsulated 185 uniformly as well as independently. 187 0 1 2 3 188 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 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Label | EXP |S| TTL | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | GAL Label (13) | TC |S| TTL | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 |0 0 0 1|Version| Reserved | Channel Type | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 Figure 1 G-ACh Format in MPLS 199 In MPLS-TP, ITU-T G.8113.1 [ITU-T G.8113.1] specifies a large set of 200 OAM mechanisms and has been widely deployed in packet transport 201 networks. Figure 2 shows the common OAM PDU format of different OAM 202 mechanisms. 204 0 1 2 3 205 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 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | MEL | Version | OpCode | Flags | TLV Offset | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | OAM PDU | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 |End TLV| 212 +-+-+-+-+ 214 Figure 2 ITU-T G.8113.1 Common OAM PDU Format 216 MEG Level: MEG Level is a 3-bit field. It contains an integer value 217 that identifies the MEG level of OAM PDU. Value ranges from 0 to 7. 219 Version: Version is a 5-bit field. It contains an integer value that 220 identifies the OAM protocol version. Value is 0 in the current 221 version. 223 OpCode: OpCode is a 1-octet field. It contains an OpCode that 224 identifies an OAM PDU type. OpCode is used to identify the remaining 225 content of an OAM PDU. Value for the CCM PDU type is 1. 227 Flags: Flags is an 8-bit field. Use of the bits in this field is 228 dependent on the OAM PDU type. 230 TLV Offset: TLV Offset is a 1-octet field. It contains the offset to 231 the first TLV in an OAM PDU relative to the TLV Offset field. The 232 value of this field is associated with an OAM PDU type. When the TLV 233 Offset is 0, it points to the first octet following the TLV Offset 234 field. 236 End TLV: an all-ZEROes octet value. 238 When signal degrade happens in MPLS-TP, an MPLS-TP Alarm Indication 239 Signal (AIS) OAM message with active AIS indication is generated and 240 transmitted within the OAM maintenance domain. Maintenance Entity 241 Group End Point (MEP), usually also acting as protection switchover 242 selector, performs the protection switchover once it receives the AIS 243 indication in MPLS-TP OAM message. 245 3.3. Problem in SR-MPLS 247 When Segment Routing is introduced to MPLS, the nodes except the 248 headend have no information of the forwarding path. If the signal 249 degrade is happened on the transit nodes, MPLS-TP AIS OAM message 250 cannot be generated because this node has no knowledge of labels 251 ought to be encapsulated in MPLS label stack. Either the label 252 information of forwarding path can be obtained on transit node, or 253 the defect can be indicated in different messages could help the 254 defect spread in network. It is valuable to keep transit node with 255 the capability of reporting defects in SR-MPLS. 257 4. Solution in SR-MPLS 259 Segment routing is designed to reduce the states in transit nodes, 260 any defects like SD defect cannot be indicated in a newly generated 261 OAM message on transit node. Alternative way is to indicate the 262 defect in other OAM messages. Continuity Check Message (CCM) is 263 proposed to indicate the signal degrade defect for two reasons. 264 Firstly, CCM is designed to be applicable for fault management, 265 performance monitoring, or protection switching applications. 266 Secondly, consider the merit of CCM's various transmission period, 267 the defect indication can be flexibly transmitted according to 268 operator's needs. 270 One reservation bits in Flag section in CCM OAM PDU message can be 271 used as Error Indication (EI) to indicate signal degrade. Flag 272 format with EI extension is shown in Figure 3. 274 MSB LSB 275 0 276 0 1 2 3 4 5 6 7 277 +---+---+---+---+---+---+---+---+ 278 |RDI| EI| Reserved | Period | 279 +---+---+---+---+---+---+---+---+ 281 Figure 3 CCM OAM PDU Flags Format with EI Extension 283 RDI: Remote Defect Indication, set to 1 to indicate RDI, otherwise it 284 is set to 0. 286 Period: Indicate the transmission period. 288 EI: Error indication, 0 indicates no error, 1 indicates error. 290 Reserved: Reserved fields are set to all ZEROes. 292 If the node detects the signal degrade defect, EI field is set in CCM 293 OAM message and transmitted to other nodes. Note that, Maintenance 294 Entity Group Intermediate Point (MIP) is required to be transparent 295 to CCM message in MPLS-TP. In order to support BER indication on 296 each node along the forwarding path, extra configuration and 297 intervening implementation to process CCM message would be required 298 on MIP. 300 Editor's Note: When other OAM mechanisms used in generic associated 301 channel (G-ACh), there might be various solutions to transmit signal 302 degrade defect, or any other defects detected by transit nodes. This 303 draft introduces a very light-weight solution, which has already been 304 implemented and deployed in networks. 306 5. IANA Considerations 308 This document requests IANA to assign one bit from Flags of MPLS-TP 309 OAM PDU format to indicate "Signal Degrade". 311 6. Security Considerations 313 There are MEP and MIP node defined in OAM mechanisms. Some types of 314 OAM message are defined to be transparent to MIP node, and requires 315 no extra configuration or message processing on MIP nodes. If the 316 transit node of SR-MPLS acts as MIP in OAM maintenance domain, this 317 MIP node needs to process the OAM messages to indicate the defects. 318 At the moment, explicit configuration is required on MIP to have the 319 authority to process OAM messages. 321 7. Acknowledgements 323 The authors want to thank Yuanlong Jiang, Mach Chen, Yongjian Hu for 324 their valuable suggestions during the construction of draft. 326 8. References 327 8.1. Normative References 329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 330 Requirement Levels", BCP 14, RFC 2119, 331 DOI 10.17487/RFC2119, March 1997, 332 . 334 8.2. Informative References 336 [I-D.yang-mpls-ps-sdi-sr] 337 Yang, F., Han, L., and J. Zhao, "Problem Statement of 338 Signal Degrade Indication for SR over MPLS", draft-yang- 339 mpls-ps-sdi-sr-01 (work in progress), November 2020. 341 [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., 342 "MPLS Generic Associated Channel", RFC 5586, 343 DOI 10.17487/RFC5586, June 2009, 344 . 346 [RFC6372] Sprecher, N., Ed. and A. Farrel, Ed., "MPLS Transport 347 Profile (MPLS-TP) Survivability Framework", RFC 6372, 348 DOI 10.17487/RFC6372, September 2011, 349 . 351 [ITU-T_G8113.1] 352 ITU-T, "ITU-T G.8113.1: Operations, administration 353 and maintenance mechanisms for MPLS-TP in packet 354 transport networks", April 2016. 356 Authors' Addresses 358 Liuyan Han 359 China Mobile 360 Beijing 361 China 363 Email: hanliuyan@chinamobile.com 365 Fan Yang 366 Huawei Technologies 367 Beijing 368 China 370 Email: shirley.yangfan@huawei.com 371 Junfeng Zhao 372 CAICT 373 Beijing 374 China 376 Email: zhaojunfeng@caict.ac.cn