idnits 2.17.1 draft-li-sfc-nsh-multi-domain-01.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 (October 21, 2016) is 2744 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: April 22, 2017 Qi Xu 5 Bohao Feng 6 Huachun Zhou 7 Beijing Jiaotong University 8 October 21, 2016 10 Multi-domain Service Forwarding For NSH 11 draft-li-sfc-nsh-multi-domain-01 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 April 22, 2017. 35 Copyright Notice 37 Copyright (c) 2016 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 purposed 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 purposed 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 ........................ 4 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...................................... 7 72 7. IANA Considerations ......................................... 8 73 8. Conclusions ................................................. 8 74 9. References .................................................. 8 75 9.1. Normative References.................................... 8 76 9.2. Informative References.................................. 8 77 10. Acknowledgments ............................................ 9 79 1. Introduction 81 Service Function Chaining (SFC) [RFC7665] is an architecture purposed 82 to decouple traditional network service functions with corresponding 83 physical resources. It is flexible and convenience for a network 84 operator to deploy on-demand service functions and steer the traffic 85 through them in sequence. 87 Network Service Header (NSH) [I-D.ietf-sfc-nsh] is defined as a data 88 plane protocol to create a dynamic service function chaining. 89 According to the NSH encapsulation, the flow can pass along its 90 service function path and exchange metadata among the Service 91 Classifier, the Service Function and the Service Function Forwarder 92 for information sharing. 94 Network service forwarding in SFC is based on the combination of 95 Service Path Identifier (SPI) and Service index (SI), which is 96 described in [I-D.ietf-sfc-nsh]. [I-D.kumar-sfc-nsh-forwarding] 97 analyzes the NSH forwarding shortcomings and further discusses the 98 separation of the service forwarding and the service delivery. 99 However, it focuses on infrastructure service forwarding for NSH in 100 single domain. [I-D.ietf-sfc-hierarchical] purpose a hierarchical way 101 to achieves multi-domain SFC, which can be regarded as a vertical 102 approach. Contrast to the vertical approach, a horizontal one is easy 103 to scale in and out. Besides, the horizontal approach can decrease 104 the overhead of the control plane, because it maintains more service 105 traffic in the data plane. 107 Therefore, this document purposes 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 SFP in each 111 domain by its classifier independently. A label is purposed 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 ----> Domain1 +----> Domain2 +->......--> DomainN +---> 135 | | | | | | 136 +-----------+ +-----------+ +-----------+ 137 Figure 1 Multi-domain SFC Divide 139 As shown in Figure 1, SFC control plane divides the whole SFC and 140 issues cross-domain forwarding tables to corresponding classifiers 141 initially. Multi-domain service forwarding includes two aspects: the 142 inter-domain service forwarding and the intra-domain forwarding. The 143 former is based on a unique label for each flow, and the latter is 144 performed by the classifier. To achieve a unify service forwarding 145 mechanism in multi-domain, this mechanism uses metadata in NSH 146 encapsulation to carry the necessary forwarding information among 147 different forwarding elements, such as the Service Classifier and the 148 Service Function Forwarder. 150 3. Definition Of Terms 152 This document uses some terms defined in SFC architecture [RFC7665] 153 and NSH [I-D.ietf-sfc-nsh] drafts for ease of understanding and the 154 reader is advised to refer to those documents for up to date and 155 additional information. 157 Segmental SFC: The cross-domain SFC is divided into several segmental 158 SFCs according to the domain partitions. Each segmental SFC is 159 assigned to its corresponding domain. 161 Service Label: A label used to identify different flows can help the 162 classifier create the SFP by its corresponding segmental SFC, which 163 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 a 167 specific flow with its Service Label. The cross-domain forwarding of 168 a 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 corresponding classifier according to the Segmental SFC. 172 3.1. Service Function Chaining Segmentation 174 At first, the orchestrator in SFC control plane creates a SFC with a 175 unique Service Label for the flow. Then, the SFC is divided into 176 several segmental SFCs according to physical resource constraints. It 177 is important to note that the control plane MUST NOT specific the SFP 178 directly. The control plane is only responsible to indicate what 179 service functions are required in each domain, and the corresponding 180 SFP MUST be specified by the service classifier. 182 3.2. Inter-domain Service Forwarding 184 The Service Label is purposed to identify different flows when 185 packets need to be cross-domain forwarded. When the service 186 classifier receives a packet with the NSH encapsulation, it firstly 187 checks the Service Label of the packet to look up the address of the 188 next classifier in its cross-domain forwarding table. The table is 189 issued by SFC control plane. Then the information of next classifier 190 is written into the metadata and will be used by the last SFF in the 191 domain. Once the last SFF receives the packet from last SF in the 192 domain, which changes the SI to zero, it forwards the packet to next 193 classifier directly without any modification of the encapsulation. 195 The Service Label is only carried by the first packet of a certain 196 flow with specific SPI. It's beneficial to decrease header cost and 197 improve forwarding efficiency. 199 3.3. Classification and Intra-domain Service Forwarding 201 The service classifier creates SFP for each flow according to the 202 segmental SFC in its cross-domain forwarding table. After the control 203 plane assigns segmental SFCs for different domains, the corresponding 204 table is issued to the classifier in each domain. When the packet 205 with an NSH encapsulation arrives at the classifier, its Service 206 Label is used to find out the corresponding segmental SFC. Then, the 207 classifier creates a SFP for the flow according to its segmental SFC. 209 4. Multi-domain Service Forwarding Encapsulation 211 In order to reduce overhead of metadata, the context header with MD 212 Type = 0x2 is chosen to support multi-domain service forwarding, 213 Figure 2 shows the allocation of the metadata. 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 |Ver|O|C|R|R|R|R|R|R| Length | MD-type=0x2 | Next Protocol | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Service Path Identifier (SPI) | Service Index | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Metadata Class=0x20 |C| Type=0x1 |R|R|R| Len=0x4 | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 |D|R|R|R| Service Label | Next Classifier | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 Figure 2 Multi-domain Service Forwarding Encapsulation 227 Context Header Allocation Descriptions: 229 Metadata Class: It MUST be set to 0x20 as requested in Section 7. 231 C bit: It SHOULD be set indicating critical metadata exists. 233 Type: It MUST be set to 0x1 for multi-domain service forwarding. 235 Len: Because the length of the context header is constant, it MUST be 236 set to 0x4. 238 D bit: The default value is zero, which means the metadata SHOULD be 239 ignored. When set to 0x1 indicates that this packet need to be for- 240 warded in multiple domains. 242 Service Label: Identifies different flows with different labels. The 243 service classifier decides the service forwarding path of the packet 244 according to its domain label with a forwarding table issued by 245 control plane. 247 Next Classifier: Indicates the address of the classifier in next 248 domain. Because of the SFC segmentation, each classifier only works 249 in the SFC domain it belongs to. When a packet leaves current domain, 250 it will notice the last SFF where is the next classifier. 252 All other flag fields are reserved for future use. Reserved bits MUST 253 be set to zero and MUST be ignored upon receipt. 255 5. Multi-domain Service Forwarding Example 257 +----------+ +----------+ +----------+ 258 | | | | | | 259 Domain1 | SF-a | | SF-b | Domain2 | SF-c | 260 | | | | | | 261 +---^--+---+ +---^--+---+ +---^--+---+ 262 | | | | | | 263 +-------+ +---+--v---+ +---+--v---+ +-------+ +---+--v---+ 264 | | | | | | | | | | 265 ---> CF1 +-> SFF1-1 +-> SFF1-2 +----> CF2 +-> SFF2-1 +---> 266 | | | | | | | | | | 267 +-------+ +----------+ +----------+ +-------+ +----------+ 268 Figure 3 Multi-domain Service Forwarding Example 270 This section describes the scenario shown in Figure 3, a packet flow 271 pass through tree service functions deployed in two domains. The 272 Domain1 is consist of CF1, SFF1-1, SFF1-2, SF-a and SF-b; the Domain2 273 is consist of CF2, SFF2-1 and SF-c. The workflow is as follow: 275 1.SFC control plane creates the SFC with a Service Label for the 276 specific flow and divides the whole SFC into several segmental SFCs. 278 2.The cross-domain forwarding table is issued to its corresponding 279 classifier with Service Label, Next Classifier and Segmental SFC. 281 3.CF1(the classifier in domain1) creates the SFP and the NSH 282 encapsulation for the first packet of a certain flow according to its 283 segmental SFC in domain1. It sets 'D' flag to 1 and fills in the 284 Service Label and Next Classifier. 286 4.CF1 forwards the packet to SFF1-1. 288 5.SFF1-1 determines SF-a as the next hop and forwards the packet. 290 6.After SF-a processes the packet, the packet is forwarded back to 291 SFF with decremented SI. 293 7.SFF1-1 forwards the received packet to SFF1-2. 295 8.SFF1-2 determines SF-a as the next hop and forwards the packet. 297 9.Similar to SF-a, SF-b forwards the packet to SFF1-2 and decrements 298 SI to zero. 300 10.When SFF1-2 receives the packet, it finds out that the SFP is 301 terminate in this domain because of the SI, and then SFF1-2 forwards 302 the packet to next classifier without modification of the NSH 303 encapsulation. The following packets of this flow (in same SPI) are 304 forwarded with the same routing information. 306 11.When CF2(the classifier in domain2) receives the first packet with 307 an NSH encapsulation, CF2 will checks its Service Label. 309 12.Accroding to the Service Label, CF2 looks up segmental SFC in the 310 cross-domain forwarding table and creates the corresponding SFP and 311 the NSH encapsulation. 313 13.CF2 sets the 'D' flag to zero and forwards the packet to SFF2-1. 314 The action of its following packets are similar. 316 13.SFF2-1 determines SF-c as the next hop and forwards the packet. 318 14.SFc processes the packet and forwards it back to SFF2-1 with 319 decremented SI. 321 15.SFF2-1 finds out that the SFP is terminate and forwards the packet 322 to the final Receiver. 324 6. Security Considerations 326 As with many other protocols, metadata of the NSH encapsulation can 327 be spoofed or otherwise modified. It is important to protect the 328 cross-domain packet from malicious modification, because the metadata 329 contains sensitive information about the user and environment. 330 Therefore, it is significate to ensure the integrity of the metadata 331 and provide the protection of the user privacy. 333 7. IANA Considerations 335 IANA is requested to allocate a new class from the TLV Class defined 336 in [I-D.ietf-sfc-nsh]. 338 0x20 Multi-domain Forwarding Type 340 IANA is requested to set up a registry of "NSH Multi-domain Service 341 Forwarding TLV Types". These are 7-bit values. Registry entries 342 are assigned by using the "IETF Review" policy defined in [RFC5226]. 344 IANA is requested to allocate two new types as follows: 346 o Type = 0x00 Reserved 348 o Type = 0x01 Multi-domain Service Forwarding 350 8. Conclusions 352 This document purposes a mechanism for multi-domain service forward- 353 ing based on a unique label. In order to relieve the pressure of the 354 control plane, the multi-domain SFC is divided into segmental SFC 355 according to the domain partitions, and the SFP in each domain is 356 created independently. 358 9. References 360 9.1. Normative References 362 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 363 Requirement Levels", BCP 14, RFC 2119, March 1997. 365 [I-D.ietf-sfc-nsh] 367 Quinn, P. and U. Elzur, "Network Service Header", draft- 368 ietf-sfc-nsh-10 (work in progress), September 2016. 370 9.2. Informative References 372 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 373 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 374 2008. 376 [RFC7665] J. Halpern, Ed. and C. Pignataro, Ed. "Service Function 377 Chaining (SFC) Architecture", October 2015. 379 [I-D.ietf-sfc-hierarchical] 381 D. Dolson, S. Homma, D. Lopez, et al. "Hierarchical Service 382 Function Chaining", draft-ietf-sfc-hierarchical-01 (work in 383 progress), September 2016. 385 [I-D.kumar-sfc-nsh-forwarding] 387 S. Kumar, K. Leung, P. Bosch, et al. "Infrastructure 388 Service Forwarding For NSH", draft-kumar-sfc-nsh- 389 forwarding-01 (work in progress), August 2016. 391 10. Acknowledgments 393 This work in this document was supported by National High Technology 394 of China ("863 program") under Grant No.2015AA015702. 396 Authors' Addresses 398 Guanwen Li 399 Beijing Jiaotong University 400 Beijing 100044, P.R. China 402 Email: 14120079@bjtu.edu.cn 404 Guanglei Li 405 Beijing Jiaotong University 406 Beijing 100044, P.R. China 408 Email: 15111035@bjtu.edu.cn 410 Taixin Li 411 Beijing Jiaotong University 412 Beijing 100044, P.R. China 414 Email: 14111040@bjtu.edu.cn 416 Qi Xu 417 Beijing Jiaotong University 418 Beijing 100044, P.R. China 420 Email: 15111046@bjtu.edu.cn 422 Bohao Feng 423 Beijing Jiaotong University 424 Beijing 100044, P.R. China 426 Email: 11111021@bjtu.edu.cn 428 Huachun Zhou 429 Beijing Jiaotong University 430 Beijing 100044, P.R. China 432 Email: hchzhou@bjtu.edu.cn