Документ взят из кэша поисковой машины. Адрес оригинального документа : http://mirror.msu.net/pub/rfc-editor/internet-drafts/draft-wang-sfc-multi-layer-oam-03.txt Дата изменения: Tue Dec 22 05:22:21 2015 Дата индексирования: Sun Apr 10 07:29:22 2016 Кодировка: Поисковые слова: vallis

SFC WG C. Wang
Internet-Draft W. Meng
Intended status: Standards Track ZTE Corporation
Expires: June 23, 2016 B. Khasnabish
ZTE TX, Inc.
December 21, 2015


Multi-Layering OAM for Service function Chaining
draft-wang-sfc-multi-layer-oam-03

Abstract

This document tries to discuss some problems in SFC OAM framework
document and proposes the SFC OAM multi-layering requirements in SFC
domain to improve the troubleshooting efficiency.

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 23, 2016.

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
(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.



Wang, et al. Expires June 23, 2016 [Page 1]

Internet-Draft Multi-Layer OAM for SFC December 2015


Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Convention and Terminology . . . . . . . . . . . . . . . . . . 4
3. SFC Layering model . . . . . . . . . . . . . . . . . . . . . . 5
4. Requirements for SFC OAM multi-layering model . . . . . . . . 6
5. SFC OAM multi-layering model . . . . . . . . . . . . . . . . . 8
6. Gap analysis . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13





































Wang, et al. Expires June 23, 2016 [Page 2]

Internet-Draft Multi-Layer OAM for SFC December 2015


1. Introduction

In [SFC-arch], it defines several requisite components to implement
SFC, including classifier, which performs classification for incoming
packets, and Service Function Forwarder/SFF, which is responsible for
forwarding traffic to one or more connected service functions
according to the information carried in the SFC encapsulation, as
well as handling traffic coming back from the SF and transporting
traffic to another SFF and terminating the SFP. And what!_s more,
another significant component is Service Function/SF, which is
responsible for specific treatment of received packets.

Based on these SFC components, there are different notions for
differentiated level of service chains, such as fully abstract notion
named SFC, which defines an ordered set of service functions that
must be applied to packets selected as a result of classification.
But, SFC doesn!_t define the exactly SFFs/SFs. And another notion is
half-fully abstraction notion named SFP, which is the instantiation
of a SFC in the network and provides a level of indirection between
the fully abstract SFC and a fully specified RSP. The mean is that
SFP defines some SFFs/SFs, not every SFFs/SFs. As well, there is a
fully specific notion named RSP, which defines exactly which SFFs/SFs
the packet will visit when it actually traverses the network. The
main difference between SFP and RSP is that whether delegate the
SFF/SF selection authority to the network or not.

This document tries to discuss some problems in basic SFC OAM
framework document and proposes the SFC OAM multi-layering
requirements to improve the troubleshooting efficiency.






















Wang, et al. Expires June 23, 2016 [Page 3]

Internet-Draft Multi-Layer OAM for SFC December 2015


2. Convention and Terminology

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].

The terms are all defined in [RFC7665].












































Wang, et al. Expires June 23, 2016 [Page 4]

Internet-Draft Multi-Layer OAM for SFC December 2015


3. SFC Layering model

As described in [I-D.ietf-sfc-oam-framework], multiple layers come
into play for implementing the SFC, including the Service layer at
SFC layer and the underlying Network layer, Transport layer, as well
as Link layer, which are depicted in Figure 1.

As for the Service layer in Figure 1, it consists of classifiers
and/or service functions/SFs.

Concerning Network layer and Transport Layer in Figure 1, it
leverages various overlay network technologies interconnecting
service functions and allows establishing of service function paths.

As for the Link layer in Figure 1, it is dependent on the physical
technology used. Such as, Ethernet, POS etc..)


