idnits 2.17.1 draft-aldrin-sfc-oam-framework-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 2, 2014) is 3586 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 460, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-sfc-problem-statement-07 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Aldrin 3 Internet-Draft Huawei Technologies 4 Intended status: Informational C. Pignataro 5 Expires: January 3, 2015 N. Akiya 6 Cisco Systems 7 July 2, 2014 9 Service Function Chaining 10 Operations, Administration and Maintenance Framework 11 draft-aldrin-sfc-oam-framework-00 13 Abstract 15 This document provides reference framework for Operations, 16 Administration and Maintenance (OAM) of Service Function Chaining 17 (SFC). 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 30, 2014. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Document Scope . . . . . . . . . . . . . . . . . . . . . . 3 55 2. SFC Layering Model . . . . . . . . . . . . . . . . . . . . . . 3 56 3. SFC OAM Components . . . . . . . . . . . . . . . . . . . . . . 4 57 3.1. Service Function Component . . . . . . . . . . . . . . . . 5 58 3.1.1. Service Function Availability . . . . . . . . . . . . 5 59 3.1.2. Service Function Performance Measurement . . . . . . . 6 60 3.2. Service Function Chain Component . . . . . . . . . . . . . 6 61 3.2.1. Service Function Chain Availability . . . . . . . . . 6 62 3.2.2. Service Function Chain Performance Measurement . . . . 6 63 3.3. Classifier Component . . . . . . . . . . . . . . . . . . . 7 64 4. SFC OAM Functions . . . . . . . . . . . . . . . . . . . . . . 7 65 4.1. Connectivity Functions . . . . . . . . . . . . . . . . . . 7 66 4.2. Continuity Functions . . . . . . . . . . . . . . . . . . . 8 67 4.3. Trace Functions . . . . . . . . . . . . . . . . . . . . . 8 68 4.4. Performance Measurement Function . . . . . . . . . . . . . 8 69 5. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 5.1. Existing OAM Functions . . . . . . . . . . . . . . . . . . 9 71 5.2. Missing OAM Functions . . . . . . . . . . . . . . . . . . 10 72 5.3. Required OAM Functions . . . . . . . . . . . . . . . . . . 10 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 78 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 81 1. Introduction 83 Service Function Chaining (SFC) enables the creation of composite 84 services that consist of an ordered set of Service Functions (SF) 85 that must be applied to packets and/or frames selected as a result of 86 classification. Service Function Chaining is a concept that provides 87 for more than just the application of an ordered set of SFs to 88 selected traffic; rather, it describes a method for deploying SFs in 89 a way that enables dynamic ordering and topological independence of 90 those SFs as well as the exchange of metadata between participating 91 entities. Foundations of the SFC are described in below documents: 93 o [I-D.ietf-sfc-problem-statement]: SFC problem statement. 95 o Various individual drafts 97 This document provides reference framework for Operations, 98 Administration and Maintenance (OAM, [RFC6291]) of the SFC. 99 Specifically, this document provides: 101 o In Section 2, an SFC layering model; 103 o In Section 3, involved components within the SFC layer; 105 o In Section 4, functional requirements for the SFC OAM; 107 o In Section 5, an OAM gap analysis. 109 1.1. Document Scope 111 The focus of this document is to provide an architectural framework 112 for the SFC OAM, particularly focused on the aspect of the Operation 113 portion of the OAM. Actual solutions and mechanisms are outside the 114 scope of this document. 116 2. SFC Layering Model 118 Multiple layers come into play for implementing the SFC. These 119 include the service layer at SFC layer and the underlying Network, 120 Transport, Link, etc., layers. 122 o The service layer, refer to as the "Service Layer" in Figure 1, 123 consists of classifiers and service functions, and uses the 124 overlay network reach from a classifier to service functions and 125 service functions to service functions. 127 o The network overlay transport layer, refer to as the "Network", 128 "transport" and layers below in Figure 1, extends in between 129 various service functions and is mostly transparent to the service 130 functions. It leverages various overlay network technologies 131 interconnecting service functions and allows establishing of 132 service function paths. 134 o The link layer, refer to as the "Link" in Figure 1, is dependent 135 upon the physical technology used. Ethernet is a popular choice 136 for this layer, but other alternatives are deployed (e.g. POS, 137 DWDM etc...). 139 o----------------------Service Layer----------------------o 141 +------+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ 142 |Classi|---|SF1|---|SF2|---|SF3|---|SF4|---|SF5|---|SF6|---|SF7| 143 |fier | +---+ +---+ +---+ +---+ +---+ +---+ +---+ 144 +------+ 145 o-N/W Elem 1----o o-N/w Elem 2-o o-N/W Elem 3-o 147 o-----------------o-------------------o---------------o Network 149 o-----------------o-----------------------------------o Transport 151 o--------o--------o--------o--------o--------o--------o Link 153 Figure 1: SFC Layering Example 155 3. SFC OAM Components 157 The SFC operates at the service layer. For the purpose of defining 158 the OAM framework, the service layer is broken up into three distinct 159 components. 161 1. Service function component: A function providing a specific 162 service. OAM solutions for this component are to test the 163 service functions from any SFC aware network devices (i.e. 164 classifiers, controllers, other service nodes). 166 2. Service function chain component: An ordered set of service 167 functions. OAM solution for this component are to test the 168 service function chains and the service function paths. 170 3. Classifier component: A policy that describes the mapping from 171 flows to service function chains. OAM solutions for this 172 component are to test the validity of the classifiers. 174 Below figure illustrates an example where OAM for the three defined 175 components are used within the SFC environment. 177 +-Classifier +-Service Function Chain OAM 178 | OAM | 179 | | _________________________________________ 180 | \ /\ Service Function Chain \ 181 | +------+ \/ \ +---+ +---+ +---+ +---+ +---+ \ 182 +----> |Classi|...(+-> ) |SF1|---|SF2|---|SF4|---|SF6|---|SF7| ) 183 |fier | \ / +-^-+ +---+ +-|-+ +-^-+ +---+ / 184 +----|-+ \/_____|_______________|_______|_________ / 185 | | +-SF_OAM+ 186 +----SF_OAM----+ +---+ +---+ 187 +SF_OAM>|SF3| |SF5| 188 | +-^-+ +-^-+ 189 +------|---+ | | 190 |Controller| +-SF_OAM+ 191 +----------+ 192 Service Function OAM (SF_OAM) 194 Figure 2: SFC OAM for Three Components 196 It is expected that multiple SFC OAM solutions will be defined, many 197 targeting one specific component of the service layer. However, it 198 is critical that SFC OAM solutions together provide the coverage of 199 all three SFC OAM components: the service function component, the 200 service function chain component and the classifier component. 202 3.1. Service Function Component 204 3.1.1. Service Function Availability 206 One SFC OAM requirement for the service function component is to 207 allow an SFC aware network device to check the availability to a 208 specific service function, located on the same or different network 209 devices. Service function availability is an aspect which raises an 210 interesting question. How does one determine that a service function 211 is available? On one end of the spectrum, one might argue that a 212 service function is sufficiently available if the service node 213 (physical or virtual) hosting the service function is available and 214 is functional. On the other end of the spectrum, one might argue 215 that the service function availability can only be concluded if the 216 packet, after passing through the service function, was examined and 217 verified that the packet got expected service applied. 219 The former approach will likely not provide sufficient confidence to 220 the actual service function availability, i.e. a service node and a 221 service function are two different entities. The latter approach is 222 capable of providing an extensive verification, but comes with a 223 cost. Some service functions make direct modifications to packets, 224 while other service functions do not make any modifications to 225 packets. Additionally, purpose of some service functions is to, 226 conditionally, drop packets intentionally. In such case, packets 227 will not be coming out from the service function. The fact is that 228 there are many flavors of service functions available, and many more 229 flavors of service functions will likely be introduced in future. 230 Even a given service function may introduce a new functionality 231 within a service function (ex: a new signature in a firewall). The 232 cost of this approach is that verifier functions will need to be 233 continuously modified to "keep up" with new services coming out: lack 234 of extendibility. 236 This framework document provides a RECOMMENDED architectural model 237 where generalized approach is taken to verify that a service function 238 is sufficiently available. TBD - details will be provided in a later 239 revision. 241 3.1.2. Service Function Performance Measurement 243 Second SFC OAM requirement for the service function component is to 244 allow an SFC aware network device to check the loss and delay of a 245 specific service function, located on the same or different network 246 devices. TBD - details will be provided in a later revision. 248 3.2. Service Function Chain Component 250 3.2.1. Service Function Chain Availability 252 Verifying an SFC is a complicated process as the SFC could be 253 comprised of varying SF's. Thus, SFC requires the OAM layer to 254 perform validation and verification of SF's within an SFC Path, as 255 well as connectivity and fault isolation. 257 In order to perform service connectivity verification of an SFC, the 258 OAM could be initiated from any SFC aware network devices for end-to- 259 end paths or partial path terminating on a specific SF within the 260 SFC. This OAM function is to ensure the SF's chained together has 261 connectivity as it is intended to when SFC was established. Necessary 262 return code should be defined to be sent back in the response to OAM 263 packet, in order to qualify the verification. 265 When ECMP exists at the service layer on a given SFC, there must be 266 an ability to discover and traverse all available paths. 268 TBD - further details will be provided in a later revision. 270 3.2.2. Service Function Chain Performance Measurement 272 The ingress of the service function chain or an SFC aware network 273 device must have an ability to perform loss and delay measurements 274 over the service function chain as a unit (i.e. end-to-end) or to a 275 specific service function through the SFC. 277 3.3. Classifier Component 279 A classifier defines a flow and maps incoming traffic to a specific 280 SFC, and it is vital that the classifier is correctly defined and 281 functioning. The SFC OAM must be able to test the definition of 282 flows and the mapping functionality to expected SFCs. 284 4. SFC OAM Functions 286 Section 3 described SFC OAM operations required on each SFC 287 component. This section explores the same from the OAM functionality 288 point of view, which many will be applicable to multiple SFC 289 components. 291 Various SFC OAM requirements provides the need for various OAM 292 functions at different layers. Many of the OAM functions at 293 different layers are already defined and in existence. In order to 294 support SFC and SF's, these functions have to be enhanced to operate 295 a single SF to multiple SF's in an SFC and also multiple SFC's. 297 4.1. Connectivity Functions 299 Connectivity is mainly an on-demand function to verify that the 300 connectivity exists between network elements and the availability 301 exists to service functions. Ping is a common tool used to perform 302 this function. OAM messages should be encapsulated with necessary 303 SFC header and with OAM markings when testing the service function 304 chain component. OAM messages MAY be encapsulated with necessary SFC 305 header and with OAM markings when testing the service function 306 component. Some of the OAM functions performed by connectivity 307 functions are as follows: 309 o Verify the MTU size from a source to the destination SF or through 310 the SFC. This requires the ability for OAM packet to take 311 variable length packet size. 313 o Verify the packet re-ordering and corruption. 315 o Verify the policy of an SFC or SF using OAM packet. 317 o Verification and validating forwarding paths. 319 o Proactively test alternate or protected paths to ensure 320 reliability of network configurations. 322 4.2. Continuity Functions 324 Continuity is a model where OAM messages are sent periodically to 325 validate or verify the reachability to a given SF or through a given 326 SFC. This allows monitor network device to quickly detect failures 327 like link failures, network failures, service function outages or 328 service function chain outages. BFD is one such function which helps 329 in detecting failures quickly. OAM functions supported by continuity 330 check are as follows: 332 o Ability to provision continuity check to a given SF or through a 333 given SFC. 335 o Notifying the failure upon failure detection for other OAM 336 functions to take appropriate action. 338 4.3. Trace Functions 340 Tracing is an important OAM function that allows the operation to 341 trigger an action (ex: response generation) from every transit device 342 on the tested layer. This function is typically useful to gather 343 information from every transit devices or to isolate the failure 344 point towards an SF or through an SFC. Some of the OAM functions 345 supported by trace functions are: 347 o Ability to trigger action from every transit device on the tested 348 layer towards an SF or through an SFC, using TTL or other means. 350 o Ability to trigger every transit device to generate response with 351 OAM code(s) on the tested layer towards an SF or through an SFC, 352 using TTL or other means. 354 o Ability to discover and traverse ECMP paths within an SFC. 356 o Ability to skip un-supported SF's while tracing SF's in an SFC. 358 4.4. Performance Measurement Function 360 Performance management functions involve measuring of packet loss, 361 delay, delay variance, etc. These measurements could be measured 362 pro-actively and on-demand. 364 SFC OAM framework should provide the ability to perform packet loss 365 for an SFC. In an SFC, there are various SF's chained together. 366 Measuring packet loss is very important function. Using on-demand 367 function, the packet loss could be measured using statistical means. 368 Using OAM packets, the approximation of packet loss for a given SFC 369 could be measured. 371 Delay within an SFC could be measured from the time it takes for a 372 packet to traverse the SFC from ingress SF to egress SF. As the 373 SFC's are generally unidirectional in nature, measurement of one-way 374 delay is important. In order to measure one-way delay, the clocks 375 have to be synchronized using NTP, GPS, etc. 377 Delay variance could also be measured by sending OAM packets and 378 measuring the jitter between the packets passing through the SFC. 380 Some of the OAM functions supported by the performance measurement 381 functions are: 383 o Ability to measure the packet processing delay of a service 384 function or a service function path along an SFC. 386 o Ability to measure the packet loss of a service function or a 387 service function path along an SFC. 389 5. Gap Analysis 391 This Section identifies various OAM functions available at different 392 levels. It will also identify various gaps, if not all, existing 393 within the existing toolset, to perform OAM function on an SFC. 395 5.1. Existing OAM Functions 397 There are various OAM tool sets available to perform OAM function and 398 network layer, protocol layers and link layers. These OAM functions 399 could validate some of the network overlay transport. Tools like 400 ping and trace are in existence to perform connectivity check and 401 tracing intermediate hops in a network. These tools support 402 different network types like IP, MPLS, TRILL etc. There is also an 403 effort to extend the tool set to provide connectivity and continuity 404 checks within overlay networks. BFD is another tool which helps in 405 detection of data forwarding failures. 407 +----------------+--------------+-------------+--------+------------+ 408 | Layer | Connectivity | Continuity | Trace | Performance| 409 +----------------+--------------+-------------+--------+------------+ 410 | N/W Overlay | Ping | BFD, NVo3 | Trace | IPPM | 411 +----------------+--------------+-------------+--------+------------+ 412 | SF | None + None + None + None | 413 +----------------+--------------+-------------+--------+------------+ 414 | SFC | None + None + None + None | 415 +----------------+--------------+-------------+--------+------------+ 416 Figure 3: OAM Tool GAP Analysis 418 5.2. Missing OAM Functions 420 As shown in Figure 3, OAM functions for SFC are not standardized yet. 421 Hence, there are no standard based tools available to verify SF and 422 SFC. 424 5.3. Required OAM Functions 426 Primary OAM functions exist for network, transport, link and other 427 layers. Tools like ping, trace, BFD, etc., exist in order to perform 428 these OAM functions. Configuration, orchestration and manageability 429 of SF and SFC could be performed using CLI, Netconf etc. 431 For configuration, manageability and orchestration, providing data 432 and information models for SFC is very much essential. With 433 virtualized SF and SFC, manageability of these functions has to be 434 done programmatically. 436 6. Security Considerations 438 SFC and SF OAM must provide mechanisms for: 440 o Preventing usage of OAM channel for DDOS attacks. 442 o OAM packets meant for a given SFC should not get leaked beyond 443 that SFC. 445 o Prevent OAM packets to leak the information of an SFC beyond its 446 administrative domain. 448 7. IANA Considerations 450 No action is required by IANA for this document. 452 8. Acknowledgements 454 TBD 456 9. References 458 9.1. Normative References 460 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 461 Requirement Levels", BCP 14, RFC 2119, March 1997. 463 9.2. Informative References 465 [I-D.ietf-sfc-problem-statement] 466 Quinn, P. and T. Nadeau, "Service Function Chaining 467 Problem Statement", draft-ietf-sfc-problem-statement-07 468 (work in progress), June 2014. 470 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 471 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 472 Acronym in the IETF", BCP 161, RFC 6291, June 2011. 474 Authors' Addresses 476 Sam K. Aldrin 477 Huawei Technologies 479 Email: aldrin.ietf@gmail.com 481 Carlos Pignataro 482 Cisco Systems 484 Email: cpignata@cisco.com 486 Nobo Akiya 487 Cisco Systems 489 Email: nobo@cisco.com