draft-ietf-forces-lfb-lib-07.txt   draft-ietf-forces-lfb-lib-08.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: July 15, 2012 University of Patras Expires: September 1, 2012 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
January 12, 2012 February 29, 2012
ForCES Logical Function Block (LFB) Library ForCES Logical Function Block (LFB) Library
draft-ietf-forces-lfb-lib-07 draft-ietf-forces-lfb-lib-08
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 July 15, 2012. This Internet-Draft will expire on September 1, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 2, line 30 skipping to change at page 2, line 30
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 . . . . . . . . . . . . . . . . . 10 3.2.2. LFB Class Groupings . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.1. Atomic . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.1. Atomic . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.2. Compound struct . . . . . . . . . . . . . . . . . . . 16 4.1.2. Compound Struct . . . . . . . . . . . . . . . . . . . 16
4.1.3. Compound array . . . . . . . . . . . . . . . . . . . 16 4.1.3. Compound Array . . . . . . . . . . . . . . . . . . . 16
4.2. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 17 4.2. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 17
4.3. MetaData Types . . . . . . . . . . . . . . . . . . . . . 17 4.3. MetaData Types . . . . . . . . . . . . . . . . . . . . . 17
4.4. XML for Base Type Library . . . . . . . . . . . . . . . . 18 4.4. XML for Base Type Library . . . . . . . . . . . . . . . . 18
5. LFB Class Description . . . . . . . . . . . . . . . . . . . . 40 5. LFB Class Description . . . . . . . . . . . . . . . . . . . . 43
5.1. Ethernet Processing LFBs . . . . . . . . . . . . . . . . 40 5.1. Ethernet Processing LFBs . . . . . . . . . . . . . . . . 43
5.1.1. EtherPHYCop . . . . . . . . . . . . . . . . . . . . . 41 5.1.1. EtherPHYCop . . . . . . . . . . . . . . . . . . . . . 44
5.1.2. EtherMACIn . . . . . . . . . . . . . . . . . . . . . 43 5.1.2. EtherMACIn . . . . . . . . . . . . . . . . . . . . . 46
5.1.3. EtherClassifier . . . . . . . . . . . . . . . . . . . 44 5.1.3. EtherClassifier . . . . . . . . . . . . . . . . . . . 47
5.1.4. EtherEncap . . . . . . . . . . . . . . . . . . . . . 47 5.1.4. EtherEncap . . . . . . . . . . . . . . . . . . . . . 50
5.1.5. EtherMACOut . . . . . . . . . . . . . . . . . . . . . 49 5.1.5. EtherMACOut . . . . . . . . . . . . . . . . . . . . . 52
5.2. IP Packet Validation LFBs . . . . . . . . . . . . . . . . 50 5.2. IP Packet Validation LFBs . . . . . . . . . . . . . . . . 53
5.2.1. IPv4Validator . . . . . . . . . . . . . . . . . . . . 50 5.2.1. IPv4Validator . . . . . . . . . . . . . . . . . . . . 53
5.2.2. IPv6Validator . . . . . . . . . . . . . . . . . . . . 52 5.2.2. IPv6Validator . . . . . . . . . . . . . . . . . . . . 55
5.3. IP Forwarding LFBs . . . . . . . . . . . . . . . . . . . 53 5.3. IP Forwarding LFBs . . . . . . . . . . . . . . . . . . . 56
5.3.1. IPv4UcastLPM . . . . . . . . . . . . . . . . . . . . 54 5.3.1. IPv4UcastLPM . . . . . . . . . . . . . . . . . . . . 57
5.3.2. IPv4NextHop . . . . . . . . . . . . . . . . . . . . . 56 5.3.2. IPv4NextHop . . . . . . . . . . . . . . . . . . . . . 59
5.3.3. IPv6UcastLPM . . . . . . . . . . . . . . . . . . . . 58 5.3.3. IPv6UcastLPM . . . . . . . . . . . . . . . . . . . . 61
5.3.4. IPv6NextHop . . . . . . . . . . . . . . . . . . . . . 60 5.3.4. IPv6NextHop . . . . . . . . . . . . . . . . . . . . . 63
5.4. Redirect LFBs . . . . . . . . . . . . . . . . . . . . . . 62 5.4. Redirect LFBs . . . . . . . . . . . . . . . . . . . . . . 65
5.4.1. RedirectIn . . . . . . . . . . . . . . . . . . . . . 62 5.4.1. RedirectIn . . . . . . . . . . . . . . . . . . . . . 65
5.4.2. RedirectOut . . . . . . . . . . . . . . . . . . . . . 63 5.4.2. RedirectOut . . . . . . . . . . . . . . . . . . . . . 66
5.5. General Purpose LFBs . . . . . . . . . . . . . . . . . . 64 5.5. General Purpose LFBs . . . . . . . . . . . . . . . . . . 67
5.5.1. BasicMetadataDispatch . . . . . . . . . . . . . . . . 64 5.5.1. BasicMetadataDispatch . . . . . . . . . . . . . . . . 67
5.5.2. GenericScheduler . . . . . . . . . . . . . . . . . . 65 5.5.2. GenericScheduler . . . . . . . . . . . . . . . . . . 68
6. XML for LFB Library . . . . . . . . . . . . . . . . . . . . . 68 6. XML for LFB Library . . . . . . . . . . . . . . . . . . . . . 71
7. LFB Class Use Cases . . . . . . . . . . . . . . . . . . . . . 90 7. LFB Class Use Cases . . . . . . . . . . . . . . . . . . . . . 100
7.1. IPv4 Forwarding . . . . . . . . . . . . . . . . . . . . . 90 7.1. IPv4 Forwarding . . . . . . . . . . . . . . . . . . . . . 100
7.2. ARP processing . . . . . . . . . . . . . . . . . . . . . 91 7.2. ARP processing . . . . . . . . . . . . . . . . . . . . . 101
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 94 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 104
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 95 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 105
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 96 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 106
10.1. LFB Class Names and LFB Class Identifiers . . . . . . . . 96 10.1. LFB Class Names and LFB Class Identifiers . . . . . . . . 106
10.2. Metadata ID . . . . . . . . . . . . . . . . . . . . . . . 98 10.2. Metadata ID . . . . . . . . . . . . . . . . . . . . . . . 108
10.3. Exception ID . . . . . . . . . . . . . . . . . . . . . . 98 10.3. Exception ID . . . . . . . . . . . . . . . . . . . . . . 108
10.4. Validate Error ID . . . . . . . . . . . . . . . . . . . . 99 10.4. Validate Error ID . . . . . . . . . . . . . . . . . . . . 109
11. Security Considerations . . . . . . . . . . . . . . . . . . . 101 11. Security Considerations . . . . . . . . . . . . . . . . . . . 111
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 102 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 112
12.1. Normative References . . . . . . . . . . . . . . . . . . 102 12.1. Normative References . . . . . . . . . . . . . . . . . . 112
12.2. Informative References . . . . . . . . . . . . . . . . . 102 12.2. Informative References . . . . . . . . . . . . . . . . . 112
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 113
1. Terminology and Conventions 1. Terminology and Conventions
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Definitions 2. Definitions
skipping to change at page 9, line 24 skipping to change at page 9, line 24
fairness. fairness.
* Recognizes error conditions and generates ICMP error and * Recognizes error conditions and generates ICMP error and
information messages as required. information messages as required.
* Drops datagrams whose time-to-live fields have reached zero. * Drops datagrams whose time-to-live fields have reached zero.
* Fragments datagrams when necessary to fit into the MTU of the * Fragments datagrams when necessary to fit into the MTU of the
next network. next network.
(4) Choose a next-hop destination for each IP datagram, based on the (4) Choose a next hop destination for each IP datagram, based on the
information in its routing database. information in its routing database.
(5) Usually support an interior gateway protocol (IGP) to carry out (5) Usually support an interior gateway protocol (IGP) to carry out
distributed routing and reachability algorithms with the other distributed routing and reachability algorithms with the other
routers in the same autonomous system. In addition, some routers in the same autonomous system. In addition, some
routers will need to support an exterior gateway protocol (EGP) routers will need to support an exterior gateway protocol (EGP)
to exchange topological information with other autonomous to exchange topological information with other autonomous
systems. For all routers, it is essential to provide ability to systems. For all routers, it is essential to provide ability to
manage static routing items. manage static routing items.
skipping to change at page 10, line 5 skipping to change at page 10, line 5
[RFC5812] specifications, instructs the LFBs on the FE how to treat [RFC5812] specifications, instructs the LFBs on the FE how to treat
received/sent packets. received/sent packets.
Packets in an IP router are received and transmitted on physical Packets in an IP router are received and transmitted on physical
media typically referred to as "ports". Different physical port media typically referred to as "ports". Different physical port
media will have different ways for encapsulating outgoing frames and media will have different ways for encapsulating outgoing frames and
decapsulating incoming frames. The different physical media will decapsulating incoming frames. The different physical media will
also have different attributes that influence its behavior and how also have different attributes that influence its behavior and how
frames get encapsulated or decapsulated. This document will only frames get encapsulated or decapsulated. This document will only
deal with Ethernet physical media. Other future documents may deal deal with Ethernet physical media. Other future documents may deal
with other types of media. This document will also interchangeably with other type of media. This document will also interchangeably
refer to a port to be an abstraction that constitutes a PHY and a MAC refer to a port to be an abstraction that constitutes a PHY and a MAC
as described by the LFBs like EtherPHYCop, EtherMACIn, and as described by the LFBs like EtherPHYCop, EtherMACIn, and
EtherMACOut. EtherMACOut.
IP packets emanating from port LFBs are then processed by a IP packets emanating from port LFBs are then processed by a
validation LFB before being further forwarded to the next LFB. After validation LFB before being further forwarded to the next LFB. After
the validation process the packet is passed to an LFB where IP the validation process the packet is passed to an LFB where IP
forwarding decision is made. In the IP Forwarding LFBs, a Longest forwarding decision is made. In the IP Forwarding LFBs, a Longest
Prefix Match LFB is used to look up the destination information in a Prefix Match LFB is used to look up the destination information in a
packet and select a next hop index for sending the packet onward. A packet and select a next hop index for sending the packet onward. A
skipping to change at page 10, line 33 skipping to change at page 10, line 33
It is critical to classify functional requirements into various It is critical to classify functional requirements into various
classes of LFBs and construct a typical but also flexible enough base classes of LFBs and construct a typical but also flexible enough base
LFB library for various IP forwarding equipments. LFB library for various IP forwarding equipments.
3.2.1. LFB Design Choices 3.2.1. LFB Design Choices
A few design principles were factored into choosing how the base LFBs A few design principles were factored into choosing how the base LFBs
looked like. These are: looked like. These are:
o if a function can be designed by either one LFB or two or more o If a function can be designed by either one LFB or two or more
LFBs with the same cost, the choice is to go with two or more LFBs LFBs with the same cost, the choice is to go with two or more LFBs
so as to provide more flexibility for implementers. so as to provide more flexibility for implementers.
o when flexibility is not required, an LFB should take advantage of o When flexibility is not required, an LFB should take advantage of
its independence as much as possible and have minimal coupling its independence as much as possible and have minimal coupling
with other LFBs. The coupling may be from LFB attributes with other LFBs. The coupling may be from LFB attributes
definitions as well as physical implementations. definitions as well as physical implementations.
o unless there is a clear difference in functionality, similar o Unless there is a clear difference in functionality, similar
packet processing should not be represented as two or more packet processing should not be represented as two or more
different LFBs. Or else, it may add extra burden on different LFBs. Or else, it may add extra burden on
implementation to achieve interoperability. implementation to achieve interoperability.
3.2.2. LFB Class Groupings 3.2.2. LFB Class Groupings
The document defines groups of LFBs for typical router function The document defines groups of LFBs for typical router function
requirements: requirements:
(1) A group of Ethernet processing LFBs are defined to abstract the (1) A group of Ethernet processing LFBs are defined to abstract the
packet processing for Ethernet as the port media type. As the packet processing for Ethernet as the port media type. As the
most popular media type with rich processing features, Ethernet most popular media type with rich processing features, Ethernet
media processing LFBs was a natural choice. Definitions for media processing LFBs was a natural choice. Definitions for
processing of other port media types like POS or ATM may be processing of other port media type like POS or ATM may be
incorporated in the library in future version of the document or incorporated in the library in future version of the document or
in a future separate document. The following LFBs are defined in a future separate document. The following LFBs are defined
for Ethernet processing: for Ethernet processing:
* EtherPHYCop (Section 5.1.1) * EtherPHYCop (Section 5.1.1)
* EtherMACIn (Section 5.1.2) * EtherMACIn (Section 5.1.2)
* EtherClassifier (Section 5.1.3) * EtherClassifier (Section 5.1.3)
skipping to change at page 13, line 39 skipping to change at page 13, line 39
|Ether| +-----+ +---+ | | |Ether| +-----+ +---+ | |
|PHY | Ether +----+ | | |PHY | Ether +----+ | |
|Cop | Classifier | | +-------+ | | |Cop | Classifier | | +-------+ | |
|#n | +------+ | | |Ether | | | |#n | +------+ | | |Ether | | |
| | | | | |<--|Encap |<-+ | | | | | | |<--|Encap |<-+ |
| | | |<------| | | | | | | | |<------| | | | |
| |<---------------|Ether | ...| | +-------+ | | |<---------------|Ether | ...| | +-------+ |
| | |MACOut| +---| | | | | |MACOut| +---| | |
| | | | | +----+ | | | | | | +----+ |
+-----+ +------+ | BasicMetadataDispatch | +-----+ +------+ | BasicMetadataDispatch |
+-------------------------+ +----------->-------------+
Figure 1: LFB use case for IPv4 forwarding Figure 1: LFB use case for IPv4 forwarding
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
skipping to change at page 15, line 43 skipping to change at page 15, line 43
4.1.1. Atomic 4.1.1. Atomic
The following data types are defined as atomic data types and put in The following data types are defined as atomic data types and put in
the base type library: the base type library:
Data Type Name Brief Description Data Type Name Brief Description
-------------- ----------------- -------------- -----------------
IPv4Addr IPv4 address IPv4Addr IPv4 address
IPv6Addr IPv6 address IPv6Addr IPv6 address
IEEEMAC IEEE MAC address IEEEMAC IEEE MAC address
LANSpeedType Network speed values LANSpeedType LAN speed by value types
DuplexType Duplex types DuplexType Duplex types
PortStatusValues The possible values of port status, used for PortStatusType The possible types of port status, used for
both administrative and operative status both administrative and operative status.
VlanIDType The type of VLAN ID VlanIDType The type of VLAN ID
VlanPriorityType The type of VLAN priority VlanPriorityType The type of VLAN priority
SchdDisciplineType Scheduling discipline type SchdDisciplineType Scheduling discipline type
4.1.2. Compound struct 4.1.2. Compound Struct
The following compound struct types are defined in the base type The following compound struct types are defined in the base type
library: library:
Data Type Name Brief Description Data Type Name Brief Description
-------------- ----------------- -------------- -----------------
EtherDispatchEntryType Entry type for Ethernet dispatch table EtherDispatchEntryType Entry type for Ethernet dispatch table
VlanInputTableEntryType Entry type for VLAN input table VlanInputTableEntryType Entry type for VLAN input table
EncapTableEntryType Entry type for Ethernet encapsulation table EncapTableEntryType Entry type for Ethernet encapsulation table
MACInStatsType Statistics type for EtherMACIn LFB MACInStatsType Statistics type for EtherMACIn LFB
MACOutStatsType Statistics type for EtherMACOut LFB MACOutStatsType Statistics type for EtherMACOut LFB
EtherClassifyStatsType Entry type for statistics table in EtherClassifyStatsType Entry type for statistics table in
EtherClassifier LFB EtherClassifier LFB.
IPv4PrefixInfoType Entry type for IPv4 prefix table IPv4PrefixInfoType Entry type for IPv4 prefix table
IPv6PrefixInfoType Entry type for IPv6 prefix table IPv6PrefixInfoType Entry type for IPv6 prefix table
IPv4NextHopInfoType Entry type for IPv4 next hop table IPv4NextHopInfoType Entry type for IPv4 next hop table
IPv6NextHopInfoType Entry type for IPv6 next hop table IPv6NextHopInfoType Entry type for IPv6 next hop table
IPv4ValidatorStatsType Statistics type in IPv4validator LFB IPv4ValidatorStatsType Statistics type in IPv4validator LFB
IPv6ValidatorStatsType Statistics type in IPv6validator LFB IPv6ValidatorStatsType Statistics type in IPv6validator LFB
IPv4UcastLPMStatsType Statistics type in IPv4Unicast LFB IPv4UcastLPMStatsType Statistics type in IPv4UcastLPM LFB
IPv6UcastLPMStatsType Statistics type in IPv6Unicast LFB IPv6UcastLPMStatsType Statistics type in IPv6UcastLPM LFB
QueueStatsType Entry type for queue depth table QueueStatsType Entry type for queue depth table
MetadataDispatchType Entry type for metadata dispatch table MetadataDispatchType Entry type for metadata dispatch table
4.1.3. Compound array 4.1.3. Compound Array
Compound array types are mostly created based on compound struct Compound array types are mostly created based on compound struct
types for LFB table components. The following compound array types types for LFB table components. The following compound array types
are defined in this base type library: are defined in this base type library:
Data Type Name Brief Description Data Type Name Brief Description
-------------- ----------------- -------------- -----------------
EtherClassifyStatsTableType Type for Ethernet classifier statistics EtherClassifyStatsTableType Type for Ethernet classifier statistics
information table information table.
EtherDispatchTableType Type for Ethernet dispatch table EtherDispatchTableType Type for Ethernet dispatch table
VlanInputTableType Type for VLAN input table VlanInputTableType Type for VLAN input table
EncapTableType Type for Ethernet encapsulation table EncapTableType Type for Ethernet encapsulation table
IPv4PrefixTableType Type for IPv4 prefix table IPv4PrefixTableType Type for IPv4 prefix table
IPv6PrefixTableType Type for IPv6 prefix table IPv6PrefixTableType Type for IPv6 prefix table
IPv4NextHopTableType Type for IPv4 next hop table IPv4NextHopTableType Type for IPv4 next hop table
IPv6NextHopTableType Type for IPv6 next hop table IPv6NextHopTableType Type for IPv6 next hop table
MetadataDispatchTableType Type for Metadata dispatch table MetadataDispatchTableType Type for Metadata dispatch table
QueueStatsTableType Type for Queue depth table QueueStatsTableType Type for Queue depth table
skipping to change at page 17, line 24 skipping to change at page 17, line 24
Frame Name Brief Description Frame Name Brief Description
-------------- ---------------- -------------- ----------------
EthernetII An Ethernet II frame EthernetII An Ethernet II frame
ARP An ARP packet ARP An ARP packet
IPv4 An IPv4 packet IPv4 An IPv4 packet
IPv6 An IPv6 packet IPv6 An IPv6 packet
IPv4Unicast An IPv4 unicast packet IPv4Unicast An IPv4 unicast packet
IPv4Multicast An IPv4 multicast packet IPv4Multicast An IPv4 multicast packet
IPv6Unicast An IPv6 unicast packet IPv6Unicast An IPv6 unicast packet
IPv6Multicast An IPv6 multicast packet IPv6Multicast An IPv6 multicast packet
Arbitrary Any types of packet frames Arbitrary Any type of packet frames
4.3. MetaData Types 4.3. MetaData Types
LFB Metadata is used to communicate per-packet state from one LFB to LFB Metadata is used to communicate per-packet state from one LFB to
another. The <metadataDef> element in the FE model is used to define another. The <metadataDef> element in the FE model is used to define
a new metadata type. a new metadata type.
The following metadata types are currently defined in the base type The following metadata types are currently defined in the base type
library. library.
Metadata Name Metadata ID Brief Description Metadata Name Metadata ID Brief Description
------------ ---------- ------------- ------------ ---------- -------------
PHYPortID 1 The ingress physical port that the packet PHYPortID 1 Metadata indicating a physical port ID
arrived on SrcMAC 2 Metadata indicating a source MAC address
SrcMAC 2 Source MAC address of the packet DstMAC 3 Metadata indicating a destination MAC
DstMAC 3 Destination MAC address of the packet address.
LogicalPortID 4 ID of a logical port for the packet LogicalPortID 4 Metadata of a logical port ID
EtherType 5 The packet's Ethernet type EtherType 5 Metadata indicating an Ethernet type
VlanID 6 The VLAN ID of the Ethernet packet VlanID 6 Metadata of a VLAN ID
VlanPriority 7 The priority of the Ethernet packet VlanPriority 7 Metadata of a VLAN priority
NexthopIPv4Addr 8 Nexthop IPv4 address the packet is sent to NextHopIPv4Addr 8 Metadata representing a next hop IPv4
NexthopIPv6Addr 9 Nexthop IPv6 address the packet is sent to address.
HopSelector 10 A search key the packet can use to look up NextHopIPv6Addr 9 Metadata representing a next hop IPv6
a nexthop table for next hop information address.
of the packet HopSelector 10 Metadata indicating a hop selector
ExceptionID 11 Indicating exception type of the packet ExceptionID 11 Metadata indicating exception types for
which is exceptional for some processing exceptional cases during LFB processing.
ValidateErrorID 12 Indicating error type of the packet failed ValidateErrorID 12 Metadata indicating error types when a
some validation process packet passes validation process.
L3PortID 13 ID of L3 port L3PortID 13 Metadata indicating ID of an L3 logical
RedirectIndex 14 A metadata CE sends to RedirectIn LFB for port.
the associated packet to select output RedirectIndex 14 Metadata that CE sends to RedirectIn LFB,
port in the LFB group output "PktsOut" indicating an associated packet a group
MediaEncapInfoIndex 15 A search key the packet uses to look up a output port index of the LFB.
media encapsulation table to select its MediaEncapInfoIndex 15 A search key a packet uses to look up a
encapsulation media as well as followed table in related LFBs to select an
encapsulation LFB 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>All kinds of Ethernet frame</synopsis> <synopsis>Any type of Ethernet frame</synopsis>
</frameDef> </frameDef>
<frameDef> <frameDef>
<name>EthernetII</name> <name>EthernetII</name>
<synopsis>An Ethernet II frame</synopsis> <synopsis>An Ethernet II frame</synopsis>
</frameDef> </frameDef>
<frameDef> <frameDef>
<name>ARP</name> <name>ARP</name>
<synopsis>An arp packet</synopsis> <synopsis>An ARP packet</synopsis>
</frameDef> </frameDef>
<frameDef> <frameDef>
<name>IPv4</name> <name>IPv4</name>
<synopsis>An IPv4 packet</synopsis> <synopsis>An IPv4 packet</synopsis>
</frameDef> </frameDef>
<frameDef> <frameDef>
<name>IPv6</name> <name>IPv6</name>
<synopsis>An IPv6 packet</synopsis> <synopsis>An IPv6 packet</synopsis>
</frameDef> </frameDef>
<frameDef> <frameDef>
skipping to change at page 19, line 30 skipping to change at page 19, line 30
<frameDef> <frameDef>
<name>IPv6Unicast</name> <name>IPv6Unicast</name>
<synopsis>An IPv6 unicast packet</synopsis> <synopsis>An IPv6 unicast packet</synopsis>
</frameDef> </frameDef>
<frameDef> <frameDef>
<name>IPv6Multicast</name> <name>IPv6Multicast</name>
<synopsis>An IPv6 multicast packet</synopsis> <synopsis>An IPv6 multicast packet</synopsis>
</frameDef> </frameDef>
<frameDef> <frameDef>
<name>Arbitrary</name> <name>Arbitrary</name>
<synopsis>Any types of packet frames</synopsis> <synopsis>Any type of packet frames</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>Network speed values</synopsis> <synopsis>LAN speed by value types</synopsis>
<atomic> <atomic>
<baseType>uint32</baseType> <baseType>uint32</baseType>
<specialValues> <specialValues>
<specialValue value="0x00000000">
<name>LAN_SPEED_NONE</name>
<synopsis>Nothing is connected</synopsis>
</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>1000M 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_AUTO</name>
<synopsis>LAN speed auto</synopsis> <synopsis>LAN speed by auto negotiation</synopsis>
</specialValue> </specialValue>
</specialValues> </specialValues>
</atomic> </atomic>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>DuplexType</name> <name>DuplexType</name>
<synopsis>Duplex types</synopsis> <synopsis>Duplex types</synopsis>
<atomic> <atomic>
<baseType>uint32</baseType> <baseType>uint32</baseType>
<specialValues> <specialValues>
<specialValue value="0x00000001"> <specialValue value="0x00000001">
<name>Auto</name> <name>Auto</name>
<synopsis>Auto negotitation.</synopsis> <synopsis>Auto negotiation</synopsis>
</specialValue> </specialValue>
<specialValue value="0x00000002"> <specialValue value="0x00000002">
<name>Half-duplex</name> <name>HalfDuplex</name>
<synopsis>port negotitation half duplex</synopsis> <synopsis>Half duplex</synopsis>
</specialValue> </specialValue>
<specialValue value="0x00000003"> <specialValue value="0x00000003">
<name>Full-duplex</name> <name>FullDuplex</name>
<synopsis>port negotitation full duplex</synopsis> <synopsis>Full duplex</synopsis>
</specialValue> </specialValue>
</specialValues> </specialValues>
</atomic> </atomic>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>PortStatusValues</name> <name>PortStatusType</name>
<synopsis>The possible values of port status, used for both <synopsis>
administrative and operative status.</synopsis> Data types for port status, used for both administrative and
operative status.
</synopsis>
<atomic> <atomic>
<baseType>uchar</baseType> <baseType>uchar</baseType>
<specialValues> <specialValues>
<specialValue value="0"> <specialValue value="0">
<name>Disabled </name> <name>Disabled </name>
<synopsis>the port is operatively disabled.</synopsis> <synopsis>Port is operatively disabled</synopsis>
</specialValue> </specialValue>
<specialValue value="1"> <specialValue value="1">
<name>UP</name> <name>Up</name>
<synopsis>the port is up.</synopsis> <synopsis>Port is up</synopsis>
</specialValue> </specialValue>
<specialValue value="2"> <specialValue value="2">
<name>Down</name> <name>Down</name>
<synopsis>The port is down.</synopsis> <synopsis>Port is down</synopsis>
</specialValue> </specialValue>
</specialValues> </specialValues>
</atomic> </atomic>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>MACInStatsType</name> <name>MACInStatsType</name>
<synopsis>Statistics type in EtherMACIn LFB.</synopsis> <synopsis>
Data types for statistics in EtherMACIn LFB
</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>NumPacketsReceived</name> <name>NumPacketsReceived</name>
<synopsis>The number of packets received.</synopsis> <synopsis>Number of packets received</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>NumPacketsDropped</name> <name>NumPacketsDropped</name>
<synopsis>The number of packets dropped.</synopsis> <synopsis>Number of packets dropped</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>MACOutStatsType</name> <name>MACOutStatsType</name>
<synopsis>Statistics type in EtherMACOut LFB.</synopsis> <synopsis>
Data types for statistics in EtherMACOut LFB
</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>NumPacketsTransmitted</name> <name>NumPacketsTransmitted</name>
<synopsis>The number of packets transmitted.</synopsis> <synopsis>Number of packets transmitted</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>NumPacketsDropped</name> <name>NumPacketsDropped</name>
<synopsis>The number of packets dropped.</synopsis> <synopsis>Number of packets dropped</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>EtherDispatchEntryType</name> <name>EtherDispatchEntryType</name>
<synopsis>Entry type for Ethernet dispatch table in <synopsis>
EtherClassifier LFB.</synopsis> Data type for entry of Ethernet dispatch table in
EtherClassifier LFB.
</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>LogicalPortID</name> <name>LogicalPortID</name>
<synopsis>Logical port ID.</synopsis> <synopsis>Logical port ID</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>EtherType</name> <name>EtherType</name>
<synopsis>The EtherType value in the Ether head. <synopsis>
Ethernet type as defined in Ethernet frame header
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="3"> <component componentID="3">
<name>LFBOutputSelectIndex</name> <name>LFBOutputSelectIndex</name>
<synopsis>LFB Group output port index to select <synopsis>
downstream LFB port. Some possibilities of downstream Index for a packet to select a port instance in
LFB instances are: EtherClassifier LFB group output port to link to a
a) IPv4Validator downstream LFB. Possible downstream LFBs are
b) IPv6Validator IPv4Validator, IPv6Validator, RedirectOut, etc.
c) RedirectOut </synopsis>
d) etc
Note: LFBOutputSelectIndex is the FromPortIndex for
the port group "ClassifyOut" in the table LFBTopology
(of FEObject LFB) as defined for the EtherClassifier
LFB.</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>EtherDispatchTableType</name> <name>EtherDispatchTableType</name>
<synopsis>Type for Ethernet dispatch table.This table is used <synopsis>
in EtherClassifier LFB. Every Ethernet packet can be Data type for Ethernet dispatch table in EtherClassifier
dispatched to the LFB output group ports according to the LFB. The table entry type is defined by
logical port ID.</synopsis> EtherDispatchEntryType.
</synopsis>
<array type="variable-size"> <array type="variable-size">
<typeRef>EtherDispatchEntryType</typeRef> <typeRef>EtherDispatchEntryType</typeRef>
</array> </array>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>VlanIDType</name> <name>VlanIDType</name>
<synopsis>The type of VLAN ID</synopsis> <synopsis>Data type for VLAN ID</synopsis>
<atomic> <atomic>
<baseType>uint16</baseType> <baseType>uint16</baseType>
<rangeRestriction> <rangeRestriction>
<allowedRange min="0" max="4095"/> <allowedRange min="0" max="4095"/>
</rangeRestriction> </rangeRestriction>
</atomic> </atomic>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>VlanPriorityType</name> <name>VlanPriorityType</name>
<synopsis>The type of VLAN priority.</synopsis> <synopsis>Data type for VLAN priority</synopsis>
<atomic> <atomic>
<baseType>uchar</baseType> <baseType>uchar</baseType>
<rangeRestriction> <rangeRestriction>
<allowedRange min="0" max="7"/> <allowedRange min="0" max="7"/>
</rangeRestriction> </rangeRestriction>
</atomic> </atomic>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>VlanInputTableEntryType</name> <name>VlanInputTableEntryType</name>
<synopsis>Entry type for VLAN input table in EtherClassifier <synopsis>
LFB.</synopsis> Data type for entry of VLAN input table in EtherClassifier
LFB.
</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>IncomingPortID</name> <name>IncomingPortID</name>
<synopsis>The incoming port ID.</synopsis> <synopsis>The incoming port ID</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>VlanID</name> <name>VlanID</name>
<synopsis>Vlan ID.</synopsis> <synopsis>The VLAN ID</synopsis>
<typeRef>VlanIDType</typeRef> <typeRef>VlanIDType</typeRef>
</component> </component>
<component componentID="3"> <component componentID="3">
<name>Reserved</name>
<synopsis>Reserved for future use</synopsis>
<typeRef>uint16</typeRef>
</component>
<component componentID="4">
<name>LogicalPortID</name> <name>LogicalPortID</name>
<synopsis>logical port ID.</synopsis> <synopsis>The logical port ID</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>VlanInputTableType</name> <name>VlanInputTableType</name>
<synopsis>Type for VLAN input table.This table is used <synopsis>
in EtherClassifier LFB. Every Ethernet packet can get a new Data type for VlanInputTable in EtherClassifier LFB. The
LogicalPortID according to the IncomingPortID and VlanID. 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> </synopsis>
<array type="variable-size"> <array type="variable-size">
<typeRef>VlanInputTableEntryType</typeRef> <typeRef>VlanInputTableEntryType</typeRef>
</array> </array>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>EtherClassifyStatsType</name> <name>EtherClassifyStatsType</name>
<synopsis>Entry type for statistics table in EtherClassifier <synopsis>
LFB.</synopsis> Data type for entry of statistics table in EtherClassifier
LFB.
</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>EtherType</name> <name>EtherType</name>
<synopsis>The EtherType value</synopsis> <synopsis>
The Ethernet type as defined in Ethernet packet header
</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>PacketsNum</name> <name>PacketsNum</name>
<synopsis>Packets number</synopsis> <synopsis>Packets number</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>EtherClassifyStatsTableType</name> <name>EtherClassifyStatsTableType</name>
<synopsis>Type for Ethernet classifier statistics <synopsis>
information table in EtherClassifier LFB.</synopsis> Data type for Ethernet classifying statistics table in
EtherClassifier LFB, the entry of which is defined by
EtherClassifyStatsType.
</synopsis>
<array type="variable-size"> <array type="variable-size">
<typeRef>EtherClassifyStatsType</typeRef> <typeRef>EtherClassifyStatsType</typeRef>
</array> </array>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv4ValidatorStatsType</name> <name>IPv4ValidatorStatsType</name>
<synopsis>Statistics type in IPv4validator LFB.</synopsis> <synopsis>
Data type for statistics in IPv4validator LFB
</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>badHeaderPkts</name> <name>badHeaderPkts</name>
<synopsis>Number of bad header packets.</synopsis> <synopsis>Number of bad header packets</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>badTotalLengthPkts</name> <name>badTotalLengthPkts</name>
<synopsis>Number of bad total length packets.</synopsis> <synopsis>
Number of packets with bad total length
</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
<component componentID="3"> <component componentID="3">
<name>badTTLPkts</name> <name>badTTLPkts</name>
<synopsis>Number of bad TTL packets.</synopsis> <synopsis>Number of bad TTL packets</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
<component componentID="4"> <component componentID="4">
<name>badChecksumPkts</name> <name>badChecksumPkts</name>
<synopsis>Number of bad checksum packets.</synopsis> <synopsis>Number of bad checksum packets</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv6ValidatorStatsType</name> <name>IPv6ValidatorStatsType</name>
<synopsis>Statistics type in IPv6validator LFB.</synopsis> <synopsis>
Data type for statistics in IPv6validator LFB
</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>badHeaderPkts</name> <name>badHeaderPkts</name>
<synopsis>Number of bad header packets.</synopsis> <synopsis>Number of bad header packets</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>badTotalLengthPkts</name> <name>badTotalLengthPkts</name>
<synopsis>Number of bad total length packets.</synopsis> <synopsis>Number of bad total length packets</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
<component componentID="3"> <component componentID="3">
<name>badHopLimitPkts</name> <name>badHopLimitPkts</name>
<synopsis>Number of bad Hop limit packets.</synopsis> <synopsis>Number of bad hop limit packets</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv4PrefixInfoType</name> <name>IPv4PrefixInfoType</name>
<synopsis>Entry type for IPv4 prefix table.</synopsis> <synopsis>Data type for entry of IPv4 prefix table</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>IPv4Address</name> <name>IPv4Address</name>
<synopsis>An IPv4 Address</synopsis> <synopsis>The IPv4 address</synopsis>
<typeRef>IPv4Addr</typeRef> <typeRef>IPv4Addr</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>Prefixlen</name> <name>Prefixlen</name>
<synopsis>The prefix length</synopsis> <synopsis>The prefix length</synopsis>
<atomic> <atomic>
<baseType>uchar</baseType> <baseType>uchar</baseType>
<rangeRestriction> <rangeRestriction>
<allowedRange min="0" max="32"/> <allowedRange min="0" max="32"/>
</rangeRestriction> </rangeRestriction>
</atomic> </atomic>
</component> </component>
<component componentID="3"> <component componentID="3">
<name>HopSelector</name>
<synopsis>HopSelector is the nexthop ID which points to
the nexthop table</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="4">
<name>ECMPFlag</name> <name>ECMPFlag</name>
<synopsis>An ECMP Flag for this route</synopsis> <synopsis>ECMP flag</synopsis>
<atomic> <atomic>
<baseType>boolean</baseType> <baseType>boolean</baseType>
<specialValues> <specialValues>
<specialValue value="false"> <specialValue value="false">
<name>False</name> <name>False</name>
<synopsis>This route does not have multiple <synopsis>
nexthops.</synopsis> ECMP flag is false, indicating the route
does not have multiple next hops.
</synopsis>
</specialValue> </specialValue>
<specialValue value="true"> <specialValue value="true">
<name>True</name> <name>True</name>
<synopsis>This route has multiple nexthops. <synopsis>
ECMP flag is true, indicating the route
has multiple next hops.
</synopsis> </synopsis>
</specialValue> </specialValue>
</specialValues> </specialValues>
</atomic> </atomic>
</component> </component>
<component componentID="5"> <component componentID="4">
<name>DefaultRouteFlag</name> <name>DefaultRouteFlag</name>
<synopsis>A default route flag.</synopsis> <synopsis>Default route flag</synopsis>
<atomic> <atomic>
<baseType>boolean</baseType> <baseType>boolean</baseType>
<specialValues> <specialValues>
<specialValue value="false"> <specialValue value="false">
<name>False</name> <name>False</name>
<synopsis>This is not a default route. <synopsis>
Default route flag is false, indicating the
route is not a default route.
</synopsis> </synopsis>
</specialValue> </specialValue>
<specialValue value="true"> <specialValue value="true">
<name>True</name> <name>True</name>
<synopsis>This route is a default route. <synopsis>
Default route flag is true, indicating the
route is a default route.
</synopsis> </synopsis>
</specialValue> </specialValue>
</specialValues> </specialValues>
</atomic> </atomic>
</component> </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>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv4PrefixTableType</name> <name>IPv4PrefixTableType</name>
<synopsis>Type for IPv4 prefix table. This table is currently <synopsis>
used in IPv4UcastLPM LFB. The LFB uses the destination IPv4 Data type for IPv4 longest prefix match table used for
address of every input packet as search key to look up this IPv4UcastLPM LFB. The destination IPv4 address of every
table in order extract a next hop selector.</synopsis> input packet is used as a search key to look up the table
to find out a next hop selector. Entry type of the table is
defined by IPv4PrefixInfoType.
</synopsis>
<array type="variable-size"> <array type="variable-size">
<typeRef>IPv4PrefixInfoType</typeRef> <typeRef>IPv4PrefixInfoType</typeRef>
</array> </array>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv4UcastLPMStatsType</name> <name>IPv4UcastLPMStatsType</name>
<synopsis>Statistics type in IPv4Unicast LFB.</synopsis> <synopsis>Statistics type in IPv4UcastLPM LFB</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>InRcvdPkts</name> <name>InRcvdPkts</name>
<synopsis>The total number of input packets received. <synopsis>
Total number of input packets received
</synopsis> </synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>FwdPkts</name> <name>FwdPkts</name>
<synopsis>IPv4 packets forwarded by this LFB</synopsis> <synopsis>Packets forwarded by the LFB</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
<component componentID="3"> <component componentID="3">
<name>NoRoutePkts</name> <name>NoRoutePkts</name>
<synopsis>The number of IP datagrams discarded because <synopsis>Packets with no routes found</synopsis>
no route could be found.</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv6PrefixInfoType</name> <name>IPv6PrefixInfoType</name>
<synopsis>Entry type for IPv6 prefix table.</synopsis> <synopsis>Entry type for IPv6 prefix table</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>IPv6Address</name> <name>IPv6Address</name>
<synopsis>An IPv6 Address</synopsis> <synopsis>The IPv6 address</synopsis>
<typeRef>IPv6Addr</typeRef> <typeRef>IPv6Addr</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>Prefixlen</name> <name>Prefixlen</name>
<synopsis>The prefix length</synopsis> <synopsis>The prefix length</synopsis>
<atomic> <atomic>
<baseType>uchar</baseType> <baseType>uchar</baseType>
<rangeRestriction> <rangeRestriction>
<allowedRange min="0" max="128"/> <allowedRange min="0" max="32"/>
</rangeRestriction> </rangeRestriction>
</atomic> </atomic>
</component> </component>
<component componentID="3"> <component componentID="3">
<name>HopSelector</name>
<synopsis>HopSelector is the nexthop ID which points
to the nexthop table</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="4">
<name>ECMPFlag</name> <name>ECMPFlag</name>
<synopsis>An ECMP Flag for this route</synopsis> <synopsis>ECMP flag</synopsis>
<atomic> <atomic>
<baseType>boolean</baseType> <baseType>boolean</baseType>
<specialValues> <specialValues>
<specialValue value="false"> <specialValue value="false">
<name>False</name> <name>False</name>
<synopsis>This route does not have multiple <synopsis>
nexthops.</synopsis> ECMP flag is false, indicating the route
does not have multiple next hops.
</synopsis>
</specialValue> </specialValue>
<specialValue value="true"> <specialValue value="true">
<name>True</name> <name>True</name>
<synopsis>This route has multiple nexthops. <synopsis>
ECMP flag is true, indicating the route has
multiple next hops.
</synopsis> </synopsis>
</specialValue> </specialValue>
</specialValues> </specialValues>
</atomic> </atomic>
</component> </component>
<component componentID="5"> <component componentID="4">
<name>DefaultRouteFlag</name> <name>DefaultRouteFlag</name>
<synopsis>A Default Route Flag.</synopsis> <synopsis>Default route flag</synopsis>
<atomic> <atomic>
<baseType>boolean</baseType> <baseType>boolean</baseType>
<specialValues> <specialValues>
<specialValue value="false"> <specialValue value="false">
<name>False</name> <name>False</name>
<synopsis>This is not a default route. <synopsis>
Default route flag is false, indicating the
route is not a default route.
</synopsis> </synopsis>
</specialValue> </specialValue>
<specialValue value="true"> <specialValue value="true">
<name>True</name> <name>True</name>
<synopsis>This route is a default route. <synopsis>
Default route flag is true, indicating the
route is a default route.
</synopsis> </synopsis>
</specialValue> </specialValue>
</specialValues> </specialValues>
</atomic> </atomic>
</component> </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>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv6PrefixTableType</name> <name>IPv6PrefixTableType</name>
<synopsis>Type for IPv6 prefix table.This table is currently <synopsis>
used in IPv6UcastLPM LFB. The LFB uses the destination IPv6 Data type for IPv6 longest prefix match table used for
address of every input packet as search key to look up this IPv6UcastLPM LFB. The destination IPv6 address of every
table in order extract a next hop selector.</synopsis> input packet is used as a search key to look up the table
to find out a next hop selector. Entry type of the table is
defined by IPv6PrefixInfoType.
</synopsis>
<array type="variable-size"> <array type="variable-size">
<typeRef>IPv6PrefixInfoType</typeRef> <typeRef>IPv6PrefixInfoType</typeRef>
</array> </array>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv6UcastLPMStatsType</name> <name>IPv6UcastLPMStatsType</name>
<synopsis>Statistics type in IPv6Unicast LFB.</synopsis> <synopsis>Statistics type in IPv6UcastLPM LFB</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>InRcvdPkts</name> <name>InRcvdPkts</name>
<synopsis>The total number of input packets <synopsis>
received</synopsis> Total number of input packets received
</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>FwdPkts</name> <name>FwdPkts</name>
<synopsis>IPv6 packets forwarded by this LFB</synopsis> <synopsis>Packets forwarded by the LFB</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
<component componentID="3"> <component componentID="3">
<name>NoRoutePkts</name> <name>NoRoutePkts</name>
<synopsis>The number of IP datagrams discarded because <synopsis>Packets with no routes found</synopsis>
no route could be found.</synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv4NextHopInfoType</name> <name>IPv4NextHopInfoType</name>
<synopsis>Entry type for IPv4 next hop table.</synopsis> <synopsis>
Data type for entry of IPv4 next hop information table used
in IPv4NextHop LFB.
</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>L3PortID</name> <name>L3PortID</name>
<synopsis>The ID of the Logical/physical Output Port <synopsis>
that we pass onto the downstream LFB instance. This The L3PortID is the ID of the logical output port
ID indicates what port to the neighbor is as defined that is passed onto the downstream LFB, indicating
by L3.</synopsis> what port to the neighbor is as defined by L3.
</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>MTU</name> <name>MTU</name>
<synopsis>Maximum Transmission Unit for out going port. <synopsis>
It is for desciding whether the packet need Maximum Transmission Unit for outgoing port
fragmentation </synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="3"> <component componentID="3">
<name>NextHopIPAddr</name> <name>NextHopIPAddr</name>
<synopsis>Next Hop IPv4 Address</synopsis> <synopsis>Next hop IPv4 address</synopsis>
<typeRef>IPv4Addr</typeRef> <typeRef>IPv4Addr</typeRef>
</component> </component>
<component componentID="4"> <component componentID="4">
<name>MediaEncapInfoIndex</name> <name>MediaEncapInfoIndex</name>
<synopsis>The index we pass onto the downstream LFB <synopsis>
instance. This index is used to lookup a table The index is passed onto the downstream encapsulation
(typically media encapsulatation related) further LFB instance and is used there as a search key to
downstream.</synopsis> lookup the index of a table (typically media
encapsulation related) for further encapsulation
information.
</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="5"> <component componentID="5">
<name>LFBOutputSelectIndex</name> <name>LFBOutputSelectIndex</name>
<synopsis>LFB Group output port index to select <synopsis>
downstream LFB port. Some possibilities of downstream The index is for the LFB Group output port to select
LFB instances are: downstream LFB port. It is a 1-to-1 mapping with
a) EtherEncap FEObject LFB's table LFBTopology component
b) Other type of media LFB FromPortIndex corresponding to the port group mapping
c) A metadata Dispatcher FromLFBID as IPv4NextHop LFB instance.
d) A redirect LFB
e) etc
Note: LFBOutputSelectIndex is the FromPortIndex for
the port group "SuccessOut" in the table LFBTopology
(of FEObject LFB) as defined for the IPv4NextHop LFB.
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv4NextHopTableType</name> <name>IPv4NextHopTableType</name>
<synopsis>Type for IPv4 next hop table. This table is used <synopsis>
in IPv4NextHop LFB. The LFB uses metadata "HopSelector" Data type for IPv4 next hop table in IPv4NextHop LFB. The
received to match the array index to get the next hop LFB uses a hop selector metadata received from upstream LFB
information. </synopsis> as a search key to look up the index of the table to get
next hop information. Entry type of the table is defined by
IPv4NextHopInfoType.
</synopsis>
<array type="variable-size"> <array type="variable-size">
<typeRef>IPv4NextHopInfoType</typeRef> <typeRef>IPv4NextHopInfoType</typeRef>
</array> </array>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv6NextHopInfoType</name> <name>IPv6NextHopInfoType</name>
<synopsis>Entry type for IPv6 next hop table.</synopsis> <synopsis>
Data type for entry of IPv6 next hop information table used
in IPv6NextHop LFB.
</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>L3PortID</name> <name>L3PortID</name>
<synopsis>The ID of the Logical/physical Output Port <synopsis>
that we pass onto the downstream LFB instance. This The L3PortID is the ID of the logical output port
ID indicates what port to the neighbor is as defined that is passed onto the downstream LFB, indicating
by L3.</synopsis> what port to the neighbor is as defined by L3.
</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>MTU</name> <name>MTU</name>
<synopsis>Maximum Transmission Unit for out going port. <synopsis>
It is for desciding whether the packet need Maximum Transmission Unit for outgoing port
fragmentation.</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="3"> <component componentID="3">
<name>NextHopIPAddr</name> <name>NextHopIPAddr</name>
<synopsis>Next Hop IPv6 Address</synopsis> <synopsis>Next hop IPv6 address</synopsis>
<typeRef>IPv6Addr</typeRef> <typeRef>IPv6Addr</typeRef>
</component> </component>
<component componentID="4"> <component componentID="4">
<name>MediaEncapInfoIndex</name> <name>MediaEncapInfoIndex</name>
<synopsis>The index we pass onto the downstream LFB <synopsis>
instance. This index is used to lookup a table The index is passed onto the downstream encapsulation
(typically media encapsulatation related) further LFB instance and is used there as a search key to
downstream.</synopsis> lookup the index of a table (typically media
encapsulation related) for further encapsulation
information.
</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="5"> <component componentID="5">
<name>LFBOutputSelectIndex</name> <name>LFBOutputSelectIndex</name>
<synopsis>LFB Group output port index to select <synopsis>
downstream LFB port. Some possibilities of downstream The index is for the LFB group output port to select
LFB instances are: downstream LFB port. It is a 1-to-1 mapping with
a) EtherEncap FEObject LFB's table LFBTopology component
b) Other type of media LFB FromPortIndex corresponding to the port group mapping
c) A metadata Dispatcher FromLFBID as IPv6NextHop LFB instance.
d) A redirect LFB
e) etc
Note: LFBOutputSelectIndex is the FromPortIndex for
the port group "SuccessOut" in the table LFBTopology
(of FEObject LFB) as defined for the IPv6NextHop LFB.
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv6NextHopTableType</name> <name>IPv6NextHopTableType</name>
<synopsis>Type for IPv6 next hop table. This table is used <synopsis>
in IPv6NextHop LFB. The LFB uses metadata "HopSelector" Data type for IPv6 next hop table in IPv6NextHop LFB. The
received to match the array index to get the next hop LFB uses a hop selector metadata received from upstream LFB
information.</synopsis> as a search key to look up the index of the table to get
next hop information. Entry type of the table is defined by
IPv6NextHopInfoType.
</synopsis>
<array type="variable-size"> <array type="variable-size">
<typeRef>IPv6NextHopInfoType</typeRef> <typeRef>IPv6NextHopInfoType</typeRef>
</array> </array>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>EncapTableEntryType</name> <name>EncapTableEntryType</name>
<synopsis>Entry type for Ethernet encapsulation table in <synopsis>
EtherEncap LFB.</synopsis> Data type for entry of Ethernet encapsulation table in
EtherEncap LFB.
</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>DstMac</name> <name>DstMac</name>
<synopsis>Ethernet Mac of the Neighbor</synopsis> <synopsis>
Destination MAC address for Ethernet encapsulation of
the packet.
</synopsis>
<typeRef>IEEEMAC</typeRef> <typeRef>IEEEMAC</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>SrcMac</name> <name>SrcMac</name>
<synopsis>Source MAC used in encapsulation</synopsis> <synopsis>
Source MAC address for Ethernet encapsulation of the
packet.
</synopsis>
<typeRef>IEEEMAC</typeRef> <typeRef>IEEEMAC</typeRef>
</component> </component>
<component componentID="3"> <component componentID="3">
<name>VlanID</name> <name>VlanID</name>
<synopsis>VLAN ID.</synopsis> <synopsis>The VLAN ID assigned to the packet</synopsis>
<typeRef>VlanIDType</typeRef> <typeRef>VlanIDType</typeRef>
</component> </component>
<component componentID="4"> <component componentID="4">
<name>Reserved</name>
<synopsis>Reserved for future use</synopsis>
<typeRef>uint16</typeRef>
</component>
<component componentID="5">
<name>L2PortID</name> <name>L2PortID</name>
<synopsis>Output logical L2 port ID.</synopsis> <synopsis>
The L2 logical output port ID for the packet
</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>EncapTableType</name> <name>EncapTableType</name>
<synopsis>Type for Ethernet encapsulation table. This <synopsis>
table is used in EtherEncap LFB. The LFB uses the metadata Data type for Ethernet encapsulation table in Etherencap
"MediaEncapInfoIndex " received to get the encapsulation LFB. The LFB uses the metadata "MediaEncapInfoIndex"
information.</synopsis> 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>
<array type="variable-size"> <array type="variable-size">
<typeRef>EncapTableEntryType</typeRef> <typeRef>EncapTableEntryType</typeRef>
</array> </array>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>MetadataDispatchType</name> <name>MetadataDispatchType</name>
<synopsis>Entry type for Metadata dispatch table in <synopsis>
BasicMetadataDispatch LFB.</synopsis> Data type for entry of metadata dispatch table used
in BasicMetadataDispatch LFB.
</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>MetadataValue</name> <name>MetadataValue</name>
<synopsis>metadata value.</synopsis> <synopsis>The value of the dispatch metadata</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>OutputIndex</name> <name>OutputIndex</name>
<synopsis>group output port index.</synopsis> <synopsis>
Index of a group output port for outgoing packets
with the dispatch metadata value.
</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>MetadataDispatchTableType</name> <name>MetadataDispatchTableType</name>
<synopsis>Type for Metadata dispatch table. This table is used <synopsis>
in BasicMetadataDispatch LFB. The LFB uses MetadataValue to Data type for metadata dispatch table used in
get the LFB group output port index.</synopsis> BasicMetadataDispatch LFB. The LFB uses a metadata value as
the search key to look up the table to get an index of the
LFB group output port for output of the packet. Metadata
value of the table is also defined as a content key field so
that CE can manipulate the table by means of a content key.
</synopsis>
<array type="variable-size"> <array type="variable-size">
<typeRef>MetadataDispatchType</typeRef> <typeRef>MetadataDispatchType</typeRef>
<contentKey contentKeyID="1"> <contentKey contentKeyID="1">
<contentKeyField>MetadataValue</contentKeyField> <contentKeyField>MetadataValue</contentKeyField>
</contentKey> </contentKey>
</array> </array>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>SchdDisciplineType</name> <name>SchdDisciplineType</name>
<synopsis>Scheduling discipline type.</synopsis> <synopsis>Scheduling discipline types</synopsis>
<atomic> <atomic>
<baseType>uint32</baseType> <baseType>uint32</baseType>
<specialValues> <specialValues>
<specialValue value="1"> <specialValue value="1">
<name>RR</name> <name>RR</name>
<synopsis>Round Robin scheduler.</synopsis> <synopsis>
Round Robin scheduling discipline
</synopsis>
</specialValue> </specialValue>
</specialValues> </specialValues>
</atomic> </atomic>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>QueueStatsType</name> <name>QueueStatsType</name>
<synopsis>Entry type for queue statistics table in <synopsis>
GenericScheduler LFB.</synopsis> Data type for entry of queue statistics table in
GenericScheduler LFB.
</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>QueueID</name> <name>QueueID</name>
<synopsis>Queue ID</synopsis> <synopsis>The input queue ID</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>QueueDepthInPackets</name> <name>QueueDepthInPackets</name>
<synopsis>the Queue Depth when the depth units <synopsis>Current queue depth in packets</synopsis>
are packets.</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="3"> <component componentID="3">
<name>QueueDepthInBytes</name> <name>QueueDepthInBytes</name>
<synopsis>the Queue Depth when the depth units <synopsis>Current queue depth in bytes</synopsis>
are bytes.</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>QueueStatsTableType</name> <name>QueueStatsTableType</name>
<synopsis>Type for Queue statistics table in GenericScheduler <synopsis>
LFB.</synopsis> Data type for queue statistics table in GenericScheduler
LFB. Entry type of the table is defined by QueueStatsType.
</synopsis>
<array type="variable-size"> <array type="variable-size">
<typeRef>QueueDepthType</typeRef> <typeRef>QueueStatsType</typeRef>
</array> </array>
</dataTypeDef> </dataTypeDef>
</dataTypeDefs> </dataTypeDefs>
<metadataDefs> <metadataDefs>
<metadataDef> <metadataDef>
<name>PHYPortID</name> <name>PHYPortID</name>
<synopsis>The physical port ID that a packet has entered. <synopsis>Metadata indicating a physical port ID</synopsis>
</synopsis>
<metadataID>1</metadataID> <metadataID>1</metadataID>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</metadataDef> </metadataDef>
<metadataDef> <metadataDef>
<name>SrcMAC</name> <name>SrcMAC</name>
<synopsis>Source MAC address of the packet.</synopsis> <synopsis>Metadata indicating a source MAC address</synopsis>
<metadataID>2</metadataID> <metadataID>2</metadataID>
<typeRef>IEEEMAC</typeRef> <typeRef>IEEEMAC</typeRef>
</metadataDef> </metadataDef>
<metadataDef> <metadataDef>
<name>DstMAC</name> <name>DstMAC</name>
<synopsis>Destination MAC address of the packet.</synopsis> <synopsis>
Metadata indicating a destination MAC address
</synopsis>
<metadataID>3</metadataID> <metadataID>3</metadataID>
<typeRef>IEEEMAC</typeRef> <typeRef>IEEEMAC</typeRef>
</metadataDef> </metadataDef>
<metadataDef> <metadataDef>
<name>LogicalPortID</name> <name>LogicalPortID</name>
<synopsis>ID of a logical port for the packet.</synopsis> <synopsis>Metadata of a logical port ID</synopsis>
<metadataID>4</metadataID> <metadataID>4</metadataID>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</metadataDef> </metadataDef>
<metadataDef> <metadataDef>
<name>EtherType</name> <name>EtherType</name>
<synopsis>Indicating the Ethernet type of the Ethernet packet. <synopsis>Metadata indicating an Ethernet type</synopsis>
</synopsis>
<metadataID>5</metadataID> <metadataID>5</metadataID>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</metadataDef> </metadataDef>
<metadataDef> <metadataDef>
<name>VlanID</name> <name>VlanID</name>
<synopsis>The Vlan ID of the Ethernet packet.</synopsis> <synopsis>Metadata of a VLAN ID</synopsis>
<metadataID>6</metadataID> <metadataID>6</metadataID>
<typeRef>VlanIDType</typeRef> <typeRef>VlanIDType</typeRef>
</metadataDef> </metadataDef>
<metadataDef> <metadataDef>
<name>VlanPriority</name> <name>VlanPriority</name>
<synopsis>The priority of the Ethernet packet.</synopsis> <synopsis>Metadata of a VLAN priority</synopsis>
<metadataID>7</metadataID> <metadataID>7</metadataID>
<typeRef>VlanPriorityType</typeRef> <typeRef>VlanPriorityType</typeRef>
</metadataDef> </metadataDef>
<metadataDef> <metadataDef>
<name>NexthopIPv4Addr</name> <name>NextHopIPv4Addr</name>
<synopsis>Nexthop IPv4 address the packet is sent to. <synopsis>
Metadata representing a next hop IPv4 address
</synopsis> </synopsis>
<metadataID>8</metadataID> <metadataID>8</metadataID>
<typeRef>IPv4Addr</typeRef> <typeRef>IPv4Addr</typeRef>
</metadataDef> </metadataDef>
<metadataDef> <metadataDef>
<name>NexthopIPv6Addr</name> <name>NextHopIPv6Addr</name>
<synopsis>Nexthop IPv6 address the packet is sent to. <synopsis>
Metadata representing a next hop IPv6 address
</synopsis> </synopsis>
<metadataID>9</metadataID> <metadataID>9</metadataID>
<typeRef>IPv6Addr</typeRef> <typeRef>IPv6Addr</typeRef>
</metadataDef> </metadataDef>
<metadataDef> <metadataDef>
<name>HopSelector</name> <name>HopSelector</name>
<synopsis>A search key the packet can use to look up a nexthop <synopsis>Metadata indicating a hop selector</synopsis>
table for next hop information of the packet.</synopsis>
<metadataID>10</metadataID> <metadataID>10</metadataID>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</metadataDef> </metadataDef>
<metadataDef> <metadataDef>
<name>ExceptionID</name> <name>ExceptionID</name>
<synopsis>Indicating exception type of the packet which is <synopsis>
exceptional for some processing.</synopsis> Metadata indicating exception types for exceptional cases
during LFB processing.
</synopsis>
<metadataID>11</metadataID> <metadataID>11</metadataID>
<atomic> <atomic>
<baseType>uint32</baseType> <baseType>uint32</baseType>
<specialValues> <specialValues>
<specialValue value="0"> <specialValue value="0">
<name>AnyUnrecognizedExceptionCase</name> <name>AnyUnrecognizedExceptionCase</name>
<synopsis>any unrecognized exception case.</synopsis> <synopsis>Any unrecognized exception case</synopsis>
</specialValue> </specialValue>
<specialValue value="1"> <specialValue value="1">
<name>ClassifyNoMatching</name> <name>ClassifyNoMatching</name>
<synopsis>There is no matching when classifying the <synopsis>
packet in EtherClassifier LFB.</synopsis> There is no matching of tables in EtherClassifier
LFB.
</synopsis>
</specialValue> </specialValue>
<specialValue value="2"> <specialValue value="2">
<name>MediaEncapInfoIndexInvalid</name> <name>MediaEncapInfoIndexInvalid</name>
<synopsis>The MediaEncapInfoIndex value of the <synopsis>
packet is invalid and can not be allocated in the The MediaEncapInfoIndex value of the packet is
EncapTable.</synopsis> invalid and cannot be allocated in the EncapTable
in EtherEncap LFB.
</synopsis>
</specialValue> </specialValue>
<specialValue value="3"> <specialValue value="3">
<name>EncapTableLookupFailed</name> <name>EncapTableLookupFailed</name>
<synopsis>The packet failed lookup of the EncapTable <synopsis>
table even though the MediaEncapInfoIndex is valid. The packet failed lookup of the EncapTable table
in EtherEncap LFB even though the
MediaEncapInfoIndex is valid.
</synopsis> </synopsis>
</specialValue> </specialValue>
<specialValue value="4"> <specialValue value="4">
<name>BadTTL</name> <name>BadTTL</name>
<synopsis>Packet with expired TTL.</synopsis> <synopsis>Packet with expired TTL</synopsis>
</specialValue> </specialValue>
<specialValue value="5"> <specialValue value="5">
<name>IPv4HeaderLengthMismatch</name> <name>IPv4HeaderLengthMismatch</name>
<synopsis>Packet with header length more than 5 <synopsis>
words.</synopsis> Packet with header length more than 5 words
</synopsis>
</specialValue> </specialValue>
<specialValue value="6"> <specialValue value="6">
<name>RouterAlertOptions</name> <name>RouterAlertOptions</name>
<synopsis>Packet IP head include Router Alert <synopsis>
options.</synopsis> Packet IP head includes router alert Options
</synopsis>
</specialValue> </specialValue>
<specialValue value="7"> <specialValue value="7">
<name>IPv6HopLimitZero</name> <name>IPv6HopLimitZero</name>
<synopsis>Packet with Hop Limit zero </synopsis> <synopsis>Packet with the hop limit zero</synopsis>
</specialValue> </specialValue>
<specialValue value="8"> <specialValue value="8">
<name>IPv6NextHeaderHBH</name> <name>IPv6NextHeaderHBH</name>
<synopsis>Packet with next header set to Hop-by-Hop <synopsis>
Packet with next header set to Hop-by-Hop
</synopsis> </synopsis>
</specialValue> </specialValue>
<specialValue value="9"> <specialValue value="9">
<name>SrcAddressExecption</name> <name>SrcAddressExecption</name>
<synopsis>Packet with exceptional source address. <synopsis>
Packet with exceptional source address
</synopsis> </synopsis>
</specialValue> </specialValue>
<specialValue value="10"> <specialValue value="10">
<name>DstAddressExecption</name> <name>DstAddressExecption</name>
<synopsis>Packet with exceptional destination <synopsis>
address </synopsis> Packet with exceptional destination address
</synopsis>
</specialValue> </specialValue>
<specialValue value="11"> <specialValue value="11">
<name>LPMLookupFailed</name> <name>LPMLookupFailed</name>
<synopsis>The packet failed the LPM lookup of the <synopsis>
prefix table.</synopsis> Packet failed the LPM table lookup in a prefix
match LFB.
</synopsis>
</specialValue> </specialValue>
<specialValue value="12"> <specialValue value="12">
<name>HopSelectorInvalid</name> <name>HopSelectorInvalid</name>
<synopsis>The HopSelector for the packet is invalid. <synopsis>
HopSelector for the packet is invalid
</synopsis> </synopsis>
</specialValue> </specialValue>
<specialValue value="13"> <specialValue value="13">
<name>NextHopLookupFailed</name> <name>NextHopLookupFailed</name>
<synopsis>The packet failed lookup of the NextHop <synopsis>
table even though the HopSelector is valid. Packet failed lookup of a next hop table even
though HopSelector is valid.
</synopsis> </synopsis>
</specialValue> </specialValue>
<specialValue value="14"> <specialValue value="14">
<name>FragRequired</name> <name>FragRequired</name>
<synopsis>The MTU for outgoing interface is less <synopsis>
than the packet size.</synopsis> Packet fragmentation is required
</synopsis>
</specialValue> </specialValue>
<specialValue value="15"> <specialValue value="15">
<name>MetadataNoMatching</name> <name>MetadataNoMatching</name>
<synopsis>There is no matching when looking up the <synopsis>
metadata dispatch table.</synopsis> There is no matching when looking up the metadata
dispatch table in BasicMetadataDispatch LFB.
</synopsis>
</specialValue> </specialValue>
</specialValues> </specialValues>
</atomic> </atomic>
</metadataDef> </metadataDef>
<metadataDef> <metadataDef>
<name>ValidateErrorID</name> <name>ValidateErrorID</name>
<synopsis>Indicating error type of the packet failed some <synopsis>
validation process.</synopsis> Metadata indicating error types when a packet passes
validation process.
</synopsis>
<metadataID>12</metadataID> <metadataID>12</metadataID>
<atomic> <atomic>
<baseType>uint32</baseType> <baseType>uint32</baseType>
<specialValues> <specialValues>
<specialValue value="0"> <specialValue value="0">
<name>AnyUnrecognizedValidateErrorCase</name> <name>AnyUnrecognizedValidateErrorCase</name>
<synopsis> Any unrecognized validate error case. <synopsis>
Any unrecognized validate error case
</synopsis> </synopsis>
</specialValue> </specialValue>
<specialValue value="1"> <specialValue value="1">
<name>InvalidIPv4PacketSize</name> <name>InvalidIPv4PacketSize</name>
<synopsis>Packet size reported is less than 20 <synopsis>
bytes.</synopsis> Packet length reported by the link layer is less
than 20 bytes.
</synopsis>
</specialValue> </specialValue>
<specialValue value="2"> <specialValue value="2">
<name>NotIPv4Packet</name> <name>NotIPv4Packet</name>
<synopsis>Packet is not IP version 4.</synopsis> <synopsis>Packet is not IP version 4</synopsis>
</specialValue> </specialValue>
<specialValue value="3"> <specialValue value="3">
<name>InvalidIPv4HeaderLengthSize</name> <name>InvalidIPv4HeaderLengthSize</name>
<synopsis>Packet with header length less than <synopsis>
5 words.</synopsis> Packet with header length field in the header
less than 5 words.
</synopsis>
</specialValue> </specialValue>
<specialValue value="4"> <specialValue value="4">
<name>InvalidIPv4LengthFieldSize</name> <name>InvalidIPv4LengthFieldSize</name>
<synopsis>Packet with total length field less than <synopsis>
20 bytes.</synopsis> Packet with total length field in the header less
than 20 bytes.
</synopsis>
</specialValue> </specialValue>
<specialValue value="5"> <specialValue value="5">
<name>InvalidIPv4Checksum</name> <name>InvalidIPv4Checksum</name>
<synopsis>Packet with invalid checksum.</synopsis> <synopsis>Packet with invalid checksum</synopsis>
</specialValue> </specialValue>
<specialValue value="6"> <specialValue value="6">
<name>InvalidIPv4SrcAddr</name> <name>InvalidIPv4SrcAddr</name>
<synopsis>Packet with invalid source address. <synopsis>
Packet with invalid IPv4 source address
</synopsis> </synopsis>
</specialValue> </specialValue>
<specialValue value="7"> <specialValue value="7">
<name>InvalidIPv4DstAddr</name> <name>InvalidIPv4DstAddr</name>
<synopsis>Packet with source address 0.</synopsis> <synopsis>
Packet with invalid IPv4 destination address
</synopsis>
</specialValue> </specialValue>
<specialValue value="8"> <specialValue value="8">
<name>InvalidIPv6PacketSize</name> <name>InvalidIPv6PacketSize</name>
<synopsis>Packet size reported is less than 40 <synopsis>
bytes.</synopsis> Packet size is less than 40 bytes
</synopsis>
</specialValue> </specialValue>
<specialValue value="9"> <specialValue value="9">
<name>NotIPv6Packet</name> <name>NotIPv6Packet</name>
<synopsis>Packet is not IP version 6.</synopsis> <synopsis>Packet is not IP version 6</synopsis>
</specialValue> </specialValue>
<specialValue value="10"> <specialValue value="10">
<name>InvalidIPv6SrcAddr</name> <name>InvalidIPv6SrcAddr</name>
<synopsis>Packet with invalid source address. <synopsis>
Packet with invalid IPv6 source address
</synopsis> </synopsis>
</specialValue> </specialValue>
<specialValue value="11"> <specialValue value="11">
<name>InvalidIPv6DstAddr</name> <name>InvalidIPv6DstAddr</name>
<synopsis>Packet with invalid destination address. <synopsis>
Packet with invalid IPv6 destination address
</synopsis> </synopsis>
</specialValue> </specialValue>
</specialValues> </specialValues>
</atomic> </atomic>
</metadataDef> </metadataDef>
<metadataDef> <metadataDef>
<name>L3PortID</name> <name>L3PortID</name>
<synopsis>ID of L3 port. See the definition in <synopsis>
IPv4NextHopInfoType.</synopsis> Metadata indicating ID of an L3 logical port
</synopsis>
<metadataID>13</metadataID> <metadataID>13</metadataID>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</metadataDef> </metadataDef>
<metadataDef> <metadataDef>
<name>RedirectIndex</name> <name>RedirectIndex</name>
<synopsis>metadata CE sends to RedirectIn LFB for the <synopsis>
associated packet to select output port in the LFB group Metadata that CE sends to RedirectIn LFB, indicating an
output "PktsOut".</synopsis> associated packet a group output port index of the LFB.
</synopsis>
<metadataID>14</metadataID> <metadataID>14</metadataID>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</metadataDef> </metadataDef>
<metadataDef> <metadataDef>
<name>MediaEncapInfoIndex</name> <name>MediaEncapInfoIndex</name>
<synopsis>A search key the packet uses to look up a media <synopsis>
encapsulation table to select its encapsulation media as A search key a packet uses to look up a table in related
well as followed encapsulation LFB.</synopsis> LFBs to select an encapsulation media.
</synopsis>
<metadataID>15</metadataID> <metadataID>15</metadataID>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</metadataDef> </metadataDef>
</metadataDefs> </metadataDefs>
</LFBLibrary> </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
skipping to change at page 41, line 27 skipping to change at page 44, line 27
the library. the library.
5.1.1. EtherPHYCop 5.1.1. EtherPHYCop
EtherPHYCop LFB abstracts an Ethernet interface physical layer with EtherPHYCop LFB abstracts an Ethernet interface physical layer with
media limited to copper. media limited to copper.
5.1.1.1. Data Handling 5.1.1.1. Data Handling
This LFB is the interface to the Ethernet physical media. The LFB This LFB is the interface to the Ethernet physical media. The LFB
handles ethernet frames coming in from or going out of the FE. handles Ethernet frames coming in from or going out of the FE.
Ethernet frames sent and received cover all packets encapsulated with Ethernet frames sent and received cover all packets encapsulated with
different versions of Ethernet protocols, like Ethernet V2, 802.3 different versions of Ethernet protocols, like Ethernet V2, 802.3
RAW, IEEE 802.3/802.2,IEEE 802.3/802.2 SNAP, including packets RAW, IEEE 802.3/802.2,IEEE 802.3/802.2 SNAP, including packets
encapsulated with varieties of LAN techniques based on Ethernet, like encapsulated with varieties of LAN techniques based on Ethernet, like
various VLANs, MACinMAC, etc. Therefore in the XML an EthernetAll various VLANs, MACinMAC, etc. Therefore in the XML an EthernetAll
frame type has been introduced. frame type has been introduced.
Ethernet frames are received from the physical media port and passed Ethernet frames are received from the physical media port and passed
downstream to LFBs such as EtherMACIn via a singleton output known as downstream to LFBs such as EtherMACIn via a singleton output known as
"EtherPHYOut". A 'PHYPortID' metadata, to indicate which physical "EtherPHYOut". A 'PHYPortID' metadata, to indicate which physical
skipping to change at page 43, line 22 skipping to change at page 46, line 22
5.1.2.1. Data Handling 5.1.2.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
some Ethernet physical layer LFB, like an EtherPHYCop LFB, alongside some Ethernet physical layer LFB, like an EtherPHYCop LFB, alongside
with a metadata indicating the physical port ID that the packet with a metadata indicating the physical port ID that the packet
arrived on. arrived on.
The LFB is defined with two separate singleton outputs. All Output The LFB is defined with two separate singleton outputs. All Output
packets are emitted in the original ethernet format received at the packets are emitted in the original Ethernet format received at the
physical port, unchanged, and cover all types of ethernet types. physical port, unchanged, and cover all types of Ethernet types.
The first singleton output is known as "NormalPathOut". It usually The first singleton output is known as "NormalPathOut". It usually
outputs Ethernet packets to some LFB like an EtherClassifier LFB for outputs Ethernet packets to some LFB like an EtherClassifier LFB for
further L3 forwarding process alongside with a PHYPortID metadata further L3 forwarding process alongside with a PHYPortID metadata
indicating which physical port the packet came from. indicating which physical port the packet came from.
The second singleton output is known as "L2BridgingPathOut". The second singleton output is known as "L2BridgingPathOut".
Although the LFB library this document defines is basically to meet Although the LFB library this document defines is basically to meet
typical router functions, it will attempt to be forward compatible typical router functions, it will attempt to be forward compatible
with future router functions. The "L2BridgingPathOut" is defined to with future router functions. The "L2BridgingPathOut" is defined to
skipping to change at page 45, line 32 skipping to change at page 48, line 32
physical port the packet comes from. In some cases, for instance, physical port the packet comes from. In some cases, for instance,
like in a MACinMAC case, a LogicalPortID metadata may be expected to like in a MACinMAC case, a LogicalPortID metadata may be expected to
associate with the Ethernet packet to further indicate which logical associate with the Ethernet packet to further indicate which logical
port the Ethernet packet belongs to. Note that PHYPortID metadata is port the Ethernet packet belongs to. Note that PHYPortID metadata is
always expected while LogicalPortID metadata is optionally expected. always expected while LogicalPortID metadata is optionally expected.
Two output LFB ports are defined. Two output LFB ports are defined.
The first output is a group output port known as "ClassifyOut". The first output is a group output port known as "ClassifyOut".
Types of network layer protocol packets are output to instances of Types of network layer protocol packets are output to instances of
the port group. Because there may be various types of protocol the port group. Because there may be various type of protocol
packets at the output ports, the produced output frame is defined as packets at the output ports, the produced output frame is defined as
arbitrary for the purpose of wide extensibility in the future. arbitrary for the purpose of wide extensibility in the future.
Metadata to be carried along with the packet data is produced at this Metadata to be carried along with the packet data is produced at this
LFB for consumption by downstream LFBs. The metadata passed LFB for consumption by downstream LFBs. The metadata passed
downstream includes PHYPortID, as well as information on Ethernet downstream includes PHYPortID, as well as information on Ethernet
type, source MAC address, destination MAC address and the logical type, source MAC address, destination MAC address and the logical
port ID. .If the original packet is a VLAN packet and contains a VLAN port ID. If the original packet is a VLAN packet and contains a VLAN
ID and a VLAN priority value, then the VLAN ID and the VLAN priority ID and a VLAN priority value, then the VLAN ID and the VLAN priority
value are also carried downstream as metadata. As a result, the VLAN value are also carried downstream as metadata. As a result, the VLAN
ID and priority metadata are defined with the availability of ID and priority metadata are defined with the availability of
"conditional". "conditional".
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 include:
skipping to change at page 47, line 23 skipping to change at page 50, line 23
5.1.4.1. Data Handling 5.1.4.1. Data Handling
This LFB abstracts the process of encapsulating Ethernet headers onto This LFB abstracts the process of encapsulating Ethernet headers onto
received packets. The encapsulation is based on passed metadata. received packets. The encapsulation is based on passed metadata.
The LFB is expected to receive IPv4 and IPv6 packets, via a singleton The LFB is expected to receive IPv4 and IPv6 packets, via a singleton
input port known as "EncapIn" which may be connected to an upstream input port known as "EncapIn" which may be connected to an upstream
LFB like an IPv4NextHop, an IPv6NextHop, BasicMetadataDispatch, or LFB like an IPv4NextHop, an IPv6NextHop, BasicMetadataDispatch, or
any LFB which requires to output packets for Ethernet encapsulation. any LFB which requires to output packets for Ethernet encapsulation.
The LFB always expects from upstream LFBs the MediaEncapInfoIndex The LFB always expects from upstream LFBs the
metadata which is used as a search key to lookup the Encapsulation MedTableiaEncapInfoIndex metadata which is used as a search key to
Table. An input packet may also optionally receive a VLAN priority lookup the encapsulation table EncapTable by the search key matching
metadata, indicating that the packet is originally with a priority the table index. An input packet may also optionally receive a VLAN
value. The priority value will be loaded back to the packet when priority metadata, indicating that the packet is originally with a
encapsulating. The optional VLAN priority metadata is defined with a priority value. The priority value will be loaded back to the packet
default value 0. when encapsulating. The optional VLAN priority metadata is defined
with a default value 0.
Two singleton output LFB ports are defined. Two singleton output LFB ports are defined.
The first singleton output known as "SuccessOut". Upon a successful The first singleton output known as "SuccessOut". Upon a successful
table lookup, the destination and source MAC addresses, and the table lookup, the destination and source MAC addresses, and the
logical media port (L2PortID) are found in the matching table entry. logical media port (L2PortID) are found in the matching table entry.
The CE may set the VlanID in case VLANs are used. By default the The CE may set the VlanID in case VLANs are used. By default the
table entry for VlanID of 0 is used as per IEEE rules. Whatever the table entry for VlanID of 0 is used as per IEEE rules. Whatever the
value of VlanID is, if the input metadata VlanPriority is non-zero, value of VlanID is, if the input metadata VlanPriority is non-zero,
the packet will have a VLAN tag. If the VlanPriority and the VlanID the packet will have a VLAN tag. If the VlanPriority and the VlanID
skipping to change at page 48, line 18 skipping to change at page 51, line 21
The upstream LFB may be programmed by the CE to pass along a The upstream LFB may be programmed by the CE to pass along a
MediaEncapInfoIndex that does not exist in the EncapTable. That is MediaEncapInfoIndex that does not exist in the EncapTable. That is
to allow for resolution of the L2 headers, if needed, to be made at to allow for resolution of the L2 headers, if needed, to be made at
the L2 encapsulation level in this case (Ethernet) via ARP, or ND (or the L2 encapsulation level in this case (Ethernet) via ARP, or ND (or
other methods depending on the link layer technology) when a table other methods depending on the link layer technology) when a table
miss occurs. miss occurs.
For neighbor L2 header resolution(table miss exception), the For neighbor L2 header resolution(table miss exception), the
processing LFB may pass this packet to the CE via the redirect LFB or processing LFB may pass this packet to the CE via the redirect LFB or
FE software or another LFB instance for further resolution. In such FE software or another LFB instance for further resolution. In such
a case the metadata NexthopIPv4Addr or NexthopIPv6Addr generated by a case the metadata NextHopIPv4Addr or NextHopIPv6Addr generated by
Nexthop LFB is also passed to the exception handling. Such an IP next hop LFB is also passed to the exception handling. Such an IP
address could be used to do activities such as ARP or ND by the address could be used to do activities such as ARP or ND by the
handler it is passed to. handler it is passed to.
The result of the L2 resolution is to update the EncapTable as well The result of the L2 resolution is to update the EncapTable as well
as the Nexthop LFB so subsequent packets do not fail EncapTable as the next hop LFB so subsequent packets do not fail EncapTable
lookup. The EtherEncap LFB does not make any assumptions of how the lookup. The EtherEncap LFB does not make any assumptions of how the
EncapTable is updated by the CE (or whether ARP/ND is used EncapTable is updated by the CE (or whether ARP/ND is used
dynamically or static maps exist). dynamically or static maps exist).
Downstream LFB instances could be either an EtherMACOut type or a Downstream LFB instances could be either an EtherMACOut type or a
BasicMetadataDispatch type. If the final packet L2 processing is BasicMetadataDispatch type. If the final packet L2 processing is
possible to be on per-media-port basis or resides on a different FE possible to be on per-media-port basis or resides on a different FE
or in cases where L2 header resolution is needed, then the model or in cases where L2 header resolution is needed, then the model
makes sense to use a BasicMetadataDispatch LFB to fanout to different makes sense to use a BasicMetadataDispatch LFB to fan out to
LFB instances. If there is a direct egress port point, then the different LFB instances. If there is a direct egress port point,
model makes sense to have a downstream LFB instance being an then the model makes sense to have a downstream LFB instance being an
EtherMACOut. EtherMACOut.
5.1.4.2. Components 5.1.4.2. Components
This LFB has only one component named EncapTable which is defined as This LFB has only one component named EncapTable which is defined as
an array. Each row of the array is a struct containing the an array. Each row of the array is a struct containing the
destination MAC address, the source MAC address, the VLAN ID with a destination MAC address, the source MAC address, the VLAN ID with a
default value of zero and the output logical L2 port ID. default value of zero and the output logical L2 port ID.
5.1.4.3. Capabilities 5.1.4.3. Capabilities
skipping to change at page 56, line 32 skipping to change at page 59, line 32
This LFB abstracts the process of selecting ipv4 next hop action. This LFB abstracts the process of selecting ipv4 next hop action.
5.3.2.1. Data Handling 5.3.2.1. Data Handling
The LFB abstracts the process of next hop information application to The LFB abstracts the process of next hop information application to
IPv4 packets. It receives an IPv4 packet with an associated next hop IPv4 packets. It receives an IPv4 packet with an associated next hop
identifier (HopSelector), and uses the identifier as a table index to identifier (HopSelector), and uses the identifier as a table index to
look up a next hop table to find an appropriate LFB output port. look up a next hop table to find an appropriate LFB output port.
The LFB is expected to receive unicast IPv4 packets, via a singleton The LFB is expected to receive unicast IPv4 packets, via a singleton
input known as "PcktsIn" along with a HopSelector metadata which is input known as "PktsIn" along with a HopSelector metadata which is
used as a table index to lookup the NextHop table. The data used as a table index to lookup the NextHop table. The data
processing involves the forwarding TTL decrement and IP checksum processing involves the forwarding TTL decrement and IP checksum
recalculation. recalculation.
Two output LFB ports are defined. Two output LFB ports are defined.
The first output is a group output port known as "SuccessOut". On The first output is a group output port known as "SuccessOut". On
successful data processing the packet is sent out an LFB-port from successful data processing the packet is sent out an LFB-port from
within the LFB port group as selected by the LFBOutputSelectIndex within the LFB port group as selected by the LFBOutputSelectIndex
value of the matched table entry. The packet is sent to a downstream value of the matched table entry. The packet is sent to a downstream
LFB alongside with the L3PortID and MediaEncapInfoIndex metadata. LFB alongside with the L3PortID and MediaEncapInfoIndex metadata.
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 include:
o The HopSelector for the packet is invalid. o The HopSelector for the packet is invalid.
o The packet failed lookup of the NextHop table even though the o The packet failed lookup of the next hop table even though the
HopSelector is valid. HopSelector is valid.
o The MTU for outgoing interface is less than the packet size. o The MTU for outgoing interface is less than the packet size.
Downstream LFB instances could be either a BasicMetadataDispatch type Downstream LFB instances could be either a BasicMetadataDispatch type
(Section 5.5.1), used to fanout to different LFB instances or a media (Section 5.5.1), used to fan out to different LFB instances or a
encapsulation related type, such as an EtherEncap type or a media encapsulation related type, such as an EtherEncap type or a
RedirectOut type(Section 5.4.2). For example, if there are Ethernet RedirectOut type(Section 5.4.2). For example, if there are Ethernet
and other tunnel Encapsulation, then a BasicMetadataDispatch LFB can and other tunnel Encapsulation, then a BasicMetadataDispatch LFB can
use the L3PortID metadata (Section 5.3.2.2) to dispatch packets to use the L3PortID metadata (Section 5.3.2.2) to dispatch packets to
different Encapsulator. different encapsulator.
5.3.2.2. Components 5.3.2.2. Components
This LFB has only one component named IPv4NextHopTable which is This LFB has only one component named IPv4NextHopTable which is
defined as an array. The HopSelector received is used to match the defined as an array. The HopSelector received is used to match the
array index of IPv4NextHopTable to find out a row of the table as the array index of IPv4NextHopTable to find out a row of the table as the
next hop information result. Each row of the array is a struct next hop information result. Each row of the array is a struct
containing: containing:
o The L3PortID, which is the ID of the Logical Output Port that is o The L3PortID, which is the ID of the Logical Output Port that is
passed onto the downstream LFB instance. This ID indicates what passed onto the downstream LFB instance. This ID indicates what
port to the neighbor is as defined by L3. Usually this ID is used port to the neighbor is as defined by L3. Usually this ID is used
for the NextHop LFB to distinguish packets that need different L2 for the next hop LFB to distinguish packets that need different L2
encapsulating. For instance, some packets may require general encapsulating. For instance, some packets may require general
Ethernet encapsulation while others may require various types of Ethernet encapsulation while others may require various types of
tunnel encapsulations. In such case, different L3PortIDs are tunnel encapsulations. In such case, different L3PortIDs are
assigned to the packets and are as metadata passed to downstream assigned to the packets and are as metadata passed to downstream
LFB. A BasicMetadataDispatch LFB(Section 5.5.1) may have to be LFB. A BasicMetadataDispatch LFB(Section 5.5.1) may have to be
applied as the downstream LFB so as to dispatch packets to applied as the downstream LFB so as to dispatch packets to
different encapsulation LFB insatnces according to the L3PortIDs. different encapsulation LFB instances according to the L3PortIDs.
o MTU, the Maximum Transmission Unit for the outgoing port. o MTU, the Maximum Transmission Unit for the outgoing port.
o NextHopIPAddr, the IPv4 next hop Address. o NextHopIPAddr, the IPv4 next hop address.
o MediaEncapInfoIndex, the index we pass onto the downstream o MediaEncapInfoIndex, the index we pass onto the downstream
encapsulation LFB instance and that is used there as a search key encapsulation LFB instance and that is used there as a search key
to lookup a table (typically media encapsulation related) for to lookup a table (typically media encapsulation related) for
further encapsulation information. Note that an encapsulation LFB further encapsulation information. The search key looks up the
instance may not directly follow the NextHop LFB, but the index is table by matching the table index.Note that an encapsulation LFB
passed as a metadata associated, as such an encapsulation LFB instance may not directly follow the next hop LFB, but the index
instance even further downstream to the NextHop LFB can still use is passed as a metadata associated, as such an encapsulation LFB
instance even further downstream to the next hop LFB can still use
the index. In some cases, depending on implementation, the CE may the index. In some cases, depending on implementation, the CE may
set the MediaEncapInfoIndex passed downstream to a value that will set the MediaEncapInfoIndex passed downstream to a value that will
fail lookup when it gets to a target encapsulation LFB; such a fail lookup when it gets to a target encapsulation LFB; such a
lookup failure at that point is an indication that further lookup failure at that point is an indication that further
resolution is needed. For an example of this approach refer to resolution is needed. For an example of this approach refer to
Section 7.2 which talks about ARP and mentions this approach. Section 7.2 which talks about ARP and mentions this approach.
o LFBOutputSelectIndex, the LFB Group output port index to select o LFBOutputSelectIndex, the LFB Group output port index to select
downstream LFB port. It is a 1-to-1 mapping with FEObject LFB's downstream LFB port. It is a 1-to-1 mapping with FEObject LFB's
table LFBTopology (See [RFC5812]) component FromPortIndex table LFBTopology (See [RFC5812]) component FromPortIndex
skipping to change at page 60, line 30 skipping to change at page 63, line 30
This LFB abstracts the process of selecting IPv6 next hop action. This LFB abstracts the process of selecting IPv6 next hop action.
5.3.4.1. Data Handling 5.3.4.1. Data Handling
The LFB abstracts the process of next hop information application to The LFB abstracts the process of next hop information application to
IPv6 packets. It receives an IPv6 packet with an associated next hop IPv6 packets. It receives an IPv6 packet with an associated next hop
identifier (HopSelector), and uses the identifier to look up a next identifier (HopSelector), and uses the identifier to look up a next
hop table to find an appropriate output port from the LFB. hop table to find an appropriate output port from the LFB.
The LFB is expected to receive unicast IPv6 packets, via a singleton The LFB is expected to receive unicast IPv6 packets, via a singleton
input known as "PcktsIn" along with a HopSelector metadata which is input known as "PktsIn" along with a HopSelector metadata which is
used as a table index to lookup the NextHop table. used as a table index to lookup the next hop table.
Two output LFB ports are defined. Two output LFB ports are defined.
The first output is a group output port known as "SuccessOut". On The first output is a group output port known as "SuccessOut". On
successful data processing the packet is sent out an LFB port from successful data processing the packet is sent out an LFB port from
within the LFB port group as selected by the LFBOutputSelectIndex within the LFB port group as selected by the LFBOutputSelectIndex
value of the matched table entry. The packet is sent to a downstream value of the matched table entry. The packet is sent to a downstream
LFB alongside with the L3PortID and MediaEncapInfoIndex metadata. LFB alongside with the L3PortID and MediaEncapInfoIndex metadata.
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 include:
o The HopSelector for the packet is invalid. o The HopSelector for the packet is invalid.
o The packet failed lookup of the NextHop table even though the o The packet failed lookup of the next hop table even though the
HopSelector is valid. HopSelector is valid.
o The MTU for outgoing interface is less than the packet size. o The MTU for outgoing interface is less than the packet size.
Downstream LFB instances could be either a BasicMetadataDispatch Downstream LFB instances could be either a BasicMetadataDispatch
type, used to fanout to different LFB instances or a media type, used to fan out to different LFB instances or a media
encapsulatation related type, such as an EtherEncap type or a encapsulatation related type, such as an EtherEncap type or a
RedirectOut type. For example, when the downstream LFB is RedirectOut type. For example, when the downstream LFB is
BasicMetadataDispatch, and there exist Ethernet and other tunnel BasicMetadataDispatch, and there exist Ethernet and other tunnel
Encapsulation downstream from BasicMetadataDispatch, then the Encapsulation downstream from BasicMetadataDispatch, then the
BasicMetadataDispatch LFB can use the L3PortID metadata (See section BasicMetadataDispatch LFB can use the L3PortID metadata (See section
below) to dispatch packets to the different Encapsulator LFBs. below) to dispatch packets to the different encapsulator LFBs.
5.3.4.2. Components 5.3.4.2. Components
This LFB has only one component named IPv6NextHopTable which is This LFB has only one component named IPv6NextHopTable which is
defined as an array. The array index of IPv6NextHopTable is used for defined as an array. The array index of IPv6NextHopTable is used for
a HopSelector to find out a row of the table as the next hop a HopSelector to find out a row of the table as the next hop
information. Each row of the array is a struct containing: information. Each row of the array is a struct containing:
o The L3PortID, which is the ID of the Logical Output Port that is o The L3PortID, which is the ID of the Logical Output Port that is
passed onto the downstream LFB instance. This ID indicates what passed onto the downstream LFB instance. This ID indicates what
port to the neighbor is as defined by L3. Usually this ID is used port to the neighbor is as defined by L3. Usually this ID is used
for the NextHop LFB to distinguish packets that need different L2 for the next hop LFB to distinguish packets that need different L2
encapsulating. For instance, some packets may require general encapsulating. For instance, some packets may require general
Ethernet encapsulation while others may require various types of Ethernet encapsulation while others may require various types of
tunnel encapsulations. In such case, different L3PortIDs are tunnel encapsulations. In such case, different L3PortIDs are
assigned to the packets and are as metadata passed to downstream assigned to the packets and are as metadata passed to downstream
LFB. A BasicMetadataDispatch LFB(Section 5.5.1) may have to be LFB. A BasicMetadataDispatch LFB(Section 5.5.1) may have to be
applied as the downstream LFB so as to dispatch packets to applied as the downstream LFB so as to dispatch packets to
different encapsulation LFB instances according to the L3PortIDs. different encapsulation LFB instances according to the L3PortIDs.
o MTU, the Maximum Transmission Unit for the outgoing port. o MTU, the Maximum Transmission Unit for the outgoing port.
o NextHopIPAddr, the IPv6 next hop Address. o NextHopIPAddr, the IPv6 next hop address.
o MediaEncapInfoIndex, the index we pass onto the downstream o MediaEncapInfoIndex, the index we pass onto the downstream
encapsulation LFB instance and that is used there as a search key encapsulation LFB instance and that is used there as a search key
to lookup a table (typically media encapsulation related) for to lookup a table (typically media encapsulation related) for
further encapsulation information. Note that an encapsulation LFB further encapsulation information. The saearch key looks up the
instance may not directly follow the NextHop LFB, but the index is table by matching the table index. Note that an encapsulation LFB
passed as a metadata associated, as such an encapsulation LFB instance may not directly follow the next hop LFB, but the index
instance even further downstream to the NextHop LFB can still use is passed as a metadata associated, as such an encapsulation LFB
instance even further downstream to the next hop LFB can still use
the index. In some cases, depending on implementation, the CE may the index. In some cases, depending on implementation, the CE may
set the MediaEncapInfoIndex passed downstream to a value that will set the MediaEncapInfoIndex passed downstream to a value that will
fail lookup when it gets to a target encapsulation LFB; such a fail lookup when it gets to a target encapsulation LFB; such a
lookup failure at that point is an indication that further lookup failure at that point is an indication that further
resolution is needed. For an example of this approach refer to resolution is needed. For an example of this approach refer to
Section 7.2 which talks about ARP and mentions this approach. Section 7.2 which talks about ARP and mentions this approach.
o LFBOutputSelectIndex, the LFB Group output port index to select o LFBOutputSelectIndex, the LFB Group output port index to select
downstream LFB port. It is a 1-to-1 mapping with FEObject LFB's downstream LFB port. It is a 1-to-1 mapping with FEObject LFB's
table LFBTopology (See [RFC5812]) component FromPortIndex table LFBTopology (See [RFC5812]) component FromPortIndex
skipping to change at page 64, line 32 skipping to change at page 67, line 34
The BasicMetadataDispatch LFB is defined to abstract the process in The BasicMetadataDispatch LFB is defined to abstract the process in
which a packet is dispatched to some output path based on its which a packet is dispatched to some output path based on its
associated metadata value. associated metadata value.
5.5.1.1. Data Handling 5.5.1.1. Data Handling
The BasicMetadataDispatch has only one singleton input known as The BasicMetadataDispatch has only one singleton input known as
"PktsIn". Every input packet should be associated with a metadata "PktsIn". Every input packet should be associated with a metadata
that will be used by the LFB to do the dispatch. This LFB contains a that will be used by the LFB to do the dispatch. This LFB contains a
Metadata ID component a dispatch table named MetadataDispatchTable, metadata ID and a dispatch table named MetadataDispatchTable, all
all configured by the CE. The Metadata ID specifies which metadata configured by the CE. The metadata ID specifies which metadata is to
is to be used for dispatching packets. The MetadataDispatchTable be used for dispatching packets. The MetadataDispatchTable contains
contains entries of a Metadata value and an OutputIndex, specifying entries of a metadata value and an OutputIndex, specifying that the
that the packet with the metadata value must go out from the LFB packet with the metadata value must go out from the LFB group output
group output port instance with the OutputIndex. port instance with the OutputIndex.
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
skipping to change at page 65, line 31 skipping to change at page 68, line 31
types supported may be used to dispatch packets. types supported may be used to dispatch packets.
5.5.1.2. Components 5.5.1.2. Components
This LFB has two components. One component is MetadataID and the This LFB has two components. One component is MetadataID and the
other is MetadataDispatchTable. Each row entry of the dispatch table other is MetadataDispatchTable. Each row entry of the dispatch table
is a struct containing metadata value and the OutputIndex. Note that is a struct containing metadata value and the OutputIndex. Note that
currently, the metadata value is only allowed to be 32-bits integer. currently, the metadata value is only allowed to be 32-bits integer.
The metadata value is also defined as a content key for the table. The metadata value is also defined as a content key for the table.
The concept of content key is a searching key for tables which is The concept of content key is a searching key for tables which is
defined in the ForCES FE Model [RFC5812]. See this document and also defined in the ForCES FE Model [RFC5812]. With the content key, CE
the ForCES Protocol [RFC5810] for more details on the definition and can manipulate the table by means of a specific metadata value rather
use of a content key. than by the table index only. See [RFC5812] document and also the
ForCES Protocol [RFC5810] for more details on the definition and use
of a content key.
5.5.1.3. Capabilities 5.5.1.3. Capabilities
This LFB does not have a list of capabilities This LFB does not have a list of capabilities
5.5.1.4. Events 5.5.1.4. Events
This LFB does not have any events specified. This LFB does not have any events specified.
5.5.2. GenericScheduler 5.5.2. GenericScheduler
skipping to change at page 66, line 11 skipping to change at page 69, line 17
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 scheduler LFB to further
construct more complex scheduler LFBs by means of inheritance as construct more complex scheduler LFBs by means of inheritance as
described in [RFC5812]. described in [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. instance may be connected to different upstream LFB output. Inside
the LFB, it is abstracted that each input port instance is connected
Multiple queues reside at the input side, with every input LFB port to a queue, and the queue is marked with a queue ID whose value is
instance connected to one queue. Every queue is marked with a queue exactly the same as the index of corresponding group input port
ID, and the queue ID is exactly the same as the index of instance. Scheduling disciplines are applied to all queues and also
corresponding input port instance. Scheduling disciplines are all packets in the queues.The group input port property
applied to all queues and also all packets in the queues. PortGroupLimits in ObjectLFB as defined by ForCES FE model[RFC5810]
provides means for the CE to query the capability of total queue
numbers the scheduler supports. The CE can then decide how many
queues it may use for a scheduling application.
Scheduled packets are output from a singleton output port of the LFB Scheduled packets are output from a singleton output port of the LFB
knows as "PktsOut" with no corresponding metadata. knows as "PktsOut" with no corresponding metadata.
More complex scheduler LFBs may be defined with more complex More complex scheduler LFBs may be defined with more complex
scheduling disciplines by succeeding this LFB. For instance, a scheduling disciplines by succeeding this LFB. For instance, a
priority scheduler LFB may be defined by inheriting this LFB and priority scheduler LFB may be defined by inheriting this LFB and
defining a component to indicate priorities for all input queues. defining a component to indicate priorities for all input queues.
5.5.2.2. Components 5.5.2.2. Components
The QueueCount component is defined to specify the number of queues
to be scheduled.
The SchedulingDiscipline component is for the CE to specify a The SchedulingDiscipline component is for the CE to specify a
scheduling discipline to the LFB. Currently defined scheduling scheduling discipline to the LFB. Currently defined scheduling
disciplines only include Round Robin (RR) strategy. The default disciplines only include Round Robin (RR) strategy. The default
scheduling discipline is RR then. scheduling discipline is RR then.
The QueueStats component is defined to allow CE to query every queue The QueueStats component is defined to allow CE to query every queue
status of the scheduler. It is an array component and each row of status of the scheduler. It is an array component and each row of
the array is a struct containing a queue ID. Currently defined queue the array is a struct containing a queue ID. Currently defined queue
status includes the queue depth in packets and the queue depth in status includes the queue depth in packets and the queue depth in
bytes. Using the queue ID as the index, the CE can query every queue bytes. Using the queue ID as the index, the CE can query every queue
skipping to change at page 68, 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>The LFB describes an Ethernet port abstracted at <synopsis>
physical layer.It limits its physical media to copper. The EtherPHYCop LFB describes an Ethernet interface
Multiple virtual PHYs isn't supported in this LFB version. abstracted at physical layer. It limits the physical media
</synopsis> to copper.
<version>1.0</version> </synopsis>
<inputPorts> <version>1.0</version>
<inputPort> <inputPorts>
<name>EtherPHYIn</name> <inputPort>
<synopsis>The input port of the EtherPHYCop LFB. It <name>EtherPHYIn</name>
expects any kind of Ethernet frame.</synopsis> <synopsis>
<expectation> The input port of the EtherPHYCop LFB. It expects any
<frameExpected> type of Ethernet frame.
<ref>EthernetAll</ref> </synopsis>
</frameExpected> <expectation>
</expectation> <frameExpected>
</inputPort> <ref>EthernetAll</ref>
</inputPorts> </frameExpected>
<outputPorts> </expectation>
<outputPort> </inputPort>
<name>EtherPHYOut</name> </inputPorts>
<synopsis>The output port of the EtherPHYCop LFB. It <outputPorts>
can produce any kind of Ethernet frame and along with <outputPort>
the frame passes the ID of the Physical Port as <name>EtherPHYOut</name>
metadata to be used by the next LFBs.</synopsis> <synopsis>
<product> The output port of the EtherPHYCop LFB. The output
<frameProduced> packet has the same Ethernet frame type with the
<ref>EthernetAll</ref> input packet, associated with a metadata indicating
</frameProduced> the ID of the physical port.
<metadataProduced> </synopsis>
<ref>PHYPortID</ref> <product>
</metadataProduced> <frameProduced>
</product> <ref>EthernetAll</ref>
</outputPort> </frameProduced>
</outputPorts> <metadataProduced>
<components> <ref>PHYPortID</ref>
<component componentID="1" access="read-only"> </metadataProduced>
<name>PHYPortID</name> </product>
<synopsis>The ID of the physical port that this LFB
handles.</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2" access="read-write">
<name>AdminStatus</name>
<synopsis>Admin status of the LFB</synopsis>
<typeRef>PortStatusValues</typeRef>
<defaultValue>2</defaultValue>
</component>
<component componentID="3" access="read-only">
<name>OperStatus</name>
<synopsis>Operational status of the LFB.</synopsis>
<typeRef>PortStatusValues</typeRef>
</component>
<component componentID="4" access="read-write">
<name>AdminLinkSpeed</name>
<synopsis>The link speed that the admin has requested.
</synopsis>
<typeRef>LANSpeedType</typeRef>
<defaultValue>LAN_SPEED_AUTO</defaultValue>
</component>
<component componentID="5" access="read-only">
<name>OperLinkSpeed</name>
<synopsis>The actual operational link speed.</synopsis>
<typeRef>LANSpeedType</typeRef>
</component>
<component componentID="6" access="read-write">
<name>AdminDuplexMode</name>
<synopsis>The duplex mode that the admin has requested.
</synopsis>
<typeRef>DuplexType</typeRef>
<defaultValue>Auto</defaultValue>
</component>
<component componentID="7" access="read-only">
<name>OperDuplexMode</name>
<synopsis>The actual duplex mode.</synopsis>
<typeRef>DuplexType</typeRef>
</component>
<component componentID="8" access="read-only">
<name>CarrierStatus</name>
<synopsis>The status of the Carrier. Whether the port
is linked with an operational connector.</synopsis>
<typeRef>boolean</typeRef>
<defaultValue>false</defaultValue>
</component>
</components>
<capabilities>
<capability componentID="30">
<name>SupportedLinkSpeed</name>
<synopsis>Supported Link Speeds</synopsis>
<array>
<typeRef>LANSpeedType</typeRef>
</array>
</capability>
<capability componentID="31">
<name>SupportedDuplexMode</name>
<synopsis>Supported Duplex Modes</synopsis>
<array>
<typeRef>DuplexType</typeRef>
</array>
</capability>
</capabilities>
<events baseID="60">
<event eventID="1">
<name>PHYPortStatusChanged</name>
<synopsis>When the status of the Physical port is
changed,the LFB sends the new status.</synopsis>
<eventTarget>
<eventField>OperStatus</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>OperStatus</eventField>
</eventReport>
</eventReports>
</event>
<event eventID="2">
<name>LinkSpeedChanged</name>
<synopsis>When the operational speed of the link
is changed, the LFB sends the new operational link
speed.</synopsis>
<eventTarget>
<eventField>OperLinkSpeed</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>OperLinkSpeed</eventField>
</eventReport>
</eventReports>
</event>
<event eventID="3">
<name>DuplexModeChanged</name>
<synopsis>When the operational duplex mode
is changed, the LFB sends the new operational mode.
</synopsis>
<eventTarget>
<eventField>OperDuplexMode</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>OperDuplexMode</eventField>
</eventReport>
</eventReports>
</event>
</events>
</LFBClassDef>
<LFBClassDef LFBClassID="4">
<name>EtherMACIn</name>
<synopsis>An LFB abstracts an Ethernet port at MAC data link
layer. It specifically describes Ethernet processing functions
like MAC address locality check, deciding if the Ethernet
packets should be bridged, provide Ethernet layer flow control,
etc.Multiple virtual MACs isn't supported in this LFB
version.</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort group="false">
<name>EtherPktsIn</name>
<synopsis>The input port of the EtherMACIn. It
expects any kind of Ethernet frame.</synopsis>
<expectation>
<frameExpected>
<ref>EthernetAll</ref>
</frameExpected>
<metadataExpected>
<ref>PHYPortID</ref>
</metadataExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort group="false">
<name>NormalPathOut</name>
<synopsis>The normal output port of the EtherMACIn.
It can produce any kind of Ethernet frame and along
with the frame passes the ID of the Physical Port as
metadata to be used by the next LFBs.</synopsis>
<product>
<frameProduced>
<ref>EthernetAll</ref>
</frameProduced> </outputPort>
<metadataProduced> </outputPorts>
<ref>PHYPortID</ref> <components>
</metadataProduced> <component componentID="1" access="read-only">
</product> <name>PHYPortID</name>
</outputPort> <synopsis>
<outputPort> The identification of the physical port
<name>L2BridgingPathOut</name> </synopsis>
<synopsis>The Bridging Output Port of the EtherMACIn. <typeRef>uint32</typeRef>
It can produce any kind of Ethernet frame and along </component>
with the frame passes the ID of the Physical Port as <component componentID="2" access="read-write">
metadata to be used by the next LFBs.</synopsis> <name>AdminStatus</name>
<product> <synopsis>
<frameProduced> The port status administratively requested
<ref>EthernetAll</ref> </synopsis>
</frameProduced> <typeRef>PortStatusType</typeRef>
<metadataProduced> <defaultValue>2</defaultValue>
<ref>PHYPortID</ref> </component>
</metadataProduced> <component componentID="3" access="read-only">
</product> <name>OperStatus</name>
</outputPort> <synopsis>
</outputPorts> The actual operational status of the port
<components> </synopsis>
<component componentID="1" access="read-write"> <typeRef>PortStatusType</typeRef>
<name>AdminStatus</name> </component>
<synopsis>Admin status of the port</synopsis> <component componentID="4" access="read-write">
<typeRef>PortStatusValues</typeRef> <name>AdminLinkSpeed</name>
<defaultValue>2</defaultValue> <synopsis>
</component> The port link speed administratively requested
<component componentID="2" access="read-write"> </synopsis>
<name>LocalMACAddresses</name> <typeRef>LANSpeedType</typeRef>
<synopsis>Local Mac addresses</synopsis> <defaultValue>LAN_SPEED_AUTO</defaultValue>
<array> </component>
<typeRef>IEEEMAC</typeRef> <component componentID="5" access="read-only">
</array> <name>OperLinkSpeed</name>
</component> <synopsis>
<component componentID="3" access="read-write"> The actual operational link speed of the port
<name>L2BridgingPathEnable</name> </synopsis>
<synopsis>Is the LFB doing L2 Bridging?</synopsis> <typeRef>LANSpeedType</typeRef>
<typeRef>boolean</typeRef> </component>
<defaultValue>false</defaultValue> <component componentID="6" access="read-write">
</component> <name>AdminDuplexMode</name>
<component componentID="4" access="read-write"> <synopsis>
<name>PromiscuousMode</name> The port duplex mode administratively requested
<synopsis>Is the LFB in Promiscuous Mode?</synopsis> </synopsis>
<typeRef>boolean</typeRef> <typeRef>DuplexType</typeRef>
<defaultValue>false</defaultValue> <defaultValue>Auto</defaultValue>
</component> </component>
<component componentID="5" access="read-write"> <component componentID="7" access="read-only">
<name>TxFlowControl</name> <name>OperDuplexMode</name>
<synopsis>Transmit flow control</synopsis> <synopsis>
<typeRef>boolean</typeRef> The actual operational duplex mode of the port
<defaultValue>false</defaultValue> </synopsis>
</component> <typeRef>DuplexType</typeRef>
<component componentID="6" access="read-write"> </component>
<name>RxFlowControl</name> <component componentID="8" access="read-only">
<synopsis>Receive flow control</synopsis> <name>CarrierStatus</name>
<typeRef>boolean</typeRef> <synopsis>The carrier status of the port </synopsis>
<defaultValue>false</defaultValue> <typeRef>boolean</typeRef>
</component> <defaultValue>false</defaultValue>
<component componentID="7" access="read-reset"> </component>
<name>MACInStats</name> </components>
<synopsis>MACIn statistics</synopsis> <capabilities>
<typeRef>MACInStatsType</typeRef> <capability componentID="30">
</component> <name>SupportedLinkSpeed</name>
</components> <synopsis>
</LFBClassDef> A list of link speeds the port supports
<LFBClassDef LFBClassID="5"> </synopsis>
<name>EtherClassifier</name> <array>
<synopsis>This LFB abstracts the process to decapsulate <typeRef>LANSpeedType</typeRef>
Ethernet packets and classify the data packets into </array>
various network layer data packets according to information </capability>
included in the Ethernet packets headers.</synopsis> <capability componentID="31">
<version>1.0</version> <name>SupportedDuplexMode</name>
<inputPorts> <synopsis>
<inputPort> A list of duplex modes the port supports
<name>EtherPktsIn</name> </synopsis>
<synopsis>Input port for data packet.</synopsis> <array>
<expectation> <typeRef>DuplexType</typeRef>
<frameExpected> </array>
<ref>EthernetAll</ref> </capability>
</frameExpected> </capabilities>
<metadataExpected> <events baseID="60">
<ref>PHYPortID</ref> <event eventID="1">
<ref dependency="optional" defaultValue="0"> <name>PHYPortStatusChanged</name>
LogicalPortID</ref> <synopsis>
</metadataExpected> An event reports change on operational status of the
</expectation> physical port.
</inputPort> </synopsis>
</inputPorts> <eventTarget>
<outputPorts> <eventField>OperStatus</eventField>
<outputPort group="true"> </eventTarget>
<name>ClassifyOut</name> <eventChanged/>
<synopsis>Output port for classification.</synopsis> <eventReports>
<product> <eventReport>
<frameProduced> <eventField>OperStatus</eventField>
<ref>Arbitrary</ref>
</frameProduced> </eventReport>
<metadataProduced> </eventReports>
<ref>PHYPortID</ref> </event>
<ref>SrcMAC</ref> <event eventID="2">
<ref>DstMAC</ref> <name>LinkSpeedChanged</name>
<ref>EtherType</ref> <synopsis>
<ref availability="conditional">VlanID</ref> An event reports change on operational link speed of
<ref availability="conditional">VlanPriority</ref> the physical port.
</metadataProduced> </synopsis>
</product> <eventTarget>
</outputPort> <eventField>OperLinkSpeed</eventField>
</outputPorts> </eventTarget>
<components> <eventChanged/>
<component access="read-write" componentID="1"> <eventReports>
<name>EtherDispatchTable</name> <eventReport>
<synopsis>Ether classify dispatch table</synopsis> <eventField>OperLinkSpeed</eventField>
<typeRef>EtherDispatchTableType</typeRef> </eventReport>
</component> </eventReports>
<component access="read-write" componentID="2"> </event>
<name>VlanInputTable</name> <event eventID="3">
<synopsis>Vlan input table</synopsis> <name>DuplexModeChanged</name>
<typeRef>VlanInputTableType</typeRef> <synopsis>
</component> An event reports change on operational duplex mode of
<component access="read-reset" componentID="3"> the physical port.
<name>EtherClassifyStats</name> </synopsis>
<synopsis>Ether classify statistic table</synopsis> <eventTarget>
<typeRef>EtherClassifyStatsTableType</typeRef> <eventField>OperDuplexMode</eventField>
</component> </eventTarget>
</components> <eventChanged/>
<eventReports>
<eventReport>
<eventField>OperDuplexMode</eventField>
</eventReport>
</eventReports>
</event>
</events>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="6"> <LFBClassDef LFBClassID="4">
<name>EtherEncap</name> <name>EtherMACIn</name>
<synopsis>This LFB abstracts the process to encapsulate IP <synopsis>
packets to Ethernet packets according to the L2 information. EtherMACIn LFB abstracts an Ethernet port at MAC data link
</synopsis> layer. This LFB describes Ethernet processing functions
<version>1.0</version> like MAC address locality check, deciding if the Ethernet
<inputPorts> packets should be bridged, providing Ethernet layer flow
<inputPort group="false"> control, etc.
<name>EncapIn</name> </synopsis>
<synopsis>A Single Packet Input</synopsis> <version>1.0</version>
<expectation> <inputPorts>
<frameExpected> <inputPort group="false">
<ref>IPv4</ref> <name>EtherPktsIn</name>
<ref>IPv6</ref> <synopsis>
</frameExpected> The input port of the EtherMACIn LFB. It expects any
<metadataExpected> type of Ethernet frame.
<ref>MediaEncapInfoIndex</ref> </synopsis>
<ref dependency="optional" defaultValue="0"> <expectation>
VlanPriority</ref> <frameExpected>
</metadataExpected> <ref>EthernetAll</ref>
</expectation> </frameExpected>
</inputPort> <metadataExpected>
</inputPorts> <ref>PHYPortID</ref>
<outputPorts> </metadataExpected>
<outputPort group="false"> </expectation>
<name>SuccessOut</name> </inputPort>
<synopsis>Output port for Packets which have found </inputPorts>
Ethernet L2 information and have been successfully <outputPorts>
encapsulated to an Ethernet packet.</synopsis> <outputPort group="false">
<product> <name>NormalPathOut</name>
<frameProduced> <synopsis>
<ref>IPv4</ref> An output port called normal path output in the
<ref>IPv6</ref> EtherMACIn LFB. It outputs Ethernet packets to
</frameProduced> downstream LFBs for normal processing like Ethernet
<metadataProduced> packet classification and further L3 processing.
<ref>L2PortID</ref> </synopsis>
</metadataProduced> <product>
</product> <frameProduced>
</outputPort> <ref>EthernetAll</ref>
<outputPort group="false"> </frameProduced>
<name>ExceptionOut</name> <metadataProduced>
<synopsis>All packets that fail with the other <ref>PHYPortID</ref>
operations in this LFB are output via this port. </metadataProduced>
</synopsis> </product>
<product> </outputPort>
<frameProduced> <outputPort>
<ref>IPv4</ref> <name>L2BridgingPathOut</name>
<ref>IPv6</ref> <synopsis>
</frameProduced> An output port called L2 bridging path output in
<metadataProduced> the EtherMACIn LFB. It outputs Ethernet packets
<ref>ExceptionID</ref> to downstream LFBs for layer 2 bridging processing.
<ref>MediaEncapInfoIndex</ref> The port is switched on or off by the
<ref availability="conditional">VlanPriority</ref> L2BridgingPathEnable flag.
</metadataProduced> </synopsis>
</product> <product>
</outputPort> <frameProduced>
</outputPorts> <ref>EthernetAll</ref>
<components> </frameProduced>
<component componentID="1" access="read-write"> <metadataProduced>
<name>EncapTable</name> <ref>PHYPortID</ref>
<synopsis>Ethernet Encapsulation table.</synopsis> </metadataProduced>
<typeRef>EncapTableType</typeRef> </product>
</component> </outputPort>
</components> </outputPorts>
</LFBClassDef> <components>
<LFBClassDef LFBClassID="7"> <component componentID="1" access="read-write">
<name>EtherMACOut</name> <name>AdminStatus</name>
<synopsis>EtherMACOut LFB abstracts an Ethernet port at MAC <synopsis>
data link layer. It specifically describes Ethernet packet The LFB status administratively requested, which has
output process. Ethernet output functions are closely related the same data type with a port status. Default is in
to Ethernet input functions, therefore some components 'down' status.
defined in this LFB are actually alias of EtherMACIn LFB. </synopsis>
</synopsis> <typeRef>PortStatusType</typeRef>
<version>1.0</version> <defaultValue>2</defaultValue>
<inputPorts> </component>
<inputPort group="false"> <component componentID="2" access="read-write">
<name>EtherPktsIn</name> <name>LocalMACAddresses</name>
<synopsis>The Input Port of the EtherMACIn. It expects <synopsis>
any kind of Ethernet frame.</synopsis> Local MAC addresses of the Ethernet port the LFB
<expectation> represents.
<frameExpected> </synopsis>
<ref>EthernetAll</ref> <array>
</frameExpected> <typeRef>IEEEMAC</typeRef>
<metadataExpected> </array>
<ref>PHYPortID</ref> </component>
</metadataExpected> <component componentID="3" access="read-write">
</expectation> <name>L2BridgingPathEnable</name>
</inputPort> <synopsis>
</inputPorts> A flag indicating if the LFB L2 BridgingPath output
<outputPorts> port is enabled or not. Default is not.
<outputPort group="false"> </synopsis>
<name>EtherPktsOut</name> <typeRef>boolean</typeRef>
<synopsis>The Normal Output Port of the EtherMACOut. It <defaultValue>false</defaultValue>
can produce any kind of Ethernet frame and along with </component>
the frame passes the ID of the Physical Port as <component componentID="4" access="read-write">
metadata to be used by the next LFBs.</synopsis> <name>PromiscuousMode</name>
<product> <synopsis>
<frameProduced> A flag indicating whether the LFB is in promiscuous
<ref>EthernetAll</ref> mode or not. Default is not.
</frameProduced> </synopsis>
<metadataProduced> <typeRef>boolean</typeRef>
<ref>PHYPortID</ref> <defaultValue>false</defaultValue>
</metadataProduced> </component>
</product> <component componentID="5" access="read-write">
</outputPort> <name>TxFlowControl</name>
</outputPorts> <synopsis>
<components> A flag indicating whether transmit flow control is
<component componentID="1" access="read-write"> applied or not. Default is not.
<name>AdminStatus</name> </synopsis>
<synopsis>Admin status of the port. It is the alias of <typeRef>boolean</typeRef>
"AdminStatus" component defined in EtherMACIn. <defaultValue>false</defaultValue>
</synopsis> </component>
<alias>PortStatusValues</alias> <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>
<typeRef>boolean</typeRef>
<defaultValue>false</defaultValue>
</component>
<component componentID="7" access="read-reset">
<name>MACInStats</name>
<synopsis>
The statistics of the EtherMACIn LFB
</synopsis>
<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">
</component> LogicalPortID</ref>
<component componentID="2" access="read-write"> </metadataExpected>
<name>MTU</name> </expectation>
<synopsis>Maximum transmission unit.</synopsis> </inputPort>
<typeRef>uint32</typeRef> </inputPorts>
</component> <outputPorts>
<component componentID="3" access="read-write"> <outputPort group="true">
<name>TxFlowControl</name> <name>ClassifyOut</name>
<synopsis>Transmit flow control. It is the alias of <synopsis>
"TxFlowControl" component defined in EtherMACIn. A group port for output of Ethernet classifying
</synopsis> results.
<alias>boolean</alias> </synopsis>
</component> <product>
<component componentID="4" access="read-write"> <frameProduced>
<name>RxFlowControl</name> <ref>Arbitrary</ref>
<synopsis>Receive flow control. It is the alias of </frameProduced>
"RxFlowControl" component defined in EtherMACIn. <metadataProduced>
</synopsis> <ref>PHYPortID</ref>
<alias>boolean</alias> <ref>SrcMAC</ref>
</component> <ref>DstMAC</ref>
<component componentID="5" access="read-reset"> <ref>EtherType</ref>
<name>MACOutStats</name> <ref availability="conditional">VlanID</ref>
<synopsis>MACOut statistics</synopsis> <ref availability="conditional">VlanPriority</ref>
<typeRef>MACOutStatsType</typeRef> </metadataProduced>
</component> </product>
</components> </outputPort>
</LFBClassDef> <outputPort group="false">
<LFBClassDef LFBClassID="8"> <name>ExceptionOut</name>
<name>IPv4Validator</name> <synopsis>
<synopsis>An LFB that performs IPv4 packets validation A single port for output of all Ethernet packets that
according to RFC1812. At the same time, ipv4 unicast and fail the classifying process. An ExceptionID metadata
multicast are classified in this LFB.</synopsis> indicates the failure reason.
<version>1.0</version> </synopsis>
<inputPorts> <product>
<inputPort> <frameProduced>
<name>ValidatePktsIn</name> <ref>Arbitrary</ref>
<synopsis>Input port for data packet.</synopsis> </frameProduced>
<expectation> <metadataProduced>
<frameExpected> <ref>ExceptionID</ref>
<ref>Arbitrary</ref> </metadataProduced>
</frameExpected> </product>
</expectation> </outputPort>
</inputPort> </outputPorts>
</inputPorts> <components>
<outputPorts> <component access="read-write" componentID="1">
<outputPort> <name>EtherDispatchTable</name>
<name>IPv4UnicastOut</name> <synopsis>
<synopsis>Output for IPv4 unicast packet.</synopsis> An EtherDispatchTable array component is defined in
<product> the LFB to dispatch every Ethernet packet to output
<frameProduced> group according to logical port ID assigned by the
<ref>IPv4Unicast</ref> VlanInputTable and Ethernet type in the Ethernet
</frameProduced> packet header.
</product> </synopsis>
</outputPort> <typeRef>EtherDispatchTableType</typeRef>
<outputPort> </component>
<name>IPv4MulticastOut</name> <component access="read-write" componentID="2">
<synopsis>Output for IPv4 multicast packet.</synopsis> <name>VlanInputTable</name>
<product> <synopsis>
<frameProduced> A VlanInputTable array component is defined in the
<ref>IPv4Multicast</ref> LFB to classify VLAN Ethernet packets. Every input
</frameProduced> packet is assigned with a new LogicalPortID according
</product> to the packet incoming port ID and the VLAN ID.
</outputPort> </synopsis>
<outputPort> <typeRef>VlanInputTableType</typeRef>
<name>ExceptionOut</name> </component>
<synopsis>Output for exception packet.</synopsis> <component access="read-reset" componentID="3">
<product> <name>EtherClassifyStats</name>
<frameProduced> <synopsis>
<ref>IPv4</ref> A table records statistics on the Ethernet
</frameProduced> classifying process in the LFB.
<metadataProduced> </synopsis>
<ref>ExceptionID</ref> <typeRef>EtherClassifyStatsTableType</typeRef>
</metadataProduced> </component>
</product> </components>
</outputPort> </LFBClassDef>
<outputPort> <LFBClassDef LFBClassID="6">
<name>FailOut</name> <name>EtherEncap</name>
<synopsis>Output for failed validation packet. <synopsis>
</synopsis> This LFB abstracts the process of encapsulating Ethernet
<product> headers onto received packets. The encapsulation is based
<frameProduced> on passed metadata.
<ref>IPv4</ref> </synopsis>
</frameProduced> <version>1.0</version>
<metadataProduced> <inputPorts>
<ref>ValidateErrorID</ref> <inputPort group="false">
</metadataProduced> <name>EncapIn</name>
</product> <synopsis>
</outputPort> A port inputs IPv4 and/or IPv6 packets for
</outputPorts> encapsulation. A MediaEncapInfoIndex metadata is
<components> expected and a VLAN priority metadata is optionally
<component access="read-write" componentID="1"> expected with every input packet.
<name>IPv4ValidatorStats</name> </synopsis>
<synopsis>IPv4 validator statistics information. <expectation>
</synopsis> <frameExpected>
<typeRef>IPv4ValidatorStatsType</typeRef> <ref>IPv4</ref>
</component> <ref>IPv6</ref>
</components> </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>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1" access="read-write">
<name>EncapTable</name>
<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>
<LFBClassDef LFBClassID="9"> <LFBClassDef LFBClassID="7">
<name>IPv6Validator</name> <name>EtherMACOut</name>
<synopsis>An LFB that performs IPv6 packets validation <synopsis>
according to RFC2460. At the same time, ipv6 unicast and EtherMACOut LFB abstracts an Ethernet port at MAC data link
multicast are classified in this LFB.</synopsis> layer. It specifically describes Ethernet packet process
<version>1.0</version> for output to physical port. A downstream LFB is usually an
<inputPorts> Ethernet physical LFB like EtherPHYcop LFB.Ethernet output
<inputPort> functions are closely related to Ethernet input functions,
<name>ValidatePktsIn</name> therefore some components defined in this LFB are as alias
<synopsis>Input port for data packet.</synopsis> of EtherMACIn LFB.
<expectation> </synopsis>
<frameExpected> <version>1.0</version>
<ref>Arbitrary</ref> <inputPorts>
</frameExpected> <inputPort group="false">
</expectation> <name>EtherPktsIn</name>
</inputPort> <synopsis>
</inputPorts> The input port of the EtherMACOut LFB. It expects any
<outputPorts> type of Ethernet frame.
<outputPort> </synopsis>
<name>IPv6UnicastOut</name> <expectation>
<synopsis>Output for IPv6 unicast packet.</synopsis> <frameExpected>
<product> <ref>EthernetAll</ref>
<frameProduced> </frameExpected>
<ref>IPv6Unicast</ref> <metadataExpected>
</frameProduced> <ref>PHYPortID</ref>
</product> </metadataExpected>
</outputPort> </expectation>
<outputPort> </inputPort>
<name>IPv6MulticastOut</name> </inputPorts>
<synopsis>Output for IPv6 multicast packet.</synopsis> <outputPorts>
<product> <outputPort group="false">
<frameProduced> <name>EtherPktsOut</name>
<ref>IPv6Multicast</ref> <synopsis>
</frameProduced> A port to output all Ethernet packets,each with a
</product> metadata indicating the physical port ID the packet
</outputPort> is to go through.
<outputPort> </synopsis>
<name>ExceptionOut</name> <product>
<synopsis>Output for exception packet.</synopsis> <frameProduced>
<product> <ref>EthernetAll</ref>
<frameProduced> </frameProduced>
<ref>IPv6</ref> <metadataProduced>
</frameProduced> <ref>PHYPortID</ref>
<metadataProduced> </metadataProduced>
<ref>ExceptionID</ref> </product>
</metadataProduced> </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. It is defined
as alias of AdminStatus component in EtherMACIn LFB.
</synopsis>
<alias>PortStatusType</alias>
</component>
<component componentID="2" access="read-write">
<name>MTU</name>
<synopsis>Maximum transmission unit (MTU) </synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3" access="read-write">
<name>TxFlowControl</name>
<synopsis>
A flag indicating whether transmit flow control is
applied, defined as alias of TxFlowControl component
in EtherMACIn LFB.
</synopsis>
<alias>boolean</alias>
</component>
<component componentID="4" access="read-write">
<name>RxFlowControl</name>
<synopsis>
A flag indicating whether receive flow control is
applied, defined as alias of RxFlowControl component
in EtherMACIn LFB.
</synopsis>
<alias>boolean</alias>
</component>
<component componentID="5" access="read-reset">
<name>MACOutStats</name>
<synopsis>
The statistics of the EtherMACOut LFB
</synopsis>
<typeRef>MACOutStatsType</typeRef>
</component>
</components>
</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>
<typeRef>IPv4ValidatorStatsType</typeRef>
</component>
</components>
</LFBClassDef>
</product> <LFBClassDef LFBClassID="9">
</outputPort> <name>IPv6Validator</name>
<outputPort> <synopsis>
<name>FailOut</name> The IPv6Validator LFB performs IPv6 validation according to
<synopsis>Output for failed validation packet. [RFC2460]. The IPv6 packet will be output to the
</synopsis> corresponding port regarding of the validation result,
<product> whether the packet is a unicast or a multicast one, an
<frameProduced> exception has occurred or the validation failed.
<ref>IPv6</ref> </synopsis>
</frameProduced> <version>1.0</version>
<metadataProduced> <inputPorts>
<ref>ValidateErrorID</ref> <inputPort>
</metadataProduced> <name>ValidatePktsIn</name>
</product> <synopsis>
</outputPort> Input port for data packets to be validated
</outputPorts> </synopsis>
<components> <expectation>
<component access="read-write" componentID="1"> <frameExpected>
<name>IPv6ValidatorStats</name> <ref>Arbitrary</ref>
<synopsis>IPv6 validator statistics information. </frameExpected>
</synopsis> </expectation>
<typeRef>IPv6ValidatorStatsType</typeRef> </inputPort>
</component> </inputPorts>
</components> <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>
<typeRef>IPv6ValidatorStatsType</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="10">
<name>IPv4UcastLPM</name>
<synopsis>
The IPv4UcastLPM LFB abstracts the IPv4 unicast Longest
Prefix Match (LPM) process. This LFB also provides
facilities to support users to implement equal-cost
multi-path routing (ECMP) or reverse path forwarding (RPF).
However, this LFB itself does not provide ECMP or RPF.
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort group="false">
<name>PktsIn</name>
<synopsis>
A port for input of packets to be processed. IPv4
unicast packets are expected.
</synopsis>
<expectation>
<frameExpected>
<ref>IPv4Unicast</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort group="false">
<name>NormalOut</name>
<synopsis>
A normal output port outputs IPv4 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>IPv4Unicast</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>IPv4Unicast</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>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. 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 IPv4 unicast longest
prefix match process in the LFB.
</synopsis>
<typeRef>IPv4UcastLPMStatsType</typeRef>
</component>
</components>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="10"> <LFBClassDef LFBClassID="11">
<name>IPv4UcastLPM </name> <name>IPv6UcastLPM</name>
<synopsis>An LFB that performs IPv4 Longest Prefix Match <synopsis>
Lookup.It is defined to provide some facilities to support The IPv6UcastLPM LFB abstracts the IPv6 unicast Longest
users to implement equal-cost multi-path routing(ECMP) or Prefix Match (LPM) process. This LFB also provides
reverse path forwarding (RPF).</synopsis> facilities to support users to implement equal-cost
<version>1.0</version> multi-path routing (ECMP) or reverse path forwarding (RPF).
<inputPorts> However, this LFB itself does not provide ECMP or RPF.
<inputPort group="false"> </synopsis>
<name>PktsIn</name> <version>1.0</version>
<synopsis>A Single Packet Input</synopsis> <inputPorts>
<expectation> <inputPort group="false">
<frameExpected> <name>PktsIn</name>
<ref>IPv4Unicast</ref> <synopsis>
</frameExpected> A port for input of packets to be processed. IPv6
</expectation> unicast packets are expected.
</inputPort> </synopsis>
</inputPorts> <expectation>
<outputPorts> <frameExpected>
<outputPort group="false"> <ref>IPv6Unicast</ref>
<name>NormalOut</name> </frameExpected>
<synopsis>This output port is connected with </expectation>
IPv4NextHop LFB</synopsis> </inputPort>
<product> </inputPorts>
<frameProduced> <outputPorts>
<ref>IPv4Unicast</ref> <outputPort group="false">
</frameProduced> <name>NormalOut</name>
<metadataProduced> <synopsis>
<ref>HopSelector</ref> A normal output port outputs IPv6 unicast packets
</metadataProduced> that succeed the LPM lookup. A HopSelector metadata
</product> is produced for every packet for downstream LFB to do
</outputPort> next hop action.
<outputPort group="false"> </synopsis>
<name>ECMPOut</name> <product>
<synopsis>This output port is connected with ECMP LFB, <frameProduced>
if there is ECMP LFB in the FE.</synopsis> <ref>IPv6Unicast</ref>
<product> </frameProduced>
<frameProduced> <metadataProduced>
<ref>IPv4Unicast</ref> <ref>HopSelector</ref>
</frameProduced> </metadataProduced>
<metadataProduced> </product>
<ref>HopSelector</ref> </outputPort>
</metadataProduced> <outputPort group="false">
</product> <name>ECMPOut</name>
</outputPort> <synopsis>
<outputPort group="false"> The port outputs packets that need further ECMP
<name>ExceptionOut</name> processing. An ECMP processing LFB is usually
<synopsis>The output for the packet if an exception followed the output. If ECMP is not required, no
occurs</synopsis> downstream LFB may be connected to the port.
<product> </synopsis>
<frameProduced> <product>
<ref>IPv4Unicast</ref> <frameProduced>
</frameProduced> <ref>IPv6Unicast</ref>
<metadataProduced>
<ref>ExceptionID</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1" access="read-write">
<name>IPv4PrefixTable</name>
<synopsis>The IPv4 prefix table.</synopsis>
<typeRef>IPv4PrefixTableType</typeRef>
</component>
<component componentID="2" access="read-reset">
<name>IPv4UcastLPMStats</name>
<synopsis>Statistics for IPv4 Unicast Longest Prefix
Match</synopsis>
<typeRef>IPv4UcastLPMStatsType</typeRef>
</component>
</components> </frameProduced>
</LFBClassDef> <metadataProduced>
<LFBClassDef LFBClassID="11"> <ref>HopSelector</ref>
<name>IPv6UcastLPM </name> </metadataProduced>
<synopsis>An LFB that performs IPv6 Longest Prefix Match </product>
Lookup.It is defined to provide some facilities to support </outputPort>
users to implement equal-cost multi-path routing(ECMP) or <outputPort group="false">
reverse path forwarding (RPF).</synopsis> <name>ExceptionOut</name>
<version>1.0</version> <synopsis>
<inputPorts> The port outputs all packets with exceptional cases
<inputPort group="false"> when doing LPM process. An ExceptionID metadata
<name>PktsIn</name> associated indicates what caused the exception.
<synopsis>A Single Packet Input</synopsis> </synopsis>
<expectation> <product>
<frameExpected> <frameProduced>
<ref>IPv6Unicast</ref> <ref>IPv6Unicast</ref>
</frameExpected> </frameProduced>
</expectation> <metadataProduced>
</inputPort> <ref>ExceptionID</ref>
</inputPorts> </metadataProduced>
<outputPorts> </product>
<outputPort group="false"> </outputPort>
<name>NormalOut</name> </outputPorts>
<synopsis>This output port is connected with <components>
IPv6NextHop LFB</synopsis> <component componentID="1" access="read-write">
<product> <name>IPv6PrefixTable</name>
<frameProduced> <synopsis>
<ref>IPv6Unicast</ref> A table for IPv6 longest prefix match. The
</frameProduced> destination IPv6 address of every input packet is
<metadataProduced> used as a search key to look up the table to find
<ref>HopSelector</ref> out a next hop selector.
</metadataProduced> </synopsis>
</product> <typeRef>IPv6PrefixTableType</typeRef>
</outputPort> </component>
<outputPort group="false"> <component componentID="2" access="read-reset">
<name>ECMPOut</name> <name>IPv6UcastLPMStats</name>
<synopsis>This output port is connected with ECMP LFB, <synopsis>
if there is ECMP LFB in the FE.</synopsis> The statistics information for IPv6 unicast longest
<product> prefix match process in the LFB.
<frameProduced> </synopsis>
<ref>IPv6Unicast</ref> <typeRef>IPv6UcastLPMStatsType</typeRef>
</frameProduced> </component>
<metadataProduced> </components>
<ref>HopSelector</ref> </LFBClassDef>
</metadataProduced> <LFBClassDef LFBClassID="12">
</product> <name>IPv4NextHop</name>
</outputPort> <synopsis>
<outputPort group="false"> The LFB abstracts the process of next hop information
<name>ExceptionOut</name> application to IPv4 packets. It receives an IPv4 packet
<synopsis>The output for the packet if an exception with an associated next hop identifier (HopSelector), and
occurs</synopsis> uses the identifier as a table index to look up a next hop
<product> table to find an appropriate LFB output port. The data
<frameProduced> processing also involves the forwarding TTL decrement and
<ref>IPv6Unicast</ref> IP checksum recalculation.
</frameProduced> </synopsis>
<metadataProduced> <version>1.0</version>
<ref>ExceptionID</ref> <inputPorts>
</metadataProduced> <inputPort group="false">
</product> <name>PktsIn</name>
</outputPort> <synopsis>
</outputPorts> A port for input of unicast IPv4 packets, along with
<components> a HopSelector metadata which is used as a table index
<component componentID="1" access="read-write"> to lookup the next hop table in the LFB.
<name>IPv6PrefixTable</name> </synopsis>
<synopsis>The IPv6 prefix table.</synopsis> <expectation>
<typeRef>IPv6PrefixTableType</typeRef> <frameExpected>
</component> <ref>IPv4Unicast</ref>
<component componentID="2" access="read-reset"> </frameExpected>
<name>IPv6UcastLPMStats</name> <metadataExpected>
<synopsis>Statistics for IPv6 Unicast Longest Prefix <ref>HopSelector</ref>
Match</synopsis> </metadataExpected>
<typeRef>IPv6UcastLPMStatsType</typeRef> </expectation>
</component> </inputPort>
</components> </inputPorts>
</LFBClassDef> <outputPorts>
<LFBClassDef LFBClassID="12"> <outputPort group="true">
<name>IPv4NextHop</name> <name>SuccessOut</name>
<synopsis>This LFB abstracts the process of selecting ipv4 <synopsis>
next hop action. It receives an IPv4 packet with an The group output port for packets successfully found
associated next hop ID, and uses the ID to look up a next next hop information. The group output port index for
hop table to find an appropriate output port from the LFB. every packet is decided by the LFBOutputSelectIndex
</synopsis> value assigned in the next hop table entry. The
<version>1.0</version> packet is sent to a downstream LFB along with an
<inputPorts> L3PortID, a NextHopIPv4Addr, and optionally a
<inputPort group="false"> MediaEncapInfoIndex metadata.
<name>PktsIn</name> </synopsis>
<synopsis>A Single Packet Input</synopsis> <product>
<expectation> <frameProduced>
<frameExpected> <ref>IPv4Unicast</ref>
<ref>IPv4Unicast</ref> </frameProduced>
</frameExpected> <metadataProduced>
<metadataExpected> <ref>L3PortID</ref>
<ref>HopSelector</ref> <ref>NextHopIPv4Addr</ref>
</metadataExpected> <ref availability="conditional">
</expectation> MediaEncapInfoIndex</ref>
</inputPort> </metadataProduced>
</inputPorts> </product>
<outputPorts> </outputPort>
<outputPort group="true"> <outputPort group="false">
<name>SuccessOut</name> <name>ExceptionOut</name>
<synopsis>The output for the packet if it is valid to be <synopsis>
forwarded</synopsis> The output port for packets with exceptional or
<product> failure cases when doing next hop action. An
<frameProduced> ExceptionID metadata indicates what caused the case.
<ref>IPv4Unicast</ref> </synopsis>
</frameProduced> <product>
<metadataProduced> <frameProduced>
<ref>L3PortID</ref> <ref>IPv4Unicast</ref>
<ref>NextHopIPv4Addr</ref> </frameProduced>
<ref availability="conditional"> <metadataProduced>
MediaEncapInfoIndex</ref> <ref>ExceptionID</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
<outputPort group="false"> </outputPorts>
<name>ExceptionOut</name> <components>
<synopsis>The output for the packet if an exception <component componentID="1">
occurs</synopsis> <name>IPv4NextHopTable</name>
<product> <synopsis>
<frameProduced> The IPv4NextHopTable is defined as an array. A
<ref>IPv4Unicast</ref> HopSelector is used to match the array index of the
</frameProduced> table to find out a row of the table as the next hop
<metadataProduced> information result. Each row of the array is a struct
<ref>ExceptionID</ref> containing the L3PortID, MTU, NextHopIPAddr(IPv4
</metadataProduced> type), MediaEncapInfoIndex, and LFBOutputSelectIndex.
</product> </synopsis>
</outputPort> <typeRef>IPv4NextHopTableType</typeRef>
</outputPorts> </component>
<components> </components>
<component componentID="1"> </LFBClassDef>
<name>IPv4NextHopTable</name> <LFBClassDef LFBClassID="13">
<synopsis>The next hop table.</synopsis> <name>IPv6NextHop</name>
<typeRef>IPv4NextHopTableType</typeRef> <synopsis>
</component> The LFB abstracts the process of next hop information
</components> application to IPv6 packets. It receives an IPv6 packet
</LFBClassDef> with an associated next hop identifier (HopSelector), and
<LFBClassDef LFBClassID="13"> uses the identifier as a table index to look up a next hop
<name>IPv6NextHop</name> table to find an appropriate LFB output port.
<synopsis>The LFB abstracts the process of next hop </synopsis>
information application to IPv6 packets. It receives an IPv4 <version>1.0</version>
packet with an associated next hop ID, and uses the ID to <inputPorts>
look up a next hop table to find an appropriate output port <inputPort group="false">
from the LFB..</synopsis> <name>PktsIn</name>
<version>1.0</version> <synopsis>
<inputPorts> A port for input of unicast IPv6 packets, along with
<inputPort group="false"> a HopSelector metadata which is used as a table index
<name>PktsIn</name> to lookup the next hop table in the LFB.
<synopsis>A single packet input.</synopsis> </synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
<ref>IPv6Unicast</ref> <ref>IPv6Unicast</ref>
</frameExpected> </frameExpected>
<metadataExpected> <metadataExpected>
<ref>HopSelector</ref> <ref>HopSelector</ref>
</metadataExpected> </metadataExpected>
</expectation> </expectation>
</inputPort> </inputPort>
</inputPorts> </inputPorts>
<outputPorts> <outputPorts>
<outputPort group="true"> <outputPort group="true">
<name>SuccessOut</name> <name>SuccessOut</name>
<synopsis>The output for the packet if it is valid to <synopsis>
be forwarded</synopsis> The group output port for packets successfully found
<product> next hop information. The group output port index for
<frameProduced> every packet is decided by the LFBOutputSelectIndex
<ref>IPv6Unicast</ref> value assigned in the next hop table entry. The
</frameProduced> packet is sent to a downstream LFB along with an
<metadataProduced> L3PortID, a NextHopIPv6Addr, and optionally a
<ref>L3PortID</ref> MediaEncapInfoIndex metadata.
<ref>NextHopIPv6Addr</ref> </synopsis>
<ref availability="conditional"> <product>
MediaEncapInfoIndex</ref> <frameProduced>
</metadataProduced> <ref>IPv6Unicast</ref>
</product> </frameProduced>
</outputPort> <metadataProduced>
<outputPort group="false"> <ref>L3PortID</ref>
<name>ExceptionOut</name> <ref>NextHopIPv6Addr</ref>
<synopsis>The output for the packet if an exception <ref availability="conditional">
occurs</synopsis> MediaEncapInfoIndex</ref>
<product> </metadataProduced>
<frameProduced> </product>
<ref>IPv6Unicast</ref> </outputPort>
</frameProduced> <outputPort group="false">
<metadataProduced> <name>ExceptionOut</name>
<ref>ExceptionID</ref> <synopsis>
</metadataProduced> The output port for packets with exceptional or
</product> failure cases when doing next hop action. An
</outputPort> ExceptionID metadata indicates what caused the case.
</outputPorts> </synopsis>
<components> <product>
<component componentID="1"> <frameProduced>
<name>IPv6NextHopTable</name> <ref>IPv6Unicast</ref>
<synopsis>The next hop table.</synopsis>
<typeRef>IPv6NextHopTableType</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="14">
<name>RedirectIn</name>
<synopsis>The RedirectIn LFB abstracts the process for CE to
inject data packets into FE LFB topology, so as to input data
packets into FE data paths. CE may associate some
metadata to data packets to indicate various information on
the packets. Among them, there MUST exist a 'RedirectIndex'
metadata, which is an integer acting as an output port index.
</synopsis>
<version>1.0</version>
<outputPorts>
<outputPort group="true">
<name>PktsOut</name>
<synopsis>This output group sends the redirected packet
in the data path.</synopsis>
<product>
<frameProduced>
<ref>Arbitrary</ref>
</frameProduced>
</product>
</outputPort>
</outputPorts>
</LFBClassDef>
<LFBClassDef LFBClassID="15">
<name>RedirectOut</name>
<synopsis>The LFB abstracts the process for LFBs in
FE to deliver data packets to CE. All metadata
associated with the input packets will be delivered to CE
via the redirect message of ForCES protocol [RFC5810].
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort group="false">
<name>PktsIn</name>
<synopsis>This input receives packets to send to
the CE.</synopsis>
<expectation>
<frameExpected>
<ref>Arbitrary</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
</LFBClassDef> </frameProduced>
<LFBClassDef LFBClassID="16"> <metadataProduced>
<name>BasicMetadataDispatch</name> <ref>ExceptionID</ref>
<synopsis>This LFB provides the function to dispatch input </metadataProduced>
packets to a group output according to a metadata and a </product>
dispatch table.This LFB currently only allow a metadata with </outputPort>
an interger value to be used for dispatch. </synopsis> </outputPorts>
<version>1.0</version> <components>
<inputPorts> <component componentID="1">
<inputPort> <name>IPv6NextHopTable</name>
<name>PktsIn</name> <synopsis>
<synopsis>Input port for data packet.</synopsis> The IPv6NextHopTable is defined as an array. A
<expectation> HopSelector is used to match the array index of the
<frameExpected> table to find out a row of the table as the next hop
<ref>Arbitrary</ref> information result. Each row of the array is a struct
</frameExpected> containing the L3PortID, MTU, NextHopIPAddr(IPv6
<metadataExpected> type), MediaEncapInfoIndex, and LFBOutputSelectIndex.
<ref>Arbitrary</ref> </synopsis>
</metadataExpected> <typeRef>IPv6NextHopTableType</typeRef>
</expectation> </component>
</inputPort> </components>
</inputPorts>
<outputPorts>
<outputPort group="true">
<name>PktsOut</name>
<synopsis>Data packet output</synopsis>
<product>
<frameProduced>
<ref>Arbitrary</ref>
</frameProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component access="read-write" componentID="1">
<name>MetadataID</name>
<synopsis>the metadata ID for dispatching</synopsis>
<typeRef>uint32</typeRef>
</component>
<component access="read-write" componentID="2">
<name>MetadataDispatchTable</name>
<synopsis>Metadata dispatch table.</synopsis>
<typeRef>MetadataDispatchTableType</typeRef>
</component>
</components>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="17"> <LFBClassDef LFBClassID="14">
<name>GenericScheduler</name> <name>RedirectIn</name>
<synopsis>This is a preliminary generic scheduler LFB for <synopsis>
abstracting a simple scheduling process.Users may use this A RedirectIn LFB abstracts the process for the ForCES CE to
LFB as a basic scheduler LFB to further construct more inject data packets into the ForCES FE LFB topology so as to
complex scheduler LFBs by means of inheritance as described input data packets into FE data paths.
in RFC5812.</synopsis> </synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <outputPorts>
<inputPort group="true"> <outputPort group="true">
<name>PktsIn</name> <name>PktsOut</name>
<synopsis>Input port for data packet.</synopsis> <synopsis>
<expectation> The output port of RedirectIn LFB is defined as a
<frameExpected> group output type. Packets produced by this output
<ref>Arbitrary</ref> will have arbitrary frame types decided by the CE
</frameExpected> which generated the packets. From LFB topology point
</expectation> of view, the RedirectIn LFB acts as a source point
</inputPort> for data packets coming from CE, therefore RedirectIn
</inputPorts> LFB is defined with a single output LFB port (and no
<outputPorts> input LFB port). The CE may associate some metadata
<outputPort> to indicate the frame types and may also associate
<name>PktsOut</name> other metadata to indicate information on the packets.
<synopsis>Data packet output.</synopsis> Among them, there must exist a 'RedirectIndex'
<product> metadata, which is an integer acting as an index. When
<frameProduced> the CE transmits the metadata along with the packet to
<ref>Arbitrary</ref> a RedirectIn LFB, the LFB will read the RedirectIndex
</frameProduced> metadata and output the packet to one of its group
</product> output port instance, whose port index is indicated
</outputPort> by this metadata. Any other metadata, in addition to
</outputPorts> 'RedirectIndex', will be passed untouched along the
<components> packet delivered by the CE to downstream LFB. This
<component access="read-only" componentID="1"> means the 'RedirectIndex' metadata from CE will be
<name>QueueCount</name> "consumed" by the RedirectIn LFB and will not be
<synopsis>The number of queues to be scheduled. passed to downstream LFB. Note that, a packet from
</synopsis> CE without a 'RedirectIndex' metadata associated will
<typeRef>uint32</typeRef> be dropped by the LFB.
</component> </synopsis>
<component access="read-write" componentID="2"> <product>
<name>SchedulingDiscipline</name> <frameProduced>
<synopsis>the Scheduler discipline.</synopsis> <ref>Arbitrary</ref>
<typeRef>SchdDisciplineType</typeRef> </frameProduced>
</component> </product>
<component access="read-only" componentID="3"> </outputPort>
<name>QueueStats</name> </outputPorts>
<synopsis>Current statistics for all queues</synopsis>
<typeRef>QueueStatsTableType</typeRef>
</component>
</components>
<capabilities>
<capability componentID="30">
<name>QueueLenLimit</name>
<synopsis>Maximum length of each queue,the unit is
byte.</synopsis>
<typeRef>uint32</typeRef>
</capability>
</capabilities>
</LFBClassDef> </LFBClassDef>
</LFBClassDefs> <LFBClassDef LFBClassID="15">
</LFBLibrary> <name>RedirectOut</name>
<synopsis>
A RedirectOut LFB abstracts the process for LFBs in the
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 single input LFB
port (and no output LFB port). The port expects all
types of packet frames and metadata. All associated
metadata produced (but not consumed) by previous
processed LFBs should be delivered to the CE.
</synopsis>
<expectation>
<frameExpected>
<ref>Arbitrary</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
</LFBClassDef>
<LFBClassDef LFBClassID="16">
<name>BasicMetadataDispatch</name>
<synopsis>
The BasicMetadataDispatch LFB is defined to abstract the
process in which a packet is dispatched to some output path
based on its associated metadata value. 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 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 outputs packets for which the data
processing failed, along with an additional
ExceptionID metadata to indicate 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 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>
<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>
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 91, line 13 skipping to change at page 101, line 13
downstream LFBs. downstream LFBs.
If a packet is classified as an IPv4 packet, it is sent downstream to If a packet is classified as an IPv4 packet, it is sent downstream to
an IPv4Validator LFB (Section 5.2.1) to validate the IPv4 packet. In an IPv4Validator LFB (Section 5.2.1) to validate the IPv4 packet. In
the validator LFB, IPv4 packets are validated and are additionally the validator LFB, IPv4 packets are validated and are additionally
classified into either IPv4 unicast packets or multicast packets. classified into either IPv4 unicast packets or multicast packets.
IPv4 unicast packets are sent to downstream to the IPv4UcastLPM LFB IPv4 unicast packets are sent to downstream to the IPv4UcastLPM LFB
(Section 5.3.1). (Section 5.3.1).
The IPv4UcastLPM LFB is where the longest prefix match decision is The IPv4UcastLPM LFB is where the longest prefix match decision is
made, and a next hop selection is selected. The nexthop ID metadata made, and a next hop selection is selected. The next hop ID metadata
is generated by the IPv4UcastLPM LFB to be consumed downstream by the is generated by the IPv4UcastLPM LFB to be consumed downstream by the
IPv4NextHop LFB (Section 5.3.2). IPv4NextHop LFB (Section 5.3.2).
The IPv4NextHop LFB uses the nexthop ID metadata to do derive where The IPv4NextHop LFB uses the next hop ID metadata to do derive where
the packet is to go next and the media encapsulation type for the the packet is to go next and the media encapsulation type for the
port, etc. The IPv4NextHop LFB generates the L3PortID metadata used port, etc. The IPv4NextHop LFB generates the L3PortID metadata used
to identify a next hop output physical/logical port. In the example to identify a next hop output physical/logical port. In the example
use case, the next hop output port is an Ethernet type; as a result, use case, the next hop output port is an Ethernet type; as a result,
the packet and its L3 port ID metadata are sent downstream to an the packet and its L3 port ID metadata are sent downstream to an
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
skipping to change at page 92, line 7 skipping to change at page 102, line 7
7.2. ARP processing 7.2. ARP processing
Figure 2 shows the processing path for ARP protocol in the case the Figure 2 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
...-->| | . | | | ...-->| | . | | |
| | . | +---+ | | . | +---+
| | . | RedirectOut | | . | RedirectOut
+---+ | +---+ ^
Ether EtherEncap | IPv4 packets lack Ether EtherEncap | IPv4 packets lack
Classifier +---+ | address resolution information Classifier +---+ | address resolution information
| | | | | |
Packets need | |--------->---+ Packets need | |--------->---+
...--------->| | ...--------->| |
L2 Encapsulation| | L2 Encapsulation| |
+---+ | | +------+ +---+ | | +------+
| | +-->| |--+ +---+ |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 2: LFB use case for ARP
skipping to change at page 96, line 37 skipping to change at page 106, line 37
The assignment of LFB class names and LFB class identifiers is as in The assignment of LFB class names and LFB class identifiers is as in
the following table. the following table.
+-----------+---------------+------------------------+--------------+ +-----------+---------------+------------------------+--------------+
| LFB Class | LFB Class Name| Description | Reference | | LFB Class | LFB Class Name| Description | Reference |
| Identifier| | | | | Identifier| | | |
+-----------+---------------+------------------------+--------------+ +-----------+---------------+------------------------+--------------+
| 3 | EtherPHYCop | Define an Ethernet port| RFC????(this| | 3 | EtherPHYCop | Define an Ethernet port| RFC????(this|
| | | abstracted at physical | document) | | | | abstracted at physical | document) |
| | | layer | Section 5.1.1| | | | layer. | Section 5.1.1|
| | | -------------- | | | | | | |
| 4 | EtherMACIn | Define an Ethernet | RFC???? | | 4 | EtherMACIn | Define an Ethernet | RFC???? |
| | | input port at MAC data | Section 5.1.2| | | | input port at MAC data | Section 5.1.2|
| | | link layer | | | | | link layer. | |
| | | -------------- | | | | | | |
| 5 |EtherClassifier| Define the process to | RFC???? | | 5 |EtherClassifier| Define the process to | RFC???? |
| | | decapsulate Ethernet | Section 5.1.3| | | | decapsulate Ethernet | Section 5.1.3|
| | | packets and classify | | | | | packets and classify | |
| | | the packets | | | | | the packets. | |
| | | -------------- | | | | | | |
| 6 | EtherEncap | Define the process to | RFC???? | | 6 | EtherEncap | Define the process to | RFC???? |
| | | encapsulate IP packets | Section 5.1.4| | | | encapsulate IP packets | Section 5.1.4|
| | | to Ethernet packets | | | | | to Ethernet packets. | |
| | | -------------- | | | | | | |
| 7 | EtherMACOut | Define an Ethernet | RFC ???? | | 7 | EtherMACOut | Define an Ethernet | RFC ???? |
| | | output port at MAC | Section 5.1.5| | | | output port at MAC | Section 5.1.5|
| | | data link layer | | | | | data link layer. | |
| | | -------------- | | | | | | |
| 8 | IPv4Validator | Perform IPv4 packets | RFC ???? | | 8 | IPv4Validator | Perform IPv4 packets | RFC ???? |
| | | validation. | Section 5.2.1| | | | validation. | Section 5.2.1|
| | | -------------- | | | | | | |
| 9 | IPv6Validator | Perform IPv6 packets | RFC ???? | | 9 | IPv6Validator | Perform IPv6 packets | RFC ???? |
| | | validation | Section 5.2.2| | | | validation. | Section 5.2.2|
| | | -------------- | | | | | | |
| 10 | IPv4UcastLPM | Perform IPv4 Longest | RFC ???? | | 10 | IPv4UcastLPM | Perform IPv4 Longest | RFC ???? |
| | | Prefix Match Lookup | Section 5.3.1| | | | Prefix Match Lookup. | Section 5.3.1|
| | | -------------- | | | | | | |
| 11 | IPv6UcastLPM | Perform IPv6 Longest | RFC ???? | | 11 | IPv6UcastLPM | Perform IPv6 Longest | RFC ???? |
| | | Prefix Match Lookup | Section 5.3.3| | | | Prefix Match Lookup. | Section 5.3.3|
| | | -------------- | | | | | | |
| 12 | IPv4NextHop | Define the process of | RFC ??? | | 12 | IPv4NextHop | Define the process of | RFC ??? |
| | | selecting Ipv4 next hop| Section 5.3.2| | | | selecting Ipv4 next hop| Section 5.3.2|
| | | action | | | | | action. | |
| | | -------------- | | | | | | |
| 13 | IPv6NextHop | Define the process of | RFC ??? | | 13 | IPv6NextHop | Define the process of | RFC ??? |
| | | selecting Ipv6 next hop| Section 5.3.4| | | | selecting Ipv6 next hop| Section 5.3.4|
| | | action | | | | | action. | |
| | | -------------- | | | | | | |
| 14 | RedirectIn | Define the process for | RFC ??? | | 14 | RedirectIn | Define the process for | RFC ??? |
| | | CE to inject data | Section 5.4.1| | | | CE to inject data | Section 5.4.1|
| | | packets into FE LFB | | | | | packets into FE LFB | |
| | | topology | | | | | topology. | |
| | | -------------- | | | | | | |
| 15 | RedirectOut | Define the process for | RFC ??? | | 15 | RedirectOut | Define the process for | RFC ??? |
| | | LFBs in FE to deliver | Section 5.4.2| | | | LFBs in FE to deliver | Section 5.4.2|
| | | data packets to CE | | | | | data packets to CE. | |
| | | -------------- | | | | | | |
| 16 |BasicMetadata | Dispatch input packets | RFC ??? | | 16 | BasicMetadata | Dispatch input packets | RFC ??? |
| |Dispatch | to a group output | Section 5.5.1| | | Dispatch | to a group output | Section 5.5.1|
| | | according to a metadata| | | | | according to a metadata| |
| | | -------------- | | | | | | |
| 17 |Generic | Define a preliminary | RFC ???? | | 17 | Generic | Define a preliminary | RFC ???? |
| |Scheduler | generic scheduling | Section 5.5.2| | | Scheduler | generic scheduling | Section 5.5.2|
| | | process | | | | | process. | |
+-----------+---------------+------------------------+--------------+ +-----------+---------------+------------------------+--------------+
Table 1 Table 1
10.2. Metadata ID 10.2. Metadata ID
The Metadata ID namespace is 32 bits long. The following is the The Metadata ID namespace is 32 bits long. The following is the
guideline for managing the namespace. guideline for managing the namespace.
Metadata ID 0x00000000-0x7FFFFFFF Metadata ID 0x00000000-0x7FFFFFFF
skipping to change at page 98, line 27 skipping to change at page 108, line 27
+--------------+-------------------------+--------------------------+ +--------------+-------------------------+--------------------------+
| Value | Name | Definition | | Value | Name | Definition |
+--------------+-------------------------+--------------------------+ +--------------+-------------------------+--------------------------+
| 0x00000001 | PHYPortID | See Section 4.4 | | 0x00000001 | PHYPortID | See Section 4.4 |
| 0x00000002 | SrcMAC | See Section 4.4 | | 0x00000002 | SrcMAC | See Section 4.4 |
| 0x00000003 | DstMAC | See Section 4.4 | | 0x00000003 | DstMAC | See Section 4.4 |
| 0x00000004 | LogicalPortID | See Section 4.4 | | 0x00000004 | LogicalPortID | See Section 4.4 |
| 0x00000005 | EtherType | See Section 4.4 | | 0x00000005 | EtherType | See Section 4.4 |
| 0x00000006 | VlanID | See Section 4.4 | | 0x00000006 | VlanID | See Section 4.4 |
| 0x00000007 | VlanPriority | See Section 4.4 | | 0x00000007 | VlanPriority | See Section 4.4 |
| 0x00000008 | NexthopIPv4Addr | See Section 4.4 | | 0x00000008 | NextHopIPv4Addr | See Section 4.4 |
| 0x00000009 | NexthopIPv6Addr | See Section 4.4 | | 0x00000009 | NextHopIPv6Addr | See Section 4.4 |
| 0x0000000A | HopSelector | See Section 4.4 | | 0x0000000A | HopSelector | See Section 4.4 |
| 0x0000000B | ExceptionID | See Section 4.4 | | 0x0000000B | ExceptionID | See Section 4.4 |
| 0x0000000C | ValidateErrorID | See Section 4.4 | | 0x0000000C | ValidateErrorID | See Section 4.4 |
| 0x0000000D | L3PortID | See Section 4.4 | | 0x0000000D | L3PortID | See Section 4.4 |
| 0x0000000E | RedirectIndex | See Section 4.4 | | 0x0000000E | RedirectIndex | See Section 4.4 |
| 0x0000000F | MediaEncapInfoIndex | See Section 4.4 | | 0x0000000F | MediaEncapInfoIndex | See Section 4.4 |
+--------------+-------------------------+--------------------------+ +--------------+-------------------------+--------------------------+
Table 2 Table 2
 End of changes. 243 change blocks. 
1475 lines changed or deleted 1989 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/