SFC WG T. Ao
Internet-Draft ZTE Corporation
Intended status: Standards Track G. Mirsky
Expires: December 31, 2017 ZTE Corp.
Z. Chen
China Telecom
June 29, 2017
SFC OAM for path consistency
draft-ao-sfc-oam-path-consistency-00
Abstract
Service Function Chain(SFC) defines an ordered set of service
functions(SFs) to be applied to packets and/or frames and/or flows
selected as a result of classification. SFC Operation,
Administration and Maintenance can monitor the continuity of the SFC,
i.e., that all elements of the SFC are reachable to each other in the
downstream direction. But SFC OAM must support verification that the
order of traversing these SFs corresponds to the state defined by the
SFC control plane or ochestrator, the metric referred in this
document as the path consistency of the SFC. This document defines a
new SFC OAM method to support SFC consistency, i.e. verification that
all elements of the given SFC are being traversed in the expected
order.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on December 31, 2017.
Ao, et al. Expires December 31, 2017 [Page 1]
Internet-Draft SFC OAM for path consistency June 2017
Copyright Notice
Copyright (c) 2017 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
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. Consistency OAM: Theory of Operation . . . . . . . . . . . . 3
3.1. COAM packet . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. SF Sub-TLV . . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
5.1. COAM Message Types . . . . . . . . . . . . . . . . . . . 5
5.2. SFF Information Record TLV Type . . . . . . . . . . . . . 6
5.3. SF Information Sub-TLV Type . . . . . . . . . . . . . . . 6
5.4. SF Types . . . . . . . . . . . . . . . . . . . . . . . . 6
5.5. SF Identifier Types . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . 8
6.2. Informational References . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Service Function Chain (SFC) is a chain with a series of ordered
Service Functions(SFs). Service Function Path (SFP) is a path of a
SFC. SFC is described in detail in the SFC architecture document
[RFC7665]. The SFs in the SFC are ordered and only when traffic is
processed by one SF then it should be processed by the next SF,
otherwise errors may occur. Sometimes, a SF needs to use the
metadata from its upstream SF process. That's why it's very
important for the operator to make sure that the order of traversing
the SFs is exactly as defined by the control plane or the
Ao, et al. Expires December 31, 2017 [Page 2]
Internet-Draft SFC OAM for path consistency June 2017
orchestrator. This document refers to the correspondence between the
state of control plane and the SFP itself as the SFP consistency.
This document defines the method to check the path consistency of the
SFP. It is an extension of the Overlay Echo-Request/Echo-reply
specified in the [I-D.ooamdt-rtgwg-demand-cc-cv].
2. Conventions used in this document
2.1. Terminology
SFC(Service Function Chain): An ordered set of some abstract SFs.
SFF: Service Function Forwarder
SF: Service Function
OAM: Operation, Administration and Maintenance
SFP: Service Function Path
COAM(Consistency OAM): OAM that can be used to check path
consistency.
2.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Consistency OAM: Theory of Operation
Consistency OAM uses two functions: COAM Request and COAM Reply. The
SFF, that is ingress of the SFP, transmits COAM Request packet.
Every intermediate SFF that receives the COAM Request MUST perform
the following actions:
collect information of traversed by the COAM Request packet SFs
and send it to the ingress SFF as COAM Reply packet over IP
network [I-D.wang-sfc-multi-layer-oam];
forward the COAM Request to next downstream SFF if the one exists.
As result, the ingress SFF collects information about all traversed
SFFs and SFs, information of the actual path the COAM packet has
traveled, so that we can verify the path consistency of the SFC. The
Ao, et al. Expires December 31, 2017 [Page 3]
Internet-Draft SFC OAM for path consistency June 2017
mechanism for the SFP consistency verification is outside the scope
of this document.
3.1. COAM packet
Consistency OAM introduces two new types of messages to the OOAM Echo
Request/Reply operation [I-D.ooamdt-rtgwg-demand-cc-cv] with the
following values Section 5.1:
o TBA1 - COAM Request
o TBA2 - COAM Reply
An SFF, upon receiving the Consistency OAM Request, MUST include the
corresponding SFs information, Section 3.2, into the Value field of
the COAM Reply packet.
The COAM packet is displayed in Figure 1.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Reply mode | Return Code | Return S.code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: COAM Packet Header
3.2. SF Sub-TLV
Every SFF receiving COAM Request packet MUST include the SF
characteristic data into the COAM Reply packet. The per SF data
included in COAM Reply packet as SF Information sub-TLV that is
displayed in Figure 2.
After the COAM traversed the SFP, all the information of the SFs on
the SFP are collected in the TLVs with COAM Reply.
Ao, et al. Expires December 31, 2017 [Page 4]
Internet-Draft SFC OAM for path consistency June 2017
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SF sub-TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SF Type | Service Index| SF ID Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SF Identifier |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Service Function sub-TLV
SF TLV Type: indicate that the TLV is a SF TLV which contains the
information of one SF.
SF Type: indicates the type of SF, e.g., Firewall, Deep Packet
Inspection, WAN optimization controller, etc.
Service Index: indicates the SF's position on the SFP.
SF ID Type:
0x01: IPv4
0x02: IPv6
0x03: MAC address
0x04-0xFF: Reserved
SF Identifier: An identifier of the SF. The length of the SF
Identifier depends on the type of the SF ID Type. For example, if
the SF Identifier is its IPv4 address, the SF Identifier should be 32
bits.
4. Security Considerations
Will be added in the future updates.
5. IANA Considerations
5.1. COAM Message Types
IANA is requested to assign values from its Message Types sub-
registry in Overlay Echo Request/Echo Reply Message Types registry as
follows:
Ao, et al. Expires December 31, 2017 [Page 5]
Internet-Draft SFC OAM for path consistency June 2017
+-------+------------------------------+---------------+
| Value | Description | Reference |
+-------+------------------------------+---------------+
| TBA1 | SFP Consistency Echo Request | This document |
| TBA2 | SFP Consistency Echo Reply | This document |
+-------+------------------------------+---------------+
Table 1: SFP Consistency Echo Request/Echo Reply Message Types
5.2. SFF Information Record TLV Type
IANA is requested to assign new type value from SFC OAM TLV Type
registry as follows:
+-------+-----------------------------+---------------+
| Value | Description | Reference |
+-------+-----------------------------+---------------+
| TBA3 | SFF Information Record Type | This document |
+-------+-----------------------------+---------------+
Table 2: SFF-Information Record
5.3. SF Information Sub-TLV Type
IANA is requested to assign new type value from SFC OAM TLV Type
registry as follows:
+-------+----------------+---------------+
| Value | Description | Reference |
+-------+----------------+---------------+
| TBA4 | SF Information | This document |
+-------+----------------+---------------+
Table 3: SF-Information Sub-TLV Type
5.4. SF Types
IANA is requested create in the registry SF Types. All code points
in the range 1 through 32759 in this registry shall be allocated
according to the "IETF Review" procedure as specified in [RFC5226].
Code points in the range 32760 through 65279 in this registry shall
be allocated according to the "First Come First Served" procedure as
specified in [RFC5226]. Remaining code points are allocated
according to the Table 4:
Ao, et al. Expires December 31, 2017 [Page 6]
Internet-Draft SFC OAM for path consistency June 2017
+---------------+--------------+-------------------------+
| Value | Description | Reference |
+---------------+--------------+-------------------------+
| 0 | Reserved | This document |
| 1- 32759 | Unassigned | IETF Review |
| 32760 - 65279 | Unassigned | First Come First Served |
| 65280 - 65519 | Experimental | This document |
| 65520 - 65534 | Private Use | This document |
| 65535 | Reserved | This document |
+---------------+--------------+-------------------------+
Table 4: SF Type Registry
This document defines the following new value in SF Type registry:
+-------+-------------+---------------+
| Value | Description | Reference |
+-------+-------------+---------------+
| TBA5 | Firewall | This document |
+-------+-------------+---------------+
Table 5: SF Types
5.5. SF Identifier Types
IANA is requested create in the registry SF Types the new sub-
registry SF Identifier Types. All code points in the range 1 through
191 in this registry shall be allocated according to the "IETF
Review" procedure as specified in [RFC5226] and assign values as
follows:
+------------+-------------+-------------------------+
| Value | Description | Reference |
+------------+-------------+-------------------------+
| 0 | Reserved | This document |
| TBA6 | IPv4 | This document |
| TBA7 | IPv6 | This document |
| TBA8 | MAC | This document |
| TBA8+1-191 | Unassigned | IETF Review |
| 192-251 | Unassigned | First Come First Served |
| 252-254 | Unassigned | Private Use |
| 255 | Reserved | This document |
+------------+-------------+-------------------------+
Table 6: SF Identifier Type
Ao, et al. Expires December 31, 2017 [Page 7]
Internet-Draft SFC OAM for path consistency June 2017
6. References
6.1. Normative References
[I-D.ooamdt-rtgwg-demand-cc-cv]
Mirsky, G., Kumar, N., Kumar, D., Chen, M., Yizhou, L.,
and D. Dolson, "Echo Request and Echo Reply for Overlay
Networks", draft-ooamdt-rtgwg-demand-cc-cv-03 (work in
progress), March 2017.
[I-D.wang-sfc-multi-layer-oam]
Mirsky, G., Meng, W., Khasnabish, B., and C. Wang, "Multi-
Layer OAM for Service Function Chains in Networks", draft-
wang-sfc-multi-layer-oam-09 (work in progress), June 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <http://www.rfc-editor.org/info/rfc8174>.
6.2. Informational References
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<http://www.rfc-editor.org/info/rfc7665>.
Authors' Addresses
Ting Ao
ZTE Corporation
No.889, BiBo Road
Shanghai 201203
China
Phone: +86 21 68897642
Email: ao.ting@zte.com.cn
Ao, et al. Expires December 31, 2017 [Page 8]
Internet-Draft SFC OAM for path consistency June 2017
Greg Mirsky
ZTE Corp.
1900 McCarthy Blvd. #205
Milpitas, CA 95035
USA
Email: gregimirsky@gmail.com
Zhonghua Chen
China Telecom
No.1835, South PuDong Road
Shanghai 201203
China
Phone: +86 18918588897
Email: 18918588897@189.cn
Ao, et al. Expires December 31, 2017 [Page 9]