idnits 2.17.1 draft-fedyk-sfc-mac-chain-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 -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.guichard-sfc-nsh-dc-allocation' is defined on line 893, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-05 == Outdated reference: A later version (-07) exists of draft-guichard-sfc-nsh-dc-allocation-04 == Outdated reference: A later version (-04) exists of draft-napper-sfc-nsh-broadband-allocation-00 == Outdated reference: A later version (-13) exists of draft-ietf-nvo3-vxlan-gpe-02 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group P. Bottorff 2 Internet Draft D. Fedyk 3 Intended status: Informational HP Enterprise 4 Expires: January 2017 H. Assarpour 5 Broadcom 6 July 21,2016 8 Ethernet MAC Chaining 9 draft-fedyk-sfc-mac-chain-02.txt 11 Abstract 13 This document introduces and describes a simple and highly scalable 14 service function chaining mechanism called MAC chaining which is 15 built largely on existing Ethernet frame and forwarding capabilities. 16 MAC chaining uses IEEE 802 Media Access Control (MAC) addresses to 17 provide flexible and complete service function chains. It is largely 18 transparent to layers above Ethernet and designed to augment and 19 coexist with existing virtual and physical network forwarding. MAC 20 chaining is achievable in some devices and virtual switches today 21 using existing protocols. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 This Internet-Draft will expire on January 2017. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction...................................................3 64 2. Conventions used in this document..............................4 65 3. Terminology....................................................5 66 4. MAC Chaining...................................................6 67 4.1. MAC Chaining Packet and Address Formats...................7 68 4.2. Meta-Data Encoding Consideration for NSH.................10 69 4.3. Forwarding...............................................11 70 4.3.1. Destination Address MAC Chaining Operation..........13 71 4.3.2. Destination and Source Address MAC Chaining.........14 72 4.3.3. Forwarding by Service Functions.....................14 73 4.3.4. Reverse Path Forwarding by Service Functions........15 74 4.3.5. Proxy Forwarders....................................16 75 4.3.6. Example MAC Chaining Walk Through using DA/SA Chaining 76 ...........................................................17 77 4.3.7. Forwarding by Chain Termination Functions...........19 78 5. Programming a Service Chain...................................19 79 6. Considerations for Operation over NVO3 Tunnel Transports......19 80 7. Domain of operation...........................................20 81 8. Security Considerations.......................................20 82 9. IANA Considerations...........................................20 83 10. References...................................................21 84 10.1. Normative References....................................21 85 10.2. Informative References..................................21 86 11. Acknowledgments..............................................21 88 1. Introduction 90 Service Function Chaining (SFC) enables the creation of composite 91 (network) services that consist of a directed graph of Service 92 Functions (SF) which must be applied to packets selected as a result 93 of classification. SFC is described in detail in the SFC architecture 94 document [RFC7665], and is not repeated here. 96 This document describes a new highly scalable, low resource, service 97 function chain (SFC) mechanism called MAC chaining that is based on 98 the current IEEE 802 [802-2001] Ethernet header for physical and 99 virtualized environments. Service function chaining is an active area 100 in the standards and various proposals for how to do SFCs are being 101 put forward. The basic mechanism used for MAC chaining is the use of 102 MAC addresses in the Ethernet header as a mechanism both for 103 identifying chains and for forwarding packets along a MAC chain. The 104 forwarding mechanism used in MAC chaining is independent from virtual 105 or overlay networks used to form subnets. MAC chaining addresses are 106 terminated at each Service Function Forwarder (SFF) and replaced by a 107 new set of MAC chaining addresses used to forward through the next 108 Service Function in the chain. 110 +-----------------------------------------+ 111 / E2E Network / 112 / / 113 +-----------------------------------------+ 114 +----------------------------------+ 115 O /| / MAC Function Chaining / 116 R / | / / 117 C / | +----------------------------------+ 118 H / | +----------------------------------+ 119 E | | / Virtual Networks / 120 S | | / Overlay/Underlay / 121 T | | +----------------------------------+ 122 R | | +---------------+ +---------------+ 123 A | | / Physical / / Physical / 124 T | | / Networks / / Networks / 125 I | | +---------------+ +---------------+ 126 O | / 127 N | / 128 | / 129 |/ 131 Figure 1 Service Forwarding Plane 133 MAC chaining can be viewed as a network service plane as shown in 134 Figure 1. The SFC architecture document [RFC7665] describes chain 135 forwarding in terms of 3 main architecture components which are the 136 Service Classification Function (SCF), Service Function Forwarder 137 (SFF) and the Service Function (SF). When managed with MAC chaining, 138 Service Functions (SF) are simple links in the service chain and 139 require little context of the overall chain. MAC chaining Service 140 Function Forwarders (SFF) enable the chain and control the path to 141 and from the SFs. Logically the SFF forms a switching layer above the 142 existing virtual networking layers. In MAC chaining, a Chain 143 Termination Function (CTF) is added to the architecture to separate 144 the operation of de-encapsulating the packet and sending it toward 145 the final destination from the operations of service function 146 classification and service function forwarding described in the I- 147 I.ietf-sfc-architecture. 149 MAC Chain forwarding is performed by a MAC Chaining Service Function 150 Forwarder (SFF) using DA and SA address swapping. The operation of a 151 MAC Chaining SFF has characteristics of a router in that it uses 152 information in the packet to determine a new link destination, 153 however unlike a router the new link decision is based on the 154 previous MAC address rather than the IP address. This arrangement has 155 the advantage that the IP addresses retains the end-to-end address 156 eliminating the need for NAT addresses on entry and exit of the 157 chain. A MAC Chain Service Function Forwarder also has 158 characteristics of a Bridge in that it uses a promiscuous receiver 159 with exact matching of every frame presented on its links to a MAC DA 160 and VLAN entry in the filtering database. This matching prevents 161 forwarding frames which don't contain allocated Chain MAC addresses. 162 The exact matching performed by a MAC Chaining SFF provides orders of 163 magnitude higher table scaling than longest match forwarding 164 characteristic of routers. 166 MAC chaining can interwork with other chaining mechanisms when used 167 in hybrid chains. In Hybrid chains the SFFs or proxies are 168 responsible for converting the packet formats for the appropriate 169 elements. 171 2. Conventions used in this document 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in RFC-2119 [RFC2119]. 177 In this document, these words will appear with that interpretation 178 only when in ALL CAPS. Lower case uses of these words are not to be 179 interpreted as carrying RFC-2119 significance. 181 3. Terminology 183 Chain Termination Function (CTF): See [RFC7665]. The chain 184 termination function terminates a Service Function Path 185 performing any de-encapsulation and operations required 186 to continue forwarding to the final destination. The 187 CTF may also be the final destination of the chain. 189 CS-MAC: A MAC address which identifies a MAC Chain Segment 191 CS-MAC Authority: CS-MAC Authority refers to the purely 192 administrative mechanism to ensure CS-MACs are unique 193 but allows the optional reuse of MACs in different VNs. 194 Each VN port has a single CS-MAC Authority. Multiple 195 ports may share the same Authority. A MAC Chain may be 196 under a single CS-MAC Authority or it may be split 197 among multiple CS-MAC Authorities. 199 DA: MAC destination address 201 I/G The Individual/Group (I/G) address bit (LSB of octet 202 0). 204 MAC Address: IEEE 802 Media Access Control Address a 48 bit address. 206 MAC Chain Segment (CS): A hop between either Service Forwarding 207 Functions, a Service Classification Function and a 208 Service Forwarding Function, or a Service Forwarding 209 Function and a Chain Termination Function 211 MTU: Maximum Transmission Unit. Layer 2 has a maximum frame 212 size and Layer 3 has a Maximum Packet Unit. This 213 documents uses the term Layer 2 MTU to identify that 214 MAC chaining does not affect L3 or IP MTU. 216 VN Port: In this document a port is the logical interface 217 context for a MAC address in a virtual network (VN). A 218 VN port may be implemented on any type of physical port 219 or logical supporting Ethernet. 221 SA: MAC source address 223 Service Function (SF): See [RFC7665]. 225 Service Classification Function (SCF): 226 See [RFC7665]. 228 Service Function Chain (SFC): See [RFC7665]. 230 Service Function Forwarder (SFF): See [RFC7665]. 232 Service Function Path (SFP): See [RFC7665]. 234 U/L: The Universally or Locally administered (U/L) address 235 bit is the bit of octet 0 adjacent to the I/G bit. 237 Virtual Network (VN): A Virtual network is used to identify a 238 network segment controlled by a CS-MAC Authority. 240 4. MAC Chaining 242 MAC chaining uses controlled assignment of Ethernet 48 bit MAC 243 addresses to form the chain. Ethernet MAC addresses are selected to 244 uniquely identify both the chain and the particular chain segment (or 245 hop) within the identified chain. These assigned Ethernet addresses 246 are called Chain Segment MAC (CS-MAC) addresses in this document. 247 These CS-MACs allow MAC chaining to be implemented on existing 248 Ethernet infrastructure making it broadly interoperable with the 249 majority of installed base including existing Ethernet, Carrier 250 Ethernet and IP equipment. 252 Each MAC chain is composed of a series of Chain Segments (CS) which 253 are hops between Classifiers, Service Function Forwarders and Chain 254 Terminating Functions (see figure 2). Some of the chain segments 255 include Service Functions while others perform forwarding between the 256 SCF, SFF and CTF. For each chain segment, a Destination MAC address 257 (DA), and optionally a Source MAC address (SA) are selected, from a 258 locally administered MAC address space, to uniquely identify the 259 chain segment within the SFC domain. MAC chaining uses these CS-MACs, 260 in the Ethernet header, as an identifier to enable forwarding packets 261 in a MAC chain. 263 +-----+ +-----+ +------+ +-----+ +-----+ +------+ +-----| +-----+ 264 | | | | \ SF2/ | | | | \ SF4/ | | | | 265 | SCF +--+ SFF1+---+B +---+ SFF1+-+ SFF2+---+D +---+ SFF2+-+ CTF | 266 | X| 1|A C|2 \/ 2|C | | E|3 \/ 4|E Y| |F | 267 +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ 268 \...../ \............/ \.../ \............/ \..../ 269 CS 1 CS 2 CS 5 CS 3 CS 4 270 CS-MAC=A CS-MAC=C CS-MAC=G CS-MAC=E CS-MAC=F 272 Figure 2 MAC Chain Segments Addressing 274 In Figure 2 five chain segments are illustrated. The first chain 275 segment is between the classifier and service function forwarder 276 identified as SFF1. This chain segment, designated CS1, has been 277 assigned CS-MAC A. (For brevity the 48 bit MAC addresses are 278 identified by letters). The next chain segment is from SFF1 VN port 2 279 through service function 2 and back to SFF1 VN port 2. This chain 280 segment designated CS2 has been assigned CS-MAC C. SF2 on CS2 is a 281 single armed SF with MAC address B attached to SFF VN port 2. (See 282 section 4.3.3 for a description of the types of armed SF). Chain 283 segment CS5 is between SFF1 and SFF2. It has an assigned CS-MAC G. 284 Chain segment CS3 from SFF2 VN port 3 to SFF2 VN port 4 is identified 285 by CS-MAC E. SF4, lying on CS3, is a dual armed SF with MAC address D 286 on the side connecting to SFF2 VN port 3. The final chain segment, 287 CS4, of the path is between SFF2 and the CTF and is identified by CS- 288 MAC F. 290 As described here, MAC chaining operates in the context of Virtual 291 Networks (VN). To fully describe each MAC chaining address the tuple 292 (CS-MAC Authority, CS-MAC) is used which uniquely identifies each 293 chain segment as well as the entire chain. Each chain segment and 294 each VN MUST belong to a single CS-MAC Authority which is a 295 management construct that assigns unique CS-MACs for that segment and 296 VN. If a chain segment crosses between two independent VNs, then 297 both the VNs must have the same CS-MAC Authority. 299 4.1. MAC Chaining Packet and Address Formats 301 The IEEE 802.3 [802-2001] frame header consists of a Destination MAC 302 Address (DA) (6 bytes) followed by a Source MAC Address (SA)(6 Bytes) 303 followed by a number of possible fields which are identified by an 304 Ethertype (2 Bytes) following the SA. A VLAN tag (4 bytes) is a 305 common TAG that also carries Priority Code Points and Discard 306 Eligible Information for traffic classification. For the purpose of 307 this document the DA and SA are the primary fields used for MAC 308 chaining however the frame may optionally have VLAN Tags. The MAC 309 chaining frame can also be carried inside other encapsulations (i.e. 310 within an overlay) like VxLAN, Geneve, GUE, L2VPN or Provider 311 Backbone Bridging (PBB). 313 Figure 3 illustrates the formats MAC chaining uses to carry the 314 original IPv4 or L2 packets when entering the classifier. Since MAC 315 chaining encodes a SFC path solely in the MAC addresses of the 316 Ethernet header the SPI and SI fields of the Network Service Header 317 (NSH) [I-D.ietf-quinn-sfc-nsh] are not necessary and therefore NSH is 318 an optional addition when using a MAC segment chain. 320 Format 1: Original IPv4, MAC Chaining without NSH: 321 +-------------------------------------------+--------------------+ 322 | Outer Ethernet, ET=0x0800 | original IP Packet | 323 +-------------------------------------------+--------------------+ 325 Format 2: Original IPv4, MAC Chaining with NSH 326 +---------------------------+---------------+--------------------+ 327 | Outer Ethernet, ET=0x894F | NSH, NP = 0x1 | original IP Packet | 328 +---------------------------+---------------+--------------------+ 330 Format 3: Original L2, MAC Chaining without NSH 331 +-------------------------------------------+--------------------+ 332 | Outer Ethernet, ET=0x**** | original L2 frame | 333 +-------------------------------------------+--------------------+ 335 Format 4: Original L2, MAC Chaining with NSH 336 +---------------------------+---------------+--------------------+ 337 | Outer Ethernet, ET=0x894F | NSH, NP = 0x3 | original L2 frame | 338 +---------------------------+---------------+--------------------+ 339 Figure 3 MAC Chaining Formats for IPv4 and L2 Service Packets 341 For original L3 packets MAC Chaining can forward a standard L3 frame 342 without any further encapsulation. In addition if the SFs or Proxy 343 functions are NSH aware, the format 2 for original L3 packets allows 344 adding the NSH header to pass meta-data between SFs. 346 Figure 3 provides two alternate encapsulations for original L2 347 packets. The simple format 3 encoding without NSH uses an Ethertype 348 to designate an L2 frame follows. This encoding provides an L2 349 encapsulated in an L2 frame. The format 4 encoding uses the NSH 350 header with the Next Protocol set to 0x3 designating an L2 frame 351 encapsulation. The NSH encapsulation provides all the functions of 352 the simple L2 encapsulation and therefore can be used whenever the 353 SFs or Proxy functions are NSH aware. 355 In addition to meta-data carried in the NSH it is also possible to 356 encode a small amount of meta-data in the Chain Segment MAC 357 addresses. The branch taken bit (figure 4) is a small piece of meta- 358 data that can be used in the MAC chaining header. For more elaborate 359 meta-data, the Network Service Header draft [I-D.ietf-quinn-sfc-nsh] 360 header is compatible with MAC chaining. Section 11.3 of [I-D.ietf- 361 quinn-sfc-nsh] illustrates that the Ether type following a MAC 362 chaining outer header has a registered type of 0x894F (TBC) with an 363 NSH that subsequently defines the payload. SFs can use the NSH within 364 the chain. Any SCF, SF or CTF can remove or modify the NSH as 365 specified in the NSH draft. When using the IETF NSH draft each SF 366 must either be capable of receiving an Ethernet frame with the NSH or 367 must be supported by a proxy which removes the NSH before the SF. 369 The format of the MAC address used by MAC chaining is the standard 370 IEEE MAC address format of 48 bits as illustrated in figure 4. 372 Every MAC address is identified as either a global or a local MAC 373 address. Global MAC addresses are intended to be worldwide unique 374 while local address are intended for the use of local administrations 375 domains and are not worldwide unique. Each global address uses a 22 376 bit Organizational Unique Identifier (OUI) prefix which is assigned 377 by the IEEE Registration Authority Committee to support worldwide 378 uniqueness. Recently, in response the needs of virtualization 379 environments, the IEEE Registration Authority Committee has started 380 assigning 22 bit Company IDs (CID) to allow independent vendors to 381 share the local MAC addresses space within a domain where multiple 382 un-coordinated authorities are assigning addresses. MAC chaining MAY 383 make use of the new administered local MAC addresses. 385 I U 386 / / B 387 G L T 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 |X|n|CID1[42:47]| CID2[32:39] | CID3[24:31] |CS-ID[16:22] |X| 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | CS-ID [8:15] | CS-ID [0:7] | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 Figure 4 MAC Chaining Ethernet MAC address Format 395 Where: 397 I/G IEEE 802 Ethernet Individual/ Group address bit. 399 U/L IEEE 802 Ethernet Universal / Local Bit. Bit MAY be set 400 indicating local. 402 CID Company ID - 22 Bits (Not Mandatory example only). Company 403 Ids are assigned by IEEE registration to vendors who use 404 Local addresses for MAC chaining or other purposes. The CIDs 405 are unique and ensure that there are no collisions with 406 other protocols that use local addresses. However the local 407 addresses can be reused in other networks. 409 BT Branch Taken Chain indicator. Required. This bit may be set 410 or reset in context of a chain. 412 CS-ID Chain Segment ID 23 bits. (Example only). 414 CS-MAC addresses, which identify chain segments, SHOULD be allocated 415 by the CS-MAC Authority from the local space using a Company ID 416 assigned to the CS-MAC Authority. MAC addresses also have an 417 Individual (unicast) or Group (Multicast) bit I/G. MAC chaining MAY 418 use individual or group addresses for the CS-MACs though restriction 419 on the use of group CS-MACs may apply depending on the type of 420 forwarding performed by the SFF for the particular segment. 422 MAC chaining may also use global or local MAC addresses. The MAC 423 address assigned to a Service Function MAY be Global or Local and can 424 be assigned by any authority, not necessarily the CS-MAC Authority. 426 As with other types of Service chaining, a packet or a frame travels 427 through a network until it encounters an initial classifier. 428 Forwarding before the classifier is out of the scope of this 429 specification. The native packet format (L2 or L3 or tunneled, etc.) 430 arriving at the classifier does not matter but the classifier (or set 431 of classifiers) need to inspect the packet and determine that the 432 packet is part of a service chain. 434 In all cases of MAC chaining after a frame (L2, L3, etc.) has been 435 classified the MAC chain begins by prepending the packet with an 436 Ethernet L2 Frame header. The frame will also have a valid 4 byte CRC 437 checksum. 439 One advantage of MAC chaining is the MAC frame has an overhead of 440 bytes that can leave the L2 MTU unaffected. As with all Ethernet II 441 frames payload must be a minimum of 64 bytes or must be padded to 64 442 bytes. 444 4.2. Meta-Data Encoding Consideration for NSH 446 A Network Service Header (NSH) is required on NSH aware chain 447 segments where meta-data is being carried. A NSH may be inserted and 448 deleted from the chain depending on the requirements of the specific 449 SFs by the MAC Chaining SFFs as discussed in 4.1. 451 The current NSH draft [I-D.ietf-quinn-sfc-nsh] has a mandatory 32 452 byte service path header. MAC Chaining doesn't require the Service 453 path and Service index, of the NSH for forwarding, and when used for 454 MAC Chaining and utilizing NSH these fields are simply transparent 455 metadata. When used in hybrid chains of MAC chaining and other chain 456 types the service path header SHOULD carry Service path and Service 457 index values that are relevant to the particular chain segments. MAC 458 chaining can also be used with service functions that understand the 459 NSH header and in this case a proxy operation MUST ensure the service 460 path header has the appropriate values for the service function. A 461 proxy operation may be a district function or part of an SFF that 462 Maps or sets the service header appropriately for an SF. 464 There are several drafts that are proposing context based headers 465 [I-D.meng-sfc-nsh-broadband-allocation], [I-D.guichard-sfc-nsh-dc- 466 allocation], and [I-D.napper-sfc-nsh-mobility-allocation]. In a 467 hybrid SFC chain environment that supports different SFC forwarding 468 on different chain segments, SFFs SHOULD map MAC chainIDs to Service 469 paths or vice versa where required. 471 4.3. Forwarding 473 Forwarding of a packet proceeds from a classifier (SCF) to the 474 Service Function Forwarder (SFF) to the service function (SF) to the 475 next SFF to the next SF and so on until the chain is finished. MAC 476 chaining makes the distinction that the forwarding operations 477 performed by a SFF and a SF are distinct and independent. However 478 implementations may place SFF and SF functions as combined or 479 separate entities. This makes MAC chaining particularly useful for 480 deployment in virtualization environments where a virtual machine may 481 implement one or more SFs and SFFs. Forwarding is a table driven 482 operation. Note that all active chains are normally preprogrammed. 484 Figure 5 illustrates the table driven forwarding operation of a MAC 485 chaining SFF. Every frame arriving on the ingress VN port is matched 486 to the MAC chaining filtering database. On arrival at the SFF the DA 487 always contains a CS-MAC for the chain segment just crossed. The DA 488 is looked up in the context of its ingress Port (a VN port). A 489 subsequent DA prime (DA' a CS-MAC used as the new frame DA if this 490 segment is DA forwarding) and SA' (a CS-MAC used as the new frame SA 491 if this segment is DA/SA forwarding) and egress Port prime (1') are 492 determined by the lookup. 494 Ingress Port Egress Port 495 +------+------+-----------+ +------+------+-----------+ 496 |CS_DA | SA | | -> | DA' | SA' | | 497 +--+---+------+-----------+ +------+------+-----------+ 498 | \............/ 499 | ^ 500 | | 501 | MATCH | ACTION 502 | ............. ..................... 503 | / \ / \ 504 | +-------+-------+-----+---------+-------+ 505 `------>|Port1 |CS_DA1 |DA1' | SA1' |Port1' | 506 |Port2 |CS_DA2 |DA2' | SA2' |Port2' | 507 |Port3 |CS_DA3 |DA3' | SA3' |Port3' | 508 | | | | | | 509 | | | | | | 510 +-------+-------+-----+---------+-------+ 511 MAC Chaining Filtering Database 513 Figure 5 MAC Chain Destination Match Forwarding 515 Any frame that arrives at an SFF and doesn't exactly match an entry 516 in the MAC chaining filtering database MUST be discarded. The 517 filtering database itself is configured by network controller (see 518 section 6) which creates the chain by programming the MAC chaining 519 filtering database. The MAC chaining filtering database is an exact 520 match database which may use existing Bridge match logic. The exact 521 match filtering with a hash implementation allows the filtering 522 database to easily scale to a large number of chains. Devices in the 523 forwarding path that are not MAC service chaining aware are free to 524 bridge the frame normally or to route using any underlay Layer 3 or 525 2.5 VN encapsulation. 527 The Branch Taken (BT) Operation bit (Figure 4) allows an SF to branch 528 the chain by changing the BT bit. Not all service chains are branch 529 capable. If a simple branch chain is desired it must be programmed in 530 the SFF filtering database. A branch operation is indicated by 531 setting a reserved bit in the CS-MAC address. This bit is not read as 532 a bit but as a paired address to the forward direction. The context 533 of the BT bit may be maintained in both the SA and the DA once the 534 bit has been set. An SFF receiving a frame with the BT bit set will 535 look up the exact match address and forward the frame in the context 536 of the received VN. 538 More complicated branching requires SF chain awareness. The next hop 539 addresses may be overridden by chain aware SFs to perform more 540 advance branching. A SF must be provided with the allocated addresses 541 for larger branches. 543 MAC Chaining supports two different types of forwarding methods for 544 SFs which are called DA forwarding and DA/SA forwarding. These two 545 types of forwarding are used for coupling different types of SFs into 546 a chain. The DA forwarding method is suited to operating on existing 547 SFs (such as Firewalls) which provide transparent or Bridge 548 forwarding modes. The DA/SA forwarding method is suited for use with 549 Virtualized SFs that are operating in Virtual Machines or Containers. 550 The main difference between the two methods is when using DA 551 forwarding the SFF encodes the Chain Segment MAC in the DA field. The 552 DA therefore contains an address for the next SFF hop rather than an 553 explicit address for the SF. In DA/SA forwarding the SFF encodes the 554 Chain Segment MAC in the SA rather than the DA. For DA/SA forwarding 555 the SFF uses the DA to directly address the SF. This allows any SF to 556 receive on a single unique address which may be shared by all chains 557 passing through the SF. The choice of DA or DA/SA forwarding is made 558 for each SF of the chain depending on the requirements of the 559 specific SF. 561 A MAC chain aware SF can determine if the packet is using DA or DA/SA 562 forwarding by determining if the received DA addresses the SF itself 563 and if the SA contains an address allocated by the CS-MAC authority. 565 4.3.1. Destination Address MAC Chaining Operation 567 Destination MAC address chaining uses only the Destination MAC 568 address to key on and implement a chain. Destination Address MAC 569 chaining is used to operate with a MAC chaining un-aware SF which 570 operates in a transparent Bridge mode. A Classifier/Service Function 571 Forwarder (SFF), composing a DA MAC chaining hop, encodes the Chain 572 Segment MAC in the frame DA and an address for the SFF in the frame 573 SA. This encoding will address the next SFF or CTF in the chain. DA 574 MAC chaining may only be used with dual-arm or multi-arm SFs since an 575 unmodified frame can't be returned to the same network where it was 576 received. Any SF along a DA MAC chaining segment must be operating in 577 Transparent or in Bridging mode so it behaves as a "bump in the 578 wire". 580 For a Service Function to participates in a DA MAC chaining it must 581 operate in promiscuous receiver, like an Ethernet Bridge, rather than 582 explicit receiver used by Ethernet stations. In promiscuous receiver 583 the SF receives and inspects every frame presented to it independent 584 of the addressing on the frame. 586 DA MAC chaining is determined by the configuration of the forwarding 587 table in the SFF. After the initial classification the packet is 588 passed to the first SFF (this may be a virtual operation completely 589 within a single chaining switch). The SFF formats the Ethernet frame 590 with a DA of the next hop in the Chain. At each hop the MAC address 591 is looked up in a table similar to figure 5. 593 4.3.2. Destination and Source Address MAC Chaining 595 DA and SA MAC chaining is a variation of MAC chaining that allows MAC 596 chaining aware SFs to use an explicit receiver mode and to support 597 single armed as well as dual and multi-armed SFs. When using DA/SA 598 MAC chaining the SF is individually addressed by a MAC DA and 599 therefore does not need to operate as a promiscuous receiver. This 600 type of SF does not need a MAC lookup table and may be provisioned 601 with a single global or local address under any administration 602 authority (not necessarily the MAC chaining address authority). 603 Service Functions using DA/SA MAC chaining require only a single MAC 604 address regardless of the number of chains passing through them. 605 DA/SA MAC chaining is particularly advantageous for virtual service 606 functions (VNFs) since it reduces the need to flood frames into the 607 virtual NIC supporting the SFs virtual machines and server I/O 608 accelerators. 610 DA/SA MAC chaining uses both addresses in the Ethernet L2 Header. The 611 DA is used for the next hop device and the SA is used for the 612 subsequent next hop device of the chain. A SF receives a frame; 613 processes the frame; replaces the DA with the received SA and uses 614 resulting DA (received SA) to forward the frame. By specifying 2 hops 615 in a chain the SF can be a very generic operation. The original SA of 616 the received frame does not have to be the address at the SFF that 617 created the header, allowing forwarding flexibility. 619 4.3.3. Forwarding by Service Functions 621 MAC chaining Service Functions (SFs) must be able to pass Ethernet 622 DA/SA addresses through the SF unless the SF is supported by a Proxy 623 Forwarder (see Proxy Forwarders section below). SFs are not required 624 to pass VLAN Tags. Service Functions supported by MAC chaining can be 625 classified by how they attach to the network as single armed, dual 626 armed or multi-armed. Single arm SFs receive and send all packets on 627 the same VN port. Single armed SFs are typically used when the 628 direction of travel is unimportant to the SF. Dual arm SFs have two 629 VN ports and pass packets between the two VN ports. Dual arm SFs are 630 typically used when the SF needs to know the direction of travel. 631 Multi-arm SFs have more than two VN ports. In a multi-arm (two or 632 more) the SF selects the egress VN port based on its' re- 633 classification of the packet. Each VN port of a multi-arm SF must 634 attach to a different VN or the SF must be MAC Chaining aware. These 635 SFs allow the SFs to branch the chain based on re-classification or 636 to replicate in the chain. 638 4.3.4. Reverse Path Forwarding by Service Functions 640 The BT bit SHOULD be used for the special case where a SF reverses 641 the chain direction. An example of this type of SF is one which 642 proxies TCP. Another example is a loopback function. 644 An SF uses the BT bit for reverse chain forwarding by setting the BT 645 bit in the destination MAC for frames directed in the reverse 646 direction and leaves the BT bit clear for frames following normal 647 forwarding. 649 To enable reverse path forwarding, for a particular SF by using the 650 BT bit, the SFF must be configured with a separate match rules for 651 the reverse paths. To support an SF that is reverse path capable the 652 SFF can have up to 4 table match entries (see Figure 5), one for the 653 right direction (e.g. proceeding from left to right), one for the 654 left direction, one for the reverse (BT set to 1) of the right 655 direction, and one for the reverse (BT set to 1) of the left 656 direction. The right and right reverse, or the left and left reverse 657 paths can be independently programmed to allow the reverse paths to 658 be symmetric or asymmetric with the right or left paths. 660 Service Function 661 right path +----------------+ 662 > --------------------+---+----------+----------------- > 663 reverse right path \ | / 664 < ----------------------+-+ / 665 \ / left path 666 < ------------------------+---+--+--------------------- < 667 \ | / reverse left path 668 \ +------------------------ > 669 \/ 671 Figure 6: Reversing Paths at a Service Function 673 In addition to reversing the Service Function Path some chains will 674 need to have re-arranged or re-constructed meta-data for the reverse 675 path. In general this may require re-classification of the packet. If 676 re-construction of meta-data is required this can be handled using 677 exception processing at the SFF initiated on the reverse path match. 679 4.3.5. Proxy Forwarders 681 Proxy forwarding is typically for legacy devices or other devices 682 that do not have an ability to support MAC chaining by passing 683 through L2 headers. 685 Some service functions may reside on devices that do not understand 686 MAC chaining. Legacy functions on middle boxes are one example and 687 service functions that use the NSH header are another example. In 688 these cases a proxy forwarding function is used. Proxies may be 689 integrated with the SFF or located in the switches attaching to the 690 SF. The proxy removes the MAC chaining header and forwards the packet 691 in an appropriate format to the SF. The SF then returns the packet to 692 the proxy upon completion of its operation. The Specific formats of 693 frames between the proxy and the SF, when using a proxy, is out of 694 the scope of this document. 696 The most basic proxy is a transparent proxy, which must be located 697 between the SF and any underlay entity. A transparent proxy provides 698 a provisioned Ethernet destination which is used for forwarding all 699 frames egressed by the SF at a specific VN port. The use of a 700 transparent proxy constrains the service chain in which it is 701 inserted since no explicit chain state is passed through the SF by 702 the proxy, however can be highly useful for supporting existing SFs. 703 The combination of a transparent proxy with extended match SFFs can 704 allow simple support for existing high layer SF. 706 A NSH proxy function converting a packet to a NSH aware SF sets the 707 service path header of the NSH header while leaving other meta data 708 in the NSH untouched. 710 A more specific proxy technique for chain unaware SFs is to store the 711 CS-MAC by reading the SA on ingress to the SF and then inserting the 712 stored CS-MAC in the DA on egress from the SF. 714 4.3.6. Example MAC Chaining Walk Through using DA/SA Chaining 716 Figure 7 outlines the general path and operations of a MAC chaining. 718 The Service Classification Function (SCF) determines if a packet 719 matches a predetermined policy for the chain by inspecting the packet 720 then selecting the chain by encoding the frame with next destination 721 equal to the chain segment 1 MAC Address A and itself as the Source 722 Address (SA) designated as H in figure 7. 724 SFF1 receives a frame from the SCF with Destination Address (DA) 725 equal (exact match) to A and finds the next chain segment by looking 726 up A to find the next DA equal to SF2 MAC Address B and sets the SA 727 equal to chain segment 2 MAC Address C. 729 SF2 is a single armed Service Function which receives and sends all 730 data on a single network interface. The single SF2 network interface 731 normally connects to a single virtual or physical network. SF2 732 receives a frame from SFF1 performs its function and then returns the 733 frame to C. This process requires the SF to forward back to the 734 frame's SA, by swapping DA and SA, on the same VN port. 736 One Arm Two Arm 737 +-----+ +-----+ +------+ +-----+ +------+ +-----| +-----+ 738 | | | | \ SF2/ | | \ SF4/ | | | | 739 | SCF +---+ SFF1+----+B +----+ SFF1+----+D +----+ SFF2+-+ CTF | 740 | H| |A C| \/ |C | \/x |E T| |F | 741 +-----+ +-----+ +-----+ +-----+ +-----+ 742 \...../ \............../ \............../ \..../ 743 CS 1 CS2 CS3 CS4 745 +----+ +----+ +----+ +----+ +----+ +----+ 746 |A,H | |B,C | |C,B | |D,E | |E,x | |F,T | 747 +----+ +----+ +----+ +----+ +----+ +----+ 748 Frames showing MAC DA, SA 750 Figure 7 MAC Service Chain Example 752 SCF: Service Classification Function 753 CTF: Chain Termination Function 754 SF: Service Function 755 SFF: Service Function Forwarder 756 CSx: Chain Segment x. 758 SFF1 receives a frame from SF2 with DA equal to chain segment 2 MAC 759 Address C, finds the next chain segment by looking up C to find the 760 next destination equal to SF4 MAC Address D and the SA equals chain 761 segment 3 MAC Address E. 763 SF4 is a dual armed Service Function which receives and sends data on 764 two network interfaces. SF4 always forwards frames between its two 765 interfaces. The two interfaces of SF4 are normally connected to 766 separate virtual or physical networks. SF4 receives the frame from 767 SFF1 with DA equals D and SA equals E performs its function then 768 forwards to E by swapping DA with SA and sends out the packet to the 769 other VN port (A VN port that supports address E as a destination). 771 SFF2 receives a frame from SF4 with DA equals chain segment 3 MAC 772 Address E, finds the next chain segment by looking up E to find the 773 next destination equals chain segment 4 MAC Address F and SA equals 774 SFF2 MAC Address T. 776 The CTF receives a frame from SFF2 with destination equals F. The CTF 777 must perform any required packet header adjustment and egress VN port 778 determination based on the destination equals F and the frame payload 779 (i.e. uses the IP address to route the packet). 781 4.3.7. Forwarding by Chain Termination Functions 783 The forwarding to the final destination by the CTF typically does not 784 use MAC chaining. The CTF is responsible for receiving frames 785 addresses to the termination CS-MAC for each chain, de-encapsulating 786 the packets, and forwarding the packets toward their final 787 destination. One common method which may be used by the CTF for 788 forwarding to the final destination is to route the packets using the 789 IP address of the service packet. 791 If the service packet (data payload) is an L2 packet then the CTF may 792 use either the IP network addresses or the L2 addresses to forward 793 the packet. The choice between these two CTF forwarding models will 794 depend on the application. Other CTF forwarding models are possible 795 using by using the CS-MAC or meta-data for forwarding. 797 5. Programming a Service Chain 799 The capability exists today with open flow enabled switches to 800 specify MAC match criteria and actions that match MAC forwarding all 801 operations. However not all switches are Openflow enabled. 803 A Yang model could be specified to enable the MAC Chaining operations 804 using an I2RS agent. 806 Chains must be preprogrammed. Care must be taken to ensure that 807 service chain loops are not programmed (this can easily be verified 808 before a chain is active) however MAC chains that are programmed 809 correctly are inherently loop free in the data plane. The policy is 810 to drop a frame that is not an exact match on any MAC chaining aware 811 SFF. 813 MAC chaining may be programmed be allowed to pass through bridges 814 that are not MAC chaining aware. It is recommended that this 815 operation be explicitly controlled by setting up port based VLANs 816 designed for this purpose. Ports can add a VLAN tag as part of their 817 forwarding operation. This can be usually be achieved with existing 818 Ethernet controls that allow ports to have service tags added. The 819 VLAN tagging is independent of MAC chaining in this regard. 821 6. Considerations for Operation over NVO3 Tunnel Transports 823 MAC Chaining can be used with the L3 encapsulation transport tunnels 824 being specified in NVO3 ([I-D.ietf-nvo3-vxlan-gpe], etc.). When using 825 an NVO3 encapsulation it is preferable to use an encapsulation which 826 supports encapsulation of an L2 packet such as [I-D.ietf-nvo3-vxlan- 827 gpe], since this allows encoding the MAC addresses used for chain 828 forwarding at the natural layer boundary used to address Virtual 829 Machines or containers. 831 It is desirable to encode any meta-data header, such as the NSH 832 within an NVO3 transport tunnel following an encapsulated L2 MAC 833 header as an Ethernet tag since this will allow a natural protocol 834 layering for delivery of the meta-data to an addressed Virtual 835 Machine or container. Since Virtual Machines and containers are 836 addressed by MAC addresses at the hypervisor vSwitch or system level, 837 the meta-data will be carried as part of the frame layer into the 838 guest OS or container environments along with the MAC addresses used 839 for chaining. 841 7. Domain of operation 843 MAC chaining requires connectivity of L2 virtual networks over the 844 service chain path. (This may include multiple VNs that are 845 interconnected.) In many networks this is readily available. Data 846 centers for example can use MAC chain within a physical site that has 847 L2 connectivity. 849 If Virtualization of the L2 domain is enabled MAC chaining could 850 operate over L2 networks such as NVO3 or Ethernet EVPN and an 851 existing L2 Overlay. 853 8. Security Considerations 855 MAC chaining is an Ethernet based forwarding operation that follows 856 standard Ethernet rules. VN ports should be qualified with VLANs 857 that limit the scope of MAC chaining frames. This prevents MAC 858 chaining messages from being flooded to external parts of the network 859 or injected into a network from external sources. Programming the 860 VLAN that support MAC chaining is controlled and access to those 861 VLANs is allowed only by trusted devices. 863 MAC chaining is IP agnostic but like any tunneling protocol it will 864 deliver IP frames to other parts of a network. 866 9. IANA Considerations 868 There are no IANA considerations for this document. 870 10. References 872 10.1. Normative References 874 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 875 Requirement Levels", BCP 14, RFC 2119, March 1997. 877 [802-2001] "Standard for Local and Metropolitan Area Networks: 878 Overview and Architecture", IEEE 802, Standard 2014. 880 10.2. Informative References 882 [RFC7665] Halpern, J., Pignataro, C. Editors, "Service Function 883 Chaining (SFC) Architecture", RFC 7665, June 2015. 885 [I-D.ietf-quinn-sfc-nsh] 886 P.Quinn et al., "Network Service Header", draft-ietf-sfc- 887 nsh-05 work in progress), May 26, 2016. 889 [I-D.meng-sfc-nsh-broadband-allocation] 890 W. Meng et al., "NSH Context Header - Broadband", draft- 891 meng-sfc-nsh-broadband-allocation-01, May 10, 2016 893 [I-D.guichard-sfc-nsh-dc-allocation] 894 J. Guichard et al., "Network Service Header (NSH) Context 895 Header Allocation (Data Center)", draft-guichard-sfc-nsh- 896 dc-allocation-04, February 15, 2016 898 [I-D.napper-sfc-nsh-mobility-allocation] 899 J. Napper et al., "NSH Context Header Allocation - 900 Broadband", draft-napper-sfc-nsh-broadband-allocation-00, 901 March 21, 2016 903 [I-D.ietf-nvo3-vxlan-gpe] 904 P. Quinn et al., "Generic Protocol Extension for VxLAN", 905 draft-ietf-nvo3-vxlan-gpe-02, April 21, 2016 907 11. Acknowledgments 909 This document was prepared using 2-Word-v2.0.template.dot. 911 Copyright (c) 2016 IETF Trust and the persons identified as authors 912 of the code. All rights reserved. 914 Redistribution and use in source and binary forms, with or without 915 modification, are permitted provided that the following conditions 916 are met: 918 o Redistributions of source code must retain the above copyright 919 notice, this list of conditions and the following disclaimer. 921 o Redistributions in binary form must reproduce the above copyright 922 notice, this list of conditions and the following disclaimer in 923 the documentation and/or other materials provided with the 924 distribution. 926 o Neither the name of Internet Society, IETF or IETF Trust, nor the 927 names of specific contributors, may be used to endorse or promote 928 products derived from this software without specific prior written 929 permission. 931 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 932 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 933 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 934 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 935 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 936 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 937 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 938 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 939 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 940 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 941 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 943 Authors' Addresses 945 Don Fedyk 946 Hewlett Packard Enterprise 947 153 Taylor Street 948 Littleton, MA 949 Email: don.fedyk@hpe.com 951 Paul Bottorff 952 Hewlett Packard Enterprise 953 8000 Foothills Blvd. 954 Roseville, CA 955 Email: paul.bottorff@hpe.com 957 Hamid Assarpour 958 Broadcom Corporation 959 600 Federal Street 960 Andover, MA 961 Email: hamid@broadcom.com