draft-ietf-forces-lfb-lib-12.txt   rfc6956.txt 
Internet Engineering Task Force W. Wang Internet Engineering Task Force (IETF) W. Wang
Internet-Draft Zhejiang Gongshang University Request for Comments: 6956 Zhejiang Gongshang University
Intended status: Standards Track E. Haleplidis Category: Standards Track E. Haleplidis
Expires: September 30, 2013 University of Patras ISSN: 2070-1721 University of Patras
K. Ogawa K. Ogawa
NTT Corporation NTT Corporation
C. Li C. Li
Hangzhou DPtech Hangzhou DPtech
J. Halpern J. Halpern
Ericsson Ericsson
March 29, 2013 June 2013
ForCES Logical Function Block (LFB) Library Forwarding and Control Element Separation (ForCES)
draft-ietf-forces-lfb-lib-12 Logical Function Block (LFB) Library
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 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 the ForCES Forwarding
protocol specifications, and are scoped to meet requirements of Element (FE) model and ForCES protocol specifications; they are
typical router functions and considered as the basic LFB library for scoped to meet requirements of typical router functions and are
ForCES. The library includes the descriptions of the LFBs and the considered the basic LFB library for ForCES. The library includes
XML definitions. the descriptions of the LFBs and the XML definitions.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on September 30, 2013. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6956.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Terminology and Conventions . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Terminology and Conventions .....................................4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Requirements Language ......................................4
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Definitions ................................................4
3.1. Scope of the Library . . . . . . . . . . . . . . . . . . 8 3. Overview ........................................................6
3.2. Overview of LFB Classes in the Library . . . . . . . . . 10 3.1. Scope of the Library .......................................6
3.2.1. LFB Design Choices . . . . . . . . . . . . . . . . . 10 3.2. Overview of LFB Classes in the Library .....................8
3.2.2. LFB Class Groupings . . . . . . . . . . . . . . . . . 11 3.2.1. LFB Design Choices ..................................8
3.2.3. Sample LFB Class Application . . . . . . . . . . . . 12 3.2.2. LFB Class Groupings .................................9
3.3. Document Structure . . . . . . . . . . . . . . . . . . . 13 3.2.3. Sample LFB Class Application .......................10
4. Base Types . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3. Document Structure ........................................11
4.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . 14 4. Base Types .....................................................11
4.1.1. Atomic . . . . . . . . . . . . . . . . . . . . . . . 14 4.1. Data Types ................................................13
4.1.2. Compound Struct . . . . . . . . . . . . . . . . . . . 15 4.1.1. Atomic .............................................13
4.1.3. Compound Array . . . . . . . . . . . . . . . . . . . 15 4.1.2. Compound Struct ....................................13
4.2. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 16 4.1.3. Compound Array .....................................14
4.3. MetaData Types . . . . . . . . . . . . . . . . . . . . . 16 4.2. Frame Types ...............................................14
4.4. XML for Base Type Library . . . . . . . . . . . . . . . . 17 4.3. Metadata Types ............................................15
5. LFB Class Description . . . . . . . . . . . . . . . . . . . . 43 4.4. XML for Base Type Library .................................16
5.1. Ethernet Processing LFBs . . . . . . . . . . . . . . . . 43 5. LFB Class Descriptions .........................................41
5.1.1. EtherPHYCop . . . . . . . . . . . . . . . . . . . . . 44 5.1. Ethernet-Processing LFBs ..................................42
5.1.2. EtherMACIn . . . . . . . . . . . . . . . . . . . . . 46 5.1.1. EtherPHYCop ........................................42
5.1.3. EtherClassifier . . . . . . . . . . . . . . . . . . . 48 5.1.2. EtherMACIn .........................................44
5.1.4. EtherEncap . . . . . . . . . . . . . . . . . . . . . 50 5.1.3. EtherClassifier ....................................46
5.1.5. EtherMACOut . . . . . . . . . . . . . . . . . . . . . 52 5.1.4. EtherEncap .........................................48
5.2. IP Packet Validation LFBs . . . . . . . . . . . . . . . . 53 5.1.5. EtherMACOut ........................................50
5.2.1. IPv4Validator . . . . . . . . . . . . . . . . . . . . 54 5.2. IP Packet Validation LFBs .................................52
5.2.2. IPv6Validator . . . . . . . . . . . . . . . . . . . . 55 5.2.1. IPv4Validator ......................................52
5.3. IP Forwarding LFBs . . . . . . . . . . . . . . . . . . . 57 5.2.2. IPv6Validator ......................................54
5.3.1. IPv4UcastLPM . . . . . . . . . . . . . . . . . . . . 57
5.3.2. IPv4NextHop . . . . . . . . . . . . . . . . . . . . . 59
5.3.3. IPv6UcastLPM . . . . . . . . . . . . . . . . . . . . 61
5.3.4. IPv6NextHop . . . . . . . . . . . . . . . . . . . . . 63
5.4. Redirect LFBs . . . . . . . . . . . . . . . . . . . . . . 65
5.4.1. RedirectIn . . . . . . . . . . . . . . . . . . . . . 65
5.4.2. RedirectOut . . . . . . . . . . . . . . . . . . . . . 66
5.5. General Purpose LFBs . . . . . . . . . . . . . . . . . . 67
5.5.1. BasicMetadataDispatch . . . . . . . . . . . . . . . . 67
5.5.2. GenericScheduler . . . . . . . . . . . . . . . . . . 69
6. XML for LFB Library . . . . . . . . . . . . . . . . . . . . . 71
7. LFB Class Use Cases . . . . . . . . . . . . . . . . . . . . . 100
7.1. IPv4 Forwarding . . . . . . . . . . . . . . . . . . . . . 100
7.2. ARP processing . . . . . . . . . . . . . . . . . . . . . 102
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 105
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 106
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 107
10.1. LFB Class Names and LFB Class Identifiers . . . . . . . . 107
10.2. Metadata ID . . . . . . . . . . . . . . . . . . . . . . . 109
10.3. Exception ID . . . . . . . . . . . . . . . . . . . . . . 109
10.4. Validate Error ID . . . . . . . . . . . . . . . . . . . . 110
11. Security Considerations . . . . . . . . . . . . . . . . . . . 112
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 113
12.1. Normative References . . . . . . . . . . . . . . . . . . 113
12.2. Informative References . . . . . . . . . . . . . . . . . 113
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 115
1. Terminology and Conventions 5.3. IP Forwarding LFBs ........................................55
5.3.1. IPv4UcastLPM .......................................56
5.3.2. IPv4NextHop ........................................58
5.3.3. IPv6UcastLPM .......................................60
5.3.4. IPv6NextHop ........................................62
5.4. Redirect LFBs .............................................64
5.4.1. RedirectIn .........................................64
5.4.2. RedirectOut ........................................65
5.5. General Purpose LFBs ......................................66
5.5.1. BasicMetadataDispatch ..............................66
5.5.2. GenericScheduler ...................................68
6. XML for LFB Library ............................................69
7. LFB Class Use Cases ............................................97
7.1. IPv4 Forwarding ...........................................98
7.2. ARP Processing ...........................................101
8. IANA Considerations ...........................................102
8.1. LFB Class Names and LFB Class Identifiers ................103
8.2. Metadata ID ..............................................105
8.3. Exception ID .............................................106
8.4. Validate Error ID ........................................107
9. Security Considerations .......................................108
10. References ...................................................108
10.1. Normative References ....................................108
10.2. Informative References ..................................108
Appendix A. Acknowledgements ....................................110
Appendix B. Contributors ........................................110
1.1. Requirements Language 1. Introduction
[RFC3746] specifies the Forwarding and Control Element Separation
(ForCES) framework. In the framework, Control Elements (CEs)
configure and manage one or more separate Forwarding Elements (FEs)
within a Network Element (NE) by use of a ForCES protocol. [RFC5810]
specifies the ForCES protocol. [RFC5812] specifies the Forwarding
Element (FE) model. In the model, resources in FEs are described by
classes of Logical Function Blocks (LFBs). The FE model defines the
structure and abstract semantics of LFBs and provides XML schema for
the definitions of LFBs.
This document conforms to the specifications of the FE model
[RFC5812] and specifies detailed definitions of classes of LFBs,
including detailed XML definitions of LFBs. These LFBs form a base
LFB library for ForCES. LFBs in the base library are expected to be
combined to form an LFB topology for a typical router to implement IP
forwarding. It should be emphasized that an LFB is an abstraction of
functions rather than implementation details. The purpose of the LFB
definitions is to represent functions so as to provide
interoperability between separate CEs and FEs.
More LFB classes with more functions may be developed in the future
and documented by the IETF. Vendors may also develop proprietary LFB
classes as described in the FE model [RFC5812].
2. Terminology and Conventions
2.1. Requirements Language
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.2. Definitions
This document follows the terminology defined by the ForCES protocol This document follows the terminology defined by the ForCES protocol
in [RFC5810] and by the ForCES FE model in [RFC5812]. The in [RFC5810] and by the ForCES FE model in [RFC5812]. The
definitions below are repeated for clarity. definitions below are repeated for clarity.
Control Element (CE) - A logical entity that implements the ForCES Control Element (CE) - A logical entity that implements the ForCES
protocol and uses it to instruct one or more FEs on how to process protocol and uses it to instruct one or more FEs on how to process
packets. CEs handle functionality such as the execution of packets. CEs handle functionality such as the execution of
control and signaling protocols. control and signaling protocols.
Forwarding Element (FE) - A logical entity that implements the Forwarding Element (FE) - A logical entity that implements the
ForCES protocol. FEs use the underlying hardware to provide per- ForCES protocol. FEs use the underlying hardware to provide per-
packet processing and handling as directed/controlled by one or packet processing and handling as directed/controlled by one or
more CEs via the ForCES protocol. more CEs via the ForCES protocol.
ForCES Network Element (NE) - An entity composed of one or more ForCES Network Element (NE) - An entity composed of one or more
CEs and one or more FEs. To entities outside an NE, the NE CEs and one or more FEs. To entities outside an NE, the NE
represents a single point of management. Similarly, an NE usually represents a single point of management. Similarly, an NE usually
hides its internal organization from external entities. hides its internal organization from external entities.
LFB (Logical Function Block) - The basic building block that is Logical Function Block (LFB) - The basic building block that is
operated on by the ForCES protocol. The LFB is a well defined, operated on by the ForCES protocol. The LFB is a well-defined,
logically separable functional block that resides in an FE and is logically separable functional block that resides in an FE and is
controlled by the CE via ForCES protocol. The LFB may reside at controlled by the CE via the ForCES protocol. The LFB may reside
the FE's datapath and process packets or may be purely an FE at the FE's data path and process packets or may be purely an FE
control or configuration entity that is operated on by the CE. control or configuration entity that is operated on by the CE.
Note that the LFB is a functionally accurate abstraction of the Note that the LFB is a functionally accurate abstraction of the
FE's processing capabilities, but not a hardware-accurate FE's processing capabilities but not a hardware-accurate
representation of the FE implementation. representation of the FE implementation.
FE Model - The FE model is designed to model the logical FE Model - The FE model is designed to model the logical
processing functions of an FE, which is defined by the ForCES FE processing functions of an FE, which is defined by the ForCES FE
model document [RFC5812]. The FE model proposed in this document model document [RFC5812]. The FE model proposed in this document
includes three components; the LFB modeling of individual Logical includes three components: the LFB modeling of individual Logical
Functional Block (LFB model), the logical interconnection between Functional Blocks (LFB model), the logical interconnection between
LFBs (LFB topology), and the FE-level attributes, including FE LFBs (LFB topology), and the FE-level attributes, including FE
capabilities. The FE model provides the basis to define the capabilities. The FE model provides the basis to define the
information elements exchanged between the CE and the FE in the information elements exchanged between the CE and the FE in the
ForCES protocol [RFC5810]. ForCES protocol [RFC5810].
FE Topology - A representation of how the multiple FEs within a FE Topology - A representation of how the multiple FEs within a
single NE are interconnected. Sometimes this is called inter-FE single NE are interconnected. Sometimes this is called inter-FE
topology, to be distinguished from intra-FE topology (i.e., LFB topology, to be distinguished from intra-FE topology (i.e., LFB
topology). topology).
LFB Class and LFB Instance - LFBs are categorized by LFB Classes. LFB Class and LFB Instance - LFBs are categorized by LFB classes.
An LFB Instance represents an LFB Class (or Type) existence. An LFB instance represents an LFB class (or type) existence.
There may be multiple instances of the same LFB Class (or Type) in There may be multiple instances of the same LFB class (or type) in
an FE. An LFB Class is represented by an LFB Class ID, and an LFB an FE. An LFB class is represented by an LFB class ID, and an LFB
Instance is represented by an LFB Instance ID. As a result, an instance is represented by an LFB instance ID. As a result, an
LFB Class ID associated with an LFB Instance ID uniquely specifies LFB class ID associated with an LFB instance ID uniquely specifies
an LFB existence. an LFB existence.
LFB Metadata - Metadata is used to communicate per-packet state LFB Metadata - Metadata is used to communicate per-packet state
from one LFB to another, but is not sent across the network. The from one LFB to another but is not sent across the network. The
FE model defines how such metadata is identified, produced and FE model defines how such metadata is identified, produced, and
consumed by the LFBs. It defines the functionality but not how consumed by the LFBs. It defines the functionality but not how
metadata is encoded within an implementation. metadata is encoded within an implementation.
LFB Component - Operational parameters of the LFBs that must be LFB Component - Operational parameters of the LFBs that must be
visible to the CEs are conceptualized in the FE model as the LFB visible to the CEs are conceptualized in the FE model as the LFB
components. The LFB components include, for example, flags, components. The LFB components include, for example, flags,
single parameter arguments, complex arguments, and tables that the single parameter arguments, complex arguments, and tables that the
CE can read and/or write via the ForCES protocol (see below). CE can read and/or write via the ForCES protocol (see below).
LFB Topology - Representation of how the LFB instances are LFB Topology - Representation of how the LFB instances are
logically interconnected and placed along the datapath within one logically interconnected and placed along the data path within one
FE. Sometimes it is also called intra-FE topology, to be FE. Sometimes it is also called intra-FE topology, to be
distinguished from inter-FE topology. distinguished from inter-FE topology.
Data Path - A conceptual path taken by packets within the Data Path - A conceptual path taken by packets within the
forwarding plane inside an FE. Note that more than one data path forwarding plane inside an FE. Note that more than one data path
can exist within an FE. can exist within an FE.
ForCES Protocol - While there may be multiple protocols used ForCES Protocol - While there may be multiple protocols used
within the overall ForCES architecture, the term "ForCES protocol" within the overall ForCES architecture, the term "ForCES protocol"
and "protocol" refer to the Fp reference points in the ForCES and "protocol" refer to the Fp reference points in the ForCES
Framework in [RFC3746]. This protocol does not apply to CE-to-CE framework in [RFC3746]. This protocol does not apply to CE-to-CE
communication, FE-to-FE communication, or to communication between communication, FE-to-FE communication, or to communication between
FE and CE managers. Basically, the ForCES protocol works in a FE and CE managers. Basically, the ForCES protocol works in a
master-slave mode in which FEs are slaves and CEs are masters. master-slave mode in which FEs are slaves and CEs are masters.
Physical Port - A port refers to a physical media input port or Physical Port - A port refers to a physical media input port or
output port of an FE. A physical port is usually assigned with a output port of an FE. A physical port is usually assigned with a
physical port ID, abbreviated with a PHYPortID. This document physical port ID, abbreviated with a PHYPortID. This document
mainly deals with physical ports with Ethernet media. mainly deals with physical ports with Ethernet media.
Logical Port - A conceptually virtual port at data link layer (L2) Logical Port - A conceptually virtual port at the data link layer
or network layer (L3). A logical port is usually assigned with a (L2) or network layer (L3). A logical port is usually assigned
logical port ID, abbreviated with a LogicalPortID. The logical with a logical port ID, abbreviated with a LogicalPortID. The
ports can be further categorized with a L2 logical port or a L3 logical ports can be further categorized with an L2 logical port
logical port. An L2 logical port can be assigned with a L2 or an L3 logical port. An L2 logical port can be assigned with an
logical port ID, abbreviated with a L2PortID. An L3 logical port L2 logical port ID, abbreviated with an L2PortID. An L3 logical
can be assigned with a L3 logical port ID, abbreviated with a port can be assigned with an L3 logical port ID, abbreviated with
L3PortID. MAC layer VLAN ports belongs to L2 logical ports as an L3PortID. MAC-layer VLAN ports belong to logical ports, and
well as logical ports. they belong to L2 logical ports.
LFB Port - The connection points where one LFB can be connected to LFB Port - The connection points where one LFB can be connected to
another within an FE. As described in [RFC5812], the CE can another within an FE. As described in [RFC5812], the CE can
connect LFBs together by establishing connections between an connect LFBs together by establishing connections between an
output port of one LFB instance and an input port of another LFB output port of one LFB instance and an input port of another LFB
instance. Also see Section 3.2 of [RFC5812] for more details. instance. Also see Section 3.2 of [RFC5812] for more details.
Singleton Port - A named input or output port of an LFB. This Singleton Port - A named input or output port of an LFB. This
port is referred to by a name. When the context is clear, the port is referred to by a name. When the context is clear, the
term singleton by itself is used to refer to a singleton port. term "singleton" by itself is used to refer to a singleton port.
Group Port - A named collection of input or output ports of an Group Port - A named collection of input or output ports of an
LFB. A group port is referred to by a name. Whereas, a group LFB. A group port is referred to by a name. A group port
port consists of a number of port instances, which are referred to consists of a number of port instances, which are referred to by a
by a combination of a name and an index. combination of a name and an index.
LFB Class Library - The LFB class library is a set of LFB classes LFB Class Library - The LFB class library is a set of LFB classes
that has been identified as the most common functions found in that has been identified as the most common functions found in
most FEs and hence should be defined first by the ForCES Working most FEs and hence should be defined first by the ForCES Working
Group. The LFB Class Library is defined by this document. Group. The LFB class library is defined by this document.
3. Introduction
[RFC3746] specifies Forwarding and Control Element Separation
(ForCES) framework. In the framework, Control Elements (CEs)
configure and manage one or more separate Forwarding Elements (FEs)
within a Network Element (NE) by use of a ForCES protocol. [RFC5810]
specifies the ForCES protocol. [RFC5812] specifies the Forwarding
Element (FE) model. In the model, resources in FEs are described by
classes of Logical Function Blocks (LFBs). The FE model defines the
structure and abstract semantics of LFBs, and provides XML schema for
the definitions of LFBs.
This document conforms to the specifications of the FE model
[RFC5812] and specifies detailed definitions of classes of LFBs,
including detailed XML definitions of LFBs. These LFBs form a base
LFB library for ForCES. LFBs in the base library are expected to be
combined to form an LFB topology for a typical router to implement IP
forwarding. It should be emphasized that an LFB is an abstraction of
functions rather than its implementation details. The purpose of the
LFB definitions is to represent functions so as to provide
interoperability between separate CEs and FEs.
More LFB classes with more functions may be developed in future time 3. Overview
and documented by IETF. Vendors may also develop proprietary LFB
classes as described in the FE model [RFC5812].
3.1. Scope of the Library 3.1. Scope of the Library
It is intended that the LFB classes described in this document are It is intended that the LFB classes described in this document are
designed to provide the functions of a typical router. [RFC1812] designed to provide the functions of a typical router. [RFC1812]
specifies that a typical router is expected to provide functions to: specifies that a typical router is expected to provide functions to:
(1) Interface to packet networks and implement the functions (1) Interface to packet networks and implement the functions
required by that network. These functions typically include: required by that network. These functions typically include:
* Encapsulating and decapsulating the IP datagrams with the * Encapsulating and decapsulating the IP datagrams with the
connected network framing (e.g., an Ethernet header and connected network framing (e.g., an Ethernet header and
checksum), checksum),
* Sending and receiving IP datagrams up to the maximum size * Sending and receiving IP datagrams up to the maximum size
supported by that network, this size is the network's Maximum supported by that network (this size is the network's Maximum
Transmission Unit or MTU, Transmission Unit or MTU),
* Translating the IP destination address into an appropriate * Translating the IP destination address into an appropriate
network-level address for the connected network (e.g., an network-level address for the connected network (e.g., an
Ethernet hardware address), if needed, and Ethernet hardware address), if needed, and
* Responding to network flow control and error indications, if * Responding to network flow control and error indications, if
any. any.
(2) Conform to specific Internet protocols including the Internet (2) Conform to specific Internet protocols including the Internet
Protocol (IPv4 and/or IPv6), Internet Control Message Protocol Protocol (IPv4 and/or IPv6), Internet Control Message Protocol
(ICMP), and others as necessary. (ICMP), and others as necessary.
(3) Receive and forward Internet datagrams. Important issues in (3) Receive and forward Internet datagrams. Important issues in
this process are buffer management, congestion control, and this process are buffer management, congestion control, and
fairness. fairness.
* Recognizes error conditions and generates ICMP error and * Recognize error conditions and generate ICMP error and
information messages as required. information messages as required.
* Drops datagrams whose time-to-live fields have reached zero. * Drop datagrams whose time-to-live fields have reached zero.
* Fragments datagrams when necessary to fit into the MTU of the * Fragment datagrams when necessary to fit into the MTU of the
next link or interface. next link or interface.
(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 the
manage static routing items. ability to manage static routing items.
(6) Provide network management and system support facilities, (6) Provide network management and system support facilities,
including loading, debugging, status reporting, statistcs query, including loading, debugging, status reporting, statistics
exception reporting and control. query, exception reporting, and control.
The classical IP router utilizing the ForCES framework constitutes a The classical IP router utilizing the ForCES framework constitutes a
CE running some controlling IGP and/or EGP function or static route CE running some controlling IGP and/or EGP function or static route
setup and FEs implementing using Logical Function Blocks (LFBs) setup and FEs implemented by use of Logical Function Blocks (LFBs)
conforming to the FE model[RFC5812] specifications. The CE, in conforming to the FE model [RFC5812] specification. The CE, in
conformance to the ForCES protocol[RFC5810] and the FE model conformance to the ForCES protocol [RFC5810] and the FE model
[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 media
media will have different ways for encapsulating outgoing frames and 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. Future documents may deal with
with other type of media. This document will also interchangeably other types of media. This document will also interchangeably refer
refer to a port to be an abstraction that constitutes a PHY and a MAC to a port as an abstraction that constitutes a physical layer (PHY)
as described by the LFBs like EtherPHYCop, EtherMACIn, and and a Media Access Control (MAC) layer, as described by LFBs like
EtherMACOut. EtherPHYCop, EtherMACIn, and 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 an 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
next hop LFB uses the next hop index metadata to apply the proper next-hop LFB uses the next-hop index metadata to apply the proper
headers to the IP packets, and direct them to the proper egress. headers to the IP packets and direct them to the proper egress. Note
Note that in the process of IP packets processing, in this document, that in the process of IP packet processing, in this document, we are
we are adhering to the weak-host model [RFC1122] since that is the adhering to the weak-host model [RFC1122] since that is the most
most usable model for a packet processing Network Element. usable model for a packet processing a Network Element.
3.2. Overview of LFB Classes in the Library 3.2. Overview of LFB Classes in the Library
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 what the base
looked like. These are: LFBs look like:
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 An LFB should take advantage of its independence as much as o An LFB should take advantage of its independence as much as
possible and have minimal coupling with other LFBs. The coupling possible and have minimal coupling with other LFBs. The coupling
may be from LFB attributes definitions as well as physical may be from LFB attributes definitions as well as physical
implementations. implementations.
o Unless there is a clear difference in functionality, similar o Unless there is a clear difference in functionality, similar
packet processing in the base LFB library should not be packet processing in the base LFB library should not be
represented simultaneously as two or more LFBs. For instance, it represented simultaneously as two or more LFBs. For instance, it
should not be simultaneously defined with two different LFBs for should not be simultaneously defined with two different LFBs for
the same next hop processing. Or else, it may add extra burden on the same next-hop processing. Otherwise, it may add extra burden
implementation to achieve interoperability. on 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 This 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
most popular media type with rich processing features, Ethernet Ethernet is the most popular media type with rich processing
media processing LFBs was a natural choice. Definitions for features, Ethernet media processing LFBs were a natural choice.
processing of other port media type like POS or ATM may be Definitions for processing of other port media types like Packet
incorporated in the library in future version of the document or over SONET (POS) or Asynchronous Transfer Mode (ATM) may be
in a future separate document. The following LFBs are defined incorporated in the library in future versions of this document
for Ethernet processing: or in a separate document. The following LFBs are defined 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)
* EtherEncap (Section 5.1.4) * EtherEncap (Section 5.1.4)
* EtherMACOut (Section 5.1.5) * EtherMACOut (Section 5.1.5)
skipping to change at page 12, line 17 skipping to change at page 10, line 29
packet processing. These processing processes are usually packet processing. These processing processes are usually
general to many processing locations in an FE LFB topology. The general to many processing locations in an FE LFB topology. The
following LFBs are defined for redirect processing: following LFBs are defined for redirect processing:
* BasicMetadataDispatch (Section 5.5.1) * BasicMetadataDispatch (Section 5.5.1)
* GenericScheduler (Section 5.5.2) * GenericScheduler (Section 5.5.2)
3.2.3. Sample LFB Class Application 3.2.3. Sample LFB Class Application
Although Section 7 will present use cases for LFBs defined in this Although Section 7 will present use cases for the LFBs defined in
document, this section shows a simple sample LFB class application in this document, this section shows a simple sample LFB class
advance so that readers can get a quick overlook of the LFB classes application in advance so that readers can get a quick overlook of
with the usage. the LFB classes with the usage.
Figure 1 shows a simple LFB processing path for Ethernet packets Figure 1 shows a simple LFB processing path for Ethernet packets
entered from Ethernet physical ports. entered from Ethernet physical ports.
+-----+ +------+ +-----+ +------+
| |EtherPHYIn | | from some LFB(s) which | |EtherPHYIn | | from some LFB(s) that
| |<---------------|Ether |<---------- generate Ethernet | |<---------------|Ether |<---------- generate Ethernet
| | |MACOut| packets | | |MACOut| packets
| | | LFB | | | | LFB |
|Ether| +------+ |Ether| +------+
|PHY | +------+ |PHY | +------+
|Cop | | | |Cop | | |
|LFB |EtherPHYOut | Ether| to some LFB(s) which |LFB |EtherPHYOut | Ether| to some LFB(s) that
| |--------------->| MACIn|----------> may classify Ethernet | |--------------->| MACIn|----------> may classify Ethernet
| | | LFB | packets and do IP layer | | | LFB | packets and do IP-layer
| | | | processing | | | | processing
+-----+ +------+ +-----+ +------+
Figure 1: A simple sample LFB use case Figure 1: A Simple Sample LFB Use Case
In the figure, Ethernet packets from outer networks enter via the In the figure, Ethernet packets from outer networks enter via the
EtherPHYCop LFB(Section 5.1.1), which describes Ethernet copper EtherPHYCop LFB (Section 5.1.1), which describes Ethernet copper
interface property(like the link speed) at physical layer. After interface properties (like the link speed) at the physical layer.
physical layer process, Ethernet packets are delivered to EtherMACIn After physical-layer processing, Ethernet packets are delivered to
LFB(Section 5.1.2) to describe its MAC layer processing the EtherMACIn LFB (Section 5.1.2) to describe its MAC-layer
functions(like locality check). The packets after EtherMACIn LFB may processing functions (like locality check). The packets after the
require further processing to implement various functions(like IP EtherMACIn LFB may require further processing to implement various
layer forwarding),therefore some LFBs may follow the EtherMACIn LFB functions (like IP-layer forwarding); therefore, some LFBs may follow
in topology to describe followed processing functions. the EtherMACIn LFB in topology to describe followed processing
functions.
Meanwhile, packets generated by some LFB(s) may need to be submitted Meanwhile, packets generated by some LFB(s) may need to be submitted
to outer physical networks. The process is described in the figure to outer physical networks. The process is described in the figure
by an EtherMACOut LFB(Section 5.1.5) at MAC layer and the EtherPHYCop by an EtherMACOut LFB (Section 5.1.5) at the MAC layer and the
LFB at physical layer. EtherPHYCop LFB at the physical layer.
3.3. Document Structure 3.3. Document Structure
Base type definitions, including data types, packet frame types, and Base type definitions, including data types, packet frame types, and
metadata types are presented in advance for definitions of various metadata types, are presented in advance for definitions of various
LFB classes. Section 4 (Base Types section) provides a description LFB classes. Section 4 ("Base Types") provides a description on the
on the base types used by this LFB library. To enable extensive use base types used by this LFB library. To enable extensive use of
of these base types by other LFB class definitions, the base type these base types by other LFB class definitions, the base type
definitions are provided as a separate library. definitions are provided as a separate library.
Within every group of LFB classes, a set of LFBs are defined for Within every group of LFB classes, a set of LFBs are defined for
individual function purposes. Section 5 (LFB Class Descriptions individual function purposes. Section 5 ("LFB Class Descriptions")
section) provides text descriptions on the individual LFBs. Note provides text descriptions on the individual LFBs. Note that for a
that for a complete definition of an LFB, a text description as well complete definition of an LFB, a text description and an XML
as a XML definition is required. definition are required.
LFB classes are finally defined by XML with specifications and schema LFB classes are finally defined by XML with specifications and schema
defined in the ForCES FE model[RFC5812]. Section 6 (XML LFB defined in the ForCES FE model [RFC5812]. Section 6 ("XML for LFB
Definitions section) provides the complete XML definitions of the Library") provides the complete XML definitions of the base LFB
base LFB classes library. classes library.
Section 7 provides several use cases on how some typical router Section 7 provides several use cases on how some typical router
functions can be implemented using the base LFB library defined in functions can be implemented using the base LFB library defined in
this document. this document.
4. Base Types 4. Base Types
The FE model [RFC5812] has specified predefined (built-in) atomic The FE model [RFC5812] has specified predefined (built-in) atomic
data-types as below: data types: char, uchar, int16, uint16, int32, uint32, int64, uint64,
string[N], string, byte[N], boolean, octetstring[N], float16,
char, uchar, int16, uint16, int32, uint32, int64, uint64, string[N], float32, and float64.
string, byte[N], boolean, octetstring[N], float16, float32, float64.
Note that, unlike SNMP information model SMI([RFC2578]), the FE model Note that, unlike the Simple Network Management Protocol (SNMP)
has not defined specific atomic data type for counting purpose. This information model, called the Structure of Management Information
document follows not to define specific counter types. To describe (SMI) [RFC2578], the FE model has not defined specific atomic data
LFB elements for packet statistics which actually require counters on types for counting purposes. This document also does not define
packets, an unsigned integer, like an uint32 or an uint64 is adopted. specific counter types. To describe LFB elements for packet
This document states that any LFB element defined for counter purpose statistics, which actually requires counters on packets, an unsigned
is specified to monotonically increase until it reaches a maximum integer, like an uint32 or an uint64, is adopted. This document
value, when it wraps around and starts increasing again from zero. states that any LFB element defined for counting purposes is
This document also states that it is implementation's issue how the specified to monotonically increase until it reaches a maximum value,
unsigned integer element might be maintained to cope with issues like when it wraps around and starts increasing again from zero. This
counter discontinuities when a counter wraps or is reset by any document also states that how the unsigned integer element might be
reasons. If a CE is expected to understand more meanings of the maintained to cope with issues like counter discontinuities when a
counter wraps or is reset for any reason is an implementation's
issue. If a CE is expected to understand more meanings of the
counter element than stated above, a private definition on the counter element than stated above, a private definition on the
element between CE and FE may be required. element between the CE and FE may be required.
Based on the atomic data types and with the use of type definition Based on the atomic data types and with the use of type definition
elements in the FE model XML schema, new data types, packet frame elements in the FE model XML schema, new data types, packet frame
types, and metadata types can be defined. types, and metadata types can be defined.
To define a base LFB library for typical router functions, a set of To define a base LFB library for typical router functions, a set of
base data types, frame types, and metadata types should be defined. base data types, frame types, and metadata types should be defined.
This section provides a brief description of the base types and a This section provides a brief description of the base types and a
full XML definition of them as well. full XML definition of them as well.
The base type XML definitions are provided with a separate XML The base type XML definitions are provided with a separate XML
library file named "BaseTypeLibrary". Users can refer to this library file named "BaseTypeLibrary". Users can refer to this
library by the statement: library by the statement:
<load library="BaseTypeLibrary" location="..."/> <load library="BaseTypeLibrary" location="..."/>
4.1. Data Types 4.1. Data Types
Data types defined in the base type library are categorized by types Data types defined in the base type library are categorized by the
of atomic, compound struct, and compound array. following types: atomic, compound struct, and compound array.
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 LAN speed by value types LANSpeedType LAN speed by value types
DuplexType Duplex types DuplexType Duplex types
PortStatusType The possible types 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 IPv4UcastLPM LFB IPv4UcastLPMStatsType Statistics type in IPv4UcastLPM LFB
IPv6UcastLPMStatsType Statistics type in IPv6UcastLPM 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
4.2. Frame Types 4.2. Frame Types
According to FE model [RFC5812], frame types are used in LFB According to the FE model [RFC5812], frame types are used in LFB
definitions to define packet frame types both an LFB expects at its definitions to define packet frame types that an LFB expects at its
input port and the LFB emits at its output port. The <frameDef> input port and that the LFB emits at its output port. The <frameDef>
element in the FE model is used to define a new frame type. element in the FE model is used to define a new frame type.
The following frame types are defined in the base type library: The following frame types are defined in the base type library:
Frame Name Brief Description Frame Name Brief Description
-------------- ---------------- -------------- -----------------
EthernetII An Ethernet II frame EthernetII An Ethernet II frame
ARP An ARP packet frame ARP An ARP packet frame
IPv4 An IPv4 packet frame IPv4 An IPv4 packet frame
IPv6 An IPv6 packet frame IPv6 An IPv6 packet frame
IPv4Unicast An IPv4 unicast packet frame IPv4Unicast An IPv4 unicast packet frame
IPv4Multicast An IPv4 multicast packet frame IPv4Multicast An IPv4 multicast packet frame
IPv6Unicast An IPv6 unicast packet frame IPv6Unicast An IPv6 unicast packet frame
IPv6Multicast An IPv6 multicast packet frame IPv6Multicast An IPv6 multicast packet frame
Arbitrary Any type 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 Metadata indicating a physical port ID PHYPortID 1 Metadata indicating a physical port ID
SrcMAC 2 Metadata indicating a source MAC address SrcMAC 2 Metadata indicating a source MAC address
DstMAC 3 Metadata indicating a destination MAC DstMAC 3 Metadata indicating a destination MAC
address. address
LogicalPortID 4 Metadata of a logical port ID LogicalPortID 4 Metadata of a logical port ID
EtherType 5 Metadata indicating an Ethernet type EtherType 5 Metadata indicating an Ethernet type
VlanID 6 Metadata of a VLAN ID VlanID 6 Metadata of a VLAN ID
VlanPriority 7 Metadata of a VLAN priority VlanPriority 7 Metadata of a VLAN priority
NextHopIPv4Addr 8 Metadata representing a next hop IPv4 NextHopIPv4Addr 8 Metadata representing a next-hop IPv4
address. address
NextHopIPv6Addr 9 Metadata representing a next hop IPv6 NextHopIPv6Addr 9 Metadata representing a next-hop IPv6
address. address
HopSelector 10 Metadata indicating a hop selector HopSelector 10 Metadata indicating a hop selector
ExceptionID 11 Metadata indicating exception types for ExceptionID 11 Metadata indicating exception types for
exceptional cases during LFB processing. exceptional cases during LFB processing
ValidateErrorID 12 Metadata indicating error types when a ValidateErrorID 12 Metadata indicating error types when a
packet passes validation process. packet passes validation process
L3PortID 13 Metadata indicating ID of an L3 logical L3PortID 13 Metadata indicating ID of an L3 logical
port. port
RedirectIndex 14 Metadata that CE sends to RedirectIn LFB, RedirectIndex 14 Metadata that CE sends to RedirectIn LFB,
indicating an associated packet a group indicating an associated packet a group
output port index of the LFB. output port index of the LFB
MediaEncapInfoIndex 15 A search key a packet uses to look up a MediaEncapInfoIndex 15 A search key a packet uses to look up a
table in related LFBs to select an table in related LFBs to select an
encapsulation media. encapsulation media
4.4. XML for Base Type Library 4.4. XML for Base Type Library
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0" <LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
provides="BaseTypeLibrary"> provides="BaseTypeLibrary">
<frameDefs> <frameDefs>
<frameDef> <frameDef>
<name>EthernetAll</name> <name>EthernetAll</name>
skipping to change at page 22, line 32 skipping to change at page 21, line 7
group output port of EtherClassifier LFB to output. group output port of EtherClassifier LFB to output.
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>EtherDispatchTableType</name> <name>EtherDispatchTableType</name>
<synopsis> <synopsis>
Data type defined for Ethernet dispatch table in Data type defined for Ethernet dispatch table in
EtherClassifier LFB. The table is composed of an array EtherClassifier LFB. The table is composed of an array
of entries with EtherDispatchEntryType data type. of entries with EtherDispatchEntryType data type.
</synopsis> </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>Data type for VLAN ID</synopsis> <synopsis>Data type for VLAN ID</synopsis>
<atomic> <atomic>
skipping to change at page 23, line 15 skipping to change at page 21, line 38
<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> <synopsis>
Data type for entry of VLAN input table in EtherClassifier Data type for entry of VLAN input table in EtherClassifier
LFB. Each entry of the table contains an incoming port ID, LFB. Each entry of the table contains an incoming port ID,
a VLAN ID and a logical port ID. Every input packet is a VLAN ID and a logical port ID. Every input packet is
assigned with a new logical port ID according to the assigned with a new logical port ID according to the
packet incoming port ID and the VLAN ID. packet incoming port ID and the VLAN ID.
</synopsis> </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">
skipping to change at page 23, line 50 skipping to change at page 22, line 25
<name>LogicalPortID</name> <name>LogicalPortID</name>
<synopsis>The 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> <synopsis>
Data type for the VLAN input table in EtherClassifier Data type for the VLAN input table in EtherClassifier
LFB. The table is composed of an array of entries with LFB. The table is composed of an array of entries with
VlanInputTableEntryType. VlanInputTableEntryType.
</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> <synopsis>
Data type for entry of statistics table in EtherClassifier Data type for entry of statistics table in EtherClassifier
LFB. LFB.
skipping to change at page 26, line 11 skipping to change at page 24, line 34
<synopsis> <synopsis>
Number of packets with bad hop limit. Number of packets with bad hop limit.
</synopsis> </synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv4PrefixInfoType</name> <name>IPv4PrefixInfoType</name>
<synopsis>Data type for entry of IPv4 longest prefix match <synopsis>Data type for entry of IPv4 longest prefix match
table in IPv4UcastLPM LFB. The destination IPv4 address table in IPv4UcastLPM LFB. The destination IPv4 address
of every input packet is used as a search key to look up of every input packet is used as a search key to look up
the table to find out a next hop selector.</synopsis> the table to find out a next-hop selector.</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>IPv4Address</name> <name>IPv4Address</name>
<synopsis>The destination IPv4 address</synopsis> <synopsis>The destination 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>
skipping to change at page 27, line 41 skipping to change at page 26, line 15
<synopsis> <synopsis>
A reserved bit space mainly for purpose of padding A reserved bit space mainly for purpose of padding
and packing efficiency. and packing efficiency.
</synopsis> </synopsis>
<typeRef>uchar</typeRef> <typeRef>uchar</typeRef>
</component> </component>
<component componentID="6"> <component componentID="6">
<name>HopSelector</name> <name>HopSelector</name>
<synopsis> <synopsis>
The HopSelector produced by the prefix matching LFB, The HopSelector produced by the prefix matching LFB,
which will be output to downstream LFB to find next which will be output to downstream LFB to find next-
hop information. hop information.
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv4PrefixTableType</name> <name>IPv4PrefixTableType</name>
<synopsis> <synopsis>
Data type for IPv4 longest prefix match table in Data type for IPv4 longest prefix match table in
IPv4UcastLPM LFB. Entry of the table is IPv4UcastLPM LFB. Entry of the table is
of IPv4PrefixInfoType data type. of IPv4PrefixInfoType data type.
</synopsis> </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> <synopsis>
Data type for statistics in IPv4UcastLPM LFB. Data type for statistics in IPv4UcastLPM LFB.
skipping to change at page 28, line 38 skipping to change at page 27, line 15
<synopsis> <synopsis>
Number of packets with no route found. Number of packets with no route found.
</synopsis> </synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv6PrefixInfoType</name> <name>IPv6PrefixInfoType</name>
<synopsis>Data type for entry of IPv6 longest prefix match <synopsis>Data type for entry of IPv6 longest prefix match
table in IPv6UcastLPM LFB. The destination IPv6 address table in IPv6UcastLPM LFB. The destination IPv6 address
of every input packet is used as a search key to look up of every input packet is used as a search key to look up
the table to find out a next hop selector.</synopsis> the table to find out a next-hop selector.</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>IPv6Address</name> <name>IPv6Address</name>
<synopsis>The destination IPv6 address</synopsis> <synopsis>The destination 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="32"/> <allowedRange min="0" max="128"/>
</rangeRestriction> </rangeRestriction>
</atomic> </atomic>
</component> </component>
<component componentID="3"> <component componentID="3">
<name>ECMPFlag</name> <name>ECMPFlag</name>
<synopsis>ECMP flag</synopsis> <synopsis>ECMP flag</synopsis>
<atomic> <atomic>
<baseType>boolean</baseType> <baseType>boolean</baseType>
<specialValues> <specialValues>
<specialValue value="false"> <specialValue value="false">
skipping to change at page 30, line 7 skipping to change at page 28, line 32
<synopsis> <synopsis>
A reserved bit space mainly for purpose of padding A reserved bit space mainly for purpose of padding
and packing efficiency. and packing efficiency.
</synopsis> </synopsis>
<typeRef>uchar</typeRef> <typeRef>uchar</typeRef>
</component> </component>
<component componentID="6"> <component componentID="6">
<name>HopSelector</name> <name>HopSelector</name>
<synopsis> <synopsis>
The HopSelector produced by the prefix matching LFB, The HopSelector produced by the prefix matching LFB,
which will be output to downstream LFB to find next which will be output to downstream LFB to find next-
hop information. hop information.
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv6PrefixTableType</name> <name>IPv6PrefixTableType</name>
<synopsis> <synopsis>
Data type for IPv6 longest prefix match table in Data type for IPv6 longest prefix match table in
IPv6UcastLPM LFB. Entry of the table is IPv6UcastLPM LFB. Entry of the table is
of IPv6PrefixInfoType data type. of IPv6PrefixInfoType data type.
</synopsis> </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>Data type for statistics in IPv6UcastLPM LFB <synopsis>Data type for statistics in IPv6UcastLPM LFB
</synopsis> </synopsis>
skipping to change at page 31, line 4 skipping to change at page 29, line 30
<synopsis> <synopsis>
Number of packets with no route found. Number of packets with no route found.
</synopsis> </synopsis>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv4NextHopInfoType</name> <name>IPv4NextHopInfoType</name>
<synopsis> <synopsis>
Data type for entry of IPv4 next hop information table Data type for entry of IPv4 next-hop information table
in IPv4NextHop LFB. The table uses a hop selector in IPv4NextHop LFB. The table uses a hop selector
received from upstream LFB as a search key to look up received from upstream LFB as a search key to look up
index of the table to find the next hop information. index of the table to find the next-hop information.
</synopsis> </synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>L3PortID</name> <name>L3PortID</name>
<synopsis> <synopsis>
The ID of the logical output port that is to pass The ID of the logical output port that is to pass
onto downstream LFB, indicating what port to the onto downstream LFB, indicating what port to the
neighbor is as defined by L3. neighbor is as defined by L3.
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>MTU</name> <name>MTU</name>
<synopsis> <synopsis>
Maximum Transmission Unit for outgoing port Maximum Transmission Unit for outgoing port
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="3"> <component componentID="3">
<name>NextHopIPAddr</name> <name>NextHopIPAddr</name>
<synopsis>The next hop IPv4 address</synopsis> <synopsis>The 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> <synopsis>
The index passed onto a downstream encapsulation The index passed onto a downstream encapsulation
LFB, used there as a search key to lookup further LFB, used there as a search key to lookup further
encapsulation information. encapsulation information.
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
skipping to change at page 32, line 6 skipping to change at page 30, line 32
instance in the group output port of the LFB to instance in the group output port of the LFB to
output. output.
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv4NextHopTableType</name> <name>IPv4NextHopTableType</name>
<synopsis> <synopsis>
Data type for IPv4 next hop table in IPv4NextHop LFB. Data type for IPv4 next-hop table in IPv4NextHop LFB.
Entry of the table is of IPv4NextHopInfoType data type. Entry of the table is of IPv4NextHopInfoType data type.
</synopsis> </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> <synopsis>
Data type for entry of IPv6 next hop information table Data type for entry of IPv6 next-hop information table
in IPv6NextHop LFB. The table uses a hop selector in IPv6NextHop LFB. The table uses a hop selector
received from upstream LFB as a search key to look up received from upstream LFB as a search key to look up
index of the table to find the next hop information. index of the table to find the next-hop information.
</synopsis> </synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>L3PortID</name> <name>L3PortID</name>
<synopsis> <synopsis>
The ID of the logical output port that is to pass The ID of the logical output port that is to pass
onto downstream LFB, indicating what port to the onto downstream LFB, indicating what port to the
neighbor is as defined by L3. neighbor is as defined by L3.
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
<name>MTU</name> <name>MTU</name>
<synopsis> <synopsis>
Maximum Transmission Unit for outgoing port Maximum Transmission Unit for outgoing port
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="3"> <component componentID="3">
<name>NextHopIPAddr</name> <name>NextHopIPAddr</name>
<synopsis>The next hop IPv6 address</synopsis> <synopsis>The 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> <synopsis>
The index passed onto a downstream encapsulation The index passed onto a downstream encapsulation
LFB, used there as a search key to lookup further LFB, used there as a search key to lookup further
encapsulation information. encapsulation information.
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
skipping to change at page 33, line 17 skipping to change at page 31, line 46
The index for the IPv6NextHop LFB to choose an instance The index for the IPv6NextHop LFB to choose an instance
in the group output port of the LFB to output. in the group output port of the LFB to output.
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>IPv6NextHopTableType</name> <name>IPv6NextHopTableType</name>
<synopsis> <synopsis>
Data type for IPv6 next hop table in IPv6NextHop LFB. Data type for IPv6 next-hop table in IPv6NextHop LFB.
Entry of the table is of IPv6NextHopInfoType data type. Entry of the table is of IPv6NextHopInfoType data type.
</synopsis> </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> <synopsis>
Data type for entry of Ethernet encapsulation table in Data type for entry of Ethernet encapsulation table in
EtherEncap LFB. The LFB uses the MediaEncapInfoIndex EtherEncap LFB. The LFB uses the MediaEncapInfoIndex
received from upstream LFB as index of the table to received from upstream LFB as index of the table to
find encapsulation information of every packet. find encapsulation information of every packet.
</synopsis> </synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>DstMac</name> <name>DstMac</name>
<synopsis> <synopsis>
Destination MAC address for Ethernet encapsulation of Destination MAC address for Ethernet encapsulation of
the packet. the packet.
</synopsis> </synopsis>
skipping to change at page 34, line 26 skipping to change at page 33, line 7
<synopsis> <synopsis>
The L2 logical output port ID for the packet. The L2 logical output port ID for the packet.
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>EncapTableType</name> <name>EncapTableType</name>
<synopsis> <synopsis>
Data type for Ethernet encapsulation table in Etherencap Data type for Ethernet encapsulation table in EtherEncap
LFB. Entry of the table is of EncapTableEntryType data LFB. Entry of the table is of EncapTableEntryType data
type. type.
</synopsis> </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> <synopsis>
Data type for entry of metadata dispatch table used in Data type for entry of metadata dispatch table used in
BasicMetadataDispatch LFB. The LFB uses a metadata value BasicMetadataDispatch LFB. The LFB uses a metadata value
as a search key to look up the table to find an index of as a search key to look up the table to find an index of
the LFB group output port to output the packet. the LFB group output port to output the packet.
</synopsis> </synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>MetadataValue</name> <name>MetadataValue</name>
<synopsis>The value of the dispatch metadata</synopsis> <synopsis>The value of the dispatch metadata</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="2"> <component componentID="2">
skipping to change at page 35, line 4 skipping to change at page 33, line 33
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>MetadataValue</name> <name>MetadataValue</name>
<synopsis>The value of the dispatch metadata</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> <synopsis>
Index of a group output port for outgoing packets. Index of a group output port for outgoing packets.
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>MetadataDispatchTableType</name> <name>MetadataDispatchTableType</name>
<synopsis> <synopsis>
Data type for metadata dispatch table used in Data type for metadata dispatch table used in
BasicMetadataDispatch LFB. Metadata value of BasicMetadataDispatch LFB. Metadata value of
the table is also defined as a content key field. the table is also defined as a content key field.
</synopsis> </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>
skipping to change at page 36, line 18 skipping to change at page 34, line 47
<name>QueueDepthInBytes</name> <name>QueueDepthInBytes</name>
<synopsis>Current queue depth in bytes</synopsis> <synopsis>Current queue depth in bytes</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>QueueStatsTableType</name> <name>QueueStatsTableType</name>
<synopsis> <synopsis>
Data type for queue statistics table in GenericScheduler Data type for queue statistics table in GenericScheduler
LFB. Entry of the table is of QueueStatsType data type. LFB. Entry of the table is of QueueStatsType data type.
</synopsis> </synopsis>
<array type="variable-size"> <array type="variable-size">
<typeRef>QueueStatsType</typeRef> <typeRef>QueueStatsType</typeRef>
</array> </array>
</dataTypeDef> </dataTypeDef>
</dataTypeDefs> </dataTypeDefs>
<metadataDefs> <metadataDefs>
<metadataDef> <metadataDef>
<name>PHYPortID</name> <name>PHYPortID</name>
<synopsis>Metadata indicating physical port ID</synopsis> <synopsis>Metadata indicating physical port ID</synopsis>
<metadataID>1</metadataID> <metadataID>1</metadataID>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</metadataDef> </metadataDef>
<metadataDef> <metadataDef>
skipping to change at page 37, line 25 skipping to change at page 36, line 6
</metadataDef> </metadataDef>
<metadataDef> <metadataDef>
<name>VlanPriority</name> <name>VlanPriority</name>
<synopsis>Metadata of VLAN priority</synopsis> <synopsis>Metadata of 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> <synopsis>
Metadata representing a next hop IPv4 address 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> <synopsis>
Metadata representing a next hop IPv6 address 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>Metadata indicating a hop selector</synopsis> <synopsis>Metadata indicating a hop selector</synopsis>
<metadataID>10</metadataID> <metadataID>10</metadataID>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</metadataDef> </metadataDef>
skipping to change at page 39, line 20 skipping to change at page 37, line 49
</synopsis> </synopsis>
</specialValue> </specialValue>
<specialValue value="8"> <specialValue value="8">
<name>IPv6NextHeaderHBH</name> <name>IPv6NextHeaderHBH</name>
<synopsis> <synopsis>
Exception case: packet with next header set to Exception case: packet with next header set to
Hop-by-Hop. Hop-by-Hop.
</synopsis> </synopsis>
</specialValue> </specialValue>
<specialValue value="9"> <specialValue value="9">
<name>SrcAddressExecption</name> <name>SrcAddressException</name>
<synopsis> <synopsis>
Exception case: packet with exceptional source Exception case: packet with exceptional source
address. address.
</synopsis> </synopsis>
</specialValue> </specialValue>
<specialValue value="10"> <specialValue value="10">
<name>DstAddressExecption</name> <name>DstAddressException</name>
<synopsis> <synopsis>
Exception case: packet with exceptional destination Exception case: packet with exceptional destination
address. address.
</synopsis> </synopsis>
</specialValue> </specialValue>
<specialValue value="11"> <specialValue value="11">
<name>LPMLookupFailed</name> <name>LPMLookupFailed</name>
<synopsis> <synopsis>
Exception case: packet failed the LPM table lookup Exception case: packet failed the LPM table lookup
in a prefix match LFB. in a prefix match LFB.
skipping to change at page 39, line 50 skipping to change at page 38, line 31
<specialValue value="12"> <specialValue value="12">
<name>HopSelectorInvalid</name> <name>HopSelectorInvalid</name>
<synopsis> <synopsis>
Exception case: HopSelector for the packet is Exception case: HopSelector for the packet is
invalid. invalid.
</synopsis> </synopsis>
</specialValue> </specialValue>
<specialValue value="13"> <specialValue value="13">
<name>NextHopLookupFailed</name> <name>NextHopLookupFailed</name>
<synopsis> <synopsis>
Exception case: packet failed lookup of a next hop Exception case: packet failed lookup of a next-hop
table even though HopSelector is valid. table even though HopSelector is valid.
</synopsis> </synopsis>
</specialValue> </specialValue>
<specialValue value="14"> <specialValue value="14">
<name>FragRequired</name> <name>FragRequired</name>
<synopsis> <synopsis>
Exception case: packet fragmentation is required Exception case: packet fragmentation is required
</synopsis> </synopsis>
</specialValue> </specialValue>
<specialValue value="15"> <specialValue value="15">
<name>MetadataNoMatching</name> <name>MetadataNoMatching</name>
<synopsis> <synopsis>
skipping to change at page 43, line 4 skipping to change at page 41, line 26
<name>MediaEncapInfoIndex</name> <name>MediaEncapInfoIndex</name>
<synopsis> <synopsis>
A search key a packet uses to look up a table to select A search key a packet uses to look up a table to select
an encapsulation media. an encapsulation media.
</synopsis> </synopsis>
<metadataID>15</metadataID> <metadataID>15</metadataID>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</metadataDef> </metadataDef>
</metadataDefs> </metadataDefs>
</LFBLibrary> </LFBLibrary>
5. LFB Class Description
According to ForCES specifications, LFB (Logical Function Block) is a 5. LFB Class Descriptions
well defined, logically separable functional block that resides in an
FE, and is a functionally accurate abstraction of the FE's processing According to ForCES specifications, an LFB (Logical Function Block)
capabilities. An LFB Class (or type) is a template that represents a is a well-defined, logically separable functional block that resides
fine-grained, logically separable aspect of FE processing. Most LFBs in an FE and is a functionally accurate abstraction of the FE's
are related to packet processing in the data path. LFB classes are processing capabilities. An LFB class (or type) is a template that
the basic building blocks of the FE model. Note that [RFC5810] has represents a fine-grained, logically separable aspect of FE
already defined an 'FE Protocol LFB' which is a logical entity in processing. Most LFBs are related to packet processing in the data
each FE to control the ForCES protocol. [RFC5812] has already path. LFB classes are the basic building blocks of the FE model.
defined an 'FE Object LFB'. Information like the FE Name, FE ID, FE Note that [RFC5810] has already defined an 'FE Protocol LFB', which
State, LFB Topology in the FE are represented in this LFB. is a logical entity in each FE to control the ForCES protocol.
[RFC5812] has already defined an 'FE Object LFB'. Information like
the FE Name, FE ID, FE State, and LFB Topology in the FE are
represented in this LFB.
As specified in Section 3.1, this document focuses on the base LFB As specified in Section 3.1, this document focuses on the base LFB
library for implementing typical router functions, especially for IP library for implementing typical router functions, especially for IP
forwarding functions. As a result, LFB classes in the library are forwarding functions. As a result, LFB classes in the library are
all base LFBs to implement router forwarding. all base LFBs to implement router forwarding.
In this section, the terms "upstream LFB" and "downstream LFB" are In this section, the terms "upstream LFB" and "downstream LFB" are
used. These are used relative to an LFB to an LFB that is being used. These are used relative to the LFB that is being described.
described. An "upstream LFB" is one whose output ports are connected An "upstream LFB" is one whose output ports are connected to input
to input ports of the LFB under consideration such that output ports of the LFB under consideration such that output (typically
(typically packets with metadata) can be sent from the "upstream LFB" packets with metadata) can be sent from the "upstream LFB" to the LFB
to the LFB under consideration. Similarly, a "downstream LFB" whose under consideration. Similarly, a "downstream LFB" whose input ports
input ports are connected to output ports of the LFB under are connected to output ports of the LFB under consideration such
consideration such that the LFB under consideration can send that the LFB under consideration can send information to the
information to the "downstream LFB". Note that in some rare "downstream LFB". Note that in some rare topologies, an LFB may be
topologies, an LFB may be both upstream and downstream relative to both upstream and downstream relative to another LFB.
another LFB.
Also note that, as a default provision of [RFC5812], in FE model, all Also note that, as a default provision of [RFC5812], in the FE model,
metadata produced by upstream LFBs will pass through all downstream all metadata produced by upstream LFBs will pass through all
LFBs by default without being specified by input port or output port. downstream LFBs by default without being specified by input port or
Only those metadata that will be used (consumed) by an LFB will be output port. Only those metadata that will be used (consumed) by an
explicitly marked in input of the LFB as expected metadata. For LFB will be explicitly marked in the input of the LFB as expected
instance, in downstream LFBs of a physical layer LFB, even there is metadata. For instance, in downstream LFBs of a physical-layer LFB,
no specific metadata expected, metadata like PHYPortID produced by even if there is no specific metadata expected, metadata like
the physical layer LFB will always pass through all downstream LFBs PHYPortID produced by the physical-layer LFB will always pass through
regardless of whether the metadata has been expected by the LFBs or all downstream LFBs regardless of whether or not the metadata has
not. been expected by the LFBs.
5.1. Ethernet Processing LFBs 5.1. Ethernet-Processing LFBs
As the most popular physical and data link layer protocols, Ethernet As the most popular physical- and data-link-layer protocol, Ethernet
is widely deployed. It becomes a basic requirement for a router to is widely deployed. It becomes a basic requirement for a router to
be able to process various Ethernet data packets. be able to process various Ethernet data packets.
Note that there exist different versions of Ethernet formats, like Note that different versions of Ethernet formats exist, like Ethernet
Ethernet V2, 802.3 RAW, IEEE 802.3/802.2, IEEE 802.3/802.2 SNAP. V2, 802.3 RAW, IEEE 802.3/802.2, and IEEE 802.3/802.2 SNAP.
There also exist varieties of LAN techniques based on Ethernet, like Varieties of LAN techniques based on Ethernet also exist, like
various VLANs, MACinMAC, etc. Ethernet processing LFBs defined here various VLANs, MACinMAC, etc. Ethernet-processing LFBs defined here
are intended to be able to cope with all these variations of Ethernet are intended to be able to cope with all these variations of Ethernet
technology. technology.
There are also various types of Ethernet physical interface media. There are also various types of Ethernet physical interface media.
Among them, copper and fiber media may be the most popular ones. As Among them, copper and fiber media may be the most popular ones. As
a base LFB definition and a starting point, the document only defines a base LFB definition and a starting point, this document only
an Ethernet physical LFB with copper media. For other media defines an Ethernet physical LFB with copper media. For other media
interfaces, specific LFBs may be defined in the future versions of interfaces, specific LFBs may be defined in future versions of the
the library. 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, and 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 LFBs, via a singleton output
"EtherPHYOut". A 'PHYPortID' metadata, to indicate which physical known as "EtherPHYOut". A PHYPortID metadata, which indicates the
port the frame came into from the external world, is passed along physical port from which the frame came in from the external world,
with the frame. is passed along with the frame.
Ethernet packets are received by this LFB from upstream LFBs such as Ethernet packets are received by this LFB from upstream LFBs, such as
EtherMacOut LFBs via the singleton input known as "EtherPHYIn" before EtherMacOut LFBs, via the singleton input known as "EtherPHYIn"
being sent out onto the external world. before being sent out to the external world.
5.1.1.2. Components 5.1.1.2. Components
The AdminStatus component is defined for CE to administratively The AdminStatus component is defined for the CE to administratively
manage the status of the LFB. The CE may administratively startup or manage the status of the LFB. The CE may administratively start up
shutdown the LFB by changing the value of AdminStatus. The default or shut down the LFB by changing the value of AdminStatus. The
value is set to 'Down'. default value is set to 'Down'.
An OperStatus component captures the physical port operational An OperStatus component captures the physical port operational
status. A PHYPortStatusChanged event is defined so the LFB can status. A PHYPortStatusChanged event is defined so the LFB can
report to the CE whenever there is an operational status change of report to the CE whenever there is an operational status change of
the physical port. the physical port.
The PHYPortID component is a unique identification for a physical The PHYPortID component is a unique identification for a physical
port. It is defined as 'read-only' by CE. Its value is enumerated port. It is defined as 'read-only' by the CE. Its value is
by FE. The component will be used to produce a 'PHYPortID' metadata enumerated by FE. The component will be used to produce a PHYPortID
at the LFB output and to associate it to every Ethernet packet this metadata at the LFB output and to associate it to every Ethernet
LFB receives. The metadata will be handed to downstream LFBs for packet this LFB receives. The metadata will be handed to downstream
them to use the PHYPortID. LFBs for them to use the PHYPortID.
A group of components are defined for link speed management. The A group of components are defined for link speed management. The
AdminLinkSpeed is for CE to configure link speed for the port and the AdminLinkSpeed is for the CE to configure link speed for the port,
OperLinkSpeed is for CE to query the actual link speed in operation. and the OperLinkSpeed is for the CE to query the actual link speed in
The default value for the AdminLinkSpeed is set to auto-negotiation operation. The default value for the AdminLinkSpeed is set to auto-
mode. negotiation mode.
A group of components are defined for duplex mode management. The A group of components are defined for duplex mode management. The
AdminDuplexMode is for CE to configure proper duplex mode for the AdminDuplexMode is for the CE to configure proper duplex mode for the
port and the OperDuplexMode is for CE to query the actual duplex mode port, and the OperDuplexMode is for CE to query the actual duplex
in operation. The default value for the AdminDuplexMode is set to mode in operation. The default value for the AdminDuplexMode is set
auto-negotiation mode. to auto-negotiation mode.
A CarrierStatus component captures the status of the carrier and A CarrierStatus component captures the status of the carrier and
specifies whether the port link is operationally up. The default specifies whether the port link is operationally up. The default
value for the CarrierStatus is 'false'. value for the CarrierStatus is 'false'.
5.1.1.3. Capabilities 5.1.1.3. Capabilities
The capability information for this LFB includes the link speeds that The capability information for this LFB includes the link speeds that
are supported by the FE (SupportedLinkSpeed) as well as the supported are supported by the FE (SupportedLinkSpeed) as well as the supported
duplex modes (SupportedDuplexMode). duplex modes (SupportedDuplexMode).
5.1.1.4. Events 5.1.1.4. Events
Several events are generated. There is an event for changes in the Several events are generated. There is an event for changes in the
status of the physical port (PhyPortStatusChanged). Such an event status of the physical port (PhyPortStatusChanged). Such an event
will notify that the physical port status has been changed and the will notify that the physical port status has been changed, and the
report will include the new status of the physical port. report will include the new status of the physical port.
Another event captures changes in the operational link speed Another event captures changes in the operational link speed
(LinkSpeedChanged). Such an event will notify the CE that the (LinkSpeedChanged). Such an event will notify the CE that the
operational speed has been changed and the report will include the operational speed has been changed, and the report will include the
new negotiated operational speed. new negotiated operational speed.
A final event captures changes in the duplex mode A final event captures changes in the duplex mode
(DuplexModeChanged). Such an event will notify the CE that the (DuplexModeChanged). Such an event will notify the CE that the
duplex mode has been changed and the report will include the new duplex mode has been changed and the report will include the new
negotiated duplex mode. negotiated duplex mode.
5.1.2. EtherMACIn 5.1.2. EtherMACIn
EtherMACIn LFB abstracts an Ethernet port at MAC data link layer. EtherMACIn LFB abstracts an Ethernet port at the MAC data link layer.
This LFB describes Ethernet processing functions like MAC address This LFB describes Ethernet processing functions like checking MAC
locality check, deciding if the Ethernet packets should be bridged, address locality, deciding if the Ethernet packets should be bridged,
providing Ethernet layer flow control, etc. providing Ethernet-layer flow control, etc.
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
some Ethernet physical layer LFB, like an EtherPHYCop LFB, alongside from some Ethernet physical-layer LFB, like an EtherPHYCop LFB, along
with a metadata indicating the physical port ID that the packet with a metadata indicating the physical port ID of the port on which
arrived on. the packet arrived.
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 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,
further L3 forwarding process alongside with a PHYPortID metadata for further L3 forwarding process along with a PHYPortID metadata
indicating which physical port the packet came from. indicating the physical port from which the packet came.
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
meet the requirement that L2 bridging functions may be optionally meet the requirement that L2 bridging functions may be optionally
supported simultaneously with L3 processing and some L2 bridging LFBs supported simultaneously with L3 processing and some L2 bridging LFBs
that may be defined in the future. If the FE supports L2 bridging, that may be defined in the future. If the FE supports L2 bridging,
the CE can enable or disable it by means of a "L2BridgingPathEnable" the CE can enable or disable it by means of a "L2BridgingPathEnable"
component in the FE. If it is enabled, by also instantiating some L2 component in the FE. If it is enabled, by also instantiating some L2
bridging LFB instances following the L2BridgingPathOut, FEs are bridging LFB instances following the L2BridgingPathOut, FEs are
expected to fulfill L2 bridging functions. L2BridgingPathOut will expected to fulfill L2 bridging functions. L2BridgingPathOut will
output packets exactly the same as that in the NormalPathOut output. output packets exactly the same as in the NormalPathOut output.
This LFB can be set to work in a Promiscuous Mode, allowing all This LFB can be set to work in a promiscuous mode, allowing all
packets to pass through the LFB without being dropped. Otherwise, a packets to pass through the LFB without being dropped. Otherwise, a
locality check will be performed based on the local MAC addresses. locality check will be performed based on the local MAC addresses.
All packets that do not pass through the locality check will be All packets that do not pass through the locality check will be
dropped. dropped.
This LFB can optionally participate in Ethernet flow control in This LFB can optionally participate in Ethernet flow control in
cooperation with EtherMACOut LFB. This document does not go into the cooperation with EtherMACOut LFB. This document does not go into the
details of how this is implemented. This document also does not details of how this is implemented. This document also does not
describe how the buffers which induce the flow control messages describe how the buffers that induce the flow control messages behave
behave - it is assumed that such artifacts exist and describing them -- it is assumed that such artifacts exist, and describing them is
is out of scope in this document. out of scope in this document.
5.1.2.2. Components 5.1.2.2. Components
The AdminStatus component is defined for the CE to administratively The AdminStatus component is defined for the CE to administratively
manage the status of the LFB. The CE may administratively startup or manage the status of the LFB. The CE may administratively start up
shutdown the LFB by changing the value of AdminStatus. The default or shut down the LFB by changing the value of AdminStatus. The
value is set to 'Down'. default value is set to 'Down'.
The LocalMACAddresses component specifies the local MAC addresses The LocalMACAddresses component specifies the local MAC addresses
based on which locality checks will be made. This component is an based on which locality checks will be made. This component is an
array of MAC addresses, and of 'read-write' access permission. array of MAC addresses and of 'read-write' access permission.
An L2BridgingPathEnable component captures whether the LFB is set to An L2BridgingPathEnable component captures whether the LFB is set to
work as a L2 bridge. An FE that does not support bridging will work as an L2 bridge. An FE that does not support bridging will
internally set this flag to false, and additionally set the flag internally set this flag to false and additionally set the flag
property as read-only. The default value for the component is property as read-only. The default value for the component is
'false'. 'false'.
The PromiscuousMode component specifies whether the LFB is set to The PromiscuousMode component specifies whether the LFB is set to
work as in a promiscuous mode. The default value for the component work in a promiscuous mode. The default value for the component is
is 'false'. 'false'.
The TxFlowControl component defines whether the LFB is performing The TxFlowControl component defines whether the LFB is performing
flow control on sending packets. The default value is 'false'. Note flow control on sending packets. The default value is 'false'. Note
that the component is defined as "optional". If an FE does not that the component is defined as "optional". If an FE does not
implement the component while a CE try to configure the component to implement the component while a CE tries to configure the component
this FE, an error from FE may be responded to CE with error code to that FE, an error from the FE may be responded to the CE with an
like: 0x09(E_COMPONENT_DOES_NOT_EXIST) or 0x15(E_NOT_SUPPORTED) error code like 0x09 (E_COMPONENT_DOES_NOT_EXIST) or 0x15
depending on the FE processing. See [RFC5810] for details. (E_NOT_SUPPORTED), depending on the FE processing. See [RFC5810] for
details.
The RxFlowControl component defines whether the LFB is performing The RxFlowControl component defines whether the LFB is performing
flow control on receiving packets. The default value is 'false'.The flow control on receiving packets. The default value is 'false'.
component is also defined as "optional" one. The component is defined as "optional".
A struct component, MACInStats, defines a set of statistics for this A struct component, MACInStats, defines a set of statistics for this
LFB, including the number of received packets and the number of LFB, including the number of received packets and the number of
dropped packets. Note that this statistics component is optional to dropped packets. Note that this statistics component is optional to
implementers. If a CE tries to query the componennt while it is not implementers. If a CE tries to query the component while it is not
implemented in an FE, an error code will be responded to CE implemented in an FE, an error code will be responded to the CE
indicating the error type like: 0x09(E_COMPONENT_DOES_NOT_EXIST) or indicating the error type like 0x09 (E_COMPONENT_DOES_NOT_EXIST) or
0x15(E_NOT_SUPPORTED), depending on the FE implementation. 0x15 (E_NOT_SUPPORTED), depending on the FE implementation.
5.1.2.3. Capabilities 5.1.2.3. Capabilities
This LFB does not have a list of capabilities. This LFB does not have a list of capabilities.
5.1.2.4. Events 5.1.2.4. Events
This LFB does not have any events specified. This LFB does not have any events specified.
5.1.3. EtherClassifier 5.1.3. EtherClassifier
EtherClassifier LFB abstracts the process to decapsulate Ethernet The EtherClassifier LFB abstracts the process to decapsulate Ethernet
packets and then classify them. packets and then classify them.
5.1.3.1. Data Handling 5.1.3.1. Data Handling
This LFB describes the process of decapsulating Ethernet packets and This LFB describes the process of decapsulating Ethernet packets and
classifying them into various network layer data packets according to classifying them into various network-layer data packets according to
information included in the Ethernet packets headers. information included in the Ethernet packets headers.
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
an upstream LFB like EtherMACIn LFB. This input is also capable of from an upstream LFB like EtherMACIn LFB. This input is also capable
multiplexing to allow for multiple upstream LFBs being connected. of multiplexing to allow for multiple upstream LFBs to be connected.
For instance, when L2 bridging function is enabled in EtherMACIn LFB, For instance, when an L2 bridging function is enabled in the
some L2 bridging LFBs may be applied. In this case, some Ethernet EtherMACIn LFB, some L2 bridging LFBs may be applied. In this case,
packets after L2 processing may have to be input to EtherClassifier after L2 processing, some Ethernet packets may have to be input to
LFB for classification, while simultaneously packets directly output the EtherClassifier LFB for classification, while simultaneously,
from EtherMACIn may also need to input to this LFB. This input is packets directly output from EtherMACIn may also need to input to
capable of handling such a case. Usually, all expected Ethernet this LFB. This input is capable of handling such a case. Usually,
Packets will be associated with a PHYPortID metadata, indicating the all expected Ethernet packets will be associated with a PHYPortID
physical port the packet comes from. In some cases, for instance, metadata, indicating the physical port from which the packet comes.
like in a MACinMAC case, a LogicalPortID metadata may be expected to In some cases, for instance, in a MACinMAC case, a LogicalPortID
associate with the Ethernet packet to further indicate which logical metadata may be expected to associate with the Ethernet packet to
port the Ethernet packet belongs to. Note that PHYPortID metadata is further indicate the logical port to which the Ethernet packet
always expected while LogicalPortID metadata is optionally expected. belongs. Note that PHYPortID metadata is 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 type of protocol the port group. Because there may be various types 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:
o There is no matching when classifying the packet. o There is no matching when classifying the packet.
Usually the exception out port may point to no where, indicating Usually, the ExceptionOut port may point to nowhere, indicating
packets with exceptions are dropped, while in some cases, the output packets with exceptions are dropped, while in some cases, the output
may be pointed to the path to the CE for further processing, may be pointed to the path to the CE for further processing,
depending on individual implementations. depending on individual implementations.
5.1.3.2. Components 5.1.3.2. Components
An EtherDispatchTable array component is defined in the LFB to An EtherDispatchTable array component is defined in the LFB to
dispatch every Ethernet packet to the output group according to the dispatch every Ethernet packet to the output group according to the
logical port ID assigned by the VlanInputTable to the packet and the logical port ID assigned by the VlanInputTable to the packet and the
Ethernet type in the Ethernet packet header. Each row of the array Ethernet type in the Ethernet packet header. Each row of the array
is a struct containing a Logical Port ID, an EtherType and an Output is a struct containing a logical port ID, an EtherType and an output
Index. With the CE configuring the dispatch table, the LFB can be index. With the CE configuring the dispatch table, the LFB can be
expected to classify various network layer protocol type packets and expected to classify various network-layer protocol type packets and
output them at different output ports. It is expected that the LFB output them at different output ports. It is expected that the LFB
classify packets according to protocols like IPv4, IPv6, MPLS, ARP, classify packets according to protocols like IPv4, IPv6, MPLS,
ND, etc. Address Resolution Protocol (ARP), Neighbor Discovery (ND), etc.
A VlanInputTable array component is defined in the LFB to classify A VlanInputTable array component is defined in the LFB to classify
VLAN Ethernet packets. Each row of the array is a struct containing VLAN Ethernet packets. Each row of the array is a struct containing
an Incoming Port ID, a VLAN ID and a Logical Port ID. According to an incoming port ID, a VLAN ID, and a logical port ID. According to
IEEE VLAN specifications, all Ethernet packets can be recognized as IEEE VLAN specifications, all Ethernet packets can be recognized as
VLAN types by defining that if there is no VLAN encapsulation in a VLAN types by defining that if there is no VLAN encapsulation in a
packet, a case with VLAN tag 0 is considered. Every input packet is packet, a case with VLAN tag 0 is considered. Every input packet is
assigned with a new LogicalPortID according to the packet incoming assigned with a new LogicalPortID according to the packet's incoming
port ID and the VLAN ID. A packet incoming port ID is defined as a port ID and the VLAN ID. A packet's incoming port ID is defined as a
logical port ID if a logical port ID is associated with the packet, logical port ID if a logical port ID is associated with the packet or
or a physical port ID if no logical port ID associated. The VLAN ID a physical port ID if no logical port ID is associated. The VLAN ID
is exactly the VLAN ID in the packet if it is a VLAN packet, or 0 if is exactly the VLAN ID in the packet if it is a VLAN packet, or 0 if
it is not. Note that a logical port ID of a packet may be rewritten it is not. Note that a logical port ID of a packet may be rewritten
with a new one by the VlanInputTable processing. with a new one by the VlanInputTable processing.
Note that the logical port ID and physical port ID mentioned above Note that the logical port ID and physical port ID mentioned above
are all originally configured by CE, and are globally effective are all originally configured by the CE, and are globally effective
within a ForCES NE (Network Element). To distinguish a physical port within a ForCES NE (Network Element). To distinguish a physical port
ID from a logical port ID in the incoming port ID field of the ID from a logical port ID in the incoming port ID field of the
VlanInputTable, physical port ID and logical port ID must be assigned VlanInputTable, physical port ID and logical port ID must be assigned
with separate number spaces. with separate number spaces.
An array component, EtherClassifyStats, defines a set of statistics An array component, EtherClassifyStats, defines a set of statistics
for this LFB, measuring the number of packets per EtherType. Each for this LFB, measuring the number of packets per EtherType. Each
row of the array is a struct containing an EtherType and a Packet row of the array is a struct containing an EtherType and a packet
number.Note that this statistics component is optional to number. Note that this statistics component is optional to
implementers. implementers.
5.1.3.3. Capabilities 5.1.3.3. Capabilities
This LFB does not have a list of capabilities. This LFB does not have a list of capabilities.
5.1.3.4. Events 5.1.3.4. Events
This LFB has no events specified. This LFB has no events specified.
5.1.4. EtherEncap 5.1.4. EtherEncap
The EtherEncap LFB abstracts the process to replace or attach The EtherEncap LFB abstracts the process to replace or attach
appropriate Ethernet headers to the packet. appropriate Ethernet headers to the packet.
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 IPv4NextHop, IPv6NextHop, BasicMetadataDispatch, or any LFB
any LFB which requires to output packets for Ethernet encapsulation. that requires output packets for Ethernet encapsulation. The LFB
The LFB always expects from upstream LFBs the MediaEncapInfoIndex always expects from upstream LFBs the MediaEncapInfoIndex metadata,
metadata which is used as a search key to lookup the encapsulation which is used as a search key to look up the encapsulation table
table EncapTable by the search key matching the table index. An EncapTable by the search key matching the table index. An input
input packet may also optionally receive a VLAN priority metadata, packet may also optionally receive a VLAN priority metadata,
indicating that the packet is originally with a priority value. The indicating that the packet originally had a priority value. The
priority value will be loaded back to the packet when encapsulating. priority value will be loaded back to the packet when encapsulating.
The optional VLAN priority metadata is defined with a default value The optional VLAN priority metadata is defined with a default value
0. of 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 is known as "SuccessOut". Upon a
table lookup, the destination and source MAC addresses, and the successful table lookup, the destination and source MAC addresses and
logical media port (L2PortID) are found in the matching table entry. the logical media port (L2PortID) are found in the matching table
The CE may set the VlanID in case VLANs are used. By default the entry. The CE may set the VlanID in case VLANs are used. By
table entry for VlanID of 0 is used as per IEEE rules. Whatever the default, the table entry for VlanID of 0 is used as per IEEE rules
value of VlanID is, if the input metadata VlanPriority is non-zero, [IEEE.802-1Q]. Whatever the value of VlanID, if the input metadata
the packet will have a VLAN tag. If the VlanPriority and the VlanID VlanPriority is non-zero, the packet will have a VLAN tag. If the
are all zero, there is no VLAN tag to this packet. After replacing VlanPriority and the VlanID are all zero, there is no VLAN tag for
or attaching the appropriate Ethernet headers to the packet is this packet. After replacing or attaching the appropriate Ethernet
complete, the packet is passed out on the "SuccessOut" LFB port to a headers to the packet is complete, the packet is passed out on the
downstream LFB instance alongside with the L2PortID. "SuccessOut" LFB port to a downstream LFB instance along with the
L2PortID.
The second singleton output known as "ExceptionOut", which will The second singleton output is known as "ExceptionOut" and will
output packets for which the table lookup fails, along with an output packets for which the table lookup fails, along with an
additional ExceptionID metadata. Currently defined exception types additional ExceptionID metadata. Currently defined exception types
only include the following case: only include the following cases:
o The MediaEncapInfoIndex value of the packet is invalid and can not o The MediaEncapInfoIndex value of the packet is invalid and can not
be allocated in the EncapTable. be allocated in the EncapTable.
o The packet failed lookup of the EncapTable table even though the o The packet failed lookup of the EncapTable table even though the
MediaEncapInfoIndex is valid. MediaEncapInfoIndex is valid.
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. This
to allow for resolution of the L2 headers, if needed, to be made at allows for resolution of the L2 headers, if needed, to be made at the
the L2 encapsulation level in this case (Ethernet) via ARP, or ND (or 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
next hop LFB is also passed to the exception handling. Such an IP the next-hop LFB is also passed to the exception handling. Such an
address could be used to do activities such as ARP or ND by the IP address could be used to do activities such as ARP or ND by the
handler it is passed to. handler to which it is passed.
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 next hop 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 on
possible to be on per-media-port basis or resides on a different FE a per-media-port basis, resides on a different FE, or needs L2 header
or in cases where L2 header resolution is needed, then the model resolution, then it makes sense for the model to use a
makes sense to use a BasicMetadataDispatch LFB to fan out to BasicMetadataDispatch LFB to fan out to different LFB instances. If
different LFB instances. If there is a direct egress port point, there is a direct egress port point, then it makes sense for the
then the model makes sense to have a downstream LFB instance being an model to have a downstream LFB instance be 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
This LFB does not have a list of capabilities. This LFB does not have a list of capabilities.
5.1.4.4. Events 5.1.4.4. Events
This LFB does not have any events specified. This LFB does not have any events specified.
5.1.5. EtherMACOut 5.1.5. EtherMACOut
EtherMACOut LFB abstracts an Ethernet port at MAC data link layer. The EtherMACOut LFB abstracts an Ethernet port at the MAC data link
This LFB describes Ethernet packet output process. Ethernet output layer. This LFB describes Ethernet packet output process. Ethernet
functions are closely related to Ethernet input functions, therefore output functions are closely related to Ethernet input functions;
many components defined in this LFB are as aliases of EtherMACIn LFB therefore, many components defined in this LFB are aliases of
components. EtherMACIn LFB components.
5.1.5.1. Data Handling 5.1.5.1. Data Handling
The LFB is expected to receive all types of Ethernet packets, via a The LFB is expected to receive all types of Ethernet packets (via a
singleton input known as "EtherPktsIn", which are usually output from singleton input known as "EtherPktsIn"), which are usually output
an Ethernet encapsulation LFB, alongside with a metadata indicating from an Ethernet encapsulation LFB along with a metadata indicating
the physical port ID that the packet will go through. the ID of the physical port that the packet will go through.
The LFB is defined with a singleton output port known as The LFB is defined with a singleton output port known as
"EtherPktsOut". All Output packets are in Ethernet format, possibly "EtherPktsOut". All output packets are in Ethernet format, possibly
with various Ethernet types, alongside with a metadata indicating the with various Ethernet types, along with a metadata indicating the ID
physical port ID the packet is to go through. This output links to a of the physical port that the packet is to go through. This output
downstream LFB that is usually an Ethernet physical LFB like links to a downstream LFB that is usually an Ethernet physical LFB
EtherPHYcop LFB. like the EtherPHYCop LFB.
This LFB can optionally participate in Ethernet flow control in This LFB can optionally participate in Ethernet flow control in
cooperation with EtherMACIn LFB. This document does not go into the cooperation with the EtherMACIn LFB. This document does not go into
details of how this is implemented. This document also does not the details of how this is implemented. This document also does not
describe how the buffers which induce the flow control messages describe how the buffers that induce the flow control messages behave
behave - it is assumed that such artifacts exist and describing them -- it is assumed that such artifacts exist, but describing them is
is out of scope in this document. out of the scope of this document.
Note that as a base definition, functions like multiple virtual MAC Note that as a base definition, functions like multiple virtual MAC
layers are not supported in this LFB version. It may be supported in layers are not supported in this LFB version. It may be supported in
the future by defining a subclass or a new version of this LFB. the future by defining a subclass or a new version of this LFB.
5.1.5.2. Components 5.1.5.2. Components
The AdminStatus component is defined for CE to administratively The AdminStatus component is defined for the CE to administratively
manage the status of the LFB. The CE may administratively startup or manage the status of the LFB. The CE may administratively start up
shutdown the LFB by changing the value of AdminStatus. The default or shut down the LFB by changing the value of AdminStatus. The
value is set to 'Down'. Note that this component is defined as an default value is set to 'Down'. Note that this component is defined
alias of the AdminStatus component in the EtherMACIn LFB. This as an alias of the AdminStatus component in the EtherMACIn LFB. This
infers that an EtherMACOut LFB usually coexists with an EtherMACIn infers that an EtherMACOut LFB usually coexists with an EtherMACIn
LFB, both of which share the same administrative status management by LFB, both of which share the same administrative status management by
CE. Alias properties as defined in the ForCES FE model [RFC5812] the CE. Alias properties, as defined in the ForCES FE model
will be used by CE to declare the target component this alias refers, [RFC5812], will be used by the CE to declare the target component to
which include the target LFB class and instance IDs as well as the which the alias refers, which includes the target LFB class and
path to the target component. instance IDs as well as the path to the target component.
The MTU component defines the maximum transmission unit. The MTU component defines the maximum transmission unit.
The optinal TxFlowControl component defines whether the LFB is The optional TxFlowControl component defines whether or not the LFB
performing flow control on sending packets. The default value is is performing flow control on sending packets. The default value is
'false'. Note that this component is defined as an alias of 'false'. Note that this component is defined as an alias of the
TxFlowControl component in the EtherMACIn LFB. TxFlowControl component in the EtherMACIn LFB.
The optional RxFlowControl component defines whether the LFB is The optional RxFlowControl component defines whether or not the LFB
performing flow control on receiving packets. The default value is is performing flow control on receiving packets. The default value
'false'. Note that this component is defined as an alias of is 'false'. Note that this component is defined as an alias of the
RxFlowControl component in the EtherMACIn LFB. RxFlowControl component in the EtherMACIn LFB.
A struct component, MACOutStats, defines a set of statistics for this A struct component, MACOutStats, defines a set of statistics for this
LFB, including the number of transmitted packets and the number of LFB, including the number of transmitted packets and the number of
dropped packets. This statistics component is optional to dropped packets. This statistics component is optional to
impleneters. implementers.
5.1.5.3. Capabilities 5.1.5.3. Capabilities
This LFB does not have a list of capabilities. This LFB does not have a list of capabilities.
5.1.5.4. Events 5.1.5.4. Events
This LFB does not have any events specified. This LFB does not have any events specified.
5.2. IP Packet Validation LFBs 5.2. IP Packet Validation LFBs
The LFBs are defined to abstract IP packet validation process. An The LFBs are defined to abstract the IP packet validation process.
IPv4Validator LFB is specifically for IPv4 protocol validation and an An IPv4Validator LFB is specifically for IPv4 protocol validation,
IPv6Validator LFB for IPv6. and an IPv6Validator LFB is specifically for IPv6.
5.2.1. IPv4Validator 5.2.1. IPv4Validator
The IPv4Validator LFB performs IPv4 packets validation. The IPv4Validator LFB performs IPv4 packet validation.
5.2.1.1. Data Handling 5.2.1.1. Data Handling
This LFB performs IPv4 validation according to [RFC1812] and its This LFB performs IPv4 validation according to [RFC1812] and its
updates. The IPv4 packet will be output to the corresponding LFB updates. The IPv4 packet will be output to the corresponding LFB
port the indication whether the packet is unicast, multicast or port, indicating whether the packet is unicast or multicast or
whether an exception has occurred or the validation failed. whether an exception has occurred or the validation failed.
This LFB always expects, as input, packets which have been indicated This LFB always expects, as input, packets that have been indicated
as IPv4 packets by an upstream LFB, like an EtherClassifier LFB. as IPv4 packets by an upstream LFB, like an EtherClassifier LFB.
There is no specific metadata expected by the input of the LFB. There is no specific metadata expected by the input of the LFB.
Four output LFB ports are defined. Four output LFB ports are defined.
All validated IPv4 unicast packets will be output at the singleton All validated IPv4 unicast packets will be output at the singleton
port known as "IPv4UnicastOut". All validated IPv4 multicast packets port known as "IPv4UnicastOut". All validated IPv4 multicast packets
will be output at the singleton port known as "IPv4MulticastOut" will be output at the singleton port known as "IPv4MulticastOut"
port. port.
A singleton port known as "ExceptionOut" is defined to output packets A singleton port known as "ExceptionOut" is defined to output packets
which have been validated as exception packets. An exception ID that have been validated as exception packets. An exception ID
metadata is produced to indicate what has caused the exception. An metadata is produced to indicate what has caused the exception. An
exception case is the case when a packet needs further processing exception case is the case when a packet needs further processing
before being normally forwarded. Currently defined exception types before being normally forwarded. Currently defined exception types
include: include:
o Packet with expired TTL o Packet with expired TTL
o Packet with header length more than 5 words o Packet with header length more than 5 words
o Packet IP head including Router Alert options o Packet IP head including router alert options
o Packet with exceptional source address o Packet with exceptional source address
o Packet with exceptional destination address o Packet with exceptional destination address
Note that although TTL is checked in this LFB for validity, Note that although Time to Live (TTL) is checked in this LFB for
operations like TTL decrement are made by the downstream forwarding validity, operations like TTL decrement are made by the downstream
LFB. forwarding LFB.
The final singleton port known as "FailOut" is defined for all The final singleton port known as "FailOut" is defined for all
packets which have errors and failed the validation process. An packets that have errors and failed the validation process. An error
error case is the case when a packet is unable to be further case is when a packet is unable to be further processed or forwarded
processed nor forwarded except being dropped. An error ID is without being dropped. An error ID is associated with a packet to
associated a packet to indicate the failure reason. Currently indicate the failure reason. Currently defined failure reasons
defined failure reasons include: include:
o Packet with size reported less than 20 bytes o Packet with size reported less than 20 bytes
o Packet with version is not IPv4 o Packet with version not IPv4
o Packet with header length less than 5 words o Packet with header length less than 5 words
o Packet with total length field less than 20 bytes o Packet with total length field less than 20 bytes
o Packet with invalid checksum o Packet with invalid checksum
o Packet with invalid source address o Packet with invalid source address
o Packet with invalid destination address o Packet with invalid destination address
5.2.1.2. Components 5.2.1.2. Components
This LFB has only one struct component, the This LFB has only one struct component, the
IPv4ValidatorStatisticsType, which defines a set of statistics for IPv4ValidatorStatisticsType, which defines a set of statistics for
validation process, including the number of bad header packets, the validation process, including the number of bad header packets, the
number of bad total length packets, the number of bad TTL packets, number of bad total length packets, the number of bad TTL packets,
and the number of bad checksum packets. This statistics componennt and the number of bad checksum packets. This statistics component is
is optional to implementers. optional to implementers.
5.2.1.3. Capabilities 5.2.1.3. Capabilities
This LFB does not have a list of capabilities This LFB does not have a list of capabilities
5.2.1.4. Events 5.2.1.4. Events
This LFB does not have any events specified. This LFB does not have any events specified.
5.2.2. IPv6Validator 5.2.2. IPv6Validator
The IPv6Validator LFB performs IPv6 packets validation. The IPv6Validator LFB performs IPv6 packet validation.
5.2.2.1. Data Handling 5.2.2.1. Data Handling
This LFB performs IPv6 validation according to [RFC2460] and its This LFB performs IPv6 validation according to [RFC2460] and its
updates. Then the IPv6 packet will be output to the corresponding updates. Then the IPv6 packet will be output to the corresponding
port regarding of the validation result, whether the packet is a port regarding of the validation result, indicating whether the
unicast or a multicast one, an exception has occurred or the packet is a unicast or a multicast one, an exception has occurred or
validation failed. the validation failed.
This LFB always expects, as input, packets which have been indicated This LFB always expects, as input, packets that have been indicated
as IPv6 packets by an upstream LFB, like an EtherClassifier LFB. as IPv6 packets by an upstream LFB, like an EtherClassifier LFB.
There is no specific metadata expected by the input of the LFB. There is no specific metadata expected by the input of the LFB.
Similar to the IPv4validator LFB, IPv6Validator LFB has also defined Similar to the IPv4validator LFB, the IPv6Validator LFB has also
four output ports to emit packets with various validation results. defined four output ports to emit packets with various validation
results.
All validated IPv6 unicast packets will be output at the singleton All validated IPv6 unicast packets will be output at the singleton
port known as "IPv6UnicastOut". All validated IPv6 multicast packets port known as "IPv6UnicastOut". All validated IPv6 multicast packets
will be output at the singleton port known as "IPv6MulticastOut" will be output at the singleton port known as "IPv6MulticastOut".
port. There is no metadata produced at this LFB. There is no metadata produced at this LFB.
A singleton port known as "ExceptionOut" is defined to output packets A singleton port known as "ExceptionOut" is defined to output packets
which have been validated as exception packets. An exception case is that have been validated as exception packets. An exception case is
the case when a packet needs further processing before being normally when a packet needs further processing before being normally
forwarded. An exception ID metadata is produced to indicate what forwarded. An exception ID metadata is produced to indicate what
caused the exception. Currently defined exception types include: caused the exception. Currently defined exception types include:
o Packet with hop limit to zero o Packet with hop limit to zero
o Packet with next header set to Hop-by-Hop o Packet with next header set to hop-by-hop
o Packet with exceptional source address o Packet with exceptional source address
o Packet with exceptional destination address o Packet with exceptional destination address
The final singleton port known as "FailOut" is defined for all The final singleton port known as "FailOut" is defined for all
packets which have errors and failed the validation process. An packets that have errors and failed the validation process. An error
error case is the case when a packet is unable to be further case when a packet is unable to be further processed or forwarded
processed nor forwarded except being dropped. A validate error ID is without being dropped. A validate error ID is associated to every
associated to every failed packet to indicate the reason. Currently failed packet to indicate the reason. Currently defined reasons
defined reasons include: include:
o Packet with size reported less than 40 bytes o Packet with size reported less than 40 bytes
o Packet with not IPv6 version o Packet with version not IPv6
o Packet with invalid source address o Packet with invalid source address
o Packet with invalid destination address o Packet with invalid destination address
Note that in the base type library, definitions for exception ID and Note that in the base type library, definitions for exception ID and
validate error ID metadata are applied to both IPv4Validator and validate error ID metadata are applied to both IPv4Validator and
IPv6Validator LFBs, i.e., the two LFBs share the same medadata IPv6Validator LFBs, i.e., the two LFBs share the same metadata
definition, with different ID assignment inside. definition, with different ID assignment inside.
5.2.2.2. Components 5.2.2.2. Components
This LFB has only one struct component, the This LFB has only one struct component, the
IPv6ValidatorStatisticsType, which defines a set of statistics for IPv6ValidatorStatisticsType, which defines a set of statistics for
validation process, including the number of bad header packets, the the validation process, including the number of bad header packets,
number of bad total length packets, and the number of bad hop limit the number of bad total length packets, and the number of bad hop
packets. Note that this component is optional to implementers. limit packets. Note that this component is optional to implementers.
5.2.2.3. Capabilities 5.2.2.3. Capabilities
This LFB does not have a list of capabilities This LFB does not have a list of capabilities.
5.2.2.4. Events 5.2.2.4. Events
This LFB does not have any events specified. This LFB does not have any events specified.
5.3. IP Forwarding LFBs 5.3. IP Forwarding LFBs
IP Forwarding LFBs are specifically defined to abstract the IP IP Forwarding LFBs are specifically defined to abstract the IP
forwarding processes. As definitions for a base LFB library, this forwarding processes. As definitions for a base LFB library, this
document restricts its LFB definition scope only to IP unicast document restricts its LFB definition scope only to IP unicast
forwarding. IP multicast may be defined in future documents. forwarding. IP multicast may be defined in future documents.
The two fundamental tasks performed in IP unicast forwarding The two fundamental tasks performed in IP unicast forwarding
constitute looking up the forwarding information table to find next constitute looking up the forwarding information table to find next-
hop information, and then using the resulting next hop details to hop information and then using the resulting next-hop details to
forward packets out on specific physical output ports. This document forward packets out on specific physical output ports. This document
models the forwarding processes by abstracting out the described two models the forwarding processes by abstracting out the described two
steps. Whereas this document describes functional LFB models which steps. Whereas this document describes functional LFB models that
are modular, there may be multiple ways to implement the abstracted are modular, there may be multiple ways to implement the abstracted
models. It is not intended nor expected that the provided LFB models models. It is not intended or expected that the provided LFB models
constrain implementations. constrain implementations.
Based on the IP forwarding abstraction, two kind of typical IP Based on the IP forwarding abstraction, two kinds of typical IP
unicast forwarding LFBs are defined, Unicast LPM lookup LFB and next unicast forwarding LFBs are defined: unicast LPM lookup LFB and next-
hop application LFB. They are further distinguished by IPv4 and IPv6 hop application LFB. They are further distinguished by IPv4 and IPv6
protocols. protocols.
5.3.1. IPv4UcastLPM 5.3.1. IPv4UcastLPM
The IPv4UcastLPM LFB abstracts the IPv4 unicast Longest Prefix Match The IPv4UcastLPM LFB abstracts the IPv4 unicast Longest Prefix Match
(LPM) process. (LPM) process.
This LFB also provides facilities to support users to implement This LFB also provides facilities to support users to implement
equal-cost multi-path routing (ECMP) or reverse path forwarding equal-cost multipath (ECMP) routing or reverse path forwarding (RPF).
(RPF). However, this LFB itself does not provide ECMP or RPF. To However, this LFB itself does not provide ECMP or RPF. To fully
fully implement ECMP or RPF, additional specific LFBs, like a implement ECMP or RPF, additional specific LFBs, like a specific ECMP
specific ECMP LFB or an RPF LFB, will have to be defined. LFB or an RPF LFB, will have to be defined.
5.3.1.1. Data Handling 5.3.1.1. Data Handling
This LFB performs the IPv4 unicast LPM table looking up. It always This LFB performs the IPv4 unicast LPM table lookup. It always
expects as input IPv4 unicast packets from one singleton input known expects as input IPv4 unicast packets from one singleton input known
as "PktsIn". Then the LFB uses the destination IPv4 address of every as "PktsIn". Then, the LFB uses the destination IPv4 address of
packet as search key to look up the IPv4 prefix table and generate a every packet as a search key to look up the IPv4 prefix table and
hop selector as the matching result. The hop selector is passed as generate a hop selector as the matching result. The hop selector is
packet metadata to downstream LFBs, and will usually be used there as passed as packet metadata to downstream LFBs and will usually be used
a search index to find more next hop information. there as a search index to find more next-hop information.
Three singleton output LFB ports are defined. Three singleton output LFB ports are defined.
The first singleton output known as "NormalOut" outputs IPv4 unicast The first singleton output is known as "NormalOut" and outputs IPv4
packets that succeed the LPM lookup and (got a hop selector). The unicast packets that succeed the LPM lookup (and got a hop selector).
hop selector is associated with the packet as a metadata. Downstream The hop selector is associated with the packet as a metadata.
from the LPM LFB is usually a next hop application LFB, like an Downstream from the LPM LFB is usually a next-hop application LFB,
IPv4NextHop LFB. like an IPv4NextHop LFB.
The second singleton output known as "ECMPOut" is defined to provide The second singleton output is known as "ECMPOut" and is defined to
support for users wishing to implement ECMP. provide support for users wishing to implement ECMP.
An ECMP flag is defined in the LPM table to enable the LFB to support An ECMP flag is defined in the LPM table to enable the LFB to support
ECMP. When a table entry is created with the flag set true, it ECMP. When a table entry is created with the flag set to true, it
indicates this table entry is for ECMP only. A packet, which has indicates this table entry is for ECMP only. A packet that has
passed through this prefix lookup, will always output from "ECMPOut" passed through this prefix lookup will always output from the
output port, with the hop selector being its lookup result. The "ECMPOut" output port, with the hop selector being its lookup result.
output will usually directly go to a downstream ECMP processing LFB, The output will usually go directly to a downstream ECMP processing
where the hop selector can usually further generate optimized one or LFB, where the hop selector can usually further generate optimized
multiple next hop routes by use of ECMP algorithms. one or multiple next-hop routes by use of ECMP algorithms.
A default route flag is defined in the LPM table to enable the LFB to A default route flag is defined in the LPM table to enable the LFB to
support a default route as well as loose RPF. When this flag is set support a default route as well as loose RPF. When this flag is set
true, the table entry is identified a default route which also to true, the table entry is identified as a default route, which also
implies that the route is forbidden for RPF. If a user wants to implies that the route is forbidden for RPF. If a user wants to
implement RPF on FE, a specific RPF LFB will have to be defined. In implement RPF on FE, a specific RPF LFB will have to be defined. In
such RPF LFB, a component can be defined as an alias of the prefix such an RPF LFB, a component can be defined as an alias of the prefix
table component of this LFB as described below. table component of this LFB, as described below.
The final singleton output is known as "ExceptionOut" and is defined The final singleton output is known as "ExceptionOut" of the
to allow exception packets to output here, along with an ExceptionID IPv4UcastLPM LFB and is defined to output exception packets after the
metadata to indicate what caused the exception. Currently defined LFB processing, along with an ExceptionID metadata to indicate what
exception types include: caused the exception. Currently defined exception types include:
o The packet failed the LPM lookup of the prefix table. o The packet failed the LPM lookup of the prefix table.
The upstream LFB of this LFB is usually IPv4Validator LFB. If RPF is The upstream LFB of this LFB is usually an IPv4Validator LFB. If RPF
to be adopted, the upstream can be an RPF LFB, when defined. is to be adopted, the upstream can be an RPF LFB, when defined.
The downstream LFB is usually IPv4NextHop LFB. If ECMP is adopted, The downstream LFB is usually an IPv4NextHop LFB. If ECMP is
the downstream can be an ECMP LFB, when defined. adopted, the downstream can be an ECMP LFB, when defined.
5.3.1.2. Components 5.3.1.2. Components
This LFB has two components. This LFB has two components.
The IPv4PrefixTable component is defined as an array component of the The IPv4PrefixTable component is defined as an array component of the
LFB. Each row of the array contains an IPv4 address, a Prefix LFB. Each row of the array contains an IPv4 address, a prefix
length, a Hop Selector, an ECMP flag and a Default Route flag. The length, a hop selector, an ECMP flag and a default route flag. The
LFB uses the destination IPv4 address of every input packet as search LFB uses the destination IPv4 address of every input packet as a
key to look up this table in order extract a next hop selector. The search key to look up this table in order extract a next-hop
ECMP flag is for the LFB to support ECMP. The default route flag is selector. The ECMP flag is for the LFB to support ECMP. The default
for the LFB to support a default route and for loose RPF. route flag is for the LFB to support a default route and for loose
RPF.
The IPv4UcastLPMStats component is a struct component which collects The IPv4UcastLPMStats component is a struct component that collects
statistics information, including the total number of input packets statistics information, including the total number of input packets
received, the IPv4 packets forwarded by this LFB and the number of IP received, the IPv4 packets forwarded by this LFB, and the number of
datagrams discarded due to no route found.Note the component is IP datagrams discarded due to no route found. Note that this
defined as optional to implementers. component is defined as optional to implementers.
5.3.1.3. Capabilities 5.3.1.3. Capabilities
This LFB does not have a list of capabilities This LFB does not have a list of capabilities.
5.3.1.4. Events 5.3.1.4. Events
This LFB does not have any events specified. This LFB does not have any events specified.
5.3.2. IPv4NextHop 5.3.2. IPv4NextHop
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 "PktsIn" 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 look up 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 from an LFB port
within the LFB port group as selected by the LFBOutputSelectIndex from within the LFB port group as selected by the
value of the matched table entry. The packet is sent to a downstream LFBOutputSelectIndex value of the matched table entry. The packet is
LFB alongside with the L3PortID and MediaEncapInfoIndex metadata. sent to a downstream LFB along 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 next hop 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 fan out to different LFB instances or a (Section 5.5.1), used to fan out to different LFB instances or a
media encapsulation related type, such as an EtherEncap type or a 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 a
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, IPv4NextHopTable, which is defined
defined as an array. The HopSelector received is used to match the as an array. The HopSelector received is used to match the array
array index of IPv4NextHopTable to find out a row of the table as the index of IPv4NextHopTable to find out a row of the table as the next-
next hop information result. Each row of the array is a struct 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 on to the downstream LFB instance. This ID indicates what
port to the neighbor is as defined by L3. Usually this ID is used kind of encapsulating port the neighbor is to use. This is L3-
for the next hop LFB to distinguish packets that need different L2 derived information that affects L2 processing and so needs to be
encapsulating. For instance, some packets may require general based from one LFB to another as metadata. Usually, this ID is
Ethernet encapsulation while others may require various types of used for the next-hop LFB to distinguish packets that need
tunnel encapsulations. In such case, different L3PortIDs are different L2 encapsulating. For instance, some packets may
assigned to the packets and are as metadata passed to downstream require general Ethernet encapsulation while others may require
LFB. A BasicMetadataDispatch LFB(Section 5.5.1) may have to be various types of tunnel encapsulations. In such a case, different
applied as the downstream LFB so as to dispatch packets to L3PortIDs are assigned to the packets and are passed as metadata
different encapsulation LFB instances according to the L3PortIDs. to a downstream LFB. A BasicMetadataDispatch LFB (Section 5.5.1)
may have to be applied as the downstream LFB so as to dispatch
packets to different encapsulation LFB instances according to the
L3PortIDs.
o 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 that passes on to 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 look up a table (typically media-encapsulation-related) for
further encapsulation information. The search key looks up the further encapsulation information. The search key looks up the
table by matching the table index.Note that an encapsulation LFB table by matching the table index. Note that the encapsulation
instance may not directly follow the next hop LFB, but the index LFB instance that uses this metadata may not be the LFB instance
is passed as a metadata associated, as such an encapsulation LFB that immediately follows this LFB instance in the processing. The
instance even further downstream to the next hop LFB can still use MediaEncapInfoIndex metadata is attached here and is passed
the index. In some cases, depending on implementation, the CE may through intermediate LFBs until it is used by the encapsulation
set the MediaEncapInfoIndex passed downstream to a value that will LFB instance. In some cases, depending on implementation, the CE
fail lookup when it gets to a target encapsulation LFB; such a may set the MediaEncapInfoIndex passed downstream to a value that
lookup failure at that point is an indication that further will fail lookup when it gets to a target encapsulation LFB; such
resolution is needed. For an example of this approach refer to a lookup failure at that point is an indication that further
Section 7.2 which talks about ARP and mentions this approach. resolution is needed. For an example of this approach, refer to
Section 7.2, which discusses 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 the downstream LFB port. This value identifies the specific port
table LFBTopology (See [RFC5812]) component FromPortIndex within the SuccessOut port group out of which packets that
corresponding to the port group mapping FromLFBID as IPv4NextHop successfully use this next-hop entry are to be sent.
LFB instance.
5.3.2.3. Capabilities 5.3.2.3. Capabilities
This LFB does not have a list of capabilities This LFB does not have a list of capabilities.
5.3.2.4. Events 5.3.2.4. Events
This LFB does not have any events specified. This LFB does not have any events specified.
5.3.3. IPv6UcastLPM 5.3.3. IPv6UcastLPM
The IPv6UcastLPM LFB abstracts the IPv6 unicast Longest Prefix Match The IPv6UcastLPM LFB abstracts the IPv6 unicast Longest Prefix Match
(LPM) process. The definition of this LFB is similar to the (LPM) process. The definition of this LFB is similar to the
IPv4UcastLPM LFB except that all IP addresses refer to IPv6 IPv4UcastLPM LFB except that all IP addresses refer to IPv6
addresses. addresses.
This LFB also provides facilities to support users to implement This LFB also provides facilities to support users to implement
equal-cost multi-path routing (ECMP) or reverse path forwarding equal-cost multipath (ECMP) routing or reverse path forwarding (RPF).
(RPF). However, this LFB itself does not provide ECMP or RPF. To However, this LFB itself does not provide ECMP or RPF. To fully
fully implement ECMP or RPF, additional specific LFBs, like a implement ECMP or RPF, additional specific LFBs, like a specific ECMP
specific ECMP LFB or an RPF LFB, will have to be defined. This work LFB or an RPF LFB, will have to be defined. This work may be done in
may be done in the future version of the document. future versions of this document.
5.3.3.1. Data Handling 5.3.3.1. Data Handling
This LFB performs the IPv6 unicast LPM table look up. It always This LFB performs the IPv6 unicast LPM table lookup. It always
expects as input IPv6 unicast packets from one singleton input known expects as input IPv6 unicast packets from one singleton input known
as "PktsIn". The destination IPv6 address of an incoming packet is as "PktsIn". The destination IPv6 address of an incoming packet is
used as search key to look up the IPv6 prefix table and generate a used as a search key to look up the IPv6 prefix table and generate a
hop selector. This hop selector result is associated to the packet hop selector. This hop selector result is associated to the packet
as a metadata and sent to downstream LFBs, and will usually be used as a metadata and sent to downstream LFBs; it will usually be used in
in downstream LFBs as a search key to find more next hop information. downstream LFBs as a search key to find more next-hop information.
Three singleton output LFB ports are defined. Three singleton output LFB ports are defined.
The first singleton output known as "NormalOut" outputs IPv6 unicast The first singleton output is known as "NormalOut" and outputs IPv6
packets that succeed the LPM lookup (and got a hop selector). The unicast packets that succeed the LPM lookup (and got a hop selector).
hop selector is associated with the packet as a metadata. Downstream The hop selector is associated with the packet as a metadata.
from the LPM LFB is usually a next hop application LFB, like an Downstream from the LPM LFB is usually a next-hop application LFB,
IPv6NextHop LFB. like an IPv6NextHop LFB.
The second singleton output known as "ECMPOut" is defined to provide The second singleton output is known as "ECMPOut" and is defined to
support for users wishing to implement ECMP. provide support for users wishing to implement ECMP.
An ECMP flag is defined in the LPM table to enable the LFB to support An ECMP flag is defined in the LPM table to enable the LFB to support
ECMP. When a table entry is created with the flag set true, it ECMP. When a table entry is created with the flag set to true, it
indicates this table entry is for ECMP only. A packet, which has indicates this table entry is for ECMP only. A packet that has
passed through this prefix lookup, will always output from "ECMPOut" passed through this prefix lookup will always output from the
output port, with the hop selector being its lookup result. The "ECMPOut" output port, with the hop selector being its lookup result.
output will usually directly go to a downstream ECMP processing LFB, The output will usually go directly to a downstream ECMP processing
where the hop selector can usually further generate optimized one or LFB, where the hop selector can usually further generate optimized
multiple next hop routes by use of ECMP algorithms. one or multiple next-hop routes by use of ECMP algorithms.
A default route flag is defined in the LPM table to enable the LFB to A default route flag is defined in the LPM table to enable the LFB to
support a default route as well as loose RPF. When this flag is set support a default route as well as loose RPF. When this flag is set
true, the table entry is identified a default route which also to true, the table entry is identified as a default route, which also
implies that the route is forbidden for RPF. implies that the route is forbidden for RPF.
If a user wants to implement RPF on FE, a specific RPF LFB will have If a user wants to implement RPF on FE, a specific RPF LFB will have
to be defined. In such RPF LFB, a component can be defined as an to be defined. In such an RPF LFB, a component can be defined as an
alias of the prefix table component of this LFB as described below. alias of the prefix table component of this LFB, as described below.
The final singleton output is known as "ExceptionOut" and is defined The final singleton output is known as "ExceptionOut" of the
to allow exception packets to output here, along with an ExceptionID IPv6UcastLPM LFB and is defined to output exception packets after the
metadata to indicate what caused the exception. Currently defined LFB processing, along with an ExceptionID metadata to indicate what
exception types include: caused the exception. Currently defined exception types include:
o The packet failed the LPM lookup of the prefix table. o The packet failed the LPM lookup of the prefix table.
The upstream LFB of this LFB is usually IPv6Validator LFB. If RPF is The upstream LFB of this LFB is usually an IPv6Validator LFB. If RPF
to be adopted, the upstream can be an RPF LFB, when defined. is to be adopted, the upstream can be an RPF LFB, when defined.
The downstream LFB is usually an IPv6NextHop LFB. If ECMP is The downstream LFB is usually an IPv6NextHop LFB. If ECMP is
adopted, the downstream can be an ECMP LFB, when defined. adopted, the downstream can be an ECMP LFB, when defined.
5.3.3.2. Components 5.3.3.2. Components
This LFB has two components. This LFB has two components.
The IPv6PrefixTable component is defined as an array component of the The IPv6PrefixTable component is defined as an array component of the
LFB. Each row of the array contains an IPv6 address, a Prefix LFB. Each row of the array contains an IPv6 address, a prefix
length, a Hop Selector, an ECMP flag and a Default Route flag. The length, a hop selector, an ECMP flag, and a default route flag. The
ECMP flag is so the LFB can support ECMP. The default route flag is ECMP flag is so the LFB can support ECMP. The default route flag is
for the LFB to support a default route and for loose RPF as described for the LFB to support a default route and for loose RPF, as
earlier. described earlier.
The IPv6UcastLPMStats component is a struct component which collects The IPv6UcastLPMStats component is a struct component that collects
statistics information, including the total number of input packets statistics information, including the total number of input packets
received, the IPv6 packets forwarded by this LFB and the number of IP received, the IPv6 packets forwarded by this LFB and the number of IP
datagrams discarded due to no route found.Note the component is datagrams discarded due to no route found. Note that the component
defined as optional to implementers. is defined as optional to implementers.
5.3.3.3. Capabilities 5.3.3.3. Capabilities
This LFB does not have a list of capabilities This LFB does not have a list of capabilities.
5.3.3.4. Events 5.3.3.4. Events
This LFB does not have any events specified. This LFB does not have any events specified.
5.3.4. IPv6NextHop 5.3.4. IPv6NextHop
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 "PktsIn" 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 next hop table. used as a table index to look up 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 from an LFB port
within the LFB port group as selected by the LFBOutputSelectIndex from within the LFB port group as selected by the
value of the matched table entry. The packet is sent to a downstream LFBOutputSelectIndex value of the matched table entry. The packet is
LFB alongside with the L3PortID and MediaEncapInfoIndex metadata. sent to a downstream LFB along 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 next hop 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 fan out 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 encapsulation 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 Ethernet and other tunnel encapsulation
Encapsulation downstream from BasicMetadataDispatch, then the exist 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 kind of encapsulating port the neighbor is to use. This is L3-
for the next hop LFB to distinguish packets that need different L2 derived information that affects L2 processing and so needs to be
encapsulating. For instance, some packets may require general based from one LFB to another as metadata. Usually, this ID is
Ethernet encapsulation while others may require various types of used for the next-hop LFB to distinguish packets that need
tunnel encapsulations. In such case, different L3PortIDs are different L2 encapsulating. For instance, some packets may
assigned to the packets and are as metadata passed to downstream require general Ethernet encapsulation while others may require
LFB. A BasicMetadataDispatch LFB(Section 5.5.1) may have to be various types of tunnel encapsulations. In such a case, different
applied as the downstream LFB so as to dispatch packets to L3PortIDs are assigned to the packets and are passed as metadata
different encapsulation LFB instances according to the L3PortIDs. to a downstream LFB. A BasicMetadataDispatch LFB (Section 5.5.1)
may have to be applied as the downstream LFB so as to dispatch
packets to different encapsulation LFB instances according to the
L3PortIDs.
o 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 that is passed on to 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 look up a table (typically media-encapsulation-related) for
further encapsulation information. The saearch key looks up the further encapsulation information. The search key looks up the
table by matching the table index. Note that an encapsulation LFB table by matching the table index. Note that the encapsulation
instance may not directly follow the next hop LFB, but the index LFB instance that uses this metadata may not be the LFB instance
is passed as a metadata associated, as such an encapsulation LFB that immediately follows this LFB instance in the processing. The
instance even further downstream to the next hop LFB can still use MediaEncapInfoIndex metadata is attached here and is passed
the index. In some cases, depending on implementation, the CE may through intermediate LFBs until it is used by the encapsulation
set the MediaEncapInfoIndex passed downstream to a value that will LFB instance. In some cases, depending on implementation, the CE
fail lookup when it gets to a target encapsulation LFB; such a may set the MediaEncapInfoIndex passed downstream to a value that
lookup failure at that point is an indication that further will fail lookup when it gets to a target encapsulation LFB; such
resolution is needed. For an example of this approach refer to a lookup failure at that point is an indication that further
Section 7.2 which talks about ARP and mentions this approach. resolution is needed. For an example of this approach, refer to
Section 7.2, which discusses 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 the downstream LFB port. This value identifies the specific port
table LFBTopology (See [RFC5812]) component FromPortIndex within the SuccessOut port group out of which packets that
corresponding to the port group mapping FromLFBID as IPv4NextHop successfully use this next-hop entry are to be sent.
LFB instance.
5.3.4.3. Capabilities 5.3.4.3. Capabilities
This LFB does not have a list of capabilities This LFB does not have a list of capabilities.
5.3.4.4. Events 5.3.4.4. Events
This LFB does not have any events specified. This LFB does not have any events specified.
5.4. Redirect LFBs 5.4. Redirect LFBs
Redirect LFBs abstract data packets transportation process between CE Redirect LFBs abstract the data packet transportation process between
and FE. Some packets output from some LFBs may have to be delivered the CE and FE. Some packets output from some LFBs may have to be
to CE for further processing, and some packets generated by CE may delivered to the CE for further processing, and some packets
have to be delivered to FE and further to some specific LFBs for data generated by the CE may have to be delivered to the FE and further to
path processing. According to [RFC5810], data packets and their some specific LFBs for data path processing. According to [RFC5810],
associated metadata are encapsulated in ForCES redirect message for data packets and their associated metadata are encapsulated in a
transportation between CE and FE. We define two LFBs to abstract the ForCES redirect message for transportation between CE and FE. We
process, a RedirectIn LFB and a RedirectOut LFB. Usually, in an LFB define two LFBs to abstract the process: a RedirectIn LFB and a
topology of an FE, only one RedirectIn LFB instance and one RedirectOut LFB. Usually, in an LFB topology of an FE, only one
RedirectOut LFB instance exist. RedirectIn LFB instance and one RedirectOut LFB instance exist.
5.4.1. RedirectIn 5.4.1. RedirectIn
RedirectIn LFB abstracts the process for the CE to inject data The RedirectIn LFB abstracts the process for the CE to inject data
packets into the FE data path. packets into the FE data path.
5.4.1.1. Data Handling 5.4.1.1. Data Handling
A RedirectIn LFB abstracts the process for the CE to inject data A RedirectIn LFB abstracts the process for the CE to inject data
packets into the FE LFB topology so as to input data packets into FE packets into the FE LFB topology so as to input data packets into FE
data paths. From LFB topology point of view, the RedirectIn LFB acts data paths. From the LFB topology's point of view, the RedirectIn
as a source point for data packets coming from CE, therefore LFB acts as a source point for data packets coming from the CE;
RedirectIn LFB is defined with a single output LFB port (and no input therefore, the RedirectIn LFB is defined with a single output LFB
LFB port). port (and no input LFB port).
The single output port of RedirectIn LFB is defined as a group output The single output port of RedirectIn LFB is defined as a group output
type, with the name of "PktsOut". Packets produced by this output type with the name of "PktsOut". Packets produced by this output
will have arbitrary frame types decided by the CE which generated the will have arbitrary frame types decided by the CE that generated the
packets. Possible frames may include IPv4, IPv6, or ARP protocol packets. Possible frames may include IPv4, IPv6, or ARP protocol
packets. The CE may associate some metadata to indicate the frame packets. The CE may associate some metadata to indicate the frame
types and may also associate other metadata to indicate various types and may also associate other metadata to indicate various
information on the packets. Among them, there MUST exist a information on the packets. Among them, there MUST exist a
'RedirectIndex' metadata, which is an integer acting as an index. RedirectIndex metadata, which is an integer acting as an index. When
When the CE transmits the metadata along with the packet to a the CE transmits the metadata along with the packet to a RedirectIn
RedirectIn LFB, the LFB will read the RedirectIndex metadata and LFB, the LFB will read the RedirectIndex metadata and output the
output the packet to one of its group output port instance, whose packet to one of its group output port instances, whose port index is
port index is indicated by this metadata. Any other metadata, in indicated by this metadata. Any other metadata, in addition to
addition to 'RedirectIndex', will be passed untouched along the RedirectIndex, will be passed untouched along the packet delivered by
packet delivered by the CE to downstream LFB. This means the the CE to the downstream LFB. This means the RedirectIndex metadata
'RedirectIndex' metadata from CE will be "consumed" by the RedirectIn from CE will be "consumed" by the RedirectIn LFB and will not be
LFB and will not be passed to downstream LFB. Note that, a packet passed to downstream LFB. Note that a packet from the CE without a
from CE without a 'RedirectIndex' metadata associated will be dropped RedirectIndex metadata associated will be dropped by the LFB. Note
by the LFB. Note that all metadata visible to the LFB need to be that all metadata visible to the LFB need to be global and IANA
global and IANA controlled. See the "IANA Considerations" of the controlled. See Section 8 ("IANA Considerations") of this document
document for more details, where a metadata ID private space that can for more details about a metadata ID space that can be used by
be used by vendors is also provided. vendors and is "Reserved for Private Use".
5.4.1.2. Components 5.4.1.2. Components
An optional statistics component is defined to collect the number of An optional statistics component is defined to collect the number of
packets received by the LFB from CE. There are no other components packets received by the LFB from the CE. There are no other
defined for current version of the LFB. components defined for the current version of the LFB.
5.4.1.3. Capabilities 5.4.1.3. Capabilities
This LFB does not have a list of capabilities This LFB does not have a list of capabilities.
5.4.1.4. Events 5.4.1.4. Events
This LFB does not have any events specified. This LFB does not have any events specified.
5.4.2. RedirectOut 5.4.2. RedirectOut
RedirectOut LFB abstracts the process for LFBs in the FE to deliver RedirectOut LFB abstracts the process for LFBs in the FE to deliver
data packets to the CE. data packets to the CE.
5.4.2.1. Data Handling 5.4.2.1. Data Handling
A RedirectOut LFB abstracts the process for LFBs in the FE to deliver A RedirectOut LFB abstracts the process for LFBs in the FE to deliver
data packets to the CE. From the LFB's topology point of view, the data packets to the CE. From the LFB topology's point of view, the
RedirectOut LFB acts as a sink point for data packets going to the 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 CE; therefore, the RedirectOut LFB is defined with a single input LFB
(and no output LFB port). port (and no output LFB port).
The RedirectOut LFB has only one singleton input known as "PktsIn", The RedirectOut LFB has only one singleton input, known as "PktsIn",
but is capable of receiving packets from multiple LFBs by but is capable of receiving packets from multiple LFBs by
multiplexing this input. The input expects any kind of frame type multiplexing this input. The input expects any kind of frame type;
therefore the frame type has been specified as arbitrary, and also therefore, the frame type has been specified as arbitrary, and also
all types of metadata are expected. All associated metadata produced all types of metadata are expected. All associated metadata produced
(but not consumed) by previous processed LFBs should be delivered to (but not consumed) by previous processed LFBs should be delivered to
CE via the ForCES protocol redirect message [RFC5810]. The CE can the CE via the ForCES protocol redirect message [RFC5810]. The CE
decide on how to process the redirected packet by referencing the can decide how to process the redirected packet by referencing the
associated metadata. As an example, a packet could be redirected by associated metadata. As an example, a packet could be redirected by
the FE to the CE because the EtherEncap LFB is not able to resolve L2 the FE to the CE because the EtherEncap LFB is not able to resolve L2
information. The metadata "ExceptionID", created by the EtherEncap information. The metadata "ExceptionID" created by the EtherEncap
LFB is passed along with the packet and should be sufficient for the LFB is passed along with the packet and should be sufficient for the
CE to do the necessary processing and resolve the L2 entry required. CE to do the necessary processing and resolve the L2 entry required.
Note that all metadata visible to the LFB need to be global and IANA Note that all metadata visible to the LFB need to be global and IANA
controlled. See the "IANA Considerations" of the document for more controlled. See Section 8 ("IANA Considerations") of this document
details, where a metadata ID private space that can be used by for more details about a metadata ID space that can be used by
vendors is also provided. vendors and is "Reserved for Private Use".
5.4.2.2. Components 5.4.2.2. Components
An optional statistics component is defined to collect the number of An optional statistics component is defined to collect the number of
packets sent by the LFB to CE. There are no other components defined packets sent by the LFB to the CE. There are no other components
for current version of the LFB. defined for the current version of the LFB.
5.4.2.3. Capabilities 5.4.2.3. Capabilities
This LFB does not have a list of capabilities This LFB does not have a list of capabilities.
5.4.2.4. Events 5.4.2.4. Events
This LFB does not have any events specified. This LFB does not have any events specified.
5.5. General Purpose LFBs 5.5. General Purpose LFBs
5.5.1. BasicMetadataDispatch 5.5.1. BasicMetadataDispatch
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 LFB 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 and a dispatch table named MetadataDispatchTable, all metadata ID and a dispatch table named MetadataDispatchTable, all
configured by the CE. The metadata ID specifies which metadata is to configured by the CE. The metadata ID specifies which metadata is to
be used for dispatching packets. The MetadataDispatchTable contains be used for dispatching packets. The MetadataDispatchTable contains
entries of a metadata value and an OutputIndex, specifying that the entries of a metadata value and an OutputIndex, specifying that the
packet with the metadata value must go out from the LFB group output packet with the metadata value must go out from the LFB group output
port instance with the OutputIndex. port instance with the OutputIndex.
Two output LFB ports are defined. Two output LFB ports are defined.
skipping to change at page 68, line 36 skipping to change at page 67, line 22
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 only include one case: exception. Currently defined exception types only include one case:
o There is no matching when looking up the metadata dispatch table. o There is no matching when looking up the metadata dispatch table.
As an example, if the CE decides to dispatch packets according to a As an example, if the CE decides to dispatch packets according to a
physical port ID (PHYPortID), the CE may set the ID of PHYPortID physical port ID (PHYPortID), the CE may set the ID of PHYPortID
metadata to the LFB first. Moreover, the CE also sets the PHYPortID metadata to the LFB first. Moreover, the CE also sets the PHYPortID
actual values (the metadata values) and assigned OutputIndex for the actual values (the metadata values) and assigned OutputIndex for the
values to the dispatch table in the LFB. When a packet arrives, a values to the dispatch table in the LFB. When a packet arrives, a
PHYPortID metadata is found associated with the packet, the metadata PHYPortID metadata is found associated with the packet, and the
value is further used as a key to look up the dispatch table to find metadata value is further used as a key to look up the dispatch table
out an output port instance for the packet. to find out an output port instance for the packet.
Currently the BasicMetadataDispatch LFB only allows the metadata Currently, the BasicMetadataDispatch LFB only allows the metadata
value of the dispatch table entry be 32-bits integer. A metadata value of the dispatch table entry to be a 32-bit integer. A metadata
with other types of value is not supported in this version. A more with other value types is not supported in this version. A more
complex metadata dispatch LFB may be defined in future version of the complex metadata dispatch LFB may be defined in future versions of
library. In that LFB, multiple tuples of metadata with more value the library. In that LFB, multiple tuples of metadata with more
types supported may be used to dispatch packets. value 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 the metadata value and the OutputIndex. Note
currently, the metadata value is only allowed to be 32-bits integer. that currently, the metadata value is only allowed to be a 32-bit
integer. The metadata value is also defined as a content key for the
The metadata value is also defined as a content key for the table. table. The concept of content key is a searching key for tables,
The concept of content key is a searching key for tables which is which is defined in the ForCES FE model [RFC5812]. With the content
defined in the ForCES FE Model [RFC5812]. With the content key, CE key, the CE can manipulate the table by means of a specific metadata
can manipulate the table by means of a specific metadata value rather value rather than by the table index only. See the ForCES FE model
than by the table index only. See [RFC5812] document and also the [RFC5812] and also the ForCES protocol [RFC5810] for more details on
ForCES Protocol [RFC5810] for more details on the definition and use the definition and use of a content key.
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
This is a preliminary generic scheduler LFB for abstracting a simple This is a preliminary generic scheduler LFB for abstracting a simple
scheduling process. scheduling process.
5.5.2.1. Data Handling 5.5.2.1. Data Handling
There exist various kinds of scheduling strategies with various There exist various kinds of scheduling strategies with various
implementations. As a base LFB library, this document only defines a implementations. As a base LFB library, this document only defines a
preliminary generic scheduler LFB for abstracting a simple scheduling preliminary generic scheduler LFB for abstracting a simple scheduling
process. Users may use this LFB as a basic LFB to further construct process. Users may use this LFB as a basic LFB to further construct
more complex scheduler LFBs by means of "inheritance" as described in more complex scheduler LFBs by means of "inheritance", as described
[RFC5812]. 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. Inside instance may be connected to a different upstream LFB output. Inside
the LFB, it is abstracted that each input port instance is connected the LFB, it is abstracted that each input port instance is connected
to a queue, and the queue is marked with a queue ID whose value is to a queue, and the queue is marked with a queue ID whose value is
exactly the same as the index of corresponding group input port exactly the same as the index of corresponding group input port
instance. Scheduling disciplines are applied to all queues and also instance. Scheduling disciplines are applied to all queues and also
all packets in the queues.The group input port property all packets in the queues. The group input port property
PortGroupLimits in ObjectLFB as defined by ForCES FE model[RFC5810] PortGroupLimits in ObjectLFB, as defined by the ForCES FE model
provides means for the CE to query the capability of total queue [RFC5810], provides means for the CE to query the capability of total
numbers the scheduler supports. The CE can then decide how many queue numbers the scheduler supports. The CE can then decide how
queues it may use for a scheduling application. 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 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 thus RR.
The QueueStats component is defined to allow CE to query every queue The QueueStats component is defined to allow the CE to query every
status of the scheduler. It is an array component and each row of queue status of the scheduler. It is an array component, and each
the array is a struct containing a queue ID. Currently defined queue row of the array is a struct containing a queue ID. Currently
status includes the queue depth in packets and the queue depth in defined queue status includes the queue depth in packets and the
bytes. Using the queue ID as the index, the CE can query every queue queue depth in bytes. Using the queue ID as the index, the CE can
for its used length in unit of packets or bytes.Note that the query every queue for its used length in unit of packets or bytes.
QueueStats componennt is defined as optional to implementers. Note that the QueueStats component is defined as optional to
implementers.
5.5.2.3. Capabilities 5.5.2.3. Capabilities
The following capability is currently defined for the The following capability is currently defined for the
GenericScheduler. GenericScheduler.
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
skipping to change at page 71, line 17 skipping to change at page 69, line 38
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0" <LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
provides="BaseLFBLibrary"> provides="BaseLFBLibrary">
<load library="BaseTypeLibrary"/> <load library="BaseTypeLibrary"/>
<LFBClassDefs> <LFBClassDefs>
<LFBClassDef LFBClassID="3"> <LFBClassDef LFBClassID="3">
<name>EtherPHYCop</name> <name>EtherPHYCop</name>
<synopsis> <synopsis>
The EtherPHYCop LFB describes an Ethernet interface The EtherPHYCop LFB describes an Ethernet interface
which limits the physical media to copper. that limits the physical media to copper.
</synopsis> </synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort> <inputPort>
<name>EtherPHYIn</name> <name>EtherPHYIn</name>
<synopsis> <synopsis>
The input port of the EtherPHYCop LFB. It expects any The input port of the EtherPHYCop LFB. It expects any
type of Ethernet frame. type of Ethernet frame.
</synopsis> </synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
<ref>EthernetAll</ref> <ref>EthernetAll</ref>
</frameExpected> </frameExpected>
</expectation> </expectation>
</inputPort> </inputPort>
</inputPorts> </inputPorts>
<outputPorts> <outputPorts>
<outputPort> <outputPort>
<name>EtherPHYOut</name> <name>EtherPHYOut</name>
<synopsis> <synopsis>
The output port of the EtherPHYCop LFB. The output The output port of the EtherPHYCop LFB. The output
packet has the same Ethernet frame type with the packet has the same Ethernet frame type as the
input packet, associated with a metadata indicating input packet, associated with a metadata indicating
the ID of the physical port. the ID of the physical port.
</synopsis> </synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>EthernetAll</ref> <ref>EthernetAll</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>PHYPortID</ref> <ref>PHYPortID</ref>
</metadataProduced> </metadataProduced>
skipping to change at page 74, line 45 skipping to change at page 73, line 16
<eventField>OperDuplexMode</eventField> <eventField>OperDuplexMode</eventField>
</eventReport> </eventReport>
</eventReports> </eventReports>
</event> </event>
</events> </events>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="4"> <LFBClassDef LFBClassID="4">
<name>EtherMACIn</name> <name>EtherMACIn</name>
<synopsis> <synopsis>
EtherMACIn LFB describes an Ethernet port at MAC data link EtherMACIn LFB describes an Ethernet port at MAC data link
layer. The LFB describes Ethernet processing functions layer. The LFB describes Ethernet processing functions
of MAC address locality check, deciding if the Ethernet of MAC address locality check, deciding if the Ethernet
packets should be bridged, providing Ethernet layer flow packets should be bridged, providing Ethernet-layer flow
control, etc. control, etc.
</synopsis> </synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort group="false"> <inputPort group="false">
<name>EtherPktsIn</name> <name>EtherPktsIn</name>
<synopsis> <synopsis>
The input port of the EtherMACIn LFB. It expects any The input port of the EtherMACIn LFB. It expects any
type of Ethernet frame. type of Ethernet frame.
</synopsis> </synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
<ref>EthernetAll</ref> <ref>EthernetAll</ref>
</frameExpected> </frameExpected>
<metadataExpected> <metadataExpected>
<ref>PHYPortID</ref> <ref>PHYPortID</ref>
</metadataExpected> </metadataExpected>
</expectation> </expectation>
</inputPort> </inputPort>
</inputPorts> </inputPorts>
<outputPorts> <outputPorts>
<outputPort group="false"> <outputPort group="false">
<name>NormalPathOut</name> <name>NormalPathOut</name>
<synopsis> <synopsis>
An output port in the EtherMACIn LFB. It outputs An output port in the EtherMACIn LFB. It outputs
Ethernet packets to downstream LFBs for normal Ethernet packets to downstream LFBs for normal
processing like Ethernet packet classification and processing like Ethernet packet classification and
other L3 IP layer processing. other L3 IP-layer processing.
</synopsis> </synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>EthernetAll</ref> <ref>EthernetAll</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>PHYPortID</ref> <ref>PHYPortID</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
<outputPort> <outputPort>
<name>L2BridgingPathOut</name> <name>L2BridgingPathOut</name>
<synopsis> <synopsis>
An output port in An output port in
the EtherMACIn LFB. It outputs Ethernet packets the EtherMACIn LFB. It outputs Ethernet packets
to downstream LFBs for layer 2 bridging processing. to downstream LFBs for layer 2 bridging processing.
The port is switched on or off by the The port is switched on or off by the
L2BridgingPathEnable flag in the LFB. L2BridgingPathEnable flag in the LFB.
</synopsis> </synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>EthernetAll</ref> <ref>EthernetAll</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>PHYPortID</ref> <ref>PHYPortID</ref>
skipping to change at page 76, line 4 skipping to change at page 74, line 24
to downstream LFBs for layer 2 bridging processing. to downstream LFBs for layer 2 bridging processing.
The port is switched on or off by the The port is switched on or off by the
L2BridgingPathEnable flag in the LFB. L2BridgingPathEnable flag in the LFB.
</synopsis> </synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>EthernetAll</ref> <ref>EthernetAll</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>PHYPortID</ref> <ref>PHYPortID</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
</outputPorts> </outputPorts>
<components> <components>
<component componentID="1" access="read-write"> <component componentID="1" access="read-write">
<name>AdminStatus</name> <name>AdminStatus</name>
<synopsis> <synopsis>
The LFB status administratively requested, which has The LFB status administratively requested, which has
the same data type with a port status. Default is in the same data type with a port status. Default is in
'down' status. 'Down' status.
</synopsis> </synopsis>
<typeRef>PortStatusType</typeRef> <typeRef>PortStatusType</typeRef>
<defaultValue>2</defaultValue> <defaultValue>2</defaultValue>
</component> </component>
<component componentID="2" access="read-write"> <component componentID="2" access="read-write">
<name>LocalMACAddresses</name> <name>LocalMACAddresses</name>
<synopsis> <synopsis>
Local MAC address(es) of the Ethernet port the LFB Local MAC address(es) of the Ethernet port the LFB
represents. represents.
</synopsis> </synopsis>
<array> <array>
<typeRef>IEEEMAC</typeRef> <typeRef>IEEEMAC</typeRef>
</array> </array>
</component> </component>
<component componentID="3" access="read-write"> <component componentID="3" access="read-write">
<name>L2BridgingPathEnable</name> <name>L2BridgingPathEnable</name>
<synopsis> <synopsis>
A flag indicating if the LFB L2 BridgingPath output A flag indicating if the LFB L2 BridgingPath output
port is enabled or not. Default is not enabled. port is enabled or not. Default is not enabled.
</synopsis> </synopsis>
<typeRef>boolean</typeRef> <typeRef>boolean</typeRef>
<defaultValue>false</defaultValue> <defaultValue>false</defaultValue>
</component> </component>
<component componentID="4" access="read-write"> <component componentID="4" access="read-write">
<name>PromiscuousMode</name> <name>PromiscuousMode</name>
<synopsis> <synopsis>
A flag indicating whether the LFB is in promiscuous A flag indicating whether the LFB is in promiscuous
mode or not. Default is not. mode or not. Default is not.
</synopsis> </synopsis>
<typeRef>boolean</typeRef> <typeRef>boolean</typeRef>
<defaultValue>false</defaultValue> <defaultValue>false</defaultValue>
</component> </component>
<component componentID="5" access="read-write"> <component componentID="5" access="read-write">
<name>TxFlowControl</name> <name>TxFlowControl</name>
<synopsis> <synopsis>
A flag indicating whether transmit flow control is A flag indicating whether transmit flow control is
applied or not. Default is not. applied or not. Default is not.
</synopsis> </synopsis>
<optional/> <optional/>
<typeRef>boolean</typeRef> <typeRef>boolean</typeRef>
<defaultValue>false</defaultValue> <defaultValue>false</defaultValue>
</component> </component>
<component componentID="6" access="read-write"> <component componentID="6" access="read-write">
<name>RxFlowControl</name> <name>RxFlowControl</name>
<synopsis> <synopsis>
A flag indicating whether receive flow control is A flag indicating whether receive flow control is
applied or not. Default is not. applied or not. Default is not.
</synopsis> </synopsis>
<optional/> <optional/>
<typeRef>boolean</typeRef> <typeRef>boolean</typeRef>
<defaultValue>false</defaultValue> <defaultValue>false</defaultValue>
</component> </component>
<component componentID="7" access="read-reset"> <component componentID="7" access="read-reset">
<name>MACInStats</name> <name>MACInStats</name>
<synopsis> <synopsis>
The statistics of the EtherMACIn LFB The statistics of the EtherMACIn LFB
</synopsis> </synopsis>
<optional/> <optional/>
<typeRef>MACInStatsType</typeRef> <typeRef>MACInStatsType</typeRef>
</component> </component>
</components> </components>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="5"> <LFBClassDef LFBClassID="5">
<name>EtherClassifier</name> <name>EtherClassifier</name>
<synopsis> <synopsis>
EtherClassifier LFB describes the process to decapsulate EtherClassifier LFB describes the process to decapsulate
Ethernet packets and then classify them into various Ethernet packets and then classify them into various
network layer packets according to information in the network-layer packets according to information in the
Ethernet headers. It is expected the LFB classifies packets Ethernet headers. It is expected the LFB classifies packets
by packet types like IPv4, IPv6, MPLS, ARP, ND, etc. by packet types like IPv4, IPv6, MPLS, ARP, ND, etc.
</synopsis> </synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort> <inputPort>
<name>EtherPktsIn</name> <name>EtherPktsIn</name>
<synopsis> <synopsis>
Input port of Ethernet packets. PHYPortID metadata is Input port of Ethernet packets. PHYPortID metadata is
always expected while LogicalPortID metadata is always expected while LogicalPortID metadata is
optionally expected to associate with every input optionally expected to associate with every input
Ethernet packet. Ethernet packet.
</synopsis> </synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
<ref>EthernetAll</ref> <ref>EthernetAll</ref>
</frameExpected> </frameExpected>
<metadataExpected> <metadataExpected>
<ref>PHYPortID</ref> <ref>PHYPortID</ref>
skipping to change at page 78, line 32 skipping to change at page 77, line 4
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>PHYPortID</ref> <ref>PHYPortID</ref>
<ref>SrcMAC</ref> <ref>SrcMAC</ref>
<ref>DstMAC</ref> <ref>DstMAC</ref>
<ref>EtherType</ref> <ref>EtherType</ref>
<ref availability="conditional">VlanID</ref> <ref availability="conditional">VlanID</ref>
<ref availability="conditional">VlanPriority</ref> <ref availability="conditional">VlanPriority</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
<outputPort group="false"> <outputPort group="false">
<name>ExceptionOut</name> <name>ExceptionOut</name>
<synopsis> <synopsis>
A singleton port for output of all Ethernet packets A singleton port for output of all Ethernet packets
that fail the classifying process. An ExceptionID that fail the classifying process. An ExceptionID
metadata indicates the failure reason. metadata indicates the failure reason.
</synopsis> </synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>Arbitrary</ref> <ref>Arbitrary</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>ExceptionID</ref> <ref>ExceptionID</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
</outputPorts> </outputPorts>
<components> <components>
<component access="read-write" componentID="1"> <component access="read-write" componentID="1">
<name>EtherDispatchTable</name> <name>EtherDispatchTable</name>
<synopsis> <synopsis>
An EtherDispatchTable array component which is defined An EtherDispatchTable array component that is defined
in the LFB to dispatch every Ethernet packet to output in the LFB to dispatch every Ethernet packet to output
ports according to logical port ID assigned by the ports according to logical port ID assigned by the
VlanInputTable in the LFB and Ethernet type in the VlanInputTable in the LFB and Ethernet type in the
Ethernet packet header. Ethernet packet header.
</synopsis> </synopsis>
<typeRef>EtherDispatchTableType</typeRef> <typeRef>EtherDispatchTableType</typeRef>
</component> </component>
<component access="read-write" componentID="2"> <component access="read-write" componentID="2">
<name>VlanInputTable</name> <name>VlanInputTable</name>
<synopsis> <synopsis>
A VlanInputTable array component which is defined in A VlanInputTable array component that is defined in
the LFB to classify VLAN Ethernet packets. Every input the LFB to classify VLAN Ethernet packets. Every input
packet is assigned with a new LogicalPortID according packet is assigned with a new LogicalPortID according
to the packet incoming port ID and VLAN ID. to the packet's incoming port ID and VLAN ID.
</synopsis> </synopsis>
<typeRef>VlanInputTableType</typeRef> <typeRef>VlanInputTableType</typeRef>
</component> </component>
<component access="read-reset" componentID="3"> <component access="read-reset" componentID="3">
<name>EtherClassifyStats</name> <name>EtherClassifyStats</name>
<synopsis> <synopsis>
A table recording statistics on the Ethernet A table recording statistics on the Ethernet
classifying process in the LFB. classifying process in the LFB.
</synopsis> </synopsis>
<optional/> <optional/>
skipping to change at page 79, line 32 skipping to change at page 78, line 4
<typeRef>VlanInputTableType</typeRef> <typeRef>VlanInputTableType</typeRef>
</component> </component>
<component access="read-reset" componentID="3"> <component access="read-reset" componentID="3">
<name>EtherClassifyStats</name> <name>EtherClassifyStats</name>
<synopsis> <synopsis>
A table recording statistics on the Ethernet A table recording statistics on the Ethernet
classifying process in the LFB. classifying process in the LFB.
</synopsis> </synopsis>
<optional/> <optional/>
<typeRef>EtherClassifyStatsTableType</typeRef> <typeRef>EtherClassifyStatsTableType</typeRef>
</component> </component>
</components> </components>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="6"> <LFBClassDef LFBClassID="6">
<name>EtherEncap</name> <name>EtherEncap</name>
<synopsis> <synopsis>
The EtherEncap LFB abstracts the process of encapsulating The EtherEncap LFB abstracts the process of encapsulating
Ethernet headers onto received packets. The encapsulation Ethernet headers onto received packets. The encapsulation
is based on passed metadata. is based on passed metadata.
</synopsis> </synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort group="false"> <inputPort group="false">
<name>EncapIn</name> <name>EncapIn</name>
<synopsis> <synopsis>
A input port receiving IPv4 and/or IPv6 packets for An input port receiving IPv4 and/or IPv6 packets for
encapsulation. A MediaEncapInfoIndex metadata is encapsulation. A MediaEncapInfoIndex metadata is
expected and a VLAN priority metadata is optionally expected, and a VLAN priority metadata is optionally
expected with every input packet. expected with every input packet.
</synopsis> </synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
<ref>IPv4</ref> <ref>IPv4</ref>
<ref>IPv6</ref> <ref>IPv6</ref>
</frameExpected> </frameExpected>
<metadataExpected> <metadataExpected>
<ref>MediaEncapInfoIndex</ref> <ref>MediaEncapInfoIndex</ref>
<ref dependency="optional" defaultValue="0"> <ref dependency="optional" defaultValue="0">
VlanPriority</ref> VlanPriority</ref>
</metadataExpected> </metadataExpected>
</expectation> </expectation>
</inputPort> </inputPort>
</inputPorts> </inputPorts>
<outputPorts> <outputPorts>
<outputPort group="false"> <outputPort group="false">
<name>SuccessOut</name> <name>SuccessOut</name>
<synopsis> <synopsis>
An output port for packets which have found Ethernet An output port for packets that have found Ethernet
L2 information and have been successfully encapsulated L2 information and have been successfully encapsulated
into an Ethernet packet. A L2portID metadata is into an Ethernet packet. An L2PortID metadata is
produced for every output packet. produced for every output packet.
</synopsis> </synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>IPv4</ref> <ref>IPv4</ref>
<ref>IPv6</ref> <ref>IPv6</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>L2PortID</ref> <ref>L2PortID</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
<outputPort group="false"> <outputPort group="false">
<name>ExceptionOut</name> <name>ExceptionOut</name>
<synopsis> <synopsis>
An output port for packets that fail encapsulation An output port for packets that fail encapsulation
in the LFB. An ExceptionID metadata indicates failure in the LFB. An ExceptionID metadata indicates failure
reason. reason.
</synopsis> </synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>IPv4</ref> <ref>IPv4</ref>
<ref>IPv6</ref> <ref>IPv6</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>ExceptionID</ref> <ref>ExceptionID</ref>
<ref>MediaEncapInfoIndex</ref> <ref>MediaEncapInfoIndex</ref>
skipping to change at page 81, line 4 skipping to change at page 79, line 24
</synopsis> </synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>IPv4</ref> <ref>IPv4</ref>
<ref>IPv6</ref> <ref>IPv6</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>ExceptionID</ref> <ref>ExceptionID</ref>
<ref>MediaEncapInfoIndex</ref> <ref>MediaEncapInfoIndex</ref>
<ref availability="conditional">VlanPriority</ref> <ref availability="conditional">VlanPriority</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
</outputPorts> </outputPorts>
<components> <components>
<component componentID="1" access="read-write"> <component componentID="1" access="read-write">
<name>EncapTable</name> <name>EncapTable</name>
<synopsis> <synopsis>
An array table for Ethernet encapsulation information An array table for Ethernet encapsulation information
lookup. Each row of the array contains destination MAC lookup. Each row of the array contains destination MAC
address, source MAC address, VLAN ID, and output address, source MAC address, VLAN ID, and output
logical L2 port ID. logical L2 port ID.
</synopsis> </synopsis>
<typeRef>EncapTableType</typeRef> <typeRef>EncapTableType</typeRef>
</component> </component>
</components> </components>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="7"> <LFBClassDef LFBClassID="7">
<name>EtherMACOut</name> <name>EtherMACOut</name>
<synopsis> <synopsis>
EtherMACOut LFB abstracts an Ethernet port at MAC data link EtherMACOut LFB abstracts an Ethernet port at MAC data link
layer. It specifically describes Ethernet packet process layer. It specifically describes Ethernet packet process
for output to physical port. A downstream LFB is usually an for output to physical port. A downstream LFB is usually
Ethernet physical LFB like EtherPHYcop LFB. Note that an Ethernet physical LFB like EtherPHYCop LFB. Note that
Ethernet output functions are closely related to Ethernet Ethernet output functions are closely related to Ethernet
input functions, therefore some components defined in this input functions; therefore, some components defined in this
LFB are as alias of EtherMACIn LFB. LFB are aliases of EtherMACIn LFB components.
</synopsis> </synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort group="false"> <inputPort group="false">
<name>EtherPktsIn</name> <name>EtherPktsIn</name>
<synopsis> <synopsis>
The input port of the EtherMACOut LFB. It expects any The input port of the EtherMACOut LFB. It expects
type of Ethernet frame. any type of Ethernet frame.
</synopsis> </synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
<ref>EthernetAll</ref> <ref>EthernetAll</ref>
</frameExpected> </frameExpected>
<metadataExpected> <metadataExpected>
<ref>PHYPortID</ref> <ref>PHYPortID</ref>
</metadataExpected> </metadataExpected>
</expectation> </expectation>
</inputPort> </inputPort>
</inputPorts> </inputPorts>
<outputPorts> <outputPorts>
<outputPort group="false"> <outputPort group="false">
<name>EtherPktsOut</name> <name>EtherPktsOut</name>
<synopsis> <synopsis>
A port to output all Ethernet packets, each with a A port to output all Ethernet packets, each with a
metadata indicating the physical port ID the packet metadata indicating the ID of the physical port
is to go. that the packet is to go through.
</synopsis> </synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>EthernetAll</ref> <ref>EthernetAll</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>PHYPortID</ref> <ref>PHYPortID</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
</outputPorts> </outputPorts>
<components> <components>
<component componentID="1" access="read-write"> <component componentID="1" access="read-write">
<name>AdminStatus</name> <name>AdminStatus</name>
<synopsis> <synopsis>
The LFB status administratively requested, which has The LFB status administratively requested, which has
the same data type with a port status. The component the same data type with a port status. The
is defined as alias of AdminStatus component in component is defined as an alias of AdminStatus
EtherMACIn LFB. component in EtherMACIn LFB.
</synopsis> </synopsis>
<alias>PortStatusType</alias> <alias>PortStatusType</alias>
</component> </component>
<component componentID="2" access="read-write"> <component componentID="2" access="read-write">
<name>MTU</name> <name>MTU</name>
<synopsis>Maximum transmission unit (MTU) </synopsis> <synopsis>Maximum transmission unit (MTU) </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="3" access="read-write"> <component componentID="3" access="read-write">
<name>TxFlowControl</name> <name>TxFlowControl</name>
<synopsis> <synopsis>
A flag indicating whether transmit flow control is A flag indicating whether transmit flow control is
applied, defined as alias of TxFlowControl component applied, defined as an alias of TxFlowControl
in EtherMACIn LFB. component in EtherMACIn LFB.
</synopsis> </synopsis>
<optional/> <optional/>
<alias>boolean</alias> <alias>boolean</alias>
</component> </component>
<component componentID="4" access="read-write"> <component componentID="4" access="read-write">
<name>RxFlowControl</name> <name>RxFlowControl</name>
<synopsis> <synopsis>
A flag indicating whether receive flow control is A flag indicating whether receive flow control is
applied, defined as alias of RxFlowControl component applied, defined as an alias of RxFlowControl
in EtherMACIn LFB. component in EtherMACIn LFB.
</synopsis> </synopsis>
<optional/> <optional/>
<alias>boolean</alias> <alias>boolean</alias>
</component> </component>
<component componentID="5" access="read-reset"> <component componentID="5" access="read-reset">
<name>MACOutStats</name> <name>MACOutStats</name>
<synopsis> <synopsis>
The statistics of the EtherMACOut LFB The statistics of the EtherMACOut LFB
</synopsis> </synopsis>
<optional/> <optional/>
<typeRef>MACOutStatsType</typeRef> <typeRef>MACOutStatsType</typeRef>
</component> </component>
</components> </components>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="8"> <LFBClassDef LFBClassID="8">
<name>IPv4Validator</name> <name>IPv4Validator</name>
<synopsis> <synopsis>
This LFB performs IPv4 validation according to RFC1812 and This LFB performs IPv4 validation according to RFC 1812 and
its updates. The IPv4 packet will be output to the its updates. The IPv4 packet will be output to the
corresponding LFB port, indicating whether the packet is corresponding LFB port, indicating whether the packet is
unicast, multicast or whether an exception has occurred or unicast or multicast or whether an exception has occurred
the validation failed. or the validation failed.
</synopsis> </synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort> <inputPort>
<name>ValidatePktsIn</name> <name>ValidatePktsIn</name>
<synopsis> <synopsis>
Input port for data packets to be validated Input port for data packets to be validated
</synopsis> </synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
skipping to change at page 84, line 21 skipping to change at page 82, line 40
<product> <product>
<frameProduced> <frameProduced>
<ref>IPv4Multicast</ref> <ref>IPv4Multicast</ref>
</frameProduced> </frameProduced>
</product> </product>
</outputPort> </outputPort>
<outputPort> <outputPort>
<name>ExceptionOut</name> <name>ExceptionOut</name>
<synopsis> <synopsis>
Output port for all packets with exceptional cases Output port for all packets with exceptional cases
when validating. An ExceptionID metadata indicates when validating. An ExceptionID metadata indicates
the exception case type. the exception case type.
</synopsis> </synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>IPv4</ref> <ref>IPv4</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>ExceptionID</ref> <ref>ExceptionID</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
<outputPort> <outputPort>
<name>FailOut</name> <name>FailOut</name>
<synopsis> <synopsis>
Output port for packets failed validating process. Output port for packets that failed validating
A ValidateErrorID metadata indicates the error type process. A ValidateErrorID metadata indicates the
or failure reason. error type or failure reason.
</synopsis> </synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>IPv4</ref> <ref>IPv4</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>ValidateErrorID</ref> <ref>ValidateErrorID</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
skipping to change at page 85, line 16 skipping to change at page 83, line 36
the LFB. the LFB.
</synopsis> </synopsis>
<optional/> <optional/>
<typeRef>IPv4ValidatorStatsType</typeRef> <typeRef>IPv4ValidatorStatsType</typeRef>
</component> </component>
</components> </components>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="9"> <LFBClassDef LFBClassID="9">
<name>IPv6Validator</name> <name>IPv6Validator</name>
<synopsis> <synopsis>
This LFB performs IPv6 validation according to RFC2460 and This LFB performs IPv6 validation according to RFC 2460 and
its updates. Then the IPv6 packet will be output to the its updates. Then, the IPv6 packet will be output to the
corresponding port, indicating whether the packet is a corresponding port, indicating whether the packet is
unicast or a multicast one, an exception has occurred or unicast or multicast or whether an exception has occurred
the validation failed. or the validation failed.
</synopsis> </synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort> <inputPort>
<name>ValidatePktsIn</name> <name>ValidatePktsIn</name>
<synopsis> <synopsis>
Input port for data packets to be validated Input port for data packets to be validated
</synopsis> </synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
skipping to change at page 86, line 16 skipping to change at page 84, line 36
<product> <product>
<frameProduced> <frameProduced>
<ref>IPv6Multicast</ref> <ref>IPv6Multicast</ref>
</frameProduced> </frameProduced>
</product> </product>
</outputPort> </outputPort>
<outputPort> <outputPort>
<name>ExceptionOut</name> <name>ExceptionOut</name>
<synopsis> <synopsis>
Output port for packets with exceptional cases when Output port for packets with exceptional cases when
validating. An ExceptionID metadata indicates the validating. An ExceptionID metadata indicates the
exception case type. exception case type.
</synopsis> </synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>IPv6</ref> <ref>IPv6</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>ExceptionID</ref> <ref>ExceptionID</ref>
</metadataProduced> </metadataProduced>
</product> </product>
skipping to change at page 87, line 12 skipping to change at page 85, line 32
</synopsis> </synopsis>
<optional/> <optional/>
<typeRef>IPv6ValidatorStatsType</typeRef> <typeRef>IPv6ValidatorStatsType</typeRef>
</component> </component>
</components> </components>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="10"> <LFBClassDef LFBClassID="10">
<name>IPv4UcastLPM</name> <name>IPv4UcastLPM</name>
<synopsis> <synopsis>
The IPv4UcastLPM LFB abstracts the IPv4 unicast Longest The IPv4UcastLPM LFB abstracts the IPv4 unicast Longest
Prefix Match (LPM) process. This LFB supports to implement Prefix Match (LPM) process. This LFB supports
equal-cost multi-path routing (ECMP) and reverse path implementing equal-cost multipath (ECMP) routing and
forwarding (RPF). reverse path forwarding (RPF).
</synopsis> </synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort group="false"> <inputPort group="false">
<name>PktsIn</name> <name>PktsIn</name>
<synopsis> <synopsis>
A port for input of packets to be processed. IPv4 A port for input of packets to be processed.
unicast packets are expected. IPv4 unicast packets are expected.
</synopsis> </synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
<ref>IPv4Unicast</ref> <ref>IPv4Unicast</ref>
</frameExpected> </frameExpected>
</expectation> </expectation>
</inputPort> </inputPort>
</inputPorts> </inputPorts>
<outputPorts> <outputPorts>
<outputPort group="false"> <outputPort group="false">
<name>NormalOut</name> <name>NormalOut</name>
<synopsis> <synopsis>
An output port to output IPv4 unicast packets An output port to output IPv4 unicast packets that
successfully passed the LPM lookup. A HopSelector successfully passed the LPM lookup. A HopSelector
metadata is produced to associate every output packet metadata is produced to associate every output packet
for downstream LFB to do next hop action. for downstream LFB to do next-hop action.
</synopsis> </synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>IPv4Unicast</ref> <ref>IPv4Unicast</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>HopSelector</ref> <ref>HopSelector</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
<outputPort group="false"> <outputPort group="false">
<name>ECMPOut</name> <name>ECMPOut</name>
<synopsis> <synopsis>
The port to output packets needing further ECMP The port to output packets needing further ECMP
processing. A downstream ECMP processing LFB is usually processing. A downstream ECMP processing LFB is
followed to the port. If ECMP is not required, no usually followed to the port. If ECMP is not
downstream LFB may be connected to the port. required, no downstream LFB may be connected to
the port.
</synopsis> </synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>IPv4Unicast</ref> <ref>IPv4Unicast</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>HopSelector</ref> <ref>HopSelector</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
<outputPort group="false"> <outputPort group="false">
<name>ExceptionOut</name> <name>ExceptionOut</name>
<synopsis> <synopsis>
The port to output all packets with exceptional cases The port to output all packets with exceptional cases
happened during LPM process. An ExceptionID metadata happened during LPM process. An ExceptionID metadata
is associated to indicate what caused the exception. is associated to indicate what caused the exception.
</synopsis> </synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>IPv4Unicast</ref> <ref>IPv4Unicast</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>ExceptionID</ref> <ref>ExceptionID</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
</outputPorts> </outputPorts>
<components> <components>
<component componentID="1" access="read-write"> <component componentID="1" access="read-write">
<name>IPv4PrefixTable</name> <name>IPv4PrefixTable</name>
<synopsis> <synopsis>
A table for IPv4 Longest Prefix Match(LPM). The A table for IPv4 Longest Prefix Match(LPM). The
destination IPv4 address of every input packet is destination IPv4 address of every input packet is
used as a search key to look up the table to find used as a search key to look up the table to find
out a next hop selector. out a next-hop selector.
</synopsis> </synopsis>
<typeRef>IPv4PrefixTableType</typeRef> <typeRef>IPv4PrefixTableType</typeRef>
</component> </component>
<component componentID="2" access="read-reset"> <component componentID="2" access="read-reset">
<name>IPv4UcastLPMStats</name> <name>IPv4UcastLPMStats</name>
<synopsis> <synopsis>
The statistics information for the IPv4 unicast LPM The statistics information for the IPv4 unicast LPM
process in the LFB. process in the LFB.
</synopsis> </synopsis>
<optional/> <optional/>
<typeRef>IPv4UcastLPMStatsType</typeRef> <typeRef>IPv4UcastLPMStatsType</typeRef>
</component> </component>
</components> </components>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="11"> <LFBClassDef LFBClassID="11">
<name>IPv6UcastLPM</name> <name>IPv6UcastLPM</name>
<synopsis> <synopsis>
The IPv6UcastLPM LFB abstracts the IPv6 unicast Longest The IPv6UcastLPM LFB abstracts the IPv6 unicast Longest
Prefix Match (LPM) process. This LFB supports to implement Prefix Match (LPM) process. This LFB supports
equal-cost multi-path routing (ECMP) and reverse path implementing equal-cost multipath (ECMP) routing and
forwarding (RPF). reverse path forwarding (RPF).
</synopsis> </synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort group="false"> <inputPort group="false">
<name>PktsIn</name> <name>PktsIn</name>
<synopsis> <synopsis>
A port for input of packets to be processed. IPv6 A port for input of packets to be processed.
unicast packets are expected. IPv6 unicast packets are expected.
</synopsis> </synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
<ref>IPv6Unicast</ref> <ref>IPv6Unicast</ref>
</frameExpected> </frameExpected>
</expectation> </expectation>
</inputPort> </inputPort>
</inputPorts> </inputPorts>
<outputPorts> <outputPorts>
<outputPort group="false"> <outputPort group="false">
<name>NormalOut</name> <name>NormalOut</name>
<synopsis> <synopsis>
An output port to output IPv6 unicast packets An output port to output IPv6 unicast packets that
successfully passed the LPM lookup. A HopSelector successfully passed the LPM lookup. A HopSelector
metadata is produced to associate every output packet metadata is produced to associate every output packet
for downstream LFB to do next hop action. for downstream LFB to do next-hop action.
</synopsis> </synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>IPv6Unicast</ref> <ref>IPv6Unicast</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>HopSelector</ref> <ref>HopSelector</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
<outputPort group="false"> <outputPort group="false">
<name>ECMPOut</name> <name>ECMPOut</name>
<synopsis> <synopsis>
The port to output packets needing further ECMP The port to output packets needing further ECMP
processing. A downstream ECMP processing LFB is usually processing. A downstream ECMP processing LFB is
followed to the port. If ECMP is not required, no usually followed to the port. If ECMP is not
downstream LFB may be connected to the port. required, no downstream LFB may be connected to
the port.
</synopsis> </synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>IPv6Unicast</ref> <ref>IPv6Unicast</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>HopSelector</ref> <ref>HopSelector</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
<outputPort group="false"> <outputPort group="false">
<name>ExceptionOut</name> <name>ExceptionOut</name>
<synopsis> <synopsis>
The port to output all packets with exceptional cases The port to output all packets with exceptional cases
happened during LPM process. An ExceptionID metadata happened during LPM process. An ExceptionID metadata
is associated to indicate what caused the exception. is associated to indicate what caused the exception.
</synopsis> </synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>IPv6Unicast</ref> <ref>IPv6Unicast</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>ExceptionID</ref> <ref>ExceptionID</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
</outputPorts> </outputPorts>
<components> <components>
<component componentID="1" access="read-write"> <component componentID="1" access="read-write">
<name>IPv6PrefixTable</name> <name>IPv6PrefixTable</name>
<synopsis> <synopsis>
A table for IPv6 Longest Prefix Match(LPM). The A table for IPv6 Longest Prefix Match (LPM). The
destination IPv6 address of every input packet is destination IPv6 address of every input packet is
used as a search key to look up the table to find used as a search key to look up the table to find
out a next hop selector. out a next-hop selector.
</synopsis> </synopsis>
<typeRef>IPv6PrefixTableType</typeRef> <typeRef>IPv6PrefixTableType</typeRef>
</component> </component>
<component componentID="2" access="read-reset"> <component componentID="2" access="read-reset">
<name>IPv6UcastLPMStats</name> <name>IPv6UcastLPMStats</name>
<synopsis> <synopsis>
The statistics information for the IPv6 unicast LPM The statistics information for the IPv6 unicast LPM
process in the LFB. process in the LFB.
</synopsis> </synopsis>
<optional/> <optional/>
<typeRef>IPv6UcastLPMStatsType</typeRef> <typeRef>IPv6UcastLPMStatsType</typeRef>
</component> </component>
</components> </components>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="12"> <LFBClassDef LFBClassID="12">
<name>IPv4NextHop</name> <name>IPv4NextHop</name>
<synopsis> <synopsis>
The IPv4NextHop LFB abstracts the process of next hop The IPv4NextHop LFB abstracts the process of next-hop
information application to IPv4 packets. It receives an IPv4 information application to IPv4 packets. It receives an
packet with an associated next hop identifier (HopSelector), IPv4 packet with an associated next-hop identifier
uses the identifier as a table index to look up a next hop (HopSelector) and uses the identifier as a table index
table to find an appropriate output port. The data to look up a next-hop table to find an appropriate output
processing also involves the forwarding TTL decrement and port. The data processing also involves the forwarding
IP checksum recalculation. TTL decrement and IP checksum recalculation.
</synopsis> </synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort group="false"> <inputPort group="false">
<name>PktsIn</name> <name>PktsIn</name>
<synopsis> <synopsis>
A port for input of unicast IPv4 packets, along with A port for input of unicast IPv4 packets, along with
a HopSelector metadata. a HopSelector metadata.
</synopsis> </synopsis>
<expectation> <expectation>
skipping to change at page 91, line 44 skipping to change at page 90, line 17
<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> <synopsis>
The group port for output of packets who successfully The group port for output of packets that
found next hop information. Some metadata are successfully found next-hop information. Some
associated with every packet. metadata are associated with every packet.
</synopsis> </synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>IPv4Unicast</ref> <ref>IPv4Unicast</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>L3PortID</ref> <ref>L3PortID</ref>
<ref>NextHopIPv4Addr</ref> <ref>NextHopIPv4Addr</ref>
<ref availability="conditional"> <ref availability="conditional">
MediaEncapInfoIndex</ref> MediaEncapInfoIndex</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
<outputPort group="false"> <outputPort group="false">
<name>ExceptionOut</name> <name>ExceptionOut</name>
<synopsis> <synopsis>
The output port for packets with exceptional or The output port for packets with exceptional or
failure case. An ExceptionID metadata indicates what failure cases. An ExceptionID metadata indicates
caused the case. what caused the case.
</synopsis> </synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>IPv4Unicast</ref> <ref>IPv4Unicast</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>ExceptionID</ref> <ref>ExceptionID</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
</outputPorts> </outputPorts>
<components> <components>
<component componentID="1"> <component componentID="1">
<name>IPv4NextHopTable</name> <name>IPv4NextHopTable</name>
<synopsis> <synopsis>
The IPv4NextHopTable component. A The IPv4NextHopTable component. A
HopSelector is used to match the table index HopSelector is used to match the table index
to find out a row which contains the next hop to find out a row that contains the next-hop
information result. information result.
</synopsis> </synopsis>
<typeRef>IPv4NextHopTableType</typeRef> <typeRef>IPv4NextHopTableType</typeRef>
</component> </component>
</components> </components>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="13"> <LFBClassDef LFBClassID="13">
<name>IPv6NextHop</name> <name>IPv6NextHop</name>
<synopsis> <synopsis>
The LFB abstracts the process of next hop information The LFB abstracts the process of next-hop information
application to IPv6 packets. It receives an IPv6 packet application to IPv6 packets. It receives an IPv6 packet
with an associated next hop identifier (HopSelector), with an associated next-hop identifier (HopSelector) and
uses the identifier as a table index to look up a next hop uses the identifier as a table index to look up a next-hop
table to find an appropriate output port. table to find an appropriate output port.
</synopsis> </synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort group="false"> <inputPort group="false">
<name>PktsIn</name> <name>PktsIn</name>
<synopsis> <synopsis>
A port for input of unicast IPv6 packets, along with A port for input of unicast IPv6 packets, along with
a HopSelector metadata. a HopSelector metadata.
</synopsis> </synopsis>
skipping to change at page 93, line 24 skipping to change at page 91, line 46
<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> <synopsis>
The group port for output of packets who successfully The group port for output of packets that successfully
found next hop information. Some metadata are found next-hop information. Some metadata are
associated with every packet. associated with every packet.
</synopsis> </synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>IPv6Unicast</ref> <ref>IPv6Unicast</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>L3PortID</ref> <ref>L3PortID</ref>
<ref>NextHopIPv6Addr</ref> <ref>NextHopIPv6Addr</ref>
<ref availability="conditional"> <ref availability="conditional">
MediaEncapInfoIndex</ref> MediaEncapInfoIndex</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
<outputPort group="false"> <outputPort group="false">
<name>ExceptionOut</name> <name>ExceptionOut</name>
<synopsis> <synopsis>
The output port for packets with exceptional or The output port for packets with exceptional or
failure case. An ExceptionID metadata indicates what failure cases. An ExceptionID metadata indicates
caused the case. what caused the case.
</synopsis> </synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>IPv6Unicast</ref> <ref>IPv6Unicast</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>ExceptionID</ref> <ref>ExceptionID</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
</outputPorts> </outputPorts>
<components> <components>
<component componentID="1"> <component componentID="1">
<name>IPv6NextHopTable</name> <name>IPv6NextHopTable</name>
<synopsis> <synopsis>
The IPv6NextHopTable component. A HopSelector is used The IPv6NextHopTable component. A HopSelector is
to match the table index to find out a row which used to match the table index to find out a row that
contains the next hop information result. contains the next-hop information result.
</synopsis> </synopsis>
<typeRef>IPv6NextHopTableType</typeRef> <typeRef>IPv6NextHopTableType</typeRef>
</component> </component>
</components> </components>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="14"> <LFBClassDef LFBClassID="14">
<name>RedirectIn</name> <name>RedirectIn</name>
<synopsis> <synopsis>
The RedirectIn LFB abstracts the process for the ForCES CE to The RedirectIn LFB abstracts the process for the ForCES CE to
inject data packets into the ForCES FE LFBs. inject data packets into the ForCES FE LFBs.
</synopsis> </synopsis>
<version>1.0</version> <version>1.0</version>
<outputPorts> <outputPorts>
<outputPort group="true"> <outputPort group="true">
<name>PktsOut</name> <name>PktsOut</name>
<synopsis> <synopsis>
The output port of RedirectIn LFB, which is defined as The output port of RedirectIn LFB, which is defined as
a group port type. From LFB topology point of view, a group port type. From the LFB topology's point of
the RedirectIn LFB acts as a source point for data view, the RedirectIn LFB acts as a source point for
packets coming from CE, therefore the LFB is data packets coming from CE; therefore, the LFB is
defined with a singleton output port (and no input defined with a singleton output port (and no input
port). port).
</synopsis> </synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>Arbitrary</ref> <ref>Arbitrary</ref>
</frameProduced> </frameProduced>
</product> </product>
</outputPort> </outputPort>
</outputPorts> </outputPorts>
skipping to change at page 95, line 20 skipping to change at page 93, line 42
<name>RedirectOut</name> <name>RedirectOut</name>
<synopsis> <synopsis>
The RedirectOut LFB abstracts the process for LFBs in a The RedirectOut LFB abstracts the process for LFBs in a
ForCES FE to deliver data packets to the ForCES CE. ForCES FE to deliver data packets to the ForCES CE.
</synopsis> </synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort group="false"> <inputPort group="false">
<name>PktsIn</name> <name>PktsIn</name>
<synopsis> <synopsis>
The input port for the RedirectOut LFB. From the LFB's The input port for the RedirectOut LFB. From the LFB
topology point of view, the RedirectOut LFB acts as a topology's point of view, the RedirectOut LFB acts as
sink point for data packets going to the CE, therefore a sink point for data packets going to the CE;
RedirectOut LFB is defined with a singleton input therefore, RedirectOut LFB is defined with a
port (and no output port). singleton input port (and no output port).
</synopsis> </synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
<ref>Arbitrary</ref> <ref>Arbitrary</ref>
</frameExpected> </frameExpected>
</expectation> </expectation>
</inputPort> </inputPort>
</inputPorts> </inputPorts>
<components> <components>
<component componentID="1"> <component componentID="1">
<name>NumPacketsSent</name> <name>NumPacketsSent</name>
<synopsis> <synopsis>
Numble of packets sent to CE. Number of packets sent to CE.
</synopsis> </synopsis>
<optional/> <optional/>
<typeRef>uint64</typeRef> <typeRef>uint64</typeRef>
</component> </component>
</components> </components>
</LFBClassDef> </LFBClassDef>
<LFBClassDef LFBClassID="16"> <LFBClassDef LFBClassID="16">
<name>BasicMetadataDispatch</name> <name>BasicMetadataDispatch</name>
<synopsis> <synopsis>
The BasicMetadataDispatch LFB is defined to abstract the The BasicMetadataDispatch LFB is defined to abstract the
process by which packets are dispatched to various output process by which packets are dispatched to various output
paths based on associated metadata value. Current version of paths based on associated metadata value. Current
the LFB only allows the metadata value be 32-bits integer. version of the LFB only allows the metadata value to be
a 32-bit integer.
</synopsis> </synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort> <inputPort>
<name>PktsIn</name> <name>PktsIn</name>
<synopsis> <synopsis>
The packet input port for dispatching. Every input The packet input port for dispatching. Every input
packet should be associated with a metadata that will packet should be associated with a metadata that will
be used by the LFB to do the dispatch. be used by the LFB to do the dispatch.
</synopsis> </synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
<ref>Arbitrary</ref> <ref>Arbitrary</ref>
</frameExpected> </frameExpected>
<metadataExpected> <metadataExpected>
<ref>Arbitrary</ref> <ref>Arbitrary</ref>
</metadataExpected> </metadataExpected>
</expectation> </expectation>
</inputPort> </inputPort>
</inputPorts> </inputPorts>
<outputPorts> <outputPorts>
<outputPort group="true"> <outputPort group="true">
<name>PktsOut</name> <name>PktsOut</name>
<synopsis> <synopsis>
The group output port which outputs dispatching The group output port that outputs dispatching
results. A packet with its associated metadata having results. A packet with its associated metadata
found an OutputIndex by successfully looking up the having found an OutputIndex by successfully looking
dispatch table will be output to the group port up the dispatch table will be output to the group
instance with the corresponding index. port instance with the corresponding index.
</synopsis> </synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>Arbitrary</ref> <ref>Arbitrary</ref>
</frameProduced> </frameProduced>
</product> </product>
</outputPort> </outputPort>
<outputPort group="false"> <outputPort group="false">
<name>ExceptionOut</name> <name>ExceptionOut</name>
<synopsis> <synopsis>
The output port which outputs packets which failed The output port that outputs packets that failed
to process. An ExceptionID metadata indicates what to process. An ExceptionID metadata indicates what
caused the exception. caused the exception.
</synopsis> </synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>Arbitrary</ref> <ref>Arbitrary</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>ExceptionID</ref> <ref>ExceptionID</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
</outputPorts> </outputPorts>
<components> <components>
<component access="read-write" componentID="1"> <component access="read-write" componentID="1">
<name>MetadataID</name> <name>MetadataID</name>
<synopsis> <synopsis>
The ID of the metadata to be The ID of the metadata to be
used for dispatching packets. used for dispatching packets.
skipping to change at page 97, line 43 skipping to change at page 96, line 18
<synopsis> <synopsis>
This is a preliminary generic scheduler LFB abstracting This is a preliminary generic scheduler LFB abstracting
a simple scheduling process, which may be used as a a simple scheduling process, which may be used as a
basic LFB to construct a more complex scheduler LFB. basic LFB to construct a more complex scheduler LFB.
</synopsis> </synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort group="true"> <inputPort group="true">
<name>PktsIn</name> <name>PktsIn</name>
<synopsis> <synopsis>
The group input port of the LFB. Inside the LFB, The group input port of the LFB. Inside the LFB,
each instance of the group port is connected to each instance of the group port is connected to
a queue marked with a queue ID, whose value is a queue marked with a queue ID, whose value is
index of the port instance. index of the port instance.
</synopsis> </synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
<ref>Arbitrary</ref> <ref>Arbitrary</ref>
</frameExpected> </frameExpected>
</expectation> </expectation>
</inputPort> </inputPort>
</inputPorts> </inputPorts>
<outputPorts> <outputPorts>
<outputPort> <outputPort>
<name>PktsOut</name> <name>PktsOut</name>
<synopsis> <synopsis>
The output port of the LFB. Scheduled packets are The output port of the LFB. Scheduled packets are
output from the port. output from the port.
</synopsis> </synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>Arbitrary</ref> <ref>Arbitrary</ref>
</frameProduced> </frameProduced>
</product> </product>
</outputPort> </outputPort>
</outputPorts> </outputPorts>
<components> <components>
skipping to change at page 98, line 30 skipping to change at page 97, line 4
</outputPorts> </outputPorts>
<components> <components>
<component access="read-write" componentID="1"> <component access="read-write" componentID="1">
<name>SchedulingDiscipline</name> <name>SchedulingDiscipline</name>
<synopsis> <synopsis>
The SchedulingDiscipline component, which is for the The SchedulingDiscipline component, which is for the
CE to specify a scheduling discipline to the LFB. CE to specify a scheduling discipline to the LFB.
</synopsis> </synopsis>
<typeRef>SchdDisciplineType</typeRef> <typeRef>SchdDisciplineType</typeRef>
<defaultValue>1</defaultValue> <defaultValue>1</defaultValue>
</component> </component>
<component access="read-only" componentID="2"> <component access="read-only" componentID="2">
<name>QueueStats</name> <name>QueueStats</name>
<synopsis> <synopsis>
The QueueStats component, which is defined to allow The QueueStats component, which is defined to allow
CE to query every queue statistics in the scheduler. the CE to query every queue statistics in the
scheduler.
</synopsis> </synopsis>
<optional/> <optional/>
<typeRef>QueueStatsTableType</typeRef> <typeRef>QueueStatsTableType</typeRef>
</component> </component>
</components> </components>
<capabilities> <capabilities>
<capability componentID="30"> <capability componentID="30">
<name>QueueLenLimit</name> <name>QueueLenLimit</name>
<synopsis> <synopsis>
The QueueLenLimit capability, which specifies The QueueLenLimit capability, which specifies
maximum length of each queue. The length unit is in maximum length of each queue. The length unit is in
bytes. bytes.
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</capability> </capability>
</capabilities> </capabilities>
</LFBClassDef> </LFBClassDef>
</LFBClassDefs> </LFBClassDefs>
</LFBLibrary> </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
It is assumed the LFB topology on the FE described has already been It is assumed the LFB topology on the FE described has already been
established by the CE and maps to the use cases illustrated in this established by the CE and maps to the use cases illustrated in this
section. section.
skipping to change at page 100, line 31 skipping to change at page 98, line 13
should be able to express different NE applications. should be able to express different NE applications.
7.1. IPv4 Forwarding 7.1. IPv4 Forwarding
Figure 2 shows the typical LFB processing path for an IPv4 unicast Figure 2 shows the typical LFB processing path for an IPv4 unicast
forwarding case with Ethernet media interfaces by use of the base LFB forwarding case with Ethernet media interfaces by use of the base LFB
classes. Note that in the figure, to focus on the IP forwarding classes. Note that in the figure, to focus on the IP forwarding
function, some inputs or outputs of LFBs that are not related to the function, some inputs or outputs of LFBs that are not related to the
IPv4 forwarding function are not shown. For example, an IPv4 forwarding function are not shown. For example, an
EtherClassifier LFB normally has two output ports: a "ClassifyOut" EtherClassifier LFB normally has two output ports: a "ClassifyOut"
group output port and a "ExceptionOut" singleton output port, with group output port and an "ExceptionOut" singleton output port, with
the group port contains various port instances according to various the group port containing various port instances according to various
classified packet types(Section 5.1.3). While in this figure, only classified packet types (Section 5.1.3). In this figure, only the
the IPv4 and IPv6 packet output port instances are shown for IPv4 and IPv6 packet output port instances are shown for displaying
displaying the mere IPv4 forwarding processing function. the mere IPv4 forwarding processing function.
+-----+ +------+ +-----+ +------+
| | | | | | | |
| |<---------------|Ether |<----------------------------+ | |<---------------|Ether |<----------------------------+
| | |MACOut| | | | |MACOut| |
| | | | | | | | | |
|Ether| +------+ | |Ether| +------+ |
|PHY | | |PHY | |
|Cop | +---+ | |Cop | +---+ |
|#1 | +-----+ | |----->IPv6 Packets | |#1 | +-----+ | |----->IPv6 Packets |
skipping to change at page 101, line 41 skipping to change at page 99, line 41
|Cop | Classifier | | +-------+ | | |Cop | Classifier | | +-------+ | |
|#n | +------+ | | |Ether | | | |#n | +------+ | | |Ether | | |
| | | | | |<--|Encap |<-+ | | | | | | |<--|Encap |<-+ |
| | | |<------| | | | | | | | |<------| | | | |
| |<---------------|Ether | ...| | +-------+ | | |<---------------|Ether | ...| | +-------+ |
| | |MACOut| +---| | | | | |MACOut| +---| | |
| | | | | +----+ | | | | | | +----+ |
+-----+ +------+ | BasicMetadataDispatch | +-----+ +------+ | BasicMetadataDispatch |
+----------->-------------+ +----------->-------------+
Figure 2: LFB use case for IPv4 forwarding Figure 2: LFB Use Case for IPv4 Forwarding
In the LFB use case, a number of EtherPHYCop LFB(Section 5.1.1) In the LFB use case, a number of EtherPHYCop LFB (Section 5.1.1)
instances are used to describe physical layer functions of the ports. instances are used to describe physical-layer functions of the ports.
PHYPortID metadata is generated by EtherPHYCop LFB and is used by all PHYPortID metadata is generated by the EtherPHYCop LFB and is used by
the subsequent downstream LFBs. An EtherMACIn LFB(Section 5.1.2), all the subsequent downstream LFBs. An EtherMACIn LFB
which describe the MAC layer processing, follows every EtherPHYCop (Section 5.1.2), which describes the MAC-layer processing, follows
LFB. The EtherMACIn LFB may do a locality check of MAC addresses if every EtherPHYCop LFB. The EtherMACIn LFB may do a locality check of
the CE configures the appropriate EtherMACIn LFB component. MAC addresses if the CE configures the appropriate EtherMACIn LFB
component.
Ethernet packets out of the EtherMACIn LFB are sent to an Ethernet packets out of the EtherMACIn LFB are sent to an
EtherClassifier LFB (Section 5.1.3) to be decapsulated and classified EtherClassifier LFB (Section 5.1.3) to be decapsulated and classified
into network layer types like IPv4, IPv6, ARP, etc. In the example into network-layer types like IPv4, IPv6, ARP, etc. In the example
use case, every physical Ethernet interface is associated with one use case, every physical Ethernet interface is associated with one
Classifier instance; although not illustrated, it is also feasible Classifier instance; although not illustrated, it is also feasible
that all physical interfaces are associated with only one Ethernet that all physical interfaces are associated with only one Ethernet
Classifier instance. Classifier instance.
EtherClassifier uses the PHYPortID metadata, the Ethernet type of the EtherClassifier uses the PHYPortID metadata, the Ethernet type of the
input packet, and VlanID (if present in the input Ethernet packets), input packet, and VlanID (if present in the input Ethernet packets)
to decide the packet network layer type and the LFB output port to to decide the packet network-layer type and the LFB output port to
the downstream LFB. The EtherClassifier LFB also assigns a new the downstream LFB. The EtherClassifier LFB also assigns a new
logical port ID metadata to the packet for later use. The logical port ID metadata to the packet for later use. The
EtherClassifier may also generate some new metadata for every packet EtherClassifier may also generate some new metadata for every packet,
like EtherType, SrcMAC, DstMAC, LogicPortID, etc for consumption by like EtherType, SrcMAC, DstMAC, LogicPortID, etc., for consumption by
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 next hop 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 next hop ID metadata to do derive where The IPv4NextHop LFB uses the next-hop ID metadata to derive where the
the packet is to go next and the media encapsulation type for the packet is to go next and the media encapsulation type for the port,
port, etc. The IPv4NextHop LFB generates the L3PortID metadata used etc. The IPv4NextHop LFB generates the L3PortID metadata used to
to identify a next hop output physical/logical port. In the example identify a next-hop output physical/logical port. In the example use
use case, the next hop output port is an Ethernet type; as a result, case, the next-hop output port is an Ethernet type; as a result, the
the packet and its L3 port ID metadata are sent downstream to an 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
finally dispatched to different output physical/logical ports based finally dispatched to different output physical/logical ports based
on the L3PortID metadata sent to the LFB. on the L3PortID metadata sent to the LFB.
7.2. ARP processing 7.2. ARP Processing
Figure 3 shows the processing path for ARP protocol in the case the Figure 3 shows the processing path for the Address Resolution
CE implements the ARP processing function. By no means is this the Protocol (ARP) in the case the CE implements the ARP processing
only way ARP processing could be achieved; as an example ARP function. By no means is this the only way ARP processing could be
processing could happen at the FE - but that discussion is out of achieved; as an example, ARP processing could happen at the FE, but
scope for this use case. that discussion is out of the scope of 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
skipping to change at page 103, line 30 skipping to change at page 101, line 37
| | +-->| |--+ +---+ |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 3: LFB use case for ARP Figure 3: LFB Use Case for ARP
There are two ways ARP processing could be triggered in the CE as There are two ways ARP processing could be triggered in the CE as
illustrated in Figure 3: illustrated in Figure 3:
o ARP packets arriving from outside of the NE. o ARP packets arriving from outside of the NE.
o IPV4 packets failing to resolve within the FE. o IPV4 packets failing to resolve within the FE.
ARP packets from network interfaces are filtered out by ARP packets from network interfaces are filtered out by
EtherClassifier LFB. The classified ARP packets and associated EtherClassifier LFB. The classified ARP packets and associated
metadata are then sent downstream to the RedirectOut LFB metadata are then sent downstream to the RedirectOut LFB
(Section 5.4.2) to be transported to CE. (Section 5.4.2) to be transported to CE.
The EtherEncap LFB, as described in Section 5.1.4, receives packets The EtherEncap LFB, as described in Section 5.1.4, receives packets
that need Ethernet L2 encapsulating. When the EtherEncap LFB fails that need Ethernet L2 encapsulating. When the EtherEncap LFB fails
to find the necessary L2 Ethernet information to encapsulate the to find the necessary L2 Ethernet information with which to
packet with, it outputs the packet to its ExceptionOut LFB port. encapsulate the packet, it outputs the packet to its ExceptionOut LFB
Downstream to EtherEncap LFB's ExceptionOut LFB port is the port. Downstream to EtherEncap LFB's ExceptionOut LFB port is the
RedirectOut LFB which transports the packet to the CE (Section 5.1.4 RedirectOut LFB, which transports the packet to the CE (see
on EtherEncap LFB for details). Section 5.1.4 on EtherEncap LFB for details).
To achieve its goal, the CE needs to generate ARP request and To achieve its goal, the CE needs to generate ARP request and
response packets and send them to external (to the NE) networks. ARP response packets and send them to external (to the NE) networks. ARP
request and response packets from the CE are redirected to an FE via request and response packets from the CE are redirected to an FE via
a RedirectIn LFB (Section 5.4.1). a RedirectIn LFB (Section 5.4.1).
As was the case with forwarded IPv4 packets, outgoing ARP packets are As was the case with forwarded IPv4 packets, outgoing ARP packets are
also encapsulated to Ethernet format by the EtherEncap LFB, and then also encapsulated to Ethernet format by the EtherEncap LFB, and then
dispatched to different interfaces via a BasicMetadataDispatch LFB. dispatched to different interfaces via a BasicMetadataDispatch LFB.
The BasicMetadataDispatch LFB dispatches the packets according to the The BasicMetadataDispatch LFB dispatches the packets according to the
L3PortID metadata included in every ARP packet sent from CE. L3PortID metadata included in every ARP packet sent from CE.
8. Contributors 8. IANA Considerations
The authors would like to thank Jamal Hadi Salim, Ligang Dong, and
Fenggen Jia who made major contributions to the development of this
document. Ligang Dong and Fenggen Jia were also two of the authors
of earlier documents which this document is evolved from.
Jamal Hadi Salim
Mojatatu Networks
Ottawa, Ontario
Canada
Email: hadi@mojatatu.com
Ligang Dong
Zhejiang Gongshang University
18 Xuezheng Str., Xiasha University Town
Hangzhou,310018
P.R.China
EMail: donglg@zjsu.edu.cn
Fenggen Jia
National Digital Switching Center(NDSC)
Jianxue Road
Zhengzhou 452000
P.R.China
EMail: jfg@mail.ndsc.com.cn
9. Acknowledgements
The authors would like to acknowledge the following people, whose
input has been particularly helpful during development of this
document:
Edward Crabbe
Adrian Farrel
Rong Jin
Bin Zhuge
Ming Gao
Jingjing Zhou
Xiaochun Wu
Derek Atkins
Stephen Farrel
Meral Shirazipour
Jari Arkko
Martin Stiemerling
Stewart Bryant
Richard Barnes
10. IANA Considerations
IANA has created a registry of ForCES LFB Class Names and the IANA has created a registry of ForCES LFB class names and the
corresponding ForCES LFB Class Identifiers, with the location of the corresponding ForCES LFB class identifiers, with the location of the
definition of the ForCES LFB Class, in accordance with the rules to definition of the ForCES LFB class, in accordance with the rules to
use the namespace. use the namespace.
The LFB library in this document needs for unique class names and This document registers the unique class names and numeric class
numeric class identifiers of all LFBs. Besides, this document also identifiers for the LFBs listed in Section 8.1. Besides, this
needs to define the following namespaces: document defines the following namespaces:
o Metadata ID, defined in Section 4.3 and Section 4.4 o Metadata ID, defined in Sections 4.3 and 4.4
o Exception ID, defined in Section 4.4 o Exception ID, defined in Section 4.4
o Validate Error ID, defined in Section 4.4 o Validate Error ID, defined in Section 4.4
10.1. LFB Class Names and LFB Class Identifiers 8.1. LFB Class Names and LFB Class Identifiers
LFB classes defined by this document belongs to IETF defined LFBs by LFB classes defined by this document belong to LFBs defined by
Standard Track RFCs. According to IANA, the identifier namespace for Standards Track RFCs. According to IANA, the registration procedure
these LFB classes is from 3 to 65535. is Standards Action for the range 0 to 65535 and First Come First
Served with any publicly available specification for over 65535.
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 6956, |
| | | abstracted at physical | document) | | | | abstracted at physical | Section 5.1.1|
| | | layer. | Section 5.1.1| | | | layer. | |
| | | | | | | | | |
| 4 | EtherMACIn | Define an Ethernet | RFC???? | | 4 | EtherMACIn | Define an Ethernet | RFC 6956, |
| | | 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 6956, |
| | | 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 6956, |
| | | 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 6956 |
| | | 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 6956, |
| | | validation. | Section 5.2.1| | | | validation. | Section 5.2.1|
| | | | | | | | | |
| 9 | IPv6Validator | Perform IPv6 packets | RFC ???? | | 9 | IPv6Validator | Perform IPv6 packets | RFC 6956, |
| | | validation. | Section 5.2.2| | | | validation. | Section 5.2.2|
| | | | | | | | | |
| 10 | IPv4UcastLPM | Perform IPv4 Longest | RFC ???? | | 10 | IPv4UcastLPM | Perform IPv4 Longest | RFC 6956, |
| | | 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 6956, |
| | | 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 6956, |
| | | 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 6956, |
| | | 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 6956, |
| | | 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 6956, |
| | | 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 6956, |
| | 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 |GenericScheduler| Define a preliminary | RFC 6956, |
| | Scheduler | generic scheduling | Section 5.5.2| | | | generic scheduling | Section 5.5.2|
| | | process. | | | | | process. | |
+-----------+---------------+------------------------+--------------+ +----------+--------------- +------------------------+--------------+
Table 1 Table 1
10.2. Metadata ID 8.2. Metadata ID
The Metadata ID namespace is 32 bits long. The following is the The Metadata ID namespace is 32 bits long. Below are the guidelines
guideline for managing the namespace. for managing the namespace.
Metadata ID 0x00000000-0x7FFFFFFF Metadata IDs in the range of 0x00000001-0x7FFFFFFF are Specification
Metadata with IDs in this range are Specification Required Required [RFC5226]. A metadata ID using this range MUST be
[RFC5226]. A metadata ID using this range MUST be documented in documented in an RFC or other permanent and readily available
an RFC or other permanent and readily available references. reference.
Values assigned by this specification: Values assigned by this specification:
+--------------+-------------------------+--------------------------+ +--------------+-------------------------+--------------------------+
| Value | Name | Definition | | Value | Name | Definition |
+--------------+-------------------------+--------------------------+ +--------------+-------------------------+--------------------------+
| 0x00000001 | PHYPortID | See Section 4.4 | | 0x00000000 | Reserved | RFC 6956 |
| 0x00000002 | SrcMAC | See Section 4.4 | | 0x00000001 | PHYPortID | RFC 6956, Section 4.4 |
| 0x00000003 | DstMAC | See Section 4.4 | | 0x00000002 | SrcMAC | RFC 6956, Section 4.4 |
| 0x00000004 | LogicalPortID | See Section 4.4 | | 0x00000003 | DstMAC | RFC 6956, Section 4.4 |
| 0x00000005 | EtherType | See Section 4.4 | | 0x00000004 | LogicalPortID | RFC 6956, Section 4.4 |
| 0x00000006 | VlanID | See Section 4.4 | | 0x00000005 | EtherType | RFC 6956, Section 4.4 |
| 0x00000007 | VlanPriority | See Section 4.4 | | 0x00000006 | VlanID | RFC 6956, Section 4.4 |
| 0x00000008 | NextHopIPv4Addr | See Section 4.4 | | 0x00000007 | VlanPriority | RFC 6956, Section 4.4 |
| 0x00000009 | NextHopIPv6Addr | See Section 4.4 | | 0x00000008 | NextHopIPv4Addr | RFC 6956, Section 4.4 |
| 0x0000000A | HopSelector | See Section 4.4 | | 0x00000009 | NextHopIPv6Addr | RFC 6956, Section 4.4 |
| 0x0000000B | ExceptionID | See Section 4.4 | | 0x0000000A | HopSelector | RFC 6956, Section 4.4 |
| 0x0000000C | ValidateErrorID | See Section 4.4 | | 0x0000000B | ExceptionID | RFC 6956, Section 4.4 |
| 0x0000000D | L3PortID | See Section 4.4 | | 0x0000000C | ValidateErrorID | RFC 6956, Section 4.4 |
| 0x0000000E | RedirectIndex | See Section 4.4 | | 0x0000000D | L3PortID | RFC 6956, Section 4.4 |
| 0x0000000F | MediaEncapInfoIndex | See Section 4.4 | | 0x0000000E | RedirectIndex | RFC 6956, Section 4.4 |
| 0x0000000F | MediaEncapInfoIndex | RFC 6956, Section 4.4 |
| 0x80000000- | Reserved for | RFC 6956 |
| 0xFFFFFFFF | Private Use | |
+--------------+-------------------------+--------------------------+ +--------------+-------------------------+--------------------------+
Table 2 Table 2
Metadata ID 0x80000000-0xFFFFFFFF 8.3. Exception ID
Metadata IDs in this range are reserved for vendor private
extensions and are the responsibility of individuals, i.e., used
according to the Private Use [RFC5226] policy.
10.3. Exception ID
The Exception ID namespace is 32 bits long. The following is the The Exception ID namespace is 32 bits long. Below are the guidelines
guideline for managing the namespace. for managing the namespace.
Exception ID 0x00000000-0x7FFFFFFF Exception IDs in the range of 0x00000000-0x7FFFFFFF are Specification
Exception IDs in this range are Specification Required [RFC5226]. Required [RFC5226]. An exception ID using this range MUST be
An exception ID using this range MUST be documented in an RFC or documented in an RFC or other permanent and readily available
other permanent and readily available references. reference.
Values assigned by this specification: Values assigned by this specification:
+--------------+---------------------------------+------------------+ +--------------+---------------------------------+------------------+
| Value | Name | Definition | | Value | Name | Definition |
+--------------+---------------------------------+------------------+ +--------------+---------------------------------+------------------+
| 0x00000000 | AnyUnrecognizedExceptionCase | See Section 4.4 | | 0x00000000 | AnyUnrecognizedExceptionCase | See Section 4.4 |
| 0x00000001 | ClassifyNoMatching | See Section 4.4 | | 0x00000001 | ClassifyNoMatching | See Section 4.4 |
| 0x00000002 | MediaEncapInfoIndexInvalid | See Section 4.4 | | 0x00000002 | MediaEncapInfoIndexInvalid | See Section 4.4 |
| 0x00000003 | EncapTableLookupFailed | See Section 4.4 | | 0x00000003 | EncapTableLookupFailed | See Section 4.4 |
| 0x00000004 | BadTTL | See Section 4.4 | | 0x00000004 | BadTTL | See Section 4.4 |
| 0x00000005 | IPv4HeaderLengthMismatch | See Section 4.4 | | 0x00000005 | IPv4HeaderLengthMismatch | See Section 4.4 |
| 0x00000006 | RouterAlertOptions | See Section 4.4 | | 0x00000006 | RouterAlertOptions | See Section 4.4 |
| 0x00000007 | IPv6HopLimitZero | See Section 4.4 | | 0x00000007 | IPv6HopLimitZero | See Section 4.4 |
| 0x00000008 | IPv6NextHeaderHBH | See Section 4.4 | | 0x00000008 | IPv6NextHeaderHBH | See Section 4.4 |
| 0x00000009 | SrcAddressExecption | See Section 4.4 | | 0x00000009 | SrcAddressException | See Section 4.4 |
| 0x0000000A | DstAddressExecption | See Section 4.4 | | 0x0000000A | DstAddressException | See Section 4.4 |
| 0x0000000B | LPMLookupFailed | See Section 4.4 | | 0x0000000B | LPMLookupFailed | See Section 4.4 |
| 0x0000000C | HopSelectorInvalid | See Section 4.4 | | 0x0000000C | HopSelectorInvalid | See Section 4.4 |
| 0x0000000D | NextHopLookupFailed | See Section 4.4 | | 0x0000000D | NextHopLookupFailed | See Section 4.4 |
| 0x0000000E | FragRequired | See Section 4.4 | | 0x0000000E | FragRequired | See Section 4.4 |
| 0x0000000F | MetadataNoMatching | See Section 4.4 | | 0x0000000F | MetadataNoMatching | See Section 4.4 |
| 0x80000000- | Reserved for | RFC 6956 |
| 0xFFFFFFFF | Private Use | |
+--------------+---------------------------------+------------------+ +--------------+---------------------------------+------------------+
Table 3 Table 3
Exception ID 0x80000000-0xFFFFFFFF 8.4. Validate Error ID
Exception IDs in this range are reserved for vendor private
extensions and are the responsibility of individuals, i.e., used
according to the Private Use [RFC5226] policy.
10.4. Validate Error ID
The Validate Error ID namespace is 32 bits long. The following is The Validate Error ID namespace is 32 bits long. Below are the
the guideline for managing the namespace. guidelines for managing the namespace.
Validate Error ID 0x00000000-0x7FFFFFFF Validate Error IDs in the range of 0x00000000-0x7FFFFFFF are
Validate Error IDs in this range are Specification Required Specification Required [RFC5226]. A Validate Error ID using this
[RFC5226]. A Validate Error ID using this range MUST be range MUST be documented in an RFC or other permanent and readily
documented in an RFC or other permanent and readily available available reference.
references.
Values assigned by this specification: Values assigned by this specification:
+--------------+---------------------------------+------------------+ +--------------+---------------------------------+------------------+
| Value | Name | Definition | | Value | Name | Definition |
+--------------+---------------------------------+------------------+ +--------------+---------------------------------+------------------+
| 0x00000000 | AnyUnrecognizedValidateErrorCase| See Section 4.4 | | 0x00000000 | AnyUnrecognizedValidateErrorCase| See Section 4.4 |
| 0x00000001 | InvalidIPv4PacketSize | See Section 4.4 | | 0x00000001 | InvalidIPv4PacketSize | See Section 4.4 |
| 0x00000002 | NotIPv4Packet | See Section 4.4 | | 0x00000002 | NotIPv4Packet | See Section 4.4 |
| 0x00000003 | InvalidIPv4HeaderLengthSize | See Section 4.4 | | 0x00000003 | InvalidIPv4HeaderLengthSize | See Section 4.4 |
| 0x00000004 | InvalidIPv4LengthFieldSize | See Section 4.4 | | 0x00000004 | InvalidIPv4LengthFieldSize | See Section 4.4 |