< draft-li-sfc-nsh-multi-domain-02.txt   draft-li-sfc-nsh-multi-domain-03.txt >
Service Function Chaining Guanwen Li Service Function Chaining Guanwen Li
Internet Draft Guanglei Li Internet Draft Guanglei Li
Intended status: Standards Track Taixin Li Intended status: Standards Track Taixin Li
Expires: October 19, 2017 Qi Xu Expires: April 12, 2018 Qi Xu
Bohao Feng Bohao Feng
Huachun Zhou Huachun Zhou
Beijing Jiaotong University Beijing Jiaotong University
April 18, 2017 October 11, 2017
Multi-domain Service Forwarding For NSH Multi-domain Service Forwarding For NSH
draft-li-sfc-nsh-multi-domain-02 draft-li-sfc-nsh-multi-domain-03
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-Drafts.
Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other documents and may be updated, replaced, or obsoleted by other documents at any
at any time. It is inappropriate to use Internet-Drafts as time. It is inappropriate to use Internet-Drafts as reference
reference material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on October 19, 2017. This Internet-Draft will expire on October 19, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents carefully,
carefully, as they describe your rights and restrictions with as they describe your rights and restrictions with respect to this
respect to this document. Code Components extracted from this document. Code Components extracted from this document must include
document must include Simplified BSD License text as described in Simplified BSD License text as described in Section 4.e of the Trust
Section 4.e of the Trust Legal Provisions and are provided without Legal Provisions and are provided without warranty as described in
warranty as described in the Simplified BSD License. the Simplified BSD License.
Abstract Abstract
This document describes the mechanism to achieve multi-domain ser- This document describes the mechanism to achieve multi-domain service
vice forwarding for NSH. The proposed mechanism adopts a horizontal forwarding for NSH. The proposed mechanism adopts a horizontal
deployment structure, which divides a multi-domain SFC into several deployment structure, which divides a multi-domain SFC into several
segmental SFCs in the control plane and each domain creates its own segmental SFCs in the control plane and each domain creates its own
SFP independently in data plane. A label is proposed to identify SFP independently in data plane. A label is proposed to identify
different cross-domain flows at the classifier by extending the different cross-domain flows at the classifier by extending the
metadata of the NSH encapsulation. metadata of the NSH encapsulation.
Table of Contents Table of Contents
1. Introduction ................................................ 2 1. Introduction ................................................ 2
1.1. Requirement Language ................................... 3 1.1. Requirement Language.................................... 3
2. Definition Of Terms ......................................... 4 2. Definition Of Terms ......................................... 4
3. Multi-domain Service Forwarding Mechanism ................... 3 3. Multi-domain Service Forwarding Mechanism ................... 3
3.1. Service Function Chaining Segmentation ................. 4 3.1. Service Function Chaining Segmentation ................. 4
3.2. Inter-domain Service Forwarding ........................ 4 3.2. Inter-domain Service Forwarding ........................ 4
3.3. Classification and Intra-domain Service Forwarding ..... 5 3.3. Classification and Intra-domain Service Forwarding...... 5
4. Multi-domain Service Forwarding Encapsulation ............... 5 4. Multi-domain Service Forwarding Encapsulation ............... 5
5. Multi-domain Service Forwarding Example ..................... 6 5. Multi-domain Service Forwarding Example ..................... 6
6. Security Considerations ..................................... 8 6. Security Considerations...................................... 8
7. IANA Considerations ......................................... 8 7. IANA Considerations ......................................... 8
8. Conclusions ................................................. 8 8. Conclusions ................................................. 8
9. References .................................................. 8 9. References .................................................. 8
9.1. Normative References ................................... 8 9.1. Normative References.................................... 8
9.2. Informative References ................................. 9 9.2. Informative References.................................. 9
10. Acknowledgments ............................................ 9 10. Acknowledgments ............................................ 9
1. Introduction 1. Introduction
Service Function Chaining (SFC) [RFC7665] is an architecture proposed Service Function Chaining (SFC) [RFC7665] is an architecture proposed
to decouple traditional network service functions with corresponding to decouple traditional network service functions with corresponding
physical resources. It is flexible and convenience for a network physical resources. It is flexible and convenient for the network
operator to deploy on-demand service functions and steer the traffic operator to deploy on-demand service functions and steer the traffic
through them in sequence. through them in sequence.
Network Service Header (NSH) [I-D.ietf-sfc-nsh] is defined as a data Network Service Header (NSH) [I-D.ietf-sfc-nsh] is defined as a data
plane protocol to create a dynamic service function chaining. plane protocol to create dynamic service function chains. According
According to the NSH encapsulation, the flow can pass along its to the NSH encapsulation, the flow can pass along pre-difined Service
service function path and exchange metadata among the Service Function Path and exchange metadata among the Service Classifier, the
Classifier, the Service Function and the Service Function Forwarder Service Function and the Service Function Forwarder for information
for information sharing. sharing.
Network service forwarding in SFC is based on the combination of Network service forwarding in SFC is based on the combination of
Service Path Identifier (SPI) and Service index (SI), which is Service Path Identifier (SPI) and Service index (SI), which are
described in [I-D.ietf-sfc-nsh]. [I-D.kumar-sfc-nsh-forwarding] defined in [I-D.ietf-sfc-nsh]. [I-D.kumar-sfc-nsh-forwarding]
analyzes the NSH forwarding shortcomings and further discusses the analyzes the NSH forwarding shortcomings and further discusses the
separation of the service forwarding and the service delivery. separation of the service forwarding and the service delivery.
However, it focuses on infrastructure service forwarding for NSH in However, it focuses on infrastructure service forwarding for NSH in a
single domain. [I-D.ietf-sfc-hierarchical] propose a hierarchical way single domain. [I-D.ietf-sfc-hierarchical] proposes a hierarchical
to achieves multi-domain SFC, which can be regarded as a vertical way to achieve multi-domain forwarding for SFC, which can be regarded
approach. Contrast to the vertical approach, a horizontal one is easy as a vertical approach. Contrast to the vertical approach, a
to scale in and out. Besides, the horizontal approach can decrease horizontal one is easy to scale in and out. Besides, the horizontal
the overhead of the control plane, because it maintains more service approach can decrease the overhead of the control plane, because it
traffic in the data plane. maintains more service traffic in the data plane.
Therefore, this document proposes a horizontal approach to achieve Therefore, this document proposes a horizontal approach to achieve
multi-domain service forwarding for NSH. The main idea is to divide multi-domain service forwarding for NSH. The main idea is to divide a
a multi-domain SFC into several segmental SFCs according to domain multi-domain SFC into several segmental SFCs according to domain
partitions in the control plane and create corresponding SFP in each partitions in the control plane and create corresponding SFPs in each
domain by its classifier independently. A label is proposed to domain by its classifier independently. A label is proposed to
identify different cross-domain flows, which is encapsulated in the identify different cross-domain flows, which is encapsulated in the
metadata. metadata.
1.1. Requirement Language 1.1. Requirement Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 4, line 5 skipping to change at page 4, line 5
|Segmental |Segmental |Segmental |Segmental |Segmental |Segmental
|SFC-1 |SFC-2 |SFC-N |SFC-1 |SFC-2 |SFC-N
| | | | | |
+-----v-----+ +-----v-----+ +-----v-----+ +-----v-----+ +-----v-----+ +-----v-----+
| | | | | | | | | | | |
----> Domain1 +----> Domain2 +->......--> DomainN +---> ----> Domain1 +----> Domain2 +->......--> DomainN +--->
| | | | | | | | | | | |
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
Figure 1 Multi-domain SFC Divide Figure 1 Multi-domain SFC Divide
As shown in Figure 1, SFC control plane divides the whole SFC and As shown in Figure 1, according to requirements, it divides the whole
issues cross-domain forwarding tables to corresponding classifiers SFC in the control plane and issues cross-domain forwarding tables to
initially. Multi-domain service forwarding includes two aspects: the corresponding classifiers initially. Multi-domain service forwarding
inter-domain service forwarding and the intra-domain forwarding. The includes two aspects: the inter-domain service forwarding and the
former is based on a unique label for each flow, and the latter is intra-domain service forwarding. The former is based on a unique
performed by the classifier. To achieve a unify service forwarding label for each flow, and the latter is performed by the classifier.
mechanism in multi-domain, this mechanism uses metadata in NSH To achieve a unified service forwarding mechanism in multi-domain,
encapsulation to carry the necessary forwarding information among this mechanism uses metadata in NSH encapsulation to carry the
different forwarding elements, such as the Service Classifier and necessary forwarding information among different forwarding elements,
the Service Function Forwarder. such as the Service Classifier and the Service Function Forwarder.
3. Definition Of Terms 3. Definition Of Terms
This document uses some terms defined in SFC architecture [RFC7665] This document uses some terms defined in SFC architecture [RFC7665]
and NSH [I-D.ietf-sfc-nsh] drafts for ease of understanding and the and NSH [I-D.ietf-sfc-nsh] drafts for ease of understanding and the
reader is advised to refer to those documents for up to date and reader is advised to refer to those documents for up to date and
additional information. additional information.
Segmental SFC: The cross-domain SFC is divided into several segmental Segmental SFC: The cross-domain SFC is divided into several segmental
SFCs according to the domain partitions. Each segmental SFC is SFCs according to the domain partition. Each segmental SFC is
assigned to its corresponding domain. assigned to its corresponding domain.
Service Label: A label used to identify different flows can help the Service Label: the label used to identify different flows can help
classifier create the SFP by its corresponding segmental SFC, which the classifier create the SFP by its corresponding segmental SFC,
is issued from SFC control plane. which is issued from SFC control plane.
Cross-domain Forwarding Table: There are three columns in the table: Cross-domain Forwarding Table: There are three columns in the table:
Service Label, Next Classifier and Segmental SFC. The table matches a Service Label, Next Classifier and Segmental SFC. The table matches a
specific flow with its Service Label. The cross-domain forwarding of specific flow with its Service Label. The cross-domain forwarding of
a flow is depended on the address of Next Classifier. The Cross- the flow is depended on the address of Next Classifier. The Cross-
domain Forwarding Table is maintained by SFC control plane and issued domain Forwarding Table is maintained by SFC control plane and issued
to corresponding classifier according to the Segmental SFC. to corresponding classifier according to the Segmental SFC partition.
3.1. Service Function Chaining Segmentation 3.1. Service Function Chaining Segmentation
At first, the SFC control plane creates a SFC with a unique Service At first, the control plane creates a SFC with a unique Service Label
Label for the flow. Then, the SFC is divided into several segmental for the flow. Then, the SFC is divided into several segmental SFCs
SFCs according to physical resource constraints. It is important to according to physical resource constraints. It is important to note
note that the control plane MUST NOT specific the SFP directly. The that the control plane MUST NOT specific the SFP directly. The
control plane is only responsible to indicate what service functions control plane is only responsible to indicate what service functions
are required in each domain, and the corresponding SFP MUST be are required in each domain, and the corresponding SFP MUST be
specified by the service classifier. specified by the service classifier.
3.2. Inter-domain Service Forwarding 3.2. Inter-domain Service Forwarding
The Service Label is proposed to identify different flows when The Service Label is proposed to identify different flows when
packets need to be cross-domain forwarded. When the service packets need to be cross-domain forwarded. When the service
classifier receives a packet with the NSH encapsulation, it firstly classifier receives packets with NSH encapsulations, it checks the
checks the Service Label of the packet to look up the address of the Service Label of the first packet to look up the address of the next
next classifier in its cross-domain forwarding table. The table is classifier in its cross-domain forwarding table, which is issued by
issued by SFC control plane. Then the information of next classifier SFC control plane. Then the information of next classifier is written
is written into the metadata and will be used by the last SFF in the into the metadata and will be used by the last SFF in the Segmental
domain. Once the last SFF receives the packet from last SF in the SFC. Once the last SFF receives the packet from last SF in the domain
domain, which changes the SI to zero, it forwards the packet to next which changes the SI to zero, it forwards the packets to next
classifier directly without any modification of the encapsulation. classifier directly without any modification of their NSH
encapsulations.
The Service Label is only carried by the first packet of a certain The Service Label is only carried by the first packet of a certain
flow with specific SPI. It's beneficial to decrease header cost and flow with specific SPI. It's beneficial to decrease header cost and
improve forwarding efficiency. improve forwarding efficiency.
3.3. Classification and Intra-domain Service Forwarding 3.3. Classification and Intra-domain Service Forwarding
The service classifier creates SFP for each flow according to the The service classifier creates SFP for each flow according to the
segmental SFC in its cross-domain forwarding table. After the control segmental SFC in its cross-domain forwarding table. After the control
plane assigns segmental SFCs for different domains, the corresponding plane assigns segmental SFCs for different domains, the corresponding
table is issued to the classifier in each domain. When the packet table is issued to the classifier in each domain. When the packet
with an NSH encapsulation arrives at the classifier, its Service arrives at the classifier, its Service Label is used to find out the
Label is used to find out the corresponding segmental SFC. Then, the next segmental SFC. Then, the classifier creates a SFP for the flow
classifier creates a SFP for the flow according to its segmental SFC. according to that segmental SFC.
In this situation, the classifier in a segmental SFC SHOULD set the In this situation, the classifier in a segmental SFC SHOULD set the
SI to the length of the segmental SFC. SI to the length of the segmental SFC.
4. Multi-domain Service Forwarding Encapsulation 4. Multi-domain Service Forwarding Encapsulation
In order to reduce overhead of metadata, the context header with MD In order to reduce overhead of metadata, the context header with MD
Type = 0x2 is chosen to support multi-domain service forwarding, Type = 0x2 is chosen to support multi-domain service forwarding,
Figure 2 shows the allocation of the metadata. Figure 2 shows the allocation of the metadata.
skipping to change at page 6, line 46 skipping to change at page 6, line 48
+---^--+---+ +---^--+---+ +---^--+---+ +---^--+---+ +---^--+---+ +---^--+---+
| | | | | | | | | | | |
+-------+ +---+--v---+ +---+--v---+ +-------+ +---+--v---+ +-------+ +---+--v---+ +---+--v---+ +-------+ +---+--v---+
| | | | | | | | | | | | | | | | | | | |
---> CF1 +-> SFF1-1 +-> SFF1-2 +----> CF2 +-> SFF2-1 +---> ---> CF1 +-> SFF1-1 +-> SFF1-2 +----> CF2 +-> SFF2-1 +--->
| | | | | | | | | | | | | | | | | | | |
+-------+ +----------+ +----------+ +-------+ +----------+ +-------+ +----------+ +----------+ +-------+ +----------+
Figure 3 Multi-domain Service Forwarding Example Figure 3 Multi-domain Service Forwarding Example
This section describes the scenario shown in Figure 3, a packet flow This section describes the scenario shown in Figure 3, a packet flow
pass through tree service functions deployed in two domains. The pass through three service functions deployed in two domains. The
Domain1 is consist of CF1, SFF1-1, SFF1-2, SF-a and SF-b; the Domain2 Domain1 is consist of CF1, SFF1-1, SFF1-2, SF-a and SF-b; the Domain2
is consist of CF2, SFF2-1 and SF-c. The workflow is as follow: is consist of CF2, SFF2-1 and SF-c. The workflow is as follow:
1.SFC control plane creates the SFC with a Service Label for the 1.SFC control plane creates the SFC with a Service Label for the
specific flow and divides the whole SFC into several segmental SFCs. specific flow and divides the whole SFC into several segmental SFCs.
2.The cross-domain forwarding table is issued to its corresponding 2.The cross-domain forwarding table is issued to its corresponding
classifier with Service Label, Next Classifier and Segmental SFC. classifier with specific Service Label, Next Classifier and Segmental
SFC.
3.CF1(the classifier in domain1) creates the SFP and the NSH 3.CF1(the classifier in domain1) creates the SFP and the NSH
encapsulation for the first packet of a certain flow according to its encapsulation for the first packet of a certain flow according to its
segmental SFC in domain1. It sets 'D' flag to 1 and fills in the segmental SFC in domain1. It sets 'D' flag to 1 and fills in the
Service Label and Next Classifier. The SI is set to the length of Service Label and Next Classifier. The SI is set to the length of
this segmental SFC. this segmental SFC.
4.CF1 forwards the packet to SFF1-1. 4.CF1 forwards the packet to SFF1-1.
5.SFF1-1 determines SF-a as the next hop and forwards the packet. 5.SFF1-1 determines SF-a as the next hop and forwards the packet.
skipping to change at page 8, line 47 skipping to change at page 9, line 4
created independently. created independently.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.ietf-sfc-nsh] [I-D.ietf-sfc-nsh]
Quinn, P. and U. Elzur, "Network Service Header", draft- Quinn, P. and U. Elzur, "Network Service Header", draft-
ietf-sfc-nsh-12 (work in progress), February 2017. ietf-sfc-nsh-26 (work in progress), October 2017.
9.2. Informative References 9.2. Informative References
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, May IANA Considerations Section in RFCs", BCP 26, RFC 8126,
2008. June 2017.
[RFC7665] J. Halpern, Ed. and C. Pignataro, Ed. "Service Function [RFC7665] J. Halpern, Ed. and C. Pignataro, Ed. "Service Function
Chaining (SFC) Architecture", October 2015. Chaining (SFC) Architecture", October 2015.
[I-D.ietf-sfc-hierarchical] [I-D.ietf-sfc-hierarchical]
D. Dolson, S. Homma, D. Lopez, et al. "Hierarchical Service D. Dolson, S. Homma, D. Lopez, et al. "Hierarchical Service
Function Chaining", draft-ietf-sfc-hierarchical-02 (work in Function Chaining", draft-ietf-sfc-hierarchical-02 (work in
progress), January 2017. progress), January 2017.
skipping to change at page 10, line 35 skipping to change at page 10, line 35
Qi Xu Qi Xu
Beijing Jiaotong University Beijing Jiaotong University
Beijing 100044, P.R. China Beijing 100044, P.R. China
Email: 15111046@bjtu.edu.cn Email: 15111046@bjtu.edu.cn
Bohao Feng Bohao Feng
Beijing Jiaotong University Beijing Jiaotong University
Beijing 100044, P.R. China Beijing 100044, P.R. China
Email: 11111021@bjtu.edu.cn Email: bohaofeng@bjtu.edu.cn
Huachun Zhou Huachun Zhou
Beijing Jiaotong University Beijing Jiaotong University
Beijing 100044, P.R. China Beijing 100044, P.R. China
Email: hchzhou@bjtu.edu.cn Email: hchzhou@bjtu.edu.cn
 End of changes. 31 change blocks. 
82 lines changed or deleted 82 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/