Internet DRAFT - draft-zhu-sfc-oam-architectual-issues
draft-zhu-sfc-oam-architectual-issues
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