+-----------+ +---+ +---+ +---+ +---+ +---+
|Classifier |---|SF1|---|SF2|---|SF3|---|SF4|---|SF5|
+-----------+ +---+ +---+ +---+ +---+ +---+
0------------SFC Service layer OAM------------0
0----------------0--------------0-------------0 Network layer
0-------------0-------0-------0--------0------0 Link Layer


Figure 1: SFC Layering model
























Wang, et al. Expires June 23, 2016 [Page 5]

Internet-Draft Multi-Layer OAM for SFC December 2015


4. Requirements for SFC OAM multi-layering model

In fact, besides the Link layer OAM, the Network layer and/or the
Transport layer OAM for implementing SFC OAM must detect the network
forwarders/NFs which the service function forwarders/SFFs connecting
to directly along the service function paths. As for how to steer
detection messages along these NFs is determined by the service
function paths information in the Network Service Header.

As for the SFC service layer OAM, except the service layer defined in
Figure 1 which focuses on the SFC OAM between classifier and/or SFs,
here tries to propose the SFC OAM between classifier and/or SFFs, to
improve the efficiency when diagnosing.

With regard to how to diagnose efficiently, here is an example
illustrated as follow.

Currently, according to the latest SFC architecture, we know that
there are several components defined in the SFC architecture, such as
NF, SFF, SF, etc, and the relationship between them like this:
several SFs may share the same SFF, and furthermore, several SFFs may
share the same NF(e.g, different SFFs belong to different VPNs may
residence in one network forwarder). As a result of that, multiple
RSPs, such as RSP1(SF1--SF3--SF5) and RSP2(SF2--SF4--SF6) in Figure
2, not share the same transmitting path, but they may share the same
SFFs path.


+---+ +---+ +---+ +---+ +---+ +---+
|SF1| |SF2| |SF3| |SF4| |SF5| |SF6|
+---+ +---+ +---+ +---+ +---+ +---+
\ / \ / \ /
+-----------+ +----+ +----+ +----+
|Classifier |---|SFF1|-----------|SFF2|-----------|SFF3|
+-----------+ +----+ +----+ +----+


Figure 2: different RSPs share the same SFFs path

And also, multiple SFPs, such as SFP1(SFF1--SFF3--SFF5)(e.g, VPN1)
and SFP2(SFF2--SFF4--SFF6)(e.g, VPN2) in Figure 3,not share the same
SFFs, but they may share the same NFs path.









Wang, et al. Expires June 23, 2016 [Page 6]

Internet-Draft Multi-Layer OAM for SFC December 2015


+----+ +----+ +----+ +----+ +----+ +----+
|SFF1| |SFF2| |SFF3| |SFF4| |SFF5| |SFF6|
+----+ +----+ +----+ +----+ +----+ +----+
\ / \ / \ /
+-----------+ +----+ +----+ +----+
|Classifier |---|NF1 |------------|NF2 |-------------|NF3 |
+-----------+ +----+ +----+ +----+


Figure 3: different SFPs share the same NFs path

As for users who want to diagnose, troubleshoot a set of RSPs which
may transmit the same SFFs, or a set of SFPs which may transmit the
same NFs because of similar service type , there is an aggregative
method which can aggregate this set of RSPs into one SFFs path or
this set of SFPs into one NFs path, then, users only need to
diagnose, troubleshoot the aggregative one, rather than the separated
one by one.

And also, for example, if users are willing to or have to diagnose
and troubleshoot every one, once the connectivity between different
SFs is not OK, users can detect the connectivity between different
SFFs where the SFs connecting to instead to narrow the failure
coverage. In other words, if the connectivity between the detected
SFFs is not OK, then the connectivity problem is located. If the
connectivity between the detected SFFs is OK, then the connectivity
problem should be between the detected SFs and the detected SFFs,
which can help to improve the efficiency remarkably of target
location.






















Wang, et al. Expires June 23, 2016 [Page 7]

Internet-Draft Multi-Layer OAM for SFC December 2015


5. SFC OAM multi-layering model

