idnits 2.17.1 draft-wang-sfc-multi-layer-oam-09.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 (June 14, 2017) is 2507 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) == Outdated reference: A later version (-15) exists of draft-ietf-sfc-oam-framework-01 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC WG G. Mirsky 3 Internet-Draft ZTE Corp. 4 Intended status: Standards Track W. Meng 5 Expires: December 16, 2017 ZTE Corporation 6 B. Khasnabish 7 ZTE TX, Inc. 8 C. Wang 9 June 14, 2017 11 Multi-Layer OAM for Service Function Chains in Networks 12 draft-wang-sfc-multi-layer-oam-09 14 Abstract 16 A multi-layer approach to the task of Operation, Administration and 17 Maintenance (OAM) of Service Function Chains (SFCs) in networks is 18 presented. Based on the SFC OAM requirements, a multi-layer model is 19 introduced. A mechanism to detect and localize defects using the 20 multi-layer model is also described. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 16, 2017. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Multi-layer Model of SFC OAM . . . . . . . . . . . . . . . . 3 61 4. Requirements for SFC OAM Multi-layer Model . . . . . . . . . 4 62 5. SFC OAM multi-layer model . . . . . . . . . . . . . . . . . . 5 63 6. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 6 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 8.1. SFC TLV Type . . . . . . . . . . . . . . . . . . . . . . 7 67 8.2. SFC OAM UDP Port . . . . . . . . . . . . . . . . . . . . 8 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 70 9.2. Informative References . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 [RFC7665] defines components necessary to implement Service Function 76 Chain (SFC). These include a classifier which performs 77 classification of incoming packets. A Service Function Forwarder 78 (SFF) is responsible for forwarding traffic to one or more connected 79 Service Functions (SFs) according to the information carried in the 80 SFC encapsulation. SFF also handles traffic coming back from the SF 81 and transports the data packets to the next SFF. And the SFF serves 82 as termination element of the Service Function Path (SFP). SF is 83 responsible for specific treatment of received packets. 85 Resulting from that SFC is constructed by a number of these 86 components, there are different views from different levels of the 87 SFC. One is the SFC, fully abstract entity, that defines an ordered 88 set of SFs that must be applied to packets selected as a result of 89 classification. But SFC doesn't define exact mapping between SFFs 90 and SFs. Thus there exists another semi-abstract entity referred as 91 SFP. SFP is the instantiation of the SFC in the network and provides 92 a level of indirection between the fully abstract SFC and a fully 93 specified ordered list of SFFs and SFs identities that the packet 94 will visit when it traverses the SFC. The latter entity is being 95 referred as Rendered Service Path (RSP). The main difference between 96 SFP and RSP is that in the former the authority to select the SFF/SF 97 has been delegated to the network. 99 This document proposes the multi-layer model of SFC Operation, 100 Administration and Maintenance (OAM) and requirements to improve the 101 troubleshooting efficiency. 103 2. Conventions 105 2.1. Requirements Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in BCP 110 14 [RFC2119] [RFC8174] when, and only when, they appear in all 111 capitals, as shown here. 113 2.2. Terminology 115 Unless explicitly specified in this document, active OAM in SFC and 116 SFC OAM are being used interchangeably. 118 e2e: End-to-End 120 FM: Fault Management 122 OAM: Operations, Administration, and Maintenance 124 RDI: Remote Defect Indication 126 RSP: Rendered Service Path 128 SF: Service Function 130 SFC: Service Function Chain 132 SFF: Service Function Forwarder 134 SFP: Service Function Path 136 3. Multi-layer Model of SFC OAM 138 As described in [I-D.ietf-sfc-oam-framework], multiple layers come 139 into play to realize the SFC, including the Service layer, the 140 underlying Network layer, as well as the Link layer, which are 141 depicted in Figure 1: 143 o The Service layer consists of classifiers and/or service 144 functions/SFs. 146 o Network and Transport layers leverage various overlay network 147 technologies interconnecting SFs to establish SFP. 149 o The Link layer is technology specific and reflects the technology 150 used in the underlay network. 152 +---+ +---+ +---+ +---+ +---+ 153 |SF1| |SF2| |SF3| |SF4| |SF5| 154 +---+ +---+ +---+ +---+ +---+ 155 \ / \ / | 156 +----------+ +----+ +----+ +----+ 157 |Classifier|-------|SFF1|---------|SFF2|--------|SFF3| 158 +----------+ +----+ +----+ +----+ 159 0---------------------------------------------0 Service layer 160 0----------------0--------------0-------------0 Network layer 161 0-------------0------0-------0------0---------0 Link layer 163 Figure 1: SFC OAM Multi-Layer model 165 4. Requirements for SFC OAM Multi-layer Model 167 To perfrom the OAM task of fault management (FM) in an SFC, that 168 inculdes failure detection, defect characterzation and localization, 169 this document defines the multi-layer model of OAM, presented in 170 Section 3, and set of requirements towards active OAM mechanisms to 171 be used on an SFC. 173 In example presented in Figure 1 the service SFP1 may be realized 174 through two RSPs, RSP1(SF1--SF3--SF5) and RSP2(SF2--SF4--SF6). To 175 perform end-to-end (e2e) FM SFC OAM: 177 REQ#1: Packets of active OAM in SFC SHOULD be fate sharing with 178 data traffic, i.e. in-band with the monitored traffic, i.e. follow 179 exactly the same RSP, in forward direction, i.e. from ingress 180 toward egress end point(s) of the OAM test. 182 REQ#2: SFC OAM MUST support pro-active monitoring of any element 183 in the SFC availability. 185 The egress, SFF3 in example in Figure 1, is the entity that detects 186 the failure of the SFC. It must be able to signal the new defect 187 state to the ingress, i.e. SFF1. Hence the following requirement: 189 REQ#3: SFC OAM MUST support Remote Defect Indication (RDI) 190 notification by egress to the ingress, i.e. source of continuity 191 checking. 193 REQ#4: SFC OAM MUST support connectivity verification. Definition 194 of mis-connectivity defect entry and exit criteria are outside the 195 scope of this document. 197 Once the SFF1 detects the defect objective of OAM switches from 198 failure detection to defect characterization and localization. 200 REQ#5: SFC OAM MUST support fault localization of Loss of 201 Continuity check in the SFC. 203 REQ#6: SFC OAM MUST support tracing an SFP in order to realize the 204 RSP. 206 It is practical, as presented in Figure 1, that several SFs share the 207 same SFF. In such case SFP1 may be realized over two RSPs, 208 RSP1(SF1--SF3--SF5) and RSP2(SF2--SF4--SF6). 210 REQ#7: SFC OAM MUST have the ability to discover and exercise all 211 available RSPs in the transport network. 213 In process of localizing the SFC failure separating SFC OAM layers is 214 very attractive and efficient approach. To achieve that continuity 215 among SFFs that are part of the same SFP should be verified. Once 216 SFFs reacheability along the particular SFP has been confirmed task 217 of defect localization may focus on SF reacheability verification. 218 Because reacheability of SFFs has already been verified, SFF local to 219 the SF may be used as source. 221 REQ#8: SFC OAM MUST be able to trigger on-demand FM with responses 222 being directed towards initiator of such proxy request. 224 By using the multi-layer model OAM that confirms to the above listed 225 requirements is capable to perform efficient defect localization on 226 an SFC. 228 5. SFC OAM multi-layer model 230 Figure 2 presents a use case of applying the proposed SFC OAM multi- 231 layer model. In this scenario operator needs to discover SFFs and 232 SFs of the same SFC. The Layer 1 includes the SFFs that are part of 233 the SFP. The Layer 2 - the SFs along the RSP. When trying to do SFC 234 OAM, classifier or service nodes select and confirm which SFC OAM 235 layering they plan to do, then encapsulate the layering information 236 in the SFC OAM packets, and send the SFC OAM packets along the 237 service function paths to the destination. When receiving the SFC 238 OAM packets, service nodes analyze the layering information and then 239 decide whether sending these packets to next SFFs directly without 240 being processed by SFs for Layer 1 process or sending to SFs for 241 Layer 2 process. 243 +---+ +---+ +----+ +----+ +-----+ +-----+ +------+ +------+ 244 |SF1|.|SFn| |SF1'|.|SFn'| |SF1''|.|SFn''| |SF1'''|.|SFn'''| 245 +---+ +---+ +----+ +----+ +-----+ +-----+ +------+ +------+ 246 \ / \ / | \ / \ / | 247 +------+ +----+ +----+ | +-----+ +-----+ | 248 |Class.|---|SFF1| ... |SFFn| | |SFF1'| ... |SFFn'| | 249 +------+ +----+ +----+ | +-----+ +-----+ | 250 | | | | 251 | | | | 252 |----|------Layer 1---------------| | 253 | | 254 |-------------Layer 2-------------| 256 Figure 2: SFC OAM multi-layering model 258 6. Theory of Operation 260 Echo Request/Reply is well-known OAM mechanism that is extecively 261 used to detect inconsitencies between states in control plane and 262 data plane, localize defects in the data plane. In SFC OAM Echo 263 Request/Reply is built as extension of Overlay Echo Request/Reply 264 functions [I-D.ooamdt-rtgwg-demand-cc-cv]. 266 Responder to the SFC Echo Request sends the Echo Reply over IP 267 network if the reply mode is Reply via an IPv4/IPv6 UDP Packet 268 [I-D.ooamdt-rtgwg-demand-cc-cv]. Because SFC NSH does not identify 269 the ingress of the SFP the Echo Request MUST include this information 270 that to be used as IP destination address for IP/UDP encapsulation of 271 the SFC Echo Reply. Sender of the SFC Echo Request MUST include SFC 272 Source TLV Figure 3. 274 0 1 2 3 275 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 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | SFC OAM Source ID Type | Length | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Value | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 Figure 3: SFC Source TLV 284 where 286 SFC OAM Source Id Type is two octets in length and has the value 287 of TBD1 Section 8.1. 289 Length is two octets long field and the valuse is equal to the 290 length of the Value field. 292 Value field contains IP address of the sender of the SFC OAM 293 control message, IPv4 or IPv6. 295 The UDP destination port for SFC Echo Reply TBD2 will be allocated by 296 IANA Section 8.2. 298 7. Security Considerations 300 TBD 302 8. IANA Considerations 304 8.1. SFC TLV Type 306 IANA is requested to create SFC OAM TLV Type registry. All code 307 points in the range 1 through 32759 in this registry shall be 308 allocated according to the "IETF Review" procedure as specified in 309 [RFC5226]. Code points in the range 32760 through 65279 in this 310 registry shall be allocated according to the "First Come First 311 Served" procedure as specified in [RFC5226]. Remaining code points 312 are allocated according to the Table 1: 314 +---------------+--------------+-------------------------+ 315 | Value | Description | Reference | 316 +---------------+--------------+-------------------------+ 317 | 0 | Reserved | This document | 318 | 1- 32759 | Unassigned | IETF Review | 319 | 32760 - 65279 | Unassigned | First Come First Served | 320 | 65280 - 65519 | Experimental | This document | 321 | 65520 - 65534 | Private Use | This document | 322 | 65535 | Reserved | This document | 323 +---------------+--------------+-------------------------+ 325 Table 1: SFC TLV Type Registry 327 This document defines the following new value in SFC OAM TLV Type 328 registry: 330 +-------+-------------------+---------------+ 331 | Value | Description | Reference | 332 +-------+-------------------+---------------+ 333 | TBD1 | Source IP Address | This document | 334 +-------+-------------------+---------------+ 336 Table 2: SFC OAM Source IP Address Type 338 8.2. SFC OAM UDP Port 340 IANA is requested to allocate UDP port number according to 342 +---------+--------+------------+---------+--------------+----------+ 343 | Service | Port | Transport | Descrip | Semantics | Referenc | 344 | Name | Number | Protocol | tion | Definition | e | 345 +---------+--------+------------+---------+--------------+----------+ 346 | SFC OAM | TBD2 | UDP | SFC OAM | Section 6 | This | 347 | | | | | | document | 348 +---------+--------+------------+---------+--------------+----------+ 350 Table 3: SFC OAM Port 352 9. References 354 9.1. Normative References 356 [I-D.ooamdt-rtgwg-demand-cc-cv] 357 Mirsky, G., Kumar, N., Kumar, D., Chen, M., Yizhou, L., 358 and D. Dolson, "Echo Request and Echo Reply for Overlay 359 Networks", draft-ooamdt-rtgwg-demand-cc-cv-03 (work in 360 progress), March 2017. 362 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 363 Requirement Levels", BCP 14, RFC 2119, 364 DOI 10.17487/RFC2119, March 1997, 365 . 367 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 368 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 369 May 2017, . 371 9.2. Informative References 373 [I-D.ietf-sfc-oam-framework] 374 Aldrin, S., Krishnan, R., Akiya, N., Pignataro, C., and A. 375 Ghanwani, "Service Function Chaining Operation, 376 Administration and Maintenance Framework", draft-ietf-sfc- 377 oam-framework-01 (work in progress), February 2016. 379 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 380 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 381 DOI 10.17487/RFC5226, May 2008, 382 . 384 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 385 Chaining (SFC) Architecture", RFC 7665, 386 DOI 10.17487/RFC7665, October 2015, 387 . 389 Authors' Addresses 391 Greg Mirsky 392 ZTE Corp. 394 Email: gregimirsky@gmail.com 396 Wei Meng 397 ZTE Corporation 398 No.50 Software Avenue, Yuhuatai District 399 Nanjing 400 China 402 Email: meng.wei2@zte.com.cn,vally.meng@gmail.com 403 Bhumip Khasnabish 404 ZTE TX, Inc. 405 55 Madison Avenue, Suite 160 406 Morristown, New Jersey 07960 407 USA 409 Email: bhumip.khasnabish@ztetx.com 411 Cui Wang 413 Email: lindawangjoy@gmail.com