idnits 2.17.1 draft-fedyk-sfc-mac-chain-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 : ---------------------------------------------------------------------------- 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 (July 20, 2015) is 3197 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 733, but not defined == Missing Reference: '802-2001' is mentioned on line 736, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-sfc-architecture-09 Summary: 0 errors (**), 0 flaws (~~), 4 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 Networking 4 Expires: January 2016 July 20, 2015 6 Ethernet MAC Chaining 7 draft-fedyk-sfc-mac-chain-00.txt 9 Abstract 11 This document introduces and describes a simple and highly scalable 12 service function chaining mechanism called MAC chaining which is 13 built largely on existing Ethernet frame and forwarding capabilities. 14 MAC chaining uses IEEE 802 Media Access Control (MAC) addresses to 15 provide flexible and complete service function chains. It is largely 16 transparent to layers above Ethernet and designed to augment and 17 coexist with existing virtual and physical network forwarding. MAC 18 chaining is achievable in some devices and virtual switches today 19 using existing protocols. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 This Internet-Draft will expire on January 14, 2016. 44 Copyright Notice 46 Copyright (c) 2015 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction...................................................2 62 2. Conventions used in this document..............................4 63 3. Terminology....................................................4 64 4. MAC Chaining...................................................5 65 4.1. MAC Chaining Packet and Address Formats...................6 66 4.2. Forwarding................................................9 67 4.2.1. Forwarding by Service Functions.....................11 68 4.2.2. Proxy Forwarders....................................12 69 4.2.3. Example MAC Chaining Walk Through...................13 70 4.2.4. Destination Address MAC Chaining Operation..........14 71 4.2.5. Destination and Source Address MAC Chaining.........15 72 4.2.6. Forwarding by Chain Termination Functions...........15 73 5. Programming a Service Chain...................................16 74 6. Domain of operation...........................................16 75 7. Security Considerations.......................................16 76 8. IANA Considerations...........................................17 77 9. References....................................................17 78 9.1. Normative References.....................................17 79 9.2. Informative References...................................17 80 10. Acknowledgments..............................................17 82 1. Introduction 84 Service Function Chaining (SFC) enables the creation of composite 85 (network) services that consist of a directed graph of Service 86 Functions (SF) which must be applied to packets selected as a result 87 of classification. SFC is described in detail in the SFC architecture 88 document [I-D.ietf-sfc-architecture], and is not repeated here. 90 This document describes a new highly scalable, low resource, service 91 function chain (SFC) mechanism called MAC chaining that is based on 92 the current IEEE 802 Ethernet header for physical and virtualized 93 environments. Service function chaining is an active area in the 94 standards and various proposals for how to do SFCs are being put 95 forward. The basic mechanism used for MAC chaining is the use of MAC 96 addresses in the Ethernet header as a mechanism both for identifying 97 chains and for forwarding packets along a MAC chain. The forwarding 98 mechanism used in MAC chaining is independent from virtual or overlay 99 networks used to form subnets. MAC chaining addresses are terminated 100 at each Service Function Forwarder (SFF) and replaced by a new set of 101 MAC chaining addresses used to forward through the next Service 102 Function in the chain. 104 +-----------------------------------------+ 105 / E2E Network / 106 / / 107 +-----------------------------------------+ 108 +----------------------------------+ 109 O /| / MAC Function Chaining / 110 R / | / / 111 C / | +----------------------------------+ 112 H / | +----------------------------------+ 113 E | | / Virtual Networks / 114 S | | / Overlay/Underlay / 115 T | | +----------------------------------+ 116 R | | +---------------+ +---------------+ 117 A | | / Physical / / Physical / 118 T | | / Networks / / Networks / 119 I | | +---------------+ +---------------+ 120 O | / 121 N | / 122 | / 123 |/ 125 Figure 1 Service Forwarding Plane 127 MAC function chaining can be viewed as a network service plane as 128 shown in Figure 1. The SFC architecture document [I-D.ietf-sfc- 129 architecture] describes chain forwarding in terms of 3 main 130 architecture components which are the Service Classification Function 131 (SCF), Service Function Forwarder (SFF) and the Service Function 132 (SF). When managed with MAC chaining, Service Functions (SF) are 133 simple links in the service chain and require little context of the 134 overall chain. MAC chaining Service Function Forwarders (SFF) enable 135 the chain and control the path to and from the SFs. Logically the SFF 136 forms a switching layer above the existing virtual networking layers. 137 For the description of MAC chaining Chain Termination Function (CTF) 138 is described which is responsible for de-encapsulating the packet and 139 sending it toward the final destination as a separate architectural 140 component from the SFF and the SFC. 142 2. Conventions used in this document 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in RFC-2119 [RFC2119]. 148 In this document, these words will appear with that interpretation 149 only when in ALL CAPS. Lower case uses of these words are not to be 150 interpreted as carrying RFC-2119 significance. 152 3. Terminology 154 Chain Termination Function (CTF): See [I-D.ietf-sfc-architecture]. 155 The chain termination function terminates a Service 156 Function Path performing any de-encapsulation and 157 operations required to continue forwarding to the final 158 destination. The CTF may also be the final destination 159 of the chain. 161 CS-MAC: A MAC address which identifies a MAC Chain Segment 163 CS-MAC Authority: CS-MAC Authority refers to the mechanism to ensure 164 CS-MACs are unique but allows the optional reuse of 165 MACs in different VNs. Each VN port has a single CS-MAC 166 Authority. Multiple ports may share the same Authority. 167 A MAC Chain may be under a single CS-MAC Authority or 168 it may be split among multiple CS-MAC Authorities. 170 DA: MAC destination address 172 I/G The Individual/Group (I/G) address bit (LSB of octet 173 0). 175 MAC Address: IEEE 802 Media Access Control Address a 48 bit address. 177 MAC Chain Segment (CS): A hop between either Service Forwarding 178 Functions, a Service Classification Function and a 179 Service Forwarding Function, or a Service Forwarding 180 Function and a Chain Termination Function 182 VN Port: In this document a port is the logical interface 183 context for a MAC address in a virtual network (VN). A 184 VN port may be implemented on any type of physical port 185 or logical supporting Ethernet. 187 SA: MAC source address 189 Service Function (SF): See [I-D.ietf-sfc-architecture]. 191 Service Classification Function (SCF): 192 See [I-D.ietf-sfc-architecture]. 194 Service Function Chain (SFC): See [I-D.ietf-sfc-architecture]. 196 Service Function Forwarder (SFF): See [I-D.ietf-sfc-architecture]. 198 Service Function Path (SFP): See [I-D.ietf-sfc-architecture]. 200 U/L: The Universally or Locally administered (U/L) address 201 bit is the bit of octet 0 adjacent to the I/G bit. 203 Virtual Network (VN): A Virtual network is used to identify a 204 network segment controlled by a CS-MAC Authority. 206 4. MAC Chaining 208 MAC chaining uses controlled assignment of Ethernet 48 bit MAC 209 addresses to form the chain. Ethernet MAC addresses are selected to 210 uniquely identify both the chain and the particular chain segment (or 211 hop) within the identified chain. These assigned Ethernet addresses 212 are called Chain Segment MAC (CS-MAC) addresses in this document. 213 These CS-MACs allow MAC chaining to be implemented on existing 214 Ethernet infrastructure making it broadly interoperable with the 215 majority of installed base including existing Ethernet, Carrier 216 Ethernet and IP equipment. 218 Each MAC chain is composed of a series of Chain Segments (CS) which 219 are hops between Classifiers, Service Function Forwarders and Chain 220 Terminating Functions (see figure 2). Some of the chain segments 221 include Service Functions while others perform forwarding between the 222 SCF, SFF and CTF switches. For each chain segment, a MAC address is 223 selected, from a locally administered MAC address space, to uniquely 224 identify the chain segment within the SFC domain. MAC chaining uses 225 these CS-MACs, in the Ethernet header, as an identifier to enable 226 forwarding packets in a MAC chain. 228 +-----+ +-----+ +------+ +-----+ +-----+ +------+ +-----| +-----+ 229 | | | | \ SF2/ | | | | \ SF4/ | | | | 230 | SCF +--+ SFF1+---+B +---+ SFF1+-+ SFF2+---+D +---+ SFF2+-+ CTF | 231 | X| 1|A C|2 \/ 2|C | | E|3 \/ 4|E Y| |F | 232 +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ 233 \...../ \............/ \.../ \............/ \..../ 234 CS 1 CS 2 CS 5 CS 3 CS 4 235 CS-MAC=A CS-MAC=C CS-MAC=G CS-MAC=E CS-MAC=F 237 Figure 2 MAC Chain Segments Addressing 239 In Figure 2 five chain segments are illustrated. The first chain 240 segment is between the classifier and service function forwarder 241 identified as SFF1. This chain segment, designated CS1, has been 242 assigned CS-MAC A. (For brevity the 48 bit MAC addresses are 243 identified by letters). The next chain segment is from SFF1 VN port 2 244 through service function 2 and back to SFF1 VN port 2. This chain 245 segment designated CS2 has been assigned CS-MAC C. SF2 on CS2 is a 246 single armed SF with MAC address B attached to SFF VN port 2. (see 247 section 4.2.1 for a description of the types of armed SF). Chain 248 segment CS5 is between service function forwarder 1 and service 249 function forwarder 2. It has an assigned CS-MAC G. Chain segment CS3 250 from SFF2 VN port 3 to SFF2 VN port 4 is identified by CS-MAC E. SF4, 251 lying on CS3, is a dual armed SF with MAC address D on the side 252 connecting to SFF2 VN port 3. The final chain segment, CS4, of the 253 path is between SFF2 and the CTF and is identified by CS-MAC F. 255 MAC chaining operates in the context of Virtual Networks (VN). To 256 fully describe each MAC chaining address the tuple (CS-MAC Authority, 257 CS-MAC) is used which uniquely identifies each chain segment as well 258 as the entire chain. Each chain segment and each VN MUST belong to a 259 single CS-MAC Authority which assigns unique CS-MACs for that segment 260 and VN. If a chain segment crosses between two independent VNs, then 261 both the VNs must have the same CS-MAC Authority. 263 4.1. MAC Chaining Packet and Address Formats 265 The IEEE 802.3 frame header consists of a Destination MAC Address (6 266 bytes DA) followed by a Source MAC Address (6 Bytes SA) followed by a 267 number of possible fields: Ether type (2 Bytes) or other TAGs and 268 Ether types. A VLAN tag (4 bytes) is a common TAG that also carries 269 Priority Code Points and Discard Eligible Information for traffic 270 class. For the purpose of this document the DA and SA are the 271 primary fields used for MAC chaining however the frame may optionally 272 have VLAN Tags. The MAC chaining frame can also be carried inside 273 (i.e. as an NVO3 overlay) other encapsulations like VxLAN, L2VPN or 274 Provider Backbone Bridging (PBB). 276 Figure 3 illustrates the formats for MAC chaining used to carry the 277 original IPv4 packets or L2 frames entering the classifier. Since MAC 278 chaining encodes a SFC path in the MAC addresses of the Ethernet 279 header it is not necessary to have the Network Service Header(NSH) 280 [I-D.ietf-quinn-sfc-nsh] on every segment of the chain. The NSH is 281 required on any NSH aware chain segment where meta-data is being 282 carried. 284 Original IPv4, MAC Chaining without NSH: 285 +-------------------------------------------+--------------------+ 286 | Outer Ethernet, ET=0x0800 | original IP Packet | 287 +-------------------------------------------+--------------------+ 289 Original IPv4, MAC Chaining with NSH 290 +---------------------------+---------------+--------------------+ 291 | Outer Ethernet, ET=0x894F | NSH, NP = 0x1 | original IP Packet | 292 +---------------------------+---------------+--------------------+ 294 Original L2, MAC Chaining without NSH 295 +-------------------------------------------+--------------------+ 296 | Outer Ethernet, ET=0x**** | original L2 frame | 297 +-------------------------------------------+--------------------+ 299 Original L2, MAC Chaining with NSH 300 +---------------------------+---------------+--------------------+ 301 | Outer Ethernet, ET=0x894F | NSH, NP = 0x3 | original L2 frame | 302 +---------------------------+---------------+--------------------+ 304 Figure 3 MAC Chaining Formats for IPv4 and L2 Service Packets 306 The branch taken bit (figure 4) is a small piece of meta data that 307 can be used in the MAC chaining header. For more elaborate meta data, 308 the Network Service Header draft [I-D.ietf-quinn-sfc-nsh] header is 309 compatible with MAC chaining. Section 11.3 [I-D.ietf-quinn-sfc-nsh] 310 illustrates that the Ether type following a MAC chaining outer header 311 has a registered type of 0x894F with an NSH that subsequently defines 312 the payload. SFs can use the NSH within the chain. Any SCF, SF or CTF 313 can remove or modify the NSH as specified in the NSH. When using the 314 IETF NSH draft header each SF must either be capable of receiving an 315 Ethernet frame with the NSH or must be supported by a proxy which 316 removes the NSH before the SF. 318 The format of the MAC address used by MAC chaining is the standard 319 IEEE MAC address format of 48 bits as illustrated in figure 4. 321 Every MAC address is identified as either a global or a local MAC 322 address. Global MAC addresses are intended to be worldwide unique 323 while local address are intended for the use of local administrations 324 domains and are not worldwide unique. Each global address uses a 22 325 bit Organizational Unique Identifier (OUI) prefix which is assigned 326 by the IEEE Registration Authority Committee to support worldwide 327 uniqueness. Recently, in response the needs of virtualization 328 environments, the IEEE Registration Authority Committee has started 329 assigning 22 bit Company IDs (CID) to allow independent vendors to 330 share the local MAC addresses space within a domain where multiple 331 un-coordinated authorities are assigning addresses. MAC chaining MAY 332 make use of the new administered local MAC addresses. 334 I U 335 / / B 336 G L T 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 |X|n|CID1[42:47]| CID2[32:39] | CID3[24:31] |CS-ID[16:22] |X| 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | CS-ID [8:15] | CS-ID [0:7] | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 Figure 4 MAC Chaining Ethernet MAC address Format 344 Where: 346 I/G IEEE 802 Ethernet Individual/ Group address bit. 348 U/L IEEE 802 Ethernet Universal / Local Bit. Bit MAY be set 349 indicating local. 351 CID Company ID - 22 Bits (Not Mandatory example only). Company 352 Ids are assigned by IEEE registration to vendors who use 353 Local addresses for MAC chaining or other purposes. The CIDs 354 are unique and ensure that there are no collisions with 355 other protocols that use local addresses. However the local 356 addresses can be reused in other networks. 358 BT Branch Taken Chain indicator. Required. This bit may be set 359 or reset in context of a chain. 361 CS-ID Chain Segment ID 23 bits. (Example only). 363 CS-MAC addresses, which identify chain segments, SHOULD be allocated 364 by the CS-MAC Authority from the local space using a Company ID 365 assigned to the CS-MAC Authority. MAC addresses also have an 366 Individual (unicast) or Group (Multicast) bit I/G. MAC chaining MAY 367 use individual or group addresses for the CS-MACs though restriction 368 on the use of group CS-MACs may apply depending on the type of 369 forwarding performed by the SFF for the particular segment. 371 MAC chaining may also use global or local MAC addresses. The MAC 372 address assigned to a Service Function MAY be Global or Local and can 373 be assigned by any authority, not necessarily the CS-MAC Authority. 375 As with other Service chaining, a packet or a frame travels through a 376 network until it encounters an initial classifier. Forwarding before 377 the classifier is out of the scope of this specification. The native 378 packet format (L2 or L3 or tunneled, etc.) arriving at the classifier 379 does not matter but the classifier (or set of classifiers ) need to 380 inspect the packet and determine that the packet is part of a service 381 chain. 383 In all cases of MAC chaining after a frame (L2, L3, etc) has been 384 classified the MAC chain begins by prepending the packet with an 385 Ethernet L2 Frame header. The frame will also have a valid 4 byte CRC 386 checksum. 388 One advantage of MAC chaining is the MAC frame has an overhead of 389 bytes that can leave the L2 MTU unaffected. As with all Ethernet II 390 frames payload must be a minimum of 64 bytes or must be padded to 64 391 bytes. 393 4.2. Forwarding 395 Forwarding of a packet is from a classifier (SCF) to the Service 396 Function Forwarder (SFF) to the service function (SF) to the next SFF 397 to the next SF and so on until the chain is finished. MAC chaining 398 makes the distinction that the forwarding operations performed by a 399 SFF and a SF are distinct and independent. However implementations 400 may place SFF and SF functions as combined or separate entities. This 401 makes MAC chaining particularly useful for deployment in 402 virtualization environments where a virtual machine may implement one 403 or more SFs and SFFs. Forwarding is a table driven operation. Note 404 that all active chains are normally preprogrammed. 406 Figure 5 illustrates the table driven forwarding operation of a MAC 407 chaining SFF. Every frame arriving on the ingress VN port is matched 408 to the MAC chaining filtering database. On arrival at the SFF the DA 409 always contains a CS-MAC for the chain segment just crossed. The DA 410 is looked up in the context of Port 1 (a VN port) and the subsequent 411 DA prime (DA' a CS-MAC used as the new frame DA if this segment is DA 412 forwarding) and SA' (a CS-MAC used as the new frame SA if this 413 segment is DA/SA forwarding) and egress Port 1 prime (1') are 414 determined by the lookup. 416 Ingress Port1 Egress Port 417 +------+------+-----------+ +------+------+-----------+ 418 |CS_DA | SA | | -> | DA' | SA' | | 419 +--+---+------+-----------+ +------+------+-----------+ 420 | \............/ 421 | ^ 422 | | 423 | +--+ 424 | ....../........ 425 | / \ 426 | +-------+-------+-----+---------+-------+ 427 `------>|Port1 |CS_DA1 |DA1' | SA1' |Port1' | 428 |Port2 |CS_DA2 |DA2' | SA2' |Port2' | 429 |Port3 |CS_DA3 |DA3' | SA3' |Port3' | 430 | | | | | | 431 | | | | | | 432 +-------+-------+-----+---------+-------+ 433 MAC Chaining Filtering Database 435 Figure 5 MAC Chaining Table Operation 437 Any frame which doesn't exactly match an entry in the MAC chaining 438 filtering database MUST be discarded. The filtering database itself 439 is configured under the control of a network controller (see section 440 6) which is responsible for creating the chain by programming the MAC 441 chaining filtering database. The MAC chaining filtering database is 442 an exact match database which may use existing Bridge match logic. 443 The exact match filtering with hash implementation allows the 444 filtering database to easily scale to a large number of chains. 446 The Branch Taken (BT) Operation bit (figure 4) allows an SF to branch 447 the chain by changing the BT bit. Not all service chains are branch 448 capable. If a simple branch chain is desired it must be programmed in 449 the SFF filtering database. A branch operation is indicated by 450 setting a reserved bit in the CS-MAC address. This bit is not read as 451 a bit but as a paired address to the forward direction. The context 452 of the BT bit may be maintained in both the SA and the DA once the 453 bit has been set. An SFF receiving a frame with the BT bit set will 454 look up the exact match address and forward the frame in the context 455 of the received VN. 457 More complicated branching requires SF chain awareness. The next hop 458 addresses may be overridden by chain aware SFs to perform more 459 advance branching. A SF must be provided with the allocated addresses 460 for larger branches. 462 Any frame that arrives at an SFF and is not found in the forwarding 463 table is dropped. Devices in the path that are not MAC service 464 chaining aware are free to bridge the frame normally or to route 465 using any underlay Layer 3 or 2.5 VN encapsulation. 467 4.2.1. Forwarding by Service Functions 469 MAC chaining Service Functions (SFs) must be able to pass Ethernet 470 DA/SA addresses through the SF unless the SF is supported by a Proxy 471 Forwarder (see Proxy Forwarders section below). SFs are not required 472 to pass VLAN Tags. Service Functions supported by MAC chaining can be 473 classified by how they attach to the network as single armed, dual 474 armed or multi-armed. Single arm SFs receive and send all packets on 475 the same VN port. Single armed SFs are typically used when the 476 direction of travel is unimportant to the SF. Dual arm SFs have two 477 VN ports and pass packets between the two VN ports. Each VN port of a 478 dual arm SF must attach to a different virtual or physical network. 479 Dual arm SFs are typically used when the SF needs to know the 480 direction of travel. Multi-arm SFs have more than two VN ports. In a 481 multi-arm (two or more) the SF selects the egress VN port based on 482 its' re-classification of the packet. Each VN port of a multi-arm SF 483 must attach to a different VN or the SF must be MAC Chaining aware. 484 These SFs allow the SFs to branch the chain based on re- 485 classification or to replicate in the chain. 487 MAC chaining SFs can perform one of two types of frame forwarding 488 which are called DA/SA forwarding and DA forwarding. A SF that does 489 DA/SA forwarding forwards received frames to the entity identified by 490 the received SA. A SF that does DA forwarding passes the frame from 491 ingress VN port to the egress VN port without modifying the DA. The 492 choice of DA or DA/SA forwarding may be different for each chain 493 segment within a chain. 494 Service Functions performing DA/SA MAC chaining use explicit 495 receivers (standard Ethernet station interfaces) since the frames 496 directly address the SF. Service Functions using DA/SA MAC chaining 497 require only a single MAC address regardless of the number of chains 498 passing through them. Service Functions performing DA MAC chaining 499 must use a promiscuous receiver since the frames passing through them 500 will not be explicitly addressed to the SF. 502 Existing MAC chaining un-aware SFs that support transparent or Bridge 503 modes can support MAC chaining using DA forwarding. A MAC chaining 504 un-aware SF forwards a received frame using the same DA and SA as 505 received. MAC chaining Service Functions may also be MAC chaining 506 aware. A MAC chaining aware SF forwards received frames using the 507 received SA as the transmit DA, exchanging DA for SA in the frame. 508 For virtual SFs (i.e. VNFs) a MAC chaining unaware SF which copies 509 Ethernet SA and DA from ingress to egress can be converted into a MAC 510 chaining aware SF by running the SF in a guest OS equipped with MAC 511 chaining aware forwarding library. 513 To allow SF with more elaborate branching operations a SF may be 514 given a set of MAC chaining addresses corresponding to a set of 515 branches (enumerated). Details of the branch semantics such as load 516 balancing or branch to chain identifiers will be added in a future 517 revision of this document. 519 4.2.2. Proxy Forwarders 521 Proxy forwarding is typically for legacy devices or other devices 522 that do not have an ability to support MAC chaining by passing 523 through L2 headers. 525 Some service functions may reside on devices that do not understand 526 MAC chaining. Legacy functions on middle boxes are one example. In 527 this case a proxy forwarding function is used. Proxies may be 528 integrated with the SFF or located in the switches attaching to the 529 FS. The proxy will removing the MAC chaining header and forwarding 530 the packet in an appropriate format to the SF. The SF then returns 531 the packet to the proxy upon completion of its operation. The 532 Specific formats of frames between the proxy and the SF, when using a 533 proxy is out of the scope of this document. 535 The most basic proxy is a transparent proxy, which must be located 536 between the SF and any underlay entity. A transparent proxy provides 537 a provisioned Ethernet header which is used for forwarding all frames 538 egressed by a SF at a specific VN port. The use of a transparent 539 proxy limits the utility of the service chain in which it is inserted 540 since no chain state is passed through the SF by the proxy. 542 4.2.3. Example MAC Chaining Walk Through 544 Figure 6 outlines the general path and operations of a MAC chaining. 546 The Service Classification Function (SCF) determines if a packet 547 matches a predetermined policy for the chain by inspecting the packet 548 then selecting the chain by encoding the frame with next destination 549 equal to the chain segment 1 MAC Address A and itself as the Source 550 Address (SA) designated as H in figure 6. 552 SFF1 receives a frame from the SCF with Destination Address (DA) 553 equal to A and finds the next chain segment by looking up A to find 554 the next DA equal to SF2 MAC Address B and sets the SA equal to chain 555 segment 2 MAC Address C. 557 SF2 is a single armed Service Function which receives and sends all 558 data on a single network interface. The single SF2 network interface 559 normally connects to a single virtual or physical network. SF2 560 receives a frame from SFF1 performs its function and then returns the 561 frame to C. This process requires the SF to forward back to the 562 frame's SA, by swapping DA and SA, on the same VN port. 564 One Arm Two Arm 565 +-----+ +-----+ +------+ +-----+ +------+ +-----| +-----+ 566 | | | | \ SF2/ | | \ SF4/ | | | | 567 | SCF +---+ SFF1+----+B +----+ SFF1+----+D +----+ SFF2+-+ CTF | 568 | H| |A C| \/ |C | \/x |E T| |F | 569 +-----+ +-----+ +-----+ +-----+ +-----+ 570 \...../ \............../ \............../ \..../ 571 CS 1 CS2 CS3 CS4 573 +----+ +----+ +----+ +----+ +----+ +----+ 574 |A,H | |B,C | |C,B | |D,E | |E,x | |F,T | 575 +----+ +----+ +----+ +----+ +----+ +----+ 576 Frames showing MAC DA,SA 578 Figure 6 MAC Service Chain Example 580 SCF: Service Classification Function 581 CTF: Chain Termination Function 582 SF: Service Function 583 SFF: Service Function Forwarder 584 CSx: Chain Segment x. 586 SFF1 receives a frame from SF2 with DA equal to chain segment 2 MAC 587 Address C, finds the next chain segment by looking up C to find the 588 next destination equal to SF4 MAC Address D and the SA equals chain 589 segment 3 MAC Address E. 591 SF4 is a dual armed Service Function which receives and sends data on 592 two network interfaces. SF4 always forwards frames between its two 593 interfaces. The two interfaces of SF4 are normally connected to 594 separate virtual or physical networks. SF4 receives the frame from 595 SFF1 with DA equals D and SA equals E performs its function then 596 forwards to E by swapping DA with SA and sends out the packet to the 597 other VN port (A VN port that supports address E as a destination). 599 SFF2 receives a frame from SF4 with DA equals chain segment 3 MAC 600 Address E, finds the next chain segment by looking up E to find the 601 next destination equals chain segment 4 MAC Address F and SA equals 602 SFF2 MAC Address T. 604 The CTF receives a frame from SFF2 with destination equals F. The CTF 605 must perform any required packet header adjustment and egress VN port 606 determination based on the destination equals F and the frame payload 607 (i.e. uses the IP address to route the packet). 609 4.2.4. Destination Address MAC Chaining Operation 611 Destination MAC address chaining uses only the Destination MAC 612 address to key on and implement a chain. Destination Address MAC 613 chaining is used to operate with a MAC chaining un-aware SF. A 614 Classifier/Service Function Forwarder (SFF), composing a DA MAC 615 chaining hop, encodes the Chain Segment MAC in the frame DA and an 616 address for the SFF in the frame SA. This encoding will address the 617 next SFF or CTF in the chain. DA MAC chaining may only be used with 618 dual-arm or multi-arm SFs since an unmodified frame can't be returned 619 to the same network where it was received. Any SF along a DA MAC 620 chaining segment must be operating in Transparent or in Bridging mode 621 so it behaves as a "bump in the wire". 623 For a Service Function to participates in a DA MAC chaining it must 624 operate in promiscuous receiver, like an Ethernet Bridge, rather than 625 explicit receiver used by Ethernet stations. A MAC chaining Service 626 Function Forwarder uses promiscuous receiver on its' VN ports just 627 like every Ethernet Bridge and most Routers. In promiscuous receiver 628 the switch receives and inspects every frame presented to it 629 independent of the addressing on the frame. 631 DA MAC chaining is determined by the configuration of the forwarding 632 table in the SFF. After the initial classification the packet is 633 passed to the first SFF (this may be a virtual operation completely 634 within a single chaining switch). The SFF formats the Ethernet frame 635 with a DA of the next hop in the Chain. At each hop the MAC address 636 is looked up in a table similar to figure 2. 638 4.2.5. Destination and Source Address MAC Chaining 640 DA and SA MAC chaining is a variation of MAC chaining that allows MAC 641 chaining aware SFs to use explicit receiver and to support single 642 armed as well as dual and multi-armed SFs. When using DA/SA MAC 643 chaining the SF is individually addressed by the DA and therefore 644 does not need to operate using a promiscuous learning receiver. Such 645 a SF does not need a MAC lookup table and may be provisioned with a 646 single global or local address under any administration authority 647 (not necessarily the MAC chaining address authority). Service 648 Functions using DA/SA MAC chaining require only a single MAC address 649 regardless of the number of chains passing through them. DA/SA MAC 650 chaining is particularly advantageous for virtual service functions 651 (VNFs) since it reduces the need to flood frames into the virtual NIC 652 supporting the SFs virtual machines and server I/O accelerators. 654 DA/SA MAC chaining uses both addresses in the Ethernet L2 Header. The 655 DA is use for the next hop device and the SA is used for the 656 subsequent next hop device of the chain. A SF receives a frame; 657 processes the frame; replaces the DA with the received SA and uses 658 resulting DA (received SA) to forward the frame. By specifying 2 hops 659 in a chain the SF can be a very generic operation. The original SA of 660 the received frame does not have to be the address at the SFF that 661 created the header, allowing forwarding flexibility. 663 4.2.6. Forwarding by Chain Termination Functions 665 The forwarding to the final destination by the CTF typically does not 666 use MAC chaining. The CTF is responsible for receiving frames 667 addresses to the termination CS-MAC for each chain, de-encapsulating 668 the packets, and forwarding the packets toward their final 669 destination. One common method which may be used by the CTF for 670 forwarding to the final destination is to route the packets using the 671 IP address of the service packet. 673 If the service packet (data payload) is an L2 packet then the CTF may 674 use either the IP network addresses or the L2 addresses to forward 675 the packet. The choice between these two CTF forwarding models will 676 depend on the application. Other CTF forwarding models are possible 677 using by using the CS-MAC or meta-data for forwarding. 679 5. Programming a Service Chain 681 The capability exists today with open flow enabled switches to 682 specify MAC match criteria and actions that match MAC forwarding all 683 operations. However not all switches are Openflow enabled. 685 A Yang model could be specified to enable the MAC Chaining operations 686 using an I2RS agent. 688 Chains must be preprogrammed. Care must be taken to ensure that 689 service chain loops are not created. The policy is to drop a frame 690 that is not an exact match on any MAC chaining aware SFF. 692 MAC chaining may be programmed be allowed to pass through bridges 693 that are not MAC chaining aware. It is recommended that this 694 operation be explicitly controlled by setting up port based VLANs 695 designed for this purpose. Ports can add a VLAN tag as part of their 696 forwarding operation. This can be usually be achieved with existing 697 Ethernet controls that allow ports to have service tags added. The 698 VLAN tagging is independent of MAC chaining in this regard. 700 6. Domain of operation 702 MAC chaining requires connectivity of L2 virtual networks over the 703 service chain path. (This may include multiple VNs that are 704 interconnected.) In many networks this is readily available. Data 705 centers for example can use MAC chain within a physical site that has 706 L2 connectivity. 708 If Virtualization of the L2 domain is enabled MAC chaining could 709 operate over L2 networks such as NVO3 or Ethernet EVPN and an 710 existing L2 Overlay. 712 7. Security Considerations 714 MAC chaining is an Ethernet based forwarding operation that follows 715 standard Ethernet rules. VN ports should be qualified with VLANs 716 that limit the scope of MAC chaining frames. This prevents MAC 717 chaining messages from being flooded to external parts of the network 718 or injected into a network from external sources. Programming the 719 VLAN that support MAC chaining is controlled and access to those 720 VLANs is allowed only by trusted devices. 722 MAC chaining is IP agnostic but like any tunneling protocol it will 723 deliver IP frames to other parts of a network. 725 8. IANA Considerations 727 There are no IANA considerations for this document. 729 9. References 731 9.1. Normative References. 733 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 734 Requirement Levels", BCP 14, RFC 2119, March 1997. 736 [802-2001] "Standard for Local and Metropolitan Area Networks: 737 Overview and Architecture", IEEE 802, Standard 2014. 739 9.2. Informative References 741 [I-D.ietf-sfc-architecture] 742 Halpern, J., Pignataro, C. Editors, "Service Function 743 Chaining (SFC) Architecture", draft-ietf-sfc-architecture- 744 09(work in progress), June 2015. 746 [I-D.ietf-quinn-sfc-nsh] 747 P.Quinn et al., "Network Service Header", draft-quinn- 748 sfc-nsh-07 work in progress), February 2015. 750 10. Acknowledgments 752 This document was prepared using 2-Word-v2.0.template.dot. 754 Copyright (c) 2015 IETF Trust and the persons identified as authors 755 of the code. All rights reserved. 757 Redistribution and use in source and binary forms, with or without 758 modification, are permitted provided that the following conditions 759 are met: 761 o Redistributions of source code must retain the above copyright 762 notice, this list of conditions and the following disclaimer. 764 o Redistributions in binary form must reproduce the above copyright 765 notice, this list of conditions and the following disclaimer in 766 the documentation and/or other materials provided with the 767 distribution. 769 o Neither the name of Internet Society, IETF or IETF Trust, nor the 770 names of specific contributors, may be used to endorse or promote 771 products derived from this software without specific prior written 772 permission. 774 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 775 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 776 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 777 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 778 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 779 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 780 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 781 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 782 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 783 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 784 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 786 Authors' Addresses 788 Don Fedyk 789 Hewlett Packard Networking 790 153 Taylor Street 791 Littleton, MA 792 Email: don.fedyk@hp.com 794 Paul Bottorff 795 Hewlett Packard Networking 796 8000 Foothills Blvd. 797 Roseville, CA 798 Email: paul.bottorff@hp.com