idnits 2.17.1 draft-li-sfc-nsh-multi-domain-02.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 (April 18, 2017) is 2559 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) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). 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: October 19, 2017 Qi Xu 5 Bohao Feng 6 Huachun Zhou 7 Beijing Jiaotong University 8 April 18, 2017 10 Multi-domain Service Forwarding For NSH 11 draft-li-sfc-nsh-multi-domain-02 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 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on October 19, 2017. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with 46 respect to this document. Code Components extracted from this 47 document must include Simplified BSD License text as described in 48 Section 4.e of the Trust Legal Provisions and are provided without 49 warranty as described in the Simplified BSD License. 51 Abstract 53 This document describes the mechanism to achieve multi-domain ser- 54 vice forwarding for NSH. The proposed mechanism adopts a horizontal 55 deployment structure, which divides a multi-domain SFC into several 56 segmental SFCs in the control plane and each domain creates its own 57 SFP independently in data plane. A label is proposed to identify 58 different cross-domain flows at the classifier by extending the 59 metadata of the NSH encapsulation. 61 Table of Contents 63 1. Introduction ................................................ 2 64 1.1. Requirement Language ................................... 3 65 2. Definition Of Terms ......................................... 4 66 3. Multi-domain Service Forwarding Mechanism ................... 3 67 3.1. Service Function Chaining Segmentation ................. 4 68 3.2. Inter-domain Service Forwarding ........................ 4 69 3.3. Classification and Intra-domain Service Forwarding ..... 5 70 4. Multi-domain Service Forwarding Encapsulation ............... 5 71 5. Multi-domain Service Forwarding Example ..................... 6 72 6. Security Considerations ..................................... 8 73 7. IANA Considerations ......................................... 8 74 8. Conclusions ................................................. 8 75 9. References .................................................. 8 76 9.1. Normative References ................................... 8 77 9.2. Informative References ................................. 9 78 10. Acknowledgments ............................................ 9 80 1. Introduction 82 Service Function Chaining (SFC) [RFC7665] is an architecture proposed 83 to decouple traditional network service functions with corresponding 84 physical resources. It is flexible and convenience for a network 85 operator to deploy on-demand service functions and steer the traffic 86 through them in sequence. 88 Network Service Header (NSH) [I-D.ietf-sfc-nsh] is defined as a data 89 plane protocol to create a dynamic service function chaining. 90 According to the NSH encapsulation, the flow can pass along its 91 service function path and exchange metadata among the Service 92 Classifier, the Service Function and the Service Function Forwarder 93 for information sharing. 95 Network service forwarding in SFC is based on the combination of 96 Service Path Identifier (SPI) and Service index (SI), which is 97 described in [I-D.ietf-sfc-nsh]. [I-D.kumar-sfc-nsh-forwarding] 98 analyzes the NSH forwarding shortcomings and further discusses the 99 separation of the service forwarding and the service delivery. 100 However, it focuses on infrastructure service forwarding for NSH in 101 single domain. [I-D.ietf-sfc-hierarchical] propose a hierarchical way 102 to achieves multi-domain SFC, which can be regarded as a vertical 103 approach. Contrast to the vertical approach, a horizontal one is easy 104 to scale in and out. Besides, the horizontal approach can decrease 105 the overhead of the control plane, because it maintains more service 106 traffic in the data plane. 108 Therefore, this document proposes a horizontal approach to achieve 109 multi-domain service forwarding for NSH. The main idea is to divide 110 a multi-domain SFC into several segmental SFCs according to domain 111 partitions in the control plane and create corresponding SFP in each 112 domain by its classifier independently. A label is proposed to 113 identify different cross-domain flows, which is encapsulated in the 114 metadata. 116 1.1. Requirement Language 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [RFC2119]. 122 2. Multi-domain Service Forwarding Mechanism 124 +---------------------------------------------------+ 125 | | 126 | Control Plane | 127 | | 128 +-----+----------------+----------------------+-----+ 129 | | | 130 |Segmental |Segmental |Segmental 131 |SFC-1 |SFC-2 |SFC-N 132 | | | 133 +-----v-----+ +-----v-----+ +-----v-----+ 134 | | | | | | 135 ----> Domain1 +----> Domain2 +->......--> DomainN +---> 136 | | | | | | 137 +-----------+ +-----------+ +-----------+ 138 Figure 1 Multi-domain SFC Divide 140 As shown in Figure 1, SFC control plane divides the whole SFC and 141 issues cross-domain forwarding tables to corresponding classifiers 142 initially. Multi-domain service forwarding includes two aspects: the 143 inter-domain service forwarding and the intra-domain forwarding. The 144 former is based on a unique label for each flow, and the latter is 145 performed by the classifier. To achieve a unify service forwarding 146 mechanism in multi-domain, this mechanism uses metadata in NSH 147 encapsulation to carry the necessary forwarding information among 148 different forwarding elements, such as the Service Classifier and 149 the Service Function Forwarder. 151 3. Definition Of Terms 153 This document uses some terms defined in SFC architecture [RFC7665] 154 and NSH [I-D.ietf-sfc-nsh] drafts for ease of understanding and the 155 reader is advised to refer to those documents for up to date and 156 additional information. 158 Segmental SFC: The cross-domain SFC is divided into several segmental 159 SFCs according to the domain partitions. Each segmental SFC is 160 assigned to its corresponding domain. 162 Service Label: A label used to identify different flows can help the 163 classifier create the SFP by its corresponding segmental SFC, which 164 is issued from SFC control plane. 166 Cross-domain Forwarding Table: There are three columns in the table: 167 Service Label, Next Classifier and Segmental SFC. The table matches a 168 specific flow with its Service Label. The cross-domain forwarding of 169 a flow is depended on the address of Next Classifier. The Cross- 170 domain Forwarding Table is maintained by SFC control plane and issued 171 to corresponding classifier according to the Segmental SFC. 173 3.1. Service Function Chaining Segmentation 175 At first, the SFC control plane creates a 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 a packet with the NSH encapsulation, it firstly 188 checks the Service Label of the packet to look up the address of the 189 next classifier in its cross-domain forwarding table. The table is 190 issued by SFC control plane. Then the information of next classifier 191 is written into the metadata and will be used by the last SFF in the 192 domain. Once the last SFF receives the packet from last SF in the 193 domain, which changes the SI to zero, it forwards the packet to next 194 classifier directly without any modification of the encapsulation. 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 with an NSH encapsulation arrives at the classifier, its Service 207 Label is used to find out the corresponding segmental SFC. Then, the 208 classifier creates a SFP for the flow according to its 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 overhead of metadata, the context header with MD 216 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|C|R|R|R|R|R|R| Length | MD-type=0x2 | Next Protocol | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Service Path Identifier (SPI) | Service Index | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Metadata Class=0x20 |C| Type=0x1 |R| Len=0x4 | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 |D|R|R|R| 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 Len: Because the length of the context header is constant, it MUST be 240 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 need 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 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 terminate, the last SFF will query the next segmental domain by this 255 identifier. 257 All other flag fields are reserved for future use. Reserved bits MUST 258 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 tree 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 Service Label, Next Classifier and Segmental SFC. 286 3.CF1(the classifier in domain1) creates the SFP and the NSH 287 encapsulation for the first packet of a certain flow according to its 288 segmental SFC in domain1. It sets 'D' flag to 1 and fills in the 289 Service Label and Next Classifier. The SI is set to the length of 290 this segmental SFC. 292 4.CF1 forwards the packet to SFF1-1. 294 5.SFF1-1 determines SF-a as the next hop and forwards the packet. 296 6.After SF-a processes the packet, the packet is forwarded back to 297 SFF with decremented SI. 299 7.SFF1-1 forwards the received packet to SFF1-2. 301 8.SFF1-2 determines SF-a as the next hop and forwards the packet. 303 9.Similar to SF-a, SF-b forwards the packet to SFF1-2 and decrements 304 SI to zero. 306 10.When SFF1-2 receives the packet, it finds out that the segmental 307 SFC is terminate in this domain because of the SI, and then SFF1-2 308 forwards the packet to next classifier without modification of the 309 NSH encapsulation. The following packets of this flow (in same SPI in 310 this domain) are forwarded with the same routing information. 312 11.When CF2(the classifier in domain2) receives the first packet with 313 an NSH encapsulation, CF2 will checks its Service Label. 315 12.Accroding to the Service Label, CF2 looks up segmental SFC in the 316 cross-domain forwarding table and creates the corresponding SFP and 317 the NSH encapsulation. 319 13.CF2 sets the 'D' flag to zero and forwards the packet to SFF2-1. 320 The action of its following packets are similar. 322 13.SFF2-1 determines SF-c as the next hop and forwards the packet. 324 14.SFc processes the packet and forwards it back to SFF2-1 with 325 decremented SI. 327 15.SFF2-1 finds out that the SFP is terminate and forwards the packet 328 to the final Receiver. 330 6. Security Considerations 332 As with many other protocols, metadata of the NSH encapsulation can 333 be spoofed or otherwise modified. It is important to protect the 334 cross-domain packet from malicious modification, because the metadata 335 contains sensitive information about the user and environment. 336 Therefore, it is significate to ensure the integrity of the metadata 337 and provide the protection of the user privacy. 339 7. IANA Considerations 341 IANA is requested to allocate a new class from the TLV Class defined 342 in [I-D.ietf-sfc-nsh]. 344 0x20 Multi-domain Forwarding Type 346 IANA is requested to set up a registry of "NSH Multi-domain Service 347 Forwarding TLV Types". These are 7-bit values. Registry entries 348 are assigned by using the "IETF Review" policy defined in [RFC5226]. 350 IANA is requested to allocate two new types as follows: 352 o Type = 0x00 Reserved 354 o Type = 0x01 Multi-domain Service Forwarding 356 8. Conclusions 358 This document proposes a mechanism for multi-domain service forward- 359 ing based on a unique label. In order to relieve the pressure of the 360 control plane, the multi-domain SFC is divided into segmental SFC 361 according to the domain partitions, and the SFP in each domain is 362 created independently. 364 9. References 366 9.1. Normative References 368 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 369 Requirement Levels", BCP 14, RFC 2119, March 1997. 371 [I-D.ietf-sfc-nsh] 373 Quinn, P. and U. Elzur, "Network Service Header", draft- 374 ietf-sfc-nsh-12 (work in progress), February 2017. 376 9.2. Informative References 378 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 379 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 380 2008. 382 [RFC7665] J. Halpern, Ed. and C. Pignataro, Ed. "Service Function 383 Chaining (SFC) Architecture", October 2015. 385 [I-D.ietf-sfc-hierarchical] 387 D. Dolson, S. Homma, D. Lopez, et al. "Hierarchical Service 388 Function Chaining", draft-ietf-sfc-hierarchical-02 (work in 389 progress), January 2017. 391 [I-D.kumar-sfc-nsh-forwarding] 393 S. Kumar, K. Leung, P. Bosch, et al. "Infrastructure 394 Service Forwarding For NSH", draft-kumar-sfc-nsh- 395 forwarding-01, August 2016. 397 10. Acknowledgments 399 This work in this document was supported by National High Technology 400 of China ("863 program") under Grant No.2015AA015702. 402 Authors' Addresses 404 Guanwen Li 405 Beijing Jiaotong University 406 Beijing 100044, P.R. China 408 Email: 14120079@bjtu.edu.cn 410 Guanglei Li 411 Beijing Jiaotong University 412 Beijing 100044, P.R. China 414 Email: 15111035@bjtu.edu.cn 416 Taixin Li 417 Beijing Jiaotong University 418 Beijing 100044, P.R. China 420 Email: 14111040@bjtu.edu.cn 422 Qi Xu 423 Beijing Jiaotong University 424 Beijing 100044, P.R. China 426 Email: 15111046@bjtu.edu.cn 428 Bohao Feng 429 Beijing Jiaotong University 430 Beijing 100044, P.R. China 432 Email: 11111021@bjtu.edu.cn 434 Huachun Zhou 435 Beijing Jiaotong University 436 Beijing 100044, P.R. China 438 Email: hchzhou@bjtu.edu.cn