SFC OAM for path consistency
draft-ao-sfc-oam-path-consistency-11
SFC WG G. Mirsky
Internet-Draft ZTE Corp.
Intended status: Standards Track T. Ao
Expires: 1 October 2021 Individual contributor
Z. Chen
China Telecom
K. Leung
Cisco System
G. Mishra
Verizon Inc.
30 March 2021
SFC OAM for path consistency
draft-ao-sfc-oam-path-consistency-11
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 due to classification. SFC Operation, Administration and
Maintenance can monitor the continuity of the SFC, i.e., that all SFC
elements 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 orchestrator, the metric referred to in this document as the path
consistency of the SFC. This document defines a new SFC active OAM
method to support SFC consistency check, 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 https://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 1 October 2021.
Mirsky, et al. Expires 1 October 2021 [Page 1]
Internet-Draft SFC OAM for path consistency March 2021
Copyright Notice
Copyright (c) 2021 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 (https://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. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. Consistency OAM: Theory of Operation . . . . . . . . . . . . 3
3.1. COAM packet . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. SFF Information Record TLV . . . . . . . . . . . . . . . 5
3.3. SF Information Sub-TLV . . . . . . . . . . . . . . . . . 6
3.4. SF Information Sub-TLV Construction . . . . . . . . . . . 7
3.4.1. Multiple SFs as hops of SFP . . . . . . . . . . . . . 7
3.4.2. Multiple SFs for load balance . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5.1. COAM Message Types . . . . . . . . . . . . . . . . . . . 9
5.2. SFF Information Record TLV Type . . . . . . . . . . . . . 9
5.3. SF Information Sub-TLV Type . . . . . . . . . . . . . . . 9
5.4. SF Identifier Types . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informational References . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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, i.e., only when an SF
processes traffic, then it can be processed by the next SF. Changes
in the order are very likely to cause errors. That's why an operator
needs to ensure that the order of traversing the SFs is as defined by
Mirsky, et al. Expires 1 October 2021 [Page 2]
Internet-Draft SFC OAM for path consistency March 2021
the control plane or the orchestrator. This document refers to the
correlation between the state of the control plane and the SFP itself
as the SFP consistency. The need to verify the consistency of the
particular SFP, using a mechanism of an active OAM protocol, is noted
in [RFC8924].
This document defines the method to check the path consistency of the
SFP. It is an extension of the SFC Echo-request/Echo-reply specified
in the [I-D.ietf-sfc-multi-layer-oam].
2. Conventions used in this document
2.1. Acronyms
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 the consistency
of the Service Function Path.
MAC: Message Authentication Code
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 (COAM) uses two functions: COAM Request and COAM
Reply. Every SFF that receives the COAM Request MUST perform the
following actions:
* Collect information of the traversed by the COAM Request packet
SFs and send it to the ingress SFF as COAM Reply packet over IP
network [I-D.ietf-sfc-multi-layer-oam];
Mirsky, et al. Expires 1 October 2021 [Page 3]
Internet-Draft SFC OAM for path consistency March 2021
* Forward the COAM Request to the next downstream SFF if the one
exists.
As a result, the ingress SFF collects information about all traversed
SFFs and SFs, information on the actual path the COAM packet has
traveled. That information is used to verify the SFC's path
consistency. The 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 SFC Echo
Request/Reply operation defined in [I-D.ietf-sfc-multi-layer-oam]
with the following values detailed in Section 5.1:
* TBA1 - COAM Request
* TBA2 - COAM Reply
Upon receiving the COAM Request, the SFF MUST respond with the COAM
Reply. The SFF MUST include the SFs information, as described in
Section 3.3 and Section 3.2.
The COAM packet, defined in [I-D.ietf-sfc-multi-layer-oam], is
displayed in Figure 1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Number | Global Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Reply mode | Return Code | Return S.code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's Handle |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mirsky, et al. Expires 1 October 2021 [Page 4]
Internet-Draft SFC OAM for path consistency March 2021
Figure 1: COAM Packet Header
The initiator of COAM Request MAY require the collected information
in the COAM Reply be sent in the integrity-protected mode using the a
Message Authentication Code (MAC) Context Header, defined in
[I-D.ietf-sfc-nsh-integrity]. If the NSH of the received SFC Echo
Reply includes the MAC Context Header, the authentication of the
packet MUST be verified before using any data. If the verification
fails, the receiver MUST stop processing the SFF Information Record
TLV and notify an operator. Specification of the notification
mechanism is outside the scope of this document.
3.2. SFF Information Record TLV
For COAM Request, the SFF MUST include the Information of SFs into
the SF Information Record TLV in the COAM Reply message. Every SFF
sends back a single COAM Reply Message, including information on all
the SFs attached to the SFF on the SFP as requested in the COAM
Request message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SFF Record TLV | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Identifier (SPI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SF Information Sub-TLV |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SFF Information Record TLV
SFF Information Record TLV is a variable-length TLV that includes the
information of all SFFs mapped to the particular SFF instance for the
specified SFP. Figure 2 presents the format of an SFC Echo Request/
Reply TLV, where fields are defined as the following:
Reserved - one-octet-long field.
Service Path Identifier (SPI): The identifier of SFP to which all
the SFs in this TLV belong.
Mirsky, et al. Expires 1 October 2021 [Page 5]
Internet-Draft SFC OAM for path consistency March 2021
SF Information Sub-TLV: The Sub-TLV is as defined in Figure 3.
3.3. SF Information Sub-TLV
Every SFF receiving COAM Request packet MUST include the SF
characteristic data into the COAM Reply packet. The data format of
an SF sub-TLV, included in a COAM Reply packet, is displayed in
Figure 3.
After the COAM Request message traverses the SFP, all the information
of the SFs on the SFP is collected from the TLVs included in COAM
Reply messages.
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| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Service Index | SF Type | SF ID Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SF Identifiers |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Service Function information sub-TLV
SF sub-TLV Type: Two octets long field. It indicates that the TLV is
an SF TLV that contains the information of one SF.
Length: Two octets long field. The value of the field is the length
of the data following the Length field counted in octets.
Service Index: Indicates the SF's position on the SFP.
SF Type: Two octets long field. It is defined in
[I-D.ietf-bess-nsh-bgp-control-plane] and indicates the type of SF,
e.g., Firewall, Deep Packet Inspection, WAN optimization controller,
etc.
Reserved: For future use. MUST be zeroed on transmission and MUST be
ignored on receipt.
SF ID Type: One octet-long field with values defined as Section 5.4.
Mirsky, et al. Expires 1 October 2021 [Page 6]
Internet-Draft SFC OAM for path consistency March 2021
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. SF ID Type and SF Identifier may be a list, indicating the
list of the SFs are which are included in a load balance group.
3.4. SF Information Sub-TLV Construction
Each SFF in the SFP MUST send one and only one COAM Reply
corresponding to the COAM Request. If only one SF is attached to the
SFF in such SFP, only one SF information sub-TLV is included in the
COAM Reply. If several SFs attached to the SFF in the SFP, SF
Information Sub-TLV MUST be constructed as described below in either
Section 3.4.1 and Section 3.4.2.
3.4.1. Multiple SFs as hops of SFP
Multiple SFs attached to the same SFF are the hops of the SFP. The
service indexes of these SFs are different. Service function types
of these SFs could be different or be the same. Information about
all SFs MAY be included in the COAM Reply message. Information about
each SF MUST be listed as separate SF Information Sub-TLVs in the
COAM Reply message.
An example of the COAM procedure for this case is shown in Figure 4.
The Service Function Path(SPI=x) is SF1->SF2->SF4->SF3. The SF1, SF2
and SF3 are attached to SFF1, and SF4 is attached to SFF2. The COAM
Request message is sent to the SFFs in the sequence of the
SFP(SFF1->SFF2->SFF1). Every SFF(SFF1, SFF2) replies with the
information of SFs belonging to the SFP. The SF information Sub-TLV
in Figure 3 contains information for each SF (SF1, SF2, SF3, and
SF4).
SF1 SF2 SF4 SF3
+------+------+ | |
COAM Req ......> SFF1 ......> SFF2 ......> SFF1
(SPI=x) . . .
<............ <.......... <...........
COAM Reply1(SF1,SF2) COAM Reply2(SF4) COAM Reply3(SF3)
Figure 4: Example 1 for COAM Reply with multiple SFs
Mirsky, et al. Expires 1 October 2021 [Page 7]
Internet-Draft SFC OAM for path consistency March 2021
3.4.2. Multiple SFs for load balance
Multiple SFs may be attached to the same SFF to balance the load; in
other words, that means that the particular traffic flow will
traverse only one of these SFs. These SFs have the same Service
Function Type and Service Index. For this case, the SF identifiers
and SF ID Type of all these SFs will be listed in the SF Identifiers
field and SF ID Type in a single SF information sub-TLV of COAM Reply
message. The number of these SFs can be calculated according to SF
ID Type and the value of the Length field of the sub-TLV.
An example of the COAM procedure for this case is shown in Figure 5.
The Service Function Path (SPI=x) is SF1a/SF1b->SF2a/SF2b. The
Service Functions SF1a and SF1b are attached to SFF1, which balances
the load among them. The Service Functions SF2a and SF2b are
attached to SFF2, which, in turn, balances its load between them.
The COAM Request message is sent to the SFFs in the sequence of the
SFP (i.e. SFF1->SFF2). Every SFF (SFF1, SFF2) replies with the
information of SFs belonging to the SFP. The SF information Sub-TLV
in Figure 3 contains information for all SFs at that hop.
/SF1a /SF2a
\SF1b \SF2b
| |
SFF1 SFF2
COAM Req .........> . .........> .
(SPI=x) . .
<............ <...............
COAM Reply1({SF1a,SF1b}) COAM Reply2({SF2a,SF2b})
Figure 5: Example 2 for COAM Reply with multiple SFs
4. Security Considerations
Security considerations discussed in [RFC8300] and
[I-D.ietf-sfc-multi-layer-oam] apply to this document.
Also, since Service Function sub-TLV discloses information about the
SFP the spoofed COAM Request packet may be used to obtain network
information, it is RECOMMENDED that implementations provide a means
of checking the source addresses of COAM Request messages, specified
in SFC Source TLV [I-D.ietf-sfc-multi-layer-oam], against an access
list before accepting the message.
5. IANA Considerations
Mirsky, et al. Expires 1 October 2021 [Page 8]
Internet-Draft SFC OAM for path consistency March 2021
5.1. COAM Message Types
IANA is requested to assign values from its Message Types sub-
registry in SFC Echo Request/Echo Reply Message Types registry as
follows:
+=======+==============================+===============+
| 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 a 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 a 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
Mirsky, et al. Expires 1 October 2021 [Page 9]
Internet-Draft SFC OAM for path consistency March 2021
5.4. SF Identifier Types
IANA is requested to 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 [RFC8126] 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 4: SF Identifier Type
6. Acknowledgements
The authors are thankful to John Drake for his review and the
reference to the work on BGP Control Plane for NSH SFC. The authors
express their appreciation to Joel M. Halpern for his suggestion
about the load balancing scenario. The authors also thank Dirk von
Hugo, for his useful comments.
7. References
7.1. Normative References
[I-D.ietf-sfc-multi-layer-oam]
Mirsky, G., Meng, W., Khasnabish, B., and C. Wang, "Active
OAM for Service Function Chaining", Work in Progress,
Internet-Draft, draft-ietf-sfc-multi-layer-oam-09, 11
February 2021, <https://tools.ietf.org/html/draft-ietf-
sfc-multi-layer-oam-09>.
Mirsky, et al. Expires 1 October 2021 [Page 10]
Internet-Draft SFC OAM for path consistency March 2021
[I-D.ietf-sfc-nsh-integrity]
Boucadair, M., Reddy, T., and D. Wing, "Integrity
Protection for the Network Service Header (NSH) and
Encryption of Sensitive Context Headers", Work in
Progress, Internet-Draft, draft-ietf-sfc-nsh-integrity-05,
23 March 2021, <https://tools.ietf.org/html/draft-ietf-
sfc-nsh-integrity-05>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
"Network Service Header (NSH)", RFC 8300,
DOI 10.17487/RFC8300, January 2018,
<https://www.rfc-editor.org/info/rfc8300>.
7.2. Informational References
[I-D.ietf-bess-nsh-bgp-control-plane]
Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L.
Jalil, "BGP Control Plane for the Network Service Header
in Service Function Chaining", Work in Progress, Internet-
Draft, draft-ietf-bess-nsh-bgp-control-plane-18, 21 August
2020, <https://tools.ietf.org/html/draft-ietf-bess-nsh-
bgp-control-plane-18>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>.
[RFC8924] Aldrin, S., Pignataro, C., Ed., Kumar, N., Ed., Krishnan,
R., and A. Ghanwani, "Service Function Chaining (SFC)
Operations, Administration, and Maintenance (OAM)
Framework", RFC 8924, DOI 10.17487/RFC8924, October 2020,
<https://www.rfc-editor.org/info/rfc8924>.
Mirsky, et al. Expires 1 October 2021 [Page 11]
Internet-Draft SFC OAM for path consistency March 2021
Authors' Addresses
Greg Mirsky
ZTE Corp.
Email: gregimirsky@gmail.com, gregory.mirsky@ztetx.com
Ting Ao
Individual contributor
No.889, BiBo Road
Shanghai
201203
China
Phone: +86 17721209283
Email: 18555817@qq.com
Zhonghua Chen
China Telecom
No.1835, South PuDong Road
Shanghai
201203
China
Phone: +86 18918588897
Email: 18918588897@189.cn
Kent Leung
Cisco System
170 West Tasman Drive
San Jose, CA 95134,
United States of America
Email: kleung@cisco.com
Gyan Mishra
Verizon Inc.
Email: gyan.s.mishra@verizon.com
Mirsky, et al. Expires 1 October 2021 [Page 12]