Internet Engineering Task Force (IETF) W. Wang
Request for Comments: 6956 Zhejiang Gongshang University
Category: Standards Track E. Haleplidis
ISSN: 2070-1721 University of Patras
K. Ogawa
NTT Corporation
C. Li
Hangzhou DPtech
J. Halpern
Ericsson
June 2013
Internet Engineering Task Force (IETF) W. Wang
Request for Comments: 6956 Zhejiang Gongshang University
Category: Standards Track E. Haleplidis
ISSN: 2070-1721 University of Patras
K. Ogawa
NTT Corporation
C. Li
Hangzhou DPtech
J. Halpern
Ericsson
June 2013
Forwarding and Control Element Separation (ForCES) Logical Function Block (LFB) Library
转发和控制元素分离（ForCES）逻辑功能块（LFB）库
Abstract
摘要
This document defines basic classes of Logical Function Blocks (LFBs) used in Forwarding and Control Element Separation (ForCES). The basic LFB classes are defined according to the ForCES Forwarding Element (FE) model and ForCES protocol specifications; they are scoped to meet requirements of typical router functions and are considered the basic LFB library for ForCES. The library includes the descriptions of the LFBs and the XML definitions.
本文件定义了转发和控制元素分离（ForCES）中使用的逻辑功能块（LFB）的基本类。根据ForCES转发元素（FE）模型和ForCES协议规范定义基本LFB类；它们的作用范围是满足典型路由器功能的要求，并被视为部队的基本LFB库。该库包括LFB和XML定义的描述。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6956.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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 ........................................110
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 ........................................110
[RFC3746] specifies the Forwarding and Control Element Separation (ForCES) framework. In the framework, Control Elements (CEs) configure and manage one or more separate Forwarding Elements (FEs) within a Network Element (NE) by use of a ForCES protocol. [RFC5810] specifies the ForCES protocol. [RFC5812] specifies the Forwarding Element (FE) model. In the model, resources in FEs are described by classes of Logical Function Blocks (LFBs). The FE model defines the structure and abstract semantics of LFBs and provides XML schema for the definitions of LFBs.
[RFC3746]指定转发和控制元素分离（ForCES）框架。在该框架中，控制元件（ce）通过使用ForCES协议来配置和管理网元（NE）内的一个或多个单独的转发元件（FEs）。[RFC5810]指定强制协议。[RFC5812]指定转发元素（FE）模型。在该模型中，FEs中的资源由逻辑功能块（LFB）类描述。FE模型定义了LFB的结构和抽象语义，并为LFB的定义提供了XML模式。
This document conforms to the specifications of the FE model [RFC5812] and specifies detailed definitions of classes of LFBs, including detailed XML definitions of LFBs. These LFBs form a base LFB library for ForCES. LFBs in the base library are expected to be combined to form an LFB topology for a typical router to implement IP forwarding. It should be emphasized that an LFB is an abstraction of functions rather than implementation details. The purpose of the LFB definitions is to represent functions so as to provide interoperability between separate CEs and FEs.
本文件符合FE模型[RFC5812]的规范，并规定了LFB类的详细定义，包括LFB的详细XML定义。这些LFB形成了一个基本LFB力库。基本库中的LFB预计将被组合成一个LFB拓扑，用于典型路由器实现IP转发。应该强调的是，LFB是功能的抽象，而不是实现细节。LFB定义的目的是表示功能，以便在单独的CE和FEs之间提供互操作性。
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].
未来可能会开发更多具有更多功能的LFB类，并由IETF记录。供应商还可以开发FE模型[RFC5812]中所述的专有LFB类。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document follows the terminology defined by the ForCES protocol in [RFC5810] and by the ForCES FE model in [RFC5812]. The definitions below are repeated for clarity.
本文件遵循[RFC5810]中的ForCES协议和[RFC5812]中的ForCES FE模型定义的术语。为清楚起见，重复以下定义。
Control Element (CE) - A logical entity that implements the ForCES protocol and uses it to instruct one or more FEs on how to process packets. CEs handle functionality such as the execution of control and signaling protocols.
控制元素（CE）-实现强制协议的逻辑实体，并使用它指示一个或多个FEs如何处理数据包。CEs处理控制和信令协议的执行等功能。
Forwarding Element (FE) - A logical entity that implements the ForCES protocol. FEs use the underlying hardware to provide per-packet processing and handling as directed/controlled by one or more CEs via the ForCES protocol.
转发元素（FE）-实现ForCES协议的逻辑实体。FEs使用底层硬件，按照一个或多个CE通过ForCES协议的指示/控制，提供每包处理和处理。
ForCES Network Element (NE) - An entity composed of one or more CEs and one or more FEs. To entities outside an NE, the NE represents a single point of management. Similarly, an NE usually hides its internal organization from external entities.
强制网元（NE）-由一个或多个CE和一个或多个FEs组成的实体。对于网元之外的实体，网元表示单个管理点。类似地，网元通常对外部实体隐藏其内部组织。
Logical Function Block (LFB) - The basic building block that is operated on by the ForCES protocol. The LFB is a well-defined, logically separable functional block that resides in an FE and is controlled by the CE via the ForCES protocol. The LFB may reside at the FE's data path and process packets or may be purely an FE control or configuration entity that is operated on by the CE. Note that the LFB is a functionally accurate abstraction of the FE's processing capabilities but not a hardware-accurate representation of the FE implementation.
逻辑功能块（LFB）-由ForCES协议操作的基本构建块。LFB是一个定义良好、逻辑上可分离的功能块，位于FE中，由CE通过ForCES协议控制。LFB可以驻留在FE的数据路径上并处理分组，或者可以是由CE操作的纯粹FE控制或配置实体。请注意，LFB是FE处理能力的功能精确抽象，但不是FE实现的硬件精确表示。
FE Model - The FE model is designed to model the logical processing functions of an FE, which is defined by the ForCES FE model document [RFC5812]. The FE model proposed in this document includes three components: the LFB modeling of individual Logical Functional Blocks (LFB model), the logical interconnection between
有限元模型-有限元模型旨在对有限元的逻辑处理功能进行建模，该功能由部队有限元模型文件[RFC5812]定义。本文中提出的有限元模型包括三个部分：单个逻辑功能块的LFB建模（LFB模型）、各逻辑功能块之间的逻辑互连
LFBs (LFB topology), and the FE-level attributes, including FE capabilities. The FE model provides the basis to define the information elements exchanged between the CE and the FE in the ForCES protocol [RFC5810].
LFB（LFB拓扑）和FE级别属性，包括FE能力。FE模型提供了在ForCES协议[RFC5810]中定义CE和FE之间交换的信息元素的基础。
FE Topology - A representation of how the multiple FEs within a single NE are interconnected. Sometimes this is called inter-FE topology, to be distinguished from intra-FE topology (i.e., LFB topology).
FE拓扑-表示单个网元内多个FE的互连方式。有时这被称为内部FE拓扑，以区别于内部FE拓扑（即LFB拓扑）。
LFB Class and LFB Instance - LFBs are categorized by LFB classes. An LFB instance represents an LFB class (or type) existence. There may be multiple instances of the same LFB class (or type) in an FE. An LFB class is represented by an LFB class ID, and an LFB instance is represented by an LFB instance ID. As a result, an LFB class ID associated with an LFB instance ID uniquely specifies an LFB existence.
LFB类和LFB实例-LFB按LFB类分类。LFB实例表示LFB类（或类型）的存在。FE中可能存在同一LFB类（或类型）的多个实例。LFB类由LFB类ID表示，LFB实例由LFB实例ID表示。因此，与LFB实例ID关联的LFB类ID唯一地指定LFB的存在。
LFB Metadata - Metadata is used to communicate per-packet state from one LFB to another but is not sent across the network. The FE model defines how such metadata is identified, produced, and consumed by the LFBs. It defines the functionality but not how metadata is encoded within an implementation.
LFB元数据-元数据用于将每个数据包状态从一个LFB传送到另一个LFB，但不会通过网络发送。FE模型定义了LFB如何识别、生成和使用这些元数据。它定义了功能，但没有定义元数据在实现中的编码方式。
LFB Component - Operational parameters of the LFBs that must be visible to the CEs are conceptualized in the FE model as the LFB components. The LFB components include, for example, flags, single parameter arguments, complex arguments, and tables that the CE can read and/or write via the ForCES protocol (see below).
LFB组件-必须对CEs可见的LFB操作参数在FE模型中被概念化为LFB组件。LFB组件包括，例如，标志、单参数参数参数、复杂参数以及CE可以通过ForCES协议读取和/或写入的表（见下文）。
LFB Topology - Representation of how the LFB instances are logically interconnected and placed along the data path within one FE. Sometimes it is also called intra-FE topology, to be distinguished from inter-FE topology.
LFB拓扑—表示LFB实例如何在一个FE内沿数据路径进行逻辑互连和放置。有时也称为内部FE拓扑，以区别于内部FE拓扑。
Data Path - A conceptual path taken by packets within the forwarding plane inside an FE. Note that more than one data path can exist within an FE.
数据路径-FE内转发平面内的数据包采用的概念路径。请注意，FE中可以存在多个数据路径。
ForCES Protocol - While there may be multiple protocols used within the overall ForCES architecture, the term "ForCES protocol" and "protocol" refer to the Fp reference points in the ForCES framework in [RFC3746]. This protocol does not apply to CE-to-CE communication, FE-to-FE communication, or to communication between FE and CE managers. Basically, the ForCES protocol works in a master-slave mode in which FEs are slaves and CEs are masters.
部队协议-虽然在整个部队体系结构中可能使用多个协议，但术语“部队协议”和“协议”指的是[RFC3746]中部队框架中的Fp参考点。本协议不适用于CE-to-CE通信、FE-to-FE通信或FE与CE经理之间的通信。基本上，ForCES协议在主-从模式下工作，其中FEs是从机，ce是主机。
Physical Port - A port refers to a physical media input port or output port of an FE. A physical port is usually assigned with a physical port ID, abbreviated with a PHYPortID. This document mainly deals with physical ports with Ethernet media.
物理端口-端口指FE的物理介质输入端口或输出端口。物理端口通常分配有物理端口ID，缩写为PHYPortID。本文档主要介绍以太网介质的物理端口。
Logical Port - A conceptually virtual port at the data link layer (L2) or network layer (L3). A logical port is usually assigned with a logical port ID, abbreviated with a LogicalPortID. The logical ports can be further categorized with an L2 logical port or an L3 logical port. An L2 logical port can be assigned with an L2 logical port ID, abbreviated with an L2PortID. An L3 logical port can be assigned with an L3 logical port ID, abbreviated with an L3PortID. MAC-layer VLAN ports belong to logical ports, and they belong to L2 logical ports.
逻辑端口-数据链路层（L2）或网络层（L3）的概念虚拟端口。逻辑端口通常分配有逻辑端口ID，缩写为LogicalPortID。逻辑端口可以进一步分类为二级逻辑端口或三级逻辑端口。L2逻辑端口可以分配L2逻辑端口ID，缩写为L2PortID。可以为L3逻辑端口分配L3逻辑端口ID，缩写为L3PortID。MAC层VLAN端口属于逻辑端口，它们属于L2逻辑端口。
LFB Port - The connection points where one LFB can be connected to another within an FE. As described in [RFC5812], the CE can connect LFBs together by establishing connections between an output port of one LFB instance and an input port of another LFB instance. Also see Section 3.2 of [RFC5812] for more details.
LFB端口-FE内一个LFB可以连接到另一个LFB的连接点。如[RFC5812]所述，CE可以通过在一个LFB实例的输出端口和另一个LFB实例的输入端口之间建立连接，将LFB连接在一起。有关更多详细信息，请参见[RFC5812]第3.2节。
Singleton Port - A named input or output port of an LFB. This port is referred to by a name. When the context is clear, the term "singleton" by itself is used to refer to a singleton port.
单例端口-LFB的命名输入或输出端口。此端口由名称引用。当上下文清楚时，术语“singleton”本身被用来指代singleton端口。
Group Port - A named collection of input or output ports of an LFB. A group port is referred to by a name. A group port consists of a number of port instances, which are referred to by a combination of a name and an index.
组端口-LFB输入或输出端口的命名集合。组端口由名称引用。组端口由多个端口实例组成，这些实例由名称和索引组合引用。
LFB Class Library - The LFB class library is a set of LFB classes that has been identified as the most common functions found in most FEs and hence should be defined first by the ForCES Working Group. The LFB class library is defined by this document.
LFB类库-LFB类库是一组LFB类，已被确定为大多数FEs中最常见的函数，因此应首先由部队工作组定义。LFB类库由本文档定义。
It is intended that the LFB classes described in this document are designed to provide the functions of a typical router. [RFC1812] specifies that a typical router is expected to provide functions to:
本文档中描述的LFB类旨在提供典型路由器的功能。[RFC1812]指定一个典型路由器应提供以下功能：
(1) Interface to packet networks and implement the functions required by that network. These functions typically include:
(1) 与分组网络的接口，并实现该网络所需的功能。这些功能通常包括：
* Encapsulating and decapsulating the IP datagrams with the connected network framing (e.g., an Ethernet header and checksum),
* 使用连接的网络帧（例如，以太网报头和校验和）封装和解封IP数据报，
* 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),
* 发送和接收IP数据报至该网络支持的最大大小（该大小是网络的最大传输单元或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
* 如果需要，将IP目标地址转换为所连接网络的适当网络级地址（例如，以太网硬件地址），以及
* Responding to network flow control and error indications, if any.
* 响应网络流量控制和错误指示（如有）。
(2) Conform to specific Internet protocols including the Internet Protocol (IPv4 and/or IPv6), Internet Control Message Protocol (ICMP), and others as necessary.
(2) 遵守特定的互联网协议，包括互联网协议（IPv4和/或IPv6）、互联网控制消息协议（ICMP）以及其他必要的协议。
(3) Receive and forward Internet datagrams. Important issues in this process are buffer management, congestion control, and fairness.
(3) 接收和转发互联网数据报。这个过程中的重要问题是缓冲区管理、拥塞控制和公平性。
* Recognize error conditions and generate ICMP error and information messages as required.
* 识别错误条件，并根据需要生成ICMP错误和信息消息。
* 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.
* 必要时对数据报进行分段，以适合下一个链接或接口的MTU。
(4) Choose a next-hop destination for each IP datagram, based on the information in its routing database.
(4) 根据路由数据库中的信息，为每个IP数据报选择下一跳目的地。
(5) 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.
(5) 通常支持内部网关协议（IGP），以便与同一自治系统中的其他路由器执行分布式路由和可达性算法。此外，一些路由器需要支持外部网关协议（EGP），以便与其他自治系统交换拓扑信息。对于所有路由器，必须提供管理静态路由项的能力。
(6) Provide network management and system support facilities, including loading, debugging, status reporting, statistics query, exception reporting, and control.
(6) 提供网络管理和系统支持设施，包括加载、调试、状态报告、统计查询、异常报告和控制。
The classical IP router utilizing the ForCES framework constitutes a CE running some controlling IGP and/or EGP function or static route setup and FEs implemented by use of Logical Function Blocks (LFBs) conforming to the FE model [RFC5812] specification. The CE, in conformance to the ForCES protocol [RFC5810] and the FE model [RFC5812] specifications, instructs the LFBs on the FE how to treat received/sent packets.
利用ForCES框架的经典IP路由器构成一个CE，运行一些控制IGP和/或EGP功能或静态路由设置，并使用符合FE模型[RFC5812]规范的逻辑功能块（LFB）实现FEs。CE根据ForCES协议[RFC5810]和FE模型[RFC5812]规范，指示FE上的LFB如何处理接收/发送的数据包。
Packets in an IP router are received and transmitted on physical media typically referred to as "ports". Different physical media will have different ways for encapsulating outgoing frames and decapsulating incoming frames. The different physical media will also have different attributes that influence its behavior and how frames get encapsulated or decapsulated. This document will only deal with Ethernet physical media. Future documents may deal with other types of media. This document will also interchangeably refer to a port as an abstraction that constitutes a physical layer (PHY) and a Media Access Control (MAC) layer, as described by LFBs like EtherPHYCop, EtherMACIn, and EtherMACOut.
IP路由器中的数据包在通常称为“端口”的物理介质上接收和传输。不同的物理介质将有不同的方式来封装传出帧和解除封装传入帧。不同的物理介质也将具有不同的属性，这些属性会影响其行为以及帧的封装或解封方式。本文档仅涉及以太网物理介质。未来的文档可能涉及其他类型的媒体。本文档还将互换地将端口称为构成物理层（PHY）和媒体访问控制（MAC）层的抽象，如EtherPHYCop、EtherMACIn和EtherMACOut等LFB所述。
IP packets emanating from port LFBs are then processed by a validation LFB before being further forwarded to the next LFB. After the validation process, the packet is passed to an LFB where an IP forwarding decision is made. In the IP Forwarding LFBs, a Longest Prefix Match LFB is used to look up the destination information in a packet and select a next-hop index for sending the packet onward. A next-hop LFB uses the next-hop index metadata to apply the proper headers to the IP packets and direct them to the proper egress. Note that in the process of IP packet processing, in this document, we are adhering to the weak-host model [RFC1122] since that is the most usable model for a packet processing a Network Element.
从端口LFB发出的IP数据包随后由验证LFB处理，然后再转发到下一个LFB。在验证过程之后，数据包被传递到LFB，在LFB中做出IP转发决策。在IP转发LFB中，使用最长前缀匹配LFB来查找分组中的目的地信息，并选择用于向前发送分组的下一跳索引。下一跳LFB使用下一跳索引元数据将适当的报头应用于IP数据包，并将其引导到适当的出口。注意，在IP分组处理的过程中，在本文档中，我们遵循弱主机模型[RFC1122]，因为这是用于处理网络元件的分组的最可用模型。
It is critical to classify functional requirements into various classes of LFBs and construct a typical but also flexible enough base LFB library for various IP forwarding equipments.
将功能需求划分为不同类别的LFB，并为各种IP转发设备构建一个典型但又足够灵活的基础LFB库是至关重要的。
A few design principles were factored into choosing what the base LFBs look like:
在选择基本LFB时考虑了一些设计原则：
o If a function can be designed by either one LFB or two or more LFBs with the same cost, the choice is to go with two or more LFBs so as to provide more flexibility for implementers.
o 如果一个函数可以由一个LFB或两个或多个LFB以相同的成本设计，那么可以选择使用两个或多个LFB，以便为实现者提供更大的灵活性。
o An LFB should take advantage of its independence as much as possible and have minimal coupling with other LFBs. The coupling may be from LFB attributes definitions as well as physical implementations.
o LFB应尽可能利用其独立性，并且与其他LFB的耦合最小。耦合可以来自LFB属性定义以及物理实现。
o Unless there is a clear difference in functionality, similar packet processing in the base LFB library should not be represented simultaneously as two or more LFBs. For instance, it should not be simultaneously defined with two different LFBs for the same next-hop processing. Otherwise, it may add extra burden on implementation to achieve interoperability.
o 除非功能上存在明显差异，否则基本LFB库中的类似数据包处理不应同时表示为两个或多个LFB。例如，对于同一下一跳处理，不应使用两个不同的LFB同时定义它。否则，它可能会增加实现互操作性的额外负担。
This document defines groups of LFBs for typical router function requirements:
本文件定义了典型路由器功能要求的LFB组：
(1) A group of Ethernet-processing LFBs are defined to abstract the packet processing for Ethernet as the port media type. As Ethernet is the most popular media type with rich processing features, 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:
(1) 定义了一组以太网处理LFB，将以太网的数据包处理抽象为端口媒体类型。由于以太网是最流行的媒体类型，具有丰富的处理功能，因此以太网媒体处理LFB是一种自然选择。其他端口媒体类型（如SONET上的数据包（POS）或异步传输模式（ATM））的处理定义可在本文档的未来版本或单独文档的库中合并。为以太网处理定义了以下LFB：
* EtherPHYCop (Section 5.1.1)
* EtherPHYCop（第5.1.1节）
* EtherMACIn (Section 5.1.2)
* 乙醚霉素（第5.1.2节）
* EtherClassifier (Section 5.1.3)
* 乙醚分级机（第5.1.3节）
* EtherEncap (Section 5.1.4)
* Ethernecap（第5.1.4节）
* EtherMACOut (Section 5.1.5)
* 以太网输出（第5.1.5节）
(2) A group of LFBs are defined for IP packet validation process. The following LFBs are defined for IP validation processing:
(2) 为IP数据包验证过程定义了一组LFB。为IP验证处理定义了以下LFB：
* IPv4Validator (Section 5.2.1)
* IPV4验证程序（第5.2.1节）
* IPv6Validator (Section 5.2.2)
* IPV6验证器（第5.2.2节）
(3) A group of LFBs are defined to abstract IP forwarding process. The following LFBs are defined for IP forwarding processing:
(3) 定义了一组LFB来抽象IP转发过程。为IP转发处理定义了以下LFB：
* IPv4UcastLPM (Section 5.3.1)
* IPv4UcastLPM（第5.3.1节）
* IPv4NextHop (Section 5.3.2)
* IPv4NextHop（第5.3.2节）
* IPv6UcastLPM (Section 5.3.3)
* IPv6UcastLPM（第5.3.3节）
* IPv6NextHop (Section 5.3.4)
* IPv6NextHop（第5.3.4节）
(4) A group of LFBs are defined to abstract the process for redirect operation, i.e., data packet transmission between CE and FEs. The following LFBs are defined for redirect processing:
(4) 定义了一组lfb来抽象重定向操作的过程，即CE和FEs之间的数据分组传输。为重定向处理定义了以下LFB：
* RedirectIn (Section 5.4.1)
* 重定向（第5.4.1节）
* RedirectOut (Section 5.4.2)
* 重定向输出（第5.4.2节）
(5) A group of LFBs are 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:
(5) 定义了一组LFB，用于抽象一些通用的数据包处理。这些处理过程通常适用于FE LFB拓扑中的许多处理位置。为重定向处理定义了以下LFB：
* BasicMetadataDispatch (Section 5.5.1)
* 基本元数据调度（第5.5.1节）
* GenericScheduler (Section 5.5.2)
* 通用调度程序（第5.5.2节）
Although Section 7 will present use cases for the LFBs defined in this document, this section shows a simple sample LFB class application in advance so that readers can get a quick overlook of the LFB classes with the usage.
尽管第7节将介绍本文档中定义的LFB的用例，但本节将提前展示一个简单的LFB类示例应用程序，以便读者能够快速了解LFB类的用法。
Figure 1 shows a simple LFB processing path for Ethernet packets entered from Ethernet physical ports.
图1显示了从以太网物理端口输入的以太网数据包的简单LFB处理路径。
+-----+ +------+
| |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
+-----+ +------+
+-----+ +------+
| |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
图1：一个简单的示例LFB用例
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.
在图中，来自外部网络的以太网数据包通过EtherPHYCop LFB（第5.1.1节）进入，该LFB描述了物理层的以太网铜缆接口属性（如链路速度）。物理层处理后，以太网数据包被传送到EtherMACIn LFB（第5.1.2节），以描述其MAC层处理功能（如位置检查）。EtherMACIn LFB之后的分组可能需要进一步处理以实现各种功能（如IP层转发）；因此，一些LFB可能在拓扑结构上遵循EtherMACIn LFB来描述后续处理功能。
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.
同时，一些LFB（s）生成的分组可能需要提交到外部物理网络。该过程在图中由MAC层的EtherMACOut LFB（第5.1.5节）和物理层的EtherPHYCop LFB描述。
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.
对于各种LFB类的定义，预先提供了基本类型定义，包括数据类型、包帧类型和元数据类型。第4节（“基本类型”）介绍了该LFB库使用的基本类型。为了使其他LFB类定义能够广泛使用这些基类型，基类型定义作为一个单独的库提供。
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类中，都定义了一组LFB用于单独的函数目的。第5节（“LFB类描述”）提供了关于各个LFB的文本描述。注意，对于LFB的完整定义，需要文本描述和XML定义。
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.
LFB类最终由XML定义，规范和模式在ForCES FE模型[RFC5812]中定义。第6节（“LFB库的XML”）提供了基本LFB类库的完整XML定义。
Section 7 provides several use cases on how some typical router functions can be implemented using the base LFB library defined in this document.
第7节提供了几个使用本文档中定义的基本LFB库实现一些典型路由器功能的用例。
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.
FE模型[RFC5812]指定了预定义（内置）的原子数据类型：char、uchar、int16、uint16、int32、uint32、int64、uint64、string[N]、string、byte[N]、boolean、octetstring[N]、float16、float32和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.
请注意，与称为管理信息结构（SMI）[RFC2578]的简单网络管理协议（SNMP）信息模型不同，FE模型没有为计数目的定义特定的原子数据类型。本文档也没有定义特定的计数器类型。为了描述用于数据包统计的LFB元素（实际上需要数据包上的计数器），采用了无符号整数，如uint32或uint64。本文件规定，为计数目的定义的任何LFB元素都被指定为单调递增，直到达到最大值为止，当它环绕并从零开始再次递增时。本文档还说明了实现的问题是如何维护无符号整数元素，以处理计数器换行或因任何原因重置时计数器不连续等问题。如果预计CE对计数器元素的理解比上述更多，则可能需要CE和FE之间对该元素的专用定义。
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.
基于原子数据类型并使用FE模型XML模式中的类型定义元素，可以定义新的数据类型、数据包帧类型和元数据类型。
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.
要为典型路由器功能定义基本LFB库，应定义一组基本数据类型、帧类型和元数据类型。本节简要介绍了基本类型以及它们的完整XML定义。
The base type XML definitions are provided with a separate XML library file named "BaseTypeLibrary". Users can refer to this library by the statement:
基本类型XML定义随一个名为“BaseTypeLibrary”的单独XML库文件提供。用户可以通过以下语句引用此库：
<load library="BaseTypeLibrary" location="..."/>
<load library="BaseTypeLibrary" location="..."/>
Data types defined in the base type library are categorized by the following types: atomic, compound struct, and compound array.
基本类型库中定义的数据类型按以下类型分类：原子、复合结构和复合数组。
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 type
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 type
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 table
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 table
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:
复合数组类型主要是基于LFB表组件的复合结构类型创建的。此基本类型库中定义了以下复合数组类型：
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 table
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 table
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.
根据FE模型[RFC5812]，LFB定义中使用帧类型来定义LFB在其输入端口期望的数据包帧类型以及LFB在其输出端口发射的数据包帧类型。FE模型中的<frameDef>元素用于定义新的框架类型。
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 frames
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 frames
LFB metadata is used to communicate per-packet state from one LFB to another. The <metadataDef> element in the FE model is used to define a new metadata type.
LFB元数据用于将每个数据包状态从一个LFB传递到另一个LFB。FE模型中的<metadataDef>元素用于定义新的元数据类型。
The following metadata types are currently 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 media
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 media
<?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>
<?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>
<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>
<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">
<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>
<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>
<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>
<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>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>
<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>
<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">
</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>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>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>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>
<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">
<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>
<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>
</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>
<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>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>
<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>
</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>
<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.
<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>
<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="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>
</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>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>
<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>
</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>
According to ForCES specifications, an LFB (Logical Function Block) is a well-defined, logically separable functional block that resides in an FE and is a functionally accurate abstraction of the FE's processing capabilities. An LFB class (or type) is a template that represents a fine-grained, logically separable aspect of FE processing. Most LFBs are related to packet processing in the data path. LFB classes are the basic building blocks of the FE model. Note that [RFC5810] has already defined an 'FE Protocol LFB', which is a logical entity in each FE to control the ForCES protocol. [RFC5812] has already defined an 'FE Object LFB'. Information like the FE Name, FE ID, FE State, and LFB Topology in the FE are represented in this LFB.
根据ForCES规范，LFB（逻辑功能块）是一个定义良好、逻辑上可分离的功能块，位于FE中，是FE处理能力的功能精确抽象。LFB类（或类型）是表示FE处理的细粒度、逻辑上可分离方面的模板。大多数LFB与数据路径中的数据包处理有关。LFB类是FE模型的基本构建块。请注意，[RFC5810]已经定义了一个“FE协议LFB”，它是每个FE中控制ForCES协议的逻辑实体。[RFC5812]已定义“FE对象LFB”。FE中的FE名称、FE ID、FE状态和LFB拓扑等信息在此LFB中表示。
As specified in Section 3.1, this document focuses on the base LFB library for implementing typical router functions, especially for IP forwarding functions. As a result, LFB classes in the library are all base LFBs to implement router forwarding.
如第3.1节所述，本文件重点介绍用于实现典型路由器功能，特别是IP转发功能的基本LFB库。因此，库中的LFB类都是实现路由器转发的基本LFB。
In this section, the terms "upstream LFB" and "downstream LFB" are used. These are used relative to the LFB that is being described. An "upstream LFB" is one whose output ports are connected to input ports of the LFB under consideration such that output (typically packets with metadata) can be sent from the "upstream LFB" to the LFB under consideration. Similarly, a "downstream LFB" whose input ports
在本节中，使用术语“上游LFB”和“下游LFB”。这些是相对于所描述的LFB使用的。“上游LFB”是其输出端口连接到考虑中的LFB的输入端口的一个，使得输出（通常是带有元数据的分组）可以从“上游LFB”发送到考虑中的LFB。类似地，一个“下游LFB”，其输入端口
are connected to output ports of the LFB under consideration such that the LFB under consideration can send information to the "downstream LFB". Note that in some rare topologies, an LFB may be both upstream and downstream relative to another LFB.
连接到正在考虑的LFB的输出端口，以便正在考虑的LFB可以向“下游LFB”发送信息。注意，在一些罕见的拓扑中，LFB可以是相对于另一LFB的上游和下游。
Also note that, as a default provision of [RFC5812], in the FE model, all metadata produced by upstream LFBs will pass through all downstream LFBs by default without being specified by input port or output port. Only those metadata that will be used (consumed) by an LFB will be explicitly marked in the input of the LFB as expected metadata. For instance, in downstream LFBs of a physical-layer LFB, even if there is no specific metadata expected, metadata like PHYPortID produced by the physical-layer LFB will always pass through all downstream LFBs regardless of whether or not the metadata has been expected by the LFBs.
还请注意，作为[RFC5812]的默认规定，在FE模型中，上游LFB生成的所有元数据将默认通过所有下游LFB，而不由输入端口或输出端口指定。只有LFB将使用（使用）的元数据才会在LFB的输入中显式标记为预期元数据。例如，在物理层LFB的下游LFB中，即使没有预期的特定元数据，由物理层LFB产生的诸如PHYPortID的元数据将始终通过所有下游LFB，而不管LFB是否预期元数据。
As the most popular physical- and data-link-layer protocol, Ethernet is widely deployed. It becomes a basic requirement for a router to be able to process various Ethernet data packets.
以太网作为最流行的物理层和数据链路层协议，得到了广泛的应用。能够处理各种以太网数据包成为路由器的基本要求。
Note that different versions of Ethernet formats exist, like Ethernet V2, 802.3 RAW, IEEE 802.3/802.2, and IEEE 802.3/802.2 SNAP. Varieties of LAN techniques based on Ethernet also exist, like various VLANs, MACinMAC, etc. Ethernet-processing LFBs defined here are intended to be able to cope with all these variations of Ethernet technology.
请注意，存在不同版本的以太网格式，如Ethernet V2、802.3 RAW、IEEE 802.3/802.2和IEEE 802.3/802.2 SNAP。基于以太网的各种LAN技术也存在，如各种VLAN、MACinMAC等。此处定义的以太网处理LFB旨在能够应对所有这些以太网技术的变化。
There are also various types of Ethernet physical interface media. Among them, copper and fiber media may be the most popular ones. As a base LFB definition and a starting point, this document only defines an Ethernet physical LFB with copper media. For other media interfaces, specific LFBs may be defined in future versions of the library.
还有各种类型的以太网物理接口介质。其中，铜和光纤介质可能是最受欢迎的介质。作为基本LFB定义和起点，本文档仅定义一个带有铜质介质的以太网物理LFB。对于其他媒体接口，可在库的未来版本中定义特定LFB。
EtherPHYCop LFB abstracts an Ethernet interface physical layer with media limited to copper.
EtherPHYCop LFB抽象了一个以太网接口物理层，介质仅限于铜。
This LFB is the interface to the Ethernet physical media. The LFB handles Ethernet frames coming in from or going out of the FE. Ethernet frames sent and received cover all packets encapsulated with different versions of Ethernet protocols, like Ethernet V2, 802.3 RAW, IEEE 802.3/802.2, and IEEE 802.3/802.2 SNAP, including packets
该LFB是以太网物理介质的接口。LFB处理从FE传入或传出的以太网帧。发送和接收的以太网帧包括使用不同版本的以太网协议封装的所有数据包，如以太网V2、802.3 RAW、IEEE 802.3/802.2和IEEE 802.3/802.2 SNAP，包括数据包
encapsulated with varieties of LAN techniques based on Ethernet, like various VLANs, MACinMAC, etc. Therefore, in the XML, an EthernetAll frame type has been introduced.
封装了各种基于以太网的局域网技术，如各种VLAN、MACinMAC等。因此，在XML中引入了EthernetAll帧类型。
Ethernet frames are received from the physical media port and passed downstream to LFBs, such as EtherMACIn LFBs, via a singleton output known as "EtherPHYOut". A PHYPortID metadata, which indicates the physical port from which the frame came in from the external world, is passed along with the frame.
以太网帧从物理媒体端口接收，并通过称为“EtherPHYOut”的单态输出向下游传递到LFB，如EtherMACIn LFB。PHYPortID元数据指示帧从外部世界传入的物理端口，它与帧一起传递。
Ethernet packets are received by this LFB from upstream LFBs, such as EtherMacOut LFBs, via the singleton input known as "EtherPHYIn" before being sent out to the external world.
以太网数据包由该LFB通过称为“EtherPHYIn”的单态输入从上游LFB（如EtherMacOut LFB）接收，然后发送到外部世界。
The AdminStatus component is defined for the CE to 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 set to 'Down'.
AdminStatus组件是为CE定义的，用于管理LFB的状态。CE可以通过更改AdminStatus的值来管理地启动或关闭LFB。默认值设置为“向下”。
An OperStatus component captures the physical port operational status. A PHYPortStatusChanged event is defined so the LFB can report to the CE whenever there is an operational status change of the physical port.
OperaStatus组件捕获物理端口的操作状态。定义PHYPortStatusChanged事件，以便LFB可以在物理端口的操作状态发生变化时向CE报告。
The PHYPortID component is a unique identification for a physical port. It is defined as 'read-only' by the CE. Its value is enumerated by FE. The component will be used to produce a PHYPortID metadata at the LFB output and to associate it to every Ethernet packet this LFB receives. The metadata will be handed to downstream LFBs for them to use the PHYPortID.
PHYPortID组件是物理端口的唯一标识。CE将其定义为“只读”。其值由FE枚举。该组件将用于在LFB输出处生成PHYPortID元数据，并将其与LFB接收的每个以太网数据包相关联。元数据将交给下游LFB，以便它们使用PHYPortID。
A group of components are defined for link speed management. The AdminLinkSpeed is for the CE to configure link speed for the port, and the OperLinkSpeed is for the CE to query the actual link speed in operation. The default value for the AdminLinkSpeed is set to auto-negotiation mode.
为链路速度管理定义了一组组件。AdminLinkSpeed用于CE为端口配置链路速度，OperLinkSpeed用于CE查询运行中的实际链路速度。AdminLinkSpeed的默认值设置为自动协商模式。
A group of components are defined for duplex mode management. The AdminDuplexMode is for the CE to configure proper duplex mode for the port, and the OperDuplexMode is for CE to query the actual duplex mode in operation. The default value for the AdminDuplexMode is set to auto-negotiation mode.
为双工模式管理定义了一组组件。AdminDuplexMode用于CE为端口配置适当的双工模式，OperDuplexMode用于CE查询实际运行的双工模式。AdminDuplexMode的默认值设置为自动协商模式。
A CarrierStatus component captures the status of the carrier and specifies whether the port link is operationally up. The default value for the CarrierStatus is 'false'.
CarrierStatus组件捕获承运人的状态，并指定端口链路是否处于运行状态。CarrierStatus的默认值为“false”。
The capability information for this LFB includes the link speeds that are supported by the FE (SupportedLinkSpeed) as well as the supported duplex modes (SupportedDuplexMode).
此LFB的能力信息包括FE（SupportedLinkSpeed）支持的链路速度以及支持的双工模式（SupportedDuplexMode）。
Several events are generated. There is an event for changes in the status of the physical port (PhyPortStatusChanged). Such an event will notify that the physical port status has been changed, and the report will include the new status of the physical port.
生成了几个事件。物理端口的状态发生更改的事件（PhyPortStatusChanged）。此类事件将通知物理端口状态已更改，并且报告将包括物理端口的新状态。
Another event captures changes in the operational link speed (LinkSpeedChanged). Such an event will notify the CE that the operational speed has been changed, and the report will include the new negotiated operational speed.
另一个事件捕获操作链路速度的变化（LinkSpeedChanged）。此类事件将通知CE运行速度已更改，报告将包括新协商的运行速度。
A final event captures changes in the duplex mode (DuplexModeChanged). Such an event will notify the CE that the duplex mode has been changed and the report will include the new negotiated duplex mode.
最后一个事件捕获双工模式中的更改（DuplexModeChanged）。此类事件将通知CE双工模式已更改，并且报告将包括新协商的双工模式。
EtherMACIn LFB abstracts an Ethernet port at the MAC data link layer. This LFB describes Ethernet processing functions like checking MAC address locality, deciding if the Ethernet packets should be bridged, providing Ethernet-layer flow control, etc.
EtherMACIn LFB在MAC数据链路层抽象出一个以太网端口。该LFB描述了以太网处理功能，如检查MAC地址位置、决定是否应桥接以太网数据包、提供以太网层流量控制等。
The LFB is expected to receive all types of Ethernet packets (via a singleton input known as "EtherPktsIn"), which are usually output from some Ethernet physical-layer LFB, like an EtherPHYCop LFB, along with a metadata indicating the physical port ID of the port on which the packet arrived.
LFB预计将接收所有类型的以太网数据包（通过称为“Etherpktin”的单例输入），这些数据包通常从一些以太网物理层LFB（如EtherPHYCop LFB）输出，以及指示数据包到达的端口的物理端口ID的元数据。
The LFB is defined with two separate singleton outputs. All output packets are emitted in the original Ethernet format received at the physical port, unchanged, and cover all Ethernet types.
LFB由两个单独的单态输出定义。所有输出数据包以物理端口接收的原始以太网格式发出，保持不变，并覆盖所有以太网类型。
The first singleton output is known as "NormalPathOut". It usually outputs Ethernet packets to some LFB, like an EtherClassifier LFB, for further L3 forwarding process along with a PHYPortID metadata indicating the physical port from which the packet came.
第一个单例输出称为“NormalPathOut”。它通常将以太网数据包输出到某些LFB，如EthernetClassifier LFB，用于进一步的L3转发过程，以及指示数据包来自的物理端口的PHYPortID元数据。
The second singleton output is known as "L2BridgingPathOut". Although the LFB library this document defines is basically to meet typical router functions, it will attempt to be forward compatible with future router functions. The L2BridgingPathOut is defined to meet the requirement that L2 bridging functions may be optionally supported simultaneously with L3 processing and some L2 bridging LFBs that may be defined in the future. If the FE supports L2 bridging, the CE can enable or disable it by means of a "L2BridgingPathEnable" component in the FE. If it is enabled, by also instantiating some L2 bridging LFB instances following the L2BridgingPathOut, FEs are expected to fulfill L2 bridging functions. L2BridgingPathOut will output packets exactly the same as in the NormalPathOut output.
第二个单例输出称为“L2BrigingPathut”。尽管本文定义的LFB库基本上满足典型路由器功能，但它将尝试与未来路由器功能向前兼容。L2BridgeingPathut的定义是为了满足以下要求，即L2桥接功能可以选择性地与L3处理和将来可能定义的一些L2桥接LFB同时支持。如果FE支持L2桥接，CE可以通过FE中的“L2BridgengPathEnable”组件启用或禁用它。如果启用该功能，则通过在L2BridgeingPathout之后实例化一些L2桥接LFB实例，FEs有望实现L2桥接功能。L2BrigingPathout将输出与NormalPathOut输出完全相同的数据包。
This LFB can be set to work in a promiscuous mode, allowing all packets to pass through the LFB without being dropped. Otherwise, a locality check will be performed based on the local MAC addresses. All packets that do not pass through the locality check will be dropped.
该LFB可以设置为在混杂模式下工作，允许所有数据包通过LFB而不会被丢弃。否则，将基于本地MAC地址执行局部性检查。所有未通过位置检查的数据包都将被丢弃。
This LFB can optionally participate in Ethernet flow control in cooperation with EtherMACOut LFB. This document does not go into the details of how this is implemented. This document also does not describe how the buffers that induce the flow control messages behave -- it is assumed that such artifacts exist, and describing them is out of scope in this document.
该LFB可以选择与EtherMACOut LFB合作参与以太网流量控制。本文件未详细说明如何实现这一点。本文档也没有描述导致流控制消息的缓冲区的行为方式——假设存在这样的构件，并且描述它们超出了本文档的范围。
The AdminStatus component is defined for the CE to 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 set to 'Down'.
AdminStatus组件是为CE定义的，用于管理LFB的状态。CE可以通过更改AdminStatus的值来管理地启动或关闭LFB。默认值设置为“向下”。
The LocalMACAddresses component specifies the local MAC addresses based on which locality checks will be made. This component is an array of MAC addresses and of 'read-write' access permission.
LocalMACAddresses组件指定将根据哪些本地MAC地址进行本地检查。此组件是MAC地址和“读写”访问权限的数组。
An L2BridgingPathEnable component captures whether the LFB is set to work as an L2 bridge. An FE that does not support bridging will internally set this flag to false and additionally set the flag property as read-only. The default value for the component is 'false'.
L2BridgengPathEnable组件捕获LFB是否设置为用作L2网桥。不支持桥接的FE将在内部将此标志设置为false，并另外将标志属性设置为只读。组件的默认值为“false”。
The PromiscuousMode component specifies whether the LFB is set to work in a promiscuous mode. The default value for the component is 'false'.
PromiscuousMode组件指定LFB是否设置为在混杂模式下工作。组件的默认值为“false”。
The TxFlowControl component defines whether the LFB is performing flow control on sending packets. The default value is 'false'. Note that the component is defined as "optional". If an FE does not implement the component while a CE tries to configure the component to that FE, an error from the FE may be responded to the CE with an error code like 0x09 (E_COMPONENT_DOES_NOT_EXIST) or 0x15 (E_NOT_SUPPORTED), depending on the FE processing. See [RFC5810] for details.
TxFlowControl组件定义LFB是否在发送数据包时执行流控制。默认值为“false”。请注意，组件定义为“可选”。如果FE在CE尝试将组件配置到该FE时未实现该组件，则FE的错误可能会以错误代码0x09（E_component_不存在）或0x15（E_不受支持）响应给CE，具体取决于FE处理。详见[RFC5810]。
The RxFlowControl component defines whether the LFB is performing flow control on receiving packets. The default value is 'false'. The component is defined as "optional".
RxFlowControl组件定义LFB是否对接收数据包执行流控制。默认值为“false”。该组件被定义为“可选”。
A struct component, MACInStats, defines a set of statistics for this LFB, including the number of received packets and the number of dropped packets. Note that this statistics component is optional to implementers. If a CE tries to query the component while it is not implemented in an FE, an error code will be responded to the CE indicating the error type like 0x09 (E_COMPONENT_DOES_NOT_EXIST) or 0x15 (E_NOT_SUPPORTED), depending on the FE implementation.
结构组件MACInStats为此LFB定义了一组统计信息，包括接收数据包的数量和丢弃数据包的数量。注意，这个统计组件对于实现者是可选的。如果CE试图查询未在FE中实现的组件，则会向CE响应一个错误代码，指示错误类型，如0x09（E_组件不存在）或0x15（E_不受支持），具体取决于FE实现。
This LFB does not have a list of capabilities.
此LFB没有功能列表。
This LFB does not have any events specified.
此LFB未指定任何事件。
The EtherClassifier LFB abstracts the process to decapsulate Ethernet packets and then classify them.
EtherClassifier LFB抽象出对以太网数据包进行去封装然后对其进行分类的过程。
This LFB describes the process of decapsulating Ethernet packets and classifying them into various network-layer data packets according to information included in the Ethernet packets headers.
本LFB描述了将以太网数据包解封并根据以太网数据包头中包含的信息将其分类为各种网络层数据包的过程。
The LFB is expected to receive all types of Ethernet packets (via a singleton input known as "EtherPktsIn"), which are usually output from an upstream LFB like EtherMACIn LFB. This input is also capable of multiplexing to allow for multiple upstream LFBs to be connected. For instance, when an L2 bridging function is enabled in the EtherMACIn LFB, some L2 bridging LFBs may be applied. In this case, after L2 processing, some Ethernet packets may have to be input to the EtherClassifier LFB for classification, while simultaneously,
LFB预计将接收所有类型的以太网数据包（通过称为“Etherpktin”的单例输入），这些数据包通常从上游LFB（如LFB中的EtherMACIn）输出。该输入还能够多路复用，以允许连接多个上游LFB。例如，当EtherMACIn LFB中启用L2桥接功能时，可以应用一些L2桥接LFB。在这种情况下，在L2处理之后，一些以太网数据包可能必须输入到EtherClassifier LFB进行分类，同时，
packets directly output from EtherMACIn may also need to input to this LFB. This input is capable of handling such a case. Usually, all expected Ethernet packets will be associated with a PHYPortID metadata, indicating the physical port from which the packet comes. In some cases, for instance, in a MACinMAC case, a LogicalPortID metadata may be expected to associate with the Ethernet packet to further indicate the logical port to which the Ethernet packet belongs. Note that PHYPortID metadata is always expected while LogicalPortID metadata is optionally expected.
直接从EtherMACIn输出的数据包也可能需要输入到此LFB。此输入能够处理此类情况。通常，所有预期的以太网数据包都将与PHYPortID元数据相关联，表示数据包来自的物理端口。在某些情况下，例如，在MACinMAC情况下，可以期望logicalport元数据与以太网分组相关联，以进一步指示以太网分组所属的逻辑端口。请注意，PHYPortID元数据始终是预期的，而LogicalPortID元数据是可选的。
Two output LFB ports are defined.
定义了两个输出LFB端口。
The first output is a group output port known as "ClassifyOut". Types of network-layer protocol packets are output to instances of the port group. Because there may be various types of protocol packets at the output ports, the produced output frame is defined as arbitrary for the purpose of wide extensibility in the future. Metadata to be carried along with the packet data is produced at this LFB for consumption by downstream LFBs. The metadata passed downstream includes PHYPortID, as well as information on Ethernet type, source MAC address, destination MAC address, and the logical port ID. If the original packet is a VLAN packet and contains a VLAN ID and a VLAN priority value, then the VLAN ID and the VLAN priority value are also carried downstream as metadata. As a result, the VLAN ID and priority metadata are defined with the availability of "conditional".
第一个输出是称为“ClassifyOut”的组输出端口。网络层协议数据包的类型被输出到端口组的实例。由于在输出端口处可能存在各种类型的协议分组，因此为了将来的广泛扩展性，所产生的输出帧被定义为任意的。与分组数据一起携带的元数据在此LFB处生成，供下游LFB使用。在下游传递的元数据包括PHYPortID，以及有关以太网类型、源MAC地址、目标MAC地址和逻辑端口ID的信息。如果原始数据包是VLAN数据包，并且包含VLAN ID和VLAN优先级值，则VLAN ID和VLAN优先级值也作为元数据携带到下游。因此，VLAN ID和优先级元数据定义为“条件”可用性。
The second output is a singleton output port known as "ExceptionOut", which will output packets for which the data processing failed, along with an additional ExceptionID metadata to indicate what caused the exception. Currently defined exception types include:
第二个输出是一个称为“ExceptionOut”的单例输出端口，它将输出数据处理失败的数据包，以及一个额外的ExceptionID元数据，以指示导致异常的原因。当前定义的异常类型包括：
o There is no matching when classifying the packet.
o 对数据包进行分类时没有匹配项。
Usually, the ExceptionOut port may point to nowhere, indicating packets with exceptions are dropped, while in some cases, the output may be pointed to the path to the CE for further processing, depending on individual implementations.
通常，ExceptionOut端口可能不指向任何地方，表示丢弃了带有异常的数据包，而在某些情况下，输出可能指向CE的路径以进行进一步处理，具体取决于各个实现。
An EtherDispatchTable array component is defined in the LFB to dispatch every Ethernet packet to the output group according to the logical port ID assigned by the VlanInputTable to the packet and the Ethernet type in the Ethernet packet header. Each row of the array is a struct containing a logical port ID, an EtherType and an output index. With the CE configuring the dispatch table, the LFB can be expected to classify various network-layer protocol type packets and
LFB中定义了EtherDispatchTable阵列组件，以根据VLAN分配的逻辑端口ID（可输入到数据包）和以太网数据包报头中的以太网类型，将每个以太网数据包分派到输出组。数组的每一行都是一个包含逻辑端口ID、EtherType和输出索引的结构。通过CE配置调度表，LFB可以对各种网络层协议类型的数据包和数据包进行分类
output them at different output ports. It is expected that the LFB classify packets according to protocols like IPv4, IPv6, MPLS, Address Resolution Protocol (ARP), Neighbor Discovery (ND), etc.
在不同的输出端口输出它们。预计LFB将根据IPv4、IPv6、MPLS、地址解析协议（ARP）、邻居发现（ND）等协议对数据包进行分类。
A VlanInputTable array component is defined in the LFB to classify VLAN Ethernet packets. Each row of the array is a struct containing an incoming port ID, a VLAN ID, and a logical port ID. According to IEEE VLAN specifications, all Ethernet packets can be recognized as VLAN types by defining that if there is no VLAN encapsulation in a packet, a case with VLAN tag 0 is considered. Every input packet is assigned with a new LogicalPortID according to the packet's incoming port ID and the VLAN ID. A packet's incoming port ID is defined as a logical port ID if a logical port ID is associated with the packet or a physical port ID if no logical port ID is associated. The VLAN ID is exactly the VLAN ID in the packet if it is a VLAN packet, or 0 if it is not. Note that a logical port ID of a packet may be rewritten with a new one by the VlanInputTable processing.
LFB中定义了一个VLAN可输入阵列组件，用于对VLAN以太网数据包进行分类。阵列的每一行都是一个包含传入端口ID、VLAN ID和逻辑端口ID的结构。根据IEEE VLAN规范，通过定义如果数据包中没有VLAN封装，则考虑VLAN标记为0的情况，可以将所有以太网数据包识别为VLAN类型。根据数据包的传入端口ID和VLAN ID，为每个输入数据包分配一个新的LogicalPortID。如果逻辑端口ID与数据包关联，则数据包的传入端口ID定义为逻辑端口ID；如果没有逻辑端口ID关联，则定义为物理端口ID。如果是VLAN数据包，则VLAN ID正好是数据包中的VLAN ID；如果不是，则为0。注意，分组的逻辑端口ID可以通过vlan可输入处理用新的重写。
Note that the logical port ID and physical port ID mentioned above are all originally configured by the CE, and are globally effective within a ForCES NE (Network Element). To distinguish a physical port ID from a logical port ID in the incoming port ID field of the VlanInputTable, physical port ID and logical port ID must be assigned with separate number spaces.
注意，上面提到的逻辑端口ID和物理端口ID最初都是由CE配置的，并且在ForCES NE（网元）内全局有效。要在VLANInputable的传入端口ID字段中区分物理端口ID和逻辑端口ID，必须为物理端口ID和逻辑端口ID分配单独的数字空间。
An array component, EtherClassifyStats, defines a set of statistics for this LFB, measuring the number of packets per EtherType. Each row of the array is a struct containing an EtherType and a packet number. Note that this statistics component is optional to implementers.
数组组件EtherClassifyStats为该LFB定义了一组统计信息，用于测量每个EtherType的数据包数。数组的每一行都是一个包含EtherType和数据包编号的结构。注意，这个统计组件对于实现者是可选的。
This LFB does not have a list of capabilities.
此LFB没有功能列表。
This LFB has no events specified.
此LFB未指定任何事件。
The EtherEncap LFB abstracts the process to replace or attach appropriate Ethernet headers to the packet.
Ethernecap LFB对替换或将适当的以太网头附加到数据包的过程进行抽象。
This LFB abstracts the process of encapsulating Ethernet headers onto received packets. The encapsulation is based on passed metadata.
该LFB抽象了将以太网报头封装到接收到的数据包上的过程。封装基于传递的元数据。
The LFB is expected to receive IPv4 and IPv6 packets (via a singleton input port known as "EncapIn"), which may be connected to an upstream LFB like IPv4NextHop, IPv6NextHop, BasicMetadataDispatch, or any LFB that requires output packets for Ethernet encapsulation. The LFB always expects from upstream LFBs the MediaEncapInfoIndex metadata, which is used as a search key to look up the encapsulation table EncapTable by the search key matching the table index. An input packet may also optionally receive a VLAN priority metadata, indicating that the packet originally had a priority value. The priority value will be loaded back to the packet when encapsulating. The optional VLAN priority metadata is defined with a default value of 0.
LFB预计将接收IPv4和IPv6数据包（通过称为“EncapIn”的单一输入端口），这些数据包可以连接到上游LFB，如IPv4NextHop、IPv6NextHop、BasicMetadataDispatch或任何需要输出数据包进行以太网封装的LFB。LFB始终希望从上游LFB获得MediaEncapInfoIndex元数据，该元数据用作搜索键，以查找可由匹配表索引的搜索键封装的封装表。输入分组还可以可选地接收VLAN优先级元数据，指示分组最初具有优先级值。封装时，优先级值将加载回数据包。使用默认值0定义了可选VLAN优先级元数据。
Two singleton output LFB ports are defined.
定义了两个单例输出LFB端口。
The first singleton output is known as "SuccessOut". Upon 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 in case VLANs are used. By default, the table entry for VlanID of 0 is used as per IEEE rules [IEEE.802-1Q]. Whatever the value of VlanID, if the input metadata VlanPriority is non-zero, the packet will have a VLAN tag. If the VlanPriority and the VlanID are all zero, there is no VLAN tag for this packet. After replacing or attaching the appropriate Ethernet headers to the packet is complete, the packet is passed out on the "SuccessOut" LFB port to a downstream LFB instance along with the L2PortID.
第一个单例输出称为“SuccessOut”。成功查找表后，将在匹配的表条目中找到目标和源MAC地址以及逻辑媒体端口（L2PortID）。如果使用VLAN，CE可以设置VlanID。默认情况下，VlanID为0的表项根据IEEE规则[IEEE.802-1Q]使用。无论VlanID的值是什么，如果输入元数据VlanPriority为非零，则数据包将具有VLAN标记。如果VLAN优先级和VlanID均为零，则此数据包没有VLAN标记。在将适当的以太网报头替换或附加到数据包后，数据包将在“SuccessOut”LFB端口上与L2PortID一起传递到下游LFB实例。
The second singleton output is known as "ExceptionOut" and will output packets for which the table lookup fails, along with an additional ExceptionID metadata. Currently defined exception types only include the following cases:
第二个单例输出称为“ExceptionOut”，它将输出表查找失败的数据包以及额外的ExceptionID元数据。当前定义的异常类型仅包括以下情况：
o The MediaEncapInfoIndex value of the packet is invalid and can not be allocated in the EncapTable.
o 数据包的MediaEncapInfoIndex值无效，无法在可封装中分配。
o The packet failed lookup of the EncapTable table even though the MediaEncapInfoIndex is valid.
o 即使MediaEncapInfoIndex有效，数据包也无法查找可封装表。
The upstream LFB may be programmed by the CE to pass along a MediaEncapInfoIndex that does not exist in the EncapTable. This allows for resolution of the L2 headers, if needed, to be made at the L2 encapsulation level, in this case, Ethernet via ARP or ND (or other methods depending on the link-layer technology), when a table miss occurs.
CE可对上游LFB进行编程，使其沿着可封装材料中不存在的MediaEncapInfoIndex传递。如果需要，这允许在L2封装级别解析L2报头，在这种情况下，当发生表丢失时，通过ARP或ND（或其他方法，取决于链路层技术）进行以太网解析。
For neighbor L2 header resolution (table miss exception), the processing LFB may pass this packet to the CE via the redirect LFB or
对于相邻L2报头解析（表未命中异常），处理LFB可以通过重定向LFB或
FE software or another LFB instance for further resolution. In such a case, the metadata NextHopIPv4Addr or NextHopIPv6Addr generated by the next-hop LFB is also passed to the exception handling. Such an IP address could be used to do activities such as ARP or ND by the handler to which it is passed.
FE软件或其他LFB实例，以进一步解决问题。在这种情况下，下一跳LFB生成的元数据NextHopIPv4Addr或NextHopIPv6Addr也会传递给异常处理。这样的IP地址可以被传递到的处理程序用来执行诸如ARP或ND之类的活动。
The result of the L2 resolution is to update the EncapTable as well as the next-hop LFB so subsequent packets do not fail EncapTable lookup. The EtherEncap LFB does not make any assumptions of how the EncapTable is updated by the CE (or whether ARP/ND is used dynamically or static maps exist).
L2解析的结果是更新可封装以及下一跳LFB，以便后续数据包不会导致可封装查找失败。Ethernecap LFB没有对CE如何更新可封装进行任何假设（或者ARP/ND是动态使用还是存在静态映射）。
Downstream LFB instances could be either an EtherMACOut type or a BasicMetadataDispatch type. If the final packet L2 processing is on a per-media-port basis, resides 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 is a direct egress port point, then it makes sense for the model to have a downstream LFB instance be an EtherMACOut.
下游LFB实例可以是EtherMACOut类型或BasicMetadataDispatch类型。如果最终的数据包L2处理基于每个媒体端口，驻留在不同的FE上，或者需要L2报头解析，那么模型使用BasicMetadataDispatch LFB扇出到不同的LFB实例是有意义的。如果存在一个直接出口端口点，那么模型将下游LFB实例作为EtherMACOut是有意义的。
This LFB has only one component named EncapTable, which is defined as an array. Each row of the array 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.
这个LFB只有一个名为EncapTable的组件，它被定义为数组。阵列的每一行都是一个结构，包含目标MAC地址、源MAC地址、默认值为零的VLAN ID和输出逻辑L2端口ID。
This LFB does not have a list of capabilities.
此LFB没有功能列表。
This LFB does not have any events specified.
此LFB未指定任何事件。
The EtherMACOut LFB abstracts an Ethernet port at the MAC data link layer. This LFB describes Ethernet packet output process. Ethernet output functions are closely related to Ethernet input functions; therefore, many components defined in this LFB are aliases of EtherMACIn LFB components.
EtherMACOut LFB在MAC数据链路层抽象出一个以太网端口。本LFB描述以太网数据包输出过程。以太网输出功能与以太网输入功能密切相关；因此，本LFB中定义的许多组件都是EtherMACIn LFB组件的别名。
The LFB is expected to receive all types of Ethernet packets (via a singleton input known as "EtherPktsIn"), which are usually output from an Ethernet encapsulation LFB along with a metadata indicating the ID of the physical port that the packet will go through.
LFB预计将接收所有类型的以太网数据包（通过称为“Etherpktin”的单例输入），这些数据包通常从以太网封装LFB输出，以及指示数据包将经过的物理端口ID的元数据。
The LFB is defined with a singleton output port known as "EtherPktsOut". All output packets are in Ethernet format, possibly with various Ethernet types, along with a metadata indicating the ID of the physical port that the packet is to go through. This output links to a downstream LFB that is usually an Ethernet physical LFB like the EtherPHYCop LFB.
LFB由一个称为“EtherPktsOut”的单例输出端口定义。所有输出数据包都是以太网格式，可能具有各种以太网类型，以及指示数据包要通过的物理端口ID的元数据。该输出链接到下游LFB，该LFB通常是以太网物理LFB，如EtherPHYCop LFB。
This LFB can optionally participate in Ethernet flow control in cooperation with the EtherMACIn LFB. This document does not go into the details of how this is implemented. This document also does not describe how the buffers that induce the flow control messages behave -- it is assumed that such artifacts exist, but describing them is out of the scope of this document.
该LFB可以与EtherMACIn LFB合作，选择性地参与以太网流量控制。本文件未详细说明如何实现这一点。本文档也没有描述导致流控制消息的缓冲区的行为方式——假设存在这样的构件，但是描述它们超出了本文档的范围。
Note that as a base definition, functions like multiple virtual MAC layers are not supported in this LFB version. It may be supported in the future by defining a subclass or a new version of this LFB.
请注意，作为基本定义，此LFB版本不支持多个虚拟MAC层等功能。将来可以通过定义子类或此LFB的新版本来支持它。
The AdminStatus component is defined for the CE to 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 set to 'Down'. Note that this component is defined as an alias of the AdminStatus component in the EtherMACIn LFB. This infers that an EtherMACOut LFB usually coexists with an EtherMACIn LFB, both of which share the same administrative status management by the CE. Alias properties, as defined in the ForCES FE model [RFC5812], will be used by the CE to declare the target component to which the alias refers, which includes the target LFB class and instance IDs as well as the path to the target component.
AdminStatus组件是为CE定义的，用于管理LFB的状态。CE可以通过更改AdminStatus的值来管理地启动或关闭LFB。默认值设置为“向下”。请注意，此组件定义为EtherMACIn LFB中AdminStatus组件的别名。这意味着EtherMACOut LFB通常与EtherMACIn LFB共存，两者共享由CE管理的相同管理状态。CE将使用ForCES FE模型[RFC5812]中定义的别名属性来声明别名所引用的目标组件，其中包括目标LFB类和实例ID以及目标组件的路径。
The MTU component defines the maximum transmission unit.
MTU组件定义了最大传输单位。
The optional TxFlowControl component defines whether or not the LFB is performing flow control on sending packets. The default value is 'false'. Note that this component is defined as an alias of the TxFlowControl component in the EtherMACIn LFB.
可选的TxFlowControl组件定义LFB是否在发送数据包时执行流控制。默认值为“false”。请注意，此组件定义为EtherMACIn LFB中TxFlowControl组件的别名。
The optional RxFlowControl component defines whether or not the LFB is performing flow control on receiving packets. The default value
可选的RxFlowControl组件定义LFB是否对接收数据包执行流控制。默认值
is 'false'. Note that this component is defined as an alias of the RxFlowControl component in the EtherMACIn LFB.
是“假”。注意，该组件被定义为EtherMACIn LFB中RxFlowControl组件的别名。
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.
结构组件MACOutStats为该LFB定义了一组统计信息，包括传输数据包的数量和丢弃数据包的数量。此统计组件对于实现者是可选的。
This LFB does not have a list of capabilities.
此LFB没有功能列表。
This LFB does not have any events specified.
此LFB未指定任何事件。
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.
LFB被定义为抽象IP数据包验证过程。IPv4验证程序LFB专门用于IPv4协议验证，IPv6验证程序LFB专门用于IPv6。
The IPv4Validator LFB performs IPv4 packet validation.
IPv4Validator LFB执行IPv4数据包验证。
This LFB performs IPv4 validation according to [RFC1812] 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.
此LFB根据[RFC1812]及其更新执行IPv4验证。IPv4数据包将输出到相应的LFB端口，指示数据包是单播还是多播，或者是否发生异常或验证失败。
This LFB always expects, as input, packets that have been indicated as IPv4 packets by an upstream LFB, like an EtherClassifier LFB. There is no specific metadata expected by the input of the LFB.
该LFB始终期望上游LFB（如以太分类器LFB）指示为IPv4数据包的数据包作为输入。LFB的输入不需要特定的元数据。
Four output LFB ports are defined.
定义了四个输出LFB端口。
All validated IPv4 unicast packets will be output at the singleton port known as "IPv4UnicastOut". All validated IPv4 multicast packets will be output at the singleton port known as "IPv4MulticastOut" port.
所有经过验证的IPv4单播数据包都将在称为“IPv4UnicastOut”的单一端口上输出。所有经过验证的IPv4多播数据包都将在称为“IPV4Multicastot”端口的单一端口上输出。
A singleton port known as "ExceptionOut" is defined to output packets that have been validated as exception packets. An exception ID metadata is produced to indicate what has caused the exception. An exception case is the case when a packet needs further processing
一个称为“ExceptionOut”的单例端口被定义为输出已验证为异常数据包的数据包。生成异常ID元数据以指示导致异常的原因。例外情况是指数据包需要进一步处理的情况
before being normally forwarded. Currently defined exception types include:
在正常转发之前。当前定义的异常类型包括：
o Packet with expired TTL
o 具有过期TTL的数据包
o Packet with header length more than 5 words
o 标头长度超过5个字的数据包
o Packet IP head including router alert options
o 包IP头，包括路由器警报选项
o Packet with exceptional source address
o 具有异常源地址的数据包
o Packet with exceptional destination address
o 具有异常目的地址的数据包
Note that although Time to Live (TTL) is checked in this LFB for validity, operations like TTL decrement are made by the downstream forwarding LFB.
请注意，尽管在该LFB中检查生存时间（TTL）的有效性，但诸如TTL递减之类的操作是由下游转发LFB进行的。
The final singleton port known as "FailOut" is defined for all packets that have errors and failed the validation process. An error case is when a packet is unable to be further processed or forwarded without being dropped. An error ID is associated with a packet to indicate the failure reason. Currently defined failure reasons include:
最后一个称为“FailOut”的单例端口是为所有有错误且验证过程失败的数据包定义的。错误情况是指数据包在未被丢弃的情况下无法进一步处理或转发。错误ID与数据包关联，以指示故障原因。目前定义的故障原因包括：
o Packet with size reported less than 20 bytes
o 报告大小小于20字节的数据包
o Packet with version not IPv4
o 版本不是IPv4的数据包
o Packet with header length less than 5 words
o 标头长度小于5个字的数据包
o Packet with total length field less than 20 bytes
o 总长度字段小于20字节的数据包
o Packet with invalid checksum
o 校验和无效的数据包
o Packet with invalid source address
o 源地址无效的数据包
o Packet with invalid destination address
o 目标地址无效的数据包
This LFB has only one struct component, the IPv4ValidatorStatisticsType, which defines a set of statistics for validation process, including 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 to implementers.
此LFB只有一个结构组件IPv4ValidatorStatisticsType，它为验证过程定义了一组统计信息，包括错误头数据包的数量、错误总长度数据包的数量、错误TTL数据包的数量和错误校验和数据包的数量。此统计组件对于实现者是可选的。
This LFB does not have a list of capabilities
此LFB没有功能列表
This LFB does not have any events specified.
此LFB未指定任何事件。
The IPv6Validator LFB performs IPv6 packet validation.
IPv6Validator LFB执行IPv6数据包验证。
This LFB performs IPv6 validation according to [RFC2460] and its updates. Then the IPv6 packet will be output to the corresponding port regarding of the validation result, indicating whether the packet is a unicast or a multicast one, an exception has occurred or the validation failed.
此LFB根据[RFC2460]及其更新执行IPv6验证。然后，IPv6数据包将被输出到相应的端口，与验证结果有关，指示该数据包是单播还是多播，是否发生异常或验证失败。
This LFB always expects, as input, packets that have been indicated as IPv6 packets by an upstream LFB, like an EtherClassifier LFB. There is no specific metadata expected by the input of the LFB.
该LFB始终期望上游LFB（如以太网分类器LFB）指示为IPv6数据包的数据包作为输入。LFB的输入不需要特定的元数据。
Similar to the IPv4validator LFB, the IPv6Validator LFB has also defined four output ports to emit packets with various validation results.
与IPv4validator LFB类似，IPv6Validator LFB还定义了四个输出端口，用于发送具有各种验证结果的数据包。
All validated IPv6 unicast packets will be output at the singleton port known as "IPv6UnicastOut". All validated IPv6 multicast packets will be output at the singleton port known as "IPv6MulticastOut". There is no metadata produced at this LFB.
所有经过验证的IPv6单播数据包都将在称为“IPv6UnicastOut”的单一端口上输出。所有经过验证的IPv6多播数据包都将在称为“IPv6MulticastOut”的单例端口上输出。此LFB没有生成元数据。
A singleton port known as "ExceptionOut" is defined to output packets that have been validated as exception packets. An exception case is when a packet needs further processing before being normally forwarded. An exception ID metadata is produced to indicate what caused the exception. Currently defined exception types include:
一个称为“ExceptionOut”的单例端口被定义为输出已验证为异常数据包的数据包。例外情况是，数据包在正常转发之前需要进一步处理。将生成异常ID元数据，以指示导致异常的原因。当前定义的异常类型包括：
o Packet with hop limit to zero
o 跳数限制为零的数据包
o Packet with next header set to hop-by-hop
o 下一个标头设置为逐跳的数据包
o Packet with exceptional source address
o 具有异常源地址的数据包
o Packet with exceptional destination address
o 具有异常目的地址的数据包
The final singleton port known as "FailOut" is defined for all packets that have errors and failed the validation process. An error case when a packet is unable to be further processed or forwarded without being dropped. A validate error ID is associated to every failed packet to indicate the reason. Currently defined reasons include:
最后一个称为“FailOut”的单例端口是为所有有错误且验证过程失败的数据包定义的。一种错误情况，当数据包不能被进一步处理或转发而不被丢弃。验证错误ID与每个失败的数据包相关联，以指示原因。目前确定的原因包括：
o Packet with size reported less than 40 bytes
o 报告大小小于40字节的数据包
o Packet with version not IPv6
o 版本不是IPv6的数据包
o Packet with invalid source address
o 源地址无效的数据包
o Packet with invalid destination address
o 目标地址无效的数据包
Note that in the base type library, definitions for exception ID and validate error ID metadata are applied to both IPv4Validator and IPv6Validator LFBs, i.e., the two LFBs share the same metadata definition, with different ID assignment inside.
请注意，在基本类型库中，异常ID和验证错误ID元数据的定义应用于IPv4Validator和IPv6Validator LFB，即这两个LFB共享相同的元数据定义，内部具有不同的ID分配。
This LFB has only one struct component, the IPv6ValidatorStatisticsType, which defines 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. Note that this component is optional to implementers.
此LFB只有一个结构组件IPv6ValidatorStatisticsType，它为验证过程定义了一组统计信息，包括坏头数据包的数量、坏总长度数据包的数量和坏跃点限制数据包的数量。请注意，此组件对于实现者是可选的。
This LFB does not have a list of capabilities.
此LFB没有功能列表。
This LFB does not have any events specified.
此LFB未指定任何事件。
IP Forwarding LFBs are specifically defined to abstract the IP forwarding processes. As definitions for a base LFB library, this document restricts its LFB definition scope only to IP unicast forwarding. IP multicast may be defined in future documents.
IP转发LFB是专门为抽象IP转发过程而定义的。作为基本LFB库的定义，本文档将其LFB定义范围仅限于IP单播转发。IP多播可能在将来的文档中定义。
The two fundamental tasks performed in IP unicast forwarding constitute looking up the forwarding information table to find next-hop information and then using the resulting next-hop details to forward packets out on specific physical output ports. This document models the forwarding processes by abstracting out the described two
IP单播转发中执行的两个基本任务是查找转发信息表以查找下一跳信息，然后使用生成的下一跳详细信息将数据包转发到特定的物理输出端口。本文通过抽象出所描述的两个过程来对转发过程进行建模
steps. Whereas this document describes functional LFB models that are modular, there may be multiple ways to implement the abstracted models. It is not intended or expected that the provided LFB models constrain implementations.
步骤。尽管本文档描述了模块化的功能LFB模型，但可能有多种方法来实现抽象模型。提供的LFB模型并不打算或期望约束实现。
Based on the IP forwarding abstraction, two kinds of typical IP unicast forwarding LFBs are defined: unicast LPM lookup LFB and next-hop application LFB. They are further distinguished by IPv4 and IPv6 protocols.
基于IP转发抽象，定义了两种典型的IP单播转发LFB：单播LPM查找LFB和下一跳应用LFB。IPv4和IPv6协议进一步区分了它们。
The IPv4UcastLPM LFB abstracts the IPv4 unicast Longest Prefix Match (LPM) process.
IPv4UcastLPM LFB抽象了IPv4单播最长前缀匹配（LPM）过程。
This LFB also provides facilities to support users 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, additional specific LFBs, like a specific ECMP LFB or an RPF LFB, will have to be defined.
该LFB还提供了支持用户实现等成本多路径（ECMP）路由或反向路径转发（RPF）的设施。但是，该LFB本身不提供ECMP或RPF。要完全实现ECMP或RPF，必须定义其他特定LFB，如特定ECMP LFB或RPF LFB。
This LFB performs the IPv4 unicast LPM table lookup. It always expects as input 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 will usually be used there as a search index to find more next-hop information.
此LFB执行IPv4单播LPM表查找。它总是期望来自一个称为“pktIn”的单例输入的IPv4单播数据包作为输入。然后，LFB使用每个数据包的目标IPv4地址作为搜索键来查找IPv4前缀表，并生成一个跃点选择器作为匹配结果。跃点选择器作为数据包元数据传递给下游LFB，通常在那里用作搜索索引以查找更多下一跳信息。
Three singleton output LFB ports are defined.
定义了三个单例输出LFB端口。
The first singleton output is known as "NormalOut" and outputs IPv4 unicast packets that succeed the LPM lookup (and got a hop selector). The hop selector is associated with the packet as a metadata. Downstream from the LPM LFB is usually a next-hop application LFB, like an IPv4NextHop LFB.
第一个单例输出称为“NormalOut”，输出成功进行LPM查找的IPv4单播数据包（并获得一个跃点选择器）。跃点选择器作为元数据与数据包相关联。LPM LFB的下游通常是下一跳应用程序LFB，如IPv4NextHop LFB。
The second singleton output is known as "ECMPOut" and is defined to provide support for users wishing to implement ECMP.
第二个单例输出称为“ECMPOut”，其定义是为希望实现ECMP的用户提供支持。
An ECMP flag is defined in the LPM table to enable the LFB to support ECMP. When a table entry is created with the flag set to true, it indicates this 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
LPM表中定义了ECMP标志，以使LFB支持ECMP。当创建一个表条目并将标志设置为true时，表示该表条目仅用于ECMP。通过此前缀查找的数据包将始终从“ECMPOut”输出端口输出，跃点选择器是其查找结果。输出通常直接进入下游ECMP处理
LFB, where the hop selector can usually further generate optimized one or multiple next-hop routes by use of ECMP algorithms.
LFB，其中跳选择器通常可以通过使用ECMP算法进一步生成优化的一个或多个下一跳路由。
A default route flag is defined in the LPM table to enable the LFB to 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.
LPM表中定义了默认路由标志，以使LFB支持默认路由和松散RPF。当该标志设置为true时，表条目被标识为默认路由，这也意味着该路由对RPF是禁止的。如果用户希望在FE上实现RPF，则必须定义特定的RPF LFB。在这样的RPF LFB中，可以将组件定义为该LFB的前缀表组件的别名，如下所述。
The final singleton output is known as "ExceptionOut" of the IPv4UcastLPM LFB and is defined to output exception packets after the LFB processing, along with an ExceptionID metadata to indicate what caused the exception. Currently defined exception types include:
最后的单例输出称为IPv4UcastLPM LFB的“ExceptionOut”，定义为在LFB处理后输出异常数据包，以及一个ExceptionID元数据，以指示异常的原因。当前定义的异常类型包括：
o The packet failed the LPM lookup of the prefix table.
o 该数据包未能通过前缀表的LPM查找。
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.
此LFB的上游LFB通常是IPV4验证程序LFB。如果采用RPF，定义时，上游可以是RPF LFB。
The downstream LFB is usually an IPv4NextHop LFB. If ECMP is adopted, the downstream can be an ECMP LFB, when defined.
下游LFB通常为IPv4NextHop LFB。如果采用ECMP，定义时，下游可以是ECMP LFB。
This LFB has two components.
该LFB有两个组件。
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.
IPv4PrefixTable组件被定义为LFB的数组组件。阵列的每一行都包含一个IPv4地址、一个前缀长度、一个跃点选择器、一个ECMP标志和一个默认路由标志。LFB使用每个输入数据包的目标IPv4地址作为搜索键来查找此表，以便提取下一跳选择器。ECMP标志用于LFB支持ECMP。默认路由标志用于LFB支持默认路由和松散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. Note that this component is defined as optional to implementers.
IPv4UcastLPMStats组件是一个结构组件，用于收集统计信息，包括接收的输入数据包总数、此LFB转发的IPv4数据包以及由于未找到路由而丢弃的IP数据报数。注意，该组件被定义为实现者的可选组件。
This LFB does not have a list of capabilities.
此LFB没有功能列表。
This LFB does not have any events specified.
此LFB未指定任何事件。
This LFB abstracts the process of selecting IPv4 next-hop action.
此LFB抽象了选择IPv4下一跳操作的过程。
The 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 LFB output port.
LFB将下一跳信息应用过程抽象为IPv4数据包。它接收具有关联的下一跳标识符（HopSelector）的IPv4数据包，并使用该标识符作为表索引来查找下一跳表以找到适当的LFB输出端口。
The LFB is expected to receive unicast IPv4 packets, via a singleton input known as "PktsIn", along with a HopSelector metadata, which is used as a table index to look up the NextHop table. The data processing involves the forwarding TTL decrement and IP checksum recalculation.
LFB预计将通过称为“pktIn”的单例输入以及HopSelector元数据接收单播IPv4数据包，HopSelector元数据用作查找NextHop表的表索引。数据处理包括转发TTL减量和IP校验和重新计算。
Two output LFB ports are defined.
定义了两个输出LFB端口。
The first output is a group output port known as "SuccessOut". On successful data processing, the packet is sent out from an LFB port from within the LFB port group as selected by the LFBOutputSelectIndex value of the matched table entry. The packet is sent to a downstream LFB along with the L3PortID and MediaEncapInfoIndex metadata.
第一个输出是称为“SuccessOut”的组输出端口。数据处理成功后，数据包从LFB端口组内的LFB端口发出，该LFB端口组由匹配表项的LFBOutputSelectIndex值选择。数据包与L3PortID和MediaEncapInfoIndex元数据一起发送到下游LFB。
The second output is a singleton output port known as "ExceptionOut", which will output packets for which the data processing failed, along with an additional ExceptionID metadata to indicate what caused the exception. Currently defined exception types include:
第二个输出是一个称为“ExceptionOut”的单例输出端口，它将输出数据处理失败的数据包，以及一个额外的ExceptionID元数据，以指示导致异常的原因。当前定义的异常类型包括：
o The HopSelector for the packet is invalid.
o 数据包的跃点选择器无效。
o The packet failed lookup of the next-hop table even though the HopSelector is valid.
o 即使跃点选择器有效，数据包也无法查找下一个跃点表。
o The MTU for outgoing interface is less than the packet size.
o 传出接口的MTU小于数据包大小。
Downstream LFB instances could be either a BasicMetadataDispatch type (Section 5.5.1), used to fan out to different LFB instances or a media-encapsulation-related type, such as an EtherEncap type or a RedirectOut type (Section 5.4.2). For example, if there are Ethernet and other tunnel encapsulation, then a BasicMetadataDispatch LFB can
下游LFB实例可以是用于扇出到不同LFB实例的BasicMetadataDispatch类型（第5.5.1节），也可以是与媒体封装相关的类型，例如Ethernecap类型或RedirectOut类型（第5.4.2节）。例如，如果存在以太网和其他隧道封装，则可以使用BasicMetadataDispatch LFB
use the L3PortID metadata (Section 5.3.2.2) to dispatch packets to a different encapsulator.
使用L3PortID元数据（第5.3.2.2节）将数据包分派到不同的封装器。
This LFB has only one component, IPv4NextHopTable, which is defined as an array. The HopSelector received is used to match the array index of IPv4NextHopTable to find out a row of the table as the next-hop information result. Each row of the array is a struct containing:
此LFB只有一个组件IPv4NextHopTable，它被定义为数组。接收到的跃点选择器用于匹配IPv4NextHopTable的数组索引，以查找表中的一行作为下一个跃点信息结果。数组的每一行都是一个结构，包含：
o The L3PortID, which is the ID of the logical output port that is passed on to the downstream LFB instance. This ID indicates what kind of encapsulating port the neighbor is to use. This is L3- derived information that affects L2 processing and so needs to be based from one LFB to another as metadata. Usually, this ID is used for the next-hop LFB to distinguish packets that need different L2 encapsulating. For instance, some packets may require general Ethernet encapsulation while others may require various types of tunnel encapsulations. In such a case, different L3PortIDs are assigned to the packets and are passed as metadata to a downstream LFB. A BasicMetadataDispatch LFB (Section 5.5.1) may have to be applied as the downstream LFB so as to dispatch packets to different encapsulation LFB instances according to the L3PortIDs.
o L3PortID，它是传递给下游LFB实例的逻辑输出端口的ID。此ID指示邻居要使用哪种封装端口。这是影响二级处理的三级派生信息，因此需要作为元数据从一个LFB到另一个LFB。通常，该ID用于下一跳LFB，以区分需要不同L2封装的数据包。例如，一些数据包可能需要通用以太网封装，而其他数据包可能需要各种类型的隧道封装。在这种情况下，不同的L3PortID被分配给分组，并作为元数据传递给下游LFB。可能必须应用BasicMetadataDispatch LFB（第5.5.1节）作为下游LFB，以便根据L3PortID将数据包分派到不同的封装LFB实例。
o MTU, the Maximum Transmission Unit for the outgoing port.
o MTU，输出端口的最大传输单位。
o NextHopIPAddr, the IPv4 next-hop address.
o NextHopIPAddr，IPv4下一跳地址。
o MediaEncapInfoIndex, the index that passes on to the downstream encapsulation LFB instance and that is used there as a search key to look up a table (typically media-encapsulation-related) for further encapsulation information. The search key looks up the table by matching the table index. Note that the encapsulation LFB instance that uses this metadata may not be the LFB instance that immediately follows this LFB instance in the processing. The MediaEncapInfoIndex metadata is attached here and is passed through intermediate LFBs until it is used by the encapsulation LFB instance. In some cases, depending on implementation, the CE may set the MediaEncapInfoIndex passed downstream to a value that will fail lookup when it gets to 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, refer to Section 7.2, which discusses ARP and mentions this approach.
o MediaEncapInfoIndex，传递到下游封装LFB实例的索引，该索引用作搜索键，用于查找表（通常与媒体封装相关）以获取进一步的封装信息。搜索键通过匹配表索引来查找表。请注意，使用此元数据的封装LFB实例可能不是处理中紧跟此LFB实例的LFB实例。MediaEncapInfoIndex元数据附加在这里，并通过中间LFB传递，直到封装LFB实例使用它。在某些情况下，取决于实现，CE可能会将向下游传递的MediaEncapInfoIndex设置为一个值，该值在到达目标封装LFB时将导致查找失败；此时的这种查找失败表明需要进一步解决。有关此方法的示例，请参阅第7.2节，其中讨论了ARP并提到了此方法。
o LFBOutputSelectIndex, the LFB group output port index to select the downstream LFB port. This value identifies the specific port within the SuccessOut port group out of which packets that successfully use this next-hop entry are to be sent.
o LFBOutputSelectIndex，用于选择下游LFB端口的LFB组输出端口索引。此值标识SuccessOut端口组中的特定端口，成功使用此下一跳条目的数据包将从中发送出去。
This LFB does not have a list of capabilities.
此LFB没有功能列表。
This LFB does not have any events specified.
此LFB未指定任何事件。
The IPv6UcastLPM LFB abstracts the IPv6 unicast Longest Prefix Match (LPM) process. The definition of this LFB is similar to the IPv4UcastLPM LFB except that all IP addresses refer to IPv6 addresses.
IPv6UcastLPM LFB抽象了IPv6单播最长前缀匹配（LPM）过程。此LFB的定义与IPv4UcastLPM LFB类似，只是所有IP地址都指IPv6地址。
This LFB also provides facilities to support users 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, additional specific LFBs, like a specific ECMP LFB or an RPF LFB, will have to be defined. This work may be done in future versions of this document.
该LFB还提供了支持用户实现等成本多路径（ECMP）路由或反向路径转发（RPF）的设施。但是，该LFB本身不提供ECMP或RPF。要完全实现ECMP或RPF，必须定义其他特定LFB，如特定ECMP LFB或RPF LFB。这项工作可能在本文件的未来版本中完成。
This LFB performs the IPv6 unicast LPM table lookup. It always expects as input IPv6 unicast packets from one singleton input known as "PktsIn". The destination IPv6 address of an incoming packet is used as a search key to look up the IPv6 prefix table and generate a hop selector. This hop selector result is associated to the packet as a metadata and sent to downstream LFBs; it will usually be used in downstream LFBs as a search key to find more next-hop information.
此LFB执行IPv6单播LPM表查找。它总是期望来自一个称为“pktIn”的单例输入的IPv6单播数据包作为输入。传入数据包的目标IPv6地址用作搜索键，以查找IPv6前缀表并生成跃点选择器。该跳选择器结果作为元数据与分组相关联，并发送到下游lfb；它通常在下游LFB中用作搜索键，以查找更多下一跳信息。
Three singleton output LFB ports are defined.
定义了三个单例输出LFB端口。
The first singleton output is known as "NormalOut" and outputs IPv6 unicast packets that succeed the LPM lookup (and got a hop selector). The hop selector is associated with the packet as a metadata. Downstream from the LPM LFB is usually a next-hop application LFB, like an IPv6NextHop LFB.
第一个单例输出称为“NormalOut”，输出成功完成LPM查找的IPv6单播数据包（并获得一个跳选择器）。跃点选择器作为元数据与数据包相关联。LPM LFB的下游通常是下一跳应用程序LFB，如IPv6NextHop LFB。
The second singleton output is known as "ECMPOut" and is defined to provide support for users wishing to implement ECMP.
第二个单例输出称为“ECMPOut”，其定义是为希望实现ECMP的用户提供支持。
An ECMP flag is defined in the LPM table to enable the LFB to support ECMP. When a table entry is created with the flag set to true, it indicates this 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.
LPM表中定义了ECMP标志，以使LFB支持ECMP。当创建一个表条目并将标志设置为true时，表示该表条目仅用于ECMP。通过此前缀查找的数据包将始终从“ECMPOut”输出端口输出，跃点选择器是其查找结果。输出通常将直接发送到下游ECMP处理LFB，其中跳选择器通常可以使用ECMP算法进一步生成优化的一个或多个下一跳路由。
A default route flag is defined in the LPM table to enable the LFB to 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.
LPM表中定义了默认路由标志，以使LFB支持默认路由和松散RPF。当该标志设置为true时，表条目被标识为默认路由，这也意味着该路由对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.
如果用户希望在FE上实现RPF，则必须定义特定的RPF LFB。在这样的RPF LFB中，可以将组件定义为该LFB的前缀表组件的别名，如下所述。
The final singleton output is known as "ExceptionOut" of the IPv6UcastLPM LFB and is defined to output exception packets after the LFB processing, along with an ExceptionID metadata to indicate what caused the exception. Currently defined exception types include:
最后的单例输出称为IPv6UcastLPM LFB的“ExceptionOut”，定义为在LFB处理后输出异常数据包，以及一个ExceptionID元数据，以指示异常的原因。当前定义的异常类型包括：
o The packet failed the LPM lookup of the prefix table.
o 该数据包未能通过前缀表的LPM查找。
The upstream LFB of this LFB is usually an IPv6Validator LFB. If RPF is to be adopted, the upstream can be an RPF LFB, when defined.
此LFB的上游LFB通常是IPv6Validator LFB。如果采用RPF，定义时，上游可以是RPF LFB。
The downstream LFB is usually an IPv6NextHop LFB. If ECMP is adopted, the downstream can be an ECMP LFB, when defined.
下游LFB通常为IPv6NextHop LFB。如果采用ECMP，定义时，下游可以是ECMP LFB。
This LFB has two components.
该LFB有两个组件。
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 so the LFB can support ECMP. The default route flag is for the LFB to support a default route and for loose RPF, as described earlier.
IPv6PrefixTable组件被定义为LFB的数组组件。阵列的每一行都包含一个IPv6地址、一个前缀长度、一个跃点选择器、一个ECMP标志和一个默认路由标志。ECMP标志为，因此LFB可以支持ECMP。如前所述，默认路由标志用于LFB支持默认路由和松散RPF。
The IPv6UcastLPMStats component is a struct component that collects statistics information, 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 the component is defined as optional to implementers.
IPv6UcastLPMStats组件是一个结构组件，用于收集统计信息，包括接收的输入数据包总数、此LFB转发的IPv6数据包以及由于未找到路由而丢弃的IP数据报数。注意，组件被定义为实现者的可选组件。
This LFB does not have a list of capabilities.
此LFB没有功能列表。
This LFB does not have any events specified.
此LFB未指定任何事件。
This LFB abstracts the process of selecting IPv6 next-hop action.
此LFB抽象了选择IPv6下一跳操作的过程。
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 to look up a next-hop table to find an appropriate output port from the LFB.
LFB将下一跳信息应用过程抽象为IPv6数据包。它接收具有关联的下一跳标识符（HopSelector）的IPv6数据包，并使用该标识符查找下一跳表以从LFB找到适当的输出端口。
The LFB is expected to receive unicast IPv6 packets, via a singleton input known as "PktsIn", along with a HopSelector metadata, which is used as a table index to look up the next-hop table.
LFB预计将通过称为“pktIn”的单例输入接收单播IPv6数据包，以及一个HopSelector元数据，该元数据用作查找下一个hop表的表索引。
Two output LFB ports are defined.
定义了两个输出LFB端口。
The first output is a group output port known as "SuccessOut". On successful data processing, the packet is sent out from an LFB port from within the LFB port group as selected by the LFBOutputSelectIndex value of the matched table entry. The packet is sent to a downstream LFB along with the L3PortID and MediaEncapInfoIndex metadata.
第一个输出是称为“SuccessOut”的组输出端口。数据处理成功后，数据包从LFB端口组内的LFB端口发出，该LFB端口组由匹配表项的LFBOutputSelectIndex值选择。数据包与L3PortID和MediaEncapInfoIndex元数据一起发送到下游LFB。
The second output is a singleton output port known as "ExceptionOut", which will output packets for which the data processing failed, along with an additional ExceptionID metadata to indicate what caused the exception. Currently defined exception types include:
第二个输出是一个称为“ExceptionOut”的单例输出端口，它将输出数据处理失败的数据包，以及一个额外的ExceptionID元数据，以指示导致异常的原因。当前定义的异常类型包括：
o The HopSelector for the packet is invalid.
o 数据包的跃点选择器无效。
o The packet failed lookup of the next-hop table even though the HopSelector is valid.
o 即使跃点选择器有效，数据包也无法查找下一个跃点表。
o The MTU for outgoing interface is less than the packet size.
o 传出接口的MTU小于数据包大小。
Downstream LFB instances could be either a BasicMetadataDispatch type, used to fan out to different LFB instances, or a media encapsulation related type, such as an EtherEncap type or a RedirectOut type. For example, when the downstream LFB is
下游LFB实例可以是BasicMetadataDispatch类型（用于扇出到不同的LFB实例），也可以是与媒体封装相关的类型，例如Ethernecap类型或RedirectOut类型。例如，当下游LFB为
BasicMetadataDispatch and Ethernet and other tunnel encapsulation exist downstream from BasicMetadataDispatch, then the BasicMetadataDispatch LFB can use the L3PortID metadata (see section below) to dispatch packets to the different encapsulator LFBs.
BasicMetadataDispatch和以太网以及其他隧道封装存在于BasicMetadataDispatch的下游，那么BasicMetadataDispatch LFB可以使用L3PortID元数据（参见下面的部分）将数据包分派到不同的封装器LFB。
This LFB has only one component named IPv6NextHopTable, which is defined as an array. The array index of IPv6NextHopTable is used for a HopSelector to find out a row of the table as the next-hop information. Each row of the array is a struct containing:
此LFB只有一个名为IPv6NextHopTable的组件，该组件定义为数组。IPv6NextHopTable的数组索引用于HopSelector查找表中的一行作为下一个跃点信息。数组的每一行都是一个结构，包含：
o The L3PortID, which is the ID of the logical output port that is passed onto the downstream LFB instance. This ID indicates what kind of encapsulating port the neighbor is to use. This is L3- derived information that affects L2 processing and so needs to be based from one LFB to another as metadata. Usually, this ID is used for the next-hop LFB to distinguish packets that need different L2 encapsulating. For instance, some packets may require general Ethernet encapsulation while others may require various types of tunnel encapsulations. In such a case, different L3PortIDs are assigned to the packets and are passed as metadata to a downstream LFB. A BasicMetadataDispatch LFB (Section 5.5.1) may have to be applied as the downstream LFB so as to dispatch packets to different encapsulation LFB instances according to the L3PortIDs.
o L3PortID，它是传递到下游LFB实例的逻辑输出端口的ID。此ID指示邻居要使用哪种封装端口。这是影响二级处理的三级派生信息，因此需要作为元数据从一个LFB到另一个LFB。通常，该ID用于下一跳LFB，以区分需要不同L2封装的数据包。例如，一些数据包可能需要通用以太网封装，而其他数据包可能需要各种类型的隧道封装。在这种情况下，不同的L3PortID被分配给分组，并作为元数据传递给下游LFB。可能必须应用BasicMetadataDispatch LFB（第5.5.1节）作为下游LFB，以便根据L3PortID将数据包分派到不同的封装LFB实例。
o MTU, the Maximum Transmission Unit for the outgoing port.
o MTU，输出端口的最大传输单位。
o NextHopIPAddr, the IPv6 next-hop address.
o NextHopIPAddr，IPv6下一跳地址。
o MediaEncapInfoIndex, the index that is passed on to the downstream encapsulation LFB instance and that is used there as a search key to look up a table (typically media-encapsulation-related) for further encapsulation information. The search key looks up the table by matching the table index. Note that the encapsulation LFB instance that uses this metadata may not be the LFB instance that immediately follows this LFB instance in the processing. The MediaEncapInfoIndex metadata is attached here and is passed through intermediate LFBs until it is used by the encapsulation LFB instance. In some cases, depending on implementation, the CE may set the MediaEncapInfoIndex passed downstream to a value that will fail lookup when it gets to 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, refer to Section 7.2, which discusses ARP and mentions this approach.
o MediaEncapInfoIndex，传递到下游封装LFB实例的索引，在那里用作搜索键，以查找表（通常与媒体封装相关）以获取进一步的封装信息。搜索键通过匹配表索引来查找表。请注意，使用此元数据的封装LFB实例可能不是处理中紧跟此LFB实例的LFB实例。MediaEncapInfoIndex元数据附加在这里，并通过中间LFB传递，直到封装LFB实例使用它。在某些情况下，取决于实现，CE可能会将向下游传递的MediaEncapInfoIndex设置为一个值，该值在到达目标封装LFB时将导致查找失败；此时的这种查找失败表明需要进一步解决。有关此方法的示例，请参阅第7.2节，其中讨论了ARP并提到了此方法。
o LFBOutputSelectIndex, the LFB group output port index to select the downstream LFB port. This value identifies the specific port within the SuccessOut port group out of which packets that successfully use this next-hop entry are to be sent.
o LFBOutputSelectIndex，用于选择下游LFB端口的LFB组输出端口索引。此值标识SuccessOut端口组中的特定端口，成功使用此下一跳条目的数据包将从中发送出去。
This LFB does not have a list of capabilities.
此LFB没有功能列表。
This LFB does not have any events specified.
此LFB未指定任何事件。
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 further to some specific LFBs for data path processing. According to [RFC5810], data packets and their associated metadata are encapsulated in a ForCES redirect message for transportation 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.
重定向LFBs抽象了CE和FE之间的数据包传输过程。从一些lfb输出的一些分组可能必须被传送到CE以进行进一步处理，并且由CE生成的一些分组可能必须被传送到FE并进一步传送到一些特定lfb以进行数据路径处理。根据[RFC5810]，数据包及其相关元数据封装在强制重定向消息中，用于CE和FE之间的传输。我们定义了两个LFB来抽象这个过程：RedirectIn LFB和RedirectOut LFB。通常，在FE的LFB拓扑中，只存在一个RedirectIn LFB实例和一个RedirectOut LFB实例。
The RedirectIn LFB abstracts the process for the CE to inject data packets into the FE data path.
重定向素LFB抽象了CE将数据包注入FE数据路径的过程。
A RedirectIn LFB abstracts the process for the CE to inject data packets into the FE LFB topology so as to input data packets into 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; therefore, the RedirectIn LFB is defined with a single output LFB port (and no input LFB port).
重定向素LFB抽象CE将数据包注入FE LFB拓扑以便将数据包输入FE数据路径的过程。从LFB拓扑的角度来看，重定向in LFB充当来自CE的数据分组的源点；因此，RedirectIn LFB定义为单输出LFB端口（无输入LFB端口）。
The single output port of RedirectIn LFB is defined as a group output type with the name of "PktsOut". Packets produced by this output will have arbitrary frame types decided by the CE that generated the packets. 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 to indicate various information on the packets. Among them, there MUST exist a RedirectIndex metadata, which is an integer acting as an index. When
RedirectIn LFB的单输出端口定义为组输出类型，名称为“PktsOut”。此输出生成的数据包将具有由生成数据包的CE决定的任意帧类型。可能的帧包括IPv4、IPv6或ARP协议包。CE可以关联一些元数据以指示帧类型，并且还可以关联其他元数据以指示分组上的各种信息。其中，必须存在一个重定向索引元数据，它是一个充当索引的整数。什么时候
the CE transmits the metadata along with the packet to a RedirectIn LFB, the LFB will read the RedirectIndex metadata and output 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, will be passed untouched along the packet delivered by the CE to the downstream LFB. This means the RedirectIndex metadata from CE will be "consumed" by the RedirectIn LFB and will not be passed to downstream LFB. Note that a packet from the CE without a RedirectIndex metadata associated will be dropped by the LFB. Note that all metadata visible to the LFB need 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".
CE将元数据与数据包一起传输到重定向IN LFB，LFB将读取重定向索引元数据并将数据包输出到其组输出端口实例之一，其端口索引由该元数据指示。除了重定向索引之外，任何其他元数据都将沿着由CE交付给下游LFB的数据包原封不动地传递。这意味着来自CE的RedirectIndex元数据将被RedirectIn LFB“消耗”，而不会传递给下游LFB。请注意，LFB将丢弃来自CE且没有关联重定向索引元数据的数据包。请注意，LFB可见的所有元数据都需要是全局的，并且由IANA控制。有关可供供应商使用且“保留供私人使用”的元数据ID空间的更多详细信息，请参见本文档第8节（“IANA注意事项”）。
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.
定义可选的统计组件以收集LFB从CE接收的数据包的数量。没有为当前版本的LFB定义其他组件。
This LFB does not have a list of capabilities.
此LFB没有功能列表。
This LFB does not have any events specified.
此LFB未指定任何事件。
RedirectOut LFB abstracts the process for LFBs in the FE to deliver data packets to the CE.
RedirectOut LFB抽象了FE中LFB向CE发送数据包的过程。
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; therefore, the RedirectOut LFB is defined with a single input LFB port (and no output LFB port).
重定向LFB抽象了FE中LFB向CE发送数据包的过程。从LFB拓扑的角度来看，RedirectOut LFB充当到CE的数据分组的汇聚点；因此，RedirectOut LFB定义为一个输入LFB端口（没有输出LFB端口）。
The RedirectOut LFB has only one singleton input, known as "PktsIn", but is capable of receiving packets from multiple LFBs by multiplexing this input. The input expects any kind of frame type; therefore, the frame type has been specified as arbitrary, and also all types of metadata are expected. All associated metadata produced (but not consumed) by previous processed LFBs should be delivered to the CE via the ForCES protocol redirect message [RFC5810]. The CE
重定向输出LFB只有一个单例输入，称为“pktIn”，但能够通过多路复用该输入从多个LFB接收数据包。输入需要任何类型的帧类型；因此，框架类型被指定为任意类型，并且所有类型的元数据都是必需的。先前处理的LFB产生（但未消耗）的所有相关元数据应通过ForCES协议重定向消息[RFC5810]交付给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 is not 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 need 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".
可以通过引用关联的元数据来决定如何处理重定向的数据包。例如，FE可以将数据包重定向到CE，因为Ethernecap LFB无法解析L2信息。Ethernecap LFB创建的元数据“ExceptionID”随数据包一起传递，应该足以让CE进行必要的处理并解析所需的L2条目。请注意，LFB可见的所有元数据都需要是全局的，并且由IANA控制。有关可供供应商使用且“保留供私人使用”的元数据ID空间的更多详细信息，请参见本文档第8节（“IANA注意事项”）。
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.
定义了一个可选的统计组件来收集LFB发送给CE的数据包数量。没有为当前版本的LFB定义其他组件。
This LFB does not have a list of capabilities.
此LFB没有功能列表。
This LFB does not have any events specified.
此LFB未指定任何事件。
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.
BasicMetadataDispatch LFB被定义为抽象过程，在该过程中，数据包根据其关联的元数据值被调度到某个输出路径。
The BasicMetadataDispatch LFB has only one singleton input known as "PktsIn". Every input packet should be associated with a metadata that will be used by the LFB to do the dispatch. This LFB contains a metadata ID and a dispatch table named MetadataDispatchTable, all configured by the CE. The metadata ID specifies which metadata is to be 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.
BasicMetadataDispatch LFB只有一个称为“pktIn”的单例输入。每个输入数据包都应该与一个元数据相关联，LFB将使用该元数据进行调度。此LFB包含一个元数据ID和一个名为MetadataDispatchTable的调度表，所有这些都由CE配置。元数据ID指定用于分派数据包的元数据。MetadataDispatchTable包含元数据值和OutputIndex的条目，指定具有元数据值的数据包必须具有OutputIndex从LFB组输出端口实例中传出。
Two output LFB ports are defined.
定义了两个输出LFB端口。
The first output is a group output port known as "PktsOut". 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.
第一个输出是一个称为“PktsOut”的组输出端口。一个数据包及其相关元数据通过成功查找分派表找到了OutputIndex，该数据包将被输出到具有相应索引的组端口实例。
The second output is a singleton output port known as "ExceptionOut", which will output packets for which the data processing failed, along with an additional ExceptionID metadata to indicate what caused the exception. Currently defined exception types only include one case:
第二个输出是一个称为“ExceptionOut”的单例输出端口，它将输出数据处理失败的数据包，以及一个额外的ExceptionID元数据，以指示导致异常的原因。当前定义的异常类型仅包括一种情况：
o There is no matching when looking up the metadata dispatch table.
o 查找元数据分派表时没有匹配项。
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 assigned OutputIndex for the values to the dispatch table in the LFB. When a packet arrives, a PHYPortID metadata is found associated with the packet, and the metadata value is further used as a key to look up the dispatch table to find out an output port instance for the packet.
例如，如果CE决定根据物理端口ID（PHYPortID）分派分组，则CE可以首先将PHYPortID元数据的ID设置为LFB。此外，CE还设置PHYPortID实际值（元数据值）并为LFB中的分派表中的值分配OutputIndex。当数据包到达时，发现与该数据包相关联的PHYPortID元数据，并且该元数据值进一步用作键来查找分派表以找出该数据包的输出端口实例。
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.
目前，BasicMetadataDispatch LFB只允许调度表项的元数据值为32位整数。此版本不支持具有其他值类型的元数据。未来版本的库中可能会定义更复杂的元数据分派LFB。在该LFB中，可以使用具有更多支持的值类型的多个元数据元组来分派数据包。
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.
该LFB有两个组件。一个组件是MetadataID，另一个是MetadataDispatchTable。分派表的每一行条目都是一个包含元数据值和OutputIndex的结构。请注意，当前元数据值仅允许为32位整数。元数据值还定义为表的内容键。内容键的概念是表的搜索键，在ForCES FE模型[RFC5812]中定义。通过内容键，CE可以通过特定的元数据值而不是仅通过表索引来操作表。有关内容密钥的定义和使用的更多详细信息，请参见ForCES FE模型[RFC5812]和ForCES协议[RFC5810]。
This LFB does not have a list of capabilities.
此LFB没有功能列表。
This LFB does not have any events specified.
此LFB未指定任何事件。
This is a preliminary generic scheduler LFB for abstracting a simple scheduling process.
这是一个初步的通用调度器LFB，用于抽象一个简单的调度过程。
There exist various kinds of scheduling strategies with various implementations. As a base LFB library, this document only defines a preliminary generic scheduler LFB for abstracting a simple scheduling process. Users may use this LFB as a basic LFB to further construct more complex scheduler LFBs by means of "inheritance", as described in [RFC5812].
存在各种各样的调度策略和不同的实现方式。作为一个基本LFB库，本文仅定义了一个初步的通用调度器LFB，用于抽象一个简单的调度过程。用户可以使用此LFB作为基本LFB，通过“继承”进一步构造更复杂的调度器LFB，如[RFC5812]中所述。
Packets of any arbitrary frame type are received via a group input known as "PktsIn" with no additional metadata expected. This group input is capable of multiple input port instances. Each port instance may be connected to a different upstream LFB output. Inside the LFB, it is abstracted that each input port instance is connected to a queue, and the queue is marked with a queue ID whose value is exactly the same as the index of corresponding group input port instance. Scheduling disciplines are applied to all queues and also all packets in the queues. The group input port property PortGroupLimits in ObjectLFB, as defined by the ForCES FE model [RFC5810], provides means for the CE to query the capability of total queue numbers the scheduler supports. The CE can then decide how many queues it may use for a scheduling application.
任何帧类型的数据包都通过称为“pktIn”的组输入接收，不需要额外的元数据。此组输入支持多个输入端口实例。每个端口实例可以连接到不同的上游LFB输出。在LFB内部，抽象为每个输入端口实例都连接到一个队列，并使用一个队列ID标记该队列，该队列ID的值与相应组输入端口实例的索引完全相同。调度规程应用于所有队列以及队列中的所有数据包。由ForCES FE模型[RFC5810]定义的ObjectLFB中的组输入端口属性PortGroupLimits为CE提供了查询调度器支持的总队列号的能力的方法。然后，CE可以决定一个调度应用程序可以使用多少队列。
Scheduled packets are output from a singleton output port of the LFB knows as "PktsOut" with no corresponding metadata.
计划的数据包从LFB的单例输出端口（称为“PktsOut”）输出，并且没有相应的元数据。
More complex scheduler LFBs may be defined with more complex scheduling disciplines by succeeding this LFB. For instance, a priority scheduler LFB may be defined by inheriting this LFB and defining a component to indicate priorities for all input queues.
通过继承此LFB，可以使用更复杂的调度规程来定义更复杂的调度器LFB。例如，优先级调度器LFB可以通过继承该LFB并定义一个组件来定义，以指示所有输入队列的优先级。
The SchedulingDiscipline component is for the CE to specify a scheduling discipline to the LFB. Currently defined scheduling disciplines only include Round Robin (RR) strategy. The default scheduling discipline is thus RR.
SchedulingPractice组件用于CE向LFB指定调度规程。目前定义的调度规程仅包括循环（RR）策略。因此，默认的调度规程是RR。
The QueueStats component is defined to allow the CE to query every queue status of the scheduler. It is an array component, and each row of the array is a struct containing a queue ID. Currently defined queue status includes the queue depth in packets and the queue depth in bytes. Using the queue ID as the index, the CE can query every queue for its used length in unit of packets or bytes. Note that the QueueStats component is defined as optional to implementers.
QueueStats组件被定义为允许CE查询调度程序的每个队列状态。它是一个数组组件，数组的每一行都是一个包含队列ID的结构。当前定义的队列状态包括以数据包为单位的队列深度和以字节为单位的队列深度。使用队列ID作为索引，CE可以以数据包或字节为单位查询每个队列的使用长度。请注意，QueueStats组件被定义为实现者的可选组件。
The following capability is currently defined for the GenericScheduler.
当前为GenericScheduler定义了以下功能。
o The queue length limit providing the storage ability for every queue.
o 为每个队列提供存储能力的队列长度限制。
This LFB does not have any events specified.
此LFB未指定任何事件。
<?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>
<?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 requested
</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 requested
</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>
</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/>
<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>
<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>
<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>
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>
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>
</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>
</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>
</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>
<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">
<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>
<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>
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>
<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
</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>
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>
<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>
</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>
</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>
</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>
<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">
<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>
<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">
<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>
<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>
</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
</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>
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>
</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>
</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>
This section demonstrates examples on how the LFB classes defined by the base LFB library in Section 6 can be applied to achieve some typical router functions. The functions demonstrated are:
本节举例说明如何应用第6节中基本LFB库定义的LFB类来实现一些典型的路由器功能。演示的功能包括：
o IPv4 forwarding
o IPv4转发
o ARP processing
o ARP处理
It is assumed the LFB topology on the FE described has already been established by the CE and maps to the use cases illustrated in this section.
假设所述FE上的LFB拓扑已经由CE建立，并映射到本节中说明的用例。
The use cases demonstrated in this section are mere examples and by no means should be treated as the only way one would construct router functionality from LFBs; based on the capability of the FE(s), a CE should be able to express different NE applications.
本节中演示的用例仅为示例，决不应视为从LFB构建路由器功能的唯一方法；基于FE（s）的能力，CE应该能够表示不同的NE应用。
Figure 2 shows the typical LFB processing path for an IPv4 unicast forwarding case with Ethernet media interfaces by use of the base LFB classes. Note that in the figure, to focus on the IP forwarding function, some inputs or outputs of LFBs that are not related to the IPv4 forwarding function are not shown. For example, an EtherClassifier LFB normally has two output ports: a "ClassifyOut" group output port and an "ExceptionOut" singleton output port, with the group port containing various port instances according to various classified packet types (Section 5.1.3). In this figure, only the IPv4 and IPv6 packet output port instances are shown for displaying the mere IPv4 forwarding processing function.
图2显示了使用基本LFB类使用以太网媒体接口的IPv4单播转发情况的典型LFB处理路径。请注意，在图中，为了关注IP转发功能，未显示与IPv4转发功能无关的LFB的一些输入或输出。例如，EtherClassifier LFB通常有两个输出端口：一个“ClassifyOut”组输出端口和一个“ExceptionOut”单例输出端口，该组端口根据不同的分类数据包类型包含不同的端口实例（第5.1.3节）。在此图中，仅显示IPv4和IPv6数据包输出端口实例，用于显示IPv4转发处理功能。
+-----+ +------+
| | | |
| |<---------------|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 |
+----------->-------------+
+-----+ +------+
| | | |
| |<---------------|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
图2:IPv4转发的LFB用例
In the LFB use case, a number of EtherPHYCop LFB (Section 5.1.1) instances are used to describe physical-layer functions of the ports. PHYPortID metadata is generated by the EtherPHYCop LFB and is used by all the subsequent downstream LFBs. An EtherMACIn LFB (Section 5.1.2), which describes the MAC-layer processing, follows every EtherPHYCop LFB. The EtherMACIn LFB may do a locality check of MAC addresses if the CE configures the appropriate EtherMACIn LFB component.
在LFB用例中，许多EtherPHYCop LFB（第5.1.1节）实例用于描述端口的物理层功能。PHYPortID元数据由EtherPHYCop LFB生成，并由所有后续下游LFB使用。描述MAC层处理的EtherMACIn LFB（第5.1.2节）位于每个EtherPHYCop LFB之后。如果CE配置了适当的EtherMACIn LFB组件，EtherMACIn LFB可以执行MAC地址的本地性检查。
Ethernet packets out of the EtherMACIn LFB are sent to an EtherClassifier LFB (Section 5.1.3) to be decapsulated and classified into network-layer types like IPv4, IPv6, ARP, etc. In the example use case, every physical Ethernet interface is associated with one Classifier instance; although not illustrated, it is also feasible that all physical interfaces are associated with only one Ethernet Classifier instance.
来自EtherMACIn LFB的以太网数据包被发送到EthernerClassifier LFB（第5.1.3节），以被解封并分类为网络层类型，如IPv4、IPv6、ARP等。在示例用例中，每个物理以太网接口与一个分类器实例相关联；尽管未说明，但所有物理接口仅与一个以太网分类器实例关联也是可行的。
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 network-layer type and the LFB output port to the downstream LFB. The EtherClassifier LFB 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 consumption by downstream LFBs.
EtherClassifier使用PHYPortID元数据、输入数据包的以太网类型和VlanID（如果存在于输入以太网数据包中）来确定数据包网络层类型和到下游LFB的LFB输出端口。EtherClassifier LFB还为数据包分配一个新的逻辑端口ID元数据，供以后使用。EtherClassifier还可以为每个数据包生成一些新的元数据，如EtherType、SrcMAC、DstMAC、LogicPortID等，供下游LFB使用。
If a packet is classified as an IPv4 packet, it is sent downstream to an IPv4Validator LFB (Section 5.2.1) to validate the IPv4 packet. In the validator LFB, IPv4 packets are validated and are additionally classified into either IPv4 unicast packets or multicast packets. IPv4 unicast packets are sent to downstream to the IPv4UcastLPM LFB (Section 5.3.1).
如果一个数据包被分类为IPv4数据包，它将被发送到下游的IPv4Validator LFB（第5.2.1节）以验证IPv4数据包。在验证器LFB中，验证IPv4数据包，并将其另外分类为IPv4单播数据包或多播数据包。IPv4单播数据包被发送到下游至IPv4UcastLPM LFB（第5.3.1节）。
The IPv4UcastLPM LFB is where the longest prefix match decision is made, and a next-hop selection is selected. The next-hop ID metadata is generated by the IPv4UcastLPM LFB to be consumed downstream by the IPv4NextHop LFB (Section 5.3.2).
IPv4UcastLPM LFB是进行最长前缀匹配决策并选择下一跳的地方。下一跳ID元数据由IPv4UcastLPM LFB生成，由IPv4NextHop LFB在下游使用（第5.3.2节）。
The IPv4NextHop LFB uses the next-hop ID metadata to derive where the packet is to go next and the media encapsulation type for the port, etc. The IPv4NextHop LFB generates the L3PortID metadata used to identify a next-hop output physical/logical port. In the example use case, the next-hop output port is an Ethernet type; as a result, the packet and its L3 port ID metadata are sent downstream to an EtherEncap LFB (Section 5.1.4).
IPv4NextHop LFB使用下一个跃点ID元数据来派生数据包下一步要去的位置以及端口的媒体封装类型等。IPv4NextHop LFB生成用于标识下一个跃点输出物理/逻辑端口的L3PortID元数据。在示例用例中，下一跳输出端口是以太网类型；因此，数据包及其L3端口ID元数据被发送到Ethernecap LFB的下游（第5.1.4节）。
The EtherEncap LFB encapsulates the incoming packet into an Ethernet frame. A BasicMetadataDispatch LFB (Section 5.5.1) follows the EtherEncap LFB. The BasicMetadataDispatch LFB is where packets are finally dispatched to different output physical/logical ports based on the L3PortID metadata sent to the LFB.
Ethernecap LFB将传入数据包封装到以太网帧中。基本元数据调度LFB（第5.5.1节）遵循Ethernecap LFB。BasicMetadataDispatch LFB是根据发送到LFB的L3PortID元数据将数据包最终调度到不同的输出物理/逻辑端口的地方。
Figure 3 shows the processing path for the Address Resolution Protocol (ARP) in the case the CE implements the ARP processing function. By no means is this the only way ARP processing could be achieved; as an example, ARP processing could happen at the FE, but that discussion is out of the scope of this use case.
图3显示了在CE实现ARP处理功能的情况下，地址解析协议（ARP）的处理路径。这决不是实现ARP处理的唯一途径；例如，ARP处理可能发生在FE上，但这种讨论超出了本用例的范围。
+---+ +---+
| | 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
+---+ +---+
| | 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 ARP
图3:ARP的LFB用例
There are two ways ARP processing could be triggered in the CE as illustrated in Figure 3:
有两种方式可以在CE中触发ARP处理，如图3所示：
o ARP packets arriving from outside of the NE.
o 来自网元外部的ARP数据包。
o IPV4 packets failing to resolve within the FE.
o 无法在FE内解析IPV4数据包。
ARP packets from network interfaces are filtered out by EtherClassifier LFB. The classified ARP packets and associated metadata are then sent downstream to the RedirectOut LFB (Section 5.4.2) to be transported to CE.
来自网络接口的ARP数据包由以太网分类器LFB过滤掉。分类的ARP数据包和相关元数据随后被发送到下游的重定向输出LFB（第5.4.2节），以传输到CE。
The EtherEncap LFB, as described in Section 5.1.4, receives packets that need Ethernet L2 encapsulating. When the EtherEncap LFB fails to find the necessary L2 Ethernet information with which to encapsulate the packet, it outputs the packet to its ExceptionOut LFB port. Downstream to EtherEncap LFB's ExceptionOut LFB port is the RedirectOut LFB, which transports the packet to the CE (see Section 5.1.4 on EtherEncap LFB for details).
如第5.1.4节所述，Ethernecap LFB接收需要以太网L2封装的数据包。当Ethernecap LFB无法找到封装数据包所需的L2以太网信息时，它将数据包输出到其ExceptionOut LFB端口。Ethernecap LFB的ExceptionOut LFB端口的下游是RedirectOut LFB，它将数据包传输到CE（有关详细信息，请参阅关于Ethernecap LFB的第5.1.4节）。
To achieve its goal, 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).
为了实现其目标，CE需要生成ARP请求和响应数据包，并将它们发送到外部（到网元）网络。来自CE的ARP请求和响应数据包通过重定向IN LFB重定向至FE（第5.4.1节）。
As was the case with forwarded IPv4 packets, outgoing ARP packets are also encapsulated to Ethernet format by the EtherEncap LFB, and then dispatched to different interfaces via a BasicMetadataDispatch LFB. The BasicMetadataDispatch LFB dispatches the packets according to the L3PortID metadata included in every ARP packet sent from CE.
与转发的IPv4数据包一样，传出的ARP数据包也由Ethernecap LFB封装为以太网格式，然后通过BasicMetadataDispatch LFB发送到不同的接口。BasicMetadataDispatch LFB根据从CE发送的每个ARP数据包中包含的L3PortID元数据来调度数据包。
IANA has created a registry of ForCES LFB class names and the corresponding ForCES LFB class identifiers, with the location of the definition of the ForCES LFB class, in accordance with the rules to use the namespace.
IANA已经创建了一个ForCES LFB类名称和相应的ForCES LFB类标识符的注册表，其中包含ForCES LFB类定义的位置，符合使用名称空间的规则。
This document registers the unique class names and numeric class identifiers for the LFBs listed in Section 8.1. Besides, this document defines the following namespaces:
本文件登记了第8.1节所列LFB的唯一类名称和数字类标识符。此外，本文档定义了以下名称空间：
o Metadata ID, defined in Sections 4.3 and 4.4
o 第4.3节和第4.4节中定义的元数据ID
o Exception ID, defined in Section 4.4
o 第4.4节中定义的异常ID
o Validate Error ID, defined in Section 4.4
o 验证第4.4节中定义的错误ID
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 over 65535.
本文件定义的LFB类属于标准跟踪RFC定义的LFB。根据IANA，注册程序是0到65535范围内的标准行动，先到先得，任何公开的65535以上的规范都会提供。
The assignment of LFB class names and LFB class identifiers is as in the following table.
LFB类名和LFB类标识符的分配如下表所示。
+----------+--------------- +------------------------+--------------+
|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|
| | | | |
+----------+--------------- +------------------------+--------------+
|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. | |
+----------+--------------- +------------------------+--------------+
| 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 1
表1
The Metadata ID namespace is 32 bits long. Below are the guidelines for managing the namespace.
元数据ID命名空间的长度为32位。下面是管理名称空间的指导原则。
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.
0x00000001-0x7FFFFFFF范围内的元数据ID是规范要求的[RFC5226]。使用此范围的元数据ID必须记录在RFC或其他永久且随时可用的参考文件中。
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 | |
+--------------+-------------------------+--------------------------+
+--------------+-------------------------+--------------------------+
| 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 2
表2
The Exception ID namespace is 32 bits long. Below are the guidelines for managing the namespace.
异常ID命名空间的长度为32位。下面是管理名称空间的指导原则。
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.
0x00000000-0x7FFFFFFF范围内的异常ID是规范要求的[RFC5226]。使用此范围的异常ID必须记录在RFC或其他永久且随时可用的参考文件中。
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 | |
+--------------+---------------------------------+------------------+
+--------------+---------------------------------+------------------+
| 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 3
表3
The Validate Error ID namespace is 32 bits long. Below are the guidelines for managing the namespace.
验证错误ID命名空间的长度为32位。下面是管理名称空间的指导原则。
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.
验证0x00000000-0x7FFFFFFF范围内的错误ID是否符合规范要求[RFC5226]。使用此范围的验证错误ID必须记录在RFC或其他永久且随时可用的参考文件中。
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 | |
+--------------+---------------------------------+------------------+
+--------------+---------------------------------+------------------+
| 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 4
表4
The ForCES framework document [RFC3746] provides a description of the security needs for the overall 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. 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. Thus, the security mechanisms and considerations from the ForCES protocol document [RFC5810] apply to this document.
部队框架文件[RFC3746]描述了整个部队架构的安全需求。例如，在通过ForCES访问本文件中描述的信息元素之前，必须根据ForCES要求对ForCES协议实体进行身份验证。ForCES协议文件[RFC5810]包括一套全面的安全机制，实现需要支持这些机制才能满足这些需求。ForCES协议的基于SCTP的传输映射层（TML）[RFC5811]为ForCES协议的传输映射指定了安全机制。本文件中定义的LFB与FE模型[RFC5812]建模的其他LFB相似。特别是，它们具有相同的安全属性。因此，部队协议文件[RFC5810]中的安全机制和注意事项适用于本文件。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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.
[RFC5810]Doria，A.，Hadi Salim，J.，Haas，R.，Khosravi，H.，Wang，W.，Dong，L.，Gopal，R.，和J.Halpern，“转发和控制元件分离（部队）协议规范”，RFC 58102010年3月。
[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.
[RFC5811]Hadi Salim，J.和K.Ogawa，“转发和控制元素分离（ForCES）协议的基于SCTP的传输映射层（TML）”，RFC 58112010年3月。
[RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control Element Separation (ForCES) Forwarding Element Model", RFC 5812, March 2010.
[RFC5812]Halpern，J.和J.Hadi Salim，“转发和控制单元分离（部队）转发单元模型”，RFC 5812，2010年3月。
[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.
[IEEE.802-1Q]IEEE，“局域网和城域网的IEEE标准——媒体访问控制（MAC）网桥和虚拟桥接局域网”，IEEE标准802.1Q，2011年。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]Baker，F.，“IP版本4路由器的要求”，RFC1812，1995年6月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578]McCloghrie，K.，Ed.，Perkins，D.，Ed.，和J.Schoenwaeld，Ed.“管理信息的结构版本2（SMIv2）”，STD 58，RFC 2578，1999年4月。
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding and Control Element Separation (ForCES) Framework", RFC 3746, April 2004.
[RFC3746]Yang，L.，Dantu，R.，Anderson，T.，和R.Gopal，“转发和控制单元分离（部队）框架”，RFC 37462004年4月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
The authors would like to acknowledge the following people, whose input was particularly helpful during development of this document:
作者要感谢以下人员，他们的意见在本文件的编写过程中特别有用：
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 Barnes
爱德华·克拉布·阿德里安·法雷尔·荣金·本·诸葛明·高晶晶周晓春·吴德里克·阿特金斯斯蒂芬·法雷尔·梅拉尔·西拉齐波尔·贾里·阿尔科·马丁·斯蒂梅林·斯图尔特·布莱恩特·理查德·巴恩斯
The authors would like to thank Jamal Hadi Salim, Ligang Dong, and Fenggen Jia, all of whom made major contributions to the development of this document. Ligang Dong and Fenggen Jia were also two of the authors of earlier documents from which this document evolved.
作者要感谢贾马尔·哈迪·萨利姆（Jamal Hadi Salim）、董立刚（Liang Dong）和贾丰根（Fenggen Jia），他们都为本文件的编写做出了重大贡献。董立刚和贾丰根也是早期文献的两位作者，该文献就是从这两位作者发展而来的。
Jamal Hadi Salim Mojatatu Networks Ottawa, Ontario Canada EMail: hadi@mojatatu.com
加拿大安大略省渥太华Jamal Hadi Salim Mojatatu Networks电子邮件：hadi@mojatatu.com
Ligang Dong Zhejiang Gongshang University 18 Xuezheng Str., Xiasha University Town Hangzhou 310018 P.R. China EMail: donglg@zjsu.edu.cn
中国杭州下沙大学城学政街18号浙江工商大学李港东310018电子邮件：donglg@zjsu.edu.cn
Fenggen Jia National Digital Switching Center (NDSC) Jianxue Road Zhengzhou 452000 P.R. China EMail: jfg@mail.ndsc.com.cn
中国郑州市建学路冯根佳国家数字交换中心（NDSC）邮编：452000电子邮件：jfg@mail.ndsc.com.cn
Authors' Addresses
作者地址
Weiming Wang Zhejiang Gongshang University 18 Xuezheng Str., Xiasha University Town Hangzhou 310018 P.R. China
王伟明浙江工商大学中国杭州下沙大学城学政街18号310018
Phone: +86 571 28877751
EMail: wmwang@zjsu.edu.cn
Phone: +86 571 28877751
EMail: wmwang@zjsu.edu.cn
Evangelos Haleplidis University of Patras Department of Electrical & Computer Engineering Patras 26500 Greece
佩特雷大学电气与计算机工程系帕特雷26500希腊分校
EMail: ehalep@ece.upatras.gr
EMail: ehalep@ece.upatras.gr
Kentaro Ogawa NTT Corporation Tokyo Japan
日本东京小川健太郎NTT公司
EMail: ogawa.kentaro@lab.ntt.co.jp
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
中国杭州市滨江区通河路68号中财集团6楼川皇里杭州DPtech 310051
EMail: chuanhuang_li@zjsu.edu.cn
EMail: chuanhuang_li@zjsu.edu.cn
Joel Halpern Ericsson P.O. Box 6049 Leesburg, VA 20178 USA
美国弗吉尼亚州利斯堡市Joel Halpern Ericsson邮政信箱6049号，邮编20178
Phone: +1 703 371 3043
EMail: joel.halpern@ericsson.com
Phone: +1 703 371 3043
EMail: joel.halpern@ericsson.com