INTERNET-DRAFT: SFC working group L. Zhu Intended Status: Informational Huawei Technologies Expires: 2 January 2016 3 July 2015 Issues to SFC OAM Framework draft-zhu-sfc-oam-architectual-issues-00 Abstract This document is motivated to illustrate SFC OAM issues from framework perspective. This document contains the problems, requirements and framework issues to support operation and management in SFC architecture. These SFC OAM framework considerations are applicable for vitalization platform. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of L. Zhu Expires January 2, 2016 [Page 1] INTERNET DRAFT Issues to SFC OAM Framework July 3, 2015 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Issues and Requirements . . . . . . . . . . . . . . . . . . . 4 3. Issues and Requirements . . . . . . . . . . . . . . . . . . . . 5 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1 Normative References . . . . . . . . . . . . . . . . . . . 7 6.2 Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 L. Zhu Expires January 2, 2016 [Page 2] INTERNET DRAFT Issues to SFC OAM Architecture July 3, 2015 1 Background The delivery of end-to-end services often requires various service functions. Service Function Chaining (SFC) enables the creation of composite services that consist of an ordered set of Service Functions (SF) that are applied to packets and/or frames selected as a result of classification. Service Function Chaining is a concept that provides for more than just the application of an ordered set of SFs to selected traffic; rather, it describes a method for deploying SFs in a way that enables dynamic ordering and topological independence of those SFs. The specification of architecture of SFC in a network is referenced to Service Function Chaining (SFC) Architecture,in [SFC ARC]. The SFC architecture would be considered to run over physical sets of service functions, or, abstract set of service functions. The exemplary use case for SFC architecture is illustrated in [mobile use case]. The application domain of SFC mobile use case is the joint network services of mobile core network, including PGW and policy provision aspect, and Gi-LAN in a mobile network applied SFC framework and protocol for IETF SFC WG. Vitalization is desirable to behave a vitalization technology to support scalability of service functions. Vitalization also applies the common platform of compute, storage and network as hardware platform which is commonly desirable for 3rd party vendor from SFs suppliers. The maintenance elements to a service function are composited of configuration, operation and management. The operation and management in SFC architecture is the subject in this document, which is to illustrate the issues to SFC OAM and the possible architectural issues to a SFC framework. This document should not target to address all detail of SFC OAM issues, as SFC architecture would include SFC components (e.g. Traffic Classification, Service Function, and Service Forwarding Function etc), management elements of a Service Function and supportive underlying networking functions. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. SFC terminologies are defined in [SFC ARC]. SFC OAM: SFC Operation, Administration and Maintenance. A group SFC functions of management functions that provide fault detection, L. Zhu Expires January 2, 2016 [Page 3] INTERNET DRAFT Issues to SFC OAM Architecture July 3, 2015 fault localization, performance information, and data and diagnosis functions. Management objects of SFC OAM are SFC, SFP, SFC policy. SFC OAM entity: data plane SFC OAM functions for execution of fault detection, fault localization and performance information notice. 2. Issues and Requirements SFC OAM (Operation Administration and Maintenance) should provide relevant functions and features to enable SFC architecture for purpose of fault detection and localization, SFC functional behavior information, performance information and diagnosis approaches in SFC architecture. Based on SFC architecture with scoped SFC components, the SFC OAM involves SFF, SF, SFC, SFP and Classifier. The framework of SFC OAM shall support OAM functions for service functions. The fault detection, performance monitoring and recovery functions are out of scope of this document. The framework of SFC OAM shall support OAM functions for service function chaining and service forwarding path. OAM function for SFC shall support fault detection and failure trace in a SFC and a SFP. OAM function for SFC in data plane shall support fault and performance information notification to OAM entity in control plane. OAM function for SFC in data plane and control plane shall support provisioning of SFC OAM configuration to SFC OAM entities, e.g. SFC Classifier. The following requirements are outlined for SFC OAM from architectural perspective. Functional requirements: 1. SFC OAM shall support SFC OAM control entity and data plane OAM functions. 2. SFC OAM data plane function shall involve SFC Classifier, SFF, and may involve SFs. 3. SFC OAM data plane function shall support service forwarding path validation. 4. SFC OAM data plane function shall support service function chaining validation. 5. SFC OAM data plane function should support SFC performance, fault detection (e.g. occurs of SFC failure). 6. SFC OAM data plane function shall support SFC OAM packages with enough information (e.g. OAM flag, SFF identifier, SFC identifier and performance information) collected for OAM uses, which can be forwarded in a service forwarding path. L. Zhu Expires January 2, 2016 [Page 4] INTERNET DRAFT Issues to SFC OAM Architecture July 3, 2015 7. SFC SF should bypass SFC OAM package once received. 8. SFC OAM framework shall support a control entity, for purposes of collection OAM notification, provisioning OAM information to SFC OAM function in data plane. 9. SFC control entity shall support to enable SFC OAM localization action in SFC OAM data plane. 10. SFC OAM control entity shall support validation of SFC rule provisioning rules. 11. SFC OAM framework shall reuse existing OAM protocol for forwarding planes (e.g. link and network layer), for SFC OAM uses. 12. SFC OAM framework shall allow OAM functions to support back compatibility to existing OAM methods (e.g. ICMP) in forwarding plane, which are in scope of SFC architecture. 3. SFC OAM Architectural Issues SFC OAM should be compliance with SFC architecture, which composites of multiple layers for application layer, SF forwarding layer, networking layer, and of components for service function, service forwarding function, classifier as functional entities in SFC architecture. SF, SFF (Service Function Forwarding) and Classifier are SFC entities in SFC architecture. The application layer as top part of SFC architecture would apply application layer management and service assurance to SFC(s). This document references and respects current application management aspect for legacy management manner for SFC. For example, management for firewall and media processor in a Gi-LAN use case in mobile network as what described in [Mobile Use Case]. Furthermore, service functions running over vitalization platform are desirable for operators in this context of document, which management manner would evolve with vitalization management since service assurance would likely rely on combined analysis for service related alarm and virtual resource failure information, finally rely on service decision to switch forwarding path in SFC or any other failure handling process in that management logic. SFC OAM shall not handle those service function management for service assurance in this document. SFF (Service Function Forwarders) and Classifier are specified to functionality of SFC data plane functions. Classifier would match SFC rules to provisioned SFPs, support function of SFC data plane L. Zhu Expires January 2, 2016 [Page 5] INTERNET DRAFT Issues to SFC OAM Architecture July 3, 2015 encapsulation and forwarding function. Service function forwarding is responsible for forwarding packets to connected service functions according to information carried in the SFC encapsulation. Service function forwarding will handle packet coming back from the service function, and including necessary forwarding plane information for OAM. Forwarding plane information is assumed to support record performance related information as an addition to service function forwarder identifiers. The metadata and encapsulation support in SFC forwarding layer is out of scope of this document. Once traffic is forwarded in SFC domain, SFC classifier shall include SFC encapsulation in packet including enough information for service function forwarder(s). The SFC OAM control entity is responsible to provision OAM actions of reporting data plane OAM results. SFC OAM control entity is also to enable SFC OAM actions to validate SFC or SFP. SFC OAM architecture shall include north bound interface between SFC data plan OAM entities and SFC OAM control entity. Information element, description language (e.g. YANG modeling based language) shall be described in other document(s). Other layers in SFC architecture: 1)Link layer entity and networking layer are also necessary parts to support SFC architecture, for forwarding proper packets to SFFs and further service functions. Link layer OAM actions for networking service assurance should be supported by link layer administration domain. SFC classifier and service function forwarders may be provisioned to schedule link layer OAM actions. The SFC OAM control entity should support enable link layer OAM actions in SFC architecture. 2)SFC OAM control entity might also support OAM information report to higher layer OAM entity from SFC domain to vitalization platform management aspect. The interface and protocol to vitalization platform management aspect is out of scope of SFC OAM. 4 Security Considerations TBD. 5 IANA Considerations New SFC OAM metadata would be specified and needs IANA registration. L. Zhu Expires January 2, 2016 [Page 6] INTERNET DRAFT Issues to SFC OAM Architecture July 3, 2015 6 References 6.1 Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.2 Informative References [SFC ARC] Halpern, J., "Service Function Chaining (SFC) Architecture", https://tools.ietf.org/html/draft-ietf-sfc- architecture-09, June 7, 2015. [Mobile Use Case] Haeffner, W., "Service Function Chaining Use Cases in Mobile Networks", https://tools.ietf.org/html/draft- ietf-sfc-use-case-mobility-03, January 13, 2015. Authors' Addresses L. Zhu Address: Huawei Building,No. 3, Xinxi Road, Haidian District E-mail address: Lei.zhu@huawei.com