idnits 2.17.1 draft-xu-sfc-hierarchical-orchestration-04.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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. 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 (March 27, 2019) is 1829 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 119, but not defined == Missing Reference: 'I-D.dolson-sfc-hierarchical' is mentioned on line 123, but not defined == Missing Reference: 'I-D.penno-sfc-trace-03' is mentioned on line 218, but not defined == Unused Reference: 'I-D.ao-sfc-for-dc-interconnect' is defined on line 246, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sfc-dc-use-cases' is defined on line 251, but no explicit reference was found in the text == Unused Reference: 'I-D.unify-sfc-control-plane-exp' is defined on line 262, but no explicit reference was found in the text == Unused Reference: '1' is defined on line 267, 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 (~~), 11 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: September 2019 Guanwen Li 5 Guanglei Li 6 Beijing Jiaotong University 7 Yang Zhang 8 Xu Feng 9 CAEIT 10 March 27, 2019 12 A Method for Service Orchestration in hSFC 13 draft-xu-sfc-hierarchical-orchestration-04.txt 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on September 27, 2019. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with 48 respect to this document. Code Components extracted from this 49 document must include Simplified BSD License text as described in 50 Section 4.e of the Trust Legal Provisions and are provided without 51 warranty as described in the Simplified BSD License. 53 Abstract 55 Hierarchical SFC is a network architecture for implementing SFC the 56 chain with an ordered set of service functions which could be 57 deployed in multiple geographically dispersed networks. How to 58 forward traffic between networks in Hierarchical SFC is what the 59 draft wants to present. 61 This document proposes a mapping-based forwarding method with 62 coordinated orchestration by the translation of H-SFC and I-SFC to 63 forward traffic between networks in Hierarchical SFC. 65 Table of Contents 67 1. Introduction ................................................ 2 68 1.1. Assumptions ............................................ 3 69 1.2. Requirements Language................................... 3 70 2. Terminology ................................................. 3 71 3. Hierarchical Service Orchestration........................... 3 72 3.1. East-west interface..................................... 4 73 3.1.1. C5: Interface between SFC Control Planes........... 4 74 3.1.2. Interface between SFC Control Planes and IBN....... 5 75 3.2. Hierarchical service orchestration...................... 5 76 4. Metadata Consideration....................................... 5 77 5. Security Considerations...................................... 5 78 6. IANA Considerations ......................................... 5 79 7. References .................................................. 5 80 7.1. Normative References.................................... 5 81 7.2. Informative References.................................. 6 82 Authors' Addresses ............................................. 7 84 1. Introduction 86 Hierarchical SFC is a network architecture for supporting service 87 function chains across multiple geographically dispersed networks. 88 Hierarchical SFC is described in detail in [I.D. dolson-sfc- 89 hierarchical] and [I.D.ao-sfc-for-dc-interconnect], and is not 90 repeated here. 92 In hSFC, SFs in top-domain can be logical and composed of several 93 more refined SFs in sub-domain. Therefore, it is necessary to check 94 the availability of those logical SFs in the procedure of 95 orchestration. 97 This document proposes that adding an east-west interface for 98 coordination among different control planes of separate SFC-enabled 99 domains so to supporting hierarchical service orchestration. 101 1.1. Assumptions 103 The following assumptions are made: 105 o A Hierarchical SFC-enabled network has multiple level network 106 domains. Each domain has their own control plane and data plane. 108 o Control planes of different domain can work coordinately, but 109 they are independent or non-transparent to each other. For 110 example, Top-domain network domain just uses logical SFs, but 111 don't care how to construct a corresponding SFC for these logical 112 SFs in Lower-Level network domains. 114 1.2. Requirements Language 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [RFC2119]. 120 2. Terminology 122 The reader should be familiar with the terms contained in [RFC7665], 123 [I-D.ietf-sfc-control-plane], [I-D.dolson-sfc-hierarchical] and [I- 124 D.ao-sfc-for-dc-interconnect]. 126 H-SFC: The SFC in the Top-domain network domain. 128 I-SFC: The SFC in the Lower-Level network domain. 130 3. Hierarchical Service Orchestration 132 When receiving a service request, the control plane should decide a 133 SFC for it, select appropriate SF instances and make a SFP for the 134 SFC. Furthermore, a classification policy which binds the flow with 135 the request to a given SFC should be told to classifiers so that the 136 flow can pass through relevant SFs along the SFP. 138 But in hierarchical SFC, SFs might be logical which means it can be 139 decomposed to several less abstract, more refined SFs. Besides, 140 logical SFs always represent SFCs in SFC-enabled sub-domains. So, 141 how to guarantee the availability of logical SFs and forward SFC 142 traffic among multiple SFC-enabled domains is an important problem. 144 3.1. East-west interface 146 +----------------------+ C5 147 | SFC Control Plane +----> 148 | | 149 +---+----+----+----+---+ 150 | | | | 151 | | | v 152 | | v C4 153 | v C3 154 v C2 155 C1 156 Figure 1: Interfaces of SFC Control Plane 158 [I-D.ietf-sfc-control-plane] presents a reference architecture of 159 the SFC control plane, including 4 kinds of interfaces between the 160 SFC control plane and various SFC data plane elements. 162 In hierarchical SFC that SFs are distributed over multiple SFC- 163 enabled domains that the SFC needs to pass through, the control 164 plane also should be hierarchical. As we know, each control plane is 165 responsible for managing a single SFC-enabled domain. Then, each SFC 166 control plane should gather and update information of local domain 167 real-timely. Due to there is no formal control hierarchy scheme, 168 this document attempts to propose a simple Hierarchical Control 169 Plane Scheme for Hierarchical SFC architecture. 171 Figure 1 shows the interface reference points of the SFC control 172 plane architecture. C1 is the interface between SFC Control Plane 173 and SFC Classifier; C2 is the interface between SFC Control Plane 174 and SFF; C3 is the interface between SFC Control Plane and SFC-aware 175 SFs; C4 is the interface between SFC Control Plane and SFC Proxy; C5 176 this document proposes is the east-west interface between SFC 177 Control Planes for supporting coordination among those control 178 planes of separate domains. 180 3.1.1. C5: Interface between SFC Control Planes 182 As [I-D.ietf-sfc-hierarchical] said the IBN acts as a SFC-aware SF 183 in the Top-Level domain and as a classifier in the Lower-Level 184 domain. 186 At the Top-domain, the SFs that compose an SFC might be logical 187 which means they are actually SFCs composed by more refined SFs in 188 the Lower-Levels. To setup these logical SFs, it needs coordinated 189 orchestration between the control planes of Top-domain and Lower- 190 domains. 192 3.1.2. Interface between SFC Control Planes and IBN 194 Due to IBN behaves as an SF to Top-domain, it is controlled by 195 interface C3 or C4. Besides, IBN acts as a classifier and a SFF of 196 end-of-chains to Lower-Level domain, it exchanges information with 197 control plane of Lower-Level domain through interface C1 and C2. 199 3.2. Hierarchical service orchestration 201 During the orchestration for logical SFs of service chains in the 202 Top-domain, the control plane of the Top-domain should send an 203 instruction to control plane of the corresponding Lower-domain. When 204 the latter receives this instruction, it is likely that the Top- 205 domain receives service requests from users. Then Lower-Level would 206 construct or assign an I-SFC for this "service request", and make a 207 classification rule for the classifier of the IBN. 209 4. Metadata Consideration 211 Because the IBN is regarded as a Service Function to the Top-domain 212 domain, it should provide the ability to handle the metadata in the 213 NSH header if necessary. 215 For example, it is common that checking the liveness of the service 216 function of a service function path before the traffic selected by a 217 Classifier traverse the network along a SFC which has been describe 218 in [I-D.penno-sfc-trace-03]. Therefore, the IBN must be able to add 219 its identifying information at the end of the existing NSH headers 220 as a Service Function. 222 5. Security Considerations 224 TBD. 226 6. IANA Considerations 228 TBD. 230 7. References 232 7.1. Normative References 234 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 235 Chaining (SFC) Architecture", RFC 7665, DOI 236 10.17487/RFC7665, October 2015, . 239 7.2. Informative References 241 [I-D.ietf-sfc-hierarchical] 242 Dolson, D., Homma, S., Lopez, D., and Boucadair, M., 243 "Hierarchical Service Function Chaining", draft- ietf-sfc- 244 hierarchical-07 (work in progress), February 2018. 246 [I-D.ao-sfc-for-dc-interconnect] 247 Ao, T. and W. Bo, "Hierarchical SFC for DC 248 Interconnection", draft-ao-sfc-for-dc-interconnect- 249 01(expired), October 2015. 251 [I-D.ietf-sfc-dc-use-cases] 252 Komma, S., Tufail, M., Majee, S., Captari, C., and 253 S.Homma, "Service Function Chaining Use Cases In Data 254 Centers", draft-ietf-sfc-dc-use-cases-06 (work in 255 progress), February 2017. 257 [I-D.ietf-sfc-control-plane] 258 Boucadair, M., Ed., "Service Function Chaining (SFC) 259 Control Plane Components & Requirements", draft-ietf-sfc- 260 control-plane-06 (work in progress), May 2016. 262 [I-D.unify-sfc-control-plane-exp] 263 Szabo, R., Sonkoly, B., "A Multi-Domain Multi-Technology 264 SFC Control Plane Experiment: A UNIFYed", draft-unify-sfc- 265 control-plane-exp-00 (work in progress), March 2016. 267 [1] Sahhaf, Sahel, et al. "Network service chaining with 268 optimized network function embedding supporting service 269 decompositions." Computer Networks (2015): 492-505. 271 Authors' Addresses 273 Qi Xu 274 Beijing Jiaotong University 275 Beijing 100044 P.R. China 277 Email: 15111046@bjtu.edu.cn 279 Huachun Zhou 280 Beijing Jiaotong University 281 Beijing 100044 P.R. China 283 Email: hchzhou@bjtu.edu.cn 285 Taixin Li 286 Beijing Jiaotong University 287 Beijing 100044 P.R. China 289 Email: 14111040@bjtu.edu.cn 291 Guanglei Li 292 Beijing Jiaotong University 293 Beijing 100044 P.R. China 295 Email: 15111035@bjtu.edu.cn 297 Guanwen Li 298 Beijing Jiaotong University 299 Beijing 100044 P.R. China 301 Email: 16111011@bjtu.edu.cn 303 Yang Zhang 304 China Academy of Electronics and InformationTechnology 305 Beijing 100043 P.R. China 307 Email: zhangyang.upc@qq.com 309 Xu Feng 310 China Academy of Electronics and InformationTechnology 311 Beijing 100043 P.R. China 313 Email: fx123815@163.com