idnits 2.17.1 draft-xu-sfc-hierarchical-orchestration-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 27, 2018) is 2037 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 116, but not defined == Missing Reference: 'I-D.dolson-sfc-hierarchical' is mentioned on line 120, but not defined == Missing Reference: 'I-D.penno-sfc-trace-03' is mentioned on line 215, but not defined == Unused Reference: 'I-D.ao-sfc-for-dc-interconnect' is defined on line 243, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sfc-dc-use-cases' is defined on line 248, but no explicit reference was found in the text == Unused Reference: 'I-D.unify-sfc-control-plane-exp' is defined on line 259, but no explicit reference was found in the text == Unused Reference: '1' is defined on line 264, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-sfc-control-plane-06 Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Service Function Chaining Qi Xu 2 Internet Draft Huachun Zhou 3 Intended status: Informational Taixin Li 4 Expires: April 2019 Guanglei Li 5 Guanwen Li 6 Beijing Jiaotong University 7 September 27, 2018 9 A Method for Service Orchestration in hSFC 10 draft-xu-sfc-hierarchical-orchestration-03.txt 12 Status of this Memo 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on April 27, 2019. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with 45 respect to this document. Code Components extracted from this 46 document must include Simplified BSD License text as described in 47 Section 4.e of the Trust Legal Provisions and are provided without 48 warranty as described in the Simplified BSD License. 50 Abstract 52 Hierarchical SFC is a network architecture for implementing SFC the 53 chain with an ordered set of service functions which could be 54 deployed in multiple geographically dispersed networks. How to 55 forward traffic between networks in Hierarchical SFC is what the 56 draft wants to present. 58 This document proposes a mapping-based forwarding method with 59 coordinated orchestration by the translation of H-SFC and I-SFC to 60 forward traffic between networks in Hierarchical SFC. 62 Table of Contents 64 1. Introduction ................................................ 2 65 1.1. Assumptions ............................................ 3 66 1.2. Requirements Language................................... 3 67 2. Terminology ................................................. 3 68 3. Hierarchical Service Orchestration........................... 3 69 3.1. East-west interface..................................... 4 70 3.1.1. C5: Interface between SFC Control Planes........... 4 71 3.1.2. Interface between SFC Control Planes and IBN....... 5 72 3.2. Hierarchical service orchestration...................... 5 73 4. Metadata Consideration....................................... 5 74 5. Security Considerations...................................... 5 75 6. IANA Considerations ......................................... 5 76 7. References .................................................. 5 77 7.1. Normative References.................................... 5 78 7.2. Informative References.................................. 6 79 Authors' Addresses ............................................. 7 81 1. Introduction 83 Hierarchical SFC is a network architecture for supporting service 84 function chains across multiple geographically dispersed networks. 85 Hierarchical SFC is described in detail in [I.D. dolson-sfc- 86 hierarchical] and [I.D.ao-sfc-for-dc-interconnect], and is not 87 repeated here. 89 In hSFC, SFs in top-domain can be logical and composed of several 90 more refined SFs in sub-domain. Therefore, it is necessary to check 91 the availability of those logical SFs in the procedure of 92 orchestration. 94 This document proposes that adding an east-west interface for 95 coordination among different control planes of separate SFC-enabled 96 domains so to supporting hierarchical service orchestration. 98 1.1. Assumptions 100 The following assumptions are made: 102 o A Hierarchical SFC-enabled network has multiple level network 103 domains. Each domain has their own control plane and data plane. 105 o Control planes of different domain can work coordinately, but 106 they are independent or non-transparent to each other. For 107 example, Top-domain network domain just uses logical SFs, but 108 don't care how to construct a corresponding SFC for these logical 109 SFs in Lower-Level network domains. 111 1.2. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 2. Terminology 119 The reader should be familiar with the terms contained in [RFC7665], 120 [I-D.ietf-sfc-control-plane], [I-D.dolson-sfc-hierarchical] and [I- 121 D.ao-sfc-for-dc-interconnect]. 123 H-SFC: The SFC in the Top-domain network domain. 125 I-SFC: The SFC in the Lower-Level network domain. 127 3. Hierarchical Service Orchestration 129 When receiving a service request, the control plane should decide a 130 SFC for it, select appropriate SF instances and make a SFP for the 131 SFC. Furthermore, a classification policy which binds the flow with 132 the request to a given SFC should be told to classifiers so that the 133 flow can pass through relevant SFs along the SFP. 135 But in hierarchical SFC, SFs might be logical which means it can be 136 decomposed to several less abstract, more refined SFs. Besides, 137 logical SFs always represent SFCs in SFC-enabled sub-domains. So, 138 how to guarantee the availability of logical SFs and forward SFC 139 traffic among multiple SFC-enabled domains is an important problem. 141 3.1. East-west interface 143 +----------------------+ C5 144 | SFC Control Plane +----> 145 | | 146 +---+----+----+----+---+ 147 | | | | 148 | | | v 149 | | v C4 150 | v C3 151 v C2 152 C1 153 Figure 1: Interfaces of SFC Control Plane 155 [I-D.ietf-sfc-control-plane] presents a reference architecture of 156 the SFC control plane, including 4 kinds of interfaces between the 157 SFC control plane and various SFC data plane elements. 159 In hierarchical SFC that SFs are distributed over multiple SFC- 160 enabled domains that the SFC needs to pass through, the control 161 plane also should be hierarchical. As we know, each control plane is 162 responsible for managing a single SFC-enabled domain. Then, each SFC 163 control plane should gather and update information of local domain 164 real-timely. Due to there is no formal control hierarchy scheme, 165 this document attempts to propose a simple Hierarchical Control 166 Plane Scheme for Hierarchical SFC architecture. 168 Figure 1 shows the interface reference points of the SFC control 169 plane architecture. C1 is the interface between SFC Control Plane 170 and SFC Classifier; C2 is the interface between SFC Control Plane 171 and SFF; C3 is the interface between SFC Control Plane and SFC-aware 172 SFs; C4 is the interface between SFC Control Plane and SFC Proxy; C5 173 this document proposes is the east-west interface between SFC 174 Control Planes for supporting coordination among those control 175 planes of separate domains. 177 3.1.1. C5: Interface between SFC Control Planes 179 As [I-D.ietf-sfc-hierarchical] said the IBN acts as a SFC-aware SF 180 in the Top-Level domain and as a classifier in the Lower-Level 181 domain. 183 At the Top-domain, the SFs that compose an SFC might be logical 184 which means they are actually SFCs composed by more refined SFs in 185 the Lower-Levels. To setup these logical SFs, it needs coordinated 186 orchestration between the control planes of Top-domain and Lower- 187 domains. 189 3.1.2. Interface between SFC Control Planes and IBN 191 Due to IBN behaves as an SF to Top-domain, it is controlled by 192 interface C3 or C4. Besides, IBN acts as a classifier and a SFF of 193 end-of-chains to Lower-Level domain, it exchanges information with 194 control plane of Lower-Level domain through interface C1 and C2. 196 3.2. Hierarchical service orchestration 198 During the orchestration for logical SFs of service chains in the 199 Top-domain, the control plane of the Top-domain should send an 200 instruction to control plane of the corresponding Lower-domain. When 201 the latter receives this instruction, it is likely that the Top- 202 domain receives service requests from users. Then Lower-Level would 203 construct or assign an I-SFC for this "service request", and make a 204 classification rule for the classifier of the IBN. 206 4. Metadata Consideration 208 Because the IBN is regarded as a Service Function to the Top-domain 209 domain, it should provide the ability to handle the metadata in the 210 NSH header if necessary. 212 For example, it is common that checking the liveness of the service 213 function of a service function path before the traffic selected by a 214 Classifier traverse the network along a SFC which has been describe 215 in [I-D.penno-sfc-trace-03]. Therefore, the IBN must be able to add 216 its identifying information at the end of the existing NSH headers 217 as a Service Function. 219 5. Security Considerations 221 TBD. 223 6. IANA Considerations 225 TBD. 227 7. References 229 7.1. Normative References 231 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 232 Chaining (SFC) Architecture", RFC 7665, DOI 233 10.17487/RFC7665, October 2015, . 236 7.2. Informative References 238 [I-D.ietf-sfc-hierarchical] 239 Dolson, D., Homma, S., Lopez, D., and Boucadair, M., 240 "Hierarchical Service Function Chaining", draft- ietf-sfc- 241 hierarchical-07 (work in progress), February 2018. 243 [I-D.ao-sfc-for-dc-interconnect] 244 Ao, T. and W. Bo, "Hierarchical SFC for DC 245 Interconnection", draft-ao-sfc-for-dc-interconnect- 246 01(expired), October 2015. 248 [I-D.ietf-sfc-dc-use-cases] 249 Komma, S., Tufail, M., Majee, S., Captari, C., and 250 S.Homma, "Service Function Chaining Use Cases In Data 251 Centers", draft-ietf-sfc-dc-use-cases-06 (work in 252 progress), February 2017. 254 [I-D.ietf-sfc-control-plane] 255 Boucadair, M., Ed., "Service Function Chaining (SFC) 256 Control Plane Components & Requirements", draft-ietf-sfc- 257 control-plane-06 (work in progress), May 2016. 259 [I-D.unify-sfc-control-plane-exp] 260 Szabo, R., Sonkoly, B., "A Multi-Domain Multi-Technology 261 SFC Control Plane Experiment: A UNIFYed", draft-unify-sfc- 262 control-plane-exp-00 (work in progress), March 2016. 264 [1] Sahhaf, Sahel, et al. "Network service chaining with 265 optimized network function embedding supporting service 266 decompositions." Computer Networks (2015): 492-505. 268 Authors' Addresses 270 Qi Xu 271 Beijing Jiaotong University 272 Beijing 100044 P.R. China 274 Email: 15111046@bjtu.edu.cn 276 Huachun Zhou 277 Beijing Jiaotong University 278 Beijing 100044 P.R. China 280 Email: hchzhou@bjtu.edu.cn 282 Taixin Li 283 Beijing Jiaotong University 284 Beijing 100044 P.R. China 286 Email: 14111040@bjtu.edu.cn 288 Guanglei Li 289 Beijing Jiaotong University 290 Beijing 100044 P.R. China 292 Email: 15111035@bjtu.edu.cn 294 Guanwen Li 295 Beijing Jiaotong University 296 Beijing 100044 P.R. China 298 Email: 16111011@bjtu.edu.cn