Network Working Group P. Bottorff Internet Draft D. Fedyk Intended status: Informational HP Networking Expires: January 2016 July 20, 2015 Ethernet MAC Chaining draft-fedyk-sfc-mac-chain-00.txt Abstract This document introduces and describes a simple and highly scalable service function chaining mechanism called MAC chaining which is built largely on existing Ethernet frame and forwarding capabilities. MAC chaining uses IEEE 802 Media Access Control (MAC) addresses to provide flexible and complete service function chains. It is largely transparent to layers above Ethernet and designed to augment and coexist with existing virtual and physical network forwarding. MAC chaining is achievable in some devices and virtual switches today using existing protocols. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on January 14, 2016. Fedyk Expires January 20, 2016 [Page 1] Internet-Draft Ethernet MAC Chaining July 2015 Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction...................................................2 2. Conventions used in this document..............................4 3. Terminology....................................................4 4. MAC Chaining...................................................5 4.1. MAC Chaining Packet and Address Formats...................6 4.2. Forwarding................................................9 4.2.1. Forwarding by Service Functions.....................11 4.2.2. Proxy Forwarders....................................12 4.2.3. Example MAC Chaining Walk Through...................13 4.2.4. Destination Address MAC Chaining Operation..........14 4.2.5. Destination and Source Address MAC Chaining.........15 4.2.6. Forwarding by Chain Termination Functions...........15 5. Programming a Service Chain...................................16 6. Domain of operation...........................................16 7. Security Considerations.......................................16 8. IANA Considerations...........................................17 9. References....................................................17 9.1. Normative References.....................................17 9.2. Informative References...................................17 10. Acknowledgments..............................................17 1. Introduction Service Function Chaining (SFC) enables the creation of composite (network) services that consist of a directed graph of Service Functions (SF) which must be applied to packets selected as a result of classification. SFC is described in detail in the SFC architecture document [I-D.ietf-sfc-architecture], and is not repeated here. Fedyk Expires January 20, 2016 [Page 2] Internet-Draft Ethernet MAC Chaining July 2015 This document describes a new highly scalable, low resource, service function chain (SFC) mechanism called MAC chaining that is based on the current IEEE 802 Ethernet header for physical and virtualized environments. Service function chaining is an active area in the standards and various proposals for how to do SFCs are being put forward. The basic mechanism used for MAC chaining is the use of MAC addresses in the Ethernet header as a mechanism both for identifying chains and for forwarding packets along a MAC chain. The forwarding mechanism used in MAC chaining is independent from virtual or overlay networks used to form subnets. MAC chaining addresses are terminated at each Service Function Forwarder (SFF) and replaced by a new set of MAC chaining addresses used to forward through the next Service Function in the chain. +-----------------------------------------+ / E2E Network / / / +-----------------------------------------+ +----------------------------------+ O /| / MAC Function Chaining / R / | / / C / | +----------------------------------+ H / | +----------------------------------+ E | | / Virtual Networks / S | | / Overlay/Underlay / T | | +----------------------------------+ R | | +---------------+ +---------------+ A | | / Physical / / Physical / T | | / Networks / / Networks / I | | +---------------+ +---------------+ O | / N | / | / |/ Figure 1 Service Forwarding Plane MAC function chaining can be viewed as a network service plane as shown in Figure 1. The SFC architecture document [I-D.ietf-sfc- architecture] describes chain forwarding in terms of 3 main architecture components which are the Service Classification Function (SCF), Service Function Forwarder (SFF) and the Service Function (SF). When managed with MAC chaining, Service Functions (SF) are simple links in the service chain and require little context of the Fedyk Expires January 20, 2016 [Page 3] Internet-Draft Ethernet MAC Chaining July 2015 overall chain. MAC chaining Service Function Forwarders (SFF) enable the chain and control the path to and from the SFs. Logically the SFF forms a switching layer above the existing virtual networking layers. For the description of MAC chaining Chain Termination Function (CTF) is described which is responsible for de-encapsulating the packet and sending it toward the final destination as a separate architectural component from the SFF and the SFC. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. 3. Terminology Chain Termination Function (CTF): See [I-D.ietf-sfc-architecture]. The chain termination function terminates a Service Function Path performing any de-encapsulation and operations required to continue forwarding to the final destination. The CTF may also be the final destination of the chain. CS-MAC: A MAC address which identifies a MAC Chain Segment CS-MAC Authority: CS-MAC Authority refers to the mechanism to ensure CS-MACs are unique but allows the optional reuse of MACs in different VNs. Each VN port has a single CS-MAC Authority. Multiple ports may share the same Authority. A MAC Chain may be under a single CS-MAC Authority or it may be split among multiple CS-MAC Authorities. DA: MAC destination address I/G The Individual/Group (I/G) address bit (LSB of octet 0). MAC Address: IEEE 802 Media Access Control Address a 48 bit address. MAC Chain Segment (CS): A hop between either Service Forwarding Functions, a Service Classification Function and a Service Forwarding Function, or a Service Forwarding Function and a Chain Termination Function Fedyk Expires January 20, 2016 [Page 4] Internet-Draft Ethernet MAC Chaining July 2015 VN Port: In this document a port is the logical interface context for a MAC address in a virtual network (VN). A VN port may be implemented on any type of physical port or logical supporting Ethernet. SA: MAC source address Service Function (SF): See [I-D.ietf-sfc-architecture]. Service Classification Function (SCF): See [I-D.ietf-sfc-architecture]. Service Function Chain (SFC): See [I-D.ietf-sfc-architecture]. Service Function Forwarder (SFF): See [I-D.ietf-sfc-architecture]. Service Function Path (SFP): See [I-D.ietf-sfc-architecture]. U/L: The Universally or Locally administered (U/L) address bit is the bit of octet 0 adjacent to the I/G bit. Virtual Network (VN): A Virtual network is used to identify a network segment controlled by a CS-MAC Authority. 4. MAC Chaining MAC chaining uses controlled assignment of Ethernet 48 bit MAC addresses to form the chain. Ethernet MAC addresses are selected to uniquely identify both the chain and the particular chain segment (or hop) within the identified chain. These assigned Ethernet addresses are called Chain Segment MAC (CS-MAC) addresses in this document. These CS-MACs allow MAC chaining to be implemented on existing Ethernet infrastructure making it broadly interoperable with the majority of installed base including existing Ethernet, Carrier Ethernet and IP equipment. Each MAC chain is composed of a series of Chain Segments (CS) which are hops between Classifiers, Service Function Forwarders and Chain Terminating Functions (see figure 2). Some of the chain segments include Service Functions while others perform forwarding between the SCF, SFF and CTF switches. For each chain segment, a MAC address is selected, from a locally administered MAC address space, to uniquely identify the chain segment within the SFC domain. MAC chaining uses these CS-MACs, in the Ethernet header, as an identifier to enable forwarding packets in a MAC chain. Fedyk Expires January 20, 2016 [Page 5] Internet-Draft Ethernet MAC Chaining July 2015 +-----+ +-----+ +------+ +-----+ +-----+ +------+ +-----| +-----+ | | | | \ SF2/ | | | | \ SF4/ | | | | | SCF +--+ SFF1+---+B +---+ SFF1+-+ SFF2+---+D +---+ SFF2+-+ CTF | | X| 1|A C|2 \/ 2|C | | E|3 \/ 4|E Y| |F | +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ \...../ \............/ \.../ \............/ \..../ CS 1 CS 2 CS 5 CS 3 CS 4 CS-MAC=A CS-MAC=C CS-MAC=G CS-MAC=E CS-MAC=F Figure 2 MAC Chain Segments Addressing In Figure 2 five chain segments are illustrated. The first chain segment is between the classifier and service function forwarder identified as SFF1. This chain segment, designated CS1, has been assigned CS-MAC A. (For brevity the 48 bit MAC addresses are identified by letters). The next chain segment is from SFF1 VN port 2 through service function 2 and back to SFF1 VN port 2. This chain segment designated CS2 has been assigned CS-MAC C. SF2 on CS2 is a single armed SF with MAC address B attached to SFF VN port 2. (see section 4.2.1 for a description of the types of armed SF). Chain segment CS5 is between service function forwarder 1 and service function forwarder 2. It has an assigned CS-MAC G. Chain segment CS3 from SFF2 VN port 3 to SFF2 VN port 4 is identified by CS-MAC E. SF4, lying on CS3, is a dual armed SF with MAC address D on the side connecting to SFF2 VN port 3. The final chain segment, CS4, of the path is between SFF2 and the CTF and is identified by CS-MAC F. MAC chaining operates in the context of Virtual Networks (VN). To fully describe each MAC chaining address the tuple (CS-MAC Authority, CS-MAC) is used which uniquely identifies each chain segment as well as the entire chain. Each chain segment and each VN MUST belong to a single CS-MAC Authority which assigns unique CS-MACs for that segment and VN. If a chain segment crosses between two independent VNs, then both the VNs must have the same CS-MAC Authority. 4.1. MAC Chaining Packet and Address Formats The IEEE 802.3 frame header consists of a Destination MAC Address (6 bytes DA) followed by a Source MAC Address (6 Bytes SA) followed by a number of possible fields: Ether type (2 Bytes) or other TAGs and Ether types. A VLAN tag (4 bytes) is a common TAG that also carries Priority Code Points and Discard Eligible Information for traffic class. For the purpose of this document the DA and SA are the primary fields used for MAC chaining however the frame may optionally have VLAN Tags. The MAC chaining frame can also be carried inside Fedyk Expires January 20, 2016 [Page 6] Internet-Draft Ethernet MAC Chaining July 2015 (i.e. as an NVO3 overlay) other encapsulations like VxLAN, L2VPN or Provider Backbone Bridging (PBB). Figure 3 illustrates the formats for MAC chaining used to carry the original IPv4 packets or L2 frames entering the classifier. Since MAC chaining encodes a SFC path in the MAC addresses of the Ethernet header it is not necessary to have the Network Service Header(NSH) [I-D.ietf-quinn-sfc-nsh] on every segment of the chain. The NSH is required on any NSH aware chain segment where meta-data is being carried. Original IPv4, MAC Chaining without NSH: +-------------------------------------------+--------------------+ | Outer Ethernet, ET=0x0800 | original IP Packet | +-------------------------------------------+--------------------+ Original IPv4, MAC Chaining with NSH +---------------------------+---------------+--------------------+ | Outer Ethernet, ET=0x894F | NSH, NP = 0x1 | original IP Packet | +---------------------------+---------------+--------------------+ Original L2, MAC Chaining without NSH +-------------------------------------------+--------------------+ | Outer Ethernet, ET=0x**** | original L2 frame | +-------------------------------------------+--------------------+ Original L2, MAC Chaining with NSH +---------------------------+---------------+--------------------+ | Outer Ethernet, ET=0x894F | NSH, NP = 0x3 | original L2 frame | +---------------------------+---------------+--------------------+ Figure 3 MAC Chaining Formats for IPv4 and L2 Service Packets The branch taken bit (figure 4) is a small piece of meta data that can be used in the MAC chaining header. For more elaborate meta data, the Network Service Header draft [I-D.ietf-quinn-sfc-nsh] header is compatible with MAC chaining. Section 11.3 [I-D.ietf-quinn-sfc-nsh] illustrates that the Ether type following a MAC chaining outer header has a registered type of 0x894F with an NSH that subsequently defines the payload. SFs can use the NSH within the chain. Any SCF, SF or CTF can remove or modify the NSH as specified in the NSH. When using the IETF NSH draft header each SF must either be capable of receiving an Ethernet frame with the NSH or must be supported by a proxy which removes the NSH before the SF. Fedyk Expires January 20, 2016 [Page 7] Internet-Draft Ethernet MAC Chaining July 2015 The format of the MAC address used by MAC chaining is the standard IEEE MAC address format of 48 bits as illustrated in figure 4. Every MAC address is identified as either a global or a local MAC address. Global MAC addresses are intended to be worldwide unique while local address are intended for the use of local administrations domains and are not worldwide unique. Each global address uses a 22 bit Organizational Unique Identifier (OUI) prefix which is assigned by the IEEE Registration Authority Committee to support worldwide uniqueness. Recently, in response the needs of virtualization environments, the IEEE Registration Authority Committee has started assigning 22 bit Company IDs (CID) to allow independent vendors to share the local MAC addresses space within a domain where multiple un-coordinated authorities are assigning addresses. MAC chaining MAY make use of the new administered local MAC addresses. I U / / B G L T +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X|n|CID1[42:47]| CID2[32:39] | CID3[24:31] |CS-ID[16:22] |X| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CS-ID [8:15] | CS-ID [0:7] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 MAC Chaining Ethernet MAC address Format Where: I/G IEEE 802 Ethernet Individual/ Group address bit. U/L IEEE 802 Ethernet Universal / Local Bit. Bit MAY be set indicating local. CID Company ID - 22 Bits (Not Mandatory example only). Company Ids are assigned by IEEE registration to vendors who use Local addresses for MAC chaining or other purposes. The CIDs are unique and ensure that there are no collisions with other protocols that use local addresses. However the local addresses can be reused in other networks. BT Branch Taken Chain indicator. Required. This bit may be set or reset in context of a chain. CS-ID Chain Segment ID 23 bits. (Example only). Fedyk Expires January 20, 2016 [Page 8] Internet-Draft Ethernet MAC Chaining July 2015 CS-MAC addresses, which identify chain segments, SHOULD be allocated by the CS-MAC Authority from the local space using a Company ID assigned to the CS-MAC Authority. MAC addresses also have an Individual (unicast) or Group (Multicast) bit I/G. MAC chaining MAY use individual or group addresses for the CS-MACs though restriction on the use of group CS-MACs may apply depending on the type of forwarding performed by the SFF for the particular segment. MAC chaining may also use global or local MAC addresses. The MAC address assigned to a Service Function MAY be Global or Local and can be assigned by any authority, not necessarily the CS-MAC Authority. As with other Service chaining, a packet or a frame travels through a network until it encounters an initial classifier. Forwarding before the classifier is out of the scope of this specification. The native packet format (L2 or L3 or tunneled, etc.) arriving at the classifier does not matter but the classifier (or set of classifiers ) need to inspect the packet and determine that the packet is part of a service chain. In all cases of MAC chaining after a frame (L2, L3, etc) has been classified the MAC chain begins by prepending the packet with an Ethernet L2 Frame header. The frame will also have a valid 4 byte CRC checksum. One advantage of MAC chaining is the MAC frame has an overhead of bytes that can leave the L2 MTU unaffected. As with all Ethernet II frames payload must be a minimum of 64 bytes or must be padded to 64 bytes. 4.2. Forwarding Forwarding of a packet is from a classifier (SCF) to the Service Function Forwarder (SFF) to the service function (SF) to the next SFF to the next SF and so on until the chain is finished. MAC chaining makes the distinction that the forwarding operations performed by a SFF and a SF are distinct and independent. However implementations may place SFF and SF functions as combined or separate entities. This makes MAC chaining particularly useful for deployment in virtualization environments where a virtual machine may implement one or more SFs and SFFs. Forwarding is a table driven operation. Note that all active chains are normally preprogrammed. Figure 5 illustrates the table driven forwarding operation of a MAC chaining SFF. Every frame arriving on the ingress VN port is matched to the MAC chaining filtering database. On arrival at the SFF the DA always contains a CS-MAC for the chain segment just crossed. The DA Fedyk Expires January 20, 2016 [Page 9] Internet-Draft Ethernet MAC Chaining July 2015 is looked up in the context of Port 1 (a VN port) and the subsequent DA prime (DA' a CS-MAC used as the new frame DA if this segment is DA forwarding) and SA' (a CS-MAC used as the new frame SA if this segment is DA/SA forwarding) and egress Port 1 prime (1') are determined by the lookup. Ingress Port1 Egress Port +------+------+-----------+ +------+------+-----------+ |CS_DA | SA | | -> | DA' | SA' | | +--+---+------+-----------+ +------+------+-----------+ | \............/ | ^ | | | +--+ | ....../........ | / \ | +-------+-------+-----+---------+-------+ `------>|Port1 |CS_DA1 |DA1' | SA1' |Port1' | |Port2 |CS_DA2 |DA2' | SA2' |Port2' | |Port3 |CS_DA3 |DA3' | SA3' |Port3' | | | | | | | | | | | | | +-------+-------+-----+---------+-------+ MAC Chaining Filtering Database Figure 5 MAC Chaining Table Operation Any frame which doesn't exactly match an entry in the MAC chaining filtering database MUST be discarded. The filtering database itself is configured under the control of a network controller (see section 6) which is responsible for creating the chain by programming the MAC chaining filtering database. The MAC chaining filtering database is an exact match database which may use existing Bridge match logic. The exact match filtering with hash implementation allows the filtering database to easily scale to a large number of chains. The Branch Taken (BT) Operation bit (figure 4) allows an SF to branch the chain by changing the BT bit. Not all service chains are branch capable. If a simple branch chain is desired it must be programmed in the SFF filtering database. A branch operation is indicated by setting a reserved bit in the CS-MAC address. This bit is not read as a bit but as a paired address to the forward direction. The context Fedyk Expires January 20, 2016 [Page 10] Internet-Draft Ethernet MAC Chaining July 2015 of the BT bit may be maintained in both the SA and the DA once the bit has been set. An SFF receiving a frame with the BT bit set will look up the exact match address and forward the frame in the context of the received VN. More complicated branching requires SF chain awareness. The next hop addresses may be overridden by chain aware SFs to perform more advance branching. A SF must be provided with the allocated addresses for larger branches. Any frame that arrives at an SFF and is not found in the forwarding table is dropped. Devices in the path that are not MAC service chaining aware are free to bridge the frame normally or to route using any underlay Layer 3 or 2.5 VN encapsulation. 4.2.1. Forwarding by Service Functions MAC chaining Service Functions (SFs) must be able to pass Ethernet DA/SA addresses through the SF unless the SF is supported by a Proxy Forwarder (see Proxy Forwarders section below). SFs are not required to pass VLAN Tags. Service Functions supported by MAC chaining can be classified by how they attach to the network as single armed, dual armed or multi-armed. Single arm SFs receive and send all packets on the same VN port. Single armed SFs are typically used when the direction of travel is unimportant to the SF. Dual arm SFs have two VN ports and pass packets between the two VN ports. Each VN port of a dual arm SF must attach to a different virtual or physical network. Dual arm SFs are typically used when the SF needs to know the direction of travel. Multi-arm SFs have more than two VN ports. In a multi-arm (two or more) the SF selects the egress VN port based on its' re-classification of the packet. Each VN port of a multi-arm SF must attach to a different VN or the SF must be MAC Chaining aware. These SFs allow the SFs to branch the chain based on re- classification or to replicate in the chain. MAC chaining SFs can perform one of two types of frame forwarding which are called DA/SA forwarding and DA forwarding. A SF that does DA/SA forwarding forwards received frames to the entity identified by the received SA. A SF that does DA forwarding passes the frame from ingress VN port to the egress VN port without modifying the DA. The Fedyk Expires January 20, 2016 [Page 11] Internet-Draft Ethernet MAC Chaining July 2015 choice of DA or DA/SA forwarding may be different for each chain segment within a chain. Service Functions performing DA/SA MAC chaining use explicit receivers (standard Ethernet station interfaces) since the frames directly address the SF. Service Functions using DA/SA MAC chaining require only a single MAC address regardless of the number of chains passing through them. Service Functions performing DA MAC chaining must use a promiscuous receiver since the frames passing through them will not be explicitly addressed to the SF. Existing MAC chaining un-aware SFs that support transparent or Bridge modes can support MAC chaining using DA forwarding. A MAC chaining un-aware SF forwards a received frame using the same DA and SA as received. MAC chaining Service Functions may also be MAC chaining aware. A MAC chaining aware SF forwards received frames using the received SA as the transmit DA, exchanging DA for SA in the frame. For virtual SFs (i.e. VNFs) a MAC chaining unaware SF which copies Ethernet SA and DA from ingress to egress can be converted into a MAC chaining aware SF by running the SF in a guest OS equipped with MAC chaining aware forwarding library. To allow SF with more elaborate branching operations a SF may be given a set of MAC chaining addresses corresponding to a set of branches (enumerated). Details of the branch semantics such as load balancing or branch to chain identifiers will be added in a future revision of this document. 4.2.2. Proxy Forwarders Proxy forwarding is typically for legacy devices or other devices that do not have an ability to support MAC chaining by passing through L2 headers. Some service functions may reside on devices that do not understand MAC chaining. Legacy functions on middle boxes are one example. In this case a proxy forwarding function is used. Proxies may be integrated with the SFF or located in the switches attaching to the FS. The proxy will removing the MAC chaining header and forwarding the packet in an appropriate format to the SF. The SF then returns the packet to the proxy upon completion of its operation. The Specific formats of frames between the proxy and the SF, when using a proxy is out of the scope of this document. Fedyk Expires January 20, 2016 [Page 12] Internet-Draft Ethernet MAC Chaining July 2015 The most basic proxy is a transparent proxy, which must be located between the SF and any underlay entity. A transparent proxy provides a provisioned Ethernet header which is used for forwarding all frames egressed by a SF at a specific VN port. The use of a transparent proxy limits the utility of the service chain in which it is inserted since no chain state is passed through the SF by the proxy. 4.2.3. Example MAC Chaining Walk Through Figure 6 outlines the general path and operations of a MAC chaining. The Service Classification Function (SCF) determines if a packet matches a predetermined policy for the chain by inspecting the packet then selecting the chain by encoding the frame with next destination equal to the chain segment 1 MAC Address A and itself as the Source Address (SA) designated as H in figure 6. SFF1 receives a frame from the SCF with Destination Address (DA) equal to A and finds the next chain segment by looking up A to find the next DA equal to SF2 MAC Address B and sets the SA equal to chain segment 2 MAC Address C. SF2 is a single armed Service Function which receives and sends all data on a single network interface. The single SF2 network interface normally connects to a single virtual or physical network. SF2 receives a frame from SFF1 performs its function and then returns the frame to C. This process requires the SF to forward back to the frame's SA, by swapping DA and SA, on the same VN port. One Arm Two Arm +-----+ +-----+ +------+ +-----+ +------+ +-----| +-----+ | | | | \ SF2/ | | \ SF4/ | | | | | SCF +---+ SFF1+----+B +----+ SFF1+----+D +----+ SFF2+-+ CTF | | H| |A C| \/ |C | \/x |E T| |F | +-----+ +-----+ +-----+ +-----+ +-----+ \...../ \............../ \............../ \..../ CS 1 CS2 CS3 CS4 +----+ +----+ +----+ +----+ +----+ +----+ |A,H | |B,C | |C,B | |D,E | |E,x | |F,T | +----+ +----+ +----+ +----+ +----+ +----+ Frames showing MAC DA,SA Figure 6 MAC Service Chain Example Fedyk Expires January 20, 2016 [Page 13] Internet-Draft Ethernet MAC Chaining July 2015 SCF: Service Classification Function CTF: Chain Termination Function SF: Service Function SFF: Service Function Forwarder CSx: Chain Segment x. SFF1 receives a frame from SF2 with DA equal to chain segment 2 MAC Address C, finds the next chain segment by looking up C to find the next destination equal to SF4 MAC Address D and the SA equals chain segment 3 MAC Address E. SF4 is a dual armed Service Function which receives and sends data on two network interfaces. SF4 always forwards frames between its two interfaces. The two interfaces of SF4 are normally connected to separate virtual or physical networks. SF4 receives the frame from SFF1 with DA equals D and SA equals E performs its function then forwards to E by swapping DA with SA and sends out the packet to the other VN port (A VN port that supports address E as a destination). SFF2 receives a frame from SF4 with DA equals chain segment 3 MAC Address E, finds the next chain segment by looking up E to find the next destination equals chain segment 4 MAC Address F and SA equals SFF2 MAC Address T. The CTF receives a frame from SFF2 with destination equals F. The CTF must perform any required packet header adjustment and egress VN port determination based on the destination equals F and the frame payload (i.e. uses the IP address to route the packet). 4.2.4. Destination Address MAC Chaining Operation Destination MAC address chaining uses only the Destination MAC address to key on and implement a chain. Destination Address MAC chaining is used to operate with a MAC chaining un-aware SF. A Classifier/Service Function Forwarder (SFF), composing a DA MAC chaining hop, encodes the Chain Segment MAC in the frame DA and an address for the SFF in the frame SA. This encoding will address the next SFF or CTF in the chain. DA MAC chaining may only be used with dual-arm or multi-arm SFs since an unmodified frame can't be returned to the same network where it was received. Any SF along a DA MAC chaining segment must be operating in Transparent or in Bridging mode so it behaves as a "bump in the wire". For a Service Function to participates in a DA MAC chaining it must operate in promiscuous receiver, like an Ethernet Bridge, rather than Fedyk Expires January 20, 2016 [Page 14] Internet-Draft Ethernet MAC Chaining July 2015 explicit receiver used by Ethernet stations. A MAC chaining Service Function Forwarder uses promiscuous receiver on its' VN ports just like every Ethernet Bridge and most Routers. In promiscuous receiver the switch receives and inspects every frame presented to it independent of the addressing on the frame. DA MAC chaining is determined by the configuration of the forwarding table in the SFF. After the initial classification the packet is passed to the first SFF (this may be a virtual operation completely within a single chaining switch). The SFF formats the Ethernet frame with a DA of the next hop in the Chain. At each hop the MAC address is looked up in a table similar to figure 2. 4.2.5. Destination and Source Address MAC Chaining DA and SA MAC chaining is a variation of MAC chaining that allows MAC chaining aware SFs to use explicit receiver and to support single armed as well as dual and multi-armed SFs. When using DA/SA MAC chaining the SF is individually addressed by the DA and therefore does not need to operate using a promiscuous learning receiver. Such a SF does not need a MAC lookup table and may be provisioned with a single global or local address under any administration authority (not necessarily the MAC chaining address authority). Service Functions using DA/SA MAC chaining require only a single MAC address regardless of the number of chains passing through them. DA/SA MAC chaining is particularly advantageous for virtual service functions (VNFs) since it reduces the need to flood frames into the virtual NIC supporting the SFs virtual machines and server I/O accelerators. DA/SA MAC chaining uses both addresses in the Ethernet L2 Header. The DA is use for the next hop device and the SA is used for the subsequent next hop device of the chain. A SF receives a frame; processes the frame; replaces the DA with the received SA and uses resulting DA (received SA) to forward the frame. By specifying 2 hops in a chain the SF can be a very generic operation. The original SA of the received frame does not have to be the address at the SFF that created the header, allowing forwarding flexibility. 4.2.6. Forwarding by Chain Termination Functions The forwarding to the final destination by the CTF typically does not use MAC chaining. The CTF is responsible for receiving frames addresses to the termination CS-MAC for each chain, de-encapsulating the packets, and forwarding the packets toward their final destination. One common method which may be used by the CTF for forwarding to the final destination is to route the packets using the IP address of the service packet. Fedyk Expires January 20, 2016 [Page 15] Internet-Draft Ethernet MAC Chaining July 2015 If the service packet (data payload) is an L2 packet then the CTF may use either the IP network addresses or the L2 addresses to forward the packet. The choice between these two CTF forwarding models will depend on the application. Other CTF forwarding models are possible using by using the CS-MAC or meta-data for forwarding. 5. Programming a Service Chain The capability exists today with open flow enabled switches to specify MAC match criteria and actions that match MAC forwarding all operations. However not all switches are Openflow enabled. A Yang model could be specified to enable the MAC Chaining operations using an I2RS agent. Chains must be preprogrammed. Care must be taken to ensure that service chain loops are not created. The policy is to drop a frame that is not an exact match on any MAC chaining aware SFF. MAC chaining may be programmed be allowed to pass through bridges that are not MAC chaining aware. It is recommended that this operation be explicitly controlled by setting up port based VLANs designed for this purpose. Ports can add a VLAN tag as part of their forwarding operation. This can be usually be achieved with existing Ethernet controls that allow ports to have service tags added. The VLAN tagging is independent of MAC chaining in this regard. 6. Domain of operation MAC chaining requires connectivity of L2 virtual networks over the service chain path. (This may include multiple VNs that are interconnected.) In many networks this is readily available. Data centers for example can use MAC chain within a physical site that has L2 connectivity. If Virtualization of the L2 domain is enabled MAC chaining could operate over L2 networks such as NVO3 or Ethernet EVPN and an existing L2 Overlay. 7. Security Considerations MAC chaining is an Ethernet based forwarding operation that follows standard Ethernet rules. VN ports should be qualified with VLANs that limit the scope of MAC chaining frames. This prevents MAC chaining messages from being flooded to external parts of the network or injected into a network from external sources. Programming the Fedyk Expires January 20, 2016 [Page 16] Internet-Draft Ethernet MAC Chaining July 2015 VLAN that support MAC chaining is controlled and access to those VLANs is allowed only by trusted devices. MAC chaining is IP agnostic but like any tunneling protocol it will deliver IP frames to other parts of a network. 8. IANA Considerations There are no IANA considerations for this document. 9. References 9.1. Normative References. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [802-2001] "Standard for Local and Metropolitan Area Networks: Overview and Architecture", IEEE 802, Standard 2014. 9.2. Informative References [I-D.ietf-sfc-architecture] Halpern, J., Pignataro, C. Editors, "Service Function Chaining (SFC) Architecture", draft-ietf-sfc-architecture- 09(work in progress), June 2015. [I-D.ietf-quinn-sfc-nsh] P.Quinn et al., "Network Service Header", draft-quinn- sfc-nsh-07 work in progress), February 2015. 10. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Copyright (c) 2015 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: o Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Fedyk Expires January 20, 2016 [Page 17] Internet-Draft Ethernet MAC Chaining July 2015 o Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. o Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Fedyk Expires January 20, 2016 [Page 18] Internet-Draft Ethernet MAC Chaining July 2015 Authors' Addresses Don Fedyk Hewlett Packard Networking 153 Taylor Street Littleton, MA Email: don.fedyk@hp.com Paul Bottorff Hewlett Packard Networking 8000 Foothills Blvd. Roseville, CA Email: paul.bottorff@hp.com Fedyk Expires January 20, 2016 [Page 19]