idnits 2.17.1 draft-ietf-sfc-oam-framework-01.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 12 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 18, 2016) is 2989 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.ietf-sfc-archiecture' is mentioned on line 79, but not defined == Unused Reference: 'I-D.ietf-sfc-architecture' is defined on line 480, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-sfc-problem-statement-10 == Outdated reference: A later version (-11) exists of draft-ietf-sfc-architecture-09 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force S. Aldrin 2 Internet-Draft Google 3 Intended status: Informational R. Krishnan 4 Expires: August 17, 2016 Dell 5 N. Akiya 6 Big Switch 7 C. Pignataro 8 Cisco Systems 9 A. Ghanwani 10 Dell 12 February 18, 2016 14 Service Function Chaining 15 Operation, Administration and Maintenance Framework 16 draft-ietf-sfc-oam-framework-01 18 Abstract 20 This document provides reference framework for Operations, 21 Administration and Maintenance (OAM) for Service Function 22 Chaining (SFC). 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on August 17, 2016. 47 Copyright Notice 49 Copyright (c) 2014 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction 66 Service Function Chaining (SFC) enables the creation of composite 67 services that consist of an ordered set of Service Functions (SF) 68 that are be applied to packets and/or frames selected as a result of 69 classification. SFC is a concept that provides 70 for more than just the application of an ordered set of SFs to 71 selected traffic; rather, it describes a method for deploying SFs in 72 a way that enables dynamic ordering and topological independence of 73 those SFs as well as the exchange of metadata between participating 74 entities. The foundations of SFC are described in the following 75 documents: 77 o SFC problem statement [I-D.ietf-sfc-problem-statement] 79 o SFC architecture [I-D.ietf-sfc-archiecture] 81 The reader is assumed to familiar with the material in these drafts. 83 This document provides reference framework for Operations, 84 Administration and Maintenance (OAM, [RFC6291]) of SFC. 85 Specifically, this document provides: 87 o In Section 2, an SFC layering model; 89 o In Section 3, aspects monitored by SFC OAM; 91 o In Section 4, functional requirements for SFC OAM; 93 o In Section 5, a gap analysis for SFC OAM. 95 1.1. Document Scope 97 The focus of this document is to provide an architectural framework 98 for SFC OAM, particularly focused on the aspect of the Operations 99 component within OAM. Actual solutions and mechanisms are outside 100 the scope of this document. 102 2. SFC Layering Model 104 Multiple layers come into play for implementing the SFC. These 105 include the service layer at which SFC operates and the underlying 106 Network, Transport, Link, etc., layers. 108 o The service layer, refered to as the "Service Layer" in Figure 1, 109 consists of classifiers and SFs, and uses the 110 transport network, which could be an overlay network, from a 111 classifier to SF and from one SF to the next. 113 o The network overlay transport layer, refer to as the "Network", 114 "Transport" and layers below in Figure 1, extends between the 115 various SFs and is mostly transparent to the SFs themselves. It 116 can leverage various overlay network technologies 117 interconnecting SFs and allows establishment of 118 service function paths (SFPs). 120 o The link layer, refer to as the "Link" in Figure 1, is dependent 121 upon the physical technology used. Ethernet is a popular choice 122 for this layer, but other alternatives are deployed (e.g. POS, 123 DWDM, etc.). 125 o----------------------Service Layer----------------------o 127 +------+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ 128 |Classi|---|SF1|---|SF2|---|SF3|---|SF4|---|SF5|---|SF6|---|SF7| 129 |fier | +---+ +---+ +---+ +---+ +---+ +---+ +---+ 130 +------+ 131 o-N/W Elem 1----o o-N/w Elem 2-o o-N/W Elem 3-o 133 o-----------------o-------------------o---------------o Network 135 o-----------------o-----------------------------------o Transport 137 o--------o--------o--------o--------o--------o--------o Link 139 Figure 1: SFC Layering Example 141 3. Aspects Monitored by SFC OAM 143 SFC operates at the service layer. For the purpose of defining 144 the OAM framework, the following aspects of the SFC must be capable of 145 monitored. 147 1. Service function: 149 SFs may be SFC-aware or SFC-unaware. An SFC-aware SF is one that 150 understands the SFC encapsulation has the SFF component co-resident with 151 the SF sub-component . An SFC-unware SF is one that does not understand 152 the SFC encapsulation (i.e. a legacy SF) and has to be accessed via an 153 separate SFF and potentially an SFC proxy function. 155 In both cases, an SF is accessed through an SFF in the SFC 156 architecture. SFC OAM must be able to monitor the SFF associated 157 with a given SF. 159 2. Service function path: 161 The SFP comprises a set of SFs that may be ordered or unordered. 162 SFC OAM must be capable of monitoring the SFP and the rendered 163 service path (RSP) that may be used by specific packets. 165 3. Classifier: 167 The classifier determines which packets are mapped to an SFP. 168 SFC OAM must be able to monitor the operation of the classifiers. 170 The figure below illustrates the various aspects monitored by SFC OAM. 172 +-SFC +-SFC OAM 173 | OAM | 174 | | _________________________________________ 175 | \ /\ Service Function Chain \ 176 | +------+ \/ \ +---+ +---+ +---+ +---+ +---+ \ 177 +----> |Classi|...(+-> ) |SF1|---|SF2|---|SF4|---|SF6|---|SF7| ) 178 |fier | \ / +-^-+ +---+ +-|-+ +-^-+ +---+ / 179 +----|-+ \/_____|_______________|_______|_________ / 180 | | +-SFCOAM+ 181 +----SFCOAM----+ +---+ +---+ 182 +SFCOAM>|SF3| |SF5| 183 | +-^-+ +-^-+ 184 +------|---+ | | 185 |Controller| +-SFCOAM+ 186 +----------+ 187 Service Function OAM (SFCOAM) 189 Figure 2: Aspects monitored by SFC OAM 191 3.1. Operation and Performance of SFs 193 3.1.1. Monitoring SF Operation 195 One SFC OAM requirement for the SF component is to 196 allow an SFC aware network device to monitor a 197 specific SF. This is accomplished by monitoring the SFF that 198 the SF is attached to. 200 A generalized way to monitor the operation of an SF is beyond the scope 201 of SFC OAM, because the functions provided by the SF are not covered by 202 SFC. SFs typically provide their own tools for monitoring. 204 An optional capability may be provided for an SFF to monitor the 205 operation of its attached SFs and report that on behalf of the SFs. 207 3.1.2. Service Function Performance Measurement 209 A second SFC OAM requirement for SF is to 210 allow an SFC aware network device to check the loss and delay to a 211 specific SF, located on the same or different network 212 devices. 214 3.2. Operation and Performance of SFPs 215 3.2.1. Monitoring SFP Operation 217 SFC OAM must be capable of monitoring one or more SFPs or RSPs that are 218 used to realize the SFC and reporting on connectivity and providing fault 219 isolation. 221 In order to perform service connectivity verification of an SFP, the 222 OAM tools could be initiated from any SFC-aware network device for 223 end-to-end paths, or partial paths terminating on a specific SF, within 224 the SFP. This OAM function is to ensure the SF's chained together has 225 connectivity as it was intended to when SFP was established. 226 Necessary return code(s) should be defined to be sent back in the 227 response to OAM packet, in order to qualify the verification. 229 When ECMP exists at the service layer on a given SFC (e.g. multiple 230 SFPs, or multiple RSPs), there must be an ability to discover and 231 traverse all available paths. 233 3.2.2. Service Function Chain Performance Measurement 235 The ingress of the SFC or an SFC-aware network 236 device must have an ability to perform loss and delay measurements 237 over the SFC as a unit (i.e. end-to-end) or to a 238 specific SF through the SFC. 240 3.3. Monitoring the Classifier 242 A classifier defines a flow and maps incoming traffic to a specific 243 SFC, and it is vital that the classifier is correctly defined and 244 functioning. SFC OAM must be able to test the definition of 245 flows and the mapping functionality to expected SFCs. 247 4. SFC OAM Functions 249 Section 3 described the various aspects monitored by SFC OAM. This 250 section explores the same from the OAM functionality 251 point of view, which many will be applicable to multiple SFC 252 components. 254 Various SFC OAM requirements provides the need for various OAM 255 functions at different layers. Many of the OAM functions at 256 different layers are already defined and in existence. In order to 257 support SFC and SF's, these functions have to be enhanced to operate 258 a single SF to multiple SF's in an SFC and also multiple SFC's. 260 4.1. Connectivity Functions 262 Connectivity is mainly an on-demand function to verify that the 263 connectivity exists between network elements and that the SFs are 264 operational. Ping is a common tool used to perform 265 this function. OAM messages should be encapsulated with necessary 266 SFC header and with OAM markings when testing the SFC component. OAM 267 messages MAY be encapsulated with necessary SFC 268 header and with OAM markings when testing the SF 269 component. Some of the OAM functions performed by connectivity 270 functions are as follows: 272 o Verify the MTU size from a source to the destination SF or through 273 the SFC. This requires the ability for OAM packet to take 274 variable length packet size. 276 o Verify the packet re-ordering and corruption. 278 o Verify the policy of an SFC or SF using OAM packet. 280 o Verification and validating forwarding paths. 282 o Proactively test alternate or protected paths to ensure 283 reliability of network configurations. 285 4.2. Continuity Functions 287 Continuity is a model where OAM messages are sent periodically to 288 validate or verify the reachability to a given SF or through a given 289 SFC. This allows the operator to monitor the network device and to 290 quickly detect failures such as link failures, network failures, 291 SF outages or SFC outages. BFD is one such function which helps 292 in detecting failures quickly. OAM functions supported by continuity 293 check are as follows: 295 o Ability to provision continuity check to a given SF or through a 296 given SFC. 298 o Notifying the failure upon failure detection for other OAM 299 functions to take appropriate action. 301 4.3. Trace Functions 303 Tracing is an important OAM function that allows the operation to 304 trigger an action (ex: response generation) from every transit device 305 on the tested layer. This function is typically useful to gather 306 information from every transit devices or to isolate the failure 307 point towards an SF or through an SFC. Mechanisms must be provided so 308 that the SFC OAM messages may be sent along the same path that a 309 given data packet would follow. Some of the OAM functions supported 310 by trace functions are: 312 o Ability to trigger action from every transit device on the tested 313 layer towards an SF or through an SFC, using TTL or other means. 315 o Ability to trigger every transit device to generate response with 316 OAM code(s) on the tested layer towards an SF or through an SFC, 317 using TTL or other means. 319 o Ability to discover and traverse ECMP paths within an SFC. 321 o Ability to skip un-supported SF's while tracing SF's in an SFC. 323 4.4. Performance Measurement Function 325 Performance management functions involve measuring of packet loss, 326 delay, delay variance, etc. These measurements could be measured 327 pro-actively and on-demand. 329 SFC OAM should provide the ability to test the packet loss 330 for an SFC. In an SFC, there are various SF's chained together. 332 Measuring packet loss is very important function. Using on-demand 333 function, the packet loss could be measured using statistical means. 334 Using OAM packets, the approximation of packet loss for a given SFC 335 could be measured. 337 Delay within an SFC could be measured from the time it takes for a 338 packet to traverse the SFC from ingress SF to egress SF. As the 339 SFC's are generally unidirectional in nature, measurement of one-way 340 delay is important. In order to measure one-way delay, the clocks 341 have to be synchronized using NTP, GPS, etc. 343 Delay variance could also be measured by sending OAM packets and 344 measuring the jitter between the packets passing through the SFC. 346 Some of the OAM functions supported by the performance measurement 347 functions are: 349 o Ability to measure the packet processing delay of a service 350 function or a service function path along an SFC. 352 o Ability to measure the packet loss of a service function or a 353 service function path along an SFC. 355 5. Gap Analysis 357 This Section identifies various OAM functions available at different 358 levels. It will also identify various gaps 359 within the existing toolset, to perform OAM function on an SFC. 361 5.1. Existing OAM Functions 363 There are various OAM tool sets available to perform OAM function and 364 network layer, protocol layers and link layers. These OAM functions 365 could validate some of the network overlay transport. Tools like 366 ping and trace are in existence to perform connectivity check and 367 tracing intermediate hops in a network. These tools support 368 different network types like IP, MPLS, TRILL etc. There is also an 369 effort to extend the tool set to provide connectivity and continuity 370 checks within overlay networks. BFD is another tool which helps in 371 detection of data forwarding failures. 373 Table 1: OAM Tool GAP Analysis 375 +----------------+--------------+-------------+--------+------------+ 376 | Layer | Connectivity | Continuity | Trace | Performance| 377 +----------------+--------------+-------------+--------+------------+ 378 | N/W Overlay | Ping | BFD, NVo3 | Trace | IPPM | 379 +----------------+--------------+-------------+--------+------------+ 380 | SF | None + None + None + None | 381 +----------------+--------------+-------------+--------+------------+ 382 | SFC | None + None + None + None | 383 +----------------+--------------+-------------+--------+------------+ 385 5.2. Missing OAM Functions 387 As shown in Table 1, OAM functions for SFC are not yet standardized. 388 Hence, there are no standards-based tools available to monitor the 389 various components identified in Section 3. 391 5.3. Required OAM Functions 393 Primary OAM functions exist for network, transport, link and other 394 layers. Tools like ping, trace, BFD, etc., exist in order to perform 395 these OAM functions. Configuration, orchestration and manageability 396 of SF and SFC could be performed using CLI, Netconf etc. 398 For configuration, manageability and orchestration, providing data 399 and information models for SFC is very much essential. With 400 virtualized SF and SFC, manageability of these functions has to be 401 done programmatically. 403 SFC OAM must provide tools that operate through various types of 404 SFs including: 406 o Transparent SFs: These SFs typically do not make any 407 modifications to the packet. In such cases, the SFF may be able 408 to process OAM messages. 410 o SFs that modify the packet: These SFs modify packet 411 fields. Certain SFs may modify only the headers 412 corresponding to the network over which it is transported, e.g. 413 the MAC headers or overlay headers. In other cases, the IP header 414 of the application's packet may be modified, e.g. NAT. In yet 415 other cases, the application session itself may be terminated and 416 a new session initiated, e.g. a load balancer that offers HTTPS 417 termination. 419 6. Open Issues 421 - Add more details on performance measurement. 423 - Call out which OAM functions can be achieved by protocol design vs 424 requiring synthetic traffic. 426 7. Security Considerations 428 SFC OAM must provide mechanisms for: 430 o Preventing usage of OAM channel for DDOS attacks. 432 o Preventing leakage of OAM packets meant for a given SFC beyond 433 that SFC. 435 o Preventing leakage of information about an sFC beyond its 436 administrative domain. 438 7. IANA Considerations 440 No action is required by IANA for this document. 442 8. Acknowledgements 444 TBD 446 9. Contributing Authors 448 Pedro A. Aranda Gutierrez 449 Telefonica I+D 450 Email: pedroa.aranda@tid.es 452 Diego Lopez 453 Telefonica I+D 454 Email: diego@tid.es 456 Joel Halpern 457 Ericsson 458 Email: joel.halpern@ericsson.com 460 Sriganesh Kini 461 Ericsson 462 Email: sriganesh.kini@ericsson.com 464 Andy Reid 465 BT 466 Email: andy.bd.reid@bt.com 468 10. References 470 10.1. Normative References 472 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 473 Requirement Levels", BCP 14, RFC 2119, March 1997. 475 [I-D.ietf-sfc-problem-statement] 476 Quinn, P. and T. Nadeau, "Service Function Chaining 477 Problem Statement", draft-ietf-sfc-problem-statement-10 478 (work in progress), August 2014. 480 [I-D.ietf-sfc-architecture] 481 Halpern J. and C. Pignataro, "Service Function Chaining 482 (SFC) Architecture", draft-ietf-sfc-architecture-09 483 (work in progress), June 2015. 485 10.2. Informative References 487 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 488 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 489 Acronym in the IETF", BCP 161, RFC 6291, June 2011. 491 Authors' Addresses 493 Sam K. Aldrin 494 Google 495 Email: aldrin.ietf@gmail.com 497 Ram Krishnan 498 Dell 499 Email: ramkri123@gmail.com 501 Nobo Akiya 502 Big Switch 503 Email: nobo.akiya.dev@gmail.com 505 Carlos Pignataro 506 Cisco Systems 507 Email: cpignata@cisco.com 509 Anoop Ghanwani 510 Dell 511 Email: anoop@alumni.duke.edu