Figure 4 is a possible architecture for SFC OAM multi-layering model.
In this figure, it tries to figure out three possible layers
information. The layer 1 sketches the NFs path along the service
function paths. The layer 2 outlines the SFFs path along the service
function paths. The layer 3 outlines the SFs path along the service
function paths. When trying to do SFC OAM, classifier or service
nodes select and confirm which SFC OAM layering they plan to do, then
encapsulate the layering information in the SFC OAM packets, and send
the SFC OAM packets along the service function paths to the
destination. When receiving the SFC OAM packets, service nodes
analyze the layering information and then decide whether send these
packets to NFs or SFFs or SFs to process and response.


+---+ +---+ +----+ +----+ +-----+ +-----+ +------+ +------+
|SF1|..|SFn| |SF1'|..|SFn'| |SF1''|..|SFn''| |SF1'''|..|SFn'''|
+---+ +---+ +----+ +----+ +-----+ +-----+ +------+ +------+
\ / \ / | \ / \ / |
+----+ +----+ | +-----+ +-----+ |
|SFF1| ... |SFFn| | |SFF1'| ... |SFFn'| |
+----+ +----+ | +-----+ +-----+ |
\ / | | \ / | |
+-----------+ +-------+ | | +-------+ | |
|Classifier |------| NF1 |---|------|------------------| NFn | | |
+-----------+ +-------+ | | +-------+ | |
| | | | | |
|------|------|-Layer 1---------------| | |
| | | |
|------|--------Layer 2-----------------| |
| |
|--------------Layer 3-----------------|
| |


Figure 4: SFC OAM multi-layering model














Wang, et al. Expires June 23, 2016 [Page 8]

Internet-Draft Multi-Layer OAM for SFC December 2015


6. Gap analysis

This document tries to complement the SFC OAM framework and all the
SFC OAM functions are the same with the SFC OAM framework.















































Wang, et al. Expires June 23, 2016 [Page 9]

Internet-Draft Multi-Layer OAM for SFC December 2015


7. Security Considerations

It will be considered in a future revision.
















































Wang, et al. Expires June 23, 2016 [Page 10]

Internet-Draft Multi-Layer OAM for SFC December 2015


8. IANA Considerations

It will be considered in a future revision.
















































Wang, et al. Expires June 23, 2016 [Page 11]

Internet-Draft Multi-Layer OAM for SFC December 2015


9. References

9.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
.

[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
Service Function Chaining", RFC 7498, DOI 10.17487/
RFC7498, April 2015,
.

[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/
RFC7665, October 2015,
.

9.2. Informative References

[I-D.boucadair-sfc-requirements]
Boucadair, M., Jacquenet, C., Jiang, Y., Parker, R., and
K. Kengo, "Requirements for Service Function Chaining
(SFC)", draft-boucadair-sfc-requirements-06 (work in
progress), February 2015.

[I-D.ietf-sfc-oam-framework]
Aldrin, S., Krishnan, R., Akiya, N., Pignataro, C., and A.
Ghanwani, "Service Function Chaining Operation,
Administration and Maintenance Framework",
draft-ietf-sfc-oam-framework-00 (work in progress),
August 2015.


















Wang, et al. Expires June 23, 2016 [Page 12]

Internet-Draft Multi-Layer OAM for SFC December 2015


Authors' Addresses

Cui Wang
ZTE Corporation
No.50 Software Avenue, Yuhuatai District
Nanjing
China

Email: wang.cui1@zte.com.cn


Wei Meng
ZTE Corporation
No.50 Software Avenue, Yuhuatai District
Nanjing
China

Email: meng.wei2@zte.com.cn,vally.meng@gmail.com


Bhumip Khasnabish
ZTE TX, Inc.
55 Madison Avenue, Suite 160
Morristown, New Jersey 07960
USA

Email: bhumip.khasnabish@ztetx.com
























Wang, et al. Expires June 23, 2016 [Page 13]