idnits 2.17.1 draft-li-sfc-nsh-multi-domain-06.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 date (March 26, 2019) is 1857 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Service Function Chaining Guanwen Li 2 Internet Draft Guanglei Li 3 Intended status: Standards Track Taixin Li 4 Expires: September 27, 2019 Qi Xu 5 Bohao Feng 6 Huachun Zhou 7 Beijing Jiaotong University 8 March 26, 2019 10 Multi-domain Service Forwarding For NSH 11 draft-li-sfc-nsh-multi-domain-06 13 Status of this Memo 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 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 September 27, 2019. 35 Copyright Notice 37 Copyright (c) 2019 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 respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Abstract 52 This document describes the mechanism to achieve multi-domain service 53 forwarding for NSH. The proposed mechanism adopts a horizontal 54 deployment structure, which divides a multi-domain SFC into several 55 segmental SFCs in the control plane and each domain creates its own 56 SFP independently in data plane. A label is proposed to identify 57 different cross-domain flows at the classifier by extending the 58 metadata of the NSH encapsulation. 60 Table of Contents 62 1. Introduction ................................................ 2 63 1.1. Requirement Language ................................... 3 64 2. Definition Of Terms ......................................... 4 65 3. Multi-domain Service Forwarding Mechanism ................... 3 66 3.1. Service Function Chaining Segmentation ................. 4 67 3.2. Inter-domain Service Forwarding ........................ 5 68 3.3. Classification and Intra-domain Service Forwarding ..... 5 69 4. Multi-domain Service Forwarding Encapsulation ............... 5 70 5. Multi-domain Service Forwarding Example ..................... 6 71 6. Security Considerations ..................................... 8 72 7. IANA Considerations ......................................... 8 73 8. Conclusions ................................................. 8 74 9. References .................................................. 8 75 9.1. Normative References ................................... 8 76 9.2. Informative References ................................. 9 77 10. Acknowledgments ............................................ 9 79 1. Introduction 81 Service Function Chaining (SFC) [RFC7665] is an architecture proposed 82 to decouple traditional network service functions with corresponding 83 physical resources. It is flexible and convenient for the network 84 operator to deploy on-demand service functions and steer the traffic 85 through them in sequence. 87 Network Service Header (NSH) [RFC8300] is defined as a data plane 88 protocol to create dynamic service function chains. According to the 89 NSH encapsulation, the flow can pass along pre-defined Service 90 Function Path and exchange metadata among the Service Classifier, the 91 Service Function and the Service Function Forwarder for information 92 sharing. 94 Network service forwarding in SFC is based on the combination of 95 Service Path Identifier (SPI) and Service index (SI), which are 96 defined in [RFC8300]. [I-D.kumar-sfc-nsh-forwarding] analyzes the NSH 97 forwarding shortcomings and further discusses the separation of the 98 service forwarding and the service delivery. However, it focuses on 99 infrastructure service forwarding for NSH in a single domain. 100 [RFC8459] proposes a hierarchical way to achieve multi-domain 101 forwarding for SFC, which can be regarded as a vertical approach. 102 Contrast to the vertical approach, a horizontal one is easy to scale 103 in and out. Besides, the horizontal approach can decrease the 104 overhead of the control plane, because it maintains more service 105 traffic in the data plane. 107 Therefore, this document proposes a horizontal approach to achieve 108 multi-domain service forwarding for NSH. The main idea is to divide a 109 multi-domain SFC into several segmental SFCs according to domain 110 partitions in the control plane and create corresponding SFPs in each 111 domain by its classifier independently. A label is proposed to 112 identify different cross-domain flows, which is encapsulated in the 113 metadata. 115 1.1. Requirement Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [RFC2119]. 121 2. Multi-domain Service Forwarding Mechanism 123 +---------------------------------------------------+ 124 | | 125 | Control Plane | 126 | | 127 +-----+----------------+----------------------+-----+ 128 | | | 129 |Segmental |Segmental |Segmental 130 |SFC-1 |SFC-2 |SFC-N 131 | | | 132 +-----v-----+ +-----v-----+ +-----v-----+ 133 | | | | | | 134 ----> Domain 1 +----> Domain 2 +->......--> Domain N +---> 135 | | | | | | 136 +-----------+ +-----------+ +-----------+ 137 Figure 1 Multi-domain SFC Divide 139 As shown in Figure 1, according to requirements, it divides the whole 140 SFC in the control plane and issues cross-domain forwarding tables to 141 corresponding classifiers initially. Multi-domain service forwarding 142 includes two aspects: the inter-domain service forwarding and the 143 intra-domain service forwarding. The former is based on a unique 144 label for each flow, and the latter is performed by the classifier. 145 To achieve a unified service forwarding mechanism in multi-domain, 146 this mechanism uses metadata in NSH encapsulation to carry the 147 necessary forwarding information among different forwarding elements, 148 such as the Service Classifier and the Service Function Forwarder. 150 3. Definition Of Terms 152 This document uses some terms defined in SFC architecture [RFC7665] 153 and NSH [RFC8300] drafts for ease of understanding and the reader is 154 advised to refer to those documents for up to date and additional 155 information. 157 Segmental SFC: The cross-domain SFC is divided into several segmental 158 SFCs according to the domain partition. Each segmental SFC is 159 assigned to its corresponding domain. 161 Service Label: the label used to identify different flows can help 162 the classifier create the SFP by its corresponding segmental SFC, 163 which is issued from SFC control plane. 165 Cross-domain Forwarding Table: There are three columns in the table: 166 Service Label, Next Classifier, and Segmental SFC. The table matches 167 a specific flow with its Service Label. The cross-domain forwarding 168 of the flow is depended on the address of Next Classifier. The Cross- 169 domain Forwarding Table is maintained by SFC control plane and issued 170 to the corresponding classifier according to the Segmental SFC 171 partitions. 173 3.1. Service Function Chaining Segmentation 175 At first, the control plane creates an SFC with a unique Service 176 Label for the flow. Then, the SFC is divided into several segmental 177 SFCs according to physical resource constraints. It is important to 178 note that the control plane MUST NOT specific the SFP directly. The 179 control plane is only responsible to indicate what service functions 180 are required in each domain, and the corresponding SFP MUST be 181 specified by the service classifier. 183 3.2. Inter-domain Service Forwarding 185 The Service Label is proposed to identify different flows when 186 packets need to be cross-domain forwarded. When the service 187 classifier receives packets with NSH encapsulations, it checks the 188 Service Label of the first packet to look up the address of the next 189 classifier in its cross-domain forwarding table, which is issued by 190 SFC control plane. Then the information of next classifier is written 191 into the metadata and will be used by the last SFF in the Segmental 192 SFC. Once the last SFF receives the packet from last SF, which 193 changes the SI to zero, it forwards the packets to next classifier 194 directly without any modification of their NSH encapsulations. 196 The Service Label is only carried by the first packet of a certain 197 flow with specific SPI. It's beneficial to decrease header cost and 198 improve forwarding efficiency. 200 3.3. Classification and Intra-domain Service Forwarding 202 The service classifier creates SFP for each flow according to the 203 segmental SFC in its cross-domain forwarding table. After the control 204 plane assigns segmental SFCs for different domains, the corresponding 205 table is issued to the classifier in each domain. When the packet 206 arrives at the classifier, its Service Label is used to find out the 207 next segmental SFC. Then, the classifier creates an SFP for the flow 208 according to that segmental SFC. 210 In this situation, the classifier in a segmental SFC SHOULD set the 211 SI to the length of the segmental SFC. 213 4. Multi-domain Service Forwarding Encapsulation 215 In order to reduce the overhead of metadata, the context header with 216 MD Type = 0x2 is chosen to support multi-domain service forwarding, 217 Figure 2 shows the allocation of the metadata. 219 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 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Service Path Identifier (SPI) | Service Index | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Metadata Class=0x20 | Type=0x1 |C| Length=0x4 | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 |D|U|U|U| Service Label | Next Classifier | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 Figure 2 Multi-domain Service Forwarding Encapsulation 231 Context Header Allocation Descriptions: 233 Metadata Class: It MUST be set to 0x20 as requested in Section 7. 235 C bit: It SHOULD be set indicating critical metadata exists. 237 Type: It MUST be set to 0x1 for multi-domain service forwarding. 239 Length: Because the length of the context header is constant, it MUST 240 be set to 0x4. 242 D bit: The default value is zero, which means the metadata SHOULD be 243 ignored. When set to 0x1 indicates that this packet needs to be for- 244 warded in multiple domains. 246 Service Label: Identifies different flows with different labels. The 247 service classifier decides the service forwarding path of the packet 248 according to its domain label with a forwarding table issued by the 249 control plane. 251 Next Classifier: Indicates the identifier of the classifier in next 252 domain. Because of the SFC segmentation, each classifier only works 253 in the SFC domain it belongs to. When the current segmental SFC is 254 terminated, the last SFF will query the next segmental domain by this 255 identifier. 257 All other flag fields are reserved for future use. Unassigned bits(U) 258 MUST be set to zero and MUST be ignored upon receipt. 260 5. Multi-domain Service Forwarding Example 262 +----------+ +----------+ +----------+ 263 | | | | | | 264 Domain1 | SF-a | | SF-b | Domain2 | SF-c | 265 | | | | | | 266 +---^--+---+ +---^--+---+ +---^--+---+ 267 | | | | | | 268 +-------+ +---+--v---+ +---+--v---+ +-------+ +---+--v---+ 269 | | | | | | | | | | 270 ---> CF1 +-> SFF1-1 +-> SFF1-2 +----> CF2 +-> SFF2-1 +---> 271 | | | | | | | | | | 272 +-------+ +----------+ +----------+ +-------+ +----------+ 273 Figure 3 Multi-domain Service Forwarding Example 275 This section describes the scenario shown in Figure 3, a packet flow 276 pass through three service functions deployed in two domains. The 277 Domain1 is consist of CF1, SFF1-1, SFF1-2, SF-a and SF-b; the Domain2 278 is consist of CF2, SFF2-1 and SF-c. The workflow is as follow: 280 1.SFC control plane creates the SFC with a Service Label for the 281 specific flow and divides the whole SFC into several segmental SFCs. 283 2.The cross-domain forwarding table is issued to its corresponding 284 classifier with specific Service Label, Next Classifier and Segmental 285 SFC. 287 3.CF1(the classifier in domain1) creates the SFP and the NSH 288 encapsulation for the first packet of a certain flow according to its 289 segmental SFC in domain1. It sets 'D' flag to 1 and fills in the 290 Service Label, and Next Classifier. The SI is set to the length of 291 this segmental SFC. 293 4.CF1 forwards the packet to SFF1-1. 295 5.SFF1-1 determines SF-a as the next hop and forwards the packet. 297 6.After SF-a processes the packet, the packet is forwarded back to 298 SFF with decremented SI. 300 7.SFF1-1 forwards the received packet to SFF1-2. 302 8.SFF1-2 determines SF-a as the next hop and forwards the packet. 304 9.Similar to SF-a, SF-b forwards the packet to SFF1-2 and decrements 305 SI to zero. 307 10.When SFF1-2 receives the packet, it finds out that the segmental 308 SFC is terminate in this domain because of the SI, and then SFF1-2 309 forwards the packet to next classifier without modification of the 310 NSH encapsulation. The following packets of this flow (in the same 311 SPI in this domain) are forwarded with the same routing information. 313 11.When CF2(the classifier in domain2) receives the first packet with 314 an NSH encapsulation, CF2 will check its Service Label. 316 12.According to the Service Label, CF2 looks up segmental SFC in the 317 cross-domain forwarding table and creates the corresponding SFP and 318 the NSH encapsulation. 320 13.CF2 sets the 'D' flag to zero and forwards the packet to SFF2-1. 321 The action of its following packets is similar. 323 13.SFF2-1 determines SF-c as the next hop and forwards the packet. 325 14.SFC processes the packet and forwards it back to SFF2-1 with 326 decremented SI. 328 15.SFF2-1 finds out that the SFP is terminate and forwards the packet 329 to the final Receiver. 331 6. Security Considerations 333 As with many other protocols, metadata of the NSH encapsulation can 334 be spoofed or otherwise modified. It is important to protect the 335 cross-domain packet from malicious modification because the metadata 336 contains sensitive information about the user and environment. 337 Therefore, it is significate to ensure the integrity of the metadata 338 and provide the protection of the user privacy. 340 7. IANA Considerations 342 IANA is requested to allocate a new class from the TLV Class defined 343 in [RFC8300]. 345 0x20 Multi-domain Forwarding Type 347 IANA is requested to set up a registry of "NSH Multi-domain Service 348 Forwarding TLV Types". These are 7-bit values. Registry entries 349 are assigned by using the "IETF Review" policy defined in [RFC8126]. 351 IANA is requested to allocate two new types as follows: 353 o Type = 0x00 Reserved 355 o Type = 0x01 Multi-domain Service Forwarding 357 8. Conclusions 359 This document proposes a mechanism for multi-domain service forward- 360 ing based on a unique label. In order to relieve the pressure of the 361 control plane, the multi-domain SFC is divided into segmental SFC 362 according to the domain partitions, and the SFP in each domain is 363 created independently. 365 9. References 367 9.1. Normative References 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, March 1997. 372 [RFC8300] P. Quinn, Ed., U. Elzur, Ed. and C. Pignataro, Ed. "Network 373 Service Header (NSH)", January 2018. 375 9.2. Informative References 377 [RFC8126] M. Cotton, B. Leiba and T. Narten, "Guidelines for Writing 378 an IANA Considerations Section in RFCs", BCP 26, RFC 8126, 379 June 2017. 381 [RFC7665] J. Halpern, Ed. and C. Pignataro, Ed. "Service Function 382 Chaining (SFC) Architecture", October 2015. 384 [RFC8459] D. Dolson, S. Homma, D. Lopez, et al. "Hierarchical Service 385 Function Chaining", September 2018. 387 [I-D.kumar-sfc-nsh-forwarding] 389 S. Kumar, K. Leung, P. Bosch, et al. "Infrastructure 390 Service Forwarding For NSH", draft-kumar-sfc-nsh- 391 forwarding-01, August 2016. 393 10. Acknowledgments 395 This work in this document was supported by National High Technology 396 of China ("863 program") under Grant No.2015AA015702. 398 Authors' Addresses 400 Guanwen Li 401 Beijing Jiaotong University 402 Beijing 100044, P.R. China 404 Email: 16111011@bjtu.edu.cn 406 Guanglei Li 407 Beijing Jiaotong University 408 Beijing 100044, P.R. China 410 Email: 15111035@bjtu.edu.cn 412 Taixin Li 413 Beijing Jiaotong University 414 Beijing 100044, P.R. China 416 Email: 14111040@bjtu.edu.cn 418 Qi Xu 419 Beijing Jiaotong University 420 Beijing 100044, P.R. China 422 Email: 15111046@bjtu.edu.cn 424 Bohao Feng 425 Beijing Jiaotong University 426 Beijing 100044, P.R. China 428 Email: bhfeng@bjtu.edu.cn 430 Huachun Zhou 431 Beijing Jiaotong University 432 Beijing 100044, P.R. China 434 Email: hchzhou@bjtu.edu.cn