idnits 2.17.1 draft-ao-sfc-transport-00.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 : ---------------------------------------------------------------------------- ** There are 24 instances of too long lines in the document, the longest one being 29 characters in excess of 72. 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 (October 20, 2018) is 1986 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-nvo3-geneve' is defined on line 360, but no explicit reference was found in the text == Unused Reference: 'RFC1701' is defined on line 370, but no explicit reference was found in the text == Unused Reference: 'RFC8126' is defined on line 380, but no explicit reference was found in the text == Unused Reference: 'RFC7665' is defined on line 396, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-nvo3-geneve-08 == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-06 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC WG T. Ao 3 Internet-Draft ZTE Corporation 4 Intended status: Informational W. Wei 5 Expires: April 23, 2019 Y. Zheng 6 ZTE Corp. 7 October 20, 2018 9 SFC transport considertation 10 draft-ao-sfc-transport-00 12 Abstract 14 A Network Service Header(NSH) is imposed encapsulates a packet or a 15 frame for Service Function Chaining. The resulting packet, in turn, 16 is encapsulate according to transport layer. The NSH contains a 17 Service Path Identifier (SPI) and a Service Index (SI). The SPI is, 18 as per its name, an identifier. The SPI alone cannot be used to 19 forward packets along a service path. Rather, the SPI provides a 20 level of indirection between the service path / topology and the 21 network transport encapsulation. For different transport 22 encapsulations, this document provides the format information with 23 transport and NSH, and gives operational constraints that transport 24 technologies, used by NSH need to meet. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 23, 2019. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Conventions used in this document . . . . . . . . . . . . . . 4 62 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 64 3. Ethernet as transport . . . . . . . . . . . . . . . . . . . . 4 65 3.1. Format in encapsulation . . . . . . . . . . . . . . . . . 4 66 3.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4. VXLAN-GPE as transport . . . . . . . . . . . . . . . . . . . 6 68 4.1. Format in encapsulation . . . . . . . . . . . . . . . . . 6 69 4.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 6 70 5. GRE as transport . . . . . . . . . . . . . . . . . . . . . . 7 71 5.1. Format in encapsulation . . . . . . . . . . . . . . . . . 7 72 5.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 7 73 6. GENEVE as transport . . . . . . . . . . . . . . . . . . . . . 8 74 6.1. Format in encapsulation . . . . . . . . . . . . . . . . . 8 75 6.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 8 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 81 10.2. Informational References . . . . . . . . . . . . . . . . 9 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 84 1. Introduction 86 For SFC using NSH, NSH is imposed on original packets/frames. NSH 87 hearder format is defined in [RFC8300] as Figure 1. NSH is transport 88 encapsulation agnostic, and SFC packet can't be forwarded or 89 transmitted along without the transport layer support. So how does 90 the different transport technologies bear SFC service traffic is what 91 is discussed in this document. 93 +------------------------------+ 94 | Transport Encapsulation | 95 +------------------------------+ 96 | Network Service Header (NSH) | 97 +------------------------------+ 98 | Original Packet / Frame | 99 +------------------------------+ 100 Figure 1 102 Figure 1: Network Service Header Encapsulation 104 The NSH is composed of a 4-byte Base Header, a 4-byte Service Path 105 Header, and optional Context Headers, as shown in Figure 2. 107 0 1 2 3 108 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 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Base Header | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | Service Path Header | 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | | 115 ~ Context Header(s) ~ 116 | | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 Figure 2 120 Figure 2: Network Service Header 122 In the Base Header part, a Next Protocol field is provided to 123 indicate the protocol type of the payload. The value definition is: 125 o 0x1: IPv4 127 o 0x2: IPv6 129 o 0x3: Ethernet 131 o 0x4: NSH 133 o 0x5: MPLS 135 o 0xFE: Experiment 1 137 o 0xFF: Experiment 2 139 This document describes SFC packet over different transport networks, 140 and defines the format for NSH with these different transport 141 protocol. For some situations, some operational constraints also 142 described. 144 2. Conventions used in this document 146 2.1. Terminology 148 SFC(Service Function Chain): An ordered set of some abstract SFs. 150 SFF: Service Function Forwarder 152 SF: Service Function 154 NVE: Network Virtualization Edge 156 VXLAN-GPE: VXLAN Generic Protocol Extension 158 GENEVE: Generic Network Virtualization Encapsulation 160 GRE: Generic Routing Encapsulation 162 2.2. Requirements Language 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 166 "OPTIONAL" in this document are to be interpreted as described in BCP 167 14 [RFC2119] [RFC8174] when, and only when, they appear in all 168 capitals, as shown here. 170 3. Ethernet as transport 172 3.1. Format in encapsulation 174 In an Ethernet network, Ethernet is as transport for SFC traffic. 175 The format for Ethernet to tranport SFC packet should be as Figure 3. 177 +-----------------------------+--------------------------------+---------------------------+ 178 | L2 Header, EtherType=0x894F | NSH Header, Next Protocol=0x01 | Original IPv4 Packet | 179 +-----------------------------+--------------------------------+---------------------------+ 180 Ethernet+ NSH IPv4 packet 182 +-----------------------------+--------------------------------+---------------------------+ 183 | L2 Header, EtherType=0x894F | NSH Header, Next Protocol=0x03 | Original L2 frame | 184 +-----------------------------+--------------------------------+---------------------------+ 185 Ethernet+ NSH L2 frame 186 Figure 3 NSH in Ethernet 188 Figure 3: NSH in Ethernet 190 3.2. Operation 192 1.The Classifier classifies the original packets according to its 193 policies and attach the NSH header. If the network transport is 194 Ethernet, before the Classifier forwards the packet, it adds a L2 195 Header as the outer header. In the outer L2 header, the source MAC 196 address is the MAC address of the Classifier, and the destination MAC 197 address is the MAC address of the first SFF. 199 For the VLAN ID in the L2 header, there should be a policy for impose 200 a VLAN ID. If the original packet is IP Packet, the VLAN ID relies 201 on the Service Function Path assigned to the packet which virtual 202 network it belongs. 204 2.The SFF receives SFC packet from a network interface, checks the 205 SPI and SI in the NSH-to-SF Mapping table, per [RFC8300], to get the 206 locator of SF attached to it, that is MAC address if the transport is 207 Ethernet. SFF modifies the L2 Header to be the destination MAC 208 addess is the SF MAC address, and the source MAC address is the MAC 209 address of the SFF, and then forwards the SFC packet to the SF 210 attached to this SFF. After the processing, the SF will decrement SI 211 in the NSH by a value of 1, and will swap the source MAC address with 212 the destination MAC address of the outer L2 Header, and then the SFC 213 packet is forwarded back to the SFF. Once the SFF receives the SFC 214 packet from SF interface, it will check the SFI and SI in the NSH-to- 215 SF Mapping table again to get the locator of next SFF, that is MAC 216 address of the next SFF if the transport is Ethernet. SFF should 217 modify the L2 Header again to be the the destination MAC address is 218 the next SFF address, and the source MAC address is the MAC address 219 of the SFF. 221 3.When the last SFF receive the SFC packet from the SF attaching to 222 it, it will check the SPI and SI in the NSH-to-SF Mapping table, 223 finding it's the end of the Service Function Path, so it should strip 224 the outer L2 Header and NSH Header before it send out the original 225 packet . 227 4. VXLAN-GPE as transport 229 4.1. Format in encapsulation 231 In an overlay network, VXLAN-GPE is as transport for SFC traffic. 232 The format for VXLAN-GPE to transport SFC packet should be as 233 Figure 4. Here assuming the overlay networks are built on Ethernet. 235 +----------+------------------------+---------------------+--------------+---------------------+ 236 |L2 header | IP + UDP dst port=4790 |VXLAN-gpe NP=0x4(NSH)|NSH, NP=0x1 |original IPv4 packet | 237 +----------+------------------------+---------------------+--------------+---------------------+ 238 VXLAN-GPE+ NSH IPv4 packet 240 +----------+------------------------+---------------------+--------------+---------------------+ 241 |L2 header | IP + UDP dst port=4790 |VXLAN-gpe NP=0x4(NSH)|NSH,NP=0x3 |original L2 frame | 242 +----------+------------------------+---------------------+--------------+---------------------+ 243 VXLAN-GPE+ NSH L2 frame 244 Figure 4 NSH in VXLAN-GPE 246 Figure 4: NSH in Vxlan-GPE 248 4.2. Operation 250 1.The Classifier classifies the original packets according to the 251 classify its policies and attaches the NSH header. If the network 252 transport is VXLAN-GPE, before the Classifier forward the packet, it 253 should add a VXLAN-GPE header first, and then UDP header and IP 254 header. UDP destination port should be 4790 which means the traffic 255 should send to NVE, which has been specified in 256 [I-D.ietf-nvo3-vxlan-gpe]. The destination IP address should be the 257 IP address of the NVE that the first SFF located. For the VNID in 258 the VXLAN-GPE header, there should be a policy for impose a VNID. If 259 the original frame has VLAN ID, there would be a mapping between VLAN 260 ID and VNID. 262 2.The SFF receives SFC packet from network interface, remove the 263 outer header and checks the SPI and SI in the NSH-to-SF Mapping table 264 in [RFC8300] to get the locator of SF attaching to it. If the 265 transport between the SFF and the SF attaching to the SFF is 266 Ethernet, the locator of SF in the NSH-to-SF Mapping table should be 267 MAC address. At this time, the SFC packet format from SFF to SF is 268 as the Figure 3 shows. So the destination MAC address of the outer 269 L2 header should be SF MAC address, and the source MAC address of the 270 outer L2 header should be MAC address of the SFF. After the process, 271 the SF will decrement SI in the NSH by a value of 1, and exchange the 272 source MAC address the and destination MAC address of the outer L2 273 Header, and then the SFC packet is forwarded back to the SFF. Once 274 the SFF receive the SFC packet from SF interface, it will check the 275 SFI and SI in the NSH-to-SF Mapping table again to get the locator of 276 next SFF, that is MAC address of the next SFF if the transport is 277 Ethernet. SFF should modify the L2 Header again to be the 278 destination MAC address is the next SFF address, and the source MAC 279 address is the MAC address of the SFF. 281 3.When the last SFF receive the SFC packet from the SF attaching to 282 it, it will check the SPI and SI in the NSH-to-SF Mapping table, 283 finding it's the end of the Service Function Path, so it should strip 284 the outer L2 Header and NSH Header before it send out the original 285 packet . 287 5. GRE as transport 289 5.1. Format in encapsulation 291 In an overlay network, GRE is as tranport for SFC traffic. The 292 format for GRE to tranport SFC packet should be as Figure 5. Here 293 assuming the overlay networks are built on Ethernet. 295 +----------+------------------------+-------------------+--------------+----------------+ 296 |L2 header | IP header, Proto=47 |GRE PT=NSH |NSH, NP=0x1 |original packet | 297 +----------+------------------------+-------------------+--------------+----------------+ 298 GRE+ NSH IPv4 packet 300 +----------+------------------------+-------------------+---------------+---------------+ 301 |L2 header | IP header, Proto=47 |GRE PT=NSH |NSH,NP=0x3 |original frame | 302 +----------+------------------------+-------------------+---------------+---------------+ 303 GRE+ NSH L2 frame 304 Figure 5 306 Figure 5: NSH in GRE 308 5.2. Operation 310 To support the encapsulation, a new value for Protocol Type in GRE is 311 required. 313 Similar with VXLAN-GPE as transport. Will add later. 315 6. GENEVE as transport 317 6.1. Format in encapsulation 319 In an overlay network, GENEVE is as STANDARD transport technology. 320 GENEVE also can be used as transport for SFC traffic. The format for 321 GENEVE to tranport SFC packet should be as Figure 6. Here assuming 322 the overlay networks are built on Ethernet. 324 +----------+------------------------+-----------------------+--------------+----------------+ 325 |L2 header | IP + UDP dst port=6081 |GENEVE PT=NSH |NSH, NP=0x1 |original packet | 326 +----------+------------------------+-----------------------+--------------+----------------+ 327 GRE+ NSH IPv4 packet 329 +----------+------------------------+----------------------+---------------+----------------+ 330 |L2 header | IP + UDP dst port=6081 |GENEVE PT=NSH |NSH,NP=0x3 |original frame | 331 +----------+------------------------+----------------------+---------------+----------------+ 332 GRE+ NSH L2 frame 333 Figure 6 335 Figure 6: NSH in GENEVE 337 6.2. Operation 339 To support the encapsulation, a new value for Protocol Type in GEVENE 340 is required. 342 Similar with operation in VXLAN-GPE transport. Details will be added 343 later. 345 7. Security Considerations 347 TBD. 349 8. IANA Considerations 351 TBD. 353 9. Acknowledgements 355 TBD. 357 10. References 358 10.1. Normative References 360 [I-D.ietf-nvo3-geneve] 361 Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic 362 Network Virtualization Encapsulation", draft-ietf- 363 nvo3-geneve-08 (work in progress), October 2018. 365 [I-D.ietf-nvo3-vxlan-gpe] 366 Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol 367 Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work 368 in progress), April 2018. 370 [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 371 Routing Encapsulation (GRE)", RFC 1701, 372 DOI 10.17487/RFC1701, October 1994, 373 . 375 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 376 Requirement Levels", BCP 14, RFC 2119, 377 DOI 10.17487/RFC2119, March 1997, 378 . 380 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 381 Writing an IANA Considerations Section in RFCs", BCP 26, 382 RFC 8126, DOI 10.17487/RFC8126, June 2017, 383 . 385 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 386 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 387 May 2017, . 389 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 390 "Network Service Header (NSH)", RFC 8300, 391 DOI 10.17487/RFC8300, January 2018, 392 . 394 10.2. Informational References 396 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 397 Chaining (SFC) Architecture", RFC 7665, 398 DOI 10.17487/RFC7665, October 2015, 399 . 401 Authors' Addresses 402 Ting Ao 403 ZTE Corporation 404 No.889, BiBo Road 405 Shanghai 201203 406 China 408 Phone: +86 21 68897642 409 Email: ao.ting@zte.com.cn 411 Wei Wei 412 ZTE Corp. 413 No.50, Ruanjian Avenue 414 Nanjing 415 China 417 Email: wei.wei@zte.com.cn 419 Yan Zheng 420 ZTE Corp. 421 No.50, Ruanjian Avenue 422 Nanjing 423 China 425 Email: zheng.yan@zte.com.cn