RFC 6956
Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library
RFC 6956 (Part 1 of 22) 💖
Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library 🎀
Okay bestie, this one is the basic LFB library for ForCES 🦋 and it's from June 2013. It's on the Standards Track, with ISSN 2070-1721. The authors are W. Wang (Zhejiang Gongshang University), E. Haleplidis (University of Patras), K. Ogawa (NTT Corporation), C. Li (Hangzhou DPtech), and J. Halpern (Ericsson). The title block doesn't list anything it obsoletes or updates, so it's standing on its own 💅.
Abstract ✨
So the big idea: this doc defines the basic classes of Logical Function Blocks (LFBs) used in Forwarding and Control Element Separation (ForCES) 🫶. The classes are built off the ForCES Forwarding Element (FE) model and the ForCES protocol specs, and they're scoped to cover typical router functions, so they count as the basic LFB library for ForCES 👑. The library includes the LFB descriptions and the XML definitions too 🧚.
Status of This Memo 🌸
This is an Internet Standards Track document 🔥.
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 💖. If you want more on Internet Standards, check Section 2 of RFC 5741 🦋.
For the current status, errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6956 ✨.
Copyright Notice 🌈
Copyright (c) 2013 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 in effect on the date of publication. Please actually read these, because they spell out your rights and restrictions for this doc 🙈. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🍓.
Table of Contents 📖
1. Introduction ....................................................3
2. Terminology and Conventions .....................................4
2.1. Requirements Language ......................................4
2.2. Definitions ................................................4
3. Overview ........................................................6
3.1. Scope of the Library .......................................6
3.2. Overview of LFB Classes in the Library .....................8
3.2.1. LFB Design Choices ..................................8
3.2.2. LFB Class Groupings .................................9
3.2.3. Sample LFB Class Application .......................10
3.3. Document Structure ........................................11
4. Base Types .....................................................11
4.1. Data Types ................................................13
4.1.1. Atomic .............................................13
4.1.2. Compound Struct ....................................13
4.1.3. Compound Array .....................................14
4.2. Frame Types ...............................................14
4.3. Metadata Types ............................................15
4.4. XML for Base Type Library .................................16
5. LFB Class Descriptions .........................................41
5.1. Ethernet-Processing LFBs ..................................42
5.1.1. EtherPHYCop ........................................42
5.1.2. EtherMACIn .........................................44
5.1.3. EtherClassifier ....................................46
5.1.4. EtherEncap .........................................48
5.1.5. EtherMACOut ........................................50
5.2. IP Packet Validation LFBs .................................52
5.2.1. IPv4Validator ......................................52
5.2.2. IPv6Validator ......................................54
5.3. IP Forwarding LFBs ........................................55
5.3.1. IPv4UcastLPM .......................................56
5.3.2. IPv4NextHop ........................................58
5.3.3. IPv6UcastLPM .......................................60
5.3.4. IPv6NextHop ........................................62
5.4. Redirect LFBs .............................................64
5.4.1. RedirectIn .........................................64
5.4.2. RedirectOut ........................................65
5.5. General Purpose LFBs ......................................66
5.5.1. BasicMetadataDispatch ..............................66
5.5.2. GenericScheduler ...................................68
6. XML for LFB Library ............................................69
7. LFB Class Use Cases ............................................97
7.1. IPv4 Forwarding ...........................................98
7.2. ARP Processing ...........................................101
8. IANA Considerations ...........................................102
8.1. LFB Class Names and LFB Class Identifiers ................103
8.2. Metadata ID ..............................................105
8.3. Exception ID .............................................106
8.4. Validate Error ID ........................................107
9. Security Considerations .......................................108
10. References ...................................................108
10.1. Normative References ....................................108
10.2. Informative References ..................................108
Appendix A. Acknowledgements ....................................110
Appendix B. Contributors ........................................1101. Introduction ✨
Okay so, [RFC3746] specifies the Forwarding and Control Element Separation (ForCES) framework 🦋. In that framework, Control Elements (CEs) configure and manage one or more separate Forwarding Elements (FEs) inside a Network Element (NE), and they do it using a ForCES protocol. [RFC5810] is the one that specifies the ForCES protocol 💖. [RFC5812] specifies the Forwarding Element (FE) model, where FE resources get described as classes of Logical Function Blocks (LFBs) 🌸. The FE model defines the structure and abstract semantics of LFBs, and it hands over an XML schema for defining them 🧚.
This document follows the FE model [RFC5812] and gets into the detailed definitions of LFB classes, including detailed XML definitions 🎀. Together these make up a base LFB library for ForCES 👑. The LFBs in this base library are expected to get combined into an LFB topology for a typical router doing IP forwarding 🔥. Important bit: an LFB is an abstraction of functions, not implementation details 🙈. The whole point of the LFB definitions is to represent functions so that separate CEs and FEs can interoperate 🫶.
More LFB classes with more functions may be developed in the future and documented by the IETF 🌈. Vendors may also develop proprietary LFB classes, as described in the FE model [RFC5812] 💅.
2. Terminology and Conventions 📚
2.1. Requirements Language 💜
Here's the key-word situation. 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 [RFC2119] 🍓. Those are the capital-letter ones, and they carry real weight, so don't treat them like casual vibes 💀.
2.2. Definitions
okay bestie, this is the glossary, and it's giving "everything you need, in one place" 💅✨ The ForCES protocol in [RFC5810] and the ForCES FE model in [RFC5812] define the terms, and this section repeats them so you don't have to flip back and forth 🎀
Control Element (CE) - A logical entity that runs the ForCES protocol and uses it to tell one or more FEs how to process packets. CEs handle things like control and signaling protocols 🧠
Forwarding Element (FE) - A logical entity that runs the ForCES protocol. FEs use the underlying hardware to do per-packet processing and handling, as directed and controlled by one or more CEs over ForCES 🚀
ForCES Network Element (NE) - An entity made of one or more CEs and one or more FEs. From the outside, the NE looks like a single point of management 🫶 It also usually hides its internal organization from anything outside it, which is so main character of it 🦋
Logical Function Block (LFB) - The basic building block that the ForCES protocol operates on. An LFB is a well-defined, logically separable functional block that lives in an FE and is controlled by the CE through ForCES. It can sit on the FE's data path and process packets, or it can be purely a control or configuration entity that the CE operates on. Also, the LFB is a functionally accurate abstraction of what the FE can do, but it is not a hardware-accurate picture of how the FE is built 🌸
FE Model - The FE model describes the logical processing functions of an FE, as defined in the ForCES FE model document [RFC5812]. The FE model in this document has three parts: the modeling of individual LFBs (the LFB model), the logical connections between LFBs (the LFB topology), and the FE-level attributes, including FE capabilities. It's the foundation for defining the information elements that the CE and FE swap in the ForCES protocol [RFC5810] 📋
FE Topology - How the multiple FEs inside one NE are connected to each other. This is sometimes called inter-FE topology, which keeps it separate from intra-FE topology (aka LFB topology) 🧩
LFB Class and LFB Instance - LFBs are sorted into LFB classes. An LFB instance represents the existence of an LFB class (or type). An FE can have several instances of the same LFB class (or type). An LFB class is identified by an LFB class ID, and an LFB instance is identified by an LFB instance ID. So when you pair an LFB class ID with an LFB instance ID, you get exactly one LFB existence, no confusion 🔍
LFB Metadata - Metadata is how one LFB passes per-packet state to another. It never goes out over the network. The FE model says how this metadata is identified, produced, and consumed by the LFBs, but it doesn't say how the metadata gets encoded inside an implementation 💭
LFB Component - The operational parameters of LFBs that the CEs need to be able to see are modeled in the FE model as LFB components. These include things like flags, single parameter arguments, complex arguments, and tables, which the CE can read and/or write through the ForCES protocol (see below) 🎀
LFB Topology - How LFB instances are logically connected to each other and placed along the data path within one FE. It's also called intra-FE topology, which keeps it separate from inter-FE topology 🪄
Data Path - The conceptual route that packets take through the forwarding plane inside an FE. More than one data path can exist inside a single FE 🛤️
ForCES Protocol - There can be several protocols in the overall ForCES architecture, but "ForCES protocol" and "protocol" both refer to the Fp reference points in the ForCES framework in [RFC3746]. The protocol does not cover CE-to-CE communication, FE-to-FE communication, or communication between FE and CE managers. Basically, it works in a master-slave mode, where FEs are the slaves and CEs are the masters 👑
Physical Port - A physical media input port or output port of an FE. A physical port is usually given a physical port ID, abbreviated as PHYPortID. This document mainly deals with physical ports that use Ethernet media 🔌
Logical Port - A conceptually virtual port at the data link layer (L2) or the network layer (L3). A logical port is usually given a logical port ID, abbreviated as LogicalPortID. Logical ports can be further sorted into L2 logical ports or L3 logical ports. An L2 logical port can be given an L2 logical port ID, abbreviated as L2PortID. An L3 logical port can be given an L3 logical port ID, abbreviated as L3PortID. MAC-layer VLAN ports count as logical ports, and specifically they count as L2 logical ports 🏷️
LFB Port - The connection points where one LFB can be hooked up to another inside an FE. As [RFC5812] describes, the CE can connect LFBs together by linking an output port of one LFB instance to an input port of another LFB instance. Check out Section 3.2 of [RFC5812] for more details 🔗
Singleton Port - A named input or output port of an LFB. It's referred to by its name. When the context is clear, people just say "singleton" to mean a singleton port 🫧
Group Port - A named collection of input or output ports of an LFB. It's referred to by its name. A group port is made up of several port instances, and each one is referred to by a combination of the name and an index 🧺
LFB Class Library - The LFB class library is a set of LFB classes. These are the most common functions found in most FEs, so they should be defined first by the ForCES Working Group. This document is what defines the LFB class library 📚✨
3. Overview ✨
3.1. Scope of the Library
Bestie, the LFB classes in this document are meant to give you the functions of a typical router 🏠 [RFC1812] says a typical router is expected to do the following:
- Interface to packet networks and implement the functions required by that network. These functions typically include:
- Encapsulating and decapsulating the IP datagrams with the connected network framing (e.g., an Ethernet header and checksum),
- Sending and receiving IP datagrams up to the maximum size supported by that network (this size is the network's Maximum Transmission Unit or MTU),
- Translating the IP destination address into an appropriate network-level address for the connected network (e.g., an Ethernet hardware address), if needed, and
- Responding to network flow control and error indications, if any.
- Conform to specific Internet protocols including the Internet Protocol (IPv4 and/or IPv6), Internet Control Message Protocol (ICMP), and others as necessary 🌐
- Receive and forward Internet datagrams. Important issues in this process are buffer management, congestion control, and fairness 🚚
- Recognize error conditions and generate ICMP error and information messages as required.
- Drop datagrams whose time-to-live fields have reached zero.
- Fragment datagrams when necessary to fit into the MTU of the next link or interface.
- Choose a next-hop destination for each IP datagram, based on the information in its routing database 🧭
- Usually support an interior gateway protocol (IGP) to carry out distributed routing and reachability algorithms with the other routers in the same autonomous system. In addition, some routers will need to support an exterior gateway protocol (EGP) to exchange topological information with other autonomous systems. For all routers, it is essential to provide the ability to manage static routing items 🗺️
- Provide network management and system support facilities, including loading, debugging, status reporting, statistics query, exception reporting, and control 🛠️
The classical IP router using the ForCES framework is a CE that runs some controlling IGP and/or EGP function (or sets up static routes), plus FEs built out of Logical Function Blocks (LFBs) that follow the FE model [RFC5812] spec. The CE follows the ForCES protocol [RFC5810] and the FE model [RFC5812] specifications, and it tells the LFBs on the FE how to treat received and sent packets 💅
Packets in an IP router come in and go out on physical media, usually called "ports". Different physical media encapsulate outgoing frames and decapsulate incoming frames in different ways, and they have different attributes that affect how that happens 🔌 This document only deals with Ethernet physical media. Future documents may cover other types of media 🔮 This document also uses "port" to mean an abstraction that covers both a physical layer (PHY) and a Media Access Control (MAC) layer, as described by LFBs like EtherPHYCop, EtherMACIn, and EtherMACOut 🫧
IP packets coming out of port LFBs go through a validation LFB before they're forwarded to the next LFB. After validation, the packet goes to an LFB that makes the IP forwarding decision. In the IP Forwarding LFBs, a Longest Prefix Match LFB looks up the destination information in a packet and picks a next-hop index for sending it onward. A next-hop LFB uses the next-hop index metadata to apply the right headers to the IP packets and send them out the proper egress 📦 Also, while processing IP packets, this document follows the weak-host model [RFC1122], since that's the most usable model for a packet being processed by a Network Element 🙌
3.2. Overview of LFB Classes in the Library
Getting the functional requirements sorted into the right classes of LFBs is critical 🎯 The goal is a base LFB library that's typical enough to be useful, but also flexible enough to serve many different IP forwarding devices 🧸
3.2.1. LFB Design Choices
A few design principles shaped what the base LFBs look like 🌈
- If a function can be designed as either one LFB or two or more LFBs at the same cost, the choice is to go with two or more LFBs, so implementers get more flexibility 🦋
- An LFB should take advantage of its independence as much as possible and have minimal coupling with other LFBs. The coupling may come from LFB attribute definitions as well as from physical implementations 🧩
- Unless there is a clear difference in functionality, similar packet processing in the base LFB library should not be represented by two or more LFBs at the same time. For instance, it should not be defined with two different LFBs for the same next-hop processing. Otherwise, it may add extra burden on implementations trying to achieve interoperability 🫶
3.2.2. LFB Class Groupings 🎀
okay so bestie, the LFBs get sorted into groups based on the typical router jobs they do 💅 this document defines groups of LFBs for typical router function requirements:
- Ethernet-processing group 🌈 A group of Ethernet-processing LFBs is defined to abstract the packet processing for Ethernet as the port media type. Ethernet is the most popular media type with rich processing features, so Ethernet media processing LFBs were a natural choice. Definitions for processing of other port media types like Packet over SONET (POS) or Asynchronous Transfer Mode (ATM) may be incorporated in the library in future versions of this document or in a separate document. The following LFBs are defined for Ethernet processing:
EtherPHYCop(Section 5.1.1)EtherMACIn(Section 5.1.2)EtherClassifier(Section 5.1.3)EtherEncap(Section 5.1.4)EtherMACOut(Section 5.1.5)
- IP validation group ✨ A group of LFBs is defined for the IP packet validation process. The following LFBs are defined for IP validation processing:
IPv4Validator(Section 5.2.1)IPv6Validator(Section 5.2.2)
- IP forwarding group 🚀 A group of LFBs is defined to abstract the IP forwarding process. The following LFBs are defined for IP forwarding processing:
IPv4UcastLPM(Section 5.3.1)IPv4NextHop(Section 5.3.2)IPv6UcastLPM(Section 5.3.3)IPv6NextHop(Section 5.3.4)
- Redirect group 🦋 A group of LFBs is defined to abstract the process for the redirect operation, i.e., data packet transmission between CE and FEs. The following LFBs are defined for redirect processing:
RedirectIn(Section 5.4.1)RedirectOut(Section 5.4.2)
- General purpose group 🧚 A group of LFBs is defined for abstracting some general purpose packet processing. These processing processes are usually general to many processing locations in an FE LFB topology. The following LFBs are defined for redirect processing:
BasicMetadataDispatch(Section 5.5.1)GenericScheduler(Section 5.5.2)
3.2.3. Sample LFB Class Application 🍓
okay, so Section 7 is where the use cases live, but this section gives you a quick peek at the LFB classes in action so you're not going in blind 👀 Figure 1 shows a simple LFB processing path for Ethernet packets entering from Ethernet physical ports.
+-----+ +------+
| |EtherPHYIn | | from some LFB(s) that
| |<---------------|Ether |<---------- generate Ethernet
| | |MACOut| packets
| | | LFB |
|Ether| +------+
|PHY | +------+
|Cop | | |
|LFB |EtherPHYOut | Ether| to some LFB(s) that
| |--------------->| MACIn|----------> may classify Ethernet
| | | LFB | packets and do IP-layer
| | | | processing
+-----+ +------+ Figure 1: A Simple Sample LFB Use Case
In the figure, Ethernet packets from outer networks enter via the EtherPHYCop LFB (Section 5.1.1), which describes Ethernet copper interface properties (like the link speed) at the physical layer. After physical-layer processing, Ethernet packets are delivered to the EtherMACIn LFB (Section 5.1.2) to describe its MAC-layer processing functions (like locality check). The packets after the EtherMACIn LFB may require further processing to implement various functions (like IP-layer forwarding); therefore, some LFBs may follow the EtherMACIn LFB in topology to describe followed processing functions.
Meanwhile, packets generated by some LFB(s) may need to be submitted to outer physical networks. The process is described in the figure by an EtherMACOut LFB (Section 5.1.5) at the MAC layer and the EtherPHYCop LFB at the physical layer. 🌸
3.3. Document Structure 📚
Base type definitions, including data types, packet frame types, and metadata types, are presented in advance for definitions of various LFB classes. Section 4 ("Base Types") provides a description on the base types used by this LFB library. To enable extensive use of these base types by other LFB class definitions, the base type definitions are provided as a separate library.
Within every group of LFB classes, a set of LFBs are defined for individual function purposes. Section 5 ("LFB Class Descriptions") provides text descriptions on the individual LFBs. Note that for a complete definition of an LFB, a text description and an XML definition are required.
LFB classes are finally defined by XML with specifications and schema defined in the ForCES FE model [RFC5812]. Section 6 ("XML for LFB Library") provides the complete XML definitions of the base LFB classes library.
Section 7 provides several use cases on how some typical router functions can be implemented using the base LFB library defined in this document. 💜
4. Base Types 🧁
The FE model [RFC5812] has specified predefined (built-in) atomic data types: char, uchar, int16, uint16, int32, uint32, int64, uint64, string[N], string, byte[N], boolean, octetstring[N], float16, float32, and float64.
Note that, unlike the Simple Network Management Protocol (SNMP) information model, called the Structure of Management Information (SMI) [RFC2578], the FE model has not defined specific atomic data types for counting purposes. This document also does not define specific counter types. To describe LFB elements for packet statistics, which actually requires counters on packets, an unsigned integer, like an uint32 or an uint64, is adopted. This document states that any LFB element defined for counting purposes is specified to monotonically increase until it reaches a maximum value, when it wraps around and starts increasing again from zero. This document also states that how the unsigned integer element might be maintained to cope with issues like counter discontinuities when a counter wraps or is reset for any reason is an implementation's issue. If a CE is expected to understand more meanings of the counter element than stated above, a private definition on the element between the CE and FE may be required. 🔢
Based on the atomic data types and with the use of type definition elements in the FE model XML schema, new data types, packet frame types, and metadata types can be defined.
To define a base LFB library for typical router functions, a set of base data types, frame types, and metadata types should be defined. This section provides a brief description of the base types and a full XML definition of them as well.
The base type XML definitions are provided with a separate XML library file named "BaseTypeLibrary". Users can refer to this library by the statement:
<load library="BaseTypeLibrary" location="..."/>4.1. Data Types 🎨
Data types defined in the base type library are categorized by the following types: atomic, compound struct, and compound array.
4.1.1. Atomic ⚛️
The following data types are defined as atomic data types and put in the base type library:
Data Type Name Brief Description
-------------- -----------------
IPv4Addr IPv4 address
IPv6Addr IPv6 address
IEEEMAC IEEE MAC address
LANSpeedType LAN speed by value types
DuplexType Duplex types
PortStatusType The possible types of port status, used for
both administrative and operative status
VlanIDType The type of VLAN ID
VlanPriorityType The type of VLAN priority
SchdDisciplineType Scheduling discipline type4.1.2. Compound Struct 🧩
The following compound struct types are defined in the base type library:
Data Type Name Brief Description
-------------- -----------------
EtherDispatchEntryType Entry type for Ethernet dispatch table
VlanInputTableEntryType Entry type for VLAN input table
EncapTableEntryType Entry type for Ethernet encapsulation table
MACInStatsType Statistics type for EtherMACIn LFB
MACOutStatsType Statistics type for EtherMACOut LFB
EtherClassifyStatsType Entry type for statistics table in
EtherClassifier LFB
IPv4PrefixInfoType Entry type for IPv4 prefix table
IPv6PrefixInfoType Entry type for IPv6 prefix table
IPv4NextHopInfoType Entry type for IPv4 next-hop table
IPv6NextHopInfoType Entry type for IPv6 next-hop table
IPv4ValidatorStatsType Statistics type in IPv4validator LFB
IPv6ValidatorStatsType Statistics type in IPv6validator LFB
IPv4UcastLPMStatsType Statistics type in IPv4UcastLPM LFB
IPv6UcastLPMStatsType Statistics type in IPv6UcastLPM LFB
QueueStatsType Entry type for queue depth table
MetadataDispatchType Entry type for metadata dispatch table4.1.3. Compound Array 🪄
Compound array types are mostly created based on compound struct types for LFB table components. The following compound array types are defined in this base type library:
Data Type Name Brief Description
-------------- -----------------
EtherClassifyStatsTableType Type for Ethernet classifier statistics
information table
EtherDispatchTableType Type for Ethernet dispatch table
VlanInputTableType Type for VLAN input table
EncapTableType Type for Ethernet encapsulation table
IPv4PrefixTableType Type for IPv4 prefix table
IPv6PrefixTableType Type for IPv6 prefix table
IPv4NextHopTableType Type for IPv4 next-hop table
IPv6NextHopTableType Type for IPv6 next-hop table
MetadataDispatchTableType Type for Metadata dispatch table
QueueStatsTableType Type for Queue depth table4.2. Frame Types 🎞️
According to the FE model [RFC5812], frame types are used in LFB definitions to define packet frame types that an LFB expects at its input port and that the LFB emits at its output port. The <frameDef> element in the FE model is used to define a new frame type.
The following frame types are defined in the base type library:
Frame Name Brief Description
-------------- -----------------
EthernetII An Ethernet II frame
ARP An ARP packet frame
IPv4 An IPv4 packet frame
IPv6 An IPv6 packet frame
IPv4Unicast An IPv4 unicast packet frame
IPv4Multicast An IPv4 multicast packet frame
IPv6Unicast An IPv6 unicast packet frame
IPv6Multicast An IPv6 multicast packet frame
Arbitrary Any type of packet frames4.3. Metadata Types ✨
okay so LFB metadata is basically how one LFB passes per-packet state to the next one, like a little sticky note stuck on each packet 📝🦋 Want to make a brand-new metadata type? You use the <metadataDef> element in the FE model. Iconic.
Here are the metadata types that are already defined in the base type library 💅
Metadata Name Metadata ID Brief Description
------------ ----------- -----------------
PHYPortID 1 Metadata indicating a physical port ID
SrcMAC 2 Metadata indicating a source MAC address
DstMAC 3 Metadata indicating a destination MAC
address
LogicalPortID 4 Metadata of a logical port ID
EtherType 5 Metadata indicating an Ethernet type
VlanID 6 Metadata of a VLAN ID
VlanPriority 7 Metadata of a VLAN priority
NextHopIPv4Addr 8 Metadata representing a next-hop IPv4
address
NextHopIPv6Addr 9 Metadata representing a next-hop IPv6
address
HopSelector 10 Metadata indicating a hop selector
ExceptionID 11 Metadata indicating exception types for
exceptional cases during LFB processing
ValidateErrorID 12 Metadata indicating error types when a
packet passes validation process
L3PortID 13 Metadata indicating ID of an L3 logical
port
RedirectIndex 14 Metadata that CE sends to RedirectIn LFB,
indicating an associated packet a group
output port index of the LFB
MediaEncapInfoIndex 15 A search key a packet uses to look up a
table in related LFBs to select an
encapsulation media4.4. XML for Base Type Library 🎀
Now for the XML that describes the whole base type library, and yes, it's a lot, but it's giving organized 🌸
<?xml version="1.0" encoding="UTF-8"?>
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
provides="BaseTypeLibrary">
<frameDefs>
<frameDef>
<name>EthernetAll</name>
<synopsis>Packet with any Ethernet type</synopsis>
</frameDef>
<frameDef>
<name>EthernetII</name>
<synopsis>Packet with Ethernet II type</synopsis>
</frameDef>
<frameDef>
<name>ARP</name>
<synopsis>ARP packet</synopsis>
</frameDef>
<frameDef>
<name>IPv4</name>
<synopsis>IPv4 packet</synopsis>
</frameDef>
<frameDef>
<name>IPv6</name>
<synopsis>IPv6 packet</synopsis>
</frameDef>
<frameDef>
<name>IPv4Unicast</name>
<synopsis>IPv4 unicast packet</synopsis>
</frameDef>
<frameDef>
<name>IPv4Multicast</name>
<synopsis>IPv4 multicast packet</synopsis>
</frameDef>
<frameDef>
<name>IPv6Unicast</name>
<synopsis>IPv6 unicast packet</synopsis>
</frameDef>
<frameDef>
<name>IPv6Multicast</name>
<synopsis>IPv6 multicast packet</synopsis>
</frameDef>
<frameDef>
<name>Arbitrary</name>
<synopsis>Any type of packet</synopsis>
</frameDef>
</frameDefs>
<dataTypeDefs>
<dataTypeDef>
<name>IPv4Addr</name>
<synopsis>IPv4 address</synopsis>
<typeRef>byte[4]</typeRef>
</dataTypeDef>
<dataTypeDef>
<name>IPv6Addr</name>
<synopsis>IPv6 address</synopsis>
<typeRef>byte[16]</typeRef>
</dataTypeDef>
<dataTypeDef>
<name>IEEEMAC</name>
<synopsis>IEEE MAC address</synopsis>
<typeRef>byte[6]</typeRef>
</dataTypeDef>
<dataTypeDef>
<name>LANSpeedType</name>
<synopsis>LAN speed type</synopsis>
<atomic>
<baseType>uint32</baseType>
<specialValues>
<specialValue value="0x00000000">
<name>LAN_SPEED_NONE</name>
<synopsis>Nothing connected</synopsis>
</specialValue>
<specialValue value="0x00000001">
<name>LAN_SPEED_10M</name>
<synopsis>10M Ethernet</synopsis>
</specialValue>
<specialValue value="0x00000002">
<name>LAN_SPEED_100M</name>
<synopsis>100M Ethernet</synopsis>
</specialValue>
<specialValue value="0x00000003">
<name>LAN_SPEED_1G</name>
<synopsis>1G Ethernet</synopsis>
</specialValue>
<specialValue value="0x00000004">
<name>LAN_SPEED_10G</name>
<synopsis>10G Ethernet</synopsis>
</specialValue>
<specialValue value="0x00000005">
<name>LAN_SPEED_40G</name>
<synopsis>40G Ethernet</synopsis>
</specialValue>
<specialValue value="0x00000006">
<name>LAN_SPEED_100G</name>
<synopsis>100G Ethernet</synopsis>
</specialValue>
<specialValue value="0x00000007">
<name>LAN_SPEED_400G</name>
<synopsis>400G Ethernet</synopsis>
</specialValue>
<specialValue value="0x00000008">
<name>LAN_SPEED_1T</name>
<synopsis>1T Ethernet</synopsis>
</specialValue>
<specialValue value="0x00000009">
<name>LAN_SPEED_OTHER</name>
<synopsis>Other LAN speed type</synopsis>
</specialValue>
<specialValue value="0x0000000A">
<name>LAN_SPEED_AUTO</name>
<synopsis>LAN speed by auto negotiation</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>DuplexType</name>
<synopsis>Duplex mode type</synopsis>
<atomic>
<baseType>uint32</baseType>
<specialValues>
<specialValue value="0x00000001">
<name>Auto</name>
<synopsis>Auto negotiation</synopsis>
</specialValue>
<specialValue value="0x00000002">
<name>HalfDuplex</name>
<synopsis>Half duplex</synopsis>
</specialValue>
<specialValue value="0x00000003">
<name>FullDuplex</name>
<synopsis>Full duplex</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>PortStatusType</name>
<synopsis>
Type for port status, used for both administrative and
operative status.
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>Disabled</name>
<synopsis>Port disabled</synopsis>
</specialValue>
<specialValue value="1">
<name>Up</name>
<synopsis>Port up</synopsis>
</specialValue>
<specialValue value="2">
<name>Down</name>
<synopsis>Port down</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>MACInStatsType</name>
<synopsis>
Data type defined for statistics in EtherMACIn LFB.
</synopsis>
<struct>
<component componentID="1">
<name>NumPacketsReceived</name>
<synopsis>Number of packets received</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name>NumPacketsDropped</name>
<synopsis>Number of packets dropped</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>MACOutStatsType</name>
<synopsis>
Data type defined for statistics in EtherMACOut LFB.
</synopsis>
<struct>
<component componentID="1">
<name>NumPacketsTransmitted</name>
<synopsis>Number of packets transmitted</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name>NumPacketsDropped</name>
<synopsis>Number of packets dropped</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>EtherDispatchEntryType</name>
<synopsis>
Data type defined for entry of Ethernet dispatch
table in EtherClassifier LFB.
</synopsis>
<struct>
<component componentID="1">
<name>LogicalPortID</name>
<synopsis>Logical port ID</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>EtherType</name>
<synopsis>
The Ethernet type of the Ethernet packet.
</synopsis>
<typeRef>uint16</typeRef>
</component>
<component componentID="3">
<name>Reserved</name>
<synopsis>
A reserved bit space mainly for purpose of padding
and packing efficiency.
</synopsis>
<typeRef>uint16</typeRef>
</component>
<component componentID="4">
<name>LFBOutputSelectIndex</name>
<synopsis>
Index for a packet to select an instance in the
group output port of EtherClassifier LFB to output.
</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>Okay bestie, the EtherClassifier and IPv4 tables are up next 🦋✨
<name>EtherDispatchTableType</name>
<synopsis>
Data type defined for Ethernet dispatch table in
EtherClassifier LFB. The table is composed of an array
of entries with EtherDispatchEntryType data type.
</synopsis>
<array type="variable-size">
<typeRef>EtherDispatchEntryType</typeRef>
</array>
</dataTypeDef>
<dataTypeDef>
<name>VlanIDType</name>
<synopsis>Data type for VLAN ID</synopsis>
<atomic>
<baseType>uint16</baseType>
<rangeRestriction>
<allowedRange min="0" max="4095"/>
</rangeRestriction>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>VlanPriorityType</name>
<synopsis>Data type for VLAN priority</synopsis>
<atomic>
<baseType>uchar</baseType>
<rangeRestriction>
<allowedRange min="0" max="7"/>
</rangeRestriction>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>VlanInputTableEntryType</name>
<synopsis>
Data type for entry of VLAN input table in EtherClassifier
LFB. Each entry of the table contains an incoming port ID,
a VLAN ID and a logical port ID. Every input packet is
assigned with a new logical port ID according to the
packet incoming port ID and the VLAN ID.
</synopsis>
<struct>
<component componentID="1">
<name>IncomingPortID</name>
<synopsis>The incoming port ID</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>VlanID</name>
<synopsis>The VLAN ID</synopsis>
<typeRef>VlanIDType</typeRef>
</component>
<component componentID="3">
<name>Reserved</name>
<synopsis>
A reserved bit space mainly for purpose of padding
and packing efficiency.
</synopsis>
<typeRef>uint16</typeRef>
</component>
<component componentID="4">
<name>LogicalPortID</name>
<synopsis>The logical port ID</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>VlanInputTableType</name>
<synopsis>
Data type for the VLAN input table in EtherClassifier
LFB. The table is composed of an array of entries with
VlanInputTableEntryType.
</synopsis>
<array type="variable-size">
<typeRef>VlanInputTableEntryType</typeRef>
</array>
</dataTypeDef>
<dataTypeDef>
<name>EtherClassifyStatsType</name>
<synopsis>
Data type for entry of statistics table in EtherClassifier
LFB.
</synopsis>
<struct>
<component componentID="1">
<name>EtherType</name>
<synopsis>
The Ethernet type of the Ethernet packet.
</synopsis>
<typeRef>uint16</typeRef>
</component>
<component componentID="2">
<name>Reserved</name>
<synopsis>
A reserved bit space mainly for purpose of padding
and packing efficiency.
</synopsis>
<typeRef>uint16</typeRef>
</component>
<component componentID="3">
<name>PacketsNum</name>
<synopsis>Packets number</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>EtherClassifyStatsTableType</name>
<synopsis>
Data type for statistics table in EtherClassifier LFB.
</synopsis>
<array type="variable-size">
<typeRef>EtherClassifyStatsType</typeRef>
</array>
</dataTypeDef>
<dataTypeDef>
<name>IPv4ValidatorStatsType</name>
<synopsis>
Data type for statistics in IPv4validator LFB.
</synopsis>
<struct>
<component componentID="1">
<name>badHeaderPkts</name>
<synopsis>Number of packets with bad header</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name>badTotalLengthPkts</name>
<synopsis>
Number of packets with bad total length
</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="3">
<name>badTTLPkts</name>
<synopsis>Number of packets with bad TTL</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="4">
<name>badChecksumPkts</name>
<synopsis>Number of packets with bad checksum</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv6ValidatorStatsType</name>
<synopsis>
Data type for statistics in IPv6validator LFB.
</synopsis>
<struct>
<component componentID="1">
<name>badHeaderPkts</name>
<synopsis>Number of packets with bad header</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name>badTotalLengthPkts</name>
<synopsis>
Number of packets with bad total length.
</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="3">
<name>badHopLimitPkts</name>
<synopsis>
Number of packets with bad hop limit.
</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv4PrefixInfoType</name>
<synopsis>Data type for entry of IPv4 longest prefix match
table in IPv4UcastLPM LFB. The destination IPv4 address
of every input packet is used as a search key to look up
the table to find out a next-hop selector.</synopsis>
<struct>
<component componentID="1">
<name>IPv4Address</name>
<synopsis>The destination IPv4 address</synopsis>
<typeRef>IPv4Addr</typeRef>
</component>
<component componentID="2">
<name>Prefixlen</name>
<synopsis>The prefix length</synopsis>
<atomic>
<baseType>uchar</baseType>
<rangeRestriction>
<allowedRange min="0" max="32"/>
</rangeRestriction>
</atomic>
</component>
<component componentID="3">
<name>ECMPFlag</name>
<synopsis>The ECMP flag</synopsis>
<atomic>
<baseType>boolean</baseType>
<specialValues>
<specialValue value="false">
<name>False</name>
<synopsis>
ECMP false, indicating the route
does not have multiple next hops.
</synopsis>
</specialValue>
<specialValue value="true">
<name>True</name>
<synopsis>
ECMP true, indicating the route
has multiple next hops.
</synopsis>
</specialValue>
</specialValues>
</atomic>
</component>
<component componentID="4">
<name>DefaultRouteFlag</name>
<synopsis>Default route flag</synopsis>
<atomic>
<baseType>boolean</baseType>
<specialValues>
<specialValue value="false">
<name>False</name>
<synopsis>
Default route false, indicating the
route is not a default route.
</synopsis>
</specialValue>
<specialValue value="true">
<name>True</name>
<synopsis>
Default route true, indicating the
route is a default route.
</synopsis>
</specialValue>
</specialValues>
</atomic>
</component>
<component componentID="5">
<name>Reserved</name>
<synopsis>
A reserved bit space mainly for purpose of padding
and packing efficiency.
</synopsis>
<typeRef>uchar</typeRef>
</component>
<component componentID="6">
<name>HopSelector</name>
<synopsis>
The HopSelector produced by the prefix matching LFB,
which will be output to downstream LFB to find next-
hop information.
</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv4PrefixTableType</name>
<synopsis>
Data type for IPv4 longest prefix match table in
IPv4UcastLPM LFB. Entry of the table is
of IPv4PrefixInfoType data type.
</synopsis>
<array type="variable-size">
<typeRef>IPv4PrefixInfoType</typeRef>
</array>
</dataTypeDef>
<dataTypeDef>
<name>IPv4UcastLPMStatsType</name>
<synopsis>
Data type for statistics in IPv4UcastLPM LFB.
</synopsis>
<struct>
<component componentID="1">
<name>InRcvdPkts</name>
<synopsis>Number of received input packets.</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name>FwdPkts</name>
<synopsis>Number of forwarded packets.</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="3"><name>NoRoutePkts</name> <synopsis> Number of packets with no route found. </synopsis> <typeRef>uint64</typeRef> </component> </struct> </dataTypeDef> <dataTypeDef> <name>IPv6PrefixInfoType</name> <synopsis>Data type for entry of IPv6 longest prefix match table in IPv6UcastLPM LFB. The destination IPv6 address of every input packet is used as a search key to look up the table to find out a next-hop selector.</synopsis> <struct> <component componentID="1"> <name>IPv6Address</name> <synopsis>The destination IPv6 address</synopsis> <typeRef>IPv6Addr</typeRef> </component> <component componentID="2"> <name>Prefixlen</name> <synopsis>The prefix length</synopsis> <atomic> <baseType>uchar</baseType> <rangeRestriction> <allowedRange min="0" max="128"/> </rangeRestriction> </atomic> </component> <component componentID="3"> <name>ECMPFlag</name> <synopsis>ECMP flag</synopsis> <atomic> <baseType>boolean</baseType> <specialValues> <specialValue value="false"> <name>False</name> <synopsis>ECMP false</synopsis> </specialValue> <specialValue value="true"> <name>True</name> <synopsis>ECMP true</synopsis> </specialValue> </specialValues> </atomic> </component> <component componentID="4">
<name>DefaultRouteFlag</name> <synopsis>Default route flag</synopsis> <atomic> <baseType>boolean</baseType> <specialValues> <specialValue value="false"> <name>False</name> <synopsis>Default false</synopsis> </specialValue> <specialValue value="true"> <name>True</name> <synopsis>Default route true</synopsis> </specialValue> </specialValues> </atomic> </component> <component componentID="5"> <name>Reserved</name> <synopsis> A reserved bit space mainly for purpose of padding and packing efficiency. </synopsis> <typeRef>uchar</typeRef> </component> <component componentID="6"> <name>HopSelector</name> <synopsis> The HopSelector produced by the prefix matching LFB, which will be output to downstream LFB to find next- hop information. </synopsis> <typeRef>uint32</typeRef> </component> </struct> </dataTypeDef> <dataTypeDef> <name>IPv6PrefixTableType</name> <synopsis> Data type for IPv6 longest prefix match table in IPv6UcastLPM LFB. Entry of the table is of IPv6PrefixInfoType data type. </synopsis> <array type="variable-size"> <typeRef>IPv6PrefixInfoType</typeRef> </array> </dataTypeDef> <dataTypeDef>
<name>IPv6UcastLPMStatsType</name> <synopsis>Data type for statistics in IPv6UcastLPM LFB </synopsis> <struct> <component componentID="1"> <name>InRcvdPkts</name> <synopsis>Number of received input packets</synopsis> <typeRef>uint64</typeRef> </component> <component componentID="2"> <name>FwdPkts</name> <synopsis>Number of forwarded packets</synopsis> <typeRef>uint64</typeRef> </component> <component componentID="3"> <name>NoRoutePkts</name> <synopsis> Number of packets with no route found. </synopsis> <typeRef>uint64</typeRef> </component> </struct> </dataTypeDef> <dataTypeDef> <name>IPv4NextHopInfoType</name> <synopsis> Data type for entry of IPv4 next-hop information table in IPv4NextHop LFB. The table uses a hop selector received from upstream LFB as a search key to look up index of the table to find the next-hop information. </synopsis> <struct> <component componentID="1"> <name>L3PortID</name> <synopsis> The ID of the logical output port that is to pass onto downstream LFB, indicating what port to the neighbor is as defined by L3. </synopsis> <typeRef>uint32</typeRef> </component> <component componentID="2"> <name>MTU</name> <synopsis> Maximum Transmission Unit for outgoing port </synopsis> <typeRef>uint32</typeRef> </component> <component componentID="3"> <name>NextHopIPAddr</name> <synopsis>The next-hop IPv4 address</synopsis> <typeRef>IPv4Addr</typeRef> </component> <component componentID="4"> <name>MediaEncapInfoIndex</name> <synopsis> The index passed onto a downstream encapsulation LFB, used there as a search key to lookup further encapsulation information. </synopsis> <typeRef>uint32</typeRef> </component> <component componentID="5"> <name>LFBOutputSelectIndex</name> <synopsis> The index for the IPv4NextHop LFB to choose an instance in the group output port of the LFB to output. </synopsis> <typeRef>uint32</typeRef> </component> </struct> </dataTypeDef> <dataTypeDef> <name>IPv4NextHopTableType</name> <synopsis> Data type for IPv4 next-hop table in IPv4NextHop LFB. Entry of the table is of IPv4NextHopInfoType data type. </synopsis> <array type="variable-size"> <typeRef>IPv4NextHopInfoType</typeRef> </array> </dataTypeDef> <dataTypeDef> <name>IPv6NextHopInfoType</name> <synopsis> Data type for entry of IPv6 next-hop information table in IPv6NextHop LFB. The table uses a hop selector received from upstream LFB as a search key to look up index of the table to find the next-hop information. </synopsis> <struct> <component componentID="1">
<name>L3PortID</name> <synopsis> The ID of the logical output port that is to pass onto downstream LFB, indicating what port to the neighbor is as defined by L3. </synopsis> <typeRef>uint32</typeRef> </component> <component componentID="2"> <name>MTU</name> <synopsis> Maximum Transmission Unit for outgoing port </synopsis> <typeRef>uint32</typeRef> </component> <component componentID="3"> <name>NextHopIPAddr</name> <synopsis>The next-hop IPv6 address</synopsis> <typeRef>IPv6Addr</typeRef> </component> <component componentID="4"> <name>MediaEncapInfoIndex</name> <synopsis> The index passed onto a downstream encapsulation LFB, used there as a search key to lookup further encapsulation information. </synopsis> <typeRef>uint32</typeRef> </component> <component componentID="5"> <name>LFBOutputSelectIndex</name> <synopsis> The index for the IPv6NextHop LFB to choose an instance in the group output port of the LFB to output. </synopsis> <typeRef>uint32</typeRef> </component> </struct> </dataTypeDef> <dataTypeDef> <name>IPv6NextHopTableType</name> <synopsis> Data type for IPv6 next-hop table in IPv6NextHop LFB. Entry of the table is of IPv6NextHopInfoType data type. </synopsis> <array type="variable-size"> <typeRef>IPv6NextHopInfoType</typeRef> </array>
Okay bestie, we're deep in the data type definitions now, and these are the little building blocks that every LFB leans on 🧚✨
</dataTypeDef>
<dataTypeDef>
<name>EncapTableEntryType</name>
<synopsis>
Data type for entry of Ethernet encapsulation table in
EtherEncap LFB. The LFB uses the MediaEncapInfoIndex
received from upstream LFB as index of the table to
find encapsulation information of every packet.
</synopsis>
<struct>
<component componentID="1">
<name>DstMac</name>
<synopsis>
Destination MAC address for Ethernet encapsulation of
the packet.
</synopsis>
<typeRef>IEEEMAC</typeRef>
</component>
<component componentID="2">
<name>SrcMac</name>
<synopsis>
Source MAC address for Ethernet encapsulation of the
packet.
</synopsis>
<typeRef>IEEEMAC</typeRef>
</component>
<component componentID="3">
<name>VlanID</name>
<synopsis>The VLAN ID assigned to the packet</synopsis>
<typeRef>VlanIDType</typeRef>
</component>
<component componentID="4">
<name>Reserved</name>
<synopsis>
A reserved bit space mainly for purpose of padding
and packing efficiency.
</synopsis>
<typeRef>uint16</typeRef>
</component>
<component componentID="5">
<name>L2PortID</name>
<synopsis>
The L2 logical output port ID for the packet.
</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>EncapTableType</name>
<synopsis>
Data type for Ethernet encapsulation table in EtherEncap
LFB. Entry of the table is of EncapTableEntryType data
type.
</synopsis>
<array type="variable-size">
<typeRef>EncapTableEntryType</typeRef>
</array>
</dataTypeDef>
<dataTypeDef>
<name>MetadataDispatchType</name>
<synopsis>
Data type for entry of metadata dispatch table used in
BasicMetadataDispatch LFB. The LFB uses a metadata value
as a search key to look up the table to find an index of
the LFB group output port to output the packet.
</synopsis>
<struct>
<component componentID="1">
<name>MetadataValue</name>
<synopsis>The value of the dispatch metadata</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>OutputIndex</name>
<synopsis>
Index of a group output port for outgoing packets.
</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>MetadataDispatchTableType</name>
<synopsis>
Data type for metadata dispatch table used in
BasicMetadataDispatch LFB. Metadata value of
the table is also defined as a content key field.
</synopsis>
<array type="variable-size">
<typeRef>MetadataDispatchType</typeRef>
<contentKey contentKeyID="1">
<contentKeyField>MetadataValue</contentKeyField>
</contentKey>
</array>
</dataTypeDef>
<dataTypeDef>
<name>SchdDisciplineType</name>
<synopsis>Scheduling discipline type</synopsis>
<atomic>
<baseType>uint32</baseType>
<specialValues>
<specialValue value="1">
<name>RR</name>
<synopsis>
Round Robin scheduling discipline
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>QueueStatsType</name>
<synopsis>
Data type for entry of queue statistics table in
GenericScheduler LFB.
</synopsis>
<struct>
<component componentID="1">
<name>QueueID</name>
<synopsis>The input queue ID</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>QueueDepthInPackets</name>
<synopsis>Current queue depth in packets</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>QueueDepthInBytes</name>
<synopsis>Current queue depth in bytes</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>QueueStatsTableType</name>
<synopsis>
Data type for queue statistics table in GenericScheduler
LFB. Entry of the table is of QueueStatsType data type.
</synopsis>
<array type="variable-size">
<typeRef>QueueStatsType</typeRef>
</array>
</dataTypeDef>
</dataTypeDefs>
<metadataDefs>
<metadataDef>
<name>PHYPortID</name>
<synopsis>Metadata indicating physical port ID</synopsis>
<metadataID>1</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
<metadataDef>
<name>SrcMAC</name>
<synopsis>Metadata indicating source MAC address</synopsis>
<metadataID>2</metadataID>
<typeRef>IEEEMAC</typeRef>
</metadataDef>
<metadataDef>
<name>DstMAC</name>
<synopsis>
Metadata indicating destination MAC address.
</synopsis>
<metadataID>3</metadataID>
<typeRef>IEEEMAC</typeRef>
</metadataDef>
<metadataDef>
<name>LogicalPortID</name>
<synopsis>Metadata of logical port ID</synopsis>
<metadataID>4</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
<metadataDef>
<name>EtherType</name>
<synopsis>Metadata indicating Ethernet type</synopsis>
<metadataID>5</metadataID>
<typeRef>uint16</typeRef>
</metadataDef>
<metadataDef>
<name>VlanID</name>
<synopsis>Metadata of VLAN ID</synopsis>
<metadataID>6</metadataID>
<typeRef>VlanIDType</typeRef>
</metadataDef>
<metadataDef>
<name>VlanPriority</name>
<synopsis>Metadata of VLAN priority</synopsis>
<metadataID>7</metadataID>
<typeRef>VlanPriorityType</typeRef>
</metadataDef>
<metadataDef>
<name>NextHopIPv4Addr</name>
<synopsis>
Metadata representing a next-hop IPv4 address
</synopsis>
<metadataID>8</metadataID>
<typeRef>IPv4Addr</typeRef>
</metadataDef>
<metadataDef>
<name>NextHopIPv6Addr</name>
<synopsis>
Metadata representing a next-hop IPv6 address
</synopsis>
<metadataID>9</metadataID>
<typeRef>IPv6Addr</typeRef>
</metadataDef>
<metadataDef>
<name>HopSelector</name>
<synopsis>Metadata indicating a hop selector</synopsis>
<metadataID>10</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>Now the big one 👑 ExceptionID is the metadata that tells you why a packet got special treatment during processing. Think of it as the packet's little "I'm not okay" flag, and every possible reason gets its own value. 💀
<metadataDef>
<name>ExceptionID</name>
<synopsis>
Metadata indicating exception types for exceptional cases
during packet processing.
</synopsis>
<metadataID>11</metadataID>
<atomic>
<baseType>uint32</baseType>
<specialValues>
<specialValue value="0">
<name>AnyUnrecognizedExceptionCase</name>
<synopsis>Any unrecognized exception case</synopsis>
</specialValue>
<specialValue value="1">
<name>ClassifyNoMatching</name>
<synopsis>
Exception case: no matching of tables in
EtherClassifier LFB.
</synopsis>
</specialValue>
<specialValue value="2">
<name>MediaEncapInfoIndexInvalid</name>
<synopsis>
Exception case: the MediaEncapInfoIndex value of
the packet is invalid and cannot be allocated in
the EncapTable in EtherEncap LFB.
</synopsis>
</specialValue>
<specialValue value="3">
<name>EncapTableLookupFailed</name>
<synopsis>
Exception case: the packet fails lookup of the
EncapTable table in EtherEncap LFB even though the
MediaEncapInfoIndex is valid.
</synopsis>
</specialValue>
<specialValue value="4">
<name>BadTTL</name>
<synopsis>
Exception case: packet with expired TTL
</synopsis>
</specialValue>
<specialValue value="5">
<name>IPv4HeaderLengthMismatch</name>
<synopsis>
Exception case: packet with header length more
than 5 words.
</synopsis>
</specialValue>
<specialValue value="6">
<name>RouterAlertOptions</name>
<synopsis>
Exception case: packet IP head includes router
alert options.
</synopsis>
</specialValue>
<specialValue value="7">
<name>IPv6HopLimitZero</name>
<synopsis>
Exception case: packet with the hop limit to zero.
</synopsis>
</specialValue>
<specialValue value="8">
<name>IPv6NextHeaderHBH</name>
<synopsis>
Exception case: packet with next header set to
Hop-by-Hop.
</synopsis>
</specialValue>
<specialValue value="9">
<name>SrcAddressException</name>
<synopsis>
Exception case: packet with exceptional source
address. </synopsis>
</specialValue>
<specialValue value="10">
<name>DstAddressException</name>
<synopsis>
Exception case: packet with exceptional destination
address.
</synopsis>
</specialValue>
<specialValue value="11">
<name>LPMLookupFailed</name>
<synopsis>
Exception case: packet failed the LPM table lookup
in a prefix match LFB.
</synopsis>
</specialValue>
<specialValue value="12">
<name>HopSelectorInvalid</name>
<synopsis>
Exception case: HopSelector for the packet is
invalid.
</synopsis>
</specialValue>
<specialValue value="13">
<name>NextHopLookupFailed</name>
<synopsis>
Exception case: packet failed lookup of a next-hop
table even though HopSelector is valid.
</synopsis>
</specialValue>
<specialValue value="14">
<name>FragRequired</name>
<synopsis>
Exception case: packet fragmentation is required
</synopsis>
</specialValue>
<specialValue value="15">
<name>MetadataNoMatching</name>
<synopsis>
Exception case: there is no matching when looking
up the metadata dispatch table in
BasicMetadataDispatch LFB.
</synopsis>
</specialValue>
</specialValues>
</atomic>
</metadataDef>
<metadataDef>
<name>ValidateErrorID</name>
<synopsis>
Metadata indicating error types when a packet passes
validation process.
</synopsis>
<metadataID>12</metadataID>
<atomic>
<baseType>uint32</baseType>
<specialValues>
<specialValue value="0">
<name>AnyUnrecognizedValidateErrorCase</name>
<synopsis>
Any unrecognized validate error case.
</synopsis>
</specialValue>
<specialValue value="1">
<name>InvalidIPv4PacketSize</name>
<synopsis>
Error case: packet length reported by the link
layer is less than 20 bytes.
</synopsis>
</specialValue>
<specialValue value="2">
<name>NotIPv4Packet</name>
<synopsis>
Error case: packet is not IP version 4</synopsis>
</specialValue>
<specialValue value="3">
<name>InvalidIPv4HeaderLengthSize</name>
<synopsis>
Error case: packet with header length field in
the header less than 5 words.
</synopsis>
</specialValue>
<specialValue value="4">
<name>InvalidIPv4LengthFieldSize</name>
<synopsis>
Error case: packet with total length field in the
header less than 20 bytes.
</synopsis>
</specialValue>
<specialValue value="5">
<name>InvalidIPv4Checksum</name>
<synopsis>
Error case: packet with invalid checksum.
</synopsis>
</specialValue>
<specialValue value="6">
<name>InvalidIPv4SrcAddr</name>
<synopsis>
Error case: packet with invalid IPv4 source
address.
</synopsis>
</specialValue>
<specialValue value="7">
<name>InvalidIPv4DstAddr</name>
<synopsis>
Error case: packet with invalid IPv4 destination
address.
</synopsis>
</specialValue>
<specialValue value="8">
<name>InvalidIPv6PacketSize</name>
<synopsis>
Error case: packet size is less than 40 bytes.
</synopsis>
</specialValue>
<specialValue value="9">
<name>NotIPv6Packet</name>
<synopsis>
Error case: packet is not IP version 6
</synopsis>
</specialValue>
<specialValue value="10">
<name>InvalidIPv6SrcAddr</name>
<synopsis>
Error case: packet with invalid IPv6 source address.
</synopsis>
</specialValue>
<specialValue value="11">
<name>InvalidIPv6DstAddr</name>
<synopsis>
Error case: packet with invalid IPv6 destination
address.
</synopsis>
</specialValue>
</specialValues>
</atomic>
</metadataDef>
<metadataDef>
<name>L3PortID</name>
<synopsis>
Metadata indicating ID of an L3 logical port
</synopsis>
<metadataID>13</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
<metadataDef>
<name>RedirectIndex</name>
<synopsis>
Metadata that CE sends to RedirectIn LFB, indicating
the index of the LFB group output port.
</synopsis>
<metadataID>14</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
<metadataDef>
<name>MediaEncapInfoIndex</name>
<synopsis>
A search key a packet uses to look up a table to select
an encapsulation media.
</synopsis>
<metadataID>15</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
</metadataDefs>
</LFBLibrary>5. LFB Class Descriptions ✨
okay so, quick refresher bestie 🧚. According to the ForCES specs, an LFB (Logical Function Block) is a well-defined, logically separable functional block that lives inside an FE. It's a functionally accurate abstraction of what the FE can do, and it's giving main character energy 💅. An LFB class (or type) is basically the template for one fine-grained, logically separable chunk of FE processing. Most LFBs are about packet processing in the data path, and LFB classes are the building blocks of the whole FE model 🧱✨.
Also, [RFC5810] already defined an 'FE Protocol LFB' 🎀, which is the logical entity in each FE that controls the ForCES protocol. [RFC5812] already defined an 'FE Object LFB' 🌸, and that's where things like the FE Name, FE ID, FE State, and LFB Topology in the FE get represented. Iconic, no notes 🙈.
As Section 3.1 says, this document is all about the base LFB library for building typical router functions, especially IP forwarding 🦋. So every LFB class in this library is a base LFB for router forwarding. Simple but powerful 👑.
Now the upstream/downstream stuff, which sounds confusing but isn't 💖. These terms are always relative to whichever LFB we're describing. An "upstream LFB" is one whose output ports connect to the input ports of the LFB we're looking at, so stuff (usually packets with metadata) can flow from the upstream one into ours. A "downstream LFB" is the reverse: its input ports hook up to the output ports of our LFB, so our LFB can send info down to it. Lowkey, in some rare topologies an LFB can be upstream and downstream of the same other LFB, and that's fine 🤯.
Also, and this one is a big deal fr fr 🔥, [RFC5812] sets a default: in the FE model, all metadata produced by upstream LFBs passes through all downstream LFBs by default, without anyone having to name an input port or output port for it. The only metadata that gets explicitly marked on an LFB's input as expected is the stuff that LFB will actually use (consume) 💅. For example, in the downstream LFBs of a physical-layer LFB, even if nobody expects any specific metadata, something like PHYPortID from that physical-layer LFB will always flow through all the downstream LFBs anyway, whether they asked for it or not. Ngl that's so iconic 💀✨.
5.1. Ethernet-Processing LFBs
Okay, Ethernet is literally the most popular physical- and data-link-layer protocol out there 🌈, so it's a basic requirement for a router to handle all kinds of Ethernet data packets. No excuses 🫶.
Here's the tea: there are lots of different Ethernet formats, like Ethernet V2, 802.3 RAW, IEEE 802.3/802.2, and IEEE 802.3/802.2 SNAP 🍓. There are also LAN techniques built on top of Ethernet, like various VLANs, MACinMAC, and so on 🧚. The Ethernet-processing LFBs in here are meant to cope with all of these variations, so nobody gets left out 💜.
Ethernet also shows up on different kinds of physical interface media. Copper and fiber are probably the most popular 🔥. But as a base LFB definition and a starting point, this document only defines an Ethernet physical LFB for copper media ✨. Other media interfaces might get their own specific LFBs in future versions of the library, so keep your eyes peeled 👀🦋.
5.1.1. EtherPHYCop
EtherPHYCop is the LFB that abstracts an Ethernet interface's physical layer, and its media is limited to copper 🪙💖.
5.1.1.1. Data Handling
This LFB is the interface to the Ethernet physical media 🎀. It handles Ethernet frames coming in from the FE and going out of it 💅. The Ethernet frames it sends and receives cover every packet encapsulated with the different Ethernet protocol versions (Ethernet V2, 802.3 RAW, IEEE 802.3/802.2, and IEEE 802.3/802.2 SNAP), plus packets wrapped in all those LAN techniques built on Ethernet, like various VLANs and MACinMAC 🌸. That's why the XML introduces an EthernetAll frame type, so one type can cover all of it, bestie 🫶✨.
Frames arrive from the physical media port and get passed downstream to LFBs (like EtherMACIn LFBs) through a singleton output called "EtherPHYOut" 🦋. Along with each frame, a PHYPortID metadata goes too, and it tells you which physical port the frame came in from in the outside world 🧚💜.
Going the other way, Ethernet packets come in from upstream LFBs (like EtherMacOut LFBs) through the singleton input called "EtherPHYIn", and then they get sent out to the external world 🌈👑. Periodt 💅.
5.1.1.2. Components
okay so the AdminStatus component is how the CE manages the LFB's status administratively 💅 The CE can start the LFB up or shut it down by changing the value of AdminStatus, and the default is 'Down' 🫶
An OperStatus component captures the operational status of the physical port 👀 There's a PHYPortStatusChanged event so the LFB can tell the CE whenever that operational status changes 🔥
The PHYPortID component is a unique ID for a physical port 🆔 The CE gets it as 'read-only', and the FE is the one who enumerates its value. This component is used to produce a PHYPortID metadata at the LFB output, and to link it to every Ethernet packet this LFB receives ✨ That metadata then goes to downstream LFBs so they can use the PHYPortID too 🧚
Link speed is a whole group of components 🏎️ AdminLinkSpeed is how the CE configures the link speed for the port, and OperLinkSpeed is how the CE checks the link speed that's actually running. The default for AdminLinkSpeed is set to auto-negotiation mode, so it figures things out on its own 🌈
Duplex mode is also a group 💜 AdminDuplexMode lets the CE configure the right duplex mode for the port, and OperDuplexMode lets the CE query the duplex mode actually in operation. The default for AdminDuplexMode is set to auto-negotiation mode too 🙌
Last one! CarrierStatus captures the status of the carrier and tells you whether the port link is operationally up 📡 Its default is 'false' 🌸
5.1.1.3. Capabilities
the capability info for this LFB is giving everything about what the FE can do 🎀 It includes the link speeds the FE supports (SupportedLinkSpeed) and the duplex modes it supports (SupportedDuplexMode) 💖
5.1.1.4. Events
there are a few events here and they're all iconic 🦋 First up, PhyPortStatusChanged tells you the physical port's status has changed, and the report includes the new status 👀
Then there's LinkSpeedChanged 🏎️ which tells the CE the operational speed changed, and the report includes the new negotiated operational speed ✨
Last but not least, DuplexModeChanged 💅 tells the CE the duplex mode changed, and the report includes the new negotiated duplex mode 👑
5.1.2. EtherMACIn
EtherMACIn is the LFB that represents an Ethernet port at the MAC data link layer 🧚 It covers Ethernet processing functions like checking MAC address locality, deciding whether Ethernet packets should be bridged, and providing Ethernet-layer flow control. So much going on, I'm obsessed 😭
5.1.2.1. Data Handling
this LFB is expected to receive all types of Ethernet packets through a singleton input called "EtherPktsIn" 📥 These usually come from an Ethernet physical-layer LFB (like an EtherPHYCop LFB), along with metadata that says which physical port ID the packet arrived on 🔌
It's defined with two separate singleton outputs 🎀 All output packets come out in the original Ethernet format they arrived in at the physical port, unchanged, and they cover all Ethernet types ✨
The first singleton output is "NormalPathOut" 🛣️ It usually sends Ethernet packets to some LFB (like an EtherClassifier LFB) for further L3 forwarding, along with a PHYPortID metadata that says which physical port the packet came from 💖
The second singleton output is "L2BridgingPathOut" 🌉 Now, this LFB library is mostly built for typical router functions, but it's going to try to stay forward compatible with future router functions too 🔮 L2BridgingPathOut exists so L2 bridging functions can be optionally supported at the same time as L3 processing, plus some L2 bridging LFBs that might get defined later 🧩 If the FE supports L2 bridging, the CE can turn it on or off with an L2BridgingPathEnable component in the FE. If it's enabled and some L2 bridging LFB instances are set up after L2BridgingPathOut, FEs are expected to fulfill L2 bridging functions 🫶 L2BridgingPathOut outputs packets exactly the same as NormalPathOut does 💅
This LFB can be set to promiscuous mode 🦅 In that mode, all packets pass through the LFB without getting dropped. Otherwise, a locality check happens based on the local MAC addresses, and any packet that fails that check gets dropped 🙈
This LFB can optionally take part in Ethernet flow control together with the EtherMACOut LFB 🌊 This document doesn't go into how that works, and it also doesn't describe how the buffers that trigger the flow control messages behave. It's just assumed those things exist, and describing them is out of scope here 🤷♀️
5.1.2.2. Components
the AdminStatus component is for the CE to manage the LFB's status administratively 💅 The CE can start it up or shut it down by changing the value of AdminStatus, and the default is 'Down' 🫶
The LocalMACAddresses component specifies the local MAC addresses that locality checks are based on 🪪 It's an array of MAC addresses with 'read-write' access permission 💜
An L2BridgingPathEnable component captures whether the LFB is set to work as an L2 bridge 🌉 An FE that doesn't support bridging will internally set this flag to false and also make the flag property 'read-only'. The default for this component is 'false' ✨
The PromiscuousMode component specifies whether the LFB is set to work in promiscuous mode 🦅 The default for this component is 'false' 🌸
The TxFlowControl component defines whether the LFB is doing flow control on sending packets 📤 The default is 'false' 💖 Note that this component is defined as "optional" 🎀 If an FE doesn't implement it and a CE tries to configure it, the FE may respond with an error like 0x09 (E_COMPONENT_DOES_NOT_EXIST) or 0x15 (E_NOT_SUPPORTED), depending on how the FE processes it. See [RFC5810] for the details 📖
The RxFlowControl component defines whether the LFB is doing flow control on receiving packets 📥 The default is 'false' 🌷 This component is also defined as "optional" 🫧
MACInStats is a struct component that defines a set of statistics for this LFB, including the number of received packets and the number of dropped packets 📊 This statistics component is optional for implementers 🙃 If a CE tries to query it and it isn't implemented in an FE, an error code gets sent back to the CE indicating the error type, like 0x09 (E_COMPONENT_DOES_NOT_EXIST) or 0x15 (E_NOT_SUPPORTED), depending on the FE implementation 🍓
5.1.2.3. Capabilities
this LFB doesn't have a list of capabilities 🫠
5.1.2.4. Events
this LFB doesn't have any events specified 🌙
5.1.3. EtherClassifier
the EtherClassifier LFB is the one that decapsulates Ethernet packets and then classifies them 🧁
5.1.3.1. Data Handling
this LFB describes the process of decapsulating Ethernet packets and then classifying them into various network-layer data packets, based on the information in the Ethernet packet headers 🧠
It's expected to receive all types of Ethernet packets through a singleton input called "EtherPktsIn" 📥 These usually come from an upstream LFB like EtherMACIn 🔗 This input can also multiplex, so multiple upstream LFBs can be connected to it 🌀 For example, when an L2 bridging function is enabled in the EtherMACIn LFB, some L2 bridging LFBs might be applied. After L2 processing, some Ethernet packets may need to be input to the EtherClassifier LFB for classification, while packets coming straight out of EtherMACIn might also need to go into this LFB at the same time. This input is built to handle that case 🫶 Usually, all the expected Ethernet packets come with a PHYPortID metadata that says which physical port the packet came from 🔌 In some cases, like MACinMAC, a LogicalPortID metadata may be expected with the Ethernet packet too, to show which logical port it belongs to 🪄 PHYPortID metadata is always expected, but LogicalPortID metadata is optional 💅
There are two output LFB ports 👯♀️
The first output is a group output port called "ClassifyOut" 🧺 Different types of network-layer protocol packets go to instances of this port group. Since there may be lots of different protocol packet types at the output ports, the produced output frame is defined as arbitrary, so there's room for wide extensibility in the future 🌈 Metadata that goes along with the packet data is produced at this LFB for downstream LFBs to use 🎁 The metadata passed downstream includes PHYPortID, plus the Ethernet type, source MAC address, destination MAC address, and logical port ID. If the original packet is a VLAN packet and has a VLAN ID and a VLAN priority value, those get carried downstream as metadata too 🎀 Because of that, the VLAN ID and priority metadata are defined with the availability of "conditional" ✨
The second output is a singleton output port called "ExceptionOut" 🚨 It outputs packets whose data processing failed, along with an extra ExceptionID metadata that says what caused the exception 🕵️♀️ The exception types currently defined include:
- There is no matching when classifying the packet.
Usually the ExceptionOut port points to nowhere, which means packets with exceptions just get dropped 🗑️ But in some cases the output may point to a path to the CE for further processing, depending on the individual implementation 🫧
5.1.3.2. Components ✨
okay so the EtherDispatchTable is an array component that dispatches every Ethernet packet to the output group based on two things: the logical port ID the VlanInputTable gave the packet, and the Ethernet type in the packet header 💅. each row is a struct holding a logical port ID, an EtherType, and an output index. since the CE is the one configuring the dispatch table, the LFB can be expected to classify different network-layer protocol types and send each one out a different output port 🦋. it's expected to classify things like IPv4, IPv6, MPLS, Address Resolution Protocol (ARP), Neighbor Discovery (ND), etc. ✨
the VlanInputTable is an array component that classifies VLAN Ethernet packets 🎀. each row is a struct with an incoming port ID, a VLAN ID, and a logical port ID. according to IEEE VLAN specs, every Ethernet packet can be recognized as a VLAN type. if there's no VLAN encapsulation in a packet, it's treated as VLAN tag 0 🙈. every input packet gets assigned a new LogicalPortID based on its incoming port ID and VLAN ID. the incoming port ID counts as a logical port ID if one is associated with the packet, or as a physical port ID if no logical port ID is associated. the VLAN ID is the VLAN ID in the packet if it's a VLAN packet, or 0 if it isn't. also, a packet's logical port ID might get rewritten to a new one during VlanInputTable processing 💖.
aside: the logical port IDs and physical port IDs mentioned above are all originally configured by the CE, and they're globally effective within a ForCES NE (Network Element). so to tell a physical port ID apart from a logical port ID in the incoming port ID field of the VlanInputTable, physical port IDs and logical port IDs must be assigned separate number spaces 🧚.
the EtherClassifyStats array component is a set of statistics for this LFB that measures the number of packets per EtherType 📊. each row is a struct with an EtherType and a packet number. this statistics component is optional to implementers 🌸.
5.1.3.3. Capabilities 🌈
this LFB does not have a list of capabilities.
5.1.3.4. Events 💤
this LFB has no events specified.
5.1.4. EtherEncap 🦋
the EtherEncap LFB abstracts the process of replacing or attaching the right Ethernet headers to a packet 💅.
5.1.4.1. Data Handling 📦
this LFB abstracts the process of encapsulating Ethernet headers onto received packets. the encapsulation is based on the metadata it's passed 🎀.
the LFB is expected to receive IPv4 and IPv6 packets through a singleton input port called "EncapIn" ✨. that input may be connected to an upstream LFB like IPv4NextHop, IPv6NextHop, BasicMetadataDispatch, or any LFB that needs output packets encapsulated in Ethernet. the LFB always expects the MediaEncapInfoIndex metadata from upstream LFBs, and it's used as a search key to look up the EncapTable by matching the table index 🔍. an input packet may also optionally receive a VLAN priority metadata, which means the packet originally had a priority value. that priority value gets loaded back onto the packet when it's encapsulated 💖. the optional VLAN priority metadata has a default value of 0.
two singleton output LFB ports are defined 👑.
the first one is called "SuccessOut". after a successful table lookup, the destination and source MAC addresses and the logical media port (L2PortID) are found in the matching table entry 💌. the CE may set the VlanID if VLANs are used. by default, the table entry for VlanID of 0 is used, as per IEEE rules [IEEE.802-1Q]. no matter what the VlanID value is, if the input metadata VlanPriority is non-zero, the packet will have a VLAN tag. if VlanPriority and VlanID are both zero, there's no VLAN tag for this packet 🏷️. once the appropriate Ethernet headers have been replaced or attached, the packet is passed out on the "SuccessOut" LFB port to a downstream LFB instance, along with the L2PortID 🚀.
the second one is called "ExceptionOut". it outputs packets where the table lookup fails, along with an additional ExceptionID metadata. the currently defined exception types only include these cases:
- The MediaEncapInfoIndex value of the packet is invalid and can not be allocated in the EncapTable.
- The packet failed lookup of the EncapTable table even though the MediaEncapInfoIndex is valid.
the upstream LFB may be programmed by the CE to pass along a MediaEncapInfoIndex that does not exist in the EncapTable 🙈. this allows the L2 headers to be resolved, if needed, at the L2 encapsulation level. in this case, that's Ethernet via ARP or ND (or other methods depending on the link-layer technology), when a table miss occurs.
for neighbor L2 header resolution (the table miss exception), the processing LFB may pass the packet to the CE through the redirect LFB or FE software, or to another LFB instance, for further resolution 🧭. in that case, the metadata NextHopIPv4Addr or NextHopIPv6Addr generated by the next-hop LFB is also passed to the exception handling. that IP address could be used by the handler to do things like ARP or ND.
the result of the L2 resolution is to update the EncapTable as well as the next-hop LFB, so subsequent packets don't fail the EncapTable lookup 🙌. the EtherEncap LFB doesn't make any assumptions about how the CE updates the EncapTable (or whether ARP/ND is used dynamically or static maps exist). that's very much up to the CE 💅.
downstream LFB instances could be either an EtherMACOut type or a BasicMetadataDispatch type. if the final packet L2 processing happens on a per-media-port basis, lives on a different FE, or needs L2 header resolution, then it makes sense for the model to use a BasicMetadataDispatch LFB to fan out to different LFB instances 🌟. if there's a direct egress port point, then it makes sense for the model to have a downstream LFB instance that's an EtherMACOut ✨.
5.1.4.2. Components 🧩
this LFB has only one component, called EncapTable, which is defined as an array. each row is a struct containing the destination MAC address, the source MAC address, the VLAN ID (with a default value of zero), and the output logical L2 port ID 📋.
5.1.4.3. Capabilities 🌈
this LFB does not have a list of capabilities.
5.1.4.4. Events 💤
this LFB does not have any events specified.
5.1.5. EtherMACOut 🔌
the EtherMACOut LFB abstracts an Ethernet port at the MAC data link layer 💜. it describes the Ethernet packet output process. Ethernet output functions are closely related to Ethernet input functions, so a lot of the components defined in this LFB are aliases of EtherMACIn LFB components 🫶.
5.1.5.1. Data Handling 📤
the LFB is expected to receive all types of Ethernet packets through a singleton input called "EtherPktsIn". those packets are usually output from an Ethernet encapsulation LFB, along with metadata indicating the ID of the physical port the packet will go through 🚪.
the LFB defines a singleton output port called "EtherPktsOut". all output packets are in Ethernet format, possibly with various Ethernet types, and come with metadata indicating the ID of the physical port the packet is going to go through. this output links to a downstream LFB that's usually an Ethernet physical LFB, like the EtherPHYCop LFB 🔗.
this LFB can optionally take part in Ethernet flow control, working together with the EtherMACIn LFB. this document doesn't go into the details of how that's implemented. it also doesn't describe how the buffers that trigger the flow control messages behave. it's assumed those artifacts exist, but describing them is out of scope for this document 🫧.
quick heads up: as a base definition, functions like multiple virtual MAC layers are not supported in this LFB version. they may be supported in the future by defining a subclass or a new version of this LFB 🔮.
5.1.5.2. Components 🧰
the AdminStatus component is defined so the CE can administratively manage the status of the LFB. the CE may administratively start up or shut down the LFB by changing the value of AdminStatus. the default value is 'Down' 🔴. this component is defined as an alias of the AdminStatus component in the EtherMACIn LFB. that means an EtherMACOut LFB usually coexists with an EtherMACIn LFB, and both share the same administrative status management by the CE 🤝. alias properties, as defined in the ForCES FE model [RFC5812], are used by the CE to declare the target component the alias refers to. that includes the target LFB class and instance IDs, as well as the path to the target component 🗺️.
the MTU component defines the maximum transmission unit 📏.
the optional TxFlowControl component defines whether or not the LFB is performing flow control on sending packets. the default value is 'false'. this component is defined as an alias of the TxFlowControl component in the EtherMACIn LFB 📤.
the optional RxFlowControl component defines whether or not the LFB is performing flow control on receiving packets. the default value is 'false'. this component is defined as an alias of the RxFlowControl component in the EtherMACIn LFB 📥.
a struct component, MACOutStats, defines a set of statistics for this LFB, including the number of transmitted packets and the number of dropped packets. this statistics component is optional to implementers 📊.
5.1.5.3. Capabilities 🌈
this LFB does not have a list of capabilities.
5.1.5.4. Events 💤
this LFB does not have any events specified.
5.2. IP Packet Validation LFBs 🛡️
the LFBs are defined to abstract the IP packet validation process 💖. an IPv4Validator LFB is specifically for IPv4 protocol validation, and an IPv6Validator LFB is specifically for IPv6 ✨.
5.2.1. IPv4Validator 🔍
the IPv4Validator LFB performs IPv4 packet validation 🫶.
5.2.1.1. Data Handling 💖
okay so this LFB is the bouncer for IPv4 packets 💅 It does IPv4 validation according to [RFC1812] and its updates. Then the packet gets sent out the right port, depending on whether it's unicast or multicast, or whether it hit an exception or failed validation. ✨
It always expects packets that an upstream LFB, like an EtherClassifier LFB, has already marked as IPv4 packets 🦋 There's no specific metadata it needs on input, so no extra paperwork, bestie 🎀
There are four output LFB ports total 🌸
All validated IPv4 unicast packets go out the singleton port called IPv4UnicastOut. All validated IPv4 multicast packets go out the singleton port called IPv4MulticastOut port.
Then there's the ExceptionOut singleton port, for packets that were validated as exception packets. An exception ID metadata gets produced to say what caused it 🧚 An exception is when a packet needs extra processing before it can be normally forwarded. The currently defined exception types are:
- Packet with expired TTL
- Packet with header length more than 5 words
- Packet IP head including router alert options
- Packet with exceptional source address
- Packet with exceptional destination address
Quick aside: even though this LFB checks Time to Live (TTL) for validity, operations like TTL decrement are done by the downstream forwarding LFB. So this one just checks, it doesn't decrement 🙈
The last singleton port is FailOut, and it's for every packet with errors that failed validation 💀 An error is when a packet can't be processed or forwarded any further without getting dropped. Every error gets an error ID that tells you the failure reason. The currently defined failure reasons are:
- Packet with size reported less than 20 bytes
- Packet with version not IPv4
- Packet with header length less than 5 words
- Packet with total length field less than 20 bytes
- Packet with invalid checksum
- Packet with invalid source address
- Packet with invalid destination address
5.2.1.2. Components 🎀
This LFB has only one struct component, the IPv4ValidatorStatisticsType. It's a set of stats for the validation process, tracking things like the number of bad header packets, the number of bad total length packets, the number of bad TTL packets, and the number of bad checksum packets 📊 This statistics component is optional for implementers, so it's totally your call 💜
5.2.1.3. Capabilities 🌈
This LFB does not have a list of capabilities.
5.2.1.4. Events 🌸
This LFB does not have any events specified.
5.2.2. IPv6Validator 🦋
The IPv6Validator LFB performs IPv6 packet validation. It's giving sibling energy to IPv4Validator, just for IPv6 ✨
5.2.2.1. Data Handling 💅
This LFB performs IPv6 validation according to [RFC2460] and its updates. Then the IPv6 packet gets output to the matching port based on the validation result. It tells you whether the packet is unicast or multicast, whether an exception happened, or whether validation failed 🫶
It always expects packets that an upstream LFB, like an EtherClassifier LFB, has already indicated as IPv6 packets. No specific metadata is expected on input, same as before 🌷
Similar to the IPv4validator LFB, the IPv6Validator LFB also defines four output ports to emit packets with the different validation results 🔥
All validated IPv6 unicast packets go out the singleton port called IPv6UnicastOut. All validated IPv6 multicast packets go out the singleton port called IPv6MulticastOut. No metadata is produced at this LFB 🍓
The ExceptionOut singleton port outputs packets that were validated as exception packets. An exception is when a packet needs further processing before it can be normally forwarded. An exception ID metadata is produced to indicate what caused it. The currently defined exception types are:
- Packet with hop limit to zero
- Packet with next header set to hop-by-hop
- Packet with exceptional source address
- Packet with exceptional destination address
The final singleton port is FailOut, for all packets that have errors and failed validation 💀 An error case is when a packet can't be processed or forwarded without getting dropped. A validate error ID is associated with every failed packet to indicate the reason. The currently defined reasons are:
- Packet with size reported less than 40 bytes
- Packet with version not IPv6
- Packet with invalid source address
- Packet with invalid destination address
Note: in the base type library, the definitions for exception ID and validate error ID metadata are applied to both the IPv4Validator and IPv6Validator LFBs. So the two LFBs share the same metadata definition, just with different ID assignments inside 🧩
5.2.2.2. Components 💜
This LFB has only one struct component, the IPv6ValidatorStatisticsType. It's a set of statistics for the validation process, including the number of bad header packets, the number of bad total length packets, and the number of bad hop limit packets. This component is optional for implementers too 🌈
5.2.2.3. Capabilities 🎀
This LFB does not have a list of capabilities.
5.2.2.4. Events ✨
This LFB does not have any events specified.
5.3. IP Forwarding LFBs 🧚
IP Forwarding LFBs exist to abstract the IP forwarding processes 🦋 As definitions for a base LFB library, this document only restricts its LFB definition scope to IP unicast forwarding. IP multicast may be defined in future documents, so stay tuned 👀
Two fundamental tasks happen in IP unicast forwarding. First, you look up the forwarding information table to find next-hop information. Then you use those next-hop details to forward packets out on specific physical output ports 💅 This document models forwarding by abstracting out those two steps. The LFB models are modular, but there may be multiple ways to implement the abstracted models. It is not intended or expected that the provided LFB models constrain implementations, so you have freedom, bestie 🌸
Based on the IP forwarding abstraction, two kinds of typical IP unicast forwarding LFBs are defined: the unicast LPM lookup LFB and the next-hop application LFB. They're further distinguished by IPv4 and IPv6 protocols 🫶
5.3.1. IPv4UcastLPM 💖
The IPv4UcastLPM LFB abstracts the IPv4 unicast Longest Prefix Match (LPM) process ✨
This LFB also provides facilities to support users who want to implement equal-cost multipath (ECMP) routing or reverse path forwarding (RPF). However, this LFB itself does not provide ECMP or RPF. To fully implement ECMP or RPF, you'll need additional specific LFBs, like a specific ECMP LFB or an RPF LFB, which will have to be defined 🔥
5.3.1.1. Data Handling 🍓
This LFB performs the IPv4 unicast LPM table lookup. It always expects IPv4 unicast packets from one singleton input known as "PktsIn". Then the LFB uses the destination IPv4 address of every packet as a search key to look up the IPv4 prefix table and generate a hop selector as the matching result 🔍 The hop selector is passed as packet metadata to downstream LFBs, and it will usually be used there as a search index to find more next-hop information 🧭
Three singleton output LFB ports are defined.
The first singleton output is known as "NormalOut". It outputs IPv4 unicast packets that succeed the LPM lookup (and got a hop selector). The hop selector is associated with the packet as metadata. Downstream from the LPM LFB is usually a next-hop application LFB, like an IPv4NextHop LFB 💜
The second singleton output is known as "ECMPOut", and it's defined to provide support for users who want to implement ECMP 🌈
An ECMP flag is defined in the LPM table to let the LFB support ECMP. When a table entry is created with the flag set to true, it means that table entry is for ECMP only. A packet that has passed through this prefix lookup will always output from the "ECMPOut" output port, with the hop selector being its lookup result. The output will usually go directly to a downstream ECMP processing LFB, where the hop selector can usually further generate optimized one or multiple next-hop routes by use of ECMP algorithms 🎀
A default route flag is defined in the LPM table to let the LFB support a default route as well as loose RPF. When this flag is set to true, the table entry is identified as a default route, which also implies that the route is forbidden for RPF. If a user wants to implement RPF on FE, a specific RPF LFB will have to be defined. In such an RPF LFB, a component can be defined as an alias of the prefix table component of this LFB, as described below 🦋
The final singleton output is known as "ExceptionOut" of the IPv4UcastLPM LFB. It outputs exception packets after the LFB processing, along with an ExceptionID metadata to indicate what caused the exception. The currently defined exception type is:
- The packet failed the LPM lookup of the prefix table.
The upstream LFB of this LFB is usually an IPv4Validator LFB. If RPF is to be adopted, the upstream can be an RPF LFB, when defined. The downstream LFB is usually an IPv4NextHop LFB. If ECMP is adopted, the downstream can be an ECMP LFB, when defined 🧩
5.3.1.2. Components 🌸
This LFB has two components.
The IPv4PrefixTable component is defined as an array component of the LFB. Each row of the array contains an IPv4 address, a prefix length, a hop selector, an ECMP flag, and a default route flag. The LFB uses the destination IPv4 address of every input packet as a search key to look up this table in order extract a next-hop selector. The ECMP flag is for the LFB to support ECMP. The default route flag is for the LFB to support a default route and for loose RPF 🍓
The IPv4UcastLPMStats component is a struct component that collects statistics information, including the total number of input packets received, the IPv4 packets forwarded by this LFB, and the number of IP datagrams discarded due to no route found. This component is defined as optional to implementers 💜
5.3.1.3. Capabilities ✨
This LFB does not have a list of capabilities.
5.3.1.4. Events 🎀
This LFB does not have any events specified.
5.3.2. IPv4NextHop 🦋
This LFB abstracts the process of selecting an IPv4 next-hop action 💖
5.3.2.1. Data Handling
okay so this LFB is the one that turns next-hop info into something you can actually use on IPv4 packets 🦋 it gets an IPv4 packet with a next-hop identifier called HopSelector, then uses that as a table index to look up a next-hop table and find the right LFB output port ✨
the LFB is expected to get unicast IPv4 packets through one singleton input called PktsIn, plus a HopSelector metadata that's used as the table index for the NextHop table 💅 the data processing does the forwarding TTL decrement and the IP checksum recalculation, so the packet is fresh and ready to go 🔥
there are two output LFB ports defined 🎀
the first one is a group output port called SuccessOut 💖 when processing succeeds, the packet goes out from one LFB port inside that port group, and which one is picked by the LFBOutputSelectIndex value of the matched table entry 😭 the packet heads to a downstream LFB with the L3PortID and MediaEncapInfoIndex metadata attached 🫶
the second one is a singleton output port called ExceptionOut 🙈 it outputs packets where the data processing failed, along with an extra ExceptionID metadata that tells you what went wrong. the currently defined exception types are:
- The
HopSelectorfor the packet is invalid. - The packet failed lookup of the next-hop table even though the
HopSelectoris valid. - The MTU for outgoing interface is less than the packet size.
downstream LFB instances could be a BasicMetadataDispatch type (Section 5.5.1), which fans packets out to different LFB instances, or a media-encapsulation-related type, like an EtherEncap type or a RedirectOut type (Section 5.4.2) 🌈 for example, if you've got Ethernet and some other tunnel encapsulation going on, a BasicMetadataDispatch LFB can use the L3PortID metadata (Section 5.3.2.2) to send packets to the right encapsulator. it's giving organized traffic cop energy 🚦👑
5.3.2.2. Components
this LFB has just one component, IPv4NextHopTable, and it's defined as an array 🧚 the HopSelector gets used to match the array index of IPv4NextHopTable, which finds the row that holds the next-hop info result. every row of the array is a struct containing:
L3PortID, the ID of the logical output port that gets passed on to the downstream LFB instance. this ID tells you what kind of encapsulating port the neighbor should use. it's L3-derived info that affects L2 processing, so it needs to travel from one LFB to another as metadata 💜 usually the next-hop LFB uses this ID to tell apart packets that need different L2 encapsulation. for instance, some packets might need general Ethernet encapsulation while others need various tunnel encapsulations. in that case, differentL3PortIDs get assigned and passed downstream as metadata. aBasicMetadataDispatchLFB (Section 5.5.1) may have to sit downstream so it can dispatch packets to different encapsulation LFB instances based on theL3PortIDs 🍓MTU, the Maximum Transmission Unit for the outgoing port 📏NextHopIPAddr, the IPv4 next-hop address 📍MediaEncapInfoIndex, the index that gets passed on to the downstream encapsulation LFB instance. that LFB uses it as a search key to look up a table (usually media-encapsulation-related) for more encapsulation info. the search key matches the table index. heads up that the encapsulation LFB using this metadata might not be the one right after this LFB in processing 👀 theMediaEncapInfoIndexgets attached here and rides along through intermediate LFBs until the encapsulation LFB uses it. in some cases, depending on implementation, the CE may set theMediaEncapInfoIndexpassed downstream to a value that will fail lookup when it reaches the target encapsulation LFB. a lookup failure at that point is a sign that further resolution is needed. for an example of this approach, check Section 7.2, which discusses ARP and mentions it 🔍LFBOutputSelectIndex, the LFB group output port index used to pick the downstream LFB port. this value identifies the specific port within theSuccessOutport group where packets that successfully use this next-hop entry get sent out 🚀
5.3.2.3. Capabilities
this LFB does not have a list of capabilities 🤷♀️
5.3.2.4. Events
this LFB does not have any events specified 🌸
5.3.3. IPv6UcastLPM
the IPv6UcastLPM LFB abstracts the IPv6 unicast Longest Prefix Match (LPM) process 💅 it's basically the IPv4UcastLPM LFB, except every IP address here means an IPv6 address ✨
this LFB also gives users the tools to build equal-cost multipath (ECMP) routing or reverse path forwarding (RPF) 🛤️ BUT, and this is important, the LFB itself does NOT do ECMP or RPF on its own 😤 to fully implement either one, you'd need additional specific LFBs, like a specific ECMP LFB or an RPF LFB. that work may happen in future versions of this document 🔮
5.3.3.1. Data Handling
this LFB does the IPv6 unicast LPM table lookup 🔎 it always expects IPv6 unicast packets from one singleton input called PktsIn. the destination IPv6 address of an incoming packet gets used as a search key to look up the IPv6 prefix table and generate a hop selector. that hop selector result gets attached to the packet as metadata and sent downstream, where it's usually used as a search key to find more next-hop info 🫶
three singleton output LFB ports are defined 🎀
the first singleton output is called NormalOut. it outputs IPv6 unicast packets that succeed the LPM lookup (and got a hop selector), with the hop selector attached as metadata. downstream from the LPM LFB is usually a next-hop application LFB, like an IPv6NextHop LFB 🦋
the second singleton output is called ECMPOut, and it's there to support users who want to implement ECMP 💜
an ECMP flag is defined in the LPM table so the LFB can support ECMP. when a table entry is created with this flag set to true, it means that entry is for ECMP only 🌈 a packet that has passed this prefix lookup always comes out of the ECMPOut output port, with the hop selector as its lookup result. the output usually goes straight to a downstream ECMP processing LFB, where the hop selector can further generate optimized one or multiple next-hop routes using ECMP algorithms 🧮
a default route flag is defined in the LPM table so the LFB can support a default route as well as loose RPF 🌍 when this flag is set to true, the table entry is identified as a default route, which also implies that the route is forbidden for RPF 🚫
if a user wants to implement RPF on FE, a specific RPF LFB will have to be defined 🛠️ in that RPF LFB, a component can be defined as an alias of the prefix table component of this LFB, as described below ✨
the final singleton output is called ExceptionOut. it outputs exception packets after LFB processing, along with an ExceptionID metadata that tells you what caused the exception 😭 the currently defined exception types are:
- The packet failed the LPM lookup of the prefix table.
the upstream LFB of this LFB is usually an IPv6Validator LFB 🧁 if RPF is adopted, the upstream can be an RPF LFB, once one is defined 🔁
the downstream LFB is usually an IPv6NextHop LFB 💖 if ECMP is adopted, the downstream can be an ECMP LFB, once one is defined 🌟
5.3.3.2. Components
this LFB has two components 🧩
the IPv6PrefixTable component is defined as an array component of the LFB. each row of the array contains an IPv6 address, a prefix length, a hop selector, an ECMP flag, and a default route flag. the ECMP flag is there so the LFB can support ECMP, and the default route flag is there so the LFB can support a default route and loose RPF, as described earlier 💅
the IPv6UcastLPMStats component is a struct component that collects statistics, including the total number of input packets received, the IPv6 packets forwarded by this LFB, and the number of IP datagrams discarded due to no route found 📊 note that this component is defined as optional for implementers 🙈
5.3.3.3. Capabilities
this LFB does not have a list of capabilities 🤷♀️
5.3.3.4. Events
this LFB does not have any events specified 🌸
5.3.4. IPv6NextHop
this LFB abstracts the process of selecting the IPv6 next-hop action 🎯
5.3.4.1. Data Handling
the LFB abstracts the process of applying next-hop info to IPv6 packets 💫 it gets an IPv6 packet with a next-hop identifier (HopSelector) and uses that identifier to look up a next-hop table and find the right output port from the LFB 🦋
the LFB is expected to receive unicast IPv6 packets through one singleton input called PktsIn, along with a HopSelector metadata that's used as the table index for the next-hop table 🫶
two output LFB ports are defined 🎀
the first output is a group output port called SuccessOut. when processing succeeds, the packet goes out from an LFB port inside that port group, selected by the LFBOutputSelectIndex value of the matched table entry 🚀 the packet goes to a downstream LFB with the L3PortID and MediaEncapInfoIndex metadata attached 💜
the second output is a singleton output port called ExceptionOut, which outputs packets where the data processing failed, along with an extra ExceptionID metadata that says what caused the exception 😭 the currently defined exception types are:
- The
HopSelectorfor the packet is invalid. - The packet failed lookup of the next-hop table even though the
HopSelectoris valid. - The MTU for outgoing interface is less than the packet size.
downstream LFB instances could be a BasicMetadataDispatch type, which fans out to different LFB instances, or a media encapsulation related type, like an EtherEncap type or a RedirectOut type 🌈 for example, when the downstream LFB is BasicMetadataDispatch and Ethernet plus other tunnel encapsulation exist downstream from it, the BasicMetadataDispatch LFB can use the L3PortID metadata (see section below) to dispatch packets to the different encapsulator LFBs 🚦🧚
5.3.4.2. Components 💖
This LFB has only one component named IPv6NextHopTable, and it's defined as an array 🎀 The array index of IPv6NextHopTable is what a HopSelector uses to find a row of the table, which is the next-hop info 🦋 Each row of the array is a struct containing:
- The L3PortID, which is the ID of the logical output port that gets passed onto the downstream LFB instance 🌸 This ID tells you what kind of encapsulating port the neighbor should use 💅 It's L3-derived info that affects L2 processing, so it needs to be passed from one LFB to another as metadata ✨ Usually this ID is how the next-hop LFB tells packets apart when they need different L2 encapsulation 👑 Like, some packets might need plain old general Ethernet encapsulation while others need some flavor of tunnel encapsulation 🌈 In that case, different L3PortIDs get assigned to the packets and get passed as metadata to a downstream LFB 🧚 A BasicMetadataDispatch LFB (Section 5.5.1) may have to be applied as the downstream LFB so it can dispatch packets to different encapsulation LFB instances according to the L3PortIDs 💜
- MTU, the Maximum Transmission Unit for the outgoing port 🍓
- NextHopIPAddr, the IPv6 next-hop address 🫶
- MediaEncapInfoIndex, the index that gets passed on to the downstream encapsulation LFB instance, where it's used as a search key to look up a table (usually media-encapsulation-related) for more encapsulation info 💖 The search key looks up the table by matching the table index 🔥 Note that the encapsulation LFB instance that uses this metadata might not be the one that comes right after this LFB in processing 😭 The MediaEncapInfoIndex metadata gets attached here and then sails through intermediate LFBs until the encapsulation LFB instance finally uses it 🦋 In some cases, depending on the implementation, the CE may set the MediaEncapInfoIndex passed downstream to a value that will fail the lookup when it reaches a target encapsulation LFB 💀 Such a lookup failure at that point is an indication that further resolution is needed 🙈 For an example of this approach, check out Section 7.2, which discusses ARP and mentions this approach 🎀
- LFBOutputSelectIndex, the LFB group output port index used to select the downstream LFB port 🌷 This value identifies the specific port within the SuccessOut port group that packets successfully using this next-hop entry get sent out of 👑
5.3.4.3. Capabilities
This LFB does not have a list of capabilities 🫧
5.3.4.4. Events
This LFB does not have any events specified 🌙
5.4. Redirect LFBs 🎀
Redirect LFBs abstract the data packet transportation process between the CE and FE 💅 Some packets output from some LFBs may have to be delivered to the CE for further processing, and some packets generated by the CE may have to be delivered to the FE and then on to some specific LFBs for data path processing 🦋 According to [RFC5810], data packets and their associated metadata get encapsulated in a ForCES redirect message for transport between CE and FE ✨ We define two LFBs to abstract the process: a RedirectIn LFB and a RedirectOut LFB 💖 Usually, in an LFB topology of an FE, only one RedirectIn LFB instance and one RedirectOut LFB instance exist 🌸
5.4.1. RedirectIn 🧚
The RedirectIn LFB abstracts the process for the CE to inject data packets into the FE data path 💜
5.4.1.1. Data Handling 🌈
A RedirectIn LFB abstracts the process for the CE to inject data packets into the FE LFB topology, so the packets can enter the FE data paths 🫶 From the LFB topology's point of view, the RedirectIn LFB acts as a source point for data packets coming from the CE, so it's defined with a single output LFB port and no input LFB port 💅
The single output port of RedirectIn LFB is defined as a group output type named "PktsOut" 🎀 Packets produced by this output can have arbitrary frame types, decided by the CE that generated them 🦋 Possible frames may include IPv4, IPv6, or ARP protocol packets 🌷 The CE may associate some metadata to indicate the frame types, and may also associate other metadata with various info about the packets ✨ Among them, there MUST exist a RedirectIndex metadata, which is an integer acting as an index 💖 When the CE transmits the metadata along with the packet to a RedirectIn LFB, the LFB reads the RedirectIndex metadata and outputs the packet to one of its group output port instances, whose port index is indicated by this metadata 👑 Any other metadata, in addition to RedirectIndex, gets passed untouched along with the packet to the downstream LFB 🌈 This means the RedirectIndex metadata from the CE gets "consumed" by the RedirectIn LFB and is not passed to the downstream LFB 🧚 Note that a packet from the CE without a RedirectIndex metadata associated will be dropped by the LFB 💀 Also, all metadata visible to the LFB needs to be global and IANA controlled 🫧 See Section 8 ("IANA Considerations") of this document for more details about a metadata ID space that can be used by vendors and is "Reserved for Private Use" 💜
5.4.1.2. Components 🌸
An optional statistics component is defined to collect the number of packets received by the LFB from the CE 🍓 There are no other components defined for the current version of the LFB 🦋
5.4.1.3. Capabilities 💅
This LFB does not have a list of capabilities 🌙
5.4.1.4. Events ✨
This LFB does not have any events specified 🫶
5.4.2. RedirectOut 🎀
RedirectOut LFB abstracts the process for LFBs in the FE to deliver data packets to the CE 💖
5.4.2.1. Data Handling 🦋
A RedirectOut LFB abstracts the process for LFBs in the FE to deliver data packets to the CE 🌸 From the LFB topology's point of view, the RedirectOut LFB acts as a sink point for data packets going to the CE, so it's defined with a single input LFB port and no output LFB port 🧚
The RedirectOut LFB has only one singleton input, known as "PktsIn", but it's capable of receiving packets from multiple LFBs by multiplexing this input 💜 The input expects any kind of frame type, so the frame type is specified as arbitrary, and all types of metadata are expected 🌈 All associated metadata produced (but not consumed) by previously processed LFBs should be delivered to the CE via the ForCES protocol redirect message [RFC5810] 💅 The CE can decide how to process the redirected packet by referencing the associated metadata ✨ As an example, a packet could be redirected by the FE to the CE because the EtherEncap LFB isn't able to resolve L2 information 😭 The metadata "ExceptionID" created by the EtherEncap LFB is passed along with the packet and should be sufficient for the CE to do the necessary processing and resolve the L2 entry required 🔥 Note that all metadata visible to the LFB needs to be global and IANA controlled 🌷 See Section 8 ("IANA Considerations") of this document for more details about a metadata ID space that can be used by vendors and is "Reserved for Private Use" 🫧
5.4.2.2. Components 💖
An optional statistics component is defined to collect the number of packets sent by the LFB to the CE 🎀 There are no other components defined for the current version of the LFB 🌙
5.4.2.3. Capabilities 🦋
This LFB does not have a list of capabilities 🧚
5.4.2.4. Events 🌸
This LFB does not have any events specified 💜
5.5. General Purpose LFBs ✨
5.5.1. BasicMetadataDispatch 💅
The BasicMetadataDispatch LFB is defined to abstract the process in which a packet is dispatched to some output path based on its associated metadata value 🫶
5.5.1.1. Data Handling 🌈
The BasicMetadataDispatch LFB has only one singleton input, known as "PktsIn" 🎀 Every input packet should be associated with a metadata that the LFB uses to do the dispatch 🦋 This LFB contains a metadata ID and a dispatch table named MetadataDispatchTable, both configured by the CE 💖 The metadata ID specifies which metadata is used for dispatching packets 👑 The MetadataDispatchTable contains entries of a metadata value and an OutputIndex, specifying that the packet with the metadata value must go out from the LFB group output port instance with the OutputIndex 🌸
Two output LFB ports are defined 🧚
The first output is a group output port known as "PktsOut" 💜 A packet whose associated metadata has found an OutputIndex by successfully looking up the dispatch table will be output to the group port instance with the corresponding index 🌈
The second output is a singleton output port known as "ExceptionOut", which outputs packets for which data processing failed, along with an additional ExceptionID metadata to indicate what caused the exception 😭 Currently defined exception types only include one case:
- There is no matching when looking up the metadata dispatch table 💀
As an example, if the CE decides to dispatch packets according to a physical port ID (PHYPortID), the CE may set the ID of PHYPortID metadata to the LFB first 🔥 Moreover, the CE also sets the PHYPortID actual values (the metadata values) and the assigned OutputIndex for those values in the dispatch table in the LFB 🫧 When a packet arrives, a PHYPortID metadata is found associated with the packet, and the metadata value is then used as a key to look up the dispatch table to find an output port instance for the packet 🙈
Currently, the BasicMetadataDispatch LFB only allows the metadata value of the dispatch table entry to be a 32-bit integer 🍓 A metadata with other value types is not supported in this version 🌙 A more complex metadata dispatch LFB may be defined in future versions of the library 🎀 In that LFB, multiple tuples of metadata with more value types supported may be used to dispatch packets 🦋
5.5.1.2. Components 💅
This LFB has two components 🌷 One component is MetadataID and the other is MetadataDispatchTable 🫶 Each row entry of the dispatch table is a struct containing the metadata value and the OutputIndex 💖 Note that currently, the metadata value is only allowed to be a 32-bit integer 👑 The metadata value is also defined as a content key for the table 🧚 The concept of content key is a searching key for tables, which is defined in the ForCES FE model [RFC5812] 🌈 With the content key, the CE can manipulate the table by means of a specific metadata value rather than by the table index only 🫧 See the ForCES FE model [RFC5812] and also the ForCES protocol [RFC5810] for more details on the definition and use of a content key 💜
5.5.1.3. Capabilities 🌸
This LFB does not have a list of capabilities 🍓
5.5.1.4. Events ✨
This LFB does not have any events specified 🎀
5.5.2. GenericScheduler 🦋
This is a preliminary generic scheduler LFB for abstracting a simple scheduling process 💅
5.5.2.1. Data Handling 💖
okay so there are LOTS of scheduling strategies out there, each with its own implementation 🧚 this document only defines a preliminary generic scheduler LFB as a base library, so it can handle a simple scheduling process. ✨ if you want something fancier, you can build on it by "inheritance", as described in [RFC5812]. it's giving building blocks 🧱
packets of any frame type come in through a group input called "PktsIn", and no extra metadata is expected 🌸 this group input can have multiple input port instances, and each one can be wired to a different upstream LFB output. inside the LFB, every input port instance is treated as being connected to its own queue. the queue gets a queue ID that is exactly the same as the index of its matching group input port instance (iconic index-matching behavior 🔥). scheduling disciplines get applied to all the queues AND all the packets inside them 💅
now the CE needs to know how many queues it can actually use, right? that's where the group input port property PortGroupLimits comes in. it lives in ObjectLFB and is defined by the ForCES FE model [RFC5810]. it lets the CE ask how many total queues the scheduler supports, so the CE can then decide how many queues it may use for a given scheduling app 🦋
the scheduled packets leave through a singleton output port called "PktsOut", and there's no corresponding metadata attached to them 🍓
and the glow-up part: more complex scheduler LFBs can be made by succeeding this one and adding fancier scheduling disciplines. for example, a priority scheduler LFB could inherit from this LFB and define a component that sets priorities for all the input queues. main character energy 👑
5.5.2.2. Components 🎀
the SchedulingDiscipline component is how the CE tells the LFB which scheduling discipline to use. right now the only one defined is Round Robin (RR), so RR is the default discipline 💜
the QueueStats component lets the CE check the status of every queue in the scheduler 👀 it's an array component, and each row is a struct containing a queue ID. right now the defined queue status info is the queue depth in packets and the queue depth in bytes. the CE can use the queue ID as the index, so it can look up every queue and ask how much it's using, in packets or bytes. one tiny note, though: QueueStats is optional for implementers to support 🙈
5.5.2.3. Capabilities ✨
the following capability is currently defined for the GenericScheduler:
- the queue length limit, which gives every queue its storage room 📦
5.5.2.4. Events 🌈
this LFB has no events specified, so there's nothing extra to track here 🫶
6. XML for LFB Library 🎀
okay here's the XML for the LFB library, bestie 💖
<?xml version="1.0" encoding="UTF-8"?>
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
provides="BaseLFBLibrary">
<load library="BaseTypeLibrary"/>
<LFBClassDefs>
<LFBClassDef LFBClassID="3">
<name>EtherPHYCop</name>
<synopsis>
The EtherPHYCop LFB describes an Ethernet interface
that limits the physical media to copper.
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>EtherPHYIn</name>
<synopsis>
The input port of the EtherPHYCop LFB. It expects any
type of Ethernet frame.
</synopsis>
<expectation>
<frameExpected>
<ref>EthernetAll</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort>
<name>EtherPHYOut</name>
<synopsis>
The output port of the EtherPHYCop LFB. The output
packet has the same Ethernet frame type as the
input packet, associated with a metadata indicating
the ID of the physical port.
</synopsis>
<product>
<frameProduced>
<ref>EthernetAll</ref>
</frameProduced>
<metadataProduced>
<ref>PHYPortID</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1" access="read-only">
<name>PHYPortID</name>
<synopsis>
The identification of the physical port
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2" access="read-write">
<name>AdminStatus</name>
<synopsis>
The port status administratively requested
</synopsis>
<typeRef>PortStatusType</typeRef>
<defaultValue>2</defaultValue>
</component>
<component componentID="3" access="read-only">
<name>OperStatus</name>
<synopsis>
The port actual operational status
</synopsis>
<typeRef>PortStatusType</typeRef>
</component>
<component componentID="4" access="read-write">
<name>AdminLinkSpeed</name>
<synopsis>
The port link speed administratively requestedokay the XML is giving a whole vibe 💅 here's the next chunk 🎀
</synopsis>
<typeRef>LANSpeedType</typeRef>
<defaultValue>LAN_SPEED_AUTO</defaultValue>
</component>
<component componentID="5" access="read-only">
<name>OperLinkSpeed</name>
<synopsis>
The port actual operational link speed
</synopsis>
<typeRef>LANSpeedType</typeRef>
</component>
<component componentID="6" access="read-write">
<name>AdminDuplexMode</name>
<synopsis>
The port duplex mode administratively requested
</synopsis>
<typeRef>DuplexType</typeRef>
<defaultValue>Auto</defaultValue>
</component>
<component componentID="7" access="read-only">
<name>OperDuplexMode</name>
<synopsis>
The port actual operational duplex mode
</synopsis>
<typeRef>DuplexType</typeRef>
</component>
<component componentID="8" access="read-only">
<name>CarrierStatus</name>
<synopsis>The carrier status of the port </synopsis>
<typeRef>boolean</typeRef>
<defaultValue>false</defaultValue>
</component>
</components>
<capabilities>
<capability componentID="30">
<name>SupportedLinkSpeed</name>
<synopsis>
A list of link speeds the port supports
</synopsis>
<array>
<typeRef>LANSpeedType</typeRef>
</array>
</capability>
<capability componentID="31">
<name>SupportedDuplexMode</name>
<synopsis>
A list of duplex modes the port supports
</synopsis>
<array>
<typeRef>DuplexType</typeRef>
</array>
</capability>
</capabilities>
<events baseID="60">
<event eventID="1">
<name>PHYPortStatusChanged</name>
<synopsis>
An event reporting change on operational status of the
physical port.
</synopsis>
<eventTarget>
<eventField>OperStatus</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>OperStatus</eventField>
</eventReport>
</eventReports>
</event>
<event eventID="2">
<name>LinkSpeedChanged</name>
<synopsis>
An event reporting change on operational link speed
of the physical port.
</synopsis>
<eventTarget>
<eventField>OperLinkSpeed</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>OperLinkSpeed</eventField>
</eventReport>
</eventReports>
</event>
<event eventID="3">
<name>DuplexModeChanged</name>
<synopsis>
An event reporting change on operational duplex mode
of the physical port.
</synopsis>
<eventTarget>
<eventField>OperDuplexMode</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>OperDuplexMode</eventField>
</eventReport>
</eventReports>
</event>
</events>
</LFBClassDef>
<LFBClassDef LFBClassID="4">
<name>EtherMACIn</name>
<synopsis>
EtherMACIn LFB describes an Ethernet port at MAC data link
layer. The LFB describes Ethernet processing functions
of MAC address locality check, deciding if the Ethernet
packets should be bridged, providing Ethernet-layer flow
control, etc.
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort group="false">
<name>EtherPktsIn</name>
<synopsis>
The input port of the EtherMACIn LFB. It expects any
type of Ethernet frame.
</synopsis>
<expectation>
<frameExpected>
<ref>EthernetAll</ref>
</frameExpected>
<metadataExpected>
<ref>PHYPortID</ref>
</metadataExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort group="false">
<name>NormalPathOut</name>
<synopsis>
An output port in the EtherMACIn LFB. It outputs
Ethernet packets to downstream LFBs for normal
processing like Ethernet packet classification and
other L3 IP-layer processing.
</synopsis>
<product>
<frameProduced>
<ref>EthernetAll</ref>
</frameProduced>
<metadataProduced>
<ref>PHYPortID</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort>
<name>L2BridgingPathOut</name>
<synopsis>
An output port in
the EtherMACIn LFB. It outputs Ethernet packets
to downstream LFBs for layer 2 bridging processing.
The port is switched on or off by the
L2BridgingPathEnable flag in the LFB.
</synopsis>
<product>
<frameProduced>
<ref>EthernetAll</ref>
</frameProduced>
<metadataProduced>
<ref>PHYPortID</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1" access="read-write">
<name>AdminStatus</name>
<synopsis>
The LFB status administratively requested, which has
the same data type with a port status. Default is in
'Down' status.
</synopsis>
<typeRef>PortStatusType</typeRef>
<defaultValue>2</defaultValue>
</component>
<component componentID="2" access="read-write">
<name>LocalMACAddresses</name>
<synopsis>
Local MAC address(es) of the Ethernet port the LFB
represents.
</synopsis>
<array>
<typeRef>IEEEMAC</typeRef>
</array>
</component>
<component componentID="3" access="read-write">
<name>L2BridgingPathEnable</name>
<synopsis>
A flag indicating if the LFB L2 BridgingPath output
port is enabled or not. Default is not enabled.
</synopsis>
<typeRef>boolean</typeRef>
<defaultValue>false</defaultValue>
</component>
<component componentID="4" access="read-write">
<name>PromiscuousMode</name>
<synopsis>
A flag indicating whether the LFB is in promiscuous
mode or not. Default is not.
</synopsis>
<typeRef>boolean</typeRef>
<defaultValue>false</defaultValue>
</component>
<component componentID="5" access="read-write">
<name>TxFlowControl</name>
<synopsis>
A flag indicating whether transmit flow control is
applied or not. Default is not.
</synopsis>
<optional/>
<typeRef>boolean</typeRef>
<defaultValue>false</defaultValue>
</component>
<component componentID="6" access="read-write">
<name>RxFlowControl</name>
<synopsis>
A flag indicating whether receive flow control is
applied or not. Default is not.
</synopsis>
<optional/>
<typeRef>boolean</typeRef>
<defaultValue>false</defaultValue>
</component>
<component componentID="7" access="read-reset">
<name>MACInStats</name>
<synopsis>
The statistics of the EtherMACIn LFB
</synopsis>
<optional/>
<typeRef>MACInStatsType</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="5">
<name>EtherClassifier</name>
<synopsis>
EtherClassifier LFB describes the process to decapsulate
Ethernet packets and then classify them into various
network-layer packets according to information in the
Ethernet headers. It is expected the LFB classifies packets
by packet types like IPv4, IPv6, MPLS, ARP, ND, etc.
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>EtherPktsIn</name>
<synopsis>
Input port of Ethernet packets. PHYPortID metadata is
always expected while LogicalPortID metadata is
optionally expected to associate with every input
Ethernet packet.
</synopsis>
<expectation>
<frameExpected>
<ref>EthernetAll</ref>
</frameExpected>
<metadataExpected>
<ref>PHYPortID</ref>
<ref dependency="optional" defaultValue="0">
LogicalPortID</ref>
</metadataExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort group="true">
<name>ClassifyOut</name>
<synopsis>
A group port for output of Ethernet classifying
results.
</synopsis>
<product>
<frameProduced>
<ref>Arbitrary</ref>
</frameProduced>
<metadataProduced>
<ref>PHYPortID</ref>
<ref>SrcMAC</ref>
<ref>DstMAC</ref>
<ref>EtherType</ref>
<ref availability="conditional">VlanID</ref>
<ref availability="conditional">VlanPriority</ref>
</metadataProduced>
</product>okay the ExceptionOut port is lowkey the hero of this section 💅 anything that fails classifying gets sent there with an ExceptionID 🫶
</outputPort>
<outputPort group="false">
<name>ExceptionOut</name>
<synopsis>
A singleton port for output of all Ethernet packets
that fail the classifying process. An ExceptionID
metadata indicates the failure reason.
</synopsis>
<product>
<frameProduced>
<ref>Arbitrary</ref>
</frameProduced>
<metadataProduced>
<ref>ExceptionID</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component access="read-write" componentID="1">
<name>EtherDispatchTable</name>
<synopsis>
An EtherDispatchTable array component that is defined
in the LFB to dispatch every Ethernet packet to output
ports according to logical port ID assigned by the
VlanInputTable in the LFB and Ethernet type in the
Ethernet packet header.
</synopsis>
<typeRef>EtherDispatchTableType</typeRef>
</component>
<component access="read-write" componentID="2">
<name>VlanInputTable</name>
<synopsis>
A VlanInputTable array component that is defined in
the LFB to classify VLAN Ethernet packets. Every input
packet is assigned with a new LogicalPortID according
to the packet's incoming port ID and VLAN ID.
</synopsis>
<typeRef>VlanInputTableType</typeRef>
</component>
<component access="read-reset" componentID="3">
<name>EtherClassifyStats</name>
<synopsis>
A table recording statistics on the Ethernet
classifying process in the LFB.
</synopsis>
<optional/>
<typeRef>EtherClassifyStatsTableType</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="6">
<name>EtherEncap</name>
<synopsis>
The EtherEncap LFB abstracts the process of encapsulating
Ethernet headers onto received packets. The encapsulation
is based on passed metadata.
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort group="false">
<name>EncapIn</name>
<synopsis>
An input port receiving IPv4 and/or IPv6 packets for
encapsulation. A MediaEncapInfoIndex metadata is
expected, and a VLAN priority metadata is optionally
expected with every input packet.
</synopsis>
<expectation>
<frameExpected>
<ref>IPv4</ref>
<ref>IPv6</ref>
</frameExpected>
<metadataExpected>
<ref>MediaEncapInfoIndex</ref>
<ref dependency="optional" defaultValue="0">
VlanPriority</ref>
</metadataExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort group="false">
<name>SuccessOut</name>
<synopsis>
An output port for packets that have found Ethernet
L2 information and have been successfully encapsulated
into an Ethernet packet. An L2PortID metadata is
produced for every output packet.
</synopsis>
<product>
<frameProduced>
<ref>IPv4</ref>
<ref>IPv6</ref>
</frameProduced>
<metadataProduced>
<ref>L2PortID</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort group="false">
<name>ExceptionOut</name>
<synopsis>
An output port for packets that fail encapsulation
in the LFB. An ExceptionID metadata indicates failure
reason.
</synopsis>
<product>
<frameProduced>
<ref>IPv4</ref>
<ref>IPv6</ref>
</frameProduced>
<metadataProduced>
<ref>ExceptionID</ref>
<ref>MediaEncapInfoIndex</ref>
<ref availability="conditional">VlanPriority</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1" access="read-write">
<name>EncapTable</name>
<synopsis>
An array table for Ethernet encapsulation information
lookup. Each row of the array contains destination MAC
address, source MAC address, VLAN ID, and output
logical L2 port ID.
</synopsis>
<typeRef>EncapTableType</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="7">
<name>EtherMACOut</name>
<synopsis>
EtherMACOut LFB abstracts an Ethernet port at MAC data link
layer. It specifically describes Ethernet packet process
for output to physical port. A downstream LFB is usually
an Ethernet physical LFB like EtherPHYCop LFB. Note that
Ethernet output functions are closely related to Ethernet
input functions; therefore, some components defined in this
LFB are aliases of EtherMACIn LFB components.
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort group="false">
<name>EtherPktsIn</name>
<synopsis>
The input port of the EtherMACOut LFB. It expects
any type of Ethernet frame.
</synopsis>
<expectation>
<frameExpected>
<ref>EthernetAll</ref>
</frameExpected>
<metadataExpected>
<ref>PHYPortID</ref>
</metadataExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort group="false">
<name>EtherPktsOut</name>
<synopsis>
A port to output all Ethernet packets, each with a
metadata indicating the ID of the physical port
that the packet is to go through.
</synopsis>
<product>
<frameProduced>
<ref>EthernetAll</ref>
</frameProduced>
<metadataProduced>
<ref>PHYPortID</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1" access="read-write">
<name>AdminStatus</name>
<synopsis>
The LFB status administratively requested, which has
the same data type with a port status. The
component is defined as an alias of AdminStatus
component in EtherMACIn LFB.
</synopsis>
<alias>PortStatusType</alias>
</component>
<component componentID="2" access="read-write">
<name>MTU</name>
<synopsis>Maximum transmission unit (MTU) </synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3" access="read-write">
<name>TxFlowControl</name>
<synopsis>
A flag indicating whether transmit flow control is
applied, defined as an alias of TxFlowControl
component in EtherMACIn LFB.
</synopsis>
<optional/>
<alias>boolean</alias>
</component>
<component componentID="4" access="read-write">
<name>RxFlowControl</name>
<synopsis>
A flag indicating whether receive flow control is
applied, defined as an alias of RxFlowControl
component in EtherMACIn LFB.
</synopsis>
<optional/>
<alias>boolean</alias>
</component>
<component componentID="5" access="read-reset">
<name>MACOutStats</name>
<synopsis>
The statistics of the EtherMACOut LFB
</synopsis>
<optional/>
<typeRef>MACOutStatsType</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="8">
<name>IPv4Validator</name>
<synopsis>
This LFB performs IPv4 validation according to RFC 1812 and
its updates. The IPv4 packet will be output to the
corresponding LFB port, indicating whether the packet is
unicast or multicast or whether an exception has occurred
or the validation failed.
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>ValidatePktsIn</name>
<synopsis>Input port for data packets to be validated </synopsis> <expectation> <frameExpected> <ref>Arbitrary</ref> </frameExpected> </expectation> </inputPort> </inputPorts> <outputPorts> <outputPort> <name>IPv4UnicastOut</name> <synopsis> Output port for validated IPv4 unicast packets </synopsis> <product> <frameProduced> <ref>IPv4Unicast</ref> </frameProduced> </product> </outputPort> <outputPort> <name>IPv4MulticastOut</name> <synopsis> Output port for validated IPv4 multicast packets </synopsis> <product> <frameProduced> <ref>IPv4Multicast</ref> </frameProduced> </product> </outputPort> <outputPort> <name>ExceptionOut</name> <synopsis> Output port for all packets with exceptional cases when validating. An ExceptionID metadata indicates the exception case type. </synopsis> <product> <frameProduced> <ref>IPv4</ref> </frameProduced> <metadataProduced> <ref>ExceptionID</ref> </metadataProduced> </product> </outputPort> <outputPort> <name>FailOut</name> <synopsis> Output port for packets that failed validating process. A ValidateErrorID metadata indicates the error type or failure reason. </synopsis> <product> <frameProduced> <ref>IPv4</ref> </frameProduced> <metadataProduced> <ref>ValidateErrorID</ref> </metadataProduced> </product> </outputPort> </outputPorts> <components> <component access="read-write" componentID="1"> <name>IPv4ValidatorStats</name> <synopsis> The statistics information for validating process in the LFB. </synopsis> <optional/> <typeRef>IPv4ValidatorStatsType</typeRef> </component> </components> </LFBClassDef> <LFBClassDef LFBClassID="9"> <name>IPv6Validator</name> <synopsis> This LFB performs IPv6 validation according to RFC 2460 and its updates. Then, the IPv6 packet will be output to the corresponding port, indicating whether the packet is unicast or multicast or whether an exception has occurred or the validation failed. </synopsis> <version>1.0</version> <inputPorts> <inputPort> <name>ValidatePktsIn</name> <synopsis> Input port for data packets to be validated </synopsis> <expectation> <frameExpected> <ref>Arbitrary</ref>
</frameExpected> </expectation> </inputPort> </inputPorts> <outputPorts> <outputPort> <name>IPv6UnicastOut</name> <synopsis> Output port for validated IPv6 unicast packets </synopsis> <product> <frameProduced> <ref>IPv6Unicast</ref> </frameProduced> </product> </outputPort> <outputPort> <name>IPv6MulticastOut</name> <synopsis> Output port for validated IPv6 multicast packets </synopsis> <product> <frameProduced> <ref>IPv6Multicast</ref> </frameProduced> </product> </outputPort> <outputPort> <name>ExceptionOut</name> <synopsis> Output port for packets with exceptional cases when validating. An ExceptionID metadata indicates the exception case type. </synopsis> <product> <frameProduced> <ref>IPv6</ref> </frameProduced> <metadataProduced> <ref>ExceptionID</ref> </metadataProduced> </product> </outputPort> <outputPort> <name>FailOut</name> <synopsis> Output port for packets failed validating process. A ValidateErrorID metadata indicates the error type or failure reason. </synopsis> <product> <frameProduced> <ref>IPv6</ref> </frameProduced> <metadataProduced> <ref>ValidateErrorID</ref> </metadataProduced> </product> </outputPort> </outputPorts> <components> <component access="read-write" componentID="1"> <name>IPv6ValidatorStats</name> <synopsis> The statistics information for validating process in the LFB. </synopsis> <optional/> <typeRef>IPv6ValidatorStatsType</typeRef> </component> </components> </LFBClassDef> <LFBClassDef LFBClassID="10"> <name>IPv4UcastLPM</name> <synopsis> The IPv4UcastLPM LFB abstracts the IPv4 unicast Longest Prefix Match (LPM) process. This LFB supports implementing equal-cost multipath (ECMP) routing and reverse path forwarding (RPF). </synopsis> <version>1.0</version> <inputPorts> <inputPort group="false"> <name>PktsIn</name> <synopsis> A port for input of packets to be processed. IPv4 unicast packets are expected. </synopsis> <expectation> <frameExpected> <ref>IPv4Unicast</ref> </frameExpected> </expectation> </inputPort> </inputPorts> <outputPorts>
<outputPort group="false"> <name>NormalOut</name> <synopsis> An output port to output IPv4 unicast packets that successfully passed the LPM lookup. A HopSelector metadata is produced to associate every output packet for downstream LFB to do next-hop action. </synopsis> <product> <frameProduced> <ref>IPv4Unicast</ref> </frameProduced> <metadataProduced> <ref>HopSelector</ref> </metadataProduced> </product> </outputPort> <outputPort group="false"> <name>ECMPOut</name> <synopsis> The port to output packets needing further ECMP processing. A downstream ECMP processing LFB is usually followed to the port. If ECMP is not required, no downstream LFB may be connected to the port. </synopsis> <product> <frameProduced> <ref>IPv4Unicast</ref> </frameProduced> <metadataProduced> <ref>HopSelector</ref> </metadataProduced> </product> </outputPort> <outputPort group="false"> <name>ExceptionOut</name> <synopsis> The port to output all packets with exceptional cases happened during LPM process. An ExceptionID metadata is associated to indicate what caused the exception. </synopsis> <product> <frameProduced> <ref>IPv4Unicast</ref> </frameProduced> <metadataProduced> <ref>ExceptionID</ref>
</metadataProduced> </product> </outputPort> </outputPorts> <components> <component componentID="1" access="read-write"> <name>IPv4PrefixTable</name> <synopsis> A table for IPv4 Longest Prefix Match(LPM). The destination IPv4 address of every input packet is used as a search key to look up the table to find out a next-hop selector. </synopsis> <typeRef>IPv4PrefixTableType</typeRef> </component> <component componentID="2" access="read-reset"> <name>IPv4UcastLPMStats</name> <synopsis> The statistics information for the IPv4 unicast LPM process in the LFB. </synopsis> <optional/> <typeRef>IPv4UcastLPMStatsType</typeRef> </component> </components> </LFBClassDef> <LFBClassDef LFBClassID="11"> <name>IPv6UcastLPM</name> <synopsis> The IPv6UcastLPM LFB abstracts the IPv6 unicast Longest Prefix Match (LPM) process. This LFB supports implementing equal-cost multipath (ECMP) routing and reverse path forwarding (RPF). </synopsis> <version>1.0</version> <inputPorts> <inputPort group="false"> <name>PktsIn</name> <synopsis> A port for input of packets to be processed. IPv6 unicast packets are expected. </synopsis> <expectation> <frameExpected> <ref>IPv6Unicast</ref> </frameExpected> </expectation> </inputPort>
Okay bestie, the LFB classes keep coming, and these next ones are so iconic 💅✨
</inputPorts>
<outputPorts>
<outputPort group="false">
<name>NormalOut</name>
<synopsis>
An output port to output IPv6 unicast packets that
successfully passed the LPM lookup. A HopSelector
metadata is produced to associate every output packet
for downstream LFB to do next-hop action.
</synopsis>
<product>
<frameProduced>
<ref>IPv6Unicast</ref>
</frameProduced>
<metadataProduced>
<ref>HopSelector</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort group="false">
<name>ECMPOut</name>
<synopsis>
The port to output packets needing further ECMP
processing. A downstream ECMP processing LFB is
usually followed to the port. If ECMP is not
required, no downstream LFB may be connected to
the port.
</synopsis>
<product>
<frameProduced>
<ref>IPv6Unicast</ref>
</frameProduced>
<metadataProduced>
<ref>HopSelector</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort group="false">
<name>ExceptionOut</name>
<synopsis>
The port to output all packets with exceptional cases
happened during LPM process. An ExceptionID metadata
is associated to indicate what caused the exception.
</synopsis>
<product>
<frameProduced>
<ref>IPv6Unicast</ref>
</frameProduced>
<metadataProduced>
<ref>ExceptionID</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1" access="read-write">
<name>IPv6PrefixTable</name>
<synopsis>
A table for IPv6 Longest Prefix Match (LPM). The
destination IPv6 address of every input packet is
used as a search key to look up the table to find
out a next-hop selector.
</synopsis>
<typeRef>IPv6PrefixTableType</typeRef>
</component>
<component componentID="2" access="read-reset">
<name>IPv6UcastLPMStats</name>
<synopsis>
The statistics information for the IPv6 unicast LPM
process in the LFB.
</synopsis>
<optional/>
<typeRef>IPv6UcastLPMStatsType</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="12">
<name>IPv4NextHop</name>
<synopsis>
The IPv4NextHop LFB abstracts the process of next-hop
information application to IPv4 packets. It receives an
IPv4 packet with an associated next-hop identifier
(HopSelector) and uses the identifier as a table index
to look up a next-hop table to find an appropriate output
port. The data processing also involves the forwarding
TTL decrement and IP checksum recalculation.
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort group="false">
<name>PktsIn</name>
<synopsis>
A port for input of unicast IPv4 packets, along with
a HopSelector metadata.
</synopsis>
<expectation>
<frameExpected>
<ref>IPv4Unicast</ref>
</frameExpected>
<metadataExpected>
<ref>HopSelector</ref>
</metadataExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort group="true">
<name>SuccessOut</name>
<synopsis>
The group port for output of packets that
successfully found next-hop information. Some
metadata are associated with every packet.
</synopsis>
<product>
<frameProduced>
<ref>IPv4Unicast</ref>
</frameProduced>
<metadataProduced>
<ref>L3PortID</ref>
<ref>NextHopIPv4Addr</ref>
<ref availability="conditional">
MediaEncapInfoIndex</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort group="false">
<name>ExceptionOut</name>
<synopsis>
The output port for packets with exceptional or
failure cases. An ExceptionID metadata indicates
what caused the case.
</synopsis>
<product>
<frameProduced>
<ref>IPv4Unicast</ref>
</frameProduced>
<metadataProduced>
<ref>ExceptionID</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1">
<name>IPv4NextHopTable</name>
<synopsis>
The IPv4NextHopTable component. A
HopSelector is used to match the table index
to find out a row that contains the next-hop
information result.
</synopsis>
<typeRef>IPv4NextHopTableType</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="13">
<name>IPv6NextHop</name>
<synopsis>
The LFB abstracts the process of next-hop information
application to IPv6 packets. It receives an IPv6 packet
with an associated next-hop identifier (HopSelector) and
uses the identifier as a table index to look up a next-hop
table to find an appropriate output port.
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort group="false">
<name>PktsIn</name>
<synopsis>
A port for input of unicast IPv6 packets, along with
a HopSelector metadata.
</synopsis>
<expectation>
<frameExpected>
<ref>IPv6Unicast</ref>
</frameExpected>
<metadataExpected>
<ref>HopSelector</ref>
</metadataExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort group="true">
<name>SuccessOut</name>
<synopsis>
The group port for output of packets that successfully
found next-hop information. Some metadata are
associated with every packet.
</synopsis>
<product>
<frameProduced>
<ref>IPv6Unicast</ref>
</frameProduced>
<metadataProduced>
<ref>L3PortID</ref>
<ref>NextHopIPv6Addr</ref>
<ref availability="conditional">
MediaEncapInfoIndex</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort group="false">
<name>ExceptionOut</name>
<synopsis>
The output port for packets with exceptional or
failure cases. An ExceptionID metadata indicates
what caused the case.
</synopsis>
<product>
<frameProduced>
<ref>IPv6Unicast</ref>
</frameProduced>
<metadataProduced>
<ref>ExceptionID</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1">
<name>IPv6NextHopTable</name>
<synopsis>
The IPv6NextHopTable component. A HopSelector is
used to match the table index to find out a row that
contains the next-hop information result.
</synopsis>
<typeRef>IPv6NextHopTableType</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="14">
<name>RedirectIn</name>
<synopsis>
The RedirectIn LFB abstracts the process for the ForCES CE to
inject data packets into the ForCES FE LFBs.
</synopsis>
<version>1.0</version>
<outputPorts>
<outputPort group="true">
<name>PktsOut</name>
<synopsis>
The output port of RedirectIn LFB, which is defined as
a group port type. From the LFB topology's point of
view, the RedirectIn LFB acts as a source point for
data packets coming from CE; therefore, the LFB is
defined with a singleton output port (and no input
port).
</synopsis>
<product>
<frameProduced>
<ref>Arbitrary</ref>
</frameProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1">
<name>NumPacketsReceived</name>
<synopsis>
Number of packets received from CE.
</synopsis>
<optional/>
<typeRef>uint64</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="15">
<name>RedirectOut</name>
<synopsis>
The RedirectOut LFB abstracts the process for LFBs in a
ForCES FE to deliver data packets to the ForCES CE.
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort group="false">
<name>PktsIn</name>
<synopsis>
The input port for the RedirectOut LFB. From the LFB
topology's point of view, the RedirectOut LFB acts as
a sink point for data packets going to the CE;
therefore, RedirectOut LFB is defined with a
singleton input port (and no output port).
</synopsis>
<expectation>
<frameExpected>
<ref>Arbitrary</ref>
</frameExpected>Quick vibe check: RedirectIn is the CE's way of sneaking packets into the FE, and RedirectOut is the FE sending them back up to the CE. Main character energy for sure 🦋
</expectation>
</inputPort>
</inputPorts>
<components>
<component componentID="1">
<name>NumPacketsSent</name>
<synopsis>
Number of packets sent to CE.
</synopsis>
<optional/>
<typeRef>uint64</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="16">
<name>BasicMetadataDispatch</name>
<synopsis>
The BasicMetadataDispatch LFB is defined to abstract the
process by which packets are dispatched to various output
paths based on associated metadata value. Current
version of the LFB only allows the metadata value to be
a 32-bit integer.
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>PktsIn</name>
<synopsis>
The packet input port for dispatching. Every input
packet should be associated with a metadata that will
be used by the LFB to do the dispatch.
</synopsis>
<expectation>
<frameExpected>
<ref>Arbitrary</ref>
</frameExpected>
<metadataExpected>
<ref>Arbitrary</ref>
</metadataExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort group="true">
<name>PktsOut</name>
<synopsis>
The group output port that outputs dispatching
results. A packet with its associated metadata
having found an OutputIndex by successfully looking
up the dispatch table will be output to the group
port instance with the corresponding index.
</synopsis>
<product>
<frameProduced>
<ref>Arbitrary</ref>
</frameProduced>
</product>
</outputPort>
<outputPort group="false">
<name>ExceptionOut</name>
<synopsis>
The output port that outputs packets that failed
to process. An ExceptionID metadata indicates what
caused the exception.
</synopsis>
<product>
<frameProduced>
<ref>Arbitrary</ref>
</frameProduced>
<metadataProduced>
<ref>ExceptionID</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component access="read-write" componentID="1">
<name>MetadataID</name>
<synopsis>
The ID of the metadata to be
used for dispatching packets.
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component access="read-write" componentID="2">
<name>MetadataDispatchTable</name>
<synopsis>
The MetadataDispatchTable component, which contains
entries of a metadata value and an output index,
specifying that a packet with the metadata value must
go out from the instance with the output index of the
LFB group output port.
</synopsis>
<typeRef>MetadataDispatchTableType</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="17">
<name>GenericScheduler</name>
<synopsis>
This is a preliminary generic scheduler LFB abstracting
a simple scheduling process, which may be used as a
basic LFB to construct a more complex scheduler LFB.
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort group="true">
<name>PktsIn</name>
<synopsis>
The group input port of the LFB. Inside the LFB,
each instance of the group port is connected to
a queue marked with a queue ID, whose value is
index of the port instance.
</synopsis>
<expectation>
<frameExpected>
<ref>Arbitrary</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort>
<name>PktsOut</name>
<synopsis>
The output port of the LFB. Scheduled packets are
output from the port.
</synopsis>
<product>
<frameProduced>
<ref>Arbitrary</ref>
</frameProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component access="read-write" componentID="1">
<name>SchedulingDiscipline</name>
<synopsis>
The SchedulingDiscipline component, which is for the
CE to specify a scheduling discipline to the LFB.
</synopsis>
<typeRef>SchdDisciplineType</typeRef>
<defaultValue>1</defaultValue>
</component>
<component access="read-only" componentID="2">
<name>QueueStats</name>
<synopsis>
The QueueStats component, which is defined to allow
the CE to query every queue statistics in the
scheduler.
</synopsis>
<optional/>
<typeRef>QueueStatsTableType</typeRef>
</component>
</components>
<capabilities>
<capability componentID="30">
<name>QueueLenLimit</name>
<synopsis>
The QueueLenLimit capability, which specifies
maximum length of each queue. The length unit is in
bytes.
</synopsis>
<typeRef>uint32</typeRef>
</capability>
</capabilities>
</LFBClassDef>
</LFBClassDefs>
</LFBLibrary>7. LFB Class Use Cases ✨
okay so this section is where the LFB classes from Section 6 actually get to show off 💅 it walks through examples of how those base library classes can be put together to build some typical router functions 🎀 the two we're looking at are:
- IPv4 forwarding 🌸
- ARP processing 🦋
it's assumed that the LFB topology on the FE has already been set up by the CE and lines up with the use cases in this section 🫶
btw, these use cases are just examples, not the only way to build router functionality out of LFBs 🙈 depending on what the FE(s) can do, a CE should be able to express different NE applications, so you've got options 👑
7.1. IPv4 Forwarding ✨
okay so this is the IPv4 forwarding path, and it's giving main character energy 💅 Figure 2 shows the typical LFB processing path for IPv4 unicast forwarding with Ethernet media interfaces, using the base LFB classes. To keep the spotlight on IP forwarding, the figure leaves out some inputs and outputs of LFBs that have nothing to do with IPv4 forwarding 🙈 For example, an EtherClassifier LFB normally has two output ports: a "ClassifyOut" group output port and an "ExceptionOut" singleton output port. The group port holds various port instances for the different classified packet types (Section 5.1.3). In this figure, only the IPv4 and IPv6 packet output port instances are shown, so we can focus on the plain IPv4 forwarding function 🦋
+-----+ +------+
| | | |
| |<---------------|Ether |<----------------------------+
| | |MACOut| |
| | | | |
|Ether| +------+ |
|PHY | |
|Cop | +---+ |
|#1 | +-----+ | |----->IPv6 Packets |
| | | | | | |
| | |Ether| | | IPv4 Packets |
| |->|MACIn|-->| |-+ +----+ |
+-----+ | | | | | | |---> Multicast Packets |
+-----+ +---+ | | | +-----+ +---+ |
Ether +->| |------->| | | | |
. Classifier| | |Unicast |IPv4 | | | |
. | | |Packets |Ucast|->| |--+ |
. | +----+ |LPM | | | | |
+---+ | IPv4 +-----+ +---+ | |
+-----+ | | | Validator IPv4 | |
| | | | | NextHop| |
+-----+ |Ether| | |-+ IPv4 Packets | |
| |->|MACIn|-->| | | |
| | | | | |----->IPv6 Packets | |
|Ether| +-----+ +---+ | |
|PHY | Ether +----+ | |
|Cop | Classifier | | +-------+ | |
|#n | +------+ | | |Ether | | |
| | | | | |<--|Encap |<-+ |
| | | |<------| | | | |
| |<---------------|Ether | ...| | +-------+ |
| | |MACOut| +---| | |
| | | | | +----+ |
+-----+ +------+ | BasicMetadataDispatch |
+----------->-------------+Figure 2: LFB Use Case for IPv4 Forwarding
In this LFB use case, a bunch of EtherPHYCop LFB (Section 5.1.1) instances handle the physical-layer stuff for the ports. PHYPortID metadata is generated by the EtherPHYCop LFB and every downstream LFB after it uses it 🔥 An EtherMACIn LFB (Section 5.1.2), which handles the MAC-layer processing, comes right after every EtherPHYCop LFB. The EtherMACIn LFB may do a locality check of MAC addresses if the CE configures the appropriate EtherMACIn LFB component.
Ethernet packets coming out of the EtherMACIn LFB go to an EtherClassifier LFB (Section 5.1.3), which decapsulates them and classifies them into network-layer types like IPv4, IPv6, ARP, etc. 🎀 In the example use case, every physical Ethernet interface is associated with one Classifier instance. It's not drawn, but it's also feasible for all physical interfaces to share just one Ethernet Classifier instance.
EtherClassifier uses the PHYPortID metadata, the Ethernet type of the input packet, and VlanID (if present in the input Ethernet packets) to decide the packet's network-layer type and which LFB output port it goes to downstream. It also assigns a new logical port ID metadata to the packet for later use ✨ The EtherClassifier may also generate some new metadata for every packet, like EtherType, SrcMAC, DstMAC, LogicPortID, etc., for downstream LFBs to consume.
If a packet is classified as an IPv4 packet, it's sent downstream to an IPv4Validator LFB (Section 5.2.1) to be validated. In the validator, IPv4 packets get checked and are also sorted into either IPv4 unicast packets or multicast packets. The IPv4 unicast packets get sent downstream to the IPv4UcastLPM LFB (Section 5.3.1) 💖
The IPv4UcastLPM LFB is where the longest prefix match decision happens, and a next-hop selection gets made. It generates the next-hop ID metadata, which the downstream IPv4NextHop LFB (Section 5.3.2) consumes.
The IPv4NextHop LFB uses the next-hop ID metadata to work out where the packet goes next and the media encapsulation type for the port, and so on. It generates the L3PortID metadata, which identifies a next-hop output physical or logical port. In the example use case, the next-hop output port is an Ethernet type, so the packet and its L3 port ID metadata are sent downstream to an EtherEncap LFB (Section 5.1.4) 🧚
The EtherEncap LFB wraps the incoming packet up in an Ethernet frame. A BasicMetadataDispatch LFB (Section 5.5.1) comes after the EtherEncap LFB. This is where packets are finally dispatched to different output physical or logical ports, based on the L3PortID metadata sent to the LFB 👑
7.2. ARP Processing ✨
Figure 3 shows the processing path for the Address Resolution Protocol (ARP) in the case where the CE implements the ARP processing function. ngl this isn't the only way ARP processing could work. For example, ARP processing could happen at the FE, but that discussion is out of scope for this use case 🙈
+---+ +---+
| | ARP packets | |
| |-------------->---------+--->| | To CE
...-->| | . | | |
| | . | +---+
| | . | RedirectOut
+---+ ^
Ether EtherEncap | IPv4 packets lack
Classifier +---+ | address resolution information
| | |
Packets need | |--------->---+
...--------->| |
L2 Encapsulation| |
+---+ | | +------+
| | +-->| |--+ +---+ |Ether |
| | | +---+ | | |--------->|MACOut|-->...
From CE| |--+ +-->| | . +------+
| |ARP Packets | | .
| |from CE | | . +------+
| | | |--------> |Ether |-->...
+---+ +---+ |MACOut|
RedirectIn BasicMetadata +------+
Dispatch
Figure 3: LFB Use Case for ARPThere are two ways ARP processing could be kicked off in the CE, as shown in Figure 3:
- ARP packets arriving from outside of the NE.
- IPV4 packets failing to resolve within the FE.
ARP packets from network interfaces get filtered out by the EtherClassifier LFB. The classified ARP packets and their associated metadata are then sent downstream to the RedirectOut LFB (Section 5.4.2) so they can be transported to the CE 💜
The EtherEncap LFB, as described in Section 5.1.4, receives packets that need Ethernet L2 encapsulation. When the EtherEncap LFB can't find the necessary L2 Ethernet information to encapsulate the packet, it sends the packet out its ExceptionOut LFB port. Downstream from that ExceptionOut port sits the RedirectOut LFB, which transports the packet to the CE (see Section 5.1.4 on EtherEncap LFB for details) 😭
To get its job done, the CE needs to generate ARP request and response packets and send them to external (to the NE) networks. ARP request and response packets from the CE are redirected to an FE via a RedirectIn LFB (Section 5.4.1) 🫶
Just like forwarded IPv4 packets, outgoing ARP packets are also encapsulated into Ethernet format by the EtherEncap LFB, and then dispatched to different interfaces via a BasicMetadataDispatch LFB. The BasicMetadataDispatch LFB dispatches each packet according to the L3PortID metadata included in every ARP packet sent from the CE 🌸
8. IANA Considerations ✨
IANA has created a registry of ForCES LFB class names and the corresponding ForCES LFB class identifiers, along with the location of the definition of each ForCES LFB class, following the rules for using the namespace 📝
This document registers the unique class names and numeric class identifiers for the LFBs listed in Section 8.1. Besides that, this document defines the following namespaces:
- Metadata ID, defined in Sections 4.3 and 4.4
- Exception ID, defined in Section 4.4
- Validate Error ID, defined in Section 4.4
8.1. LFB Class Names and LFB Class Identifiers 🎀
okay so LFB classes defined by this document belong to LFBs defined by Standards Track RFCs 📜 according to IANA, the registration procedure is Standards Action for the range 0 to 65535, and First Come First Served with any publicly available specification for anything over 65535 ✨
the assignment of LFB class names and LFB class identifiers goes like this 💅
+----------+--------------- +------------------------+--------------+
|LFB Class | LFB Class Name | Description | Reference |
|Identifier| | | |
+----------+--------------- +------------------------+--------------+
| 3 | EtherPHYCop | Define an Ethernet port| RFC 6956, |
| | | abstracted at physical | Section 5.1.1|
| | | layer. | |
| | | | |
| 4 | EtherMACIn | Define an Ethernet | RFC 6956, |
| | | input port at MAC data | Section 5.1.2|
| | | link layer. | |
| | | | |
| 5 |EtherClassifier | Define the process to | RFC 6956, |
| | | decapsulate Ethernet | Section 5.1.3|
| | | packets and classify | |
| | | the packets. | |
| | | | |
| 6 | EtherEncap | Define the process to | RFC 6956, |
| | | encapsulate IP packets | Section 5.1.4|
| | | to Ethernet packets. | |
| | | | |
| 7 | EtherMACOut | Define an Ethernet | RFC 6956 |
| | | output port at MAC | Section 5.1.5|
| | | data link layer. | |
| | | | |
| 8 | IPv4Validator | Perform IPv4 packets | RFC 6956, |
| | | validation. | Section 5.2.1|
| | | | |
| 9 | IPv6Validator | Perform IPv6 packets | RFC 6956, |
| | | validation. | Section 5.2.2|
| | | | |
| 10 | IPv4UcastLPM | Perform IPv4 Longest | RFC 6956, |
| | | Prefix Match Lookup. | Section 5.3.1|
| | | | |
| 11 | IPv6UcastLPM | Perform IPv6 Longest | RFC 6956, |
| | | Prefix Match Lookup. | Section 5.3.3|
| | | | |
| 12 | IPv4NextHop | Define the process of | RFC 6956, |
| | | selecting IPv4 next-hop| Section 5.3.2|
| | | action. | |
| | | | |
| 13 | IPv6NextHop | Define the process of | RFC 6956, |
| | | selecting IPv6 next-hop| Section 5.3.4|
| | | action. | |
| | | | |
| 14 | RedirectIn | Define the process for | RFC 6956, |
| | | CE to inject data | Section 5.4.1|
| | | packets into FE LFB | |
| | | topology. | |
| | | | |
| 15 | RedirectOut | Define the process for | RFC 6956, |
| | | LFBs in FE to deliver | Section 5.4.2|
| | | data packets to CE. | |
| | | | |
| 16 | BasicMetadata | Dispatch input packets | RFC 6956, |
| | Dispatch | to a group output | Section 5.5.1|
| | | according to a metadata| |
| | | | |
| 17 |GenericScheduler| Define a preliminary | RFC 6956, |
| | | generic scheduling | Section 5.5.2|
| | | process. | |
+----------+--------------- +------------------------+--------------+
Table 18.2. Metadata ID 🦋
the Metadata ID namespace is 32 bits long 🌸 here are the guidelines for managing it
Metadata IDs in the range of 0x00000001-0x7FFFFFFF are Specification Required [RFC5226]. a metadata ID using this range MUST be documented in an RFC or other permanent and readily available reference 📚
values assigned by this specification 👑
+--------------+-------------------------+--------------------------+
| Value | Name | Definition |
+--------------+-------------------------+--------------------------+
| 0x00000000 | Reserved | RFC 6956 |
| 0x00000001 | PHYPortID | RFC 6956, Section 4.4 |
| 0x00000002 | SrcMAC | RFC 6956, Section 4.4 |
| 0x00000003 | DstMAC | RFC 6956, Section 4.4 |
| 0x00000004 | LogicalPortID | RFC 6956, Section 4.4 |
| 0x00000005 | EtherType | RFC 6956, Section 4.4 |
| 0x00000006 | VlanID | RFC 6956, Section 4.4 |
| 0x00000007 | VlanPriority | RFC 6956, Section 4.4 |
| 0x00000008 | NextHopIPv4Addr | RFC 6956, Section 4.4 |
| 0x00000009 | NextHopIPv6Addr | RFC 6956, Section 4.4 |
| 0x0000000A | HopSelector | RFC 6956, Section 4.4 |
| 0x0000000B | ExceptionID | RFC 6956, Section 4.4 |
| 0x0000000C | ValidateErrorID | RFC 6956, Section 4.4 |
| 0x0000000D | L3PortID | RFC 6956, Section 4.4 |
| 0x0000000E | RedirectIndex | RFC 6956, Section 4.4 |
| 0x0000000F | MediaEncapInfoIndex | RFC 6956, Section 4.4 |
| 0x80000000- | Reserved for | RFC 6956 |
| 0xFFFFFFFF | Private Use | |
+--------------+-------------------------+--------------------------+
Table 28.3. Exception ID 💖
the Exception ID namespace is 32 bits long 🧚 same deal, here are the guidelines for managing it
Exception IDs in the range of 0x00000000-0x7FFFFFFF are Specification Required [RFC5226]. an exception ID using this range MUST be documented in an RFC or other permanent and readily available reference 💜
values assigned by this specification ✨
+--------------+---------------------------------+------------------+
| Value | Name | Definition |
+--------------+---------------------------------+------------------+
| 0x00000000 | AnyUnrecognizedExceptionCase | See Section 4.4 |
| 0x00000001 | ClassifyNoMatching | See Section 4.4 |
| 0x00000002 | MediaEncapInfoIndexInvalid | See Section 4.4 |
| 0x00000003 | EncapTableLookupFailed | See Section 4.4 |
| 0x00000004 | BadTTL | See Section 4.4 |
| 0x00000005 | IPv4HeaderLengthMismatch | See Section 4.4 |
| 0x00000006 | RouterAlertOptions | See Section 4.4 |
| 0x00000007 | IPv6HopLimitZero | See Section 4.4 |
| 0x00000008 | IPv6NextHeaderHBH | See Section 4.4 |
| 0x00000009 | SrcAddressException | See Section 4.4 |
| 0x0000000A | DstAddressException | See Section 4.4 |
| 0x0000000B | LPMLookupFailed | See Section 4.4 |
| 0x0000000C | HopSelectorInvalid | See Section 4.4 |
| 0x0000000D | NextHopLookupFailed | See Section 4.4 |
| 0x0000000E | FragRequired | See Section 4.4 |
| 0x0000000F | MetadataNoMatching | See Section 4.4 |
| 0x80000000- | Reserved for | RFC 6956 |
| 0xFFFFFFFF | Private Use | |
+--------------+---------------------------------+------------------+
Table 38.4. Validate Error ID 🌈
the Validate Error ID namespace is 32 bits long 🍓 the guidelines are below, and they're pretty chill
Validate Error IDs in the range of 0x00000000-0x7FFFFFFF are Specification Required [RFC5226]. a Validate Error ID using this range MUST be documented in an RFC or other permanent and readily available reference 🫶
values assigned by this specification 🦋
+--------------+---------------------------------+------------------+
| Value | Name | Definition |
+--------------+---------------------------------+------------------+
| 0x00000000 | AnyUnrecognizedValidateErrorCase| See Section 4.4 |
| 0x00000001 | InvalidIPv4PacketSize | See Section 4.4 |
| 0x00000002 | NotIPv4Packet | See Section 4.4 |
| 0x00000003 | InvalidIPv4HeaderLengthSize | See Section 4.4 |
| 0x00000004 | InvalidIPv4LengthFieldSize | See Section 4.4 |
| 0x00000005 | InvalidIPv4Checksum | See Section 4.4 |
| 0x00000006 | InvalidIPv4SrcAddr | See Section 4.4 |
| 0x00000007 | InvalidIPv4DstAddr | See Section 4.4 |
| 0x00000008 | InvalidIPv6PacketSize | See Section 4.4 |
| 0x00000009 | NotIPv6Packet | See Section 4.4 |
| 0x0000000A | InvalidIPv6SrcAddr | See Section 4.4 |
| 0x0000000B | InvalidIPv6DstAddr | See Section 4.4 |
| 0x80000000- | Reserved for | RFC 6956 |
| 0xFFFFFFFF | Private Use | |
+--------------+---------------------------------+------------------+
Table 49. Security Considerations 🔥
okay bestie, this part is SERIOUS 😭 security is not a vibe to skip
the ForCES framework document [RFC3746] describes the security needs for the whole ForCES architecture 🛡️ for example, the ForCES protocol entities must be authenticated per the ForCES requirements before they can access the information elements described in this document via ForCES 🔐 the ForCES protocol document [RFC5810] includes a comprehensive set of security mechanisms that implementations are required to support to meet these needs 💅 the SCTP-based Transport Mapping Layer (TML) for the ForCES protocol [RFC5811] specifies security mechanisms for transport mapping for the ForCES protocol 🚀 the LFBs defined in this document are similar to other LFBs modeled by the FE model [RFC5812] 👯 in particular, they have the same security properties ✨ so the security mechanisms and considerations from the ForCES protocol document [RFC5810] apply to this document, no exceptions 🙈
10. References 📚
10.1. Normative References 🎀
okay so these are the docs you literally need to have read before you touch this spec, bestie 📚✨
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H.,
Wang, W., Dong, L., Gopal, R., and J. Halpern,
"Forwarding and Control Element Separation (ForCES)
Protocol Specification", RFC 5810, March 2010.
[RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport
Mapping Layer (TML) for the Forwarding and Control
Element Separation (ForCES) Protocol", RFC 5811,
March 2010.
[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control
Element Separation (ForCES) Forwarding Element Model",
RFC 5812, March 2010.10.2. Informative References 🦋
these ones are the extra reading that's lowkey so worth it, not required but they give you the full picture 🌸
[IEEE.802-1Q] IEEE, "IEEE Standard for Local and metropolitan area
networks -- Media Access Control (MAC) Bridges and
Virtual Bridged Local Area Networks", IEEE Standard
802.1Q, 2011.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version
6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578,
April 1999.
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal,
"Forwarding and Control Element Separation (ForCES)
Framework", RFC 3746, April 2004.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26,
RFC 5226, May 2008.Appendix A. Acknowledgements 💜
the authors wanna give a huge shoutout to these people, whose input was seriously so helpful while this doc was being built. iconic behaviour 👑🫶
Edward Crabbe
Adrian Farrel
Rong Jin
Bin Zhuge
Ming Gao
Jingjing Zhou
Xiaochun Wu
Derek Atkins
Stephen Farrell
Meral Shirazipour
Jari Arkko
Martin Stiemerling
Stewart Bryant
Richard BarnesAppendix B. Contributors 🧚
the authors wanna thank Jamal Hadi Salim, Ligang Dong, and Fenggen Jia, who all made major contributions to this doc. Ligang Dong and Fenggen Jia were also two of the authors of earlier documents that this one evolved from. they really carried 🔥💅
Jamal Hadi Salim
Mojatatu Networks
Ottawa, Ontario
Canada
EMail: hadi@mojatatu.com
Ligang Dong
Zhejiang Gongshang University
18 Xuezheng Str., Xiasha University Town
Hangzhou 310018
P.R. China
EMail: donglg@zjsu.edu.cn
Fenggen Jia
National Digital Switching Center (NDSC)
Jianxue Road
Zhengzhou 452000
P.R. China
EMail: jfg@mail.ndsc.com.cnAuthors' Addresses 🌈
and here are the authors, in their own words (well, their addresses) 💖
Weiming Wang
Zhejiang Gongshang University
18 Xuezheng Str., Xiasha University Town
Hangzhou 310018
P.R. China
Phone: +86 571 28877751
EMail: wmwang@zjsu.edu.cn
Evangelos Haleplidis
University of Patras
Department of Electrical & Computer Engineering
Patras 26500
Greece
EMail: ehalep@ece.upatras.gr
Kentaro Ogawa
NTT Corporation
Tokyo
Japan
EMail: ogawa.kentaro@lab.ntt.co.jp
Chuanhuang Li
Hangzhou DPtech
6th Floor, Zhongcai Group, 68 Tonghe Road, Binjiang District
Hangzhou 310051
P.R. China
EMail: chuanhuang_li@zjsu.edu.cn
Joel Halpern
Ericsson
P.O. Box 6049
Leesburg, VA 20178
USA
Phone: +1 703 371 3043
EMail: joel.halpern@ericsson.comthat's the whole doc, bestie!! 🦄✨ you made it through all 22 parts and the authors are literally so proud of you 🎀
📦 where this page comes from
- ietf: rfc6956 2013-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms