| MPLS Working Group | Y. Liu |
| Internet-Draft | G. Mirsky |
| Intended status: Standards Track | ZTE Corporation |
| Expires: January 13, 2021 | July 12, 2020 |
MPLS-based Service Function Path(SFP) Consistency Verification
draft-lm-mpls-sfc-path-verification-00
This document proposes a method to verify the correlation between Service Function Chaining control and/or management plane view of the specified Service Function Path and the state of its data. It works for both SR service programming and MPLS-based NSH SFC.
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 January 13, 2021.
Copyright (c) 2020 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.
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 can be achieved through a variety of encapsulation methods, such as NSH [RFC8300], SR service programming [I-D.ietf-spring-sr-service-programming] and MPLS-based NSH SFC [RFC8595].
This document describes extensions to MPLS LSP ping [RFC8029] mechanisms to support verification between the control/management plane and the data plane state for both SR-MPLS service programming and MPLS-based NSH SFC.
SFC: Service Function Chain
SFF: Service Function Forwarder
SF: Service Function
SFP: Service Function Path
RSP: Rendered Service Path
MPLS echo request and reply messages [RFC8029] can be extended to support the verification of the consistency of an MPLS-based Service Function Path (SFP).
SR-MPLS/MPLS can be used to realize an SFP. Two methods have been defined:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFC Context Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SF Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The Basic Unit of MPLS Label Stack for SFC
In MPLS Label Switched Paths (LSPs), MPLS LSP ping [RFC8029] is used to check the correctness of the data plane functioning and to verify the data plane against the control plane.
The proposed extension of MPLS LSP ping allows verification of the correlation between the control/management (if data model-based central controller used) plane and the data plane state in SR-MPLS/MPLS-based SFC.
Generally, except for the designed specific functions, the packet processing functions supported by SFs are limited. SFs may not support MPLS OAM protocols like LSP ping, so SFFs are responsible for MPLS echo request processing.
An MPLS SFC validation request/reply is an MPLS echo request/reply that includes an SFC validation TLV.
Nodes examine and process the TLV only if configured to do so; other nodes MUST ignore the TLV and process the packet as a standard MPLS echo packet.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type=TBA1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SFC Information Sub-TLV(s) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SFC Validation TLV
SFC Information Sub-TLV: The Sub-TLV, as defined in Figure 3, MUST NOT be included in an MPLS SFC validation request.
Upon receiving the SFC validation request, the SFF MUST respond with an echo reply, which includes the SFC detailed information.
The SFC detailed information is recorded in SFC info sub-TLV.
Two types of sub-TLVs are defined in this section, and those are used in MPLS-based service programming [I-D.ietf-spring-sr-service-programming] and MPLS-based NSH [RFC8595] respectively.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-TLV Type=TBA1 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SFF Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SF Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SF Type | SR Proxy Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: SFC Info Sub-TLV for SR-MPLS-based Service Programming
Type TBA1 sub-TLV: used in SR-MPLS-based service programming
SFF Label: represents the SID of the SFF
SF Label: represents the service SID of the SF or SR proxy
SF Type: indicates the type of SF, such as DPI, firewall, etc.
SR Proxy Type: It is defined in [I-D.ietf-spring-sr-service-programming] and indicates the type of SR proxy if it exists.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-TLV Type=TBA2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SFC-FWD Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SFC context Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SF Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SF Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SFC Info Sub-TLV for MPLS-based NSH
Type TBA2 sub-TLV: used in MPLS-based NS
SFC-FWD Type: indicates the forwarding type of the data plane, and has the following values:
0x10: MPLS-based NSH [RFC8595] label swapping
0x11: MPLS-based NSH [RFC8595] label stacking
SFC context Label: The meaning of the SFC context label depends on the SFC Type. If SFC-FWD Type is 0x10, the SFC context Label represents SPI. If SFC-FWD Type is 0x11, the SFC context Label represents the context label [RFC8595].
SF Label: The meaning of the SF label depends on the SFC-FWD Type. If SFC Type is 0x10, the SF Label represents SI. If SFC Type is 0x11, the SF Label represents the SFI index [RFC8595].
SF Type: It is defined in [I-D.ietf-bess-nsh-bgp-control-plane] and indicates the type of SF, such as DPI, firewall, etc.
Unlike standard MPLS forwarding, which is based on a single label, in [RFC8595], packet forwarding is based on the basic unit of MPLS label stack for SFC(SFC Context Label+SF Label). A new FEC sub-TLV is defined in this document, which can be used to carry the corresponding FEC of the basic unit.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Distinguisher (RD) | | (8 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SF Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: SFC Basic Unit sub-TLV
Route Distinguisher (RD): 8 octets field in SFIR Route Type specific NLRI [I-D.ietf-bess-nsh-bgp-control-plane] .
SF Type: 2 octets. It is defined in [I-D.ietf-bess-nsh-bgp-control-plane] and indicates the type of SF, such as DPI, firewall, etc.
A node that receives an LSP ping with the new FEC will check if it is its Route Distinguisher and whether it advertised that Service Function Type.
An MPLS SFC validation request is an MPLS echo request with an SFC validation TLV, and the echo request is sent with a label stack corresponding to the SFP being tested.
Sending an SFC echo request to the control plane is triggered by one of the following packet processing exceptions: IP TTL expiration, MPLS TTL expiration, or the receiver is the terminal SFF for an SFP.
After general packet sanity verifying[RFC8029], section 3.4.1 and section 3.4.2 in this document separately describe the following processing procedures in service programming and MPLS-based NSH.
After all SFFs on the SFP send back MPLS echo reply, the sender collects information about all traversed SFFs and SFs on the rendered service path (RSP).
[I-D.ietf-spring-sr-service-programming] describes how a service can be associated with a SID to achieve service function chaining. In an SR-MPLS network, the SFP is encoded as a stack of MPLS labels. That stack is pushed on top of the packet.
If an SFC validation TLV is present in the received echo request, an SFF MUST parse through the label stack until the next label is not a local service SID to get all the SFs attached to the SFF on the SFP and record the corresponding Label-stack-depth.
The SFF then sends an MPLS echo reply with all the SF information recorded in SFC Information Sub-TLV, including the service SID and the SF type.
[RFC8595] describes how Service Function Chaining (SFC) can be achieved in an MPLS network using a logical representation of the Network Service Header (NSH) in an MPLS label stack.
SFC forwarding can be achieved by label swapping, label stacking, or the mix of both. When an SFF receives a packet containing an MPLS label stack, it examines the top basic unit of MPLS label stack for SFC, {SPI, SI} or {context label, SFI index}, to determine where to send the packet next.
Upon receiving the SFC validation request, an SFF checks the MPLS label stack to get all the locally attached basic units for SFC. Then, the SFF sends back a reply message, including SFC info sub-TLVs, for each basic unit local to the SFF.
In [RFC8595], it says, "when an SFF receives a packet from any component of the SFC system (classifier, SFI, or another SFF), it MUST discard any packets with TTL set to zero". To trace SFC, it should be changed to allow punting the packet to the control plane though under throttling control.
| [RFC7665] | Halpern, J. and C. Pignataro, "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015. |