One document matched: draft-you-mpls-spring-sfc-oam-00.txt
Mpls Working Group J. You
Internet-Draft X. Xu
Intended status: Standards Track Huawei
Expires: June 5, 2015 December 2, 2014
Service Function Chaining OAM in MPLS-SPRING Networks
draft-you-mpls-spring-sfc-oam-00
Abstract
This document describes a simple and efficient mechanism for
detecting service function connectivity and availability in Multi-
Protocol Label Switching (MPLS) - SPRING networks. This document
proposes some new information that needs to be carried in an MPLS
"echo request" and "echo reply" for the purposes of SF connectivity
and availability detection.
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 June 5, 2015.
Copyright Notice
Copyright (c) 2014 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 June 5, 2015 [Page 1]
Internet-Draft SFC OAM in MPLS-SPRING December 2014
(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 . . . . . . . . . . . . . . . . . . . 4
3.1. Return Codes . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Service Function FEC . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 6
4.1. Return Codes . . . . . . . . . . . . . . . . . . . . . . 6
4.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security considerations . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
A Service Function Chain (SFC) [I-D.ietf-sfc-architecture] as shown
in Figure 1 defines a set of abstract Service Functions (SF) and
ordering constraints that must be applied to packets and/or frames
selected as a result of classification. The SFC as a sequence of
abstract service functions to be delivered can be instantiated as a
Service Function Path (SFP). Some SFPs may be fully specified,
selecting exactly which SFF (Service Function Forwarder) and which SF
are to be visited by packets using that SFP. MPLS-SPRING technique
[I-D.filsfils-spring-segment-routing] can be leveraged to steer the
traffic through an SFP in MPLS-SPRING networks.
You & Xu Expires June 5, 2015 [Page 2]
Internet-Draft SFC OAM in MPLS-SPRING December 2014
+-------------------------------------------------+
| SPRING Netowrks |
| +-----+ +-----+ |
| | SF1 | | SF2 | |
| +--+--+ +--+--+ |
| | | |
| ^ | | |
| (2)| +---+ +---+ |
| +--+ | | |
| | | | +--------------+ |
| V | | |+-----+ | |
+----------+ (1) +---+-+----+ (3) || SF3 | | |
--> |SFC |----> | SFF 1 |---->|+-----+ |---->
----+Classifier+------+ +-----+ SFF 2 +--------
+----------+ +----------+ +--------------+ |
| |
| |
| |
+-------------------------------------------------+
Figure 1: Service Function Chaining in SPRING Network
This document describes a simple and efficient mechanism that can be
used to detect service function connectivity and availability in
MPLS-SPRING ([I-D.filsfils-spring-segment-routing-mpls]) networks
where the MPLS label stack is used to represent a given SFP
([I-D.xu-sfc-using-mpls-spring]). This document proposes some new
information that needs to be carried in an MPLS "echo request" and
"echo reply" which are defined in [RFC4379], for the purposes of SF
connectivity and availability detection.
2. Terminology
This section contains definitions for terms used frequently
throughout this document. However, many additional definitions can
be found in [RFC4379], [I-D.ietf-sfc-architecture] and
[I-D.xu-sfc-using-mpls-spring].
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
fully specified notion of exactly which SFF/SFs the packet will
visit when it actually traverses the network.
You & Xu Expires June 5, 2015 [Page 3]
Internet-Draft SFC OAM in MPLS-SPRING December 2014
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
In the MPLS-SPRING-based SFC approach, service function SIDs are
implemented as locally significant MPLS labels while node SIDs of SFF
are implemented as either globally or locally significant MPLS
labels. Thus the SFP can be represented by an MPLS label stack.
[RFC4379] describes a mechanism to detect data plane failures in MPLS
LSPs. While in the MPLS-SPRING-based SFC case, the SF is represented
by a unique identifier (i.e., SF ID) within an SFC-enabled domain.
Therefore, a new target FEC element referred to as the Service
Function FEC needs to be defined as follows:
Sub-Type Length Value Field
-------- ------ -------------
17 4 SF ID
3.1. Return Codes
The Return Code is set to zero by the sender. The receiver can set
it to 14 (i.e. Service Unavailable) if the SF is unavailable.
Value Meaning
----- -------
14 Service Unavailable
You & Xu Expires June 5, 2015 [Page 4]
Internet-Draft SFC OAM in MPLS-SPRING December 2014
3.2. Service Function FEC
When an SF SID (in the MPLS label format) is encoded in a label
stack, the corresponding Service Function FEC as shown below should
be inserted into the FEC stack accordingly. The value consists of a
4-octet SF ID; the format is given 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 = 17 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SF ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3. MPLS Echo Messages
In the MPLS-SPRING-based SFC scenario, the SFC classifier or PMS
(Path Monitoring System) generates an MPLS echo request that carries
information about the SF whose connectivity/availability needs to be
verified.
The SFC classifier or PMS can send an MPLS echo request with a Target
FEC Stack with a single FEC of type 17 (i.e., SF FEC).
Alternatively, the SFC classifier or PMS can send a Target FEC Stack
with two FECs, the first of type SF and the second of type Prefix
Node Segment ID ([I-D.kumarkini-mpls-spring-lsp-ping]). In either
case, the MPLS echo request would have a label stack of corresponding
to the SF FEC being tested and the Prefix Node SID FEC of the SN to
which the tested SF is attached. In addition, the above MPLS
encapsulated MPLS echo request packets could be imposed further with
one or more MPLS labels which are corresponding to one or more
specified SFF ([I-D.geib-spring-oam-usecase]). In this way, the MPLS
echo request packet would have to traverse one or more specified SFFs
before reaching the final SFF to which the tested SF is attached. In
other words, 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 SFs ahead of the tested SFs are not
traversed at all.
The destination SN that receives the MPLS echo request then processes
it including egress FEC validation. Specifically, the SN would check
whether the locally allocated MPLS label for the service function
identified by the SF ID (i.e. SF FEC) is identical to the SF SID in
the label stack, if not, the SN 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
You & Xu Expires June 5, 2015 [Page 5]
Internet-Draft SFC OAM in MPLS-SPRING December 2014
SN, the SN SHOULD further verify the connectivity availability to the
tested SF besides SF availability checking. How to verify
connectivity and availability is outside the scope of this document.
If the connectivity is down between the SN and the tested SF or the
tested SF is unavailable (e.g. overloaded), the SN SHOULD return an
MPLS Echo reply with the corresponding Return Code of 14 (section
3.1) to indicate that the SF is unavailable.
The SF FEC Stack TLV from the echo request MAY be copied to the
reply. On receipt of an MPLS echo reply, the SFC classifier or PMS
should parse the packet for connectivity/availability check or fault
isolation.
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 Stack 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 Stack TLV. The Return Code must be set to "Service Unavailable"
if the SF is unavailable.
4. IANA Considerations
4.1. Return Codes
Return Codes defined in this document are listed in the following:
Value Meaning
----- -------
14 Service Unavailable
4.2. TLVs
TLVs and sub-TLVs defined in this document are the following:
Type Sub-Type Value Field
-------- --------- -------------
1 Target FEC Stack
17 SF ID
You & Xu Expires June 5, 2015 [Page 6]
Internet-Draft SFC OAM in MPLS-SPRING December 2014
5. Security considerations
This document does not introduce any new security considerations.
6. Acknowledgement
TBD.
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.
7.2. Informative References
[I-D.filsfils-spring-segment-routing]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
"Segment Routing Architecture", draft-filsfils-spring-
segment-routing-04 (work in progress), July 2014.
[I-D.filsfils-spring-segment-routing-mpls]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
"Segment Routing with MPLS data plane", draft-filsfils-
spring-segment-routing-mpls-03 (work in progress), August
2014.
[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-02 (work
in progress), September 2014.
You & Xu Expires June 5, 2015 [Page 7]
Internet-Draft SFC OAM in MPLS-SPRING 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
Xiaohu Xu
Huawei
Email: xuxiaohu@huawei.com
You & Xu Expires June 5, 2015 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-23 05:24:49 |