idnits 2.17.1 draft-jxc-sfc-fm-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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 113 has weird spacing: '...provide one ...' == Line 232 has weird spacing: '...ge Type indic...' -- The document date (July 4, 2014) is 3584 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: 'RFC2119' is mentioned on line 98, but not defined == Unused Reference: 'I-D.jiang-sfc-arch' is defined on line 478, but no explicit reference was found in the text == Unused Reference: 'I-D.quinn-sfc-arch' is defined on line 485, but no explicit reference was found in the text -- No information found for draft-jiang-sfc-arch - is the name correct? -- No information found for draft-niu-sfc-mechanism - is the name correct? -- No information found for draft-quinn-sfc-arch - is the name correct? Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Working Group Y. Jiang 2 W. Xu 3 Internet Draft Huawei 4 Z. Cao 5 Intended status: Standards Track China Mobile 7 Expires: January 2015 July 4, 2014 9 Fault Management in Service Function Chaining 10 draft-jxc-sfc-fm-00.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on January 4, 2015. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Abstract 51 SFC provides a flexible and agile approach to service innovation, but 52 whether the SFC path is constructed as expected, whether the chaining 53 is functioning correctly still needs to be verified. This document 54 discusses fault management requirements in SFC and provides a fault 55 management solution for service function chaining. 57 Table of Contents 59 1. Introduction .............................................. 2 60 1.1. Conventions used in this document ...................... 3 61 1.2. Terminology ............................................ 3 62 1.3. SFC OAM Requirements ................................... 4 63 2. Packet Format ............................................. 5 64 3. Theory of Operation ....................................... 8 65 3.1. Continuity Check and Connectivity Verification of SFC .. 8 66 3.1.1. MEP sending an SFC CC-CV packet ..................... 8 67 3.1.2. MEP terminating an SFC CC-CV packet ................. 9 68 3.2. SFC Route Tracing ...................................... 9 69 3.2.1. MEP sending an SFC Trace Request ................... 11 70 3.2.2. SFE/SFF processing an SFC Trace Route Request ...... 11 71 3.2.3. Service Function treating an SFC Trace Request ..... 11 72 3.2.4. MEP receiving an SFC Trace Reply ................... 11 73 4. Security Considerations .................................. 12 74 5. IANA Considerations ...................................... 12 75 6. References ............................................... 12 76 6.1. Normative References .................................. 12 77 6.2. Informative References ................................ 12 78 7. Acknowledgments .......................................... 13 80 1. Introduction 82 This document discusses Operations, Administration and Maintenance 83 (OAM), specifically, fault management requirements for Service 84 Function Chaining (SFC), and further provides a solution that can be 85 used to detect data plane failures in SFC Paths. 87 A requisite of SFC OAM is that SFC OAM messages must follow the same 88 data path as normal SFC packets would traverse. SFC OAM request and 89 reply messages are used primarily to validate the SFC data plane, and 90 may further be used to verify the SFC data plane against the SFC 91 control plane. 93 1.1. Conventions used in this document 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 1.2. Terminology 101 Maintenance Entity Group (MEG): The set of one or more maintenance 102 entities that maintain and monitor a section or a transport path in 103 an OAM domain. 105 MEP: MEG End Point, an OAM end point capable of initiating (source 106 MEP) and terminating (sink MEP) OAM packets for fault management and 107 performance monitoring. 109 MIP: MEG Intermediate Point, an OAM intermediate point terminates and 110 processes OAM packets that are sent to this particular MIP and may 111 generate OAM packets in reaction to received OAM packets. 113 Service Function (SF): a logical entity which can provide one or 114 more service processing functions for packets/frames such as firewall, 115 DPI (Deep Packet Inspection), LI (Lawful Intercept) and etc. Usually 116 these processing functions are computation intensive. This entity may 117 also provide packet/frame encapsulation/decapsulation capability. 119 Service Forwarding Entity (SFE): a logical entity which forwards 120 packets/frames to one or more SFs in a same service chain. Optionally, 121 it provides mapping, insertion and removal of header(s) in 122 packets/frames. Note service forwarding path may not be the shortest 123 path to its destination. 125 Service Function Forwarder (SFF): A service function forwarder is 126 responsible for delivering traffic received from the SFC network 127 forwarder to one or more connected service functions via 128 information carried in the SFC encapsulation. 130 Service Chaining Header: a header in front of packet, added by an 131 SFE/SFF. SFE/SFF uses service chaining header information to forward 132 service chaining packet. 134 Service Chaining Packet: an original packet added with a service 135 chaining header. 137 1.3. SFC OAM Requirements 139 The following SFC OAM requirements MUST be supported: 141 (R1) SFC OAM MUST allow for continuity check between SFEs/SFFs. 143 (R2) SFC OAM MUST allow for connectivity verification between 144 SFEs/SFFs. 146 (R3) SFC OAM MUST support trace routing in a service function path. 148 (R4) SFC OAM MUST support connectivity verification between SFs in an 149 SFC chain. 151 (R5) SFC OAM MUST support performance measurements in SFs and 152 SFEs/SFFs. 154 (R6) SFC OAM MUST support monitoring of unidirectional and bi- 155 directional SFC path. 157 (R7) SFC OAM MUST support fate sharing of SFC OAM packets and SFC 158 service packets on the same SFC path (congruent path). 160 Since control plane is not a prerequisite for SFC, we cannot resort 161 to control plane hello session. Furthermore, OAM packets need to be 162 transported on the same data path as the SFC packets, so that any 163 data plane failure can be identified. 165 Therefore, there is a need to provide an OAM tool that would enable 166 users to detect failures in the SFC data plane, and a mechanism to 167 isolate and identify faults. 169 This document discusses the fault management problem in SFC. The 170 basic idea is to verify that packets in a particular Service Function 171 Chain actually passing through the SFEs/SFFs and SFs along the 172 respective SFC path. 174 It is proposed that this test be carried out by sending an OAM 175 message (called an "SFC trace request message") across an SFC path. 176 The SFC trace request message carries the SFC identifier whose SFC 177 path is being verified. This SFC OAM request message is forwarded on 178 the SFC path just like any SFC data packet belonging to that Service 179 Function Chain. 181 The OAM message is processed by each SFE/SFF along the SFC, and the 182 SFE/SFF will respond with an SFC trace Reply message, carrying 183 information such as the previous SF identifier and its position in 184 the SFC. 186 2. Packet Format 188 OAM messages are encapsulated in an SFC packet in the following 189 format (they should not be combined with any SFC data traffic in the 190 same SFC packet): 192 +------------+-------------+ 193 | SFC Header | OAM message | 194 +------------+-------------+ 195 Where SFC header is formatted as in Figure 1: 197 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 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 |Version|O| other parameters | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | other parameters | 202 . | 203 . | 204 . | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 Figure 1 SFC header 208 O: The O flag indicates that an SFC OAM message is following the SFC 209 header. 211 An SFC OAM message is depicted in Figure 2. 213 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 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Version | Message Type | Reserved | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Originator Handle | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Sequence Number | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | TLVs | 222 . . 223 . . 224 . . 225 | | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 Figure 2 SFC OAM message 229 o Version: version of SFC OAM message. This field is 8 bits long, 230 and current version is set to 0x01. 232 o Message Type indicate the type of SFC OAM message. 234 The SFC OAM message has the following types: 236 Value Meaning 238 ----- ------- 240 1 continuity check message 242 2 trace request message 244 3 trace reply message 246 o Originator Handle: The Originator Handle is filled in by the 247 packet original sender. 249 o Sequence Number: The Sequence Number is assigned by the sender of 250 the SFC request message and can be used to track the correct reply 251 message. 253 o The Sending Timestamp is the time-of-day (in seconds and 254 microseconds, according to the sender's clock) when the SFC OAM 255 request is sent. The Receiving Timestamp in an SFC OAM reply 256 message is the time-of-day (according to the receiver's clock) 257 that the corresponding request was received. 259 o TLVs (Type-Length-Value) have the following format: 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Type | Length | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Value | 266 . . 267 . . 268 . . 269 | | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 Figure 3 SFC OAM TLVs 273 Types of SFC OAM TLV will be defined in the next revision; Length is 274 the length of the Value field in octets; and Value field is variable 275 depending on its Type (it is zero padded to align to a 4-octet 276 boundary). 278 3. Theory of Operation 280 In order to describe SFC OAM in an abstract way, we reuse some 281 nomenclatures in MPLS WG. SFC OAM operates in the context of 282 Maintenance Entities (MEs) that define a relationship between two 283 points of a service function path to which maintenance and monitoring 284 operations apply. The two points that define a maintenance entity are 285 called Maintenance Entity Group End Points (MEPs). 287 An abstract reference model for an ME is illustrated in Figure 4 288 below: 290 +-+ +-+ +-+ +-+ 291 |A|----|B|----|C|----|D| 292 +-+ +-+ +-+ +-+ 293 Figure 4 SFC OAM Reference Model 295 In Figure 4, node A can be a classifier or an entry SFE/SFF, node D 296 can be an exit SFE/SFF, and node B and C can be any SFE/SFF or SF 297 (with the restriction that any two SFs cannot be directly connected 298 in SFC forwarding layer) on the SFC path. 300 In general, MEG End Points (MEPs) are the source and sink points of a 301 MEG for SFC OAM. 303 3.1. Continuity Check and Connectivity Verification of SFC 305 Proactive Continuity Check (CC) can be used to detect a loss of 306 continuity defect between two MEPs in a MEG. 308 Proactive Connectivity Verification (CV) can be used to detect an 309 unexpected connectivity defect between two MEGs or unexpected 310 connectivity within the MEG with an unexpected MEP. 312 BFD can also be used as a tool of proactive CC & CV in SFC, where BFD 313 Control packets must be sent along the same path as the monitored SFC 314 path. 316 3.1.1. MEP sending an SFC CC-CV packet 318 A source MEP can proactively sends CC-CV packets periodically to its 319 sink peer MEP. An SFC CC-CV packet is an SFC CC-CV message 320 encapsulated with an SFC Header. The SFC header is set as described 321 in [I-D.niu-sfc-mechanism] and its flag O MUST be set to 1. 323 The SFC OAM message is set as follows: 325 - The message type MUST be set to 1. 327 - The Sender's Handle is set by the original sender, and MUST be set 328 with the sender's identifier. 330 - The Sequence Number is set with a random value. 332 3.1.2. MEP terminating an SFC CC-CV packet 334 A sink MEP detects a loss of continuity defect when it fails to 335 receive proactive CC-V OAM packets from the source MEP for a 336 consecutive time. 338 When CC-V packets are received by a sink MEP, it is parsed. If any 339 mis-connectivity defect is detected, a warning should be raised and 340 fault management system should be notified of the detected defects. 342 3.2. SFC Route Tracing 344 According to the SFC architecture described in figure 2 of [I-D. 345 jiang-sfc-arch] and figure 2 of [I-D. quinn-sfc-arch], SFC can be 346 categorized into two abstraction layers, that is, service function 347 layer and SFC forwarding layer. In the service function layer, a 348 service function chain actually is a service function graph, where a 349 service function is connected to another service function one by one 350 in sequence. In the SFC forwarding layer, service functions are 351 further attached to SFE/SFF nodes thus form a more detailed 352 forwarding graph. As defects can be located on either service 353 functions or SFE/SFF nodes, it is critical to trace route both 354 service functions and SFE/SFF nodes to detect and isolate any defects 355 for SFC. 357 In order to trace route of a service function chain, different layers 358 of service function chain can be monitored: 360 o Service-function-layer, that is, only SF identifiers can be set as 361 the destination MEP in the trace route request and response 362 messages. The trace routing operation collects all the SFs' 363 identifiers along an SFC path. By comparing this SF list with the 364 pre-configured service function graph, an operator could determine 365 whether there is any fault in the SF connectivity and locate the 366 defect on an SF when there are any of them. 368 o SFC-forwarding-layer, that is, both SF identifiers and SFE/SFF can 369 be set as the destination MEP in the trace route request and 370 response messages. The trace routing operation collects all the 371 SFs' identifiers and SFE/SFF identifiers along an SFC path. By 372 comparing this SF and SFE/SFF list with the pre-configured SFC 373 forwarding graph, an operator could determine whether there is any 374 fault in the forwarding layer and locate the defect on an SFE/SFF 375 or an SF. 377 Furthermore, two different mechanisms may be used to trace route a 378 service function chain: 380 o TTL mechanism 382 Similar to the IP trace route, the detection node launches a number 383 of trace request messages in sequence to detect the fault in a 384 specific path, the TTL of request message is set successively to 1, 385 2, ..., and so on. 387 The trace route request will pass the SFs along the service function 388 graph, and each SF will decrease the TTL value by 1. 390 A trace route reply message will be generated and send back to the 391 launcher when the resulted TTL is equal to zero. 393 In this way, the launcher of trace routing can get the list of SFs 394 that the trace route request message passes by parsing all the trace 395 route reply messages, and isolate the fault location if there is any. 397 o record route mechanism 399 The detection node launches a single trace route request message, and 400 this message is transported over the specific SFC path. 402 When the trace route request message is received by an SF in the SFC 403 path, the SF adds its SF identifier to the end of an SF list carried 404 in the message. Moreover, a trace route reply message should be 405 generated and sent back to the launcher, and the new record route SF 406 list MUST be copied to the trace route reply message. 408 In this way, the launcher of trace routing can get the list of SFs 409 that the trace route request message passes by parsing all the trace 410 route reply messages, and isolate the fault location if there is any. 412 3.2.1. MEP sending an SFC Trace Request 414 In general, MEG End Points (MEPs) are the source and sink points of a 415 MEG for SFC OAM. An MEP initiates a trace route request packet to 416 detect and track any fault in a Service Function Chain. 417 An SFC Trace route request packet is an SFC trace route request 418 message encapsulated with an SFC Header. The SFC header is set as 419 described in [I-D.niu-sfc-mechanism] and flag O MUST be set to 1. 420 The SFC OAM message is further set as follows: 421 - The message type MUST be set to 2. 422 - The Sender's Handle MUST be set to the sender's identifier. 423 - The Receiver's Handle can be set to the exit SFE/SFF's identifier. 425 3.2.2. SFE/SFF processing an SFC Trace Route Request 427 When an SFE/SFF receives a trace route request packet with O flag 428 being set in SFC header, it firstly adds its identifier to the end of 429 the record route list in the trace request. It then performs service 430 forwarding function, and sends the new trace route request packet to 431 the next SF or next SFE/SFF. 433 Furthermore, the SFE/SFF sends a trace reply packet back to the 434 source MEP with a copy of the new record route SF list. 436 3.2.3. Service Function treating an SFC Trace Request 438 An SF can only be configured as an MIP in an MEG of SFC. When an SF 439 (being an MIP) receives a trace request packet with OAM flag being 440 set in SFC header from an SFE/SFF, it only sends it back to the 441 SFE/SFF transparently. 443 3.2.4. MEP receiving an SFC Trace Reply 445 An MEP should only process an SFC trace reply packet in response to 446 an SFC trace request that it has sent. Thus, upon receipt of an SFC 447 trace reply packet, an MEP should try to match the trace reply packet 448 with a trace request that it has previously sent, by checking the 449 corresponding path identifier and Sequence Number in the SFC OAM 450 packets. If no match is found, then the MEP MUST drop the trace reply 451 packet silently. 453 Since each SFE/SFF in the SFC path will send a trace reply packet 454 when the trace request packet passes it, a source MEP will receive a 455 sequence of trace reply packets from SFEs/SFFs (other than the MEP 456 itself) along the SFC path. Thus, the source MEP can get the full 457 service topology and SFC path if there is no defect in the SFC data 458 plane, and could detect and locate the data plane defects if there 459 are any of them. 461 4. Security Considerations 463 It will be considered in a future revision. 465 5. IANA Considerations 467 It will be considered in a future revision. 469 6. References 471 6.1. Normative References 473 6.2. Informative References 475 [sfc-ps] P. Quinn, and T. Nadeau; Service Function Chaining Problem 476 Statement; April 2014; Work in Progress 478 [I-D.jiang-sfc-arch] Y. Jiang, H. Li; An Architecture of Service 479 Function Chaining; February 2014; Work in Progress 481 [I-D.niu-sfc-mechanism] L. Niu, H. Li, Y. Jiang; A Service Function 482 Chaining Header and its Mechanism; March 2014; Work in 483 Progress 485 [I-D.quinn-sfc-arch] P. Quinn, J. Halpern; Service Function Chaining 486 (SFC) Architecture; May 2014; Work in Progress 488 7. Acknowledgments 490 TBD 492 Authors' Addresses 494 Yuanlong Jiang 495 Huawei Technologies Co., Ltd. 496 Bantian, Longgang district 497 Shenzhen 518129, China 498 Email: jiangyuanlong@huawei.com 500 Weiping Xu 501 Huawei Technologies Co., Ltd. 502 Bantian, Longgang district 503 Shenzhen 518129, China 504 Email: xuweiping@huawei.com 506 Zhen Cao 507 China Mobile 508 Xuanwumenxi Ave, Xuanwu District 509 Beijing 100053, China 510 Email: caozhen@chinamobile.com