Internet DRAFT - draft-you-mpls-spring-sfc-oam
draft-you-mpls-spring-sfc-oam
Mpls Working Group J. You
Internet-Draft X. Xu
Intended status: Standards Track Huawei
Expires: July 15, 2015 January 11, 2015
Service Function Chaining OAM in MPLS-SPRING Networks
draft-you-mpls-spring-sfc-oam-01
Abstract
To perform Service Function Chaining (SFC) in networks where both
MPLS and SPRING (Source Packet Routing in Networking) are enabled, it
is required to be able to detect Service Function (SF) connectivity
and availability. This document proposes a simple mechanism for SF
connectivity and availability detection by using the MPLS echo
request and reply messages as defined in [RFC4379].
Requirements Language
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 [RFC2119].
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 July 15, 2015.
Copyright 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
You & Xu Expires July 15, 2015 [Page 1]
Internet-Draft SFC OAM in MPLS-SPRING January 2015
(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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. SFC OAM in MPLS-SPRING-based SFC . . . . . . . . . . . . . . 4
3.1. SF FEC Sub-TLV . . . . . . . . . . . . . . . . . . . . . 4
3.2. Return Codes . . . . . . . . . . . . . . . . . . . . . . 5
3.3. MPLS Echo Messages . . . . . . . . . . . . . . . . . . . 5
3.4. Packet Format of Echo Request . . . . . . . . . . . . . . 6
3.5. Packet Format of Echo Reply . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
4.1. Return Codes . . . . . . . . . . . . . . . . . . . . . . 7
4.2. SF FEC Sub-TLV . . . . . . . . . . . . . . . . . . . . . 7
5. Security considerations . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
A service function chain [I-D.ietf-sfc-architecture] as shown in
Figure 1, is defined as a set of abstract Service Functions (SF) and
ordering constraints that must be applied to those packets and/or
frames being selected as a result of classification. A service
function chain can be instantiated as a Service Function Path (SFP)
in the network by determining which Service Function Forwarders (SFF)
and which SFs are to be visited. MPLS-SPRING (Source Packet Routing
in Networking) [I-D.ietf-spring-segment-routing-mpls] which is an
MPLS-based source routing paradigm, can be leveraged to realize the
service path layer functionality of the Service Function Chaining
(SFC) (i.e, steering traffic through a particular SFP) in MPLS-SPRING
networks by using an MPLS label stack to represent a given SFP
[I-D.xu-sfc-using-mpls-spring].
You & Xu Expires July 15, 2015 [Page 2]
Internet-Draft SFC OAM in MPLS-SPRING January 2015
+-------------------------------------------------+
| SPRING Networks |
| +-----+ +-----+ |
| | SF1 | | SF2 | |
| +--+--+ +--+--+ |
| | | |
| ^ | | |
| (2)| +---+ +---+ |
| +--+ | | |
| | | | +--------------+ |
| V | | |+-----+ | |
+----------+ (1) +---+-+----+ (3) || SF3 | | |
--> |SFC |----> | SFF 1 |---->|+-----+ |---->
----+Classifier+------+ +-----+ SFF 2 +--------
+----------+ +----------+ +--------------+ |
| |
| |
| |
+-------------------------------------------------+
Figure 1: Service Function Chaining in SPRING Network
SF connectivity and availability detection is one of the important
requirements for deploying SFC. This document describes a simple
mechanism for detecting SF connectivity and availability in MPLS-
SPRING networks by leveraging the MPLS data plane failure detection
mechanism as defined in [RFC4379]. Accordingly, This document
proposes some extensions to the MPLS "echo request" and "echo reply"
messages as defined in [RFC4379].
2. Terminology
This section contains definitions of term frequently used throughout
this document. Please note that these are not the original
definitions; they were all defined in other documents
[I-D.ietf-sfc-architecture] and [I-D.xu-sfc-using-mpls-spring]; they
are included here to make reading the document easier. Further
useful terminology can be found in these documents as well as in
[RFC4379].
Service Function Chain (SFC): A service function chain defines an
ordered set of service functions that must be applied to packets
and/or frames selected as a result of classification.
Service Function Path (SFP): The SFP provides a level of
indirection between the fully abstract notion of service chain as
a sequence of abstract service functions to be delivered, and the
You & Xu Expires July 15, 2015 [Page 3]
Internet-Draft SFC OAM in MPLS-SPRING January 2015
fully specified notion of exactly which SFF/SFs the packet will
visit when it actually traverses the network.
Service Function (SF): A function that is responsible for specific
treatment of received packets.
Service Function Forwarder (SFF): A service function forwarder is
responsible for delivering traffic received from the network to
one or more connected service functions according to information
carried in the SFC encapsulation, as well as handling traffic
coming back from the SF.
SFC Classifier: An entity that classifies packets for service
function chaining according to classification rules. Packets are
then marked with the corresponding SFC header. SFC classifier is
embedded in an SFC ingress node.
SF Identifier (SF ID): A unique identifier that represents a
service function within an SFC-enabled domain.
SID: Segment Identifier.
Service Function SID (SF SID): A locally unique SID indicating a
particular service function on an SFF.
3. SFC OAM in MPLS-SPRING-based SFC
In the MPLS-SPRING-based SFC case, a given SF within an SFC-enabled
domain is represented by a unique identifier (i.e., SF ID). To
detect the connectivity and availability of a given SF, an MPLS echo
request carrying the corresponding FEC to that SF, referred to as SF
FEC as defined in Section 3.1, will be sent.
3.1. SF FEC Sub-TLV
When an SF SID (in the MPLS label format) is encoded in an MPLS label
stack, the corresponding SF FEC as shown below SHOULD be inserted
into the target FEC stack accordingly. The format of SF FEC is
defined as below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD1 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SF ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
You & Xu Expires July 15, 2015 [Page 4]
Internet-Draft SFC OAM in MPLS-SPRING January 2015
Type (TBD1): to be assigned by IANA
Length: indicates the length of the value field (4 octets)
SF ID: Service Function Identifier
3.2. Return Codes
The Return Code is set to zero by the sender. The receiver can set
it to TBD2 (i.e. Service Unavailable) if the tested SF is
unavailable.
Value Meaning
------- -------------------
TBD2 Service Unavailable
3.3. MPLS Echo Messages
To perform SF connectivity/availability detection for a given SF in
the MPLS-SPRING-based SFC scenario, the SFC classifier would generate
an MPLS echo request that carries the SF FEC corresponding to that
SF. The MPLS echo request could also be generated from a special
node other than the classifier. In that case, the echo packet SHOULD
be further imposed with an MPLS label corresponding to the SFC
classifier according to the mechanism as defined in
[I-D.geib-spring-oam-usecase].
The SFC classifier can send an MPLS echo request with the type of the
Target FEC set to SF FEC. Alternatively, the SFC classifier can send
a Target FEC Stack with two FECs with the first being SF FEC and the
second being Prefix Node SID FEC
[I-D.kumarkini-mpls-spring-lsp-ping]. In both cases, the MPLS echo
request SHOULD have a label stack corresponding to the SF FEC being
tested and the Prefix Node SID FEC of the SFF to which the tested SF
is attached. In addition, the MPLS echo request packet could be
imposed with additional MPLS labels corresponding to one or more
additional SFFs according to the mechanism as defined in
[I-D.geib-spring-oam-usecase]. In this way, the MPLS echo request
packet will traverse one or more additional SFFs before reaching the
SFF to which the tested SF is attached. As a result, the MPLS echo
request packet can be ensured to travel through the same ordered set
of SFFs as the given SFP to which the tested SF belongs, although the
previous SFs ahead of the tested SFs along the SFP are not traversed
at all.
Upon receiving an MPLS echo request, the destination SFF would
processe it accordingly. Specifically, the SFF would check whether
the locally allocated MPLS label for the tested SF identified by the
You & Xu Expires July 15, 2015 [Page 5]
Internet-Draft SFC OAM in MPLS-SPRING January 2015
SF FEC is identical to the SF SID in the label stack of the MPLS echo
request. If not, the SFF SHOULD return an MPLS Echo reply that
carries information about the tested SF availability and one of the
Return Codes as defined in [RFC4379] to indicate the particular
error. In the case where the tested SF is externally attached to the
SFF, the SFF SHOULD further verify the connectivity between itself
and the tested SF as well as the availability of the tested SF. How
to verify the connectivity and availability is outside the scope of
this document. If the connectivity between the SFF and the tested SF
is down or the tested SF is unavailable (e.g. overloaded), the SFF
SHOULD return an echo reply with the corresponding Return Code of
TBD2 (i.e., Service Unavailable) (See section 3.2) to indicate that
the tested SF is unavailable.
The target FEC Stack TLV from the echo request MAY be copied to the
echo reply. On receipt of the corresponding echo reply, the SFC
classifier SHOULD parse the packet for connectivity/availability
check or fault isolation. For instance, to check the connectivity of
a given SFP (e.g., SFF1->SF1->SFF2->SF3) within the SFC domain as
shown in Figure 1, two OAM packets need to be sent from the
classifier: the first is used for the connectivity check of SF1 and
therefore it is appended with an SR header of {SID(SFF1), SID(SF1)};
the second is used for the connectivity check for SF3 and therefore
it is appended with an SR header of {SID(SFF1), SID(SFF2), SID(SF3)}.
In this way, it doesn't require any SF along the SFP to process the
OAM packets. As such, this connectivity check approach is applicable
in the scenario where legacy SFs exist.
To prevent the echo request packet from being forwarded by the SFF
farther to the attached SF being tested, the TTL of the innermost
label (i.e., the label corresponding to the SF FEC) MUST be set to 1,
just as what has been done for the echo request for an L2 VPN
endpoint or a pseudowire as stated in [RFC4379].
3.4. Packet Format of Echo Request
An MPLS echo request is an IPv4 or IPv6 UDP packet. The packet
format is defined in [RFC4379]. The echo request is extended to
carry the SF FEC sub-TLV.
3.5. Packet Format of Echo Reply
An MPLS echo reply is an IPv4 or IPv6 UDP packet. The packet format
is defined in [RFC4379]. The echo reply is extended to carry the SF
FEC sub-TLV. The Return Code MUST be set to TBD2 (i.e., "Service
Unavailable") if the tested SF is unavailable.
You & Xu Expires July 15, 2015 [Page 6]
Internet-Draft SFC OAM in MPLS-SPRING January 2015
4. IANA Considerations
4.1. Return Codes
IANA is requested to allocate the first free code point from the
standards action segment of the "Return Codes" sub-registry in a new
Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs)
Ping Parameters registry.
Return Codes defined in this document are listed in the following:
Value Meaning
------- -------------------
TBD2 Service Unavailable
4.2. SF FEC Sub-TLV
TLVs and sub-TLVs defined in this document are the following:
Sub-Type Length Value Field
--------- --------- -------------
TBD1 4 SF ID
5. Security considerations
This document neither introduce additional security risk nor provide
any additional security feature besides those which have been
described in [RFC4379].
6. Acknowledgement
The authors would like to thank Loa Andersson and Mach Chen for their
valuable reviews of this document.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
You & Xu Expires July 15, 2015 [Page 7]
Internet-Draft SFC OAM in MPLS-SPRING January 2015
7.2. Informative References
[I-D.geib-spring-oam-usecase]
Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "Use
case for a scalable and topology aware MPLS data plane
monitoring system", draft-geib-spring-oam-usecase-03 (work
in progress), October 2014.
[I-D.ietf-sfc-architecture]
Halpern, J. and C. Pignataro, "Service Function Chaining
(SFC) Architecture", draft-ietf-sfc-architecture-03 (work
in progress), January 2015.
[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J.,
and E. Crabbe, "Segment Routing Architecture", draft-ietf-
spring-segment-routing-00 (work in progress), December
2014.
[I-D.ietf-spring-segment-routing-mpls]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J.,
and E. Crabbe, "Segment Routing with MPLS data plane",
draft-ietf-spring-segment-routing-mpls-00 (work in
progress), December 2014.
[I-D.kumarkini-mpls-spring-lsp-ping]
Kumar, N., Swallow, G., Pignataro, C., Akiya, N., Kini,
S., Gredler, H., and M. Chen, "Label Switched Path (LSP)
Ping/Trace for Segment Routing Networks Using MPLS
Dataplane", draft-kumarkini-mpls-spring-lsp-ping-02 (work
in progress), October 2014.
[I-D.xu-sfc-using-mpls-spring]
Xu, X., Li, Z., Shah, H., and L. Contreras, "Service
Function Chaining Using MPLS-SPRING", draft-xu-sfc-using-
mpls-spring-01 (work in progress), October 2014.
Authors' Addresses
Jianjie You
Huawei
101 Software Avenue, Yuhuatai District
Nanjing, 210012
China
Email: youjianjie@huawei.com
You & Xu Expires July 15, 2015 [Page 8]
Internet-Draft SFC OAM in MPLS-SPRING January 2015
Xiaohu Xu
Huawei
Email: xuxiaohu@huawei.com
You & Xu Expires July 15, 2015 [Page 9]
