draft-ietf-forces-lfb-lib-09.txt   draft-ietf-forces-lfb-lib-10.txt 
Internet Engineering Task Force W. Wang Internet Engineering Task Force W. Wang
Internet-Draft Zhejiang Gongshang University Internet-Draft Zhejiang Gongshang University
Intended status: Standards Track E. Haleplidis Intended status: Standards Track E. Haleplidis
Expires: November 23, 2012 University of Patras Expires: August 1, 2013 University of Patras
K. Ogawa K. Ogawa
NTT Corporation NTT Corporation
C. Li C. Li
Hangzhou H3C Tech. Co., Ltd. Hangzhou H3C Tech. Co., Ltd.
J. Halpern J. Halpern
Ericsson Ericsson
May 22, 2012 January 28, 2013
ForCES Logical Function Block (LFB) Library ForCES Logical Function Block (LFB) Library
draft-ietf-forces-lfb-lib-09 draft-ietf-forces-lfb-lib-10
Abstract Abstract
This document defines basic classes of Logical Function Blocks (LFBs) This document defines basic classes of Logical Function Blocks (LFBs)
used in the Forwarding and Control Element Separation (ForCES). The used in the Forwarding and Control Element Separation (ForCES). The
basic LFB classes are defined according to ForCES FE model and ForCES basic LFB classes are defined according to ForCES FE model and ForCES
protocol specifications, and are scoped to meet requirements of protocol specifications, and are scoped to meet requirements of
typical router functions and considered as the basic LFB library for typical router functions and considered as the basic LFB library for
ForCES. The library includes the descriptions of the LFBs and the ForCES. The library includes the descriptions of the LFBs and the
XML definitions. XML definitions.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 23, 2012. This Internet-Draft will expire on August 1, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 27 skipping to change at page 2, line 27
1. Terminology and Conventions . . . . . . . . . . . . . . . . . 4 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Scope of the Library . . . . . . . . . . . . . . . . . . 8 3.1. Scope of the Library . . . . . . . . . . . . . . . . . . 8
3.2. Overview of LFB Classes in the Library . . . . . . . . . 10 3.2. Overview of LFB Classes in the Library . . . . . . . . . 10
3.2.1. LFB Design Choices . . . . . . . . . . . . . . . . . 10 3.2.1. LFB Design Choices . . . . . . . . . . . . . . . . . 10
3.2.2. LFB Class Groupings . . . . . . . . . . . . . . . . . 11 3.2.2. LFB Class Groupings . . . . . . . . . . . . . . . . . 11
3.2.3. Sample LFB Class Application . . . . . . . . . . . . 12 3.2.3. Sample LFB Class Application . . . . . . . . . . . . 12
3.3. Document Structure . . . . . . . . . . . . . . . . . . . 13 3.3. Document Structure . . . . . . . . . . . . . . . . . . . 13
4. Base Types . . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Base Types . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.1. Atomic . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.1. Atomic . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.2. Compound Struct . . . . . . . . . . . . . . . . . . . 16 4.1.2. Compound Struct . . . . . . . . . . . . . . . . . . . 15
4.1.3. Compound Array . . . . . . . . . . . . . . . . . . . 16 4.1.3. Compound Array . . . . . . . . . . . . . . . . . . . 15
4.2. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 17 4.2. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. MetaData Types . . . . . . . . . . . . . . . . . . . . . 17 4.3. MetaData Types . . . . . . . . . . . . . . . . . . . . . 16
4.4. XML for Base Type Library . . . . . . . . . . . . . . . . 18 4.4. XML for Base Type Library . . . . . . . . . . . . . . . . 17
5. LFB Class Description . . . . . . . . . . . . . . . . . . . . 43 5. LFB Class Description . . . . . . . . . . . . . . . . . . . . 43
5.1. Ethernet Processing LFBs . . . . . . . . . . . . . . . . 43 5.1. Ethernet Processing LFBs . . . . . . . . . . . . . . . . 43
5.1.1. EtherPHYCop . . . . . . . . . . . . . . . . . . . . . 44 5.1.1. EtherPHYCop . . . . . . . . . . . . . . . . . . . . . 44
5.1.2. EtherMACIn . . . . . . . . . . . . . . . . . . . . . 46 5.1.2. EtherMACIn . . . . . . . . . . . . . . . . . . . . . 46
5.1.3. EtherClassifier . . . . . . . . . . . . . . . . . . . 48 5.1.3. EtherClassifier . . . . . . . . . . . . . . . . . . . 48
5.1.4. EtherEncap . . . . . . . . . . . . . . . . . . . . . 50 5.1.4. EtherEncap . . . . . . . . . . . . . . . . . . . . . 50
5.1.5. EtherMACOut . . . . . . . . . . . . . . . . . . . . . 52 5.1.5. EtherMACOut . . . . . . . . . . . . . . . . . . . . . 52
5.2. IP Packet Validation LFBs . . . . . . . . . . . . . . . . 53 5.2. IP Packet Validation LFBs . . . . . . . . . . . . . . . . 53
5.2.1. IPv4Validator . . . . . . . . . . . . . . . . . . . . 53 5.2.1. IPv4Validator . . . . . . . . . . . . . . . . . . . . 53
5.2.2. IPv6Validator . . . . . . . . . . . . . . . . . . . . 55 5.2.2. IPv6Validator . . . . . . . . . . . . . . . . . . . . 55
skipping to change at page 3, line 9 skipping to change at page 3, line 9
5.3.2. IPv4NextHop . . . . . . . . . . . . . . . . . . . . . 59 5.3.2. IPv4NextHop . . . . . . . . . . . . . . . . . . . . . 59
5.3.3. IPv6UcastLPM . . . . . . . . . . . . . . . . . . . . 61 5.3.3. IPv6UcastLPM . . . . . . . . . . . . . . . . . . . . 61
5.3.4. IPv6NextHop . . . . . . . . . . . . . . . . . . . . . 63 5.3.4. IPv6NextHop . . . . . . . . . . . . . . . . . . . . . 63
5.4. Redirect LFBs . . . . . . . . . . . . . . . . . . . . . . 65 5.4. Redirect LFBs . . . . . . . . . . . . . . . . . . . . . . 65
5.4.1. RedirectIn . . . . . . . . . . . . . . . . . . . . . 65 5.4.1. RedirectIn . . . . . . . . . . . . . . . . . . . . . 65
5.4.2. RedirectOut . . . . . . . . . . . . . . . . . . . . . 66 5.4.2. RedirectOut . . . . . . . . . . . . . . . . . . . . . 66
5.5. General Purpose LFBs . . . . . . . . . . . . . . . . . . 67 5.5. General Purpose LFBs . . . . . . . . . . . . . . . . . . 67
5.5.1. BasicMetadataDispatch . . . . . . . . . . . . . . . . 67 5.5.1. BasicMetadataDispatch . . . . . . . . . . . . . . . . 67
5.5.2. GenericScheduler . . . . . . . . . . . . . . . . . . 69 5.5.2. GenericScheduler . . . . . . . . . . . . . . . . . . 69
6. XML for LFB Library . . . . . . . . . . . . . . . . . . . . . 71 6. XML for LFB Library . . . . . . . . . . . . . . . . . . . . . 71
7. LFB Class Use Cases . . . . . . . . . . . . . . . . . . . . . 101 7. LFB Class Use Cases . . . . . . . . . . . . . . . . . . . . . 100
7.1. IPv4 Forwarding . . . . . . . . . . . . . . . . . . . . . 101 7.1. IPv4 Forwarding . . . . . . . . . . . . . . . . . . . . . 100
7.2. ARP processing . . . . . . . . . . . . . . . . . . . . . 102 7.2. ARP processing . . . . . . . . . . . . . . . . . . . . . 102
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 105 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 105
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 106 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 106
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 107 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 107
10.1. LFB Class Names and LFB Class Identifiers . . . . . . . . 107 10.1. LFB Class Names and LFB Class Identifiers . . . . . . . . 107
10.2. Metadata ID . . . . . . . . . . . . . . . . . . . . . . . 109 10.2. Metadata ID . . . . . . . . . . . . . . . . . . . . . . . 109
10.3. Exception ID . . . . . . . . . . . . . . . . . . . . . . 109 10.3. Exception ID . . . . . . . . . . . . . . . . . . . . . . 109
10.4. Validate Error ID . . . . . . . . . . . . . . . . . . . . 110 10.4. Validate Error ID . . . . . . . . . . . . . . . . . . . . 110
11. Security Considerations . . . . . . . . . . . . . . . . . . . 112 11. Security Considerations . . . . . . . . . . . . . . . . . . . 112
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 113 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 113
skipping to change at page 8, line 34 skipping to change at page 8, line 34
LFB definitions is to represent functions so as to provide LFB definitions is to represent functions so as to provide
interoperability between separate CEs and FEs. interoperability between separate CEs and FEs.
More LFB classes with more functions may be developed in future time More LFB classes with more functions may be developed in future time
and documented by IETF. Vendors may also develop proprietary LFB and documented by IETF. Vendors may also develop proprietary LFB
classes as described in the FE model [RFC5812]. classes as described in the FE model [RFC5812].
3.1. Scope of the Library 3.1. Scope of the Library
It is intended that the LFB classes described in this document are It is intended that the LFB classes described in this document are
designed to provide the functions of a typical router. [RFC5812] designed to provide the functions of a typical router. [RFC1812]
specifies that a typical router is expected to provide functions to: specifies that a typical router is expected to provide functions to:
(1) Interface to packet networks and implement the functions (1) Interface to packet networks and implement the functions
required by that network. These functions typically include: required by that network. These functions typically include:
* Encapsulating and decapsulating the IP datagrams with the * Encapsulating and decapsulating the IP datagrams with the
connected network framing (e.g., an Ethernet header and connected network framing (e.g., an Ethernet header and
checksum), checksum),
* Sending and receiving IP datagrams up to the maximum size * Sending and receiving IP datagrams up to the maximum size
skipping to change at page 12, line 18 skipping to change at page 12, line 18
general to many processing locations in an FE LFB topology. The general to many processing locations in an FE LFB topology. The
following LFBs are defined for redirect processing: following LFBs are defined for redirect processing:
* BasicMetadataDispatch (Section 5.5.1) * BasicMetadataDispatch (Section 5.5.1)
* GenericScheduler (Section 5.5.2) * GenericScheduler (Section 5.5.2)
3.2.3. Sample LFB Class Application 3.2.3. Sample LFB Class Application
Although Section 7 will present use cases for LFBs defined in this Although Section 7 will present use cases for LFBs defined in this
document, this section shows a sample LFB class application in document, this section shows a simple sample LFB class application in
advance so that readers can get a quick overlook of the LFB classes advance so that readers can get a quick overlook of the LFB classes
with the usage. with the usage.
Figure 1 shows the typical LFB processing path for an IPv4 unicast Figure 1 shows a simple LFB processing path for Ethernet packets
forwarding case with Ethernet media interfaces. To focus on the IP entered from Ethernet physical ports.
forwarding function, some inputs or outputs of LFBs in the figure
that are not related to the function are ignored. Section 7.1 will
describe the figure in details.
+-----+ +------+ +-----+ +------+
| | | | | |EtherPHYIn | | from some LFB(s) which
| |<---------------|Ether |<----------------------------+ | |<---------------|Ether |<---------- generate Ethernet
| | |MACOut| | | | |MACOut| packets
| | | | | | | | LFB |
|Ether| +------+ | |Ether| +------+
|PHY | | |PHY | +------+
|Cop | +---+ | |Cop | | |
|#1 | +-----+ | |----->IPv6 Packets | |LFB |EtherPHYOut | Ether| to some LFB(s) which
| | | | | | | | |--------------->| MACIn|----------> may classify Ethernet
| | |Ether| | | IPv4 Packets | | | | LFB | packets and do IP layer
| |->|MACIn|-->| |-+ +----+ | | | | | processing
+-----+ | | | | | | |---> 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 1: LFB use case for IPv4 forwarding Figure 1: A simple sample LFB use case
In the figure, Ethernet packets from outer networks enter via the
EtherPHYCop LFB(Section 5.1.1), which describes Ethernet copper
interface property(like the link speed) at physical layer. After
physical layer process, Ethernet packets are delivered to EtherMACIn
LFB(Section 5.1.2) to describe its MAC layer processing
functions(like locality check). The packets after EtherMACIn LFB may
require further processing to implement various functions(like IP
layer forwarding),therefore some LFBs may follow the EtherMACIn LFB
in topology to describe followed processing functions.
Meanwhile, packets generated by some LFB(s) may need to be submitted
to outer physical networks. The process is described in the figure
by an EtherMACOut LFB(Section 5.1.5) at MAC layer and the EtherPHYCop
LFB at physical layer.
3.3. Document Structure 3.3. Document Structure
Base type definitions, including data types, packet frame types, and Base type definitions, including data types, packet frame types, and
metadata types are presented in advance for definitions of various metadata types are presented in advance for definitions of various
LFB classes. Section 4 (Base Types section) provides a description LFB classes. Section 4 (Base Types section) provides a description
on the base types used by this LFB library. To enable extensive use 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 of these base types by other LFB class definitions, the base type
definitions are provided as a separate library. definitions are provided as a separate library.
skipping to change at page 15, line 13 skipping to change at page 14, line 13
this document. this document.
4. Base Types 4. Base Types
The FE model [RFC5812] has specified predefined (built-in) atomic The FE model [RFC5812] has specified predefined (built-in) atomic
data-types as below: data-types as below:
char, uchar, int16, uint16, int32, uint32, int64, uint64, string[N], char, uchar, int16, uint16, int32, uint32, int64, uint64, string[N],
string, byte[N], boolean, octetstring[N], float16, float32, float64. string, byte[N], boolean, octetstring[N], float16, float32, float64.
Note that, unlike SNMP information model SMI([RFC2578]), the FE model
has not defined specific atomic data type for counting purpose. This
document follows not to define specific counter types. To describe
LFB elements for packet statistics which actually require counters on
packets, an unsigned integer, like an uint32 or an uint64 is adopted.
This document states that any LFB element defined for counter purpose
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 it is implementation's issue how the
unsigned integer element might be maintained to cope with issues like
counter discontinuities when a counter wraps or is reset by any
reasons. If a CE is expected to understand more meanings of the
counter element than stated above, a private definition on the
element between CE and FE may be required.
Based on the atomic data types and with the use of type definition 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 elements in the FE model XML schema, new data types, packet frame
types, and metadata types can be defined. types, and metadata types can be defined.
To define a base LFB library for typical router functions, a set of To define a base LFB library for typical router functions, a set of
base data types, frame types, and metadata types should be defined. base data types, frame types, and metadata types should be defined.
This section provides a brief description of the base types and a This section provides a brief description of the base types and a
full XML definition of them as well. full XML definition of them as well.
The base type XML definitions are provided with a separate XML The base type XML definitions are provided with a separate XML
skipping to change at page 18, line 35 skipping to change at page 17, line 35
port. port.
RedirectIndex 14 Metadata that CE sends to RedirectIn LFB, RedirectIndex 14 Metadata that CE sends to RedirectIn LFB,
indicating an associated packet a group indicating an associated packet a group
output port index of the LFB. output port index of the LFB.
MediaEncapInfoIndex 15 A search key a packet uses to look up a MediaEncapInfoIndex 15 A search key a packet uses to look up a
table in related LFBs to select an table in related LFBs to select an
encapsulation media. encapsulation media.
4.4. XML for Base Type Library 4.4. XML for Base Type Library
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0" <LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
provides="BaseTypeLibrary"> provides="BaseTypeLibrary">
<frameDefs> <frameDefs>
<frameDef> <frameDef>
<name>EthernetAll</name> <name>EthernetAll</name>
<synopsis>Any type of Ethernet frame</synopsis> <synopsis>Packet with any Ethernet type</synopsis>
</frameDef> </frameDef>
<frameDef> <frameDef>
<name>EthernetII</name> <name>EthernetII</name>
<synopsis>An Ethernet II frame</synopsis> <synopsis>Packet with Ethernet II type</synopsis>
</frameDef> </frameDef>
<frameDef> <frameDef>
<name>ARP</name> <name>ARP</name>
<synopsis>An ARP packet</synopsis> <synopsis>ARP packet</synopsis>
</frameDef> </frameDef>
<frameDef> <frameDef>
<name>IPv4</name> <name>IPv4</name>
<synopsis>An IPv4 packet</synopsis> <synopsis>IPv4 packet</synopsis>
</frameDef> </frameDef>
<frameDef> <frameDef>
<name>IPv6</name> <name>IPv6</name>
<synopsis>An IPv6 packet</synopsis> <synopsis>IPv6 packet</synopsis>
</frameDef> </frameDef>
<frameDef> <frameDef>
<name>IPv4Unicast</name> <name>IPv4Unicast</name>
<synopsis>An IPv4 unicast packet</synopsis> <synopsis>IPv4 unicast packet</synopsis>
</frameDef> </frameDef>
<frameDef> <frameDef>
<name>IPv4Multicast</name> <name>IPv4Multicast</name>
<synopsis>An IPv4 multicast packet</synopsis> <synopsis>IPv4 multicast packet</synopsis>
</frameDef> </frameDef>
<frameDef> <frameDef>
<name>IPv6Unicast</name> <name>IPv6Unicast</name>
<synopsis>An IPv6 unicast packet</synopsis> <synopsis>IPv6 unicast packet</synopsis>
</frameDef> </frameDef>
<frameDef> <frameDef>
<name>IPv6Multicast</name> <name>IPv6Multicast</name>
<synopsis>An IPv6 multicast packet</synopsis> <synopsis>IPv6 multicast packet</synopsis>
</frameDef> </frameDef>
<frameDef> <frameDef>
<name>Arbitrary</name> <name>Arbitrary</name>
<synopsis>Any type of packet frames</synopsis> <synopsis>Any type of packet</synopsis>
</frameDef> </frameDef>
</frameDefs> </frameDefs>
<dataTypeDefs> <dataTypeDefs>
<dataTypeDef> <dataTypeDef>
<name>IPv4Addr</name> <name>IPv4Addr</name>
<synopsis>IPv4 address</synopsis> <synopsis>IPv4 address</synopsis>
<typeRef>byte[4]</typeRef> <typeRef>byte[4]</typeRef>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv6Addr</name> <name>IPv6Addr</name>
<synopsis>IPv6 address</synopsis> <synopsis>IPv6 address</synopsis>
<typeRef>byte[16]</typeRef> <typeRef>byte[16]</typeRef>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IEEEMAC</name> <name>IEEEMAC</name>
<synopsis>IEEE MAC address</synopsis> <synopsis>IEEE MAC address</synopsis>
<typeRef>byte[6]</typeRef> <typeRef>byte[6]</typeRef>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>LANSpeedType</name> <name>LANSpeedType</name>
<synopsis>LAN speed by value types</synopsis> <synopsis>LAN speed type</synopsis>
<atomic> <atomic>
<baseType>uint32</baseType> <baseType>uint32</baseType>
<specialValues> <specialValues>
<specialValue value="0x00000000"> <specialValue value="0x00000000">
<name>LAN_SPEED_NONE</name> <name>LAN_SPEED_NONE</name>
<synopsis>Nothing is connected</synopsis> <synopsis>Nothing connected</synopsis>
</specialValue> </specialValue>
<specialValue value="0x00000001"> <specialValue value="0x00000001">
<name>LAN_SPEED_10M</name> <name>LAN_SPEED_10M</name>
<synopsis>10M Ethernet</synopsis> <synopsis>10M Ethernet</synopsis>
</specialValue> </specialValue>
<specialValue value="0x00000002"> <specialValue value="0x00000002">
<name>LAN_SPEED_100M</name> <name>LAN_SPEED_100M</name>
<synopsis>100M Ethernet</synopsis> <synopsis>100M Ethernet</synopsis>
</specialValue> </specialValue>
<specialValue value="0x00000003"> <specialValue value="0x00000003">
<name>LAN_SPEED_1G</name> <name>LAN_SPEED_1G</name>
<synopsis>1G Ethernet</synopsis> <synopsis>1G Ethernet</synopsis>
</specialValue> </specialValue>
<specialValue value="0x00000004"> <specialValue value="0x00000004">
<name>LAN_SPEED_10G</name> <name>LAN_SPEED_10G</name>
<synopsis>10G Ethernet</synopsis> <synopsis>10G Ethernet</synopsis>
</specialValue> </specialValue>
<specialValue value="0x00000005"> <specialValue value="0x00000005">
<name>LAN_SPEED_AUTO</name> <name>LAN_SPEED_40G</name>
<synopsis>LAN speed by auto negotiation</synopsis> <synopsis>40G Ethernet</synopsis>
</specialValue> </specialValue>
</specialValues> <specialValue value="0x00000006">
</atomic> <name>LAN_SPEED_100G</name>
</dataTypeDef> <synopsis>100G Ethernet</synopsis>
<dataTypeDef> </specialValue>
<name>DuplexType</name> <specialValue value="0x00000007">
<synopsis>Duplex types</synopsis> <name>LAN_SPEED_400G</name>
<atomic> <synopsis>400G Ethernet</synopsis>
<baseType>uint32</baseType> </specialValue>
<specialValues> <specialValue value="0x00000008">
<specialValue value="0x00000001"> <name>LAN_SPEED_1T</name>
<name>Auto</name> <synopsis>1T Ethernet</synopsis>
<synopsis>Auto negotiation</synopsis> </specialValue>
</specialValue> <specialValue value="0x00000009">
<specialValue value="0x00000002"> <name>LAN_SPEED_OTHER</name>
<name>HalfDuplex</name> <synopsis>Other LAN speed type</synopsis>
<synopsis>Half duplex</synopsis> </specialValue>
</specialValue> <specialValue value="0x0000000A">
<specialValue value="0x00000003"> <name>LAN_SPEED_AUTO</name>
<name>FullDuplex</name> <synopsis>LAN speed by auto negotiation</synopsis>
<synopsis>Full duplex</synopsis> </specialValue>
</specialValue> </specialValues>
</specialValues> </atomic>
</atomic> </dataTypeDef>
</dataTypeDef> <dataTypeDef>
<dataTypeDef> <name>DuplexType</name>
<name>PortStatusType</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> <synopsis>
Data types for port status, used for both administrative and Data type defined for statistics in EtherMACIn LFB.
operative status.
</synopsis> </synopsis>
<atomic> <struct>
<baseType>uchar</baseType> <component componentID="1">
<specialValues> <name>NumPacketsReceived</name>
<specialValue value="0"> <synopsis>Number of packets received</synopsis>
<name>Disabled</name> <typeRef>uint64</typeRef>
<synopsis>Port is operatively disabled</synopsis> </component>
</specialValue> <component componentID="2">
<specialValue value="1"> <name>NumPacketsDropped</name>
<name>Up</name> <synopsis>Number of packets dropped</synopsis>
<synopsis>Port is up</synopsis> <typeRef>uint64</typeRef>
</specialValue> </component>
<specialValue value="2"> </struct>
<name>Down</name> </dataTypeDef>
<synopsis>Port is down</synopsis> <dataTypeDef>
</specialValue> <name>MACOutStatsType</name>
</specialValues> <synopsis>
</atomic> Data type defined for statistics in EtherMACOut LFB.
</dataTypeDef> </synopsis>
<dataTypeDef> <struct>
<name>MACInStatsType</name> <component componentID="1">
<synopsis> <name>NumPacketsTransmitted</name>
Data types for statistics in EtherMACIn LFB <synopsis>Number of packets transmitted</synopsis>
</synopsis> <typeRef>uint64</typeRef>
<struct> </component>
<component componentID="1"> <component componentID="2">
<name>NumPacketsReceived</name> <name>NumPacketsDropped</name>
<synopsis>Number of packets received</synopsis> <synopsis>Number of packets dropped</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
<component componentID="2"> </struct>
<name>NumPacketsDropped</name> </dataTypeDef>
<synopsis>Number of packets dropped</synopsis> <dataTypeDef>
<typeRef>uint64</typeRef> <name>EtherDispatchEntryType</name>
</component> <synopsis>
</struct> Data type defined for entry of Ethernet dispatch
</dataTypeDef> table in EtherClassifier LFB.
<dataTypeDef> </synopsis>
<name>MACOutStatsType</name> <struct>
<synopsis> <component componentID="1">
Data types for statistics in EtherMACOut LFB <name>LogicalPortID</name>
</synopsis> <synopsis>Logical port ID</synopsis>
<struct> <typeRef>uint32</typeRef>
<component componentID="1"> </component>
<name>NumPacketsTransmitted</name> <component componentID="2">
<synopsis>Number of packets transmitted</synopsis> <name>EtherType</name>
<typeRef>uint64</typeRef> <synopsis>
</component> The Ethernet type of the Ethernet packet.
<component componentID="2"> </synopsis>
<name>NumPacketsDropped</name> <typeRef>uint16</typeRef>
<synopsis>Number of packets dropped</synopsis> </component>
<typeRef>uint64</typeRef> <component componentID="3">
</component> <name>Reserved</name>
</struct> <synopsis>
</dataTypeDef> A reserved bit space mainly for purpose of padding
<dataTypeDef> and packing efficiency.
<name>EtherDispatchEntryType</name> </synopsis>
<synopsis> <typeRef>uint16</typeRef>
Data type for entry of Ethernet dispatch table in </component>
EtherClassifier LFB <component componentID="4">
</synopsis> <name>LFBOutputSelectIndex</name>
<struct>
<component componentID="1">
<name>LogicalPortID</name>
<synopsis>Logical port ID</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>EtherType</name>
<synopsis> <synopsis>
Ethernet type as defined in Ethernet frame header Index for a packet to select an instance in the
group output port of EtherClassifier LFB to output.
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="3"> </struct>
<name>LFBOutputSelectIndex</name> </dataTypeDef>
<synopsis> <dataTypeDef>
Index for a packet to select a port instance in <name>EtherDispatchTableType</name>
EtherClassifier LFB group output port to link to a <synopsis>
downstream LFB. Possible downstream LFBs are Data type defined for Ethernet dispatch table in
IPv4Validator, IPv6Validator, RedirectOut, etc. EtherClassifier LFB. The table is composed of an array
</synopsis> of entries with EtherDispatchEntryType data type.
<typeRef>uint32</typeRef> </synopsis>
</component> <array type="variable-size">
</struct> <typeRef>EtherDispatchEntryType</typeRef>
</dataTypeDef> </array>
<dataTypeDef> </dataTypeDef>
<name>EtherDispatchTableType</name> <dataTypeDef>
<synopsis> <name>VlanIDType</name>
Data type for Ethernet dispatch table in EtherClassifier <synopsis>Data type for VLAN ID</synopsis>
LFB. The table entry type is defined by <atomic>
EtherDispatchEntryType. <baseType>uint16</baseType>
</synopsis> <rangeRestriction>
<array type="variable-size"> <allowedRange min="0" max="4095"/>
<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> </rangeRestriction>
</atomic> </atomic>
</dataTypeDef>
<dataTypeDef>
<name>VlanInputTableEntryType</name>
<synopsis>
Data type for entry of VLAN input table in EtherClassifier
LFB
</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>Reserved for future use</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 VlanInputTable in EtherClassifier LFB. The
entry type is defined by VlanInputTableEntryType. Each row
of the table is a struct containing an Incoming Port ID, a
VLAN ID and a Logical Port ID. Every input packet is
assigned with a new LogicalPortID according to the packet
incoming port ID and the VLAN ID. Then, the
EtherDispatchTable in the LFB dispatches every Ethernet
packet to different output according to the logical port ID
assigned by the VlanInputTable to the packet and the
Ethernet type in the Ethernet packet header.
</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 as defined in Ethernet packet header
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>PacketsNum</name>
<synopsis>Packets number</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>EtherClassifyStatsTableType</name>
<synopsis>
Data type for Ethernet classifying statistics table in
EtherClassifier LFB, the entry of which is defined by
EtherClassifyStatsType.
</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 bad header packets</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 bad TTL packets</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="4">
<name>badChecksumPkts</name>
<synopsis>Number of bad checksum packets</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 bad header packets</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name>badTotalLengthPkts</name>
<synopsis>Number of bad total length packets</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="3">
<name>badHopLimitPkts</name>
<synopsis>Number of bad hop limit packets</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv4PrefixInfoType</name> <name>VlanPriorityType</name>
<synopsis>Data type for entry of IPv4 prefix table</synopsis> <synopsis>Data type for VLAN priority</synopsis>
<struct> <atomic>
<component componentID="1"> <baseType>uchar</baseType>
<name>IPv4Address</name> <rangeRestriction>
<synopsis>The IPv4 address</synopsis> <allowedRange min="0" max="7"/>
<typeRef>IPv4Addr</typeRef> </rangeRestriction>
</component> </atomic>
<component componentID="2"> </dataTypeDef>
<name>Prefixlen</name> <dataTypeDef>
<synopsis>The prefix length</synopsis> <name>VlanInputTableEntryType</name>
<atomic> <synopsis>
<baseType>uchar</baseType> Data type for entry of VLAN input table in EtherClassifier
<rangeRestriction> LFB. Each entry of the table contains an incoming port ID,
<allowedRange min="0" max="32"/> a VLAN ID and a logical port ID. Every input packet is
</rangeRestriction> assigned with a new logical port ID according to the
</atomic> packet incoming port ID and the VLAN ID.
</component> </synopsis>
<component componentID="3"> <struct>
<name>ECMPFlag</name> <component componentID="1">
<synopsis>ECMP flag</synopsis> <name>IncomingPortID</name>
<atomic> <synopsis>The incoming port ID</synopsis>
<baseType>boolean</baseType> <typeRef>uint32</typeRef>
<specialValues> </component>
<specialValue value="false"> <component componentID="2">
<name>False</name> <name>VlanID</name>
<synopsis> <synopsis>The VLAN ID</synopsis>
ECMP flag is false, indicating the route <typeRef>VlanIDType</typeRef>
does not have multiple next hops. </component>
<component componentID="3">
</synopsis> <name>Reserved</name>
</specialValue> <synopsis>
<specialValue value="true"> A reserved bit space mainly for purpose of padding
<name>True</name> and packing efficiency.
<synopsis> </synopsis>
ECMP flag is true, indicating the route <typeRef>uint16</typeRef>
has multiple next hops. </component>
</synopsis> <component componentID="4">
</specialValue> <name>LogicalPortID</name>
</specialValues> <synopsis>The logical port ID</synopsis>
</atomic> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="4"> </struct>
<name>DefaultRouteFlag</name> </dataTypeDef>
<synopsis>Default route flag</synopsis> <dataTypeDef>
<atomic> <name>VlanInputTableType</name>
<baseType>boolean</baseType> <synopsis>
<specialValues> Data type for the VLAN input table in EtherClassifier
<specialValue value="false"> LFB. The table is composed of an array of entries with
<name>False</name> VlanInputTableEntryType.
<synopsis>
Default route flag is false, indicating the
route is not a default route.
</synopsis>
</specialValue>
<specialValue value="true">
<name>True</name>
<synopsis>
Default route flag is true, indicating the
route is a default route.
</synopsis>
</specialValue>
</specialValues>
</atomic>
</component>
<component componentID="5">
<name>Reserved</name>
<synopsis>Reserved for future use</synopsis>
<typeRef>uchar</typeRef>
</component>
<component componentID="6">
<name>HopSelector</name>
<synopsis>
HopSelector is produced by the prefix match LFB and
output to downstream LFBs as a next hop information
identifier.
</synopsis>
<typeRef>uint32</typeRef>
</component> </synopsis>
</struct> <array type="variable-size">
</dataTypeDef> <typeRef>VlanInputTableEntryType</typeRef>
<dataTypeDef> </array>
<name>IPv4PrefixTableType</name> </dataTypeDef>
<synopsis> <dataTypeDef>
Data type for IPv4 longest prefix match table used for <name>EtherClassifyStatsType</name>
IPv4UcastLPM LFB. The destination IPv4 address of every <synopsis>
input packet is used as a search key to look up the table Data type for entry of statistics table in EtherClassifier
to find out a next hop selector. Entry type of the table is LFB.
defined by IPv4PrefixInfoType. </synopsis>
</synopsis> <struct>
<array type="variable-size"> <component componentID="1">
<typeRef>IPv4PrefixInfoType</typeRef> <name>EtherType</name>
</array> <synopsis>
</dataTypeDef> The Ethernet type of the Ethernet packet.
<dataTypeDef> </synopsis>
<name>IPv4UcastLPMStatsType</name> <typeRef>uint16</typeRef>
<synopsis>Statistics type in IPv4UcastLPM LFB</synopsis> </component>
<struct> <component componentID="2">
<component componentID="1"> <name>Reserved</name>
<name>InRcvdPkts</name> <synopsis>
<synopsis> A reserved bit space mainly for purpose of padding
Total number of input packets received and packing efficiency.
</synopsis> </synopsis>
<typeRef>uint64</typeRef> <typeRef>uint16</typeRef>
</component> </component>
<component componentID="2"> <component componentID="3">
<name>FwdPkts</name> <name>PacketsNum</name>
<synopsis>Packets forwarded by the LFB</synopsis> <synopsis>Packets number</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
<component componentID="3"> </struct>
<name>NoRoutePkts</name> </dataTypeDef>
<synopsis>Packets with no routes found</synopsis> <dataTypeDef>
<typeRef>uint64</typeRef> <name>EtherClassifyStatsTableType</name>
</component> <synopsis>
</struct> Data type for statistics table in EtherClassifier LFB.
</dataTypeDef> </synopsis>
<dataTypeDef> <array type="variable-size">
<name>IPv6PrefixInfoType</name> <typeRef>EtherClassifyStatsType</typeRef>
<synopsis>Entry type for IPv6 prefix table</synopsis> </array>
<struct> </dataTypeDef>
<component componentID="1"> <dataTypeDef>
<name>IPv6Address</name> <name>IPv4ValidatorStatsType</name>
<synopsis>The IPv6 address</synopsis> <synopsis>
<typeRef>IPv6Addr</typeRef> Data type for statistics in IPv4validator LFB.
</component> </synopsis>
<component componentID="2"> <struct>
<name>Prefixlen</name> <component componentID="1">
<synopsis>The prefix length</synopsis> <name>badHeaderPkts</name>
<atomic> <synopsis>Number of packets with bad header</synopsis>
<baseType>uchar</baseType> <typeRef>uint64</typeRef>
<rangeRestriction> </component>
<allowedRange min="0" max="32"/> <component componentID="2">
</rangeRestriction> <name>badTotalLengthPkts</name>
</atomic> <synopsis>
</component> Number of packets with bad total length
<component componentID="3"> </synopsis>
<name>ECMPFlag</name> <typeRef>uint64</typeRef>
<synopsis>ECMP flag</synopsis> </component>
<atomic> <component componentID="3">
<baseType>boolean</baseType> <name>badTTLPkts</name>
<specialValues> <synopsis>Number of packets with bad TTL</synopsis>
<specialValue value="false"> <typeRef>uint64</typeRef>
<name>False</name> </component>
<synopsis> <component componentID="4">
ECMP flag is false, indicating the route <name>badChecksumPkts</name>
does not have multiple next hops. <synopsis>Number of packets with bad checksum</synopsis>
</synopsis> <typeRef>uint64</typeRef>
</specialValue> </component>
<specialValue value="true"> </struct>
<name>True</name> </dataTypeDef>
<synopsis> <dataTypeDef>
ECMP flag is true, indicating the route has <name>IPv6ValidatorStatsType</name>
multiple next hops. <synopsis>
</synopsis> Data type for statistics in IPv6validator LFB.
</specialValue> </synopsis>
</specialValues> <struct>
</atomic> <component componentID="1">
</component> <name>badHeaderPkts</name>
<component componentID="4"> <synopsis>Number of packets with bad header</synopsis>
<name>DefaultRouteFlag</name> <typeRef>uint64</typeRef>
<synopsis>Default route flag</synopsis> </component>
<atomic> <component componentID="2">
<baseType>boolean</baseType> <name>badTotalLengthPkts</name>
<specialValues> <synopsis>
<specialValue value="false"> Number of packets with bad total length.
<name>False</name> </synopsis>
<synopsis> <typeRef>uint64</typeRef>
Default route flag is false, indicating the </component>
route is not a default route. <component componentID="3">
</synopsis> <name>badHopLimitPkts</name>
</specialValue> <synopsis>
<specialValue value="true"> Number of packets with bad hop limit.
<name>True</name> </synopsis>
<synopsis> <typeRef>uint64</typeRef>
Default route flag is true, indicating the </component>
route is a default route. </struct>
</synopsis> </dataTypeDef>
</specialValue> <dataTypeDef>
</specialValues> <name>IPv4PrefixInfoType</name>
</atomic> <synopsis>Data type for entry of IPv4 longest prefix match
</component> table in IPv4UcastLPM LFB. The destination IPv4 address
<component componentID="5"> of every input packet is used as a search key to look up
<name>Reserved</name> the table to find out a next hop selector.</synopsis>
<synopsis>Reserved for future use</synopsis> <struct>
<typeRef>uchar</typeRef> <component componentID="1">
</component> <name>IPv4Address</name>
<component componentID="6"> <synopsis>The destination IPv4 address</synopsis>
<name>HopSelector</name> <typeRef>IPv4Addr</typeRef>
<synopsis> </component>
HopSelector is produced by the prefix match LFB and <component componentID="2">
output to downstream LFBs as a next hop information <name>Prefixlen</name>
identifier. <synopsis>The prefix length</synopsis>
</synopsis> <atomic>
<typeRef>uint32</typeRef> <baseType>uchar</baseType>
</component> <rangeRestriction>
</struct> <allowedRange min="0" max="32"/>
</dataTypeDef> </rangeRestriction>
<dataTypeDef> </atomic>
<name>IPv6PrefixTableType</name> </component>
<synopsis> <component componentID="3">
Data type for IPv6 longest prefix match table used for <name>ECMPFlag</name>
IPv6UcastLPM LFB. The destination IPv6 address of every <synopsis>The ECMP flag</synopsis>
input packet is used as a search key to look up the table <atomic>
to find out a next hop selector. Entry type of the table is <baseType>boolean</baseType>
defined by IPv6PrefixInfoType. <specialValues>
</synopsis> <specialValue value="false">
<array type="variable-size"> <name>False</name>
<typeRef>IPv6PrefixInfoType</typeRef> <synopsis>
</array> ECMP false, indicating the route
</dataTypeDef> does not have multiple next hops.
<dataTypeDef> </synopsis>
<name>IPv6UcastLPMStatsType</name> </specialValue>
<synopsis>Statistics type in IPv6UcastLPM LFB</synopsis> <specialValue value="true">
<struct> <name>True</name>
<component componentID="1"> <synopsis>
<name>InRcvdPkts</name> ECMP true, indicating the route
<synopsis> has multiple next hops.
Total number of input packets received </synopsis>
</synopsis> </specialValue>
<typeRef>uint64</typeRef> </specialValues>
</component> </atomic>
<component componentID="2">
<name>FwdPkts</name>
<synopsis>Packets forwarded by the LFB</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="3">
<name>NoRoutePkts</name>
<synopsis>Packets with no routes found</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv4NextHopInfoType</name>
<synopsis>
Data type for entry of IPv4 next hop information table used
in IPv4NextHop LFB.
</synopsis>
<struct>
<component componentID="1">
<name>L3PortID</name>
<synopsis>
The L3PortID is the ID of the logical output port
that is passed onto the 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>Next hop IPv4 address</synopsis>
<typeRef>IPv4Addr</typeRef>
</component>
<component componentID="4">
<name>MediaEncapInfoIndex</name>
<synopsis>
The index is passed onto the downstream encapsulation
LFB instance and is used there as a search key to
lookup the index of a table (typically media
encapsulation related) for further encapsulation
information.
</synopsis> </component>
<typeRef>uint32</typeRef> <component componentID="4">
</component> <name>DefaultRouteFlag</name>
<component componentID="5"> <synopsis>Default route flag</synopsis>
<name>LFBOutputSelectIndex</name> <atomic>
<synopsis> <baseType>boolean</baseType>
The index is for the LFB Group output port to select <specialValues>
downstream LFB port. It is a 1-to-1 mapping with <specialValue value="false">
FEObject LFB's table LFBTopology component <name>False</name>
FromPortIndex corresponding to the port group mapping <synopsis>
FromLFBID as IPv4NextHop LFB instance. Default route false, indicating the
</synopsis> route is not a default route.
<typeRef>uint32</typeRef> </synopsis>
</component> </specialValue>
</struct> <specialValue value="true">
</dataTypeDef> <name>True</name>
<dataTypeDef> <synopsis>
<name>IPv4NextHopTableType</name> Default route true, indicating the
<synopsis> route is a default route.
Data type for IPv4 next hop table in IPv4NextHop LFB. The </synopsis>
LFB uses a hop selector metadata received from upstream LFB </specialValue>
as a search key to look up the index of the table to get </specialValues>
next hop information. Entry type of the table is defined by </atomic>
IPv4NextHopInfoType. </component>
</synopsis> <component componentID="5">
<array type="variable-size"> <name>Reserved</name>
<typeRef>IPv4NextHopInfoType</typeRef> <synopsis>
</array> A reserved bit space mainly for purpose of padding
</dataTypeDef> and packing efficiency.
<dataTypeDef> </synopsis>
<name>IPv6NextHopInfoType</name> <typeRef>uchar</typeRef>
<synopsis> </component>
Data type for entry of IPv6 next hop information table used <component componentID="6">
in IPv6NextHop LFB. <name>HopSelector</name>
</synopsis> <synopsis>
<struct> The HopSelector produced by the prefix matching LFB,
<component componentID="1"> which will be output to downstream LFB to find next
<name>L3PortID</name> 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="32"/>
</rangeRestriction>
</atomic>
</component>
<component componentID="3">
<name>ECMPFlag</name>
<synopsis>ECMP flag</synopsis>
<atomic>
<baseType>boolean</baseType>
<specialValues>
<specialValue value="false">
<name>False</name>
<synopsis>ECMP false</synopsis>
</specialValue>
<specialValue value="true">
<name>True</name>
<synopsis>ECMP true</synopsis>
</specialValue>
</specialValues>
</atomic>
</component>
<component componentID="4">
<name>DefaultRouteFlag</name>
<synopsis>Default route flag</synopsis>
<atomic>
<baseType>boolean</baseType>
<specialValues>
<specialValue value="false">
<name>False</name>
<synopsis>Default false</synopsis>
</specialValue>
<specialValue value="true">
<name>True</name>
<synopsis>Default route true</synopsis>
</specialValue>
</specialValues>
</atomic>
</component>
<component componentID="5">
<name>Reserved</name>
<synopsis>
A reserved bit space mainly for purpose of padding
and packing efficiency.
</synopsis>
<typeRef>uchar</typeRef>
</component>
<component componentID="6">
<name>HopSelector</name>
<synopsis>
The HopSelector produced by the prefix matching LFB,
which will be output to downstream LFB to find next
hop information.
</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv6PrefixTableType</name>
<synopsis>
Data type for IPv6 longest prefix match table in
IPv6UcastLPM LFB. Entry of the table is
of IPv6PrefixInfoType data type.
</synopsis>
<array type="variable-size">
<typeRef>IPv6PrefixInfoType</typeRef>
</array>
</dataTypeDef>
<dataTypeDef>
<name>IPv6UcastLPMStatsType</name>
<synopsis>Data type for statistics in IPv6UcastLPM LFB
</synopsis>
<struct>
<component componentID="1">
<name>InRcvdPkts</name>
<synopsis>Number of received input packets</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name>FwdPkts</name>
<synopsis>Number of forwarded packets</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="3">
<name>NoRoutePkts</name>
<synopsis>
Number of packets with no route found.
</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv4NextHopInfoType</name>
<synopsis>
Data type for entry of IPv4 next hop information table
in IPv4NextHop LFB. The table uses a hop selector
received from upstream LFB as a search key to look up
index of the table to find the next hop information.
</synopsis>
<struct>
<component componentID="1">
<name>L3PortID</name>
<synopsis>
The ID of the logical output port that is to pass
onto downstream LFB, indicating what port to the
neighbor is as defined by L3.
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>MTU</name>
<synopsis>
Maximum Transmission Unit for outgoing port
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>NextHopIPAddr</name>
<synopsis>The next hop IPv4 address</synopsis>
<typeRef>IPv4Addr</typeRef>
</component>
<component componentID="4">
<name>MediaEncapInfoIndex</name>
<synopsis>
The index passed onto a downstream encapsulation
LFB, used there as a search key to lookup further
encapsulation information.
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="5">
<name>LFBOutputSelectIndex</name>
<synopsis> <synopsis>
The L3PortID is the ID of the logical output port The index for the IPv4NextHop LFB to choose an
that is passed onto the downstream LFB, indicating instance in the group output port of the LFB to
what port to the neighbor is as defined by L3. output.
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="2"> </struct>
<name>MTU</name> </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> <synopsis>
Maximum Transmission Unit for outgoing port The index for the IPv6NextHop LFB to choose an instance
in the group output port of the LFB to output.
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="3"> </struct>
<name>NextHopIPAddr</name> </dataTypeDef>
<synopsis>Next hop IPv6 address</synopsis> <dataTypeDef>
<typeRef>IPv6Addr</typeRef> <name>IPv6NextHopTableType</name>
</component> <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"> <component componentID="4">
<name>MediaEncapInfoIndex</name> <name>Reserved</name>
<synopsis> <synopsis>
The index is passed onto the downstream encapsulation A reserved bit space mainly for purpose of padding
LFB instance and is used there as a search key to and packing efficiency.
lookup the index of a table (typically media </synopsis>
encapsulation related) for further encapsulation <typeRef>uint16</typeRef>
information. </component>
</synopsis> <component componentID="5">
<typeRef>uint32</typeRef> <name>L2PortID</name>
</component> <synopsis>
<component componentID="5"> The L2 logical output port ID for the packet.
<name>LFBOutputSelectIndex</name> </synopsis>
<synopsis> <typeRef>uint32</typeRef>
The index is for the LFB group output port to select </component>
downstream LFB port. It is a 1-to-1 mapping with </struct>
FEObject LFB's table LFBTopology component </dataTypeDef>
FromPortIndex corresponding to the port group mapping <dataTypeDef>
FromLFBID as IPv6NextHop LFB instance. <name>EncapTableType</name>
</synopsis> <synopsis>
<typeRef>uint32</typeRef> Data type for Ethernet encapsulation table in Etherencap
</component> LFB. Entry of the table is of EncapTableEntryType data
</struct> type.
</dataTypeDef> </synopsis>
<dataTypeDef> <array type="variable-size">
<name>IPv6NextHopTableType</name> <typeRef>EncapTableEntryType</typeRef>
<synopsis> </array>
Data type for IPv6 next hop table in IPv6NextHop LFB. The </dataTypeDef>
LFB uses a hop selector metadata received from upstream LFB <dataTypeDef>
as a search key to look up the index of the table to get <name>MetadataDispatchType</name>
next hop information. Entry type of the table is defined by <synopsis>
IPv6NextHopInfoType. Data type for entry of metadata dispatch table used in
</synopsis> BasicMetadataDispatch LFB. The LFB uses a metadata value
<array type="variable-size"> as a search key to look up the table to find an index of
<typeRef>IPv6NextHopInfoType</typeRef> the LFB group output port to output the packet.
</array> </synopsis>
</dataTypeDef> <struct>
<dataTypeDef> <component componentID="1">
<name>EncapTableEntryType</name> <name>MetadataValue</name>
<synopsis> <synopsis>The value of the dispatch metadata</synopsis>
Data type for entry of Ethernet encapsulation table in <typeRef>uint32</typeRef>
EtherEncap LFB. </component>
</synopsis> <component componentID="2">
<struct> <name>OutputIndex</name>
<component componentID="1"> <synopsis>
<name>DstMac</name> Index of a group output port for outgoing packets.
<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>Reserved for future use</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. The LFB uses the metadata "MediaEncapInfoIndex"
received from upstream LFB as the index of the table to
get encapsulation information of every packet.Entry type
of the table is defined by EncapTableEntryType.
</synopsis> </synopsis>
<array type="variable-size"> <typeRef>uint32</typeRef>
<typeRef>EncapTableEntryType</typeRef> </component>
</array> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>MetadataDispatchType</name> <name>MetadataDispatchTableType</name>
<synopsis> <synopsis>
Data type for entry of metadata dispatch table used Data type for metadata dispatch table used in
in BasicMetadataDispatch LFB. BasicMetadataDispatch LFB. Metadata value of
</synopsis> the table is also defined as a content key field.
<struct> </synopsis>
<component componentID="1"> <array type="variable-size">
<name>MetadataValue</name> <typeRef>MetadataDispatchType</typeRef>
<synopsis>The value of the dispatch metadata</synopsis> <contentKey contentKeyID="1">
<typeRef>uint32</typeRef> <contentKeyField>MetadataValue</contentKeyField>
</component> </contentKey>
<component componentID="2"> </array>
<name>OutputIndex</name> </dataTypeDef>
<synopsis> <dataTypeDef>
Index of a group output port for outgoing packets <name>SchdDisciplineType</name>
with the dispatch metadata value. <synopsis>Scheduling discipline type</synopsis>
</synopsis> <atomic>
<typeRef>uint32</typeRef> <baseType>uint32</baseType>
</component> <specialValues>
</struct> <specialValue value="1">
</dataTypeDef> <name>RR</name>
<dataTypeDef> <synopsis>
<name>MetadataDispatchTableType</name> Round Robin scheduling discipline
<synopsis> </synopsis>
Data type for metadata dispatch table used in </specialValue>
BasicMetadataDispatch LFB. The LFB uses a metadata value as </specialValues>
the search key to look up the table to get an index of the </atomic>
LFB group output port for output of the packet. Metadata </dataTypeDef>
value of the table is also defined as a content key field so <dataTypeDef>
that CE can manipulate the table by means of a content key. <name>QueueStatsType</name>
</synopsis> <synopsis>
<array type="variable-size"> Data type for entry of queue statistics table in
<typeRef>MetadataDispatchType</typeRef> GenericScheduler LFB.
<contentKey contentKeyID="1"> </synopsis>
<contentKeyField>MetadataValue</contentKeyField> <struct>
</contentKey> <component componentID="1">
</array> <name>QueueID</name>
</dataTypeDef> <synopsis>The input queue ID</synopsis>
<dataTypeDef> <typeRef>uint32</typeRef>
<name>SchdDisciplineType</name> </component>
<synopsis>Scheduling discipline types</synopsis> <component componentID="2">
<atomic> <name>QueueDepthInPackets</name>
<baseType>uint32</baseType> <synopsis>Current queue depth in packets</synopsis>
<specialValues> <typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>QueueDepthInBytes</name>
<synopsis>Current queue depth in bytes</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>QueueStatsTableType</name>
<synopsis>
Data type for queue statistics table in GenericScheduler
LFB. Entry of the table is of QueueStatsType data type.
</synopsis>
<array type="variable-size">
<typeRef>QueueStatsType</typeRef>
</array>
</dataTypeDef>
</dataTypeDefs>
<metadataDefs>
<metadataDef>
<name>PHYPortID</name>
<synopsis>Metadata indicating physical port ID</synopsis>
<metadataID>1</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
<metadataDef>
<name>SrcMAC</name>
<synopsis>Metadata indicating source MAC address</synopsis>
<metadataID>2</metadataID>
<typeRef>IEEEMAC</typeRef>
</metadataDef>
<metadataDef>
<name>DstMAC</name>
<synopsis>
Metadata indicating destination MAC address.
</synopsis>
<metadataID>3</metadataID>
<typeRef>IEEEMAC</typeRef>
</metadataDef>
<metadataDef>
<name>LogicalPortID</name>
<synopsis>Metadata of logical port ID</synopsis>
<metadataID>4</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
<metadataDef>
<name>EtherType</name>
<synopsis>Metadata indicating Ethernet type</synopsis>
<metadataID>5</metadataID>
<typeRef>uint16</typeRef>
</metadataDef>
<metadataDef>
<name>VlanID</name>
<synopsis>Metadata of VLAN ID</synopsis>
<metadataID>6</metadataID>
<typeRef>VlanIDType</typeRef>
</metadataDef>
<metadataDef>
<name>VlanPriority</name>
<synopsis>Metadata of VLAN priority</synopsis>
<metadataID>7</metadataID>
<typeRef>VlanPriorityType</typeRef>
</metadataDef>
<metadataDef>
<name>NextHopIPv4Addr</name>
<synopsis>
Metadata representing a next hop IPv4 address
</synopsis>
<metadataID>8</metadataID>
<typeRef>IPv4Addr</typeRef>
</metadataDef>
<metadataDef>
<name>NextHopIPv6Addr</name>
<synopsis>
Metadata representing a next hop IPv6 address
</synopsis>
<metadataID>9</metadataID>
<typeRef>IPv6Addr</typeRef>
</metadataDef>
<metadataDef>
<name>HopSelector</name>
<synopsis>Metadata indicating a hop selector</synopsis>
<metadataID>10</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
<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"> <specialValue value="1">
<name>RR</name> <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> <synopsis>
Round Robin scheduling discipline 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>SrcAddressExecption</name>
<synopsis>
Exception case: packet with exceptional source
address.
</synopsis>
</specialValue>
<specialValue value="10">
<name>DstAddressExecption</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> </synopsis>
</specialValue> </specialValue>
</specialValues> </specialValues>
</atomic> </atomic>
</dataTypeDef> </metadataDef>
<dataTypeDef> <metadataDef>
<name>QueueStatsType</name> <name>ValidateErrorID</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 type of the table is defined by QueueStatsType.
</synopsis>
<array type="variable-size">
<typeRef>QueueStatsType</typeRef>
</array>
</dataTypeDef>
</dataTypeDefs>
<metadataDefs>
<metadataDef>
<name>PHYPortID</name>
<synopsis>Metadata indicating a physical port ID</synopsis>
<metadataID>1</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
<metadataDef>
<name>SrcMAC</name>
<synopsis>Metadata indicating a source MAC address</synopsis>
<metadataID>2</metadataID>
<typeRef>IEEEMAC</typeRef>
</metadataDef>
<metadataDef>
<name>DstMAC</name>
<synopsis>
Metadata indicating a destination MAC address
</synopsis>
<metadataID>3</metadataID>
<typeRef>IEEEMAC</typeRef>
</metadataDef>
<metadataDef>
<name>LogicalPortID</name>
<synopsis>Metadata of a logical port ID</synopsis>
<metadataID>4</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
<metadataDef>
<name>EtherType</name>
<synopsis>Metadata indicating an Ethernet type</synopsis>
<metadataID>5</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
<metadataDef>
<name>VlanID</name>
<synopsis>Metadata of a VLAN ID</synopsis>
<metadataID>6</metadataID>
<typeRef>VlanIDType</typeRef>
</metadataDef>
<metadataDef>
<name>VlanPriority</name>
<synopsis>Metadata of a 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> <synopsis>
Metadata indicating exception types for exceptional cases Metadata indicating error types when a packet passes
during LFB processing. validation process.
</synopsis> </synopsis>
<metadataID>11</metadataID> <metadataID>12</metadataID>
<atomic> <atomic>
<baseType>uint32</baseType> <baseType>uint32</baseType>
<specialValues> <specialValues>
<specialValue value="0"> <specialValue value="0">
<name>AnyUnrecognizedExceptionCase</name> <name>AnyUnrecognizedValidateErrorCase</name>
<synopsis>Any unrecognized exception case</synopsis>
</specialValue>
<specialValue value="1">
<name>ClassifyNoMatching</name>
<synopsis> <synopsis>
There is no matching of tables in EtherClassifier Any unrecognized validate error case.
LFB.
</synopsis> </synopsis>
</specialValue> </specialValue>
<specialValue value="2"> <specialValue value="1">
<name>MediaEncapInfoIndexInvalid</name> <name>InvalidIPv4PacketSize</name>
<synopsis>
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> <synopsis>
The packet failed lookup of the EncapTable table Error case: packet length reported by the link
in EtherEncap LFB even though the layer is less than 20 bytes.
MediaEncapInfoIndex is valid.
</synopsis> </synopsis>
</specialValue> </specialValue>
<specialValue value="4"> <specialValue value="2">
<name>BadTTL</name> <name>NotIPv4Packet</name>
<synopsis>Packet with expired TTL</synopsis>
</specialValue>
<specialValue value="5">
<name>IPv4HeaderLengthMismatch</name>
<synopsis> <synopsis>
Packet with header length more than 5 words 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> </synopsis>
</specialValue> </specialValue>
<specialValue value="6"> <specialValue value="4">
<name>RouterAlertOptions</name> <name>InvalidIPv4LengthFieldSize</name>
<synopsis> <synopsis>
Packet IP head includes router alert Options Error case: packet with total length field in the
</synopsis> header less than 20 bytes.
</specialValue> </synopsis>
<specialValue value="7"> </specialValue>
<name>IPv6HopLimitZero</name> <specialValue value="5">
<synopsis>Packet with the hop limit zero</synopsis> <name>InvalidIPv4Checksum</name>
</specialValue> <synopsis>
<specialValue value="8"> Error case: packet with invalid checksum.
<name>IPv6NextHeaderHBH</name>
<synopsis>
Packet with next header set to Hop-by-Hop
</synopsis>
</specialValue>
<specialValue value="9">
<name>SrcAddressExecption</name>
<synopsis>
Packet with exceptional source address
</synopsis>
</specialValue>
<specialValue value="10">
<name>DstAddressExecption</name>
<synopsis>
Packet with exceptional destination address
</synopsis>
</specialValue>
<specialValue value="11">
<name>LPMLookupFailed</name>
<synopsis>
Packet failed the LPM table lookup in a prefix
match LFB.
</synopsis>
</specialValue>
<specialValue value="12">
<name>HopSelectorInvalid</name>
<synopsis>
HopSelector for the packet is invalid
</synopsis>
</specialValue>
<specialValue value="13">
<name>NextHopLookupFailed</name>
<synopsis>
Packet failed lookup of a next hop table even
though HopSelector is valid.
</synopsis>
</specialValue>
<specialValue value="14">
<name>FragRequired</name>
<synopsis>
Packet fragmentation is required
</synopsis>
</specialValue>
<specialValue value="15">
<name>MetadataNoMatching</name>
<synopsis>
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>
Packet length reported by the link layer is less
than 20 bytes.
</synopsis>
</specialValue>
<specialValue value="2">
<name>NotIPv4Packet</name>
<synopsis>Packet is not IP version 4</synopsis>
</specialValue>
<specialValue value="3">
<name>InvalidIPv4HeaderLengthSize</name>
<synopsis>
Packet with header length field in the header
less than 5 words.
</synopsis>
</specialValue>
<specialValue value="4">
<name>InvalidIPv4LengthFieldSize</name>
<synopsis>
Packet with total length field in the header less
than 20 bytes.
</synopsis>
</specialValue>
<specialValue value="5">
<name>InvalidIPv4Checksum</name>
<synopsis>Packet with invalid checksum</synopsis>
</specialValue>
<specialValue value="6">
<name>InvalidIPv4SrcAddr</name>
<synopsis>
Packet with invalid IPv4 source address
</synopsis>
</specialValue>
<specialValue value="7">
<name>InvalidIPv4DstAddr</name>
<synopsis>
Packet with invalid IPv4 destination address
</synopsis>
</specialValue>
<specialValue value="8">
<name>InvalidIPv6PacketSize</name>
<synopsis>
Packet size is less than 40 bytes
</synopsis>
</specialValue>
<specialValue value="9">
<name>NotIPv6Packet</name>
<synopsis>Packet is not IP version 6</synopsis>
</specialValue>
<specialValue value="10">
<name>InvalidIPv6SrcAddr</name>
<synopsis>
Packet with invalid IPv6 source address
</synopsis> </synopsis>
</specialValue> </specialValue>
<specialValue value="11"> <specialValue value="6">
<name>InvalidIPv6DstAddr</name> <name>InvalidIPv4SrcAddr</name>
<synopsis> <synopsis>
Packet with invalid IPv6 destination address 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> </synopsis>
</specialValue> </specialValue>
</specialValues> <specialValue value="10">
</atomic> <name>InvalidIPv6SrcAddr</name>
</metadataDef> <synopsis>
<metadataDef> Error case: packet with invalid IPv6 source address.
<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 an
associated packet a group output port index of the LFB.
</synopsis>
<metadataID>14</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
<metadataDef>
<name>MediaEncapInfoIndex</name>
<synopsis>
A search key a packet uses to look up a table in related
LFBs to select an encapsulation media.
</synopsis>
<metadataID>15</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
</metadataDefs>
</LFBLibrary>
</synopsis>
</specialValue>
<specialValue value="11">
<name>InvalidIPv6DstAddr</name>
<synopsis>
Error case: packet with invalid IPv6 destination
address.
</synopsis>
</specialValue>
</specialValues>
</atomic>
</metadataDef>
<metadataDef>
<name>L3PortID</name>
<synopsis>
Metadata indicating ID of an L3 logical port
</synopsis>
<metadataID>13</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
<metadataDef>
<name>RedirectIndex</name>
<synopsis>
Metadata that CE sends to RedirectIn LFB, indicating
the index of the LFB group output port.
</synopsis>
<metadataID>14</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
<metadataDef>
<name>MediaEncapInfoIndex</name>
<synopsis>
A search key a packet uses to look up a table to select
an encapsulation media.
</synopsis>
<metadataID>15</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
</metadataDefs>
</LFBLibrary>
5. LFB Class Description 5. LFB Class Description
According to ForCES specifications, LFB (Logical Function Block) is a According to ForCES specifications, LFB (Logical Function Block) is a
well defined, logically separable functional block that resides in an well defined, logically separable functional block that resides in an
FE, and is a functionally accurate abstraction of the FE's processing FE, and is a functionally accurate abstraction of the FE's processing
capabilities. An LFB Class (or type) is a template that represents a capabilities. An LFB Class (or type) is a template that represents a
fine-grained, logically separable aspect of FE processing. Most LFBs fine-grained, logically separable aspect of FE processing. Most LFBs
are related to packet processing in the data path. LFB classes are are related to packet processing in the data path. LFB classes are
the basic building blocks of the FE model. Note that [RFC5810] has the basic building blocks of the FE model. Note that [RFC5810] has
already defined an 'FE Protocol LFB' which is a logical entity in already defined an 'FE Protocol LFB' which is a logical entity in
skipping to change at page 52, line 28 skipping to change at page 52, line 28
many components defined in this LFB are as aliases of EtherMACIn LFB many components defined in this LFB are as aliases of EtherMACIn LFB
components. components.
5.1.5.1. Data Handling 5.1.5.1. Data Handling
The LFB is expected to receive all types of Ethernet packets, via a The LFB is expected to receive all types of Ethernet packets, via a
singleton input known as "EtherPktsIn", which are usually output from singleton input known as "EtherPktsIn", which are usually output from
an Ethernet encapsulation LFB, alongside with a metadata indicating an Ethernet encapsulation LFB, alongside with a metadata indicating
the physical port ID that the packet will go through. the physical port ID that the packet will go through.
The LFB is defined with a singleton output. All Output packets are The LFB is defined with a singleton output port known as
in Ethernet format, possibly with various Ethernet types, alongside "EtherPktsOut". All Output packets are in Ethernet format, possibly
with a metadata indicating the physical port ID the packet is to go with various Ethernet types, alongside with a metadata indicating the
through. This output links to a downstream LFB that is usually an physical port ID the packet is to go through. This output links to a
Ethernet physical LFB like EtherPHYcop LFB. downstream LFB that is usually an Ethernet physical LFB like
EtherPHYcop LFB.
This LFB can optionally participate in Ethernet flow control in This LFB can optionally participate in Ethernet flow control in
cooperation with EtherMACIn LFB. This document does not go into the cooperation with EtherMACIn LFB. This document does not go into the
details of how this is implemented; the reader may refer to some details of how this is implemented; the reader may refer to some
relevant references. This document also does not describe how the relevant references. This document also does not describe how the
buffers which induce the flow control messages behave - it is assumed buffers which induce the flow control messages behave - it is assumed
that such artifacts exist and describing them is out of scope in this that such artifacts exist and describing them is out of scope in this
document. document.
Note that as a base definition, functions like multiple virtual MAC Note that as a base definition, functions like multiple virtual MAC
skipping to change at page 53, line 44 skipping to change at page 53, line 45
This LFB does not have any events specified. This LFB does not have any events specified.
5.2. IP Packet Validation LFBs 5.2. IP Packet Validation LFBs
The LFBs are defined to abstract IP packet validation process. An The LFBs are defined to abstract IP packet validation process. An
IPv4Validator LFB is specifically for IPv4 protocol validation and an IPv4Validator LFB is specifically for IPv4 protocol validation and an
IPv6Validator LFB for IPv6. IPv6Validator LFB for IPv6.
5.2.1. IPv4Validator 5.2.1. IPv4Validator
The IPv4Validator LFB performs IPv4 packets validation according to The IPv4Validator LFB performs IPv4 packets validation.
[RFC5812].
5.2.1.1. Data Handling 5.2.1.1. Data Handling
This LFB performs IPv4 validation according to [RFC5812]. The IPv4 This LFB performs IPv4 validation according to [RFC1812] and its
packet will be output to the corresponding LFB port the indication updates. The IPv4 packet will be output to the corresponding LFB
whether the packet is unicast, multicast or whether an exception has port the indication whether the packet is unicast, multicast or
occurred or the validation failed. whether an exception has occurred or the validation failed.
This LFB always expects, as input, packets which have been indicated This LFB always expects, as input, packets which have been indicated
as IPv4 packets by an upstream LFB, like an EtherClassifier LFB. as IPv4 packets by an upstream LFB, like an EtherClassifier LFB.
There is no specific metadata expected by the input of the LFB. There is no specific metadata expected by the input of the LFB.
Four output LFB ports are defined. Four output LFB ports are defined.
All validated IPv4 unicast packets will be output at the singleton All validated IPv4 unicast packets will be output at the singleton
port known as "IPv4UnicastOut". All validated IPv4 multicast packets port known as "IPv4UnicastOut". All validated IPv4 multicast packets
will be output at the singleton port known as "IPv4MulticastOut" will be output at the singleton port known as "IPv4MulticastOut"
skipping to change at page 55, line 31 skipping to change at page 55, line 31
5.2.1.3. Capabilities 5.2.1.3. Capabilities
This LFB does not have a list of capabilities This LFB does not have a list of capabilities
5.2.1.4. Events 5.2.1.4. Events
This LFB does not have any events specified. This LFB does not have any events specified.
5.2.2. IPv6Validator 5.2.2. IPv6Validator
The IPv6Validator LFB performs IPv6 packets validation according to The IPv6Validator LFB performs IPv6 packets validation.
[RFC2460].
5.2.2.1. Data Handling 5.2.2.1. Data Handling
This LFB performs IPv6 validation according to [RFC2460]. Then the This LFB performs IPv6 validation according to [RFC2460] and its
IPv6 packet will be output to the corresponding port regarding of the updates. Then the IPv6 packet will be output to the corresponding
validation result, whether the packet is a unicast or a multicast port regarding of the validation result, whether the packet is a
one, an exception has occurred or the validation failed. unicast or a multicast one, an exception has occurred or the
validation failed.
This LFB always expects, as input, packets which have been indicated This LFB always expects, as input, packets which have been indicated
as IPv6 packets by an upstream LFB, like an EtherClassifier LFB. as IPv6 packets by an upstream LFB, like an EtherClassifier LFB.
There is no specific metadata expected by the input of the LFB. There is no specific metadata expected by the input of the LFB.
Similar to the IPv4validator LFB, IPv6Validator LFB has also defined Similar to the IPv4validator LFB, IPv6Validator LFB has also defined
four output ports to emit packets with various validation results. four output ports to emit packets with various validation results.
All validated IPv6 unicast packets will be output at the singleton All validated IPv6 unicast packets will be output at the singleton
port known as "IPv6UnicastOut". All validated IPv6 multicast packets port known as "IPv6UnicastOut". All validated IPv6 multicast packets
skipping to change at page 57, line 16 skipping to change at page 57, line 16
This LFB does not have any events specified. This LFB does not have any events specified.
5.3. IP Forwarding LFBs 5.3. IP Forwarding LFBs
IP Forwarding LFBs are specifically defined to abstract the IP IP Forwarding LFBs are specifically defined to abstract the IP
forwarding processes. As definitions for a base LFB library, this forwarding processes. As definitions for a base LFB library, this
document restricts its LFB definition scope only to IP unicast document restricts its LFB definition scope only to IP unicast
forwarding. IP multicast may be defined in future documents. forwarding. IP multicast may be defined in future documents.
A typical IP unicast forwarding job is usually realized by looking up The two fundamental tasks performed in IP unicast forwarding
the forwarding information table to find next hop information, and constitute looking up the forwarding information table to find next
then based on the next hop information, forwarding packets to hop information, and then using the resulting next hop details to
specific physical output ports. It usually takes two steps to do so, forward packets out on specific physical output ports. This document
firstly to look up a forwarding information table by means of Longest models the forwarding processes by abstracting out the described two
Prefix Matching(LPM) rule to find a next hop index, then to use the steps. Whereas this document describes functional LFB models which
index as a search key to look up a next hop information table to find are modular, there may be multiple ways to implement the abstracted
enough information to submit packets to output ports. This document models. It is not intended nor expected that the provided LFB models
abstracts the forwarding processes mainly based on the two steps constrain implementations.
model. However, there actually exists other models, like one which
may only have a forwarding information base that have conjoined next
hop information together with forwarding information. In this case,
if ForCES technology is to be applied, some translation work will
have to be done in the FE to translate attributes defined by this
document into attributes related to the implementation.
Based on the IP forwarding abstraction, two kind of typical IP Based on the IP forwarding abstraction, two kind of typical IP
unicast forwarding LFBs are defined, Unicast LPM lookup LFB and next unicast forwarding LFBs are defined, Unicast LPM lookup LFB and next
hop application LFB. They are further distinguished by IPv4 and IPv6 hop application LFB. They are further distinguished by IPv4 and IPv6
protocols. protocols.
5.3.1. IPv4UcastLPM 5.3.1. IPv4UcastLPM
The IPv4UcastLPM LFB abstracts the IPv4 unicast Longest Prefix Match The IPv4UcastLPM LFB abstracts the IPv4 unicast Longest Prefix Match
(LPM) process. (LPM) process.
This LFB also provides facilities to support users to implement This LFB also provides facilities to support users to implement
equal-cost multi-path routing (ECMP) or reverse path forwarding equal-cost multi-path routing (ECMP) or reverse path forwarding
(RPF). However, this LFB itself does not provide ECMP or RPF. To (RPF). However, this LFB itself does not provide ECMP or RPF. To
fully implement ECMP or RPF, additional specific LFBs, like a fully implement ECMP or RPF, additional specific LFBs, like a
specific ECMP LFB or an RPF LFB, will have to be defined. This work specific ECMP LFB or an RPF LFB, will have to be defined.
may be done in the future version of the document.
5.3.1.1. Data Handling 5.3.1.1. Data Handling
This LFB performs the IPv4 unicast LPM table looking up. It always This LFB performs the IPv4 unicast LPM table looking up. It always
expects as input IPv4 unicast packets from one singleton input known expects as input IPv4 unicast packets from one singleton input known
as "PktsIn". Then the LFB uses the destination IPv4 address of every as "PktsIn". Then the LFB uses the destination IPv4 address of every
packet as search key to look up the IPv4 prefix table and generate a packet as search key to look up the IPv4 prefix table and generate a
hop selector as the matching result. The hop selector is passed as hop selector as the matching result. The hop selector is passed as
packet metadata to downstream LFBs, and will usually be used there as packet metadata to downstream LFBs, and will usually be used there as
a search index to find more next hop information. a search index to find more next hop information.
skipping to change at page 68, line 27 skipping to change at page 68, line 13
Two output LFB ports are defined. Two output LFB ports are defined.
The first output is a group output port known as "PktsOut". A packet The first output is a group output port known as "PktsOut". A packet
with its associated metadata having found an OutputIndex by with its associated metadata having found an OutputIndex by
successfully looking up the dispatch table will be output to the successfully looking up the dispatch table will be output to the
group port instance with the corresponding index. group port instance with the corresponding index.
The second output is a singleton output port known as "ExceptionOut", The second output is a singleton output port known as "ExceptionOut",
which will output packets for which the data processing failed, along which will output packets for which the data processing failed, along
with an additional ExceptionID metadata to indicate what caused the with an additional ExceptionID metadata to indicate what caused the
exception. Currently defined exception types include: exception. Currently defined exception types only include one case:
o There is no matching when looking up the metadata dispatch table. o There is no matching when looking up the metadata dispatch table.
As an example, if the CE decides to dispatch packets according to a 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 physical port ID (PHYPortID), the CE may set the ID of PHYPortID
metadata to the LFB first. Moreover, the CE also sets the PHYPortID metadata to the LFB first. Moreover, the CE also sets the PHYPortID
actual values (the metadata values) and assigned OutputIndex for the actual values (the metadata values) and assigned OutputIndex for the
values to the dispatch table in the LFB. When a packet arrives, a values to the dispatch table in the LFB. When a packet arrives, a
PHYPortID metadata is found associated with the packet, the metadata PHYPortID metadata is found associated with the packet, the metadata
value is further used as a key to look up the dispatch table to find value is further used as a key to look up the dispatch table to find
skipping to change at page 69, line 31 skipping to change at page 69, line 19
5.5.2. GenericScheduler 5.5.2. GenericScheduler
This is a preliminary generic scheduler LFB for abstracting a simple This is a preliminary generic scheduler LFB for abstracting a simple
scheduling process. scheduling process.
5.5.2.1. Data Handling 5.5.2.1. Data Handling
There exist various kinds of scheduling strategies with various There exist various kinds of scheduling strategies with various
implementations. As a base LFB library, this document only defines a implementations. As a base LFB library, this document only defines a
preliminary generic scheduler LFB for abstracting a simple scheduling preliminary generic scheduler LFB for abstracting a simple scheduling
process. Users may use this LFB as a basic scheduler LFB to further process. Users may use this LFB as a basic LFB to further construct
construct more complex scheduler LFBs by means of inheritance as more complex scheduler LFBs by means of "inheritance" as described in
described in [RFC5812]. [RFC5812].
Packets of any arbitrary frame type are received via a group input Packets of any arbitrary frame type are received via a group input
known as "PktsIn" with no additional metadata expected. This group known as "PktsIn" with no additional metadata expected. This group
input is capable of multiple input port instances. Each port input is capable of multiple input port instances. Each port
instance may be connected to different upstream LFB output. Inside instance may be connected to different upstream LFB output. Inside
the LFB, it is abstracted that each input port instance is connected 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 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 exactly the same as the index of corresponding group input port
instance. Scheduling disciplines are applied to all queues and also instance. Scheduling disciplines are applied to all queues and also
all packets in the queues.The group input port property all packets in the queues.The group input port property
skipping to change at page 71, line 7 skipping to change at page 71, line 7
o The queue length limit providing the storage ability for every o The queue length limit providing the storage ability for every
queue. queue.
5.5.2.4. Events 5.5.2.4. Events
This LFB does not have any events specified. This LFB does not have any events specified.
6. XML for LFB Library 6. XML for LFB Library
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0" <LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
provides="BaseLFBLibrary"> provides="BaseLFBLibrary">
<load library="BaseTypeLibrary"/> <load library="BaseTypeLibrary"/>
<LFBClassDefs> <LFBClassDefs>
<LFBClassDef LFBClassID="3"> <LFBClassDef LFBClassID="3">
<name>EtherPHYCop</name> <name>EtherPHYCop</name>
<synopsis> <synopsis>
The EtherPHYCop LFB describes an Ethernet interface The EtherPHYCop LFB describes an Ethernet interface
abstracted at physical layer. It limits the physical media which limits the physical media to copper.
to copper. </synopsis>
</synopsis> <version>1.0</version>
<version>1.0</version> <inputPorts>
<inputPorts> <inputPort>
<inputPort> <name>EtherPHYIn</name>
<name>EtherPHYIn</name> <synopsis>
<synopsis> The input port of the EtherPHYCop LFB. It expects any
The input port of the EtherPHYCop LFB. It expects any type of Ethernet frame.
type of Ethernet frame. </synopsis>
</synopsis> <expectation>
<expectation> <frameExpected>
<frameExpected> <ref>EthernetAll</ref>
<ref>EthernetAll</ref> </frameExpected>
</frameExpected> </expectation>
</expectation> </inputPort>
</inputPort> </inputPorts>
</inputPorts> <outputPorts>
<outputPorts> <outputPort>
<outputPort> <name>EtherPHYOut</name>
<name>EtherPHYOut</name> <synopsis>
<synopsis> The output port of the EtherPHYCop LFB. The output
The output port of the EtherPHYCop LFB. The output packet has the same Ethernet frame type with the
packet has the same Ethernet frame type with the input packet, associated with a metadata indicating
input packet, associated with a metadata indicating the ID of the physical port.
the ID of the physical port. </synopsis>
</synopsis> <product>
<product> <frameProduced>
<frameProduced> <ref>EthernetAll</ref>
<ref>EthernetAll</ref> </frameProduced>
</frameProduced> <metadataProduced>
<metadataProduced> <ref>PHYPortID</ref>
<ref>PHYPortID</ref> </metadataProduced>
</metadataProduced> </product>
</product> </outputPort>
</outputPort> </outputPorts>
</outputPorts> <components>
<components> <component componentID="1" access="read-only">
<component componentID="1" access="read-only"> <name>PHYPortID</name>
<name>PHYPortID</name> <synopsis>
<synopsis> The identification of the physical port
The identification of the physical port </synopsis>
</synopsis> <typeRef>uint32</typeRef>
<typeRef>uint32</typeRef> </component>
</component> <component componentID="2" access="read-write">
<component componentID="2" access="read-write"> <name>AdminStatus</name>
<name>AdminStatus</name> <synopsis>
<synopsis> The port status administratively requested
The port status administratively requested </synopsis>
</synopsis> <typeRef>PortStatusType</typeRef>
<typeRef>PortStatusType</typeRef> <defaultValue>2</defaultValue>
<defaultValue>2</defaultValue> </component>
</component> <component componentID="3" access="read-only">
<component componentID="3" access="read-only"> <name>OperStatus</name>
<name>OperStatus</name> <synopsis>
<synopsis> The port actual operational status
The actual operational status of the port </synopsis>
</synopsis> <typeRef>PortStatusType</typeRef>
<typeRef>PortStatusType</typeRef> </component>
</component> <component componentID="4" access="read-write">
<component componentID="4" access="read-write"> <name>AdminLinkSpeed</name>
<name>AdminLinkSpeed</name> <synopsis>
<synopsis> The port link speed administratively requested
The port link speed administratively requested </synopsis>
</synopsis> <typeRef>LANSpeedType</typeRef>
<typeRef>LANSpeedType</typeRef> <defaultValue>LAN_SPEED_AUTO</defaultValue>
<defaultValue>LAN_SPEED_AUTO</defaultValue> </component>
</component> <component componentID="5" access="read-only">
<component componentID="5" access="read-only"> <name>OperLinkSpeed</name>
<name>OperLinkSpeed</name> <synopsis>
<synopsis> The port actual operational link speed
The actual operational link speed of the port </synopsis>
</synopsis> <typeRef>LANSpeedType</typeRef>
<typeRef>LANSpeedType</typeRef> </component>
</component> <component componentID="6" access="read-write">
<component componentID="6" access="read-write"> <name>AdminDuplexMode</name>
<name>AdminDuplexMode</name> <synopsis>
<synopsis> The port duplex mode administratively requested
The port duplex mode administratively requested </synopsis>
</synopsis> <typeRef>DuplexType</typeRef>
<typeRef>DuplexType</typeRef> <defaultValue>Auto</defaultValue>
<defaultValue>Auto</defaultValue> </component>
</component> <component componentID="7" access="read-only">
<component componentID="7" access="read-only"> <name>OperDuplexMode</name>
<name>OperDuplexMode</name> <synopsis>
<synopsis> The port actual operational duplex mode
The actual operational duplex mode of the port </synopsis>
</synopsis> <typeRef>DuplexType</typeRef>
<typeRef>DuplexType</typeRef> </component>
</component> <component componentID="8" access="read-only">
<component componentID="8" access="read-only"> <name>CarrierStatus</name>
<name>CarrierStatus</name> <synopsis>The carrier status of the port </synopsis>
<synopsis>The carrier status of the port </synopsis> <typeRef>boolean</typeRef>
<typeRef>boolean</typeRef> <defaultValue>false</defaultValue>
<defaultValue>false</defaultValue> </component>
</component> </components>
</components> <capabilities>
<capabilities> <capability componentID="30">
<capability componentID="30"> <name>SupportedLinkSpeed</name>
<name>SupportedLinkSpeed</name> <synopsis>
<synopsis> A list of link speeds the port supports
A list of link speeds the port supports </synopsis>
</synopsis> <array>
<array> <typeRef>LANSpeedType</typeRef>
<typeRef>LANSpeedType</typeRef> </array>
</array> </capability>
</capability> <capability componentID="31">
<capability componentID="31"> <name>SupportedDuplexMode</name>
<name>SupportedDuplexMode</name> <synopsis>
<synopsis> A list of duplex modes the port supports
A list of duplex modes the port supports </synopsis>
</synopsis> <array>
<array> <typeRef>DuplexType</typeRef>
<typeRef>DuplexType</typeRef> </array>
</array> </capability>
</capability> </capabilities>
</capabilities> <events baseID="60">
<events baseID="60"> <event eventID="1">
<event eventID="1"> <name>PHYPortStatusChanged</name>
<name>PHYPortStatusChanged</name> <synopsis>
<synopsis> An event reporting change on operational status of the
An event reports change on operational status of the physical port.
physical port. </synopsis>
</synopsis> <eventTarget>
<eventTarget> <eventField>OperStatus</eventField>
<eventField>OperStatus</eventField> </eventTarget>
</eventTarget> <eventChanged/>
<eventChanged/> <eventReports>
<eventReports> <eventReport>
<eventReport> <eventField>OperStatus</eventField>
<eventField>OperStatus</eventField> </eventReport>
</eventReport> </eventReports>
</eventReports> </event>
</event> <event eventID="2">
<event eventID="2"> <name>LinkSpeedChanged</name>
<name>LinkSpeedChanged</name> <synopsis>
<synopsis> An event reporting change on operational link speed
An event reports change on operational link speed of of the physical port.
the physical port. </synopsis>
</synopsis> <eventTarget>
<eventTarget> <eventField>OperLinkSpeed</eventField>
<eventField>OperLinkSpeed</eventField> </eventTarget>
</eventTarget> <eventChanged/>
<eventChanged/> <eventReports>
<eventReports> <eventReport>
<eventReport> <eventField>OperLinkSpeed</eventField>
<eventField>OperLinkSpeed</eventField> </eventReport>
</eventReport> </eventReports>
</eventReports> </event>
</event> <event eventID="3">
<event eventID="3"> <name>DuplexModeChanged</name>
<name>DuplexModeChanged</name> <synopsis>
<synopsis> An event reporting change on operational duplex mode
An event reports change on operational duplex mode of of the physical port.
the physical port. </synopsis>
</synopsis> <eventTarget>
<eventTarget> <eventField>OperDuplexMode</eventField>
<eventField>OperDuplexMode</eventField> </eventTarget>
</eventTarget> <eventChanged/>
<eventChanged/> <eventReports>
<eventReports> <eventReport>
<eventReport> <eventField>OperDuplexMode</eventField>
<eventField>OperDuplexMode</eventField> </eventReport>
</eventReport> </eventReports>
</eventReports> </event>
</event> </events>
</events> </LFBClassDef>
</LFBClassDef> <LFBClassDef LFBClassID="4">
<LFBClassDef LFBClassID="4"> <name>EtherMACIn</name>
<name>EtherMACIn</name> <synopsis>
<synopsis> EtherMACIn LFB describes an Ethernet port at MAC data link
EtherMACIn LFB abstracts an Ethernet port at MAC data link layer. The LFB describes Ethernet processing functions
layer. This LFB describes Ethernet processing functions of MAC address locality check, deciding if the Ethernet
like MAC address locality check, deciding if the Ethernet packets should be bridged, providing Ethernet layer flow
packets should be bridged, providing Ethernet layer flow control, etc.
control, etc. </synopsis>
</synopsis> <version>1.0</version>
<version>1.0</version> <inputPorts>
<inputPorts> <inputPort group="false">
<inputPort group="false"> <name>EtherPktsIn</name>
<name>EtherPktsIn</name> <synopsis>
<synopsis> The input port of the EtherMACIn LFB. It expects any
The input port of the EtherMACIn LFB. It expects any type of Ethernet frame.
type of Ethernet frame. </synopsis>
</synopsis> <expectation>
<expectation> <frameExpected>
<frameExpected> <ref>EthernetAll</ref>
<ref>EthernetAll</ref> </frameExpected>
</frameExpected> <metadataExpected>
<metadataExpected> <ref>PHYPortID</ref>
<ref>PHYPortID</ref> </metadataExpected>
</metadataExpected> </expectation>
</expectation> </inputPort>
</inputPort> </inputPorts>
</inputPorts> <outputPorts>
<outputPorts> <outputPort group="false">
<outputPort group="false"> <name>NormalPathOut</name>
<name>NormalPathOut</name> <synopsis>
<synopsis> An output port in the EtherMACIn LFB. It outputs
An output port called normal path output in the Ethernet packets to downstream LFBs for normal
EtherMACIn LFB. It outputs Ethernet packets to processing like Ethernet packet classification and
downstream LFBs for normal processing like Ethernet other L3 IP layer processing.
packet classification and further L3 processing. </synopsis>
</synopsis> <product>
<product> <frameProduced>
<frameProduced> <ref>EthernetAll</ref>
<ref>EthernetAll</ref> </frameProduced>
</frameProduced> <metadataProduced>
<metadataProduced> <ref>PHYPortID</ref>
<ref>PHYPortID</ref> </metadataProduced>
</metadataProduced> </product>
</product> </outputPort>
</outputPort> <outputPort>
<outputPort> <name>L2BridgingPathOut</name>
<name>L2BridgingPathOut</name> <synopsis>
<synopsis> An output port in
An output port called L2 bridging path output in the EtherMACIn LFB. It outputs Ethernet packets
the EtherMACIn LFB. It outputs Ethernet packets to downstream LFBs for layer 2 bridging processing.
to downstream LFBs for layer 2 bridging processing. The port is switched on or off by the
The port is switched on or off by the L2BridgingPathEnable flag in the LFB.
L2BridgingPathEnable flag. </synopsis>
</synopsis> <product>
<product> <frameProduced>
<frameProduced> <ref>EthernetAll</ref>
<ref>EthernetAll</ref> </frameProduced>
</frameProduced> <metadataProduced>
<metadataProduced> <ref>PHYPortID</ref>
<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 addresses 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.
</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 abstracts the process to decapsulate
Ethernet packets and then classifies 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. A PHYPortID metadata
is associated and a LogicalPortID metadata is
optionally associated with every 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 single 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 is defined in
the LFB to dispatch every Ethernet packet to output
group according to logical port ID assigned by the
VlanInputTable 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 is defined in the
LFB to classify VLAN Ethernet packets. Every input
packet is assigned with a new LogicalPortID according
to the packet incoming port ID and the VLAN ID.
</synopsis>
<typeRef>VlanInputTableType</typeRef>
</component>
<component access="read-reset" componentID="3">
<name>EtherClassifyStats</name>
<synopsis>
A table records statistics on the Ethernet
classifying process in the LFB.
</synopsis>
<optional/>
<typeRef>EtherClassifyStatsTableType</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="6">
<name>EtherEncap</name>
<synopsis>
This 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>
A port inputs 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>
Output port for packets which have found Ethernet L2
information and have been successfully encapsulated
into an Ethernet packet. An L2portID metadata is
produced for every 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>
Output port for all 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> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
</outputPorts> </outputPorts>
<components> <components>
<component componentID="1" access="read-write"> <component componentID="1" access="read-write">
<name>EncapTable</name> <name>AdminStatus</name>
<synopsis> <synopsis>
An array 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.Ethernet output
functions are closely related to Ethernet input functions,
therefore some components defined in this LFB are as alias
of EtherMACIn LFB.
</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 physical port ID 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 LFB status administratively requested, which has
the same data type with a port status. It is defined the same data type with a port status. Default is in
as alias of AdminStatus component in EtherMACIn LFB. 'down' status.
</synopsis> </synopsis>
<alias>PortStatusType</alias> <typeRef>PortStatusType</typeRef>
</component> <defaultValue>2</defaultValue>
<component componentID="2" access="read-write"> </component>
<name>MTU</name> <component componentID="2" access="read-write">
<synopsis>Maximum transmission unit (MTU) </synopsis> <name>LocalMACAddresses</name>
<typeRef>uint32</typeRef> <synopsis>
</component> Local MAC address(es) of the Ethernet port the LFB
<component componentID="3" access="read-write"> represents.
<name>TxFlowControl</name> </synopsis>
<synopsis> <array>
A flag indicating whether transmit flow control is <typeRef>IEEEMAC</typeRef>
applied, defined as alias of TxFlowControl component </array>
in EtherMACIn LFB. </component>
</synopsis> <component componentID="3" access="read-write">
<optional/> <name>L2BridgingPathEnable</name>
<alias>boolean</alias> <synopsis>
</component> A flag indicating if the LFB L2 BridgingPath output
<component componentID="4" access="read-write"> port is enabled or not. Default is not enabled.
<name>RxFlowControl</name> </synopsis>
<synopsis> <typeRef>boolean</typeRef>
A flag indicating whether receive flow control is <defaultValue>false</defaultValue>
applied, defined as alias of RxFlowControl component </component>
in EtherMACIn LFB. <component componentID="4" access="read-write">
</synopsis> <name>PromiscuousMode</name>
<optional/> <synopsis>
<alias>boolean</alias> A flag indicating whether the LFB is in promiscuous
</component> mode or not. Default is not.
<component componentID="5" access="read-reset"> </synopsis>
<name>MACOutStats</name> <typeRef>boolean</typeRef>
<synopsis> <defaultValue>false</defaultValue>
The statistics of the EtherMACOut LFB </component>
</synopsis> <component componentID="5" access="read-write">
<optional/> <name>TxFlowControl</name>
<typeRef>MACOutStatsType</typeRef> <synopsis>
</component> A flag indicating whether transmit flow control is
</components> applied or not. Default is not.
</LFBClassDef>
<LFBClassDef LFBClassID="8">
<name>IPv4Validator</name>
<synopsis>
The IPv4Validator LFB performs IPv4 validation according to
[RFC5812]. The IPv4 packet will be output to the
corresponding port regarding of the validation result,
whether the packet is unicast, multicast or whether an
exception has occurred or the validation failed.
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>ValidatePktsIn</name>
<synopsis>
Input port for data packets to be validated
</synopsis>
<expectation>
<frameExpected>
<ref>Arbitrary</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort>
<name>IPv4UnicastOut</name>
<synopsis>
Output port for validated IPv4 unicast packets
</synopsis>
<product>
<frameProduced>
<ref>IPv4Unicast</ref>
</frameProduced>
</product>
</outputPort>
<outputPort>
<name>IPv4MulticastOut</name>
<synopsis>
Output port for validated IPv4 multicast packets
</synopsis>
<product>
<frameProduced>
<ref>IPv4Multicast</ref>
</frameProduced>
</product>
</outputPort>
<outputPort>
<name>ExceptionOut</name>
<synopsis>
Output port for all packets with exceptional cases
when validating. An ExceptionID metadata indicates
the exception case type.
</synopsis>
<product>
<frameProduced>
<ref>IPv4</ref>
</frameProduced>
<metadataProduced>
<ref>ExceptionID</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort>
<name>FailOut</name>
<synopsis>
Output port for packets 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>
The IPv6Validator LFB performs IPv6 validation according to
[RFC2460]. The IPv6 packet will be output to the
corresponding port regarding of the validation result,
whether the packet is a unicast or a multicast one, an
exception has occurred or the validation failed.
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>ValidatePktsIn</name>
<synopsis>
Input port for data packets to be validated
</synopsis>
<expectation>
<frameExpected>
<ref>Arbitrary</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort>
<name>IPv6UnicastOut</name>
<synopsis>
Output port for validated IPv6 unicast packets
</synopsis>
<product>
<frameProduced>
<ref>IPv6Unicast</ref>
</frameProduced>
</product>
</outputPort>
<outputPort>
<name>IPv6MulticastOut</name>
<synopsis>
Output port for validated IPv6 multicast packets
</synopsis>
<product>
<frameProduced>
<ref>IPv6Multicast</ref>
</frameProduced>
</product>
</outputPort>
<outputPort>
<name>ExceptionOut</name>
<synopsis>
Output port for packets with exceptional cases when
validating. An ExceptionID metadata indicates the
exception case type.
</synopsis>
<product>
<frameProduced>
<ref>IPv6</ref>
</frameProduced>
<metadataProduced>
<ref>ExceptionID</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort>
<name>FailOut</name>
<synopsis>
Output port for packets failed validating process.
A ValidateErrorID metadata indicates the error type
or failure reason.
</synopsis>
<product>
<frameProduced>
<ref>IPv6</ref>
</frameProduced>
<metadataProduced>
<ref>ValidateErrorID</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component access="read-write" componentID="1">
<name>IPv6ValidatorStats</name>
<synopsis>
The statistics information for validating process in
the LFB.
</synopsis>
<optional/>
<typeRef>IPv6ValidatorStatsType</typeRef>
</component> </synopsis>
</components> <optional/>
</LFBClassDef> <typeRef>boolean</typeRef>
<LFBClassDef LFBClassID="10"> <defaultValue>false</defaultValue>
<name>IPv4UcastLPM</name> </component>
<synopsis> <component componentID="6" access="read-write">
The IPv4UcastLPM LFB abstracts the IPv4 unicast Longest <name>RxFlowControl</name>
Prefix Match (LPM) process. This LFB also provides <synopsis>
facilities to support users to implement equal-cost A flag indicating whether receive flow control is
multi-path routing (ECMP) or reverse path forwarding (RPF). applied or not. Default is not.
However, this LFB itself does not provide ECMP or RPF. </synopsis>
</synopsis> <optional/>
<version>1.0</version> <typeRef>boolean</typeRef>
<inputPorts> <defaultValue>false</defaultValue>
<inputPort group="false"> </component>
<name>PktsIn</name> <component componentID="7" access="read-reset">
<synopsis> <name>MACInStats</name>
A port for input of packets to be processed. IPv4 <synopsis>
unicast packets are expected. The statistics of the EtherMACIn LFB
</synopsis> </synopsis>
<expectation> <optional/>
<frameExpected> <typeRef>MACInStatsType</typeRef>
<ref>IPv4Unicast</ref> </component>
</frameExpected> </components>
</expectation> </LFBClassDef>
</inputPort> <LFBClassDef LFBClassID="5">
</inputPorts> <name>EtherClassifier</name>
<outputPorts> <synopsis>
<outputPort group="false"> EtherClassifier LFB describes the process to decapsulate
<name>NormalOut</name> Ethernet packets and then classify them into various
<synopsis> network layer packets according to information in the
A normal output port outputs IPv4 unicast packets Ethernet headers. It is expected the LFB classifies packets
that succeed the LPM lookup. A HopSelector metadata by packet types like IPv4, IPv6, MPLS, ARP, ND, etc.
is produced for every packet for downstream LFB to </synopsis>
do next hop action. <version>1.0</version>
</synopsis> <inputPorts>
<product> <inputPort>
<frameProduced> <name>EtherPktsIn</name>
<ref>IPv4Unicast</ref> <synopsis>
</frameProduced> Input port of Ethernet packets. PHYPortID metadata is
<metadataProduced> always expected while LogicalPortID metadata is
<ref>HopSelector</ref> optionally expected to associate with every input
</metadataProduced> Ethernet packet.
</product> </synopsis>
</outputPort> <expectation>
<outputPort group="false"> <frameExpected>
<name>ECMPOut</name> <ref>EthernetAll</ref>
<synopsis> </frameExpected>
The port outputs packets that need further ECMP <metadataExpected>
processing. An ECMP processing LFB is usually <ref>PHYPortID</ref>
followed the output. If ECMP is not required, no <ref dependency="optional" defaultValue="0">
downstream LFB may be connected to the port. LogicalPortID</ref>
</synopsis> </metadataExpected>
<product> </expectation>
<frameProduced> </inputPort>
<ref>IPv4Unicast</ref> </inputPorts>
</frameProduced> <outputPorts>
<metadataProduced> <outputPort group="true">
<ref>HopSelector</ref> <name>ClassifyOut</name>
</metadataProduced> <synopsis>
</product> A group port for output of Ethernet classifying
</outputPort> results.
<outputPort group="false"> </synopsis>
<name>ExceptionOut</name> <product>
<synopsis> <frameProduced>
The port outputs all packets with exceptional cases <ref>Arbitrary</ref>
when doing LPM process. An ExceptionID metadata </frameProduced>
associated indicates what caused the exception. <metadataProduced>
</synopsis> <ref>PHYPortID</ref>
<product> <ref>SrcMAC</ref>
<frameProduced> <ref>DstMAC</ref>
<ref>IPv4Unicast</ref> <ref>EtherType</ref>
</frameProduced> <ref availability="conditional">VlanID</ref>
<metadataProduced> <ref availability="conditional">VlanPriority</ref>
<ref>ExceptionID</ref> </metadataProduced>
</metadataProduced> </product>
</product> </outputPort>
</outputPort> <outputPort group="false">
</outputPorts> <name>ExceptionOut</name>
<components> <synopsis>
<component componentID="1" access="read-write"> A singleton port for output of all Ethernet packets
<name>IPv4PrefixTable</name> that fail the classifying process. An ExceptionID
<synopsis> metadata indicates the failure reason.
A table for IPv4 longest prefix match. The </synopsis>
destination IPv4 address of every input packet is <product>
used as a search key to look up the table to find <frameProduced>
out a next hop selector. <ref>Arbitrary</ref>
</synopsis> </frameProduced>
<typeRef>IPv4PrefixTableType</typeRef> <metadataProduced>
</component> <ref>ExceptionID</ref>
<component componentID="2" access="read-reset"> </metadataProduced>
<name>IPv4UcastLPMStats</name> </product>
<synopsis> </outputPort>
The statistics information for IPv4 unicast longest </outputPorts>
prefix match process in the LFB. <components>
</synopsis> <component access="read-write" componentID="1">
<optional/> <name>EtherDispatchTable</name>
<typeRef>IPv4UcastLPMStatsType</typeRef> <synopsis>
</component> An EtherDispatchTable array component which is defined
</components> in the LFB to dispatch every Ethernet packet to output
</LFBClassDef> ports according to logical port ID assigned by the
<LFBClassDef LFBClassID="11"> VlanInputTable in the LFB and Ethernet type in the
<name>IPv6UcastLPM</name> Ethernet packet header.
<synopsis> </synopsis>
The IPv6UcastLPM LFB abstracts the IPv6 unicast Longest <typeRef>EtherDispatchTableType</typeRef>
Prefix Match (LPM) process. This LFB also provides </component>
facilities to support users to implement equal-cost <component access="read-write" componentID="2">
multi-path routing (ECMP) or reverse path forwarding (RPF). <name>VlanInputTable</name>
However, this LFB itself does not provide ECMP or RPF. <synopsis>
</synopsis> A VlanInputTable array component which is defined in
<version>1.0</version> the LFB to classify VLAN Ethernet packets. Every input
<inputPorts> packet is assigned with a new LogicalPortID according
<inputPort group="false"> to the packet incoming port ID and VLAN ID.
<name>PktsIn</name> </synopsis>
<synopsis> <typeRef>VlanInputTableType</typeRef>
A port for input of packets to be processed. IPv6 </component>
unicast packets are expected. <component access="read-reset" componentID="3">
</synopsis> <name>EtherClassifyStats</name>
<expectation> <synopsis>
<frameExpected> A table recording statistics on the Ethernet
<ref>IPv6Unicast</ref> classifying process in the LFB.
</frameExpected> </synopsis>
</expectation> <optional/>
</inputPort> <typeRef>EtherClassifyStatsTableType</typeRef>
</inputPorts> </component>
<outputPorts> </components>
<outputPort group="false">
<name>NormalOut</name>
<synopsis>
A normal output port outputs IPv6 unicast packets
that succeed the LPM lookup. A HopSelector metadata
is produced for every 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 outputs packets that need further ECMP
processing. An ECMP processing LFB is usually
followed the output. 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 outputs all packets with exceptional cases
when doing LPM process. An ExceptionID metadata
associated indicates 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. 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 IPv6 unicast longest
prefix match process in the LFB.
</synopsis>
<optional/>
<typeRef>IPv6UcastLPMStatsType</typeRef>
</component>
</components>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="12"> <LFBClassDef LFBClassID="6">
<name>IPv4NextHop</name> <name>EtherEncap</name>
<synopsis> <synopsis>
The LFB abstracts the process of next hop information The EtherEncap LFB abstracts the process of encapsulating
application to IPv4 packets. It receives an IPv4 packet Ethernet headers onto received packets. The encapsulation
with an associated next hop identifier (HopSelector), and is based on passed metadata.
uses the identifier as a table index to look up a next hop </synopsis>
table to find an appropriate LFB output port. The data <version>1.0</version>
processing also involves the forwarding TTL decrement and <inputPorts>
IP checksum recalculation. <inputPort group="false">
</synopsis> <name>EncapIn</name>
<version>1.0</version> <synopsis>
<inputPorts> A input port receiving IPv4 and/or IPv6 packets for
<inputPort group="false"> encapsulation. A MediaEncapInfoIndex metadata is
<name>PktsIn</name> expected and a VLAN priority metadata is optionally
<synopsis> expected with every input packet.
A port for input of unicast IPv4 packets, along with </synopsis>
a HopSelector metadata which is used as a table index <expectation>
to lookup the next hop table in the LFB. <frameExpected>
</synopsis> <ref>IPv4</ref>
<expectation> <ref>IPv6</ref>
<frameExpected> </frameExpected>
<ref>IPv4Unicast</ref> <metadataExpected>
</frameExpected> <ref>MediaEncapInfoIndex</ref>
<metadataExpected> <ref dependency="optional" defaultValue="0">
<ref>HopSelector</ref> VlanPriority</ref>
</metadataExpected> </metadataExpected>
</expectation> </expectation>
</inputPort> </inputPort>
</inputPorts> </inputPorts>
<outputPorts> <outputPorts>
<outputPort group="true"> <outputPort group="false">
<name>SuccessOut</name> <name>SuccessOut</name>
<synopsis> <synopsis>
The group output port for packets successfully found An output port for packets which have found Ethernet
next hop information. The group output port index for L2 information and have been successfully encapsulated
every packet is decided by the LFBOutputSelectIndex into an Ethernet packet. A L2portID metadata is
value assigned in the next hop table entry. The produced for every output packet.
packet is sent to a downstream LFB along with an </synopsis>
L3PortID, a NextHopIPv4Addr, and optionally a <product>
MediaEncapInfoIndex metadata. <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>
</synopsis> </metadataProduced>
<product> </product>
<frameProduced> </outputPort>
<ref>IPv4Unicast</ref> </outputPorts>
</frameProduced> <components>
<metadataProduced> <component componentID="1" access="read-write">
<ref>L3PortID</ref> <name>EncapTable</name>
<ref>NextHopIPv4Addr</ref> <synopsis>
<ref availability="conditional"> An array table for Ethernet encapsulation information
MediaEncapInfoIndex</ref> lookup. Each row of the array contains destination MAC
</metadataProduced> address, source MAC address, VLAN ID, and output
</product> logical L2 port ID.
</outputPort> </synopsis>
<outputPort group="false"> <typeRef>EncapTableType</typeRef>
<name>ExceptionOut</name> </component>
<synopsis> </components>
The output port for packets with exceptional or </LFBClassDef>
failure cases when doing next hop action. An <LFBClassDef LFBClassID="7">
ExceptionID metadata indicates what caused the case. <name>EtherMACOut</name>
</synopsis> <synopsis>
<product> EtherMACOut LFB abstracts an Ethernet port at MAC data link
<frameProduced> layer. It specifically describes Ethernet packet process
<ref>IPv4Unicast</ref> for output to physical port. A downstream LFB is usually an
</frameProduced> Ethernet physical LFB like EtherPHYcop LFB. Note that
<metadataProduced> Ethernet output functions are closely related to Ethernet
<ref>ExceptionID</ref> input functions, therefore some components defined in this
</metadataProduced> LFB are as alias of EtherMACIn LFB.
</product> </synopsis>
</outputPort> <version>1.0</version>
</outputPorts> <inputPorts>
<components> <inputPort group="false">
<component componentID="1"> <name>EtherPktsIn</name>
<name>IPv4NextHopTable</name> <synopsis>
<synopsis> The input port of the EtherMACOut LFB. It expects any
The IPv4NextHopTable is defined as an array. A type of Ethernet frame.
HopSelector is used to match the array index of the </synopsis>
table to find out a row of the table as the next hop <expectation>
information result. Each row of the array is a struct <frameExpected>
containing the L3PortID, MTU, NextHopIPAddr(IPv4 <ref>EthernetAll</ref>
type), MediaEncapInfoIndex, and LFBOutputSelectIndex. </frameExpected>
</synopsis> <metadataExpected>
<typeRef>IPv4NextHopTableType</typeRef> <ref>PHYPortID</ref>
</component> </metadataExpected>
</components> </expectation>
</LFBClassDef> </inputPort>
<LFBClassDef LFBClassID="13"> </inputPorts>
<name>IPv6NextHop</name> <outputPorts>
<synopsis> <outputPort group="false">
The LFB abstracts the process of next hop information <name>EtherPktsOut</name>
application to IPv6 packets. It receives an IPv6 packet <synopsis>
with an associated next hop identifier (HopSelector), and A port to output all Ethernet packets, each with a
uses the identifier as a table index to look up a next hop metadata indicating the physical port ID the packet
table to find an appropriate LFB output port. is to go.
</synopsis> </synopsis>
<version>1.0</version> <product>
<inputPorts> <frameProduced>
<inputPort group="false"> <ref>EthernetAll</ref>
<name>PktsIn</name> </frameProduced>
<synopsis> <metadataProduced>
A port for input of unicast IPv6 packets, along with <ref>PHYPortID</ref>
a HopSelector metadata which is used as a table index </metadataProduced>
to lookup the next hop table in the LFB. </product>
</synopsis> </outputPort>
<expectation> </outputPorts>
<frameExpected> <components>
<ref>IPv6Unicast</ref> <component componentID="1" access="read-write">
</frameExpected> <name>AdminStatus</name>
<metadataExpected> <synopsis>
<ref>HopSelector</ref> The LFB status administratively requested, which has
</metadataExpected> the same data type with a port status. The component
</expectation> is defined as alias of AdminStatus component in
</inputPort> EtherMACIn LFB.
</inputPorts> </synopsis>
<outputPorts> <alias>PortStatusType</alias>
<outputPort group="true"> </component>
<name>SuccessOut</name> <component componentID="2" access="read-write">
<synopsis> <name>MTU</name>
The group output port for packets successfully found <synopsis>Maximum transmission unit (MTU) </synopsis>
next hop information. The group output port index for <typeRef>uint32</typeRef>
every packet is decided by the LFBOutputSelectIndex </component>
value assigned in the next hop table entry. The <component componentID="3" access="read-write">
packet is sent to a downstream LFB along with an <name>TxFlowControl</name>
L3PortID, a NextHopIPv6Addr, and optionally a <synopsis>
MediaEncapInfoIndex metadata. A flag indicating whether transmit flow control is
</synopsis> applied, defined as alias of TxFlowControl component
<product> in EtherMACIn LFB.
<frameProduced> </synopsis>
<ref>IPv6Unicast</ref> <optional/>
</frameProduced> <alias>boolean</alias>
<metadataProduced> </component>
<ref>L3PortID</ref> <component componentID="4" access="read-write">
<ref>NextHopIPv6Addr</ref> <name>RxFlowControl</name>
<ref availability="conditional"> <synopsis>
MediaEncapInfoIndex</ref> A flag indicating whether receive flow control is
</metadataProduced> applied, defined as alias of RxFlowControl component
</product> in EtherMACIn LFB.
</outputPort> </synopsis>
<outputPort group="false"> <optional/>
<name>ExceptionOut</name> <alias>boolean</alias>
<synopsis> </component>
The output port for packets with exceptional or <component componentID="5" access="read-reset">
failure cases when doing next hop action. An <name>MACOutStats</name>
ExceptionID metadata indicates what caused the case. <synopsis>
</synopsis> The statistics of the EtherMACOut LFB
<product> </synopsis>
<frameProduced> <optional/>
<ref>IPv6Unicast</ref> <typeRef>MACOutStatsType</typeRef>
</frameProduced> </component>
<metadataProduced> </components>
<ref>ExceptionID</ref> </LFBClassDef>
</metadataProduced> <LFBClassDef LFBClassID="8">
</product> <name>IPv4Validator</name>
</outputPort> <synopsis>
</outputPorts> This LFB performs IPv4 validation according to RFC1812 and
<components> its updates. The IPv4 packet will be output to the
<component componentID="1"> corresponding LFB port, indicating whether the packet is
<name>IPv6NextHopTable</name> unicast, multicast or whether an exception has occurred or
<synopsis> the validation failed.
The IPv6NextHopTable is defined as an array. A </synopsis>
HopSelector is used to match the array index of the <version>1.0</version>
table to find out a row of the table as the next hop <inputPorts>
information result. Each row of the array is a struct <inputPort>
containing the L3PortID, MTU, NextHopIPAddr(IPv6 <name>ValidatePktsIn</name>
type), MediaEncapInfoIndex, and LFBOutputSelectIndex. <synopsis>
</synopsis> Input port for data packets to be validated
<typeRef>IPv6NextHopTableType</typeRef> </synopsis>
</component> <expectation>
</components> <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 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>
<LFBClassDef LFBClassID="14"> <LFBClassDef LFBClassID="9">
<name>RedirectIn</name> <name>IPv6Validator</name>
<synopsis> <synopsis>
A RedirectIn LFB abstracts the process for the ForCES CE to This LFB performs IPv6 validation according to RFC2460 and
inject data packets into the ForCES FE LFB topology so as to its updates. Then the IPv6 packet will be output to the
input data packets into FE data paths. corresponding port, indicating whether the packet is a
</synopsis> unicast or a multicast one, an exception has occurred or
<version>1.0</version> the validation failed.
<outputPorts> </synopsis>
<outputPort group="true"> <version>1.0</version>
<name>PktsOut</name> <inputPorts>
<synopsis> <inputPort>
The output port of RedirectIn LFB is defined as a <name>ValidatePktsIn</name>
group output type. Packets produced by this output <synopsis>
will have arbitrary frame types decided by the CE Input port for data packets to be validated
which generated the packets. From LFB topology point </synopsis>
of view, the RedirectIn LFB acts as a source point <expectation>
for data packets coming from CE, therefore RedirectIn <frameExpected>
LFB is defined with a single output LFB port (and no <ref>Arbitrary</ref>
input LFB port). The CE may associate some metadata </frameExpected>
to indicate the frame types and may also associate </expectation>
other metadata to indicate information on the packets. </inputPort>
Among them, there must exist a 'RedirectIndex' </inputPorts>
metadata, which is an integer acting as an index. When <outputPorts>
the CE transmits the metadata along with the packet to <outputPort>
a RedirectIn LFB, the LFB will read the RedirectIndex <name>IPv6UnicastOut</name>
metadata and output the packet to one of its group <synopsis>
output port instance, whose port index is indicated Output port for validated IPv6 unicast packets
by this metadata. Any other metadata, in addition to </synopsis>
'RedirectIndex', will be passed untouched along the <product>
packet delivered by the CE to downstream LFB. This <frameProduced>
means the 'RedirectIndex' metadata from CE will be <ref>IPv6Unicast</ref>
"consumed" by the RedirectIn LFB and will not be </frameProduced>
passed to downstream LFB. Note that, a packet from </product>
CE without a 'RedirectIndex' metadata associated will </outputPort>
be dropped by the LFB. <outputPort>
</synopsis> <name>IPv6MulticastOut</name>
<product> <synopsis>
<frameProduced> Output port for validated IPv6 multicast packets
<ref>Arbitrary</ref>
</frameProduced> </synopsis>
</product> <product>
</outputPort> <frameProduced>
</outputPorts> <ref>IPv6Multicast</ref>
<components> </frameProduced>
<component componentID="1"> </product>
<name>NumPacketsReceived</name> </outputPort>
<synopsis> <outputPort>
Numble of packets received from CE. A possiable <name>ExceptionOut</name>
statistical information in this LFB. <synopsis>
</synopsis> Output port for packets with exceptional cases when
<optional/> validating. An ExceptionID metadata indicates the
<typeRef>uint64</typeRef> exception case type.
</component> </synopsis>
</components> <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>
<LFBClassDef LFBClassID="15"> <LFBClassDef LFBClassID="10">
<name>RedirectOut</name> <name>IPv4UcastLPM</name>
<synopsis> <synopsis>
A RedirectOut LFB abstracts the process for LFBs in the The IPv4UcastLPM LFB abstracts the IPv4 unicast Longest
ForCES FE to deliver data packets to the ForCES CE. Prefix Match (LPM) process. This LFB supports to implement
</synopsis> equal-cost multi-path routing (ECMP) and reverse path
<version>1.0</version> forwarding (RPF).
<inputPorts> </synopsis>
<inputPort group="false"> <version>1.0</version>
<name>PktsIn</name> <inputPorts>
<synopsis> <inputPort group="false">
The input port for the RedirectOut LFB. From the LFB's <name>PktsIn</name>
topology point of view, the RedirectOut LFB acts as a <synopsis>
sink point for data packets going to the CE, therefore A port for input of packets to be processed. IPv4
RedirectOut LFB is defined with a single input LFB unicast packets are expected.
port (and no output LFB port). The port expects all </synopsis>
types of packet frames and metadata. All associated <expectation>
metadata produced (but not consumed) by previous <frameExpected>
processed LFBs should be delivered to the CE. <ref>IPv4Unicast</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort group="false">
<name>NormalOut</name>
<synopsis>
An output port to output IPv4 unicast packets
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 to implement
equal-cost multi-path routing (ECMP) 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
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),
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 who 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 case. 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 which 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),
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> </synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
<ref>Arbitrary</ref> <ref>IPv6Unicast</ref>
</frameExpected> </frameExpected>
</expectation> <metadataExpected>
</inputPort> <ref>HopSelector</ref>
</inputPorts> </metadataExpected>
<components> </expectation>
<component componentID="1"> </inputPort>
<name>NumPacketsSent</name> </inputPorts>
<synopsis> <outputPorts>
Numble of packets sent to CE. A possiable <outputPort group="true">
statistical information in this LFB. <name>SuccessOut</name>
<synopsis>
The group port for output of packets who successfully
found next hop information. Some metadata are
associated with every packet.
</synopsis> </synopsis>
<optional/> <product>
<typeRef>uint64</typeRef> <frameProduced>
</component> <ref>IPv6Unicast</ref>
</components> </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 case. 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 which
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 LFB topology 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's
topology 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>
Numble 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 be 32-bits 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 which 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 which outputs packets which 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>
<LFBClassDef LFBClassID="16"> <LFBClassDef LFBClassID="17">
<name>BasicMetadataDispatch</name> <name>GenericScheduler</name>
<synopsis> <synopsis>
The BasicMetadataDispatch LFB is defined to abstract the This is a preliminary generic scheduler LFB abstracting
process in which a packet is dispatched to some output path a simple scheduling process, which may be used as a
based on its associated metadata value. Current version of basic LFB to construct a more complex scheduler LFB.
the LFB only allows the metadata value be 32-bits integer. </synopsis>
</synopsis> <version>1.0</version>
<version>1.0</version> <inputPorts>
<inputPorts> <inputPort group="true">
<inputPort> <name>PktsIn</name>
<name>PktsIn</name> <synopsis>
<synopsis> The group input port of the LFB. Inside the LFB,
The packet input port for dispatching. Every input each instance of the group port is connected to
packet should be associated with a metadata that will a queue marked with a queue ID, whose value is
be used by the LFB to do the dispatch. index of the port instance.
</synopsis>
<expectation>
<frameExpected>
<ref>Arbitrary</ref>
</frameExpected>
</expectation>
</synopsis> </inputPort>
<expectation> </inputPorts>
<frameExpected> <outputPorts>
<ref>Arbitrary</ref> <outputPort>
</frameExpected> <name>PktsOut</name>
<metadataExpected> <synopsis>
<ref>Arbitrary</ref> The output port of the LFB. Scheduled packets are
</metadataExpected> output from the port.
</expectation> </synopsis>
</inputPort> <product>
</inputPorts> <frameProduced>
<outputPorts> <ref>Arbitrary</ref>
<outputPort group="true"> </frameProduced>
<name>PktsOut</name> </product>
<synopsis> </outputPort>
The group output port outputs dispatching results. A </outputPorts>
packet with its associated metadata having found an <components>
OutputIndex by successfully looking up the dispatch <component access="read-write" componentID="1">
table will be output to the group port instance with <name>SchedulingDiscipline</name>
the corresponding index. <synopsis>
</synopsis> The SchedulingDiscipline component, which is for the
<product> CE to specify a scheduling discipline to the LFB.
<frameProduced> </synopsis>
<ref>Arbitrary</ref> <typeRef>SchdDisciplineType</typeRef>
</frameProduced> <defaultValue>1</defaultValue>
</product> </component>
</outputPort> <component access="read-only" componentID="2">
<outputPort group="false"> <name>QueueStats</name>
<name>ExceptionOut</name> <synopsis>
<synopsis> The QueueStats component, which is defined to allow
The output port outputs packets for which the data CE to query every queue statistics in the scheduler.
processing failed, along with an additional </synopsis>
ExceptionID metadata to indicate what caused the <optional/>
exception. <typeRef>QueueStatsTableType</typeRef>
</synopsis> </component>
<product> </components>
<frameProduced> <capabilities>
<ref>Arbitrary</ref> <capability componentID="30">
</frameProduced> <name>QueueLenLimit</name>
<metadataProduced> <synopsis>
<ref>ExceptionID</ref> The QueueLenLimit capability, which specifies
</metadataProduced> maximum length of each queue. The length unit is in
</product> bytes.
</outputPort> </synopsis>
</outputPorts> <typeRef>uint32</typeRef>
<components> </capability>
<component access="read-write" componentID="1"> </capabilities>
<name>MetadataID</name> </LFBClassDef>
<synopsis>
The metadata ID specifies which metadata is to be
used for dispatching packets. It is configured by
the CE.
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component access="read-write" componentID="2">
<name>MetadataDispatchTable</name>
<synopsis>
The MetadataDispatchTable contains entries of a
Metadata value and an OutputIndex, specifying that
packet with the metadata value must go out from the
LFB group output port instance with the OutputIndex.
Note that in current version, the metadata value is
only allowed to be 32-bits integer. The metadata value
is also defined as a content key for the table.
</synopsis>
<typeRef>MetadataDispatchTableType</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="17">
<name>GenericScheduler</name>
<synopsis>
This is a preliminary generic scheduler LFB for abstracting
a simple scheduling process. Users may use this LFB as a
basic scheduler LFB to further construct more complex
scheduler LFBs by means of inheritance as described in
RFC5812.
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort group="true">
<name>PktsIn</name>
<synopsis>
A group input port. Packets of any arbitrary frame
type are received via the group input with no
additional metadata expected. 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
provides means for the CE to query the capability of
total queue numbers the scheduler supports.
</synopsis>
<expectation>
<frameExpected>
<ref>Arbitrary</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort>
<name>PktsOut</name>
<synopsis>
An output port scheduled packets are output from with
no must metadata associated.
</synopsis>
<product>
<frameProduced>
<ref>Arbitrary</ref>
</frameProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component access="read-write" componentID="1">
<name>SchedulingDiscipline</name>
<synopsis>
The SchedulingDiscipline component 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 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>
Allowed maximium length of each queue. The length
unit is in bytes.
</synopsis>
<typeRef>uint32</typeRef>
</capability>
</capabilities>
</LFBClassDef>
</LFBClassDefs>
</LFBLibrary>
</LFBClassDefs>
</LFBLibrary>
7. LFB Class Use Cases 7. LFB Class Use Cases
This section demonstrates examples on how the LFB classes defined by This section demonstrates examples on how the LFB classes defined by
the Base LFB library in Section 6 can be applied to achieve some the Base LFB library in Section 6 can be applied to achieve some
typical router functions. The functions demonstrated are: typical router functions. The functions demonstrated are:
o IPv4 forwarding o IPv4 forwarding
o ARP processing o ARP processing
skipping to change at page 101, line 26 skipping to change at page 100, line 25
established by the CE and maps to the use cases illustrated in this established by the CE and maps to the use cases illustrated in this
section. section.
The use cases demonstrated in this section are mere examples and by 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 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 functionality from LFBs; based on the capability of the FE(s), a CE
should be able to express different NE applications. should be able to express different NE applications.
7.1. IPv4 Forwarding 7.1. IPv4 Forwarding
Figure 1 (Section 3.2.3) shows a typical IPv4 forwarding processing Figure 2 shows the typical LFB processing path for an IPv4 unicast
path by use of the base LFB classes. 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 a "ExceptionOut" singleton output port, with
the group port contains various port instances according to various
classified packet types(Section 5.1.3). While in this figure, only
the IPv4 and IPv6 packet output port instances are shown for
displaying the mere IPv4 forwarding processing function.
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 EtherPHYCop LFB and is used by all the subsequent | |<---------------|Ether |<----------------------------+
downstream LFBs. An EtherMACIn LFB(Section 5.1.2), which describe | | |MACOut| |
the MAC layer processing, follows every EtherPHYCop LFB. The | | | | |
EtherMACIn LFB may do a locality check of MAC addresses if the CE |Ether| +------+ |
configures the appropriate EtherMACIn LFB component. |PHY | |
|Cop | +---+ |
|#1 | +-----+ | |----->IPv6 Packets |
| | | | | | |
| | |Ether| | | IPv4 Packets |
| |->|MACIn|-->| |-+ +----+ |
+-----+ | | | | | | |---> Multicast Packets |
+-----+ +---+ | | | +-----+ +---+ |
Ether +->| |------->| | | | |
. Classifier| | |Unicast |IPv4 | | | |
. | | |Packets |Ucast|->| |--+ |
. | +----+ |LPM | | | | |
+---+ | IPv4 +-----+ +---+ | |
+-----+ | | | Validator IPv4 | |
| | | | | NextHop| |
+-----+ |Ether| | |-+ IPv4 Packets | |
| |->|MACIn|-->| | | |
| | | | | |----->IPv6 Packets | |
|Ether| +-----+ +---+ | |
|PHY | Ether +----+ | |
|Cop | Classifier | | +-------+ | |
|#n | +------+ | | |Ether | | |
| | | | | |<--|Encap |<-+ |
| | | |<------| | | | |
| |<---------------|Ether | ...| | +-------+ |
| | |MACOut| +---| | |
| | | | | +----+ |
+-----+ +------+ | BasicMetadataDispatch |
+----------->-------------+
Figure 2: LFB use case for IPv4 forwarding
In 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 EtherPHYCop LFB and is used by all
the subsequent downstream LFBs. An EtherMACIn LFB(Section 5.1.2),
which describe 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.
Ethernet packets out of the EtherMACIn LFB are sent to an Ethernet packets out of the EtherMACIn LFB are sent to an
EtherClassifier LFB (Section 5.1.3) to be decapsulated and classified EtherClassifier LFB (Section 5.1.3) to be decapsulated and classified
into network layer types like IPv4, IPv6, ARP, etc. In the example into network layer types like IPv4, IPv6, ARP, etc. In the example
use case, every physical Ethernet interface is associated with one use case, every physical Ethernet interface is associated with one
Classifier instance; although not illustrated, it is also feasible Classifier instance; although not illustrated, it is also feasible
that all physical interfaces are associated with only one Ethernet that all physical interfaces are associated with only one Ethernet
Classifier instance. Classifier instance.
EtherClassifier uses the PHYPortID metadata, the Ethernet type of the EtherClassifier uses the PHYPortID metadata, the Ethernet type of the
skipping to change at page 102, line 33 skipping to change at page 102, line 48
EtherEncap LFB (Section 5.1.4). EtherEncap LFB (Section 5.1.4).
The EtherEncap LFB encapsulates the incoming packet into an Ethernet The EtherEncap LFB encapsulates the incoming packet into an Ethernet
frame. A BasicMetadataDispatch LFB (Section 5.5.1) follows the frame. A BasicMetadataDispatch LFB (Section 5.5.1) follows the
EtherEncap LFB. The BasicMetadataDispatch LFB is where packets are EtherEncap LFB. The BasicMetadataDispatch LFB is where packets are
finally dispatched to different output physical/logical ports based finally dispatched to different output physical/logical ports based
on the L3PortID metadata sent to the LFB. on the L3PortID metadata sent to the LFB.
7.2. ARP processing 7.2. ARP processing
Figure 2 shows the processing path for ARP protocol in the case the Figure 3 shows the processing path for ARP protocol in the case the
CE implements the ARP processing function. By no means is this the CE implements the ARP processing function. By no means is this the
only way ARP processing could be achieved; as an example ARP only way ARP processing could be achieved; as an example ARP
processing could happen at the FE - but that discussion is out of processing could happen at the FE - but that discussion is out of
scope for this use case. scope for this use case.
+---+ +---+ +---+ +---+
| | ARP packets | | | | ARP packets | |
| |-------------->---------+--->| | To CE | |-------------->---------+--->| | To CE
...-->| | . | | | ...-->| | . | | |
| | . | +---+ | | . | +---+
skipping to change at page 103, line 29 skipping to change at page 103, line 30
| | +-->| |--+ +---+ |Ether | | | +-->| |--+ +---+ |Ether |
| | | +---+ | | |--------->|MACOut|-->... | | | +---+ | | |--------->|MACOut|-->...
From CE| |--+ +-->| | . +------+ From CE| |--+ +-->| | . +------+
| |ARP Packets | | . | |ARP Packets | | .
| |from CE | | . +------+ | |from CE | | . +------+
| | | |--------> |Ether |-->... | | | |--------> |Ether |-->...
+---+ +---+ |MACOut| +---+ +---+ |MACOut|
RedirectIn BasicMetadata +------+ RedirectIn BasicMetadata +------+
Dispatch Dispatch
Figure 2: LFB use case for ARP Figure 3: LFB use case for ARP
There are two ways ARP processing could be triggered in the CE as There are two ways ARP processing could be triggered in the CE as
illustrated in Figure 2: illustrated in Figure 3:
o ARP packets arriving from outside of the NE. o ARP packets arriving from outside of the NE.
o IPV4 packets failing to resolve within the FE. o IPV4 packets failing to resolve within the FE.
ARP packets from network interfaces are filtered out by ARP packets from network interfaces are filtered out by
EtherClassifier LFB. The classified ARP packets and associated EtherClassifier LFB. The classified ARP packets and associated
metadata are then sent downstream to the RedirectOut LFB metadata are then sent downstream to the RedirectOut LFB
(Section 5.4.2) to be transported to CE. (Section 5.4.2) to be transported to CE.
<