RFC 8013
Forwarding and Control Element Separation (ForCES) Inter-FE Logical Functional Block (LFB)
Forwarding and Control Element Separation (ForCES) Inter-FE Logical Functional Block (LFB) 🎀
Okay bestie, this one is RFC 8013, an IETF Standards Track doc published in February 2017 (ISSN 2070-1721). It was written by D. Joachimpillai from Verizon and J. Hadi Salim from Mojatatu Networks. It doesn't list anything it obsoletes or updates, so it's standing on its own ✨
Abstract
This document shows how to stretch the ForCES Logical Functional Block (LFB) topology across Forwarding Elements (FEs) by defining the inter-FE LFB class 💅 The inter-FE LFB class lets data and metadata hop between FEs without changing the ForCES specification at all, which is iconic. The focus is on Ethernet transport 🦋
Status of This Memo
This is an Internet Standards Track document 🌈
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, and it went through public review before the Internet Engineering Steering Group (IESG) approved it for publication 🫶 If you want more on Internet Standards, check out Section 2 of RFC 7841.
For the current status, any errata, and how to send feedback, head to http://www.rfc-editor.org/info/rfc8013 💜
Copyright Notice
Copyright (c) 2017 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), as they stood on the publication date. Please read these carefully, bestie, because they spell out your rights and restrictions for this doc 📜 Any code components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 💀
Table of Contents ✨
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Scope and Use Cases . . . . . . . . . . . . . . . . . 4
3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Sample Use Cases . . . . . . . . . . . . . . . . . . . . 4
3.2.1. Basic IPv4 Router . . . . . . . . . . . . . . . . . . 4
3.2.1.1. Distributing the Basic IPv4 Router . . . . . . . 6
3.2.2. Arbitrary Network Function . . . . . . . . . . . . . 7
3.2.2.1. Distributing the Arbitrary Network Function . . . 8
4. Inter-FE LFB Overview . . . . . . . . . . . . . . . . . . . . 8
4.1. Inserting the Inter-FE LFB . . . . . . . . . . . . . . . 8
5. Inter-FE Ethernet Connectivity . . . . . . . . . . . . . . . 10
5.1. Inter-FE Ethernet Connectivity Issues . . . . . . . . . . 10
5.1.1. MTU Consideration . . . . . . . . . . . . . . . . . . 10
5.1.2. Quality-of-Service Considerations . . . . . . . . . . 11
5.1.3. Congestion Considerations . . . . . . . . . . . . . . 11
5.2. Inter-FE Ethernet Encapsulation . . . . . . . . . . . . . 12
6. Detailed Description of the Ethernet Inter-FE LFB . . . . . . 13
6.1. Data Handling . . . . . . . . . . . . . . . . . . . . . . 13
6.1.1. Egress Processing . . . . . . . . . . . . . . . . . . 14
6.1.2. Ingress Processing . . . . . . . . . . . . . . . . . 15
6.2. Components . . . . . . . . . . . . . . . . . . . . . . . 16
6.3. Inter-FE LFB XML Model . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8. IEEE Assignment Considerations . . . . . . . . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . 24
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 251. Introduction 🧚
In the ForCES architecture, you can model a packet service by composing a graph of one or more LFB instances 💖 If you want the full details, the ForCES model is in [RFC5812].
The ForCES model describes what happens inside a single FE using LFBs. It also gives the Control Element (CE) a way to set up and change that processing sequence, plus the parameters for each individual LFB 🍓
Sometimes it's really useful to stretch that view across more than one FE. You might want to scale by splitting the work between elements, or you might want to use specialized hardware that only lives on certain FEs 👑
The ForCES inter-LFB architecture already lets metadata move between LFBs, so it's a must (okay, a need) to define ways to extend that feature so metadata can also move between LFBs on different FEs ✨
This document explains how to extend the LFB topology across FEs. That means inter-FE connectivity, and you don't have to change any ForCES definitions to get it. The document focuses on using Ethernet as the link between FEs 🦋
2. Terminology and Conventions 💅
2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document get interpreted as described in [RFC2119] 🔥
2.2. Definitions
This doc leans on terms defined in several ForCES documents: [RFC3746], [RFC5810], [RFC5811], [RFC5812], [RFC7391], and [RFC7408] 📜 The terms are:
Control Element (CE)Forwarding Element (FE)FE ModelLFB (Logical Functional Block) Class (or type)LFB InstanceLFB ModelLFB MetadataForCES ComponentLFB ComponentForCES Protocol Layer (ForCES PL)ForCES Protocol Transport Mapping Layer (ForCES TML)
3. Problem Scope and Use Cases 🌸
The point of this document is to solve the problem of passing ForCES-defined metadata along with packet data across FEs. That includes physical and virtual FEs, and the whole goal is to spread out LFB processing 🧚
3.1. Assumptions
- The FEs involved in an inter-FE LFB belong to the same Network Element (NE). They also sit inside a single administrative private network that's in close proximity, so they're basically neighbours 🏡
- The FEs are already interconnected using Ethernet. The doc focuses on Ethernet because it's the go-to choice for FE interconnection 💜 Other higher transports (like UDP over IP) or lower transports could be defined to carry the data and metadata, but this document doesn't cover those cases 🙈
3.2. Sample Use Cases
To make the problem scope clear, the doc walks through two use cases. In each one, we start with a single FE running all the LFB functionality, then split it across multiple FEs that still hit the same end goals 🎀
3.2.1. Basic IPv4 Router
Figure 1 shows a sample LFB topology for a basic IPv4-forwarding service running inside one FE. To keep things simple, the diagram shows LFB classes as graph nodes instead of multiple LFB class instances ✨
The figure's job is to show how data and metadata flow down or upstream through a graph of LFB instances. So it hides any ports in either direction and just talks about a generic ingress and egress LFB 🦋 It also skips exception and error paths. Reverse Path Filtering, ECMP, multicast handling, and similar stuff are left out too. This is not a complete IPv4-forwarding app, so if you want a fuller example, check out the LFBLibrary document in [RFC6956] 💅
The output of the ingress LFB(s) going into the IPv4 Validator LFB includes the IPv4 packets. Depending on the implementation, it can also carry a bunch of ingress metadata, like offsets into the different headers, any classification metadata, the physical and virtual ports encountered, tunneling info, and so on. All of that gets lumped together as "ingress metadata" 🫶
Once the IPv4 validator vets the packet (for example, checking that the TTL hasn't expired), it passes the packet and the inherited metadata into the IPv4 unicast LPM (Longest-Prefix-Matching) LFB 🔥
+----+
| |
IPv4 pkt | | IPv4 pkt +-----+ +---+
+------------->| +------------->| | | |
| + ingress | | + ingress |IPv4 | IPv4 pkt | |
| metadata | | metadata |Ucast+------------>| +--+
| +----+ |LPM | + ingress | | |
+-+-+ IPv4 +-----+ + NHinfo +---+ |
| | Validator metadata IPv4 |
| | LFB NextHop|
| | LFB |
| | |
| | IPv4 pkt |
| | + {ingress |
+---+ + NHdetails}
Ingress metadata |
LFB +--------+ |
| Egress | |
<--+ |<-----------------+
| LFB |
+--------+
Figure 1: Basic IPv4 Packet Service LFB TopologyThe IPv4 unicast LPM LFB runs an LPM lookup on the IPv4 FIB, using the destination IP address as the search key. The result is usually a next-hop selector, and that gets passed downstream as metadata 💖
The NextHop LFB receives the IPv4 packet along with the associated next-hop (NH) information metadata. It consumes that NH metadata, derives a table index from it, and uses that index to look up the next-hop table and find the right egress information 🧚 The lookup result gets used to build the next-hop details for the egress side. That can include source and destination info (in this doc's case, which Media Access Control (MAC) addresses to use) as well as egress ports. (Note: This is also typically where the forwarding TTL decrement and the IP checksum recalculation happen 🙈)
The details of the egress LFB are out of scope here. Just know that somewhere in or beyond the Egress LFB, the IPv4 packet gets sent out a port, whether that's Ethernet, virtual, or physical 🌈
3.2.1.1. Distributing the Basic IPv4 Router 🦋
okay so the router LFB topology from Figure 1 can get split across two FEs, like two ASICs (Application-Specific Integrated Circuits) working together 💅. Figure 2 shows exactly that split, with the cut happening after the IPv4 unicast LPM LFB ✨
FE1
+-------------------------------------------------------------+
| +----+ |
| +----------+ | | |
| | Ingress | IPv4 pkt | | IPv4 pkt +-----+ |
| | LFB +-------------->| +------------->| | |
| | | + ingress | | + ingress |IPv4 | |
| +----------+ metadata | | metadata |Ucast| |
| ^ +----+ |LPM | |
| | IPv4 +--+--+ |
| | Validator | |
| LFB | |
+---------------------------------------------------|---------+
|
IPv4 packet +
{ingress + NHinfo}
metadata
FE2 |
+---------------------------------------------------|---------+
| V |
| +--------+ +--------+ |
| | Egress | IPv4 packet | IPv4 | |
| <-----+ LFB |<----------------------+NextHop | |
| | |{ingress + NHdetails} | LFB | |
| +--------+ metadata +--------+ |
+-------------------------------------------------------------+🌸 Figure 2: Split IPv4 Packet Service LFB Topology 🌸
Some proprietary interconnections (for example, Broadcom HiGig over XAUI [brcm-higig]) are known to exist. They carry both the IPv4 packet and the related metadata between the IPv4 Unicast LFB and the IPv4NextHop LFB across the two FEs, so it's not just a theory, it's already happening 👀
This document defines the inter-FE LFB, which is a standard mechanism for encapsulating, generating, receiving, and decapsulating packets and associated metadata FEs over Ethernet. It's giving standardised glue, bestie 🫶
3.2.2. Arbitrary Network Function 🧚
okay now we zoom out 🔭 This section shows an example of an arbitrary Network Function that's more coarsely grained in terms of functionality. Each Network Function may constitute more than one LFB, so one function can be a whole bundle of LFBs, lowkey iconic 💜
FE1
+-------------------------------------------------------------+
| +----+ |
| +----------+ | | |
| | Network | pkt |NF2 | pkt +-----+ |
| | Function +-------------->| +------------->| | |
| | 1 | + NF1 | | + NF1/2 |NF3 | |
| +----------+ metadata | | metadata | | |
| ^ +----+ | | |
| | +--+--+ |
| | | |
| | |
+---------------------------------------------------|---------+
V🌸 Figure 3: A Network Function Service Chain within One FE 🌸
The setup in Figure 3 is typical of most packet processing boxes. You've got functions like deep packet inspection (DPI), NAT, Routing, etc., all hooked together in a topology so they can deliver a packet processing service to flows. It's the classic main character chain 🎀
3.2.2.1. Distributing the Arbitrary Network Function 💖
the setup in Figure 3 can be split across three FEs instead, as shown in Figure 4 🍓 This could be motivated by scale-out reasons, or because different vendors provide different functionality that gets plugged in to provide such functionality. Either way, the end result is the same packet service delivered to the different flows passing through. no notes, it just works 💅
FE1 FE2
+----------+ +----+ FE3
| Network | pkt |NF2 | pkt +-----+
| Function +-------------->| +------------->| |
| 1 | + NF1 | | + NF1/2 |NF3 |
+----------+ metadata | | metadata | |
^ +----+ | |
| +--+--+
|
V🌸 Figure 4: A Network Function Service Chain Distributed across Multiple FEs 🌸
4. Inter-FE LFB Overview ✨
okay this is where we address the inter-FE connectivity requirements, by defining the inter-FE LFB class 🦋 Using a standard LFB class definition implies no change to the basic ForCES architecture in the form of the core LFBs (FE Protocol or Object LFBs). Bestie, this design choice was made after considering an alternative approach. That alternative would have required changes to both the FE Object capabilities (SupportedLFBs) and the LFBTopology component, so they could describe the inter-FE connectivity capabilities as well as the runtime topology of the LFB instances. Way too much drama, so we skipped it 🙈
4.1. Inserting the Inter-FE LFB ne 15
The distributed LFB topology described in Figure 2 is re-illustrated in Figure 5, to show where the inter-FE LFB would fit in 🌈
As you can see in Figure 5, the same details passed between the IPv4 unicast LPM LFB and the IPv4 NH LFB are passed to the egress side of the inter-FE LFB. This information is illustrated as multiplicity of inputs into the egress inter-FE LFB instance. Each input represents a unique set of selection information 🔥
FE1
+-------------------------------------------------------------+
| +----------+ +----+ |
| | Ingress | IPv4 pkt | | IPv4 pkt +-----+ |
| | LFB +-------------->| +------------->| | |
| | | + ingress | | + ingress |IPv4 | |
| +----------+ metadata | | metadata |Ucast| |
| ^ +----+ |LPM | |
| | IPv4 +--+--+ |
| | Validator | |
| | LFB | |
| | IPv4 pkt + metadata |
| | {ingress + NHinfo} |
| | | |
| | +..--+..+ |
| | |..| | | |
| +-V--V-V--V-+ |
| | Egress | |
| | Inter-FE | |
| | LFB | |
| +------+----+ |
+---------------------------------------------------|---------+
|
Ethernet Frame with: |
IPv4 packet data and metadata
{ingress + NHinfo + Inter-FE info}
FE2 |
+---------------------------------------------------|---------+
| +..+.+..+ |
| |..|.|..| |
| +-V--V-V--V-+ |
| | Ingress | |
| | Inter-FE | |
| | LFB | |
| +----+------+ |
| | |
| IPv4 pkt + metadata |
| {ingress + NHinfo} |
| | |
| +--------+ +----V---+ |
| | Egress | IPv4 packet | IPv4 | |
| <-----+ LFB |<----------------------+NextHop | |
| | |{ingress + NHdetails} | LFB | |
| +--------+ metadata +--------+ |
+-------------------------------------------------------------+🌸 Figure 5: Split IPv4-Forwarding Service with Inter-FE LFB 🌸
The egress of the inter-FE LFB uses the received packet and metadata to select details for encapsulation when sending messages towards the selected neighboring FE. These details include what to communicate as the source and destination FEs (abstracted as MAC addresses as described in Section 5.2). On top of that, the original metadata may be passed along with the original IPv4 packet 💅
On the ingress side of the inter-FE LFB, the received packet and its associated metadata are used to decide the packet graph continuation. This includes which of the original metadata to keep and which next LFB class instance to continue processing on. In Figure 5, an IPv4NextHop LFB instance is selected and the appropriate metadata is passed to it 🧚
The ingress side of the inter-FE LFB consumes some of the information passed, then passes the IPv4 packet along with the ingress and NHinfo metadata to the IPv4NextHop LFB, just like was done earlier in both Figures 1 and 2 🦋
5. Inter-FE Ethernet Connectivity 🌸
Section 5.1 describes some of the issues related to using Ethernet as the transport, and how we mitigate them 🫶
Section 5.2 defines a payload format that is to be used over Ethernet. An existing implementation of this specification that runs on top of Linux Traffic Control [linux-tc] is described in [tc-ife] 👑
5.1. Inter-FE Ethernet Connectivity Issues 🔥
There are several issues that may occur due to using direct Ethernet encapsulation, and they need consideration 👀
5.1.1. MTU Consideration 💀
Because we are adding data to existing Ethernet frames, MTU issues may arise. Here's what we recommend 🍓
- Using large MTUs when possible (example with jumbo frames).
- Limiting the amount of metadata that could be transmitted. Our definition allows for filtering of select metadata to be encapsulated in the frame, as described in Section 6. We recommend sizing the egress port MTU so as to allow space for the maximum size of the metadata total size to allow between FEs. In such a setup, the port is configured to "lie" to the upper layers by claiming to have a lower MTU than it is capable of 🙃 Setting the MTU can be achieved by ForCES control of the port LFB (or some other configuration. In essence, the control plane, when explicitly making a decision for the MTU settings of the egress port, is implicitly deciding how much metadata will be allowed 🧠 Caution needs to be exercised on how low the resulting reported link MTU could be: for IPv4 packets, the minimum size is 64 octets [RFC791], and for IPv6 the minimum size is 1280 octets [RFC2460] ⚠️
5.1.2. Quality-of-Service Considerations
A raw packet arriving at the inter-FE LFB (from upstream LFB class instances) may have Class-of-Service (CoS) metadata indicating how it should be treated from a Quality-of-Service perspective.
The resulting Ethernet frame will be eventually (preferentially) treated by a downstream LFB (typically a port LFB instance) and their CoS marks will be honored in terms of priority. In other words, the presence of the inter-FE LFB does not change the CoS semantics.
5.1.3. Congestion Considerations
Most of the traffic passing through FEs that utilize the inter-FE LFB is expected to be IP based, which is generally assumed to be congestion controlled [UDP-GUIDE]. For example, if congestion causes a TCP packet annotated with additional ForCES metadata to be dropped between FEs, the sending TCP can be expected to react in the same fashion as if that packet had been dropped at a different point on its path where ForCES is not involved. For this reason, additional inter-FE congestion-control mechanisms are not specified.
However, the increased packet size due to the addition of ForCES metadata is likely to require additional bandwidth on inter-FE links in comparison to what would be required to carry the same traffic without ForCES metadata. Therefore, traffic engineering SHOULD be done when deploying inter-FE encapsulation.
Furthermore, the inter-FE LFB MUST only be deployed within a single network (with a single network operator) or networks of an adjacent set of cooperating network operators where traffic is managed to avoid congestion. These are Controlled Environments, as defined by Section 3.6 of [UDP-GUIDE]. Additional measures SHOULD be imposed to restrict the impact of inter-FE-encapsulated traffic on other traffic; for example:
o rate-limiting all inter-FE LFB traffic at an upstream LFB
o managing circuit breaking [circuit-b] o Isolating the inter-FE traffic either via dedicated interfaces or VLANs
5.2. Inter-FE Ethernet Encapsulation
The Ethernet wire encapsulation is illustrated in Figure 6. The process that leads to this encapsulation is described in Section 6. The resulting frame is 32-bit aligned.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address | Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inter-FE ethertype | Metadata length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV encoded Metadata ~~~..............~~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV encoded Metadata ~~~..............~~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original packet data ~~................~~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Packet Format Definition
The Ethernet header (illustrated in Figure 6) has the following semantics:
o The Destination MAC Address is used to identify the Destination FEID by the CE policy (as described in Section 6).
o The Source MAC Address is used to identify the Source FEID by the CE policy (as described in Section 6).
o The ethertype is used to identify the frame as inter-FE LFB type. Ethertype ED3E (base 16) is to be used.
o The 16-bit metadata length is used to describe the total encoded metadata length (including the 16 bits used to encode the metadata length).
o One or more 16-bit TLV-encoded metadatum follows the Metadata length field. The TLV type identifies the metadata ID. ForCES metadata IDs that have been registered with IANA will be used.
All TLVs will be 32-bit-aligned. We recognize that using a 16-bit TLV restricts the metadata ID to 16 bits instead of a ForCES- defined component ID space of 32 bits if an Index-Length-Value (ILV) is used. However, at the time of publication, we believe this is sufficient to carry all the information we need; the TLV approach has been selected because it saves us 4 bytes per metadatum transferred as compared to the ILV approach.
o The original packet data payload is appended at the end of the metadata as shown.
- Detailed Description of the Ethernet Inter-FE LFB
The Ethernet inter-FE LFB has two LFB input port groups and three LFB output ports as shown in Figure 7.
The inter-FE LFB defines two components used in aiding processing described in Section 6.1.
+-----------------+ Inter-FE LFB | | Encapsulated | OUT2+--> Decapsulated Packet -------------->|IngressInGroup | + metadata Ethernet Frame | |
raw Packet + | OUT1+--> Encapsulated Ethernet -------------->|EgressInGroup | Frame Metadata | |
| EXCEPTIONOUT +--> ExceptionID, packet | |
|---|---|
| + metadata |
+-----------------+
Figure 7: Inter-FE LFB
6.1. Data Handling
The inter-FE LFB (instance) can be positioned at the egress of a source FE. Figure 5 illustrates an example source FE in the form of FE1. In such a case, an inter-FE LFB instance receives, via port group EgressInGroup, a raw packet and associated metadata from the preceding LFB instances. The input information is used to produce a selection of how to generate and encapsulate the new frame. The set of all selections is stored in the LFB component IFETable described further below. The processed encapsulated Ethernet frame will go out on OUT1 to a downstream LFB instance when processing succeeds or to the EXCEPTIONOUT port in the case of failure.
The inter-FE LFB (instance) can be positioned at the ingress of a receiving FE. Figure 5 illustrates an example destination FE in the form of FE1. In such a case, an inter-FE LFB receives, via an LFB port in the IngressInGroup, an encapsulated Ethernet frame. Successful processing of the packet will result in a raw packet with associated metadata IDs going downstream to an LFB connected on OUT2. On failure, the data is sent out EXCEPTIONOUT.
6.1.1. Egress Processing
The egress inter-FE LFB receives packet data and any accompanying metadatum at an LFB port of the LFB instance's input port group labeled EgressInGroup.
The LFB implementation may use the incoming LFB port (within the LFB port group EgressInGroup) to map to a table index used to look up the IFETable table.
If the lookup is successful, a matched table row that has the IFEInfo details is retrieved with the tuple (optional IFETYPE, optional StatId, Destination MAC address (DSTFE), Source MAC address (SRCFE), and optional metafilters). The metafilters lists define a whitelist of which metadatum are to be passed to the neighboring FE. The inter-FE LFB will perform the following actions using the resulting tuple:
o Increment statistics for packet and byte count observed at the corresponding IFEStats entry.
o When the MetaFilterList is present, walk each received metadatum and apply it against the MetaFilterList. If no legitimate metadata is found that needs to be passed downstream, then the processing stops and the packet and metadata are sent out the EXCEPTIONOUT port with the exceptionID of EncapTableLookupFailed [RFC6956].
o Check that the additional overhead of the Ethernet header and encapsulated metadata will not exceed MTU. If it does, increment the error-packet-count statistics and send the packet and metadata out the EXCEPTIONOUT port with the exceptionID of FragRequired [RFC6956].
o Create the Ethernet header.
o Set the Destination MAC address of the Ethernet header with the value found in the DSTFE field.
o Set the Source MAC address of the Ethernet header with the value found in the SRCFE field.
o If the optional IFETYPE is present, set the ethertype to the value found in IFETYPE. If IFETYPE is absent, then the standard inter- FE LFB ethertype ED3E (base 16) is used.
o Encapsulate each allowed metadatum in a TLV. Use the metaID as the "type" field in the TLV header. The TLV should be aligned to 32 bits. This means you may need to add a padding of zeroes at the end of the TLV to ensure alignment.
o Update the metadata length to the sum of each TLV's space plus 2 bytes (a 16-bit space for the Metadata length field).
The resulting packet is sent to the next LFB instance connected to the OUT1 LFB-port, typically a port LFB.
In the case of a failed lookup, the original packet and associated metadata is sent out the EXCEPTIONOUT port with the exceptionID of EncapTableLookupFailed [RFC6956]. Note that the EXCEPTIONOUT LFB port is merely an abstraction and implementation may in fact drop packets as described above.
6.1.2. Ingress Processing
An ingressing inter-FE LFB packet is recognized by inspecting the ethertype, and optionally the destination and source MAC addresses. A matching packet is mapped to an LFB instance port in the IngressInGroup. The IFETable table row entry matching the LFB instance port may have optionally programmed metadata filters. In such a case, the ingress processing should use the metadata filters as a whitelist of what metadatum is to be allowed.
o Increment statistics for packet and byte count observed.
o Look at the metadata length field and walk the packet data, extracting the metadata values from the TLVs. For each metadatum extracted, in the presence of metadata filters, the metaID is compared against the relevant IFETable row metafilter list. If the metadatum is recognized and allowed by the filter, the corresponding implementation Metadatum field is set. If an unknown metadatum ID is encountered or if the metaID is not in the allowed filter list, then the implementation is expected to ignore it, increment the packet error statistic, and proceed processing other metadatum.
o Upon completion of processing all the metadata, the inter-FE LFB instance resets the data point to the original payload (i.e., skips the IFE header information). At this point, the original packet that was passed to the egress inter-FE LFB at the source FE is reconstructed. This data is then passed along with the reconstructed metadata downstream to the next LFB instance in the graph.
In the case of a processing failure of either ingress or egress positioning of the LFB, the packet and metadata are sent out the EXCEPTIONOUT LFB port with the appropriate error ID. Note that the EXCEPTIONOUT LFB port is merely an abstraction and implementation may in fact drop packets as described above.
6.2. Components ✨
okay so there are two LFB components the CE gets to poke at, and you should totally peep Figure 8 for the full tea 🫶
First up is the one the CE fills in: an array called the "IFETable" table 📋. Each row is an IFEInfo structure, and it's giving everything: the optional IFETYPE, the optionally present StatId, the Destination MAC address (DSTFE), the Source MAC address (SRCFE), and an optionally present array of allowed metaIDs (MetaFilterList). main character energy 👑
The second one (ID 2) is populated by the FE and read by the CE 💜. It's an indexed array called the "IFEStats" table 📊, and each IFEStats row carries its stats info in the bstats structure.
Now, the StatId relationship between the IFETable table and the IFEStats table is lowkey the most iconic part 🙈 There are three ways an implementation can link them:
- It can map an IFETable row to an IFEStats row using the StatId entry in the matching IFETable row. If it goes this way, the IFETable StatId must be present.
- Another implementation can map an IFETable row to an IFEStats row at provisioning time 🧚
- Yet another can skip the IFETable row StatId and just use the IFETable row index as the IFEStats index 🦋
Since implementations can pick any of these routes, the StatId component is optional. no cap, that's the whole reason 💅
6.3. Inter-FE LFB XML Model
ok the XML model is next, and it's a whole vibe 🌈 Here it is, verbatim:
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
provides="IFE">
<frameDefs>
<frameDef>
<name>PacketAny</name>
<synopsis>Arbitrary Packet</synopsis>
</frameDef>
<frameDef>
<name>InterFEFrame</name>
<synopsis>
Ethernet frame with encapsulated IFE information
</synopsis>
</frameDef>
</frameDefs>
<dataTypeDefs>
<dataTypeDef>
<name>bstats</name>
<synopsis>Basic stats</synopsis>
<struct>
<component componentID="1">
<name>bytes</name>
<synopsis>The total number of bytes seen</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name>packets</name>
<synopsis>The total number of packets seen</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>errors</name>
<synopsis>The total number of packets with errors</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IFEInfo</name>
<synopsis>Describing IFE table row Information</synopsis>
<struct>
<component componentID="1">
<name>IFETYPE</name>
<synopsis>
The ethertype to be used for outgoing IFE frame
</synopsis>
<optional/>
<typeRef>uint16</typeRef>
</component>
<component componentID="2">
<name>StatId</name>
<synopsis>
The Index into the stats table
</synopsis>
<optional/>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>DSTFE</name>
<synopsis>
The destination MAC address of the destination FE
</synopsis>
<typeRef>byte[6]</typeRef>
</component>
<component componentID="4">
<name>SRCFE</name>
<synopsis>
The source MAC address used for the source FE
</synopsis>
<typeRef>byte[6]</typeRef>
</component>
<component componentID="5">
<name>MetaFilterList</name>
<synopsis>
The allowed metadata filter table
</synopsis>
<optional/>
<array type="variable-size">
<typeRef>uint32</typeRef>
</array>
</component>
</struct>
</dataTypeDef>
</dataTypeDefs>
<LFBClassDefs>
<LFBClassDef LFBClassID="18">
<name>IFE</name>
<synopsis>
This LFB describes IFE connectivity parameterization
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort group="true">
<name>EgressInGroup</name>
<synopsis>
The input port group of the egress side.
It expects any type of Ethernet frame.
</synopsis>
<expectation>
<frameExpected>
<ref>PacketAny</ref>
</frameExpected>
</expectation>
</inputPort>
<inputPort group="true">
<name>IngressInGroup</name>
<synopsis>
The input port group of the ingress side.
It expects an interFE-encapsulated Ethernet frame.
</synopsis>
<expectation>
<frameExpected>
<ref>InterFEFrame</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort>
<name>OUT1</name>
<synopsis>
The output port of the egress side
</synopsis>
<product>
<frameProduced>
<ref>InterFEFrame</ref>
</frameProduced>
</product>
</outputPort>
<outputPort>
<name>OUT2</name>
<synopsis>
The output port of the Ingress side
</synopsis>
<product>
<frameProduced>
<ref>PacketAny</ref>
</frameProduced>
</product>
</outputPort>
<outputPort>
<name>EXCEPTIONOUT</name>
<synopsis>
The exception handling path
</synopsis>
<product>
<frameProduced>
<ref>PacketAny</ref>
</frameProduced>
<metadataProduced>
<ref>ExceptionID</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1" access="read-write">
<name>IFETable</name>
<synopsis>
The table of all inter-FE relations
</synopsis>
<array type="variable-size">
<typeRef>IFEInfo</typeRef>
</array>
</component>
<component componentID="2" access="read-only">
<name>IFEStats</name>
<synopsis>
The stats corresponding to the IFETable table
</synopsis>
<typeRef>bstats</typeRef>
</component>
</components>
</LFBClassDef>
</LFBClassDefs>
</LFBLibrary>Figure 8: Inter-FE LFB XML
7. IANA Considerations
okay IANA time 📝 They've registered the following LFB class name in the "Logical Functional Block (LFB) Class Names and Class Identifiers" subregistry of the "Forwarding and Control Element Separation (ForCES)" registry, which lives at <https://www.iana.org/assignments/forces> 🌸
+------------+--------+---------+-----------------------+-----------+
| LFB Class | LFB | LFB | Description | Reference |
| Identifier | Class | Version | | |
| | Name | | | |
+------------+--------+---------+-----------------------+-----------+
| 18 | IFE | 1.0 | An IFE LFB to | This |
| | | | standardize inter-FE | document |
| | | | LFB for ForCES | |
| | | | Network Elements | |
+------------+--------+---------+-----------------------+-----------+Logical Functional Block (LFB) Class Names and Class Identifiers
8. IEEE Assignment Considerations
this one's a quick hit ✨ This memo includes a request for a new Ethernet protocol type, as described in Section 5.2 🎀
9. Security Considerations
okay bestie, this section is serious business, so put your listening ears on 🙈🔥
The FEs involved in the inter-FE LFB belong to the same NE and sit within the scope of a single administrative Ethernet LAN private network. Trust and policy already exist in the control plane and in how it's treated in the datapath, but an inter-FE LFB implementation SHOULD support security services provided by Media Access Control Security (MACsec) [ieee8021ae]. MACsec isn't widely deployed in traditional packet processing hardware yet 😭 although it is present in newer versions of the Linux kernel, which will be widely deployed [linux-macsec]. Over time, we expect that most FEs will be able to support MACsec 🌈
MACsec gives you security services like a message authentication service and an optional confidentiality service. You can set these up manually, or automatically using the MACsec Key Agreement (MKA) over the IEEE 802.1x [ieee8021x] Extensible Authentication Protocol (EAP) framework. FE implementations are expected to start with shared keys configured from the control plane, then progress to automated key management 💖
Here are the MACsec security mechanisms that need to be in place for the inter-FE LFB 👑
- Security mechanisms are NE-wide for all FEs. Once security is turned on, depending on the chosen security level (e.g., Authentication, Confidentiality), it stays in effect for the inter-FE LFB for the entire duration of the session.
- An operator SHOULD configure the same security policies for all participating FEs in the NE cluster. This keeps operations uniform and avoids unnecessary complexity in policy configuration. In other words, the Security Association Keys (SAKs) should be pre-shared. When using MKA, FEs must identify themselves with a shared Connectivity Association Key (CAK) and Connectivity Association Key Name (CKN). EAP-TLS SHOULD be used as the EAP method.
- An operator SHOULD configure the strict validation mode, i.e., all non-protected, invalid, or non-verifiable frames MUST be dropped.
It should be noted that given the above choices, if an FE is compromised, an entity running on the FE would be able to fake inter-FE or modify its content, causing bad outcomes. This is seriously a red flag 🚩💀
10. References
10.1. Normative References
okay bestie, here's the must-read list 📚🎀 these are the docs the spec leans on, so they're not optional 💅
[ieee8021ae]IEEE, "IEEE Standard for Local and metropolitan area networks Media Access Control (MAC) Security", IEEE 802.1AE-2006, DOI 10.1109/IEEESTD.2006.245590,<http://ieeexplore.ieee.org/document/1678345/>. 🔐[ieee8021x]IEEE, "IEEE Standard for Local and metropolitan area networks - Port-Based Network Access Control.", IEEE 802.1X-2010, DOI 10.1109/IEEESTD.2010.5409813,<http://ieeexplore.ieee.org/document/5409813/>. 🚪[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,<http://www.rfc-editor.org/info/rfc2119>. 🔑[RFC5810]Doria, A., Ed., Hadi Salim, J., Ed., Haas, R., Ed., Khosravi, H., Ed., Wang, W., Ed., Dong, L., Gopal, R., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Protocol Specification", RFC 5810, DOI 10.17487/RFC5810, March 2010,<http://www.rfc-editor.org/info/rfc5810>. 🧩[RFC5811]Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol", RFC 5811, DOI 10.17487/RFC5811, March 2010,<http://www.rfc-editor.org/info/rfc5811>. 🚚[RFC5812]Halpern, J. and J. Hadi Salim, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", RFC 5812, DOI 10.17487/RFC5812, March 2010,<http://www.rfc-editor.org/info/rfc5812>. 🗺️[RFC7391]Hadi Salim, J., "Forwarding and Control Element Separation (ForCES) Protocol Extensions", RFC 7391, DOI 10.17487/RFC7391, October 2014,<http://www.rfc-editor.org/info/rfc7391>. ✨[RFC7408]Haleplidis, E., "Forwarding and Control Element Separation (ForCES) Model Extension", RFC 7408, DOI 10.17487/RFC7408, November 2014,<http://www.rfc-editor.org/info/rfc7408>. 💜
10.2. Informative References
and these are the extra reads, the vibes-and-background pile 🌸 nice to know, not strictly required
[brcm-higig]Broadcom, "HiGig",<http://www.broadcom.com/products/ethernet-communication-and-switching/switching/bcm56720>. 🦋[circuit-b]Fairhurst, G., "Network Transport Circuit Breakers", Work in Progress, draft-ietf-tsvwg-circuit-breaker-15, April 2016. ⚡[linux-macsec]Dubroca, S., "MACsec: Encryption for the wired LAN", Netdev 11, Feb 2016. 🔒[linux-tc]Hadi Salim, J., "Linux Traffic Control Classifier-Action Subsystem Architecture", Netdev 01, Feb 2015. 🧁[RFC791]Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981,<http://www.rfc-editor.org/info/rfc791>. 👑[RFC2460]Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998,<http://www.rfc-editor.org/info/rfc2460>. 🌈[RFC3746]Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, DOI 10.17487/RFC3746, April 2004,<http://www.rfc-editor.org/info/rfc3746>. 🖼️[RFC6956]Wang, W., Haleplidis, E., Ogawa, K., Li, C., and J. Halpern, "Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library", RFC 6956, DOI 10.17487/RFC6956, June 2013,<http://www.rfc-editor.org/info/rfc6956>. 📚[tc-ife]Hadi Salim, J. and D. Joachimpillai, "Distributing Linux Traffic Control Classifier-Action Subsystem", Netdev 01, Feb 2015. 🌷[UDP-GUIDE]Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage Guidelines", Work in Progress, draft-ietf-tsvwg-rfc5405bis-19, October 2016. 🫶
Acknowledgements
big thank-you train time 🚂💖 the authors shout out Joel Halpern and Dave Hood for the stimulating discussions, and Evangelos Haleplidis for shepherding and helping make the doc better ✨ Alia Atlas was the AD sponsor and absolutely went in on critiquing it 👑 Joel Halpern and Sue Hares get props as Routing Area reviewers for shaping the content 🌸 David Black put in serious effort to make sure the congestion-control stuff is sane 🙏 Russ Housley did the Gen-ART review, Joe Touch did the TSV area review, and Shucheng LIU (Will) did the OPS review 🎀 Suresh Krishnan helped bring clarity during the IESG review 🧚 and the authors are seriously grateful to Stephen Farrell for all the work fixing the security section 🔐💅
Authors' Addresses
here's who to find if you wanna slide into the authors' DMs 💌
Damascane M. Joachimpillai
Verizon
60 Sylvan Rd
Waltham, MA 02451
United States of America
Email: damascene.joachimpillai@verizon.com
Jamal Hadi Salim
Mojatatu Networks
Suite 200, 15 Fitzgerald Rd.
Ottawa, Ontario K2H 9G1
Canada
Email: hadi@mojatatu.com📦 where this page comes from
- ietf: rfc8013 2017-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms