idnits 2.17.1 draft-aldrin-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: ---------------------------------------------------------------------------- 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 (October 26, 2014) is 3467 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-sfc-problem-statement-10 Summary: 0 errors (**), 0 flaws (~~), 2 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 R. Krishnan 5 Expires: April 29, 2015 Brocade Communications 6 N. Akiya 7 C. Pignataro 8 Cisco Systems 9 A. Ghanwani 10 Dell 11 October 26, 2014 13 Service Function Chaining 14 Operation, Administration and Maintenance Framework 15 draft-aldrin-sfc-oam-framework-01 17 Abstract 19 This document provides reference framework for Operations, 20 Administration and Maintenance (OAM) of Service Function 21 ChainingSFC). 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 http://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 April 29, 2015. 46 Copyright Notice 48 Copyright (c) 2014 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 (http://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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Document Scope . . . . . . . . . . . . . . . . . . . . . 3 65 2. SFC Layering Model . . . . . . . . . . . . . . . . . . . . . 3 66 3. SFC OAM Components . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. Service Function Component . . . . . . . . . . . . . . . 5 68 3.1.1. Service Function Availability . . . . . . . . . . . . 5 69 3.1.2. Service Function Performance Measurement . . . . . . 6 70 3.2. Service Function Chain Component . . . . . . . . . . . . 6 71 3.2.1. Service Function Chain Availability . . . . . . . . . 6 72 3.2.2. Service Function Chain Performance Measurement . . . 7 73 3.3. Classifier Component . . . . . . . . . . . . . . . . . . 7 74 4. SFC OAM Functions . . . . . . . . . . . . . . . . . . . . . . 7 75 4.1. Connectivity Functions . . . . . . . . . . . . . . . . . 7 76 4.2. Continuity Functions . . . . . . . . . . . . . . . . . . 8 77 4.3. Trace Functions . . . . . . . . . . . . . . . . . . . . . 8 78 4.4. Performance Measurement Function . . . . . . . . . . . . 9 79 5. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 9 80 5.1. Existing OAM Functions . . . . . . . . . . . . . . . . . 10 81 5.2. Missing OAM Functions . . . . . . . . . . . . . . . . . . 10 82 5.3. Required OAM Functions . . . . . . . . . . . . . . . . . 10 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 86 9. Contributing Authors . . . . . . . . . . . . . . . . . . . . 11 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 89 10.2. Informative References . . . . . . . . . . . . . . . . . 12 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 92 1. Introduction 94 Service Function Chaining (SFC) enables the creation of composite 95 services that consist of an ordered set of Service Functions (SF) 96 that are be applied to packets and/or frames selected as a result of 97 classification. Service Function Chaining is a concept that provides 98 for more than just the application of an ordered set of SFs to 99 selected traffic; rather, it describes a method for deploying SFs in 100 a way that enables dynamic ordering and topological independence of 101 those SFs as well as the exchange of metadata between participating 102 entities. Foundations of the SFC are described in below documents: 104 o [I-D.ietf-sfc-problem-statement]: SFC problem statement. 106 o Various individual drafts. 108 This document provides reference framework for Operations, 109 Administration and Maintenance (OAM, [RFC6291]) of the SFC. 110 Specifically, this document provides: 112 o In Section 2, an SFC layering model; 114 o In Section 3, involved components within the SFC layer; 116 o In Section 4, functional requirements for the SFC OAM; 118 o In Section 5, an OAM gap analysis. 120 1.1. Document Scope 122 The focus of this document is to provide an architectural framework 123 for the SFC OAM, particularly focused on the aspect of the Operation 124 portion of the OAM. Actual solutions and mechanisms are outside the 125 scope of this document. 127 2. SFC Layering Model 129 Multiple layers come into play for implementing the SFC. These 130 include the service layer at SFC layer and the underlying Network, 131 Transport, Link, etc., layers. 133 o The service layer, refer to as the "Service Layer" in Figure 1, 134 consists of classifiers and service functions, and uses the 135 overlay network to reach from a classifier to service functions 136 and service functions to service functions. 138 o The network overlay transport layer, refer to as the "Network", 139 "Transport" and layers below in Figure 1, extends in between 140 various service functions and is mostly transparent to the service 141 functions. It leverages various overlay network technologies 142 interconnecting service functions and allows establishing of 143 service function paths. 145 o The link layer, refer to as the "Link" in Figure 1, is dependent 146 upon the physical technology used. Ethernet is a popular choice 147 for this layer, but other alternatives are deployed (e.g. POS, 148 DWDM etc...). 150 o----------------------Service Layer----------------------o 152 +------+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ 153 |Classi|---|SF1|---|SF2|---|SF3|---|SF4|---|SF5|---|SF6|---|SF7| 154 |fier | +---+ +---+ +---+ +---+ +---+ +---+ +---+ 155 +------+ 156 o-N/W Elem 1----o o-N/w Elem 2-o o-N/W Elem 3-o 158 o-----------------o-------------------o---------------o Network 160 o-----------------o-----------------------------------o Transport 162 o--------o--------o--------o--------o--------o--------o Link 164 Figure 1: SFC Layering Example 166 3. SFC OAM Components 168 The SFC operates at the service layer. For the purpose of defining 169 the OAM framework, the service layer is broken up into three distinct 170 components. 172 1. Service function component: A function that provides a specific 173 service, and is accessible through a service function forwarder. 174 OAM solutions for this component are to test the service 175 functions from any SFC aware network devices (i.e. classifiers, 176 controllers, other service nodes). Within this component, there 177 are two sub-components: 179 A. Service function (SF) sub-component 181 B. Service function forwarder (SFF) sub-component 183 An SF that understands the SFC encapsulation has SFF as part of 184 its SF functionality. An SF that does not understand the SFC 185 encapsulation (ex: legacy SF) has to be accessed via a separate 186 SFF. In both cases, an SF is accessed through an SFF in the SFC 187 architecture. Therefore "service function component" describes 188 the SF and SFF pair, and the SF and SFF are considered sub- 189 components of the "service function component". 191 2. Service function chain component: An ordered set of service 192 functions. OAM solution for this component are to test the 193 service function chains and the service function paths. 195 3. Classifier component: A policy that describes the mapping from 196 flows to service function chains. OAM solutions for this 197 component are to test the validity of the classifiers. 199 Below figure illustrates an example where OAM for the three defined 200 components are used within the SFC environment. 202 +-Classifier +-Service Function Chain OAM 203 | OAM | 204 | | _________________________________________ 205 | \ /\ Service Function Chain \ 206 | +------+ \/ \ +---+ +---+ +---+ +---+ +---+ \ 207 +----> |Classi|...(+-> ) |SF1|---|SF2|---|SF4|---|SF6|---|SF7| ) 208 |fier | \ / +-^-+ +---+ +-|-+ +-^-+ +---+ / 209 +----|-+ \/_____|_______________|_______|_________ / 210 | | +-SF_OAM+ 211 +----SF_OAM----+ +---+ +---+ 212 +SF_OAM>|SF3| |SF5| 213 | +-^-+ +-^-+ 214 +------|---+ | | 215 |Controller| +-SF_OAM+ 216 +----------+ 217 Service Function OAM (SF_OAM) 219 Figure 2: SFC OAM for Three Components 221 It is expected that multiple SFC OAM solutions will be defined, many 222 targeting one specific component of the service layer. However, it 223 is critical that SFC OAM solutions together provide the coverage of 224 all three SFC OAM components: the service function component, the 225 service function chain component and the classifier component. 227 3.1. Service Function Component 229 3.1.1. Service Function Availability 231 One SFC OAM requirement for the service function component is to 232 allow an SFC aware network device to check the availability to a 233 specific service function, located on the same or different network 234 devices. Service function availability is an aspect which raises an 235 interesting question. How does one determine that a service function 236 is available? On one end of the spectrum, one might argue that a 237 service function is sufficiently available if the service node 238 (physical or virtual) hosting the service function is available and 239 is functional. On the other end of the spectrum, one might argue 240 that the service function availability can only be concluded if the 241 packet, after passing through the service function, was examined and 242 verified that the packet got expected service applied. 244 The former approach will likely not provide sufficient confidence to 245 the actual service function availability, i.e. a service node and a 246 service function are two different entities. The latter approach is 247 capable of providing an extensive verification, but comes with a 248 cost. Some service functions make direct modifications to packets, 249 while other service functions do not make any modifications to 250 packets. Additionally, purpose of some service functions is to, 251 conditionally, drop packets intentionally. In such case, packets 252 will not be coming out from the service function. The fact is that 253 there are many flavors of service functions available, and many more 254 flavors of service functions will likely be introduced in future. 255 Even a given service function may introduce a new functionality 256 within a service function (ex: a new signature in a firewall). The 257 cost of this approach is that verifier functions will need to be 258 continuously modified to "keep up" with new services coming out: lack 259 of extendibility. 261 This framework document provides a RECOMMENDED architectural model 262 where generalized approach is taken to verify that a service function 263 is sufficiently available. TBD - details will be provided in a later 264 revision. 266 3.1.2. Service Function Performance Measurement 268 Second SFC OAM requirement for the service function component is to 269 allow an SFC aware network device to check the loss and delay of a 270 specific service function, located on the same or different network 271 devices. TBD - details will be provided in a later revision. 273 3.2. Service Function Chain Component 275 3.2.1. Service Function Chain Availability 277 Verifying an SFC is a complicated process as the SFC could be 278 comprised of varying SF's. Thus, SFC requires the OAM layer to 279 perform validation and verification of SF's within an SFC Path, as 280 well as connectivity and fault isolation. 282 In order to perform service connectivity verification of an SFC, the 283 OAM could be initiated from any SFC aware network devices for end-to- 284 end paths or partial path terminating on a specific SF within the 285 SFC. This OAM function is to ensure the SF's chained together has 286 connectivity as it was intended to when SFC was established. 287 Necessary return code should be defined to be sent back in the 288 response to OAM packet, in order to qualify the verification. 290 When ECMP exists at the service layer on a given SFC, there must be 291 an ability to discover and traverse all available paths. 293 TBD - further details will be provided in a later revision. 295 3.2.2. Service Function Chain Performance Measurement 297 The ingress of the service function chain or an SFC aware network 298 device must have an ability to perform loss and delay measurements 299 over the service function chain as a unit (i.e. end-to-end) or to a 300 specific service function through the SFC. 302 3.3. Classifier Component 304 A classifier defines a flow and maps incoming traffic to a specific 305 SFC, and it is vital that the classifier is correctly defined and 306 functioning. The SFC OAM must be able to test the definition of 307 flows and the mapping functionality to expected SFCs. 309 4. SFC OAM Functions 311 Section 3 described SFC OAM operations required on each SFC 312 component. This section explores the same from the OAM functionality 313 point of view, which many will be applicable to multiple SFC 314 components. 316 Various SFC OAM requirements provides the need for various OAM 317 functions at different layers. Many of the OAM functions at 318 different layers are already defined and in existence. In order to 319 support SFC and SF's, these functions have to be enhanced to operate 320 a single SF to multiple SF's in an SFC and also multiple SFC's. 322 4.1. Connectivity Functions 324 Connectivity is mainly an on-demand function to verify that the 325 connectivity exists between network elements and the availability 326 exists to service functions. Ping is a common tool used to perform 327 this function. OAM messages should be encapsulated with necessary 328 SFC header and with OAM markings when testing the service function 329 chain component. OAM messages MAY be encapsulated with necessary SFC 330 header and with OAM markings when testing the service function 331 component. Some of the OAM functions performed by connectivity 332 functions are as follows: 334 o Verify the MTU size from a source to the destination SF or through 335 the SFC. This requires the ability for OAM packet to take 336 variable length packet size. 338 o Verify the packet re-ordering and corruption. 340 o Verify the policy of an SFC or SF using OAM packet. 342 o Verification and validating forwarding paths. 344 o Proactively test alternate or protected paths to ensure 345 reliability of network configurations. 347 4.2. Continuity Functions 349 Continuity is a model where OAM messages are sent periodically to 350 validate or verify the reachability to a given SF or through a given 351 SFC. This allows monitor network device to quickly detect failures 352 like link failures, network failures, service function outages or 353 service function chain outages. BFD is one such function which helps 354 in detecting failures quickly. OAM functions supported by continuity 355 check are as follows: 357 o Ability to provision continuity check to a given SF or through a 358 given SFC. 360 o Notifying the failure upon failure detection for other OAM 361 functions to take appropriate action. 363 4.3. Trace Functions 365 Tracing is an important OAM function that allows the operation to 366 trigger an action (ex: response generation) from every transit device 367 on the tested layer. This function is typically useful to gather 368 information from every transit devices or to isolate the failure 369 point towards an SF or through an SFC. Mechanism must be provided so 370 that the SFC OAM messages may be sent along the same path that a 371 given data packet would follow. Some of the OAM functions supported 372 by trace functions are: 374 o Ability to trigger action from every transit device on the tested 375 layer towards an SF or through an SFC, using TTL or other means. 377 o Ability to trigger every transit device to generate response with 378 OAM code(s) on the tested layer towards an SF or through an SFC, 379 using TTL or other means. 381 o Ability to discover and traverse ECMP paths within an SFC. 383 o Ability to skip un-supported SF's while tracing SF's in an SFC. 385 4.4. Performance Measurement Function 387 Performance management functions involve measuring of packet loss, 388 delay, delay variance, etc. These measurements could be measured 389 pro-actively and on-demand. 391 SFC OAM framework should provide the ability to perform packet loss 392 for an SFC. In an SFC, there are various SF's chained together. 394 Measuring packet loss is very important function. Using on-demand 395 function, the packet loss could be measured using statistical means. 396 Using OAM packets, the approximation of packet loss for a given SFC 397 could be measured. 399 Delay within an SFC could be measured from the time it takes for a 400 packet to traverse the SFC from ingress SF to egress SF. As the 401 SFC's are generally unidirectional in nature, measurement of one-way 402 delay is important. In order to measure one-way delay, the clocks 403 have to be synchronized using NTP, GPS, etc. 405 Delay variance could also be measured by sending OAM packets and 406 measuring the jitter between the packets passing through the SFC. 408 Some of the OAM functions supported by the performance measurement 409 functions are: 411 o Ability to measure the packet processing delay of a service 412 function or a service function path along an SFC. 414 o Ability to measure the packet loss of a service function or a 415 service function path along an SFC. 417 5. Gap Analysis 419 This Section identifies various OAM functions available at different 420 levels. It will also identify various gaps, if not all, existing 421 within the existing toolset, to perform OAM function on an SFC. 423 5.1. Existing OAM Functions 425 There are various OAM tool sets available to perform OAM function and 426 network layer, protocol layers and link layers. These OAM functions 427 could validate some of the network overlay transport. Tools like 428 ping and trace are in existence to perform connectivity check and 429 tracing intermediate hops in a network. These tools support 430 different network types like IP, MPLS, TRILL etc. There is also an 431 effort to extend the tool set to provide connectivity and continuity 432 checks within overlay networks. BFD is another tool which helps in 433 detection of data forwarding failures. 435 +----------------+--------------+-------------+--------+------------+ 436 | Layer | Connectivity | Continuity | Trace | Performance| 437 +----------------+--------------+-------------+--------+------------+ 438 | N/W Overlay | Ping | BFD, NVo3 | Trace | IPPM | 439 +----------------+--------------+-------------+--------+------------+ 440 | SF | None + None + None + None | 441 +----------------+--------------+-------------+--------+------------+ 442 | SFC | None + None + None + None | 443 +----------------+--------------+-------------+--------+------------+ 444 Figure 3: OAM Tool GAP Analysis 446 5.2. Missing OAM Functions 448 As shown in Figure 3, OAM functions for SFC are not standardized yet. 449 Hence, there are no standard based tools available to verify SF and 450 SFC. 452 5.3. Required OAM Functions 454 Primary OAM functions exist for network, transport, link and other 455 layers. Tools like ping, trace, BFD, etc., exist in order to perform 456 these OAM functions. Configuration, orchestration and manageability 457 of SF and SFC could be performed using CLI, Netconf etc. 459 For configuration, manageability and orchestration, providing data 460 and information models for SFC is very much essential. With 461 virtualized SF and SFC, manageability of these functions has to be 462 done programmatically. 464 SFC OAM must provide tools that operate through various types of 465 appliances including: 467 o Transparent appliances: These appliances typically do not make any 468 modifications to the packet. In such cases, the SFF may be able 469 to process OAM messages. 471 o Appliances that modify the packet: These appliances modify packet 472 fields. Certain appliances may modify only the headers 473 corresponding to the network over which it is transported, e.g. 474 the MAC headers or overlay headers. In other cases, the IP header 475 of the application's packet may be modified, e.g. NAT. In yet 476 other cases, the application session itself may be terminated and 477 a new session initiated, e.g. a load balancer that offers HTTPS 478 termination. 480 6. Security Considerations 482 SFC and SF OAM must provide mechanisms for: 484 o Preventing usage of OAM channel for DDOS attacks. 486 o OAM packets meant for a given SFC should not get leaked beyond 487 that SFC. 489 o Prevent OAM packets to leak the information of an SFC beyond its 490 administrative domain. 492 7. IANA Considerations 494 No action is required by IANA for this document. 496 8. Acknowledgements 498 TBD 500 9. Contributing Authors 502 Pedro A. Aranda Gutierrez 503 Telefonica I+D 504 Email: pedroa.aranda@tid.es 506 Diego Lopez 507 Telefonica I+D 508 Email: diego@tid.es 510 Joel Halpern 511 Ericsson 512 Email: joel.halpern@ericsson.com 514 Sriganesh Kini 515 Ericsson 516 Email: sriganesh.kini@ericsson.com 518 Andy Reid 519 BT 520 Email: andy.bd.reid@bt.com 522 10. References 524 10.1. Normative References 526 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 527 Requirement Levels", BCP 14, RFC 2119, March 1997. 529 10.2. Informative References 531 [I-D.ietf-sfc-problem-statement] 532 Quinn, P. and T. Nadeau, "Service Function Chaining 533 Problem Statement", draft-ietf-sfc-problem-statement-10 534 (work in progress), August 2014. 536 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 537 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 538 Acronym in the IETF", BCP 161, RFC 6291, June 2011. 540 Authors' Addresses 542 Sam K. Aldrin 543 Huawei Technologies 545 Email: aldrin.ietf@gmail.com 547 Ram Krishnan 548 Brocade Communications 550 Email: ramkri123@gmail.com 552 Nobo Akiya 553 Cisco Systems 555 Email: nobo@cisco.com 557 Carlos Pignataro 558 Cisco Systems 560 Email: cpignata@cisco.com 561 Anoop Ghanwani 562 Dell 564 Email: anoop@alumni.duke.edu