draft-ietf-forces-lfb-lib-00.txt   draft-ietf-forces-lfb-lib-01.txt 
Internet Engineering Task Force W. Wang Internet Engineering Task Force W. Wang
Internet-Draft Zhejiang Gongshang University Internet-Draft Zhejiang Gongshang University
Intended status: Informational E. Haleplidis Intended status: Informational E. Haleplidis
Expires: December 31, 2009 University of Patras Expires: September 4, 2010 University of Patras
K. Ogawa K. Ogawa
NTT Corporation NTT Corporation
F. Jia F. Jia
National Digital Switching National Digital Switching
Center(NDSC) Center(NDSC)
J. Halpern J. Halpern
Ericsson Ericsson
June 29, 2009 March 3, 2010
ForCES LFB Library ForCES LFB Library
draft-ietf-forces-lfb-lib-00 draft-ietf-forces-lfb-lib-01
Abstract
The forwarding and Control Element Separation (ForCES) protocol
defines a standard communication and control mechanism through which
a Control Element (CE) can control the behavior of a Forwarding
Element (FE). That control is accomplished through manipulating
components of Logical Function Blocks (LFBs), whose structure is
defined in a model RFC produced by the working group.In order to
build an actual solution using this protocol, there needs to be a set
of Logical Function Block definitions that can be instantiated by FEs
and controlled by CEs. This document provides a sample space of such
definitions. It is anticipated that additional defining documents
will be produced over time.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 40 skipping to change at page 2, line 8
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 31, 2009. This Internet-Draft will expire on September 4, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
The forwarding and Control Element Separation (ForCES) protocol described in the BSD License.
defines a standard communication and control mechanism through which
a Control Element (CE) can control the behavior of a Forwarding
Element (FE). That control is accomplished through manipulating
components of Logical Function Blocks (LFBs), whose structure is
defined in a model RFC produced by the working group.In order to
build an actual solution using this protocol, there needs to be a set
of Logical Function Block definitions that can be instantiated by FEs
and controlled by CEs. This document provides a sample space of such
definitions. It is anticipated that additional defining documents
will be produced over time.
Table of Contents Table of Contents
1. Terminology and Conventions . . . . . . . . . . . . . . . . . 5 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Base Definitions . . . . . . . . . . . . . . . . . . . . . . 10 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Framedefs . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Base Types . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. DataTypeDefs . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3. MetaDataDefs . . . . . . . . . . . . . . . . . . . . . . 38 5.2. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 13
5. LFB Descriptions . . . . . . . . . . . . . . . . . . . . . . 44 5.3. MetaData Types . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Core LFBs . . . . . . . . . . . . . . . . . . . . . . . . 44 5.4. XML Definition for Base Type Library . . . . . . . . . . . 15
5.1.1. FEObject LFB . . . . . . . . . . . . . . . . . . . . 44 6. LFB Classes Description . . . . . . . . . . . . . . . . . . . 39
5.1.2. FEProtocol LFB . . . . . . . . . . . . . . . . . . . 45 6.1. Core LFBs . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2. Port LFBs . . . . . . . . . . . . . . . . . . . . . . . . 45 6.1.1. FE Protocol LFB . . . . . . . . . . . . . . . . . . . 39
5.2.1. GenericConnectivityLFB . . . . . . . . . . . . . . . 45 6.1.2. FE Object LFB . . . . . . . . . . . . . . . . . . . . 39
5.2.2. EtherPort . . . . . . . . . . . . . . . . . . . . . . 45 6.2. Port LFBs . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2.3. EtherDecap . . . . . . . . . . . . . . . . . . . . . 46 6.2.1. Generic Connectivity LFB . . . . . . . . . . . . . . . 40
5.2.4. EtherEncap . . . . . . . . . . . . . . . . . . . . . 46 6.2.2. Ethernet Port LFBs . . . . . . . . . . . . . . . . . . 41
5.3. Address LFBs . . . . . . . . . . . . . . . . . . . . . . 46 6.2.3. POS Port LFBs . . . . . . . . . . . . . . . . . . . . 41
5.3.1. IPv6AddrResolution . . . . . . . . . . . . . . . . . 46 6.2.4. ATM Port LFBs . . . . . . . . . . . . . . . . . . . . 41
5.3.2. Arp . . . . . . . . . . . . . . . . . . . . . . . . . 46 6.3. Address Resolution LFBs . . . . . . . . . . . . . . . . . 41
5.3.3. ICMPGenerator . . . . . . . . . . . . . . . . . . . . 46 6.4. ICMP LFBs . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3.4. ICMPv6Generator . . . . . . . . . . . . . . . . . . . 46 6.5. IP Packet Validation LFBs . . . . . . . . . . . . . . . . 42
5.3.5. IPv4Validator . . . . . . . . . . . . . . . . . . . . 47 6.6. Classifier LFBs . . . . . . . . . . . . . . . . . . . . . 42
5.3.6. IPv6Validator . . . . . . . . . . . . . . . . . . . . 47 6.7. Forwarding LFBs . . . . . . . . . . . . . . . . . . . . . 43
5.4. Forwarding LFBs . . . . . . . . . . . . . . . . . . . . . 47 6.7.1. Unicast Longest Prefix Match LFBs . . . . . . . . . . 43
5.4.1. IPv4UcastLPM . . . . . . . . . . . . . . . . . . . . 47 6.7.2. Nexthop Applicator LFBs . . . . . . . . . . . . . . . 43
5.4.2. IPv4NextHopApplicator . . . . . . . . . . . . . . . . 47 6.8. QoS Control LFBs . . . . . . . . . . . . . . . . . . . . . 43
5.4.3. IPv6UcastLPM . . . . . . . . . . . . . . . . . . . . 47 6.8.1. Scheduler LFBs . . . . . . . . . . . . . . . . . . . . 44
5.4.4. IPv6UcastNexthopApplicator . . . . . . . . . . . . . 47 6.8.2. Queue LFBs . . . . . . . . . . . . . . . . . . . . . . 45
5.5. Queue and scheduler LFBs . . . . . . . . . . . . . . . . 48 6.9. Miscellaneous Packet Manipulation LFBs . . . . . . . . . . 45
5.5.1. Scheduler . . . . . . . . . . . . . . . . . . . . . . 48 6.10. Redirect LFB . . . . . . . . . . . . . . . . . . . . . . . 45
5.5.2. Queue . . . . . . . . . . . . . . . . . . . . . . . . 49 7. XML Definition for Base LFB Library . . . . . . . . . . . . . 46
5.5.3. WRRSched . . . . . . . . . . . . . . . . . . . . . . 49 8. Base LFB Library Use Case for Typical Router Functions . . . . 75
5.6. Miscellanious LFBs . . . . . . . . . . . . . . . . . . . 49 8.1. IP Forwardings . . . . . . . . . . . . . . . . . . . . . . 75
5.6.1. ExtendHeaderProc . . . . . . . . . . . . . . . . . . 49 8.2. Address Resolution . . . . . . . . . . . . . . . . . . . . 76
5.6.2. MetadataClassifier . . . . . . . . . . . . . . . . . 49 8.3. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.6.3. OptionProc . . . . . . . . . . . . . . . . . . . . . 49 8.4. Running Routing Protocol . . . . . . . . . . . . . . . . . 76
5.6.4. RedirectLFB . . . . . . . . . . . . . . . . . . . . . 50 8.5. Network Management . . . . . . . . . . . . . . . . . . . . 76
5.6.5. PacketTrimmer . . . . . . . . . . . . . . . . . . . . 50 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.6.6. Duplicator . . . . . . . . . . . . . . . . . . . . . 50 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 78
5.6.7. ArbitraryClassifierLFB . . . . . . . . . . . . . . . 50 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79
6. LFB Library Definition . . . . . . . . . . . . . . . . . . . 51 12. Security Considerations . . . . . . . . . . . . . . . . . . . 80
7. LFB Use Case . . . . . . . . . . . . . . . . . . . . . . . . 112 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 81
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 113 13.1. Normative References . . . . . . . . . . . . . . . . . . . 81
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 114 13.2. Informative References . . . . . . . . . . . . . . . . . . 81
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 82
11. Security Considerations . . . . . . . . . . . . . . . . . . . 116
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 117
12.1. Normative References . . . . . . . . . . . . . . . . . . 117
12.2. Informative References . . . . . . . . . . . . . . . . . 117
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 118
1. Terminology and Conventions 1. Terminology and Conventions
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Definitions 2. Definitions
skipping to change at page 8, line 7 skipping to change at page 7, line 7
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.
This document defines the specifications for this ForCES protocol. This document defines the specifications for this ForCES protocol.
3. Introduction 3. Introduction
XXX: Editorial Note: This is an initial rough copy of the document
which will undergo heavy review and modification. It was published
to beat the meeting deadline.
Forwarding and Control Element Separation (ForCES) defines an Forwarding and Control Element Separation (ForCES) defines an
architectural framework and associated protocols to standardize architectural framework and associated protocols to standardize
information exchange between the control plane and the forwarding information exchange between the control plane and the forwarding
plane in a ForCES Network Element (ForCES NE). [RFC3654]has defined plane in a ForCES Network Element (ForCES NE). [RFC3654]has defined
the ForCES requirements, and [RFC3746] has defined the ForCES the ForCES requirements, and [RFC3746] has defined the ForCES
framework. framework.
The ForCES protocol Protocol FE-protocol [I-D.ietf-forces-protocol] The ForCES protocol Protocol FE-protocol FE-protocol
defines a protocol by which Control Elements (CEs) communicated with [I-D.ietf-forces-protocol] defines a protocol for communications
and control the behavior of Forwarding Elements (FEs). That control between Control Elements (CEs) Forwarding Elements (FEs) and for
is expressed in terms of manipulations of components of Logical Control Elements to manipulate resources in Forwarding Elements.
Function Blocks (LFBs). The structure and abstract semantics of LFBs Resources in Forwarding Elements are described by classes of Logical
is defined in Model FE-MODEL [I-D.ietf-forces-model]. That document Function Blocks (LFBs). The FE model documentFE-MODEL
also defines a single LFB Class for gaining access to FE properties [I-D.ietf-forces-model]. specifies the structure and abstract
including the set of LFBs and their interconnection. The Protocol semantics of LFBs, and provides XML schema for the definitions of
document defines an LFB class for manipulating the protocol LFBs.
properties of the FE.
In order for the protocol to be useful to control any behavior, there This document comforts to the specifications of the FE modelFE-MODEL
must be a set of LFB class definitions for the LFBs which provide [I-D.ietf-forces-model] and specifies definitions of classes of LFBs
that behavior. This document provides a set of such definitions. which can be combined to provide functions of a typical router. It
This document is intended to provide an initial LFB library. It is basically provides functions to implement IP forwarding. More
expected that other definitions will be developed over time, and definitions of LFB classes with more functions may be developed in
documented in other RFCs. future time and documented by IETF, and users may also develop
individual LFB classes for purposes of their specific functions
according to the FE modelFE-MODEL [I-D.ietf-forces-model].
An LFB performs a well-defined action or computation on the packets 4. Overview
passing through it. Upon completion of its prescribed function,
either the packets are modified in certain ways (e.g., decapsulator,
marker), or some results are generated and stored, often in the form
of metadata (e.g., classifier). Each LFB typically performs a single
action. Classifiers, shapers and meters are all examples of such
LFBs.
In general, multiple LFBs are contained in one FE. An LFB, may have The LFB classes described in this document are designed to provide
inputs, outputs and components that can be queried and manipulated by the functions of a typical router [RFC1812] . They are expected to
the CE via the ForCES Protocol. An LFB can have one or more inputs. provide functions for a typical router to:
Each input takes a pair of a packet and its associated metadata. The
LFB processes the input, and produces one or more outputs, each of
which is a pair of a packet and its associated metadata.
For further information regarding the LFB model, the reader is o Interface to packet networks and implement the functions required
referenced to FE-MODEL [I-D.ietf-forces-model]. by that network. These functions typically include:
XXX: The above text is redundant. The definition gives some intro to * Encapsulating and decapsulating the IP datagrams with the
LFBs and the model and all the other docs before this tell us what an connected network framing (e.g., an Ethernet header and
LFB is checksum),
In this document we first define base structures used in building the * Sending and receiving IP datagrams up to the maximum size
LFBs in section 4 then use those base definitions to define various supported by that network, this size is the network's Maximum
LFBs. Transmission Unit or MTU,
To simplify the understanding of these LFBs - we have chosen to group * Translating the IP destination address into an appropriate
them by functionality. The following groups of LFBs will be network-level address for the connected network (e.g., an
described in section 5: Ethernet hardware address), if needed, and.
1. Core LFBs. * Responding to network flow control and error indications, if
any.
2. Port LFBs. o Conform to specific Internet protocols including the Internet
Protocol (IPv4 and/or IPv6), Internet Control Message Protocol
(ICMP), and others as necessary.
3. Address LFBs. o Receive and forwards Internet datagrams. Important issues in this
process are buffer management, congestion control, and fairness.
4. Forwarding LFBs. * Recognizes error conditions and generates ICMP error and
information messages as required.
5. Queue manager and scheduler LFBs. * Drops datagrams whose time-to-live fields have reached zero.
6. Miscellanious LFBs. * Fragments datagrams when necessary to fit into the MTU of the
next network.
4. Base Definitions o Choose a next-hop destination for each IP datagram, based on the
information in its routing database.
This section povides a base set of LFB frame, data type, and meta o Usually support an interior gateway protocol (IGP) to carry out
data definitions for use by all any LFB Class definitions (in this or distributed routing and reachability algorithms with the other
other documents. This section provides no actual LFB Class routers in the same autonomous system. In addition, some routers
definitions. will need to support an exterior gateway protocol (EGP) to
exchange topological information with other autonomous systems.
These are then used in each subsequent definition by the statement: o Provide network management and system support facilities,
including loading, debugging, status reporting, exception
reporting and control.
<load library="Base"/> According to ForCES architecture, all above typical router functions
should be implemented upon the concept of Logical Functional Blocks
(LFBs). It is critical to classify above functional requirements
into various classes of LFBs and construct a typical but also
flexible enough base LFB library for various IP forwarding
equipments. In the process, some principles may be applied:
4.1. Framedefs o if a function can be designed by either one LFB or two or more
LFBs with the same cost, it will be designed by two or more LFBs
so as to provide more flexibility for implementers.
The following Frames are defined: o when flexibility is not required, an LFB should take advantage of
its as much as possible independence and leave least couples with
other LFBs. The couples may be from LFB attributes definitions as
well as physical implementations.
1. EthernetII - An Ethernet II frame type. o unless there is a difference in actual functionality, it should
not represent the same thing in two different fashions. Or else,
it may add extra burden on implementation.
2. Ethernet802.3 - An Ethernet 802.3 frame type. The document intends to meet the above typical router function
requirements by defining groups of LFB classes like Core LFBs,Port
LFBs,etc.
3. Ethernet802.2 - An Ethernet 802.2 frame type. For every group of LFB classes, a set of LFBs are defined for
individual function purposes. Section 6(LFB Descriptions Section)
describes individual LFBs in every group of LFBs in details.
4. Ethernet802.2SNAP - An Ethernet 802.2 with SNAP frame. Based on the classes of LFBs, the typical organization of the
processing path and their interconnections can be established by the
CE using the ForCES protocol, so as to achieve typical router
functions. Taking a typical forwarding function as an example, Port
LFBs receive packets and decapsulate the IP datagrams to form IP
level packets. Different port media have different manipulating
requirements from CE, therefore various port LFBs for various media
may have to be defined. IP packets from port LFBs are then validated
before being further forwarded. A kind of valildation LFBs like IPv4
validator and/or IPv6 valildator are applied for the purpose. After
validation, some packets for control purpose will be specifically
processed, like ARP packets will be processed by an Address
resolution LFB and ICMP packets by an ICMP LFB. To separate the
control packets, a metadata classifier LFB is applied in the process.
After validation process, Forwarding LFBs can then be applied. In
the Forwarding LFBs, a Longest Prefix Match LFB is used to look up
the destination information in a packet, and select the next hop
index to be used for sending the packet onward. A next hop
applicator LFB uses the next hop index metadata to apply the proper
headers to the IP packets, and direct them to the proper egress.
5. IPv4Frame - An IPv4 packet. Section 8 provides more detailed descriptions on how various typical
router functions are implemented based on the defined base LFB
classes.
6. IPv6Frame - An IPv6 packet. To define various LFB classes, a set of base type definitions with
the data types, packet frame types, and metadata types have to be
specified in advance. Section 5 (Base Types Section) provide a
description on the base types used by this LFB library. In order to
provide an extensive use of these base types for other LFB
definitions, the base type definitions are provided by a specific xml
file as a base type library which is separate from the LFB definition
library.
7. TaggedFrame - A frame of any type with associated metadata. LFB classes are finally defined by XML with specifications and schema
from the ForCES FE modelFE-MODEL [I-D.ietf-forces-model]. Section 6
(LFB Definitions Section) provide the complete XML definitions of the
base LFB classes library.
8. MetadataFrame - Frame only contains meta data. 5. Base Types
9. Arbitrary - Any kind of frame except Metadata Frame. The FE modelFE-MODEL [I-D.ietf-forces-model] has specified the
following data types as predefined (built-in) atomic data-types:
<frameDefs> char, uchar, int16, uint16, int32, uint32, int64, uint64, string[N],
<frameDef> string, byte[N], boolean, octetstring[N], float16, float32, float64.
<name>EthernetII</name>
<synopsis>An Ethernet II frame type</synopsis>
</frameDef>
<frameDef>
<name>Ethernet802.3</name>
<synopsis>An Ethernet 802.3 frame type</synopsis>
</frameDef>
<frameDef>
<name>Ethernet802.2</name>
<synopsis>An Ethernet 802.2 frame type</synopsis>
</frameDef>
<frameDef>
<name>Ethernet802.2SNAP</name>
<synopsis>An Ethernet 802.2 with SNAP frame</synopsis>
</frameDef>
<frameDef>
<name>IPv4Frame</name>
<synopsis>An IPv4 packet</synopsis>
</frameDef>
<frameDef>
<name>IPv6Frame</name>
<synopsis>An IPv6 packet</synopsis>
</frameDef>
<frameDef>
<name>taggedFrame</name>
<synopsis>A frame of any type with associated metadata.</synopsis>
</frameDef>
<frameDef>
<name>MetadataFrame</name>
<synopsis>Frame only contains meta data</synopsis>
</frameDef>
<frameDef>
<name>Arbitrary</name>
<synopsis>Any kind of frame except Metadata Frame.</synopsis>
</frameDef>
</frameDefs>
4.2. DataTypeDefs Based on these atomic data types and with the use of type definition
elements in the FE model XML schema, new data types, packet frame
types, and metadata types can further be defined.
The following Data Types are defined: To define a base LFB library for typical router functions, a base
data types, frame types, and metadata types MUST be defined. This
section provides a description of these types and a detailed XML
definitions of the base types.
In order for extensive use of the base type definitions for other LFB
definitions than this base LFB library, the base type definitions are
provided with a separate xml library file labeled with
"BaseTypeLibrary". Users can refer to this library by the statement:
<load library="BaseTypeLibrary", location="..."/>
5.1. Data Types
The following data types are currently defined and put in the base
type library:
1. ifIndex - A Port Identifier. 1. ifIndex - A Port Identifier.
2. IEEEMAC - IEEE MAC Address. 2. IEEEMAC - IEEE MAC Address.
3. NetSpeedType - Network speed values. 3. NetSpeedType - Network speed values.
4. IEEENegotiationType - IEEENegotiation types. 4. IEEENegotiationType - IEEENegotiation types.
5. PortStatsType - Port statistics. 5. PortStatsType - Port statistics.
skipping to change at page 13, line 13 skipping to change at page 12, line 47
behaviors. behaviors.
23. WeightTableEntryType - Weight table for queues. 23. WeightTableEntryType - Weight table for queues.
24. NbrState - IPv6 neighbour entry resolution state. 24. NbrState - IPv6 neighbour entry resolution state.
25. ArpTableEntryType - Arp Entry. 25. ArpTableEntryType - Arp Entry.
26. NbrTableEntryType - IPv6 neighbour table entry. 26. NbrTableEntryType - IPv6 neighbour table entry.
27. DCHostTableEntryTypev4 - Direct connected arp table entry for 27. DCHostTableEntryTypev4 - Direct connected ARP table entry for
IPv4. IPv4.
28. DCHostTableEntryTypev6 - Direct connected arp table entry for 28. DCHostTableEntryTypev6 - Direct connected ARP table entry for
IPv6. IPv6.
29. IPPacketType - The packet type code. 29. IPPacketType - The packet type code.
30. IPDispatchTableType - The dispatch table type. 30. IPDispatchTableType - The dispatch table type.
31. MetaType - Metadata type definition. 31. MetaType - Metadata type definition.
32. MetadataClassTableType - The meta data classifying table. 32. MetadataClassTableType - The meta data classifying table.
skipping to change at page 14, line 5 skipping to change at page 13, line 40
to be applied. to be applied.
41. MatchMetaDataAction - An action to set a metadata item to either 41. MatchMetaDataAction - An action to set a metadata item to either
a specific value or a field from the incoming meta data or a specific value or a field from the incoming meta data or
packet. packet.
42. NextHopIndex - An index used by the next hop table Typically 42. NextHopIndex - An index used by the next hop table Typically
stored in and generated as metadata by the longest-prefix-match stored in and generated as metadata by the longest-prefix-match
LFB. LFB.
<dataTypeDefs> 5.2. Frame Types
<dataTypeDef>
<name>ifIndex</name>
<synopsis>A Port Identifier</synopsis>
<typeRef>uint32</typeRef>
</dataTypeDef>
<dataTypeDef>
<name>IEEEMAC</name>
<synopsis>IEEE MAC Address</synopsis>
<typeRef>byte[6]</typeRef>
</dataTypeDef>
<dataTypeDef>
<name>NetSpeedType</name>
<synopsis>Network speed values</synopsis>
<atomic>
<baseType>uint32</baseType>
<specialValues>
<specialValue value="0x00000001">
<name>LAN_SPEED_10M</name>
<synopsis>10M Ethernet</synopsis>
</specialValue>
<specialValue value="0x00000002">
<name>LAN_SPEED_100M</name>
<synopsis>100M Ethernet</synopsis>
</specialValue>
<specialValue value="0x00000003">
<name>LAN_SPEED_1G</name>
<synopsis>1000M Ethernet</synopsis>
</specialValue>
<specialValue value="0x00000004">
<name>LAN_SPEED_10G</name>
<synopsis>10G Ethernet</synopsis>
</specialValue>
<specialValue value="0x00000005">
<name>LAN_SPEED_AUTO</name>
<synopsis>LAN speed auto</synopsis>
</specialValue>
</specialValues>
<!--XXX:This doesnt look like the SNMP
definitions. We should look at the SNMP
definitions for guidance; we should not have
limitations that SNMP has such as being
restricted to 32 bits"
"refer to RFC 3635 ifSpeed and ifHighSpeed"
-->
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>IEEENegotiationType</name>
<synopsis>IEEENegotiation types</synopsis>
<atomic>
<baseType>uint32</baseType>
<specialValues>
<specialValue value="0x00000001">
<name>Auto</name>
<synopsis>Auto negotitation.</synopsis>
</specialValue>
<specialValue value="0x00000002">
<name>Half-duplex</name>
<synopsis>port negotitation half duplex</synopsis>
</specialValue>
<specialValue value="0x00000003">
<name>Full-duplex</name>
<synopsis>port negotitation full duplex</synopsis>
</specialValue>
</specialValues>
</atomic>
<!--XXX:This is very IEEE specific-->
</dataTypeDef>
<dataTypeDef>
<name>PortStatsType</name>
<synopsis>Port statistics</synopsis>
<struct>
<component componentID="1">
<name>InUcastPkts</name>
<synopsis>Number of unicast packets received</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name>InMulticastPkts</name>
<synopsis>Number of multicast packets received</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="3">
<name>InBroadcastPkts</name>
<synopsis>Number of broadcast packets received</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="4">
<name>InOctets</name>
<synopsis>number of octets received</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="5">
<name>OutUcastPkts</name>
<synopsis>Number of unicast packets transmitted</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="6">
<name>OutMulticastPkts</name>
<synopsis>Number of multicast packets transmitted</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="7">
<name>OutBroadcastPkts</name>
<synopsis>Number of broadcast packets transmitted</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="8">
<name>OutOcetes</name>
<synopsis>Number of octets transmitted</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="9">
<name>InErrorPkts</name>
<synopsis>Number of input error packets</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="10">
<name>OutErrorPkts</name>
<synopsis>Number of output error packets</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
<!--XXX:Make sure we validate with SNMP Port Stats-->
</dataTypeDef>
<dataTypeDef>
<name>PortStatusValues</name>
<synopsis>
The possible values of status. Used for both
administrative and operation status</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>Disabled</name>
<synopsis>the port is operatively disabled.</synopsis>
</specialValue>
<specialValue value="1">
<name>UP</name>
<synopsis>the port is up.</synopsis>
</specialValue>
<specialValue value="2">
<name>Down</name>
<synopsis>The port is down.</synopsis>
</specialValue>
</specialValues>
<!--XXX:Need to conform with Administrative and operational status-->
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>LocalIpAddrType</name>
<synopsis>Local IP address belonging to FE.</synopsis>
<struct>
<component componentID="1">
<name>FEID</name>
<synopsis>The FE on which the port ip resides</synopsis>
<typeRef>uint32</typeRef>
<!--XXX:FEID is know to the Object LFB. Do we need it here?-->
</component>
<component componentID="2">
<name>IfIndex</name>
<synopsis>port index on the specified FE</synopsis>
<typeRef>uint32</typeRef>
<!--XXX:We need to support the model that says that a local IP has
multiple ports. Should this be an array of uint32-->
</component>
<component componentID="3">
<name>IPaddr</name>
<synopsis>IP address of the port</synopsis>
<typeRef>IPAddr</typeRef>
</component>
<component componentID="4">
<name>netmask</name>
<synopsis>netmask of this ip address</synopsis>
<typeRef>IPAddr</typeRef>
</component>
<component componentID="5">
<name>BcastAddr</name>
<synopsis>The associated Broadcast address of the
ip address</synopsis>
<typeRef>IPAddr</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>LocalIpv6AddrType</name>
<synopsis>The device local IPv6 address infomation</synopsis>
<struct>
<component componentID="1">
<name>FEID</name>
<synopsis>The FE on which the port ip resides</synopsis>
<typeRef>uint32</typeRef>
<!--XXX:FEID is know to the Object LFB. Do we need it here?-->
</component>
<component componentID="2">
<name>IfIndex</name>
<synopsis>port index on the specified FE</synopsis>
<typeRef>uint32</typeRef>
<!--XXX:We need to support the model that says that a local IP has
multiple ports. Should this be an array of uint32-->
</component>
<component componentID="3">
<name>IPv6addr</name>
<synopsis>IP address of the port</synopsis>
<typeRef>IPv6Addr</typeRef>
</component>
<component componentID="4">
<name>prefixlen</name>
<synopsis>prefix length of this ip address</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv4Addr</name>
<synopsis>IPv4 address</synopsis>
<typeRef>byte[4]</typeRef>
</dataTypeDef>
<dataTypeDef>
<name>IPv6Addr</name>
<synopsis>IPv6 address</synopsis>
<typeRef>byte[16]</typeRef>
</dataTypeDef>
<dataTypeDef>
<name>IPv4Prefix</name>
<synopsis>IPv4 prefix defined by an address and a prefix length
</synopsis>
<struct>
<component componentID="1">
<name>address</name>
<synopsis>Address part</synopsis>
<typeRef>IPv4addr</typeRef>
</component>
<component componentID="2">
<name>prefixlen</name>
<synopsis>Prefix length part</synopsis>
<atomic>
<baseType>uchar</baseType>
<rangeRestriction>
<allowedRange min="0" max="32"/>
</rangeRestriction>
</atomic>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv4NextHopInfoType</name>
<!--XXX:Needs more discussion-->
<synopsis>IPv4 nexthop information,include nexthop ip address,
output FE and interface etc.</synopsis>
<struct>
<component componentID="1">
<name>NexthopID</name>
<synopsis>nexthop id</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>FEID</name>
<synopsis>output FE id</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>Egress</name>
<synopsis>output port index</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="4">
<name>MTU</name>
<synopsis>The maximum transmition unit of the nexthop link.
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="5">
<name>Flags</name>
<synopsis>Associated flags of the nexthop,such as local
delivery,multicast etc.</synopsis>
<typeRef>NextHopFlagsType</typeRef>
</component>
<component componentID="6">
<name>NexthopIPaddr</name>
<synopsis>IP address of the nexthop</synopsis>
<typeRef>IPv4Addr</typeRef>
</component>
<component componentID="7">
<name>L2Index</name>
<synopsis>index into the L2 link layer table,such as IPv4 ARP
table or IPv6 NBR table.</synopsis>
<typeRef>uint32</typeRef> According to FE modelFE-MODEL [I-D.ietf-forces-model], frame types
</component> are used in LFB definitions to define the types of frames the LFB
<component componentID="8"> expects at its input port(s) and emits at its output port(s). The
<name>EncapNeeded</name> <frameDef> element in the FE model is used to define a new frame
<synopsis>The type of encapsulation needed on the packet. type.
</synopsis>
<typeRef>LinkEncapType</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv4FibEntryType</name>
<!--XXX:Needs more discussion-->
<synopsis>IPv4 forwarding table entry.</synopsis>
<struct>
<component componentID="1">
<name>prefix</name>
<synopsis>IPv4 prefix.</synopsis>
<typeRef>IPv4Prefix</typeRef>
</component>
<component componentID="2">
<name>FEID</name>
<synopsis>output FE id</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>Egress</name>
<synopsis>output port index</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="4">
<name>MTU</name>
<synopsis>The maximum transmition unit of the nexthop link.
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="5">
<name>Flags</name>
<synopsis>Associated flags of the nexthop,such as local
delivery,multicast etc.</synopsis>
<typeRef>NextHopFlagsType</typeRef>
</component>
<component componentID="6">
<name>NexthopIPaddr</name>
<synopsis>IP address of the nexthop</synopsis>
<typeRef>IPv4Addr</typeRef>
</component>
<component componentID="7">
<name>L2Index</name>
<synopsis>index into the L2 link layer table,such as IPv4 ARP
table or IPv6 NBR table.</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="8">
<name>EncapNeeded</name>
<synopsis>Type of encapsulation needed on the packet</synopsis>
<typeRef>LinkEncapType</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv4PrefixTableEntry</name>
<!--XXX:Needs more discussion-->
<synopsis>IPv4 prefix table entry</synopsis>
<struct>
<component componentID="1">
<name>Prefix</name>
<synopsis>IPv4 address prefix</synopsis>
<typeRef>IPv4Prefix</typeRef>
</component>
<component componentID="2">
<name>NexthopID</name>
<synopsis>Index into the nexthop table.</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv4UcastLPMStatisticsType</name>
<!--XXX:Needs more discussion-->
<synopsis>statistics of IPv4UcastLPM LFB</synopsis>
<struct>
<component componentID="1">
<name>InRcvdPkts</name>
<synopsis>The total number of input packets received from
interfaces, including those received in error</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name>FwdPkts</name>
<synopsis>IPv4 packet forwarded by this LFB</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="3">
<name>NoRoutePkts</name>
<synopsis>The number of IP datagrams discarded because no route
could be found to transmit them to their destination.</synopsis> The following frame types are currently defined and put in the base
<typeRef>uint64</typeRef> type library as base frame types for the LFB library:
</component>
<component componentID="4">
<name>InDeliverPkts</name>
<synopsis>The total number of input datagrams successfully
delivered to IP user-protocols (including ICMP).</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv4ValidatorStatisticsType</name>
<!--XXX:Needs more discussion-->
<synopsis>IPv4 validator LFB statistics type</synopsis>
<struct>
<component componentID="1">
<name>badHeaderPkts</name>
<synopsis>The total number of input datagrams with bad ip
header</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name>badTotalLengthPkts</name>
<synopsis>The total number of input datagrams with bad length
</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="3">
<name>badTTLPkts</name>
<synopsis>The total number of input datagrams with bad TTL
</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="4">
<name>badChecksum</name>
<synopsis>The total number of input datagrams with bad checksum
</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv6Prefix</name>
<synopsis>IPv6 prefix</synopsis>
<struct>
<component componentID="1">
<name>IPv6addr</name>
<synopsis>address part of the prefix</synopsis>
<typeRef>IPv6Addr</typeRef>
</component>
<component componentID="2">
<name>prefixlen</name>
<synopsis>length of the prefix</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv6NextHopInfoType</name>
<!--XXX:Needs more discussion-->
<synopsis>IPv6 nexthop information,including nexthop ip address,
output FE and interface etc.</synopsis>
<struct>
<component componentID="1">
<name>NexthopID</name>
<synopsis>nexthop id</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>FEID</name>
<synopsis>output FE id</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>Egress</name>
<synopsis>output port index</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="4">
<name>MTU</name>
<synopsis>The maximum transmition unit of the nexthop link.
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="5">
<name>Flags</name>
<synopsis>Associated flags of the nexthop,such as local
delivery,multicast etc.</synopsis>
<typeRef>NextHopFlagsType</typeRef>
</component>
<component componentID="6">
<name>NexthopIPv6addr</name>
<synopsis>IP address of the nexthop</synopsis>
<typeRef>IPv6Addr</typeRef>
</component>
<component componentID="7">
<name>L2Index</name>
<synopsis>index into the L2 table</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="8">
<name>EncapNeeded</name>
<synopsis>Type of encapsulation needed on the packet</synopsis>
<typeRef>LinkEncapType</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv6PrefixTableEntry</name>
<!--XXX:Needs more discussion-->
<synopsis>IPv6 prefix table entry</synopsis>
<struct>
<component componentID="1">
<name>Prefix</name>
<synopsis>IPv6 address prefix</synopsis>
<typeRef>IPv6Prefix</typeRef>
</component>
<component componentID="2">
<name>NexthopID</name>
<synopsis>index to the nexthop table.</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv6LPMClassiferStatisticsType</name>
<!--XXX:Needs more discussion-->
<synopsis>statistics of IPv6LPMClassifier LFB</synopsis>
<struct>
<component componentID="1">
<name>InRcvdPkts</name>
<synopsis>The total number of input packets received from
interfaces, including those received in error</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name>FwdPkts</name>
<synopsis>IPv4 packet forwarded by this LFB</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="3">
<name>NoRoutePkts</name>
<synopsis>The number of IP datagrams discarded because no route
could be found to transmit them to their destination.</synopsis> 1. EthernetII - An Ethernet II frame type.
<typeRef>uint64</typeRef>
</component>
<component componentID="4">
<name>InDeliverPkts</name>
<synopsis>The total number of input datagrams successfully
delivered to IP user-protocols (including ICMP).</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv6ValidatorStatisticsType</name>
<!--XXX:Needs more discussion-->
<synopsis>IPv6 validator LFB statistics type</synopsis>
<struct>
<component componentID="1">
<name>badHeaderPkts</name>
<synopsis>The total number of input datagrams with bad ip
header</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name>badTotalLengthPkts</name>
<synopsis>The total number of input datagrams with bad length
</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="3">
<name>badTTLPkts</name>
<synopsis>The total number of input datagrams with bad TTL
</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="4">
<name>badChecksum</name>
<synopsis>The total number of input datagrams with bad checksum
</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>NextHopFlagsType</name>
<!--XXX:Needs more discussion-->
<synopsis>Flags to define different nexthop behaviors</synopsis>
<atomic>
<baseType>uint32</baseType>
<specialValues>
<specialValue value="0x00000001">
<name>local</name>
<synopsis>Packets match the nexthop entry with this flag are
delivered to the higher level protocols.</synopsis>
</specialValue>
<specialValue value="0x00000002">
<name>drop</name>
<synopsis>Packets match the nexthop entry with this flag are
to be dropped.</synopsis>
</specialValue>
<specialValue value="0x00000004">
<name>broadcast</name>
<synopsis>The route associated with this nexthop is a
broadcast.</synopsis>
</specialValue>
<specialValue value="0x00000008">
<name>multicast</name>
<synopsis>The route associated with this nexthop is multicast
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>WeightTableEntryType</name>
<!--XXX:Needs more discussion-->
<synopsis>Weight table for queues.</synopsis>
<struct>
<component componentID="1">
<name>QueueID</name>
<synopsis>queue id</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>weight</name>
<synopsis>weight of the queue.</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>NbrState</name>
<!--XXX:Needs more discussion-->
<synopsis>IPv6 neighbour entry resolution state.</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0x01">
<name>INCOMPLETE</name>
<synopsis>Address resolution is being performed on the entry.
Specifically, a Neighbor Solicitation has been sent to
the solicited-node multicast address of the target,
but the corresponding Neighbor Advertisement has not
yet been received.</synopsis>
</specialValue>
<specialValue value="0x02">
<name>REACHABLE</name>
<synopsis>Positive confirmation was received within the last
ReachableTime milliseconds that the forward path to the
neighbor was functioning properly. While REACHABLE, no
special action takes place as packets are sent.</synopsis>
</specialValue>
<specialValue value="0x03">
<name>STALE</name>
<synopsis>More than ReachableTime milliseconds have elapsed
since the last positive confirmation was received that
the forward path was functioning properly. While
stale, no action takes place until a packet is sent.
The STALE state is entered upon receiving an
unsolicited Neighbor Discovery message that updates
the cached link-layer address. Receipt of such a
message does not confirm reachability, and entering
the STALE state insures reachability is verified
quickly if the entry is actually being used. However,
reachability is not actually verified until the entry
is actually used.</synopsis>
</specialValue>
<specialValue value="0x04">
<name>DELAY</name>
<synopsis>More than ReachableTime milliseconds have elapsed
since the last positive confirmation was received that
the forward path was functioning properly, and a
packet was sent within the last DELAY_FIRST_PROBE_TIME
seconds. If no reachability confirmation is received
within DELAY_FIRST_PROBE_TIME seconds of entering the
DELAY state, send a Neighbor Solicitation and change
the state to PROBE.</synopsis>
</specialValue>
<specialValue value="0x05">
<name>PROBE</name>
<synopsis>A reachability confirmation is actively sought by
retransmitting Neighbor Solicitations every
RetransTimer milliseconds until a reachability
confirmation is received.</synopsis>
</specialValue>
</specialValues> 2. Ethernet802.3 - An Ethernet 802.3 frame type.
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>ArpTableEntryType</name>
<!--XXX:Needs more discussion-->
<synopsis>Arp entry.</synopsis>
<struct>
<component componentID="1">
<name>Index</name>
<synopsis>Index of the arp table.</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>NeighborIP</name>
<synopsis>IP address of the neighbour.</synopsis>
<typeRef>IPv4Addr</typeRef>
</component>
<component componentID="3">
<name>SrcMac</name>
<synopsis>Source MAC.</synopsis>
<typeRef>IEEEMAC</typeRef>
</component>
<component componentID="4">
<name>NeighborMac</name>
<synopsis>Mac of the Neighbor.</synopsis>
<typeRef>IEEEMAC</typeRef>
</component>
<component componentID="5">
<name>State</name>
<synopsis>State of the address resolution progress.</synopsis>
<typeRef>ArpStateType</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>NbrTableEntryType</name>
<!--XXX:Needs more discussion-->
<synopsis>IPv6 neighbour table entry.</synopsis>
<struct>
<component componentID="1">
<name>Index</name>
<synopsis>Index of the arp table.</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>NeighborIPv6</name>
<synopsis>IP address of the neighbour.</synopsis>
<typeRef>IPv6Addr</typeRef>
</component>
<component componentID="3">
<name>SrcMac</name>
<synopsis>Source MAC.</synopsis>
<typeRef>IEEEMAC</typeRef>
</component>
<component componentID="4">
<name>NeighborMac</name>
<synopsis>Mac of the Neighbor.</synopsis>
<typeRef>IEEEMAC</typeRef>
</component>
<component componentID="5">
<name>State</name>
<synopsis>State of the entry's resolution progress.</synopsis>
<typeRef>NbrState</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>DCHostTableEntryTypev4</name>
<!--XXX:Needs more discussion-->
<synopsis>Direct connected arp table entry for IPv4.</synopsis>
<struct>
<component componentID="1">
<name>NeighbourIP</name>
<synopsis>IP address of the neighbour.</synopsis>
<typeRef>IPv4Addr</typeRef>
</component>
<component componentID="2">
<name>SrcMac</name>
<synopsis>Source MAC.</synopsis>
<typeRef>IEEEMAC</typeRef>
</component>
<component componentID="3">
<name>NeighborMac</name>
<synopsis>Mac of the Neighbor.</synopsis>
<typeRef>IEEEMAC</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>DCHostTableEntryTypev6</name>
<!--XXX:Needs more discussion-->
<synopsis>Direct connected arp table entry for IPv6.</synopsis>
<struct>
<component componentID="1">
<name>NeighbourIPv6</name>
<synopsis>IP address of the neighbour.</synopsis>
<typeRef>IPv6Addr</typeRef>
</component>
<component componentID="2">
<name>SrcMac</name>
<synopsis>Source MAC.</synopsis>
<typeRef>IEEEMAC</typeRef>
</component>
<component componentID="3">
<name>NeighborMac</name>
<synopsis>Mac of the Neighbor.</synopsis>
<typeRef>IEEEMAC</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPPacketType</name>
<!--XXX:Needs more discussion-->
<synopsis>The packet type code.</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="1">
<name>IPv4Ucast</name>
<synopsis>IPv4 unicast packet.</synopsis>
</specialValue>
<specialValue value="2">
<name>IPv4Mcast</name>
<synopsis>IPv4 multicast packet.</synopsis>
</specialValue>
<specialValue value="3">
<name>IPv6Ucast</name>
<synopsis>IPv6 unicast packet.</synopsis>
</specialValue>
<specialValue value="4">
<name>IPv6Mcast</name>
<synopsis>IPv6 multicast packet.</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>IPDispatchTableType</name>
<!--XXX:Needs more discussion-->
<synopsis>The dispatch table type.</synopsis>
<struct>
<component componentID="1">
<name>IPPacketType</name>
<synopsis>The type of the packet.IPv4Uncast,IPv6Ucast,
IPv4Mulcast,IPv6Mulcast etc.</synopsis>
<typeRef>IPPacketType</typeRef>
</component>
<component componentID="2">
<name>index</name>
<synopsis>The index of the output group to output the packets
</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>MetaType</name>
<synopsis>Metadata type definition.</synopsis>
<struct>
<component componentID="1">
<name>MetadataID</name>
<synopsis>The ID of the metadata,the value is standardalized in
the corresponding LFB definition RFCs.</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>MetadataName</name>
<synopsis>The name of the metadata.</synopsis>
<typeRef>String</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>MetadataClassTableType</name>
<!--XXX:Needs more discussion-->
<synopsis>The meta data classifying table.</synopsis>
<struct>
<component componentID="1">
<name>value</name>
<synopsis>Value of the meta data.</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>index</name>
<synopsis>The index of the port in the output group to use for
outputing the packets.</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>LinkEncapType</name>
<!--XXX:Needs more discussion-->
<synopsis>Encapsulation type.</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="1">
<name>Link</name>
<synopsis>Link layer encapsulation such as Ethernet and PPP.
</synopsis>
</specialValue>
<specialValue value="2">
<name>InterFE</name>
<synopsis>Inter FE communication encapsulation.</synopsis>
</specialValue>
<specialValue value="3">
<name>Tunnel</name>
<synopsis>Tunnel encapsulation such as IP-in-IP.</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>IPAddress</name>
<!--XXX:Do we need a union of IPAddressess?-->
<synopsis>IP layer address.</synopsis>
<union>
<component componentID="1">
<name>Ipv4</name>
<synopsis>IPv4 address.</synopsis>
<typeRef>IPv4Addr</typeRef>
</component>
<component componentID="2">
<name>Ipv6</name>
<synopsis>IPv6 address.</synopsis>
<typeRef>IPv6Addr</typeRef>
</component>
</union>
</dataTypeDef>
<dataTypeDef>
<name>ArpStateType</name>
<!--XXX:Needs more discussion-->
<synopsis>The arp entry state.</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="1">
<name>Manual</name>
<synopsis>The entry is manually set.</synopsis>
</specialValue>
<specialValue value="2">
<name>InSolicit</name>
<synopsis>The peer's level 2 address is still in requesting.
</synopsis>
</specialValue>
<specialValue value="4">
<name>Valid</name>
<synopsis>The address resolution have been completed
successfully.Now it can be used in the data packets forwarding
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>MatchTargetType</name>
<!--XXX:Needs more discussion-->
<synopsis>
Indicator for the kind of field to be matched by this
entry in a classifier.</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>MatchNone</name>
<synopsis>A matcher against no field</synopsis>
</specialValue>
<specialValue value="1">
<name>MatchMetaData</name>
<synopsis>A matcher against a metadata item</synopsis>
</specialValue>
<specialValue value="2">
<name>MatchPacketField</name>
<synopsis>A matcher that works against an identified packet
field.</synopsis>
</specialValue>
<specialValue value="3">
<name>MatchOffsetLength</name>
<synopsis>
The match target is a specified portion of the packet.
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>MatchTargetIdentifier</name>
<!--XXX:Needs more discussion-->
<synopsis>
Identify the specific target of a match condition.
</synopsis>
<union>
<component componentID="1">
<name>MetaDataID</name>
<synopsis>The ID of a metadata item</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>packetFieldID</name>
<synopsis>
The identifier for a packet Field, such as SA, DA,
Protocol, SPort, DPort, etc. These identifiers allow
references to fields with varialbe amounts before them.
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>OffSetLengthPacketField</name>
<synopsis>
A field in the packet identified by its offset and
length in bits. This does not allow for matching fields
whose position depends upon earlier field sizes.
</synopsis>
<struct>
<component componentID="1">
<name>fieldOffset</name>
<synopsis>The offset in bits from the start of the packet
to the start of the field.</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>fieldLength</name>
<synopsis>The length of the field, in bits</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</component>
</union>
</dataTypeDef>
<dataTypeDef>
<name>MatchBitString</name>
<!--XXX:Needs more discussion-->
<synopsis>A bit string for use in a match condition.</synopsis>
<struct>
<component componentID="1">
<name>MatchBits</name>
<synopsis>The bits to match</synopsis>
<typeRef>octetstring[16]</typeRef>
</component>
<component componentID="2">
<name>MatchLength</name>
<synopsis>The number of bits to match</synopsis>
<typeRef>uchar</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<!--XXX:Needs more discussion-->
<name>MatchCondition</name>
<synopsis>Structure for a single condition to be applied</synopsis>
<struct>
<component componentID="1">
<name>TargetType</name>
<synopsis>The category of target to match</synopsis>
<typeRef>MatchTargetType</typeRef>
</component>
<component componentID="2">
<name>TargetID</name>
<synopsis>The specific target to compare</synopsis>
<typeRef>MatchTargetIdentifier</typeRef>
</component>
<component componentID="3">
<name>MatchType</name>
<synopsis>The kind of match to apply.</synopsis>
<typeRef>MatchConditionType</typeRef>
</component>
<component componentID="4">
<name>MatchParamOne</name>
<synopsis>The first parameter for the match</synopsis>
<optional/>
<typeRef>MatchBitString</typeRef>
</component>
<component componentID="5">
<name>MatchParamTwo</name>
<synopsis>The second parameter for the match</synopsis>
<optional/>
<typeRef>MatchBitString</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>MatchConditiontType</name>
<!--XXX:Needs more discussion--> 3. Ethernet802.2 - An Ethernet 802.2 frame type.
<synopsis>
Indicator for the kind of match condition to be applied.
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>MatchNone</name>
<synopsis>A matcher which always fails</synopsis>
</specialValue>
<specialValue value="1">
<name>MatchExact</name>
<synopsis>
The target and the match value must be the same, with no
padding. Only the first value of the match condition is
used. The first match value must be occur.
</synopsis>
</specialValue>
<specialValue value="2">
<name>MatchLeft</name>
<synopsis>
The target must begin with the first match value.
If there is a second match value, the remainder of the
target must match repeated occurrances of the second
value. Thus, this can be used to allow any terminal
content, or specific ending pad. The first match value
must occur.</synopsis>
</specialValue>
<specialValue value="3">
<name>MatchRight</name>
<synopsis>
The target must end with the first match value.
If there is a second match value, the preceding part
of the target must match repeated occurrances of the
second value. Thus, this can be used to allow any
leading content, or specific leading fill. The first
match value must occur.</synopsis>
</specialValue>
<specialValue value="4">
<name>MatchRange</name>
<synopsis>
The match values will be considered as numbers, and
the target must be greater than or equal to the
first match value, and less than or equal to the
second match value. An omitted match value means
that end of the range is unlimitted.</synopsis>
</specialValue>
<specialValue value="5">
<name>MatchMaskedValue</name>
<synopsis>
The target the the first value are each anded with the
second value. The match succeeds if the results of these
and operations are identical. Both values are required.
</synopsis>
</specialValue>
<specialValue value="6">
<name>MatchSucceed</name>
<synopsis>A Match which always succeeds</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<!--XXX:Needs more discussion-->
<name>MatchMetaDataAction</name>
<synopsis>
An action to set a metadata item to either a specific value
or a field from the incoming meta data or packet.</synopsis>
<struct>
<component componentID="1">
<name>MetaDataToSet</name>
<synopsis>The Meta Data Item to set</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>ExplicitValueToSet</name>
<synopsis>A value to set the metadata to</synopsis>
<optional/>
<typeRef>octetstring[16]</typeRef>
</component>
<component componentID="3">
<name>ValueFromCondition</name>
<synopsis>
This is an index into the corresponding match conditions,
and the meta data will be set to the value that was tested
by that condition.</synopsis>
<optional/>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>NextHopIndex</name>
<synopsis>
An index used by the next hop table.
Typically stored in and generated as metadata by 4. Ethernet802.2SNAP - An Ethernet 802.2 with SNAP frame.
the longest-prefix-match LFB.</synopsis>
<typeRef>int32</typeRef>
</dataTypeDef>
</dataTypeDefs>
4.3. MetaDataDefs 5. IPv4Frame - An IPv4 packet.
The following MetaData Types are defined: 6. IPv6Frame - An IPv6 packet.
7. TaggedFrame - A frame of any type with associated metadata.
8. MetadataFrame - Frame only contains meta data.
9. Arbitrary - Any kind of frame except Metadata Frame.
5.3. MetaData Types
LFB Metadata is used to communicate per-packet state from one LFB to
another. The <metadataDef> element in the FE model is used to define
a new metadata type.
The following metadata types are currently defined and put in the
base type library as base metadata types for the LFB library
definitions:
1. NextHopID - An index into a Next Hop entry in Nexthop table. 1. NextHopID - An index into a Next Hop entry in Nexthop table.
2. ExceptionID - Exception Types. 2. ExceptionID - Exception Types.
3. IngressPort - At which interface the packet arrive. 3. IngressPort - At which interface the packet arrive.
4. EgressPort - The interface out which the packet will emmit. 4. EgressPort - The interface out which the packet will emmit.
5. NextHopIP - Nexthop IPv4 address. 5. NextHopIP - Nexthop IPv4 address.
skipping to change at page 38, line 48 skipping to change at page 15, line 17
12. DstFEID - Destination FE ID. 12. DstFEID - Destination FE ID.
13. NexthopIndex - Next hop index into the link layer address 13. NexthopIndex - Next hop index into the link layer address
resolution table. resolution table.
14. NHEncapMethod - How should the following LFBs do to encapsulate 14. NHEncapMethod - How should the following LFBs do to encapsulate
the packets. the packets.
15. ErrorId - Error Type. 15. ErrorId - Error Type.
<metadataDefs> 5.4. XML Definition for Base Type Library
<metadataDef>
<name>NextHopID</name>
<synopsis>An index into a Next Hop entry in Nexthop table</synopsis>
<metadataID>1</metadataID>
<typeRef>NextHopIndex</typeRef>
</metadataDef>
<metadataDef>
<name>ExceptionID</name>
<!--XXX:Needs more discussion. See that it applies to all LFBs.-->
<synopsis>Exception Types</synopsis>
<metadataID>2</metadataID>
<atomic>
<baseType>uint32</baseType>
<specialValues>
<specialValue value="0x00000001">
<name>Options</name>
<synopsis>Packets with options,for IPv6 Packet with
next-header set to hop-by-hop header(0).</synopsis>
</specialValue>
<specialValue value="0x00000002">
<name>LengthMismatch</name>
<synopsis>The packet length reported by link layer is less
than the total length field.</synopsis>
</specialValue>
<specialValue value="0x00000003">
<name>BadTTL</name>
<synopsis>The packet can't be forwarded as the TTL has
expired.</synopsis>
</specialValue>
<specialValue value="0x00000004">
<name>Multicast</name>
<synopsis>Packet received is a multicast packet.</synopsis>
</specialValue>
<specialValue value="0x00000005">
<name>FragRequired</name>
<synopsis>The MTU for outgoing interface is less than the
packet size.</synopsis>
</specialValue>
<specialValue value="0x00000006">
<name>Redirect</name>
<synopsis>The outgoing port is same as the one on which the
packet is received.</synopsis>
</specialValue>
<specialValue value="0x00000007">
<name>LocalDelivery</name>
<synopsis>The packet is for a local interface.</synopsis>
</specialValue>
<specialValue value="0x00000008">
<name>LimitedBroadcast</name>
<synopsis>The packet received as limited broadcast</synopsis>
</specialValue>
</specialValues>
</atomic>
</metadataDef>
<metadataDef>
<name>IngressPort</name>
<synopsis>At which interface the packet arrive.</synopsis>
<metadataID>3</metadataID>
<typeRef>ifIndex</typeRef>
</metadataDef>
<metadataDef>
<name>EgressPort</name>
<synopsis>The interface out which the packet will emmit.</synopsis>
<metadataID>4</metadataID>
<typeRef>ifIndex</typeRef>
</metadataDef>
<metadataDef>
<name>NextHopIP</name>
<!--XXX:Needs more discussion if this is metadata-->
<synopsis>Nexthop IPv4 address</synopsis>
<metadataID>5</metadataID>
<typeRef>IP4Addr</typeRef>
</metadataDef>
<metadataDef>
<name>NexthopIPv6</name>
<!--XXX:Needs more discussion if this is metadata-->
<synopsis>Nexthop IPv6 address</synopsis>
<metadataID>6</metadataID>
<typeRef>IPv6Addr</typeRef>
</metadataDef>
<metadataDef>
<name>PacketLength</name>
<synopsis>The length of the packet in octets.</synopsis>
<metadataID>7</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
<metadataDef>
<name>IPPacketType</name>
<!--XXX: Needs more discussion. Should match frameDefs.-->
<synopsis>Type of the packet</synopsis>
<metadataID>8</metadataID>
<atomic>
<baseType>uint32</baseType>
<specialValues>
<specialValue value="0x8000">
<name>IPv4</name>
<synopsis>IPv4 packet</synopsis>
</specialValue>
<specialValue value="0x86DD">
<name>IPv6</name>
<synopsis>IPv6 packet</synopsis>
</specialValue>
<specialValue value="3">
<name>TaggedFrame</name>
<synopsis>packet with metadata</synopsis>
</specialValue>
<specialValue value="4">
<name>MetaDataFrame</name>
<synopsis>meta data only</synopsis>
</specialValue>
</specialValues>
</atomic>
</metadataDef>
<metadataDef>
<name>QueueID</name>
<!--XXX:Needs more discussion-->
<synopsis>The queue ID</synopsis>
<metadataID>9</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
<metadataDef>
<name>QueueOperationCmd</name>
<!--XXX:Needs more discussion-->
<synopsis>The type of operation on the queue,there are two types
defined here: enqueue and dequeue.</synopsis>
<metadataID>10</metadataID>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="1">
<name>Enqueue</name>
<synopsis>Enqueue command.</synopsis>
</specialValue>
<specialValue value="2">
<name>Dequeue</name>
<synopsis>Dequeue command.</synopsis>
</specialValue>
</specialValues>
</atomic>
</metadataDef>
<metadataDef>
<name>SrcFEID</name>
<synopsis>Source FE ID.</synopsis>
<metadataID>11</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
<metadataDef>
<name>DstFEID</name>
<synopsis>Destination FE ID.</synopsis>
<metadataID>12</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
<metadataDef>
<name>NexthopIndex</name>
<!--XXX:This should be removed-->
<synopsis>Nexthop index into the link layer address resolution
table.</synopsis>
<metadataID>13</metadataID>
<typeRef>uint</typeRef>
</metadataDef>
<metadataDef>
<name>NHEncapMethod</name>
<!--XXX: Is there any value in this?-->
<synopsis>how should the following LFBs do to encapsulate the
packets,such as link encapsulation which means the packets need to
encapsulate link layer header before sending to media;inter FE
communication encapsulation which means the packets need to first
encapsulate inter FE communication header before transimiting to
other FEs;tunnel encapsulation which means the packet need do extra
tunnel encapsulation before sending out to media.</synopsis>
<metadataID>14</metadataID>
<typeRef>LinkEncapType</typeRef>
</metadataDef>
<metadataDef>
<name>ErrorId</name>
<!--XXX:Needs more discussion-->
<synopsis>Error Type.</synopsis>
<metadataID>15</metadataID>
<atomic>
<baseType>int32</baseType>
<specialValues>
<specialValue value="0x00030001">
<name>WrongIpVersion</name>
<synopsis>the IP version wrong</synopsis>
</specialValue>
<specialValue value="0x00030002">
<name>WrongLength</name>
<synopsis>
the packet length is not as long as
the header indicates</synopsis>
</specialValue>
<specialValue value="0x000300FF">
<name>otherError</name>
<synopsis>The errors we not defined now</synopsis>
</specialValue>
</specialValues>
</atomic>
</metadataDef>
</metadataDefs>
5. LFB Descriptions
As specified in section 3.1.2 the LFBs have been grouped together for <?xml version="1.0" encoding="UTF-8"?>
better understanding. The following groups have been created <LFBLibrary provides="BaseTypeLibrary"
xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:forces:lfbmodel:1.0
SchemaFile.xsd">
<description>
This library provides base types definitions for LFB library.
</description>
<frameDefs>
<frameDef>
<name>EthernetII</name>
<synopsis>an Ethernet II frame type</synopsis>
</frameDef>
<frameDef>
<name>Ethernet802.3</name>
<synopsis>An Ethernet 802.3 frame type</synopsis>
</frameDef>
<frameDef>
<name>Ethernet802.2</name>
<synopsis>An Ethernet 802.2 frame type</synopsis>
</frameDef>
<frameDef>
<name>Ethernet802.2SNAP</name>
<synopsis>An Ethernet 802.2 with SNAP frame</synopsis>
</frameDef>
<frameDef>
<name>IPv4</name>
<synopsis>An IPv4 packet</synopsis>
</frameDef>
<frameDef>
<name>IPv6</name>
<synopsis>An IPv6 packet</synopsis>
1. Core LFBs, including FE Object LFB and FE Protocol LFB. </frameDef>
<frameDef>
<name>MetadataFrame</name>
<synopsis>Frame only contains meta data</synopsis>
</frameDef>
<frameDef>
<name>Arbitrary</name>
<synopsis>Any kind of frame except Metadata Frame.</synopsis>
</frameDef>
</frameDefs>
<dataTypeDefs>
<dataTypeDef>
<name>IEEEMAC</name>
<synopsis>IEEE mac.</synopsis>
<typeRef>byte[6]</typeRef>
</dataTypeDef>
<dataTypeDef>
<name>LANSpeedType</name>
<synopsis>LAN speed values</synopsis>
<atomic>
<baseType>uint32</baseType>
<specialValues>
<specialValue value="0x00000001">
<name>LAN_SPEED_10M</name>
<synopsis>10M Ethernet</synopsis>
</specialValue>
<specialValue value="0x00000002">
<name>LAN_SPEED_100M</name>
<synopsis>100M Ethernet</synopsis>
</specialValue>
<specialValue value="0x00000003">
<name>LAN_SPEED_1G</name>
<synopsis>1000M Ethernet</synopsis>
</specialValue>
<specialValue value="0x00000004">
<name>LAN_SPEED_10G</name>
<synopsis>10G Ethernet</synopsis>
</specialValue>
<specialValue value="0x00000005">
<name>LAN_SPEED_AUTO</name>
<synopsis>LAN speed auto</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>NegotiationType</name>
<synopsis>Negotiation types</synopsis>
<atomic>
<baseType>uint32</baseType>
<specialValues>
<specialValue value="0x00000001">
<name>Auto</name>
<synopsis>Auto negotitation.</synopsis>
</specialValue>
<specialValue value="0x00000002">
<name>Half-duplex</name>
<synopsis>port negotitation half duplex</synopsis>
</specialValue>
<specialValue value="0x00000003">
<name>Full-duplex</name>
<synopsis>port negotitation full duplex</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>PortStatsType</name>
<synopsis>port statistics</synopsis>
<struct>
<component componentID="1">
<name>InUcastPkts</name>
<synopsis>Number of unicast packets received</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name>InMulticastPkts</name>
<synopsis>Number of multicast packets received</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="3">
<name>InBroadcastPkts</name>
<synopsis>Number of broadcast packets received</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="4">
<name>InOctets</name>
<synopsis>number of octets received</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="5">
<name>OutUcastPkts</name>
<synopsis>Number of unicast packets transmitted</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="6">
<name>OutMulticastPkts</name>
<synopsis>Number of multicast packets transmitted
</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="7">
<name>OutBroadcastPkts</name>
<synopsis>Number of broadcast packets transmitted
</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="8">
<name>OutOcetes</name>
<synopsis>Number of octets transmitted</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="9">
<name>InErrorPkts</name>
<synopsis>Number of input error packets</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="10">
<name>OutErrorPkts</name>
<synopsis>Number of output error packets</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>PortStatusValues</name>
<synopsis>
The possible values of status. Used for both
administrative and operation status
</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0">
<name>Disabled </name>
<synopsis>the port is operatively disabled.</synopsis>
</specialValue>
<specialValue value="1">
<name>UP</name>
<synopsis>the port is up.</synopsis>
</specialValue>
<specialValue value="2">
<name>Down</name>
<synopsis>The port is down.</synopsis>
2. Port LFBs. These LFBs are intended to provide media and </specialValue>
encapsulation oriented capabilities associated with an interface. </specialValues>
The interfaces may be between FEs inside NE or to the outside </atomic>
world. Allowing for the complicated features of different </dataTypeDef>
interface technology. <dataTypeDef>
<name>IPAddr</name>
<synopsis>IPv4 address</synopsis>
<typeRef>uint32</typeRef>
</dataTypeDef>
<dataTypeDef>
<name>MacFilterTableEntryType</name>
<synopsis>MAC filter table entry</synopsis>
<typeRef>IEEEMAC</typeRef>
</dataTypeDef>
<dataTypeDef>
<name>LocalIpAddrType</name>
<synopsis>The device local IP address infomation</synopsis>
<struct>
<component componentID="1">
<name>FEID</name>
<synopsis>The FE on which the port ip resides</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>IfIndex</name>
<synopsis>port index on the specified FE</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>IPaddr</name>
<synopsis>IP address of the port</synopsis>
<typeRef>IPAddr</typeRef>
</component>
<component componentID="4">
<name>netmask</name>
<synopsis>netmask of this ip address</synopsis>
<typeRef>IPAddr</typeRef>
</component>
<component componentID="5">
<name>BcastAddr</name>
<synopsis>The associated Broadcast address of the ip
address </synopsis>
<typeRef>IPAddr</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>LocalIpv6AddrType</name>
<synopsis>The device local IPv6 address infomation</synopsis>
<struct>
<component componentID="1">
<name>FEID</name>
<synopsis>The FE on which the port ip resides</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>IfIndex</name>
<synopsis>port index on the specified FE</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>IPv6addr</name>
<synopsis>IP address of the port</synopsis>
<typeRef>IPv6Addr</typeRef>
</component>
<component componentID="4">
<name>prefixlen</name>
<synopsis>prefix length of this ip address</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv4Addr</name>
<synopsis>IPv4 address</synopsis>
<typeRef> uint32</typeRef>
</dataTypeDef>
<dataTypeDef>
<name>IPv6Addr</name>
<synopsis>IPv6 address</synopsis>
<typeRef>byte[16]</typeRef>
</dataTypeDef>
<dataTypeDef>
<name>IPv4Prefix</name>
<synopsis>
prefix defined by an address and a prefix length
</synopsis>
<struct>
<component componentID="1">
<name>address</name>
<synopsis>Address part</synopsis>
<typeRef>IPv4addr</typeRef>
</component>
<component componentID="2">
<name>prefixlen</name>
<synopsis>Prefix length part</synopsis>
<atomic>
<baseType>uchar</baseType>
<rangeRestriction>
<allowedRange min="0" max="32"/>
</rangeRestriction>
</atomic>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name> IPv4NextHopInfoType </name>
<synopsis>IPv4 nexthop information,include nexthop ip address,
output FE and interface etc.</synopsis>
<struct>
<component componentID="1">
<name>NexthopID</name>
<synopsis>nexthop id</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>FEID</name>
<synopsis>output FE id</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>OutputPortID</name>
<synopsis>output port index</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="4">
<name>MTU</name>
<synopsis>The maximum transmition unit of the nexthop
link.</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="5">
<name> Flags </name>
<synopsis>Associated flags of the nexthop,such as local
delivery,multicast etc.</synopsis>
<typeRef>NextHopFlagsType</typeRef>
</component>
<component componentID="6">
<name> NexthopIPaddr </name>
<synopsis>IP address of the nexthop</synopsis>
<typeRef>IPv4Addr</typeRef>
</component>
<component componentID="7">
<name> L2Index </name>
<synopsis>index into the L2 link layer table,such as IPv4
ARP table or IPv6 NBR table.</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="8">
<name> EncapNeeded </name>
<synopsis>The type of encapsulation needed on the packet.
</synopsis>
<typeRef>EncapType</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv4FibEntryType</name>
<synopsis>IPv4 forwarding table entry.</synopsis>
<struct>
<component componentID="1">
<name>prefix</name>
<synopsis>IPv4 prefix.</synopsis>
<typeRef>IPv4Prefix</typeRef>
</component>
<component componentID="2">
<name>FEID</name>
<synopsis>output FE id</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>OutputPortID</name>
<synopsis>output port index</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="4">
<name>MTU</name>
<synopsis>The maximum transmition unit of the nexthop link.
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="5">
<name> Flags </name>
<synopsis>Associated flags of the nexthop,such as local
delivery,multicast etc.</synopsis>
<typeRef>NextHopFlagsType</typeRef>
</component>
<component componentID="6">
<name> NexthopIPaddr </name>
<synopsis>IP address of the nexthop</synopsis>
<typeRef>IPv4Addr</typeRef>
</component>
<component componentID="7">
<name> L2Index </name>
<synopsis>index into the L2 link layer table,such as IPv4
ARP table or IPv6 NBR table.</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="8">
<name> EncapNeeded </name>
<synopsis>The type of encapsulation needed on the packet.
</synopsis>
<typeRef>EncapType</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv4PrefixTableEntry</name>
<synopsis>IPv4 prefix table entry</synopsis>
<struct>
<component componentID="1">
<name> Prefix </name>
<synopsis>IPv4 address prefix</synopsis>
<typeRef> IPv4Prefix </typeRef>
</component>
<component componentID="2">
<name> NexthopID </name>
<synopsis>Index into the nexthop table.</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name> IPv4UcastLPMStatisticsType </name>
<synopsis>statistics of IPv4UcastLPM LFB</synopsis>
<struct>
<component componentID="1">
<name> InRcvdPkts </name>
<synopsis>The total number of input packets received from
interfaces, including those received in error</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name> FwdPkts </name>
<synopsis>IPv4 packet forwarded by this LFB</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="3">
<name> NoRoutePkts </name>
<synopsis>The number of IP datagrams discarded because no
route could be found to transmit them to their
destination.</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="4">
<name>InDeliverPkts</name>
<synopsis>The total number of input datagrams successfully
delivered to IP user-protocols (including ICMP).
</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name> IPv4ValidatorStatisticsType </name>
<synopsis>IPv4 validator LFB statistics type</synopsis>
<struct>
<component componentID="1">
<name> badHeaderPkts </name>
<synopsis>The total number of input datagrams with bad ip
header</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name> badTotalLengthPkts </name>
<synopsis>The total number of input datagrams with bab
length</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="3">
<name> badTTLPkts </name>
<synopsis>The total number of input datagrams with bad TTL
</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="4">
<name> badChecksum</name>
<synopsis>The total number of input datagrams with bad
checksum</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv6Prefix</name>
<synopsis>IPv6 prefix</synopsis>
<struct>
<component componentID="1">
<name>IPv6addr</name>
<synopsis>address part of the prefix</synopsis>
<typeRef>IPv6Addr</typeRef>
</component>
<component componentID="2">
<name>prefixlen</name>
<synopsis>length of the prefix</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name> IPv6NextHopInfoType </name>
<synopsis>IPv4 nexthop information,include nexthop ip address,
output FE and interface etc.</synopsis>
<struct>
<component componentID="1">
<name>NexthopID</name>
<synopsis>nexthop id</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>FEID</name>
<synopsis>output FE id</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>OutputPortID</name>
<synopsis>output port index</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="4">
<name>MTU</name>
<synopsis>The maximum transmition unit of the nexthop link.
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="5">
<name> Flags </name>
<synopsis>Associated flags of the nexthop,such as local
delivery,multicast etc.</synopsis>
<typeRef>NextHopFlagsType</typeRef>
</component>
<component componentID="6">
<name> NexthopIPv6addr </name>
<synopsis>IP address of the nexthop</synopsis>
<typeRef>IPv6Addr</typeRef>
</component>
<component componentID="7">
<name> L2Index </name>
<synopsis>index into the L2 table</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="8">
<name> EncapNeeded </name>
<synopsis>The type of encapsulation needed on the packet.
</synopsis>
<typeRef>EncapType</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv6PrefixTableEntry</name>
<synopsis>IPv6 prefix table entry</synopsis>
<struct>
<component componentID="1">
<name> Prefix </name>
<synopsis>IPv6 address prefix</synopsis>
<typeRef> IPv6Prefix </typeRef>
</component>
<component componentID="2">
<name> NexthopID </name>
<synopsis>index to the nexthop table.</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name> IPv6LPMClassiferStatisticsType </name>
<synopsis>statistics of IPv6LPMClassifier LFB</synopsis>
<struct>
<component componentID="1">
<name> InRcvdPkts </name>
<synopsis>The total number of input packets received
from interfaces,including those received in error
</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name> FwdPkts </name>
<synopsis>IPv4 packet forwarded by this LFB</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="3">
<name> NoRoutePkts </name>
<synopsis>The number of IP datagrams discarded because no
route could be found to transmit them to their destination.
</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="4">
<name>InDeliverPkts</name>
<synopsis>The total number of input datagrams successfully
delivered to IP user-protocols (including ICMP).
</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name> IPv6ValidatorStatisticsType </name>
<synopsis>IPv6 validator LFB statistics type</synopsis>
<struct>
<component componentID="1">
<name> badHeaderPkts </name>
<synopsis>The total number of input datagrams with bad ip
header</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name> badTotalLengthPkts </name>
<synopsis>The total number of input datagrams with bab
length</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="3">
<name> badTTLPkts </name>
<synopsis>The total number of input datagrams with bad
TTL</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="4">
<name> badChecksum</name>
<synopsis>The total number of input datagrams with bad
checksum</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name> NextHopFlagsType </name>
<synopsis>Flags used to define different nexthop behaviors
</synopsis>
<atomic>
<baseType>uint32</baseType>
<specialValues>
<specialValue value="0x00000001">
<name>local</name>
<synopsis>Packets match the nexthop entry with this flag
are delivered
to the higher level protocols.</synopsis>
</specialValue>
<specialValue value="0x00000002">
<name>drop</name>
<synopsis>Packets match the nexthop entry with this flag
are to be
dropped.</synopsis>
</specialValue>
<specialValue value="0x00000004">
<name>broadcast</name>
<synopsis>The route associated with this nexthop is a
broadcast.</synopsis>
</specialValue>
<specialValue value="0x00000008">
<name>multicast</name>
<synopsis>The route associated with this nexthop is
multicast.</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>WeightTableEntryType</name>
<synopsis>Weight table for queues.</synopsis>
<struct>
<component componentID="1">
<name>QueueID</name>
<synopsis>queue id</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>weight</name>
<synopsis>weight of the queue.</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>NbrState</name>
<synopsis>IPv6 neighbour entry resolution state.</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="0x01">
<name>INCOMPLETE </name>
<synopsis>Address resolution is being performed on the
entry.Specifically, a Neighbor Solicitation has been
sent to the solicited-node multicast address of the
target,but the corresponding Neighbor Advertisement
has not yet been received.</synopsis>
</specialValue>
<specialValue value="0x02">
<name>REACHABLE</name>
<synopsis>Positive confirmation was received within the
last ReachableTime milliseconds that the forward path
to the neighbor was functioning properly. While
REACHABLE,no special action takes place as packets are
sent.</synopsis>
</specialValue>
<specialValue value="0x03">
<name>STALE</name>
<synopsis>More than ReachableTime milliseconds have
elapsed since the last positive confirmation was
received that the forward path was functioning properly.
While stale, no action takes place until a packet is
sent.The STALE state is entered upon receiving an
unsolicited Neighbor Discovery message that updates the
cached link-layer address. Receipt of such a message
does not confirm reachability, and entering the STALE
state insures reachability is verified quickly if the
entry is actually being used. However,reachability is
not actually verified until the entry is actually used.
</synopsis>
</specialValue>
<specialValue value="0x04">
<name>DELAY</name>
<synopsis>More than ReachableTime milliseconds have
elapsed since the last positive confirmation was
received that the forward path was functioning
properly,and a packet was sent within the last
DELAY_FIRST_PROBE_TIME seconds. If no reachability
confirmation is received within DELAY_FIRST_PROBE_TIME
seconds of entering the DELAY state, send a Neighbor
Solicitation and change the state to PROBE.</synopsis>
</specialValue>
<specialValue value="0x05">
<name>PROBE</name>
<synopsis>A reachability confirmation is actively sought
by retransmitting Neighbor Solicitations every
RetransTimer milliseconds until a reachability
confirmation is received.</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>ArpTableEntryType</name>
<synopsis>Arp entry.</synopsis>
<struct>
<component componentID="1">
<name>Index</name>
<synopsis>Index of the arp table.</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>NeighborIP</name>
<synopsis>IP address of the neighbour.</synopsis>
<typeRef>IPv4Addr</typeRef>
</component>
<component componentID="3">
<name>SrcMac</name>
<synopsis>Source MAC.</synopsis>
<typeRef>IEEEMAC</typeRef>
</component>
<component componentID="4">
<name>NeighborMac</name>
<synopsis>Mac of the Neighbor.</synopsis>
<typeRef>IEEEMAC</typeRef>
</component>
<component componentID="5">
<name>State</name>
<synopsis>The state of the address resolution progress.
</synopsis>
<typeRef>ArpStateType</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>NbrTableEntryType</name>
<synopsis>IPv6 neighbour table entry.</synopsis>
<struct>
<component componentID="1">
<name>Index</name>
<synopsis>Index of the arp table.</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>NeighborIPv6</name>
<synopsis>IP address of the neighbour.</synopsis>
<typeRef>IPv6Addr</typeRef>
</component>
<component componentID="3">
<name>SrcMac</name>
<synopsis>Source MAC.</synopsis>
<typeRef>IEEEMAC</typeRef>
</component>
<component componentID="4">
<name>NeighborMac</name>
<synopsis>Mac of the Neighbor.</synopsis>
<typeRef>IEEEMAC</typeRef>
</component>
<component componentID="5">
<name>State</name>
<synopsis>The state of the entry's resolution progress.
</synopsis>
<typeRef>NbrState</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>DCHostTableEntryTypev4</name>
<synopsis>Direct connected arp table entry for IPv4.</synopsis>
<struct>
<component componentID="1">
<name>NeighbourIP</name>
<synopsis>IP address of the neighbour.</synopsis>
<typeRef>IPv4Addr</typeRef>
</component>
<component componentID="2">
<name>SrcMac</name>
<synopsis>Source MAC.</synopsis>
<typeRef>IEEEMAC</typeRef>
</component>
<component componentID="3">
<name>NeighborMac</name>
<synopsis>Mac of the Neighbor.</synopsis>
<typeRef>IEEEMAC</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>DCHostTableEntryTypev6</name>
<synopsis>Direct connected arp table entry for IPv4.</synopsis>
<struct>
<component componentID="1">
<name>NeighbourIPv6</name>
<synopsis>IP address of the neighbour.</synopsis>
<typeRef>IPv4Addr</typeRef>
</component>
<component componentID="2">
<name>SrcMac</name>
<synopsis>Source MAC.</synopsis>
<typeRef>IEEEMAC</typeRef>
</component>
<component componentID="3">
<name>NeighborMac</name>
<synopsis>Mac of the Neighbor.</synopsis>
<typeRef>IEEEMAC</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>PacketType</name>
<synopsis>The packet type code.</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="1">
<name>IPv4Ucast</name>
<synopsis>IPv4 unicast packet.</synopsis>
</specialValue>
<specialValue value="2">
<name>IPv4Mcast</name>
<synopsis>IPv4 multicast packet.</synopsis>
</specialValue>
<specialValue value="3">
<name>IPv6Ucast</name>
<synopsis>IPv6 unicast packet.</synopsis>
</specialValue>
<specialValue value="4">
<name>IPv6Mcast</name>
<synopsis>IPv6 multicast packet.</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>DispatchTableType</name>
<synopsis>The dispatch table type.</synopsis>
<struct>
<component componentID="1">
<name>PacketType</name>
<synopsis>The type of the packet.IPv4Uncast,IPv6Ucast,
IPv4Mulcast,IPv6Mulcast etc.</synopsis>
<typeRef>PacketType</typeRef>
</component>
<component componentID="2">
<name>index</name>
<synopsis>The index of the output group to output the
packets.</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>MetaType</name>
<synopsis>Metadata type definition.</synopsis>
<struct>
<component componentID="1">
<name>MetadataID</name>
<synopsis>The ID of the metadata,the value is
standardalized in the corresponding
LFB definition RFCs.</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>MetadataName</name>
<synopsis>The name of the metadata.</synopsis>
<typeRef>String</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>MetadataClassyTableType</name>
<synopsis>The meta data classifying table.</synopsis>
<struct>
<component componentID="1">
<name>value</name>
<synopsis>Value of the meta data.</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>index</name>
<synopsis>The index of the port in the output group to use
for outputing the packets.</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>EncapType</name>
<synopsis>Encapsulation type.</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="1">
<name>Link</name>
<synopsis>Link layer encapsulation such as Ethernet and
PPP.</synopsis>
</specialValue>
<specialValue value="2">
<name>InterFE</name>
<synopsis>Inter FE communication encapsulation.
</synopsis>
</specialValue>
<specialValue value="3">
<name>Tunnel</name>
<synopsis>Tunnel encapsulation such as IP-in-IP.
</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>IPAddress</name>
<synopsis>IP layer address.</synopsis>
<union>
<component componentID="1">
<name>Ipv4</name>
<synopsis>IPv4 address.</synopsis>
<typeRef>IPv4Addr</typeRef>
</component>
<component componentID="2">
<name>Ipv6</name>
<synopsis>IPv6 address.</synopsis>
<typeRef>IPv6Addr</typeRef>
</component>
</union>
</dataTypeDef>
<dataTypeDef>
<name>ArpStateType</name>
<synopsis>The arp entry state.</synopsis>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="1">
<name>Mannul</name>
<synopsis>The entry is mannully set.</synopsis>
</specialValue>
<specialValue value="2">
<name>InSolicit</name>
<synopsis>The peer's level 2 address is still in
requesting.</synopsis>
</specialValue>
<specialValue value="4">
<name>Vaild</name>
<synopsis>The address resolution have been completed
successfully,it now can be used in the data packets
forwarding.</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
</dataTypeDefs>
<metadataDefs>
<metadataDef>
<name>NextHopID</name>
<synopsis>An index into a Next Hop entry in Nexthop table
</synopsis>
<metadataID>1</metadataID>
<typeRef>int32</typeRef>
</metadataDef>
<metadataDef>
<name>ExceptionID</name>
<synopsis>Exception Types</synopsis>
<metadataID>2</metadataID>
<atomic>
<baseType>uint32</baseType>
<specialValues>
<specialValue value="0x00000001">
<name>Options</name>
<synopsis>Packets with options,for IPv6 Packet with
next-header set to hop-by-hop header(0).</synopsis>
</specialValue>
<specialValue value="0x00000002">
<name>LengthMismatch</name>
<synopsis>The packet length reported by link layer is
less than the total length field.</synopsis>
</specialValue>
<specialValue value="0x00000003">
<name> BadTTL </name>
<synopsis>The packet can't be forwarded as the TTL has
expired.</synopsis>
</specialValue>
<specialValue value="0x00000004">
<name> Multicast </name>
<synopsis>The packet received is a multicast packet.
</synopsis>
3. Address LFBs. LFBs to model Addresses like IPv4, IPv6 addresses. </specialValue>
<specialValue value="0x00000005">
<name>FragRequired</name>
<synopsis>The MTU for outgoing interface is less than the
packet size.</synopsis>
</specialValue>
<specialValue value="0x00000006">
<name>Redirect</name>
<synopsis>The outgoing port is same as the one on which
the packet is received.</synopsis>
</specialValue>
<specialValue value="0x00000007">
<name>LocalDelivery</name>
<synopsis>The packet is for a local interface.</synopsis>
</specialValue>
<specialValue value="0x00000008">
<name>LimitedBroadcast</name>
<synopsis>The packet received as limited broadcast.
</synopsis>
</specialValue>
</specialValues>
</atomic>
</metadataDef>
<metadataDef>
<name>InputPortID</name>
<synopsis>At which interface the packet arrive.</synopsis>
<metadataID>3</metadataID>
<typeRef> uint32</typeRef>
</metadataDef>
<metadataDef>
<name>OutputPortID</name>
<synopsis>The interface out which the packet will emmit.
</synopsis>
<metadataID>4</metadataID>
<typeRef> uint32</typeRef>
</metadataDef>
<metadataDef>
<name> NextHopIP </name>
<synopsis>Nexthop IPv4 address.</synopsis>
<metadataID>5</metadataID>
<typeRef> IP4Addr </typeRef>
</metadataDef>
<metadataDef>
<name>NexthopIPv6</name>
<synopsis>Nexthop IPv6 address</synopsis>
<metadataID>6</metadataID>
<typeRef>IPv6Addr</typeRef>
</metadataDef>
<metadataDef>
<name>PacketLength</name>
<synopsis>The length of the packet in octets.</synopsis>
<metadataID>7</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
<metadataDef>
<name> PacketType </name>
<synopsis>Type of the packet</synopsis>
<metadataID>8</metadataID>
<atomic>
<baseType>uint32</baseType>
<specialValues>
<specialValue value="0x8000">
<name> IPv4 </name>
<synopsis>IPv4 packet</synopsis>
</specialValue>
<specialValue value="0x86DD">
<name> IPv6 </name>
<synopsis>IPv6 packet</synopsis>
</specialValue>
<specialValue value="3">
<name> TaggedFrame </name>
<synopsis>packet with metadata</synopsis>
</specialValue>
<specialValue value="4">
<name> MetaDataFrame </name>
<synopsis>meta data only</synopsis>
</specialValue>
</specialValues>
</atomic>
</metadataDef>
<metadataDef>
<name> QueueID </name>
<synopsis>The queue ID</synopsis>
<metadataID>9</metadataID>
<typeRef> uint32</typeRef>
</metadataDef>
<metadataDef>
<name>QueueOperationCmd</name>
<synopsis>The type of operation on the queue,there are two
types defined here: enqueue and dequeue.</synopsis>
<metadataID>10</metadataID>
<atomic>
<baseType>uchar</baseType>
<specialValues>
<specialValue value="1">
<name>Enqueue</name>
<synopsis>Enqueue command.</synopsis>
</specialValue>
<specialValue value="2">
<name>Dequeue</name>
<synopsis>Dequeue command.</synopsis>
</specialValue>
</specialValues>
</atomic>
</metadataDef>
<metadataDef>
<name>SrcFEID</name>
<synopsis>Source blade ID.</synopsis>
<metadataID>11</metadataID>
<typeRef>uchar</typeRef>
</metadataDef>
<metadataDef>
<name>DstFEID</name>
<synopsis>Destination blade ID.</synopsis>
<metadataID>12</metadataID>
<typeRef>uchar</typeRef>
</metadataDef>
<metadataDef>
<name>NexthopIndex</name>
<synopsis>Nexthop index into the link layer address resolution
table.</synopsis>
<metadataID>13</metadataID>
<typeRef>uint</typeRef>
</metadataDef>
<metadataDef>
<name>EncapMethod</name>
<synopsis>how should the following LFBs do to encapsulate the
packets,such as link encapsulation which means the packets need
to encapsulate link layer header before sending to media;inter
FE communication encapsulation which means the packets need to
first encapsulate inter FE communication header before
transimiting to other FEs;tunnel encapsulation which means the
packet need do extra tunnel encapsulation before sending out to
media. </synopsis>
<metadataID>14</metadataID>
<typeRef>EncapType</typeRef>
</metadataDef>
</metadataDefs>
</LFBLibrary>
4. Forwarding LFBs. LFBs to model the IPv4 and IPv6 forwarding 6. LFB Classes Description
function, e.g., IPv4Validor LFB, IPv4UcastLPM LFB,
IPv4NextHopApplicator LFB, ARP LFB, ICMPProc LFB, OptionProc LFB,
IPv6Validator LFB, IPv6UcastLPM LFB, ExtendHeaderProc LFB,
IPv6NexthopApplicator LFB,IPv6AddrResolutionLFB LFB, ICMPv6Proc
LFB.
5. Queue manager and scheduler LFBs. LFB that model queues and According to ForCES specifications, LFB (Logical Function Block) is a
schedulers. A basic queue LFB and scheduler LFB are defined. well defined, logically separable functional block that resides in an
Queues and scheduler can be cascaded together to build more FE, and is a functionally accurate abstraction of the FE's processing
complicated schedulers. capabilities. An LFB Class (or type) is a template that represents a
fine-grained, logically separable aspect of FE processing. Most LFBs
relate to packet processing in the data path. LFB classes are the
basic building blocks of the FE model.
6. Miscellanious LFBs. LFBs that capture the functionality broadly Only for better understanding purposes, LFB classes defined in this
used in FEs but are not part of any category, e.g., RedirectSink document are further categorized into groups of LFBs, including Core
LFB, RedirectSource LFB, MetaClassifier LFB, GeneralClassifier LFBs, Port LFBs, etc.
LFB.
5.1. Core LFBs The following sections describe the LFB classes according to the
groups.
Currently there are only two core LFBs defined. These two LFBs are 6.1. Core LFBs
core LFBs for ForCES. It's required that each FE must implement
these two LFBs for CE to control it.
1. FEObjectLFB The core LFBs provide basic ForCES functionality for FE in a ForCES
system. Two core LFBs are defined: the FE Protocol LFB and the FE
Object LFB.
2. FEProtocolLFB 6.1.1. FE Protocol LFB
5.1.1. FEObject LFB The FE Protocol LFB is defined as a logical entity in each FE that is
used to control the ForCES protocol. It repsesents FE Protocol
attributes like supportable ForCES protocol versions, current running
version, FE restart policy, CE failover policy, etc. The ForCES
protocol specification document FE-MODEL [I-D.ietf-forces-model]
defines the LFB in details and specifes that every FE must have one
FE Protocol LFB.
The FEObject LFB is described in detail in the FE-MODEL The definition of the LFB is included in this base LFB library by
[I-D.ietf-forces-model]. The reader is refered there for further using "load" element:
detail.
5.1.2. FEProtocol LFB <load library="FEPO", location="..."/>
The FEProtocol LFB is described in detail in the FE-protocol 6.1.2. FE Object LFB
[I-D.ietf-forces-protocol]. The reader is refered there for further
detail.
5.2. Port LFBs The FE Object LFB is defined to make the FE information easily
accessible. Information like the FE Name, FE ID, FE State, LFB
Topology in the FE are represented in the class of LFB. The FE model
documentFE-MODEL [I-D.ietf-forces-model] defines the LFB in details
and specifies that every FE must have one FE Object LFB.
The Port LFBs that are defined in this library are: The definition of the LFB is included in this base LFB library by
using "load" element:
1. GenericConnectivityLFB <load library="FEObject", location="..."/>
2. EtherPort 6.2. Port LFBs
3. EtherDecap Classes of Port LFBs are LFBs that are related to the operation of FE
media interfaces linked to outer networks or other FEs in the same
ForCES system. According to different media types, different media
port LFBs may have to be defined. For every type of media port, it
usually needs to implement encapsulating and decapsulating the IP
datagrams with the connected network framing. For the sake of the
flexibility, the function of encapsulating and decapsulating are
usually categorized in LFB classes as separate LFBs.
4. EtherEncap Even if ports with different media may have different logical
abstracts for the attributes, a general description for different
ports still exist. A Generic Connectivity LFB is defined for this
sake. By use of an FE model XML schema <derivedFrom> element,
specific media port LFBs are then defined in a easier way.
5.2.1. GenericConnectivityLFB 6.2.1. Generic Connectivity LFB
This LFB Class provides a generic basis for representing connectivity This LFB Class provides a generic basis for representing connectivity
between the FE and the outside world. The LFB has one or more ports between the FE and the outside world. The LFB has one or more ports
for packets that the FE processing logic is forwrding for for packets that the FE processing logic is forwrding for
transmission by this Connectivity LFB. It has one or more ports for transmission by this Connectivity LFB. It has one or more ports for
packets that the Connectivity LFB has received and is handing to the packets that the Connectivity LFB has received and is handing to the
FE processing logic. Multiple ports for handline packets are FE processing logic. Multiple ports for handline packets are
supported so that protocol specific encapsulation and demultiplexing supported so that protocol specific encapsulation and demultiplexing
can be provided by this LFB. This LFB also has ports for sending can be provided by this LFB. This LFB also has ports for sending
packets to lower layer Connectivity LFBs and receiving packets from packets to lower layer Connectivity LFBs and receiving packets from
skipping to change at page 45, line 48 skipping to change at page 41, line 5
validation, then remove media specific headers, and place the validation, then remove media specific headers, and place the
relevant information in meta-data. For ethernet, the Source MAC relevant information in meta-data. For ethernet, the Source MAC
would be in meta-data. For Frame Relay or ATM, a circuit identifier would be in meta-data. For Frame Relay or ATM, a circuit identifier
would be in meta-data. For Ethernet with VLANs, this meta-data would would be in meta-data. For Ethernet with VLANs, this meta-data would
indicate which VLAN the packet came from. For packets to be indicate which VLAN the packet came from. For packets to be
transmitted, meta-data indicating the destination (destination MAC or transmitted, meta-data indicating the destination (destination MAC or
outgoing circuit, etc.) is required. This LFB will also include outgoing circuit, etc.) is required. This LFB will also include
statistical components such as the number of octets and packets sent statistical components such as the number of octets and packets sent
and received, the number of various input and output errors, etc. and received, the number of various input and output errors, etc.
5.2.2. EtherPort 6.2.2. Ethernet Port LFBs
LFB for Ethernet ports (TBD)
5.2.3. EtherDecap 1. EtherPort LFB
An LFB class for definition of Ethernet decapsulation and Ethernet LFB for Ethernet ports
filtering functions.
5.2.4. EtherEncap 2. EtherDecap LFB
An LFB classifier definition for completes ethernet encapsulation An LFB class for definition of Ethernet decapsulation and
fuctions. Ethernet filtering functions.
5.3. Address LFBs 3. EtherEncap LFB
The Address LFBs that are defined in this library are: An LFB classifier definition for completes ethernet encapsulation
fuctions.
1. IPv6AddrResolution 6.2.3. POS Port LFBs
2. Arp (TBD)
3. ICMPGenerator 6.2.4. ATM Port LFBs
4. ICMPv6Generator (TBD)
5. IPv4Validator 6.3. Address Resolution LFBs
6. IPv6Validator (TBD)
5.3.1. IPv6AddrResolution This LFB class provides the function of address resolution for IPv4/
IPv6 nodes.
This LFB class provides the function of IPv6 address resolution part 1. ARP
of neighbor discovery protocol.It provides an offload of ND protocol
processing to FE.It process the following ND messages:neighbour
solicitation and neighbour advertisement.
5.3.2. Arp This LFB class provides the function of address resolution for
IPv4 node.
This LFB class provides the function of address resolution for IPv4 2. IPv6 Address Resolution
nodes.
5.3.3. ICMPGenerator This LFB class provides the function of IPv6 address resolution
part of neighbor discovery protocol.It provides an offload of ND
protocol processing to FE.It process the following ND messages:
neighbour solicitation and neighbour advertisement.
This LFB class provide some basic ICMP function,it only generate the 6.4. ICMP LFBs
following ICMP messages:ICMP destination unreachable and time
excceeded.
5.3.4. ICMPv6Generator (TBD)
This LFB class provide some basic ICMPv6 function,it only generate 1. ICMP Geneartor
the following ICMP messages for the packets that need some basic icmp
processing:destination not reachable and time excceeded.
5.3.5. IPv4Validator This LFB class provide some basic ICMP function. It only
generate the following ICMP messages: ICMP destination
unreachable and time excceeded.
An LFB Class definition for validates the IPv4 packet. 2. ICMPv6 Generator
This LFB validates the IP version and header length fields, including This LFB class provide some basic ICMPv6 function, it only
verifying that the packet length is at least as long as the header generate the following ICMP messages for the packets that need
indicates. some basic ICMP processing: destination not reachable and time
excceeded.
5.3.6. IPv6Validator 6.5. IP Packet Validation LFBs
An LFB Class definition for validates the IPv6 packet. (TBD)
This LFB validates the IP version and header length fields, including 1. IPv4 Validator
verifying that the packet length is at least as long as the header
indicates.
5.4. Forwarding LFBs An LFB Class definition for validates the IPv4 packet.
The Forwarding LFBs that are defined in this library are: This LFB validates the IP version and header length fields,
including verifying that the packet length is at least as long as
the header indicates.
1. IPv4UcastLPM 2. IPv6 Validator
2. IPv4NextHopApplicator An LFB Class definition for validates the IPv6 packet.
3. IPv6UcastLPM This LFB validates the IP version and header length fields,
including verifying that the packet length is at least as long as
the header indicates.
4. IPv6UcastNexthopApplicator 6.6. Classifier LFBs
5.4.1. IPv4UcastLPM (TBD)
IPv4 Longest Prefix Match Lookup LFB 1. Metadata Classifier LFB
5.4.2. IPv4NextHopApplicator This LFB class provides the function of classify packets
according to the meta data. Now it only works on one meta data.
An LFB definition for applicating next hop action to IPv4 packets,the 2. Arbitrary Classifier LFB
actions include:TTL operation,checksum recalculation. This is a class definition for an Arbitrary Classifier LFB. The
input is a port group, and the match conditions can include the
port in their test. This allows the topology to carry some
information if desired. The match conditions can select an
output from the SuccessOuput output port group. If no condition
matches, the packet will be sesnt to the FailOutput port.
5.4.3. IPv6UcastLPM 6.7. Forwarding LFBs
An LFB class definition for IPv6 longest prefix lookup function. (TBD)
5.4.4. IPv6UcastNexthopApplicator Forwarding LFBs are specifically for implementing IP packet
forwarding tasks.
An LFB for applicating next hop action to IPv6 packets,actions mainly 6.7.1. Unicast Longest Prefix Match LFBs
inlcude TTL incrementation and checksum recalculation.
5.5. Queue and scheduler LFBs 1. IPv4UcastLPM
IPv4 Longest Prefix Match Lookup LFB
2. IPv6UcastLPM
An LFB class definition for IPv6 longest prefix lookup function.
6.7.2. Nexthop Applicator LFBs
1. IPv4 NextHop Applicator
An LFB definition for applicating next hop action to IPv4
packets, the actions include:TTL operation,checksum
recalculation.
2. IPv6UcastNexthopApplicator
An LFB for applicating next hop action to IPv6 packets,actions
mainly inlcude TTL incrementation and checksum recalculation.
6.8. QoS Control LFBs
(TBD)
To build an actual forwarder, one must include some limited for of To build an actual forwarder, one must include some limited for of
queueing and scheduling. Queues are entities which store packets. queueing and scheduling. Queues are entities which store packets.
Schedulers are entities which react to the state of queues and cause Schedulers are entities which react to the state of queues and cause
packets to be emitted from queues. packets to be emitted from queues.
The actual interaction between queues and schedulers (and their real The actual interaction between queues and schedulers (and their real
world degree of separation) is quite complex. A very complex LFB world degree of separation) is quite complex. A very complex LFB
model would be required to represent all the complexity. model would be required to represent all the complexity.
Additionally, there is the issue of representing the relationship Additionally, there is the issue of representing the relationship
skipping to change at page 48, line 48 skipping to change at page 44, line 38
whihc are not under the control of the scheduler. whihc are not under the control of the scheduler.
The Queues and schedulers LFBs that are defined in this library are: The Queues and schedulers LFBs that are defined in this library are:
1. Scheduler 1. Scheduler
2. Queue 2. Queue
3. WRRSched 3. WRRSched
5.5.1. Scheduler 6.8.1. Scheduler LFBs
This defines a base LFB class for schedulers. Schedulers have an
Input Port group called Watchers for representing the queues they
watch, and an Output Port group called Controllers fro representing
the queues they control.
5.5.2. Queue
Queues have a packet input, a packet output, a control input, and a
group of control outputs. The control ports represent the control
relationships with scheduluers.
5.5.3. WRRSched 1. Generic Scheduler
Weighted round robin scheduler. This defines a base LFB class for schedulers. Schedulers have an
Input Port group called Watchers for representing the queues they
watch, and an Output Port group called Controllers fro
representing the queues they control.
5.6. Miscellanious LFBs 2. WRRSched
The Miscellanious LFBs that are defined in this library are: Weighted round robin scheduler.
1. ExtendHeaderProc 6.8.2. Queue LFBs
2. MetadataClassifier Queues have a packet input, a packet output, a control input, and a
group of control outputs. The control ports represent the control
relationships with scheduluers.
3. OptionProc 6.9. Miscellaneous Packet Manipulation LFBs
4. RedirectLFB (TBD)
5. PacketTrimmer 1. Packet Trimmer LFB
6. Duplicator LFB removes data from the front of a packet.
7. ArbitraryClassifierLfb 2. Duplicator LFB
5.6.1. ExtendHeaderProc An LFB Class definition for packet duplicator LFB. Any packet
received on an input port is logically copied and sent to all
output ports.
This LFB class process the IPv6 packet with extended header,For the 3. IPv4 Option Proccessing LFB
moment,the packets to this LFB are redirect to RedirectSink LFB by
default.
5.6.2. MetadataClassifier This LFB class process the IPv4 packet with options, it can
process on the following options: Router-alert option.
This LFB class provides the function of classify packets according to 4. IPv6 Extend Header Processing LFB
the meta data.Now it only works on one meta data.
5.6.3. OptionProc This LFB class process the IPv6 packet with extended header, For
the moment, the packets to this LFB are redirect to RedirectSink
LFB by default.
This LFB class process the IPv4 packet with options,it can process on 6.10. Redirect LFB
the following options:Router-alert option.
5.6.4. RedirectLFB (TBD)
An LFB Class definition for exchanging data packets between the FE An LFB Class definition for exchanging data packets between the FE
and the CE. and the CE.
This LFB represents a point of exchagne of data packets between the This LFB represents a point of exchagne of data packets between the
CE and the FE. Packets with meta-data are exchanged. It is expected CE and the FE. Packets with meta-data are exchanged. It is expected
that the output port of a RedirectLFB, if it is connected at all, that the output port of a RedirectLFB, if it is connected at all,
will be connected to a meta-data redirector. will be connected to a meta-data redirector.
5.6.5. PacketTrimmer 7. XML Definition for Base LFB Library
LFB removes data from the front of a packet.
5.6.6. Duplicator <?xml version="1.0" encoding="UTF-8"?>
<LFBLibrary provides="BaseLFBLibrary"
xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:forces:lfbmodel:1.0
SchemaFile.xsd">
<description>
This library provides base LFB class definitions.
</description>
<load library="BaseTypeLibrary", location="..."/>
<LFBClassDefs>
<LFBClassDef LFBClassID="3">
<name>EtherPort</name>
<synopsis>LFB for Ethernet ports</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>PacketsFromProcessingUnit</name>
<synopsis>
Ports for receiving packets from processing unit
such as NP,that will be sent to media.
</synopsis>
<expectation>
<frameExpected>
<ref>EthernetII</ref>
</frameExpected>
<metadataExpected>
<ref>OutputPort</ref>
</metadataExpected>
</expectation>
</inputPort>
<inputPort>
<name>PacketsFromMedia</name>
<synopsis>
Ports for receiving packets from ethernet media.
</synopsis>
<expectation>
<frameExpected>
<ref>EthernetII</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort>
<name>PacketsToProcessingUnit</name>
<synopsis>Ports for sending packets to processing unit such
as NP for further processing. </synopsis>
<product>
<frameProduced>
<ref>EthernetII</ref>
</frameProduced>
<metadataProduced>
<ref>InputPort</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort>
<name>PacketsToMedia</name>
<synopsis>
Ports for sending packets to media.
</synopsis>
<product>
<frameProduced>
<ref>EthernetII</ref>
</frameProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1">
<name>IfIndex</name>
<synopsis>A unique value for each interface. Its value ranges
between 1 and the value of total number of interfaces in the
system. The value for each interface must remain constant at
least from one re-initialization of the entity's network
management system to the next re-initialization. </synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>IfName</name>
<synopsis>Name of this port</synopsis>
<typeRef>string[16]</typeRef>
</component>
<component componentID="3">
<name>LinkSpeed</name>
<synopsis>Speed of this port</synopsis>
<typeRef>LANSpeedType</typeRef>
</component>
<component componentID="4">
<name>MTU</name>
<synopsis>Maximum transmition unit</synopsis>
<typeRef>uint32</typeRef>
An LFB Class definition for packet duplicator LFB. Any packet </component>
received on an input port is logically copied and sent to all output <component componentID="5" access="read-only">
ports. <name>OperaStatus</name>
<synopsis>Operate state of this port.</synopsis>
<typeRef>PortStatusValues</typeRef>
<defaultValue>"down"</defaultValue>
</component>
<component componentID="6">
<name>AdminStatus</name>
<synopsis>Administrator's state of this port</synopsis>
<typeRef>PortStatusValues</typeRef>
<defaultValue>"down"</defaultValue>
</component>
<component componentID="7">
<name>PromiscuousMode</name>
<synopsis>Whether the interface is in promiscuous mode
</synopsis>
<typeRef>booleanType</typeRef>
<defaultValue>"no"</defaultValue>
</component>
<component componentID="8" access="read-only">
<name>CarrierStatus</name>
<synopsis>whether the port is linked with an connector.
</synopsis>
<typeRef>booleanType</typeRef>
<defaultValue>"no"</defaultValue>
</component>
<component componentID="9">
<name>OperMode</name>
<synopsis>The port operation mode,must be one of the
following values:Auto,Half-duplex,Full-duplex</synopsis>
<typeRef>NegotiationType</typeRef>
<defaultValue>"auto"</defaultValue>
</component>
<component componentID="10">
<name>SrcMACAddr</name>
<synopsis>source MAC</synopsis>
<typeRef>IEEEMAC</typeRef>
</component>
<component componentID="11">
<name>MacAliasTable</name>
<synopsis>A series of MACs that the port can receive frame
on.</synopsis>
<array>
<typeRef>IEEEMAC</typeRef>
</array>
</component>
<component componentID="12">
<name>StatsEnable</name>
<synopsis>whether enable the statistics in this LFB.
</synopsis>
<optional/>
<typeRef>booleanType</typeRef>
<defaultValue>"no"</defaultValue>
</component>
<component componentID="13" access="read-reset">
<name>PortStats</name>
<synopsis>port statistics.</synopsis>
<optional/>
<typeRef>PortStatsType</typeRef>
</component>
<component componentID="14">
<name>Ipaddr</name>
<synopsis>IP layer Address.</synopsis>
<typeRef>IPAddress</typeRef>
</component>
</components>
<events baseID="100">
<event eventID="1">
<name>PortStatusChanged</name>
<synopsis>Port status has changed since last time reporting.
</synopsis>
<eventTarget>
<eventField>OperaStatus</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>OperaStatus</eventField>
</eventReport>
</eventReports>
</event>
</events>
</LFBClassDef>
<LFBClassDef LFBClassID="4">
<name>EtherDecap</name>
<synopsis>An LFB class for definition of Ethernet decapsulation
and Ethernet filtering functions</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>PacketsIn</name>
<synopsis>Packets from other LFB.</synopsis>
<expectation>
<frameExpected>
<ref>EthernetII</ref>
5.6.7. ArbitraryClassifierLFB </frameExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort group="true">
<name>DecapOut</name>
<synopsis>Ethernet decapsulation output.</synopsis>
<product>
<frameProduced>
<ref>Arbitrary</ref>
</frameProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1">
<name>DispatchTable</name>
<synopsis>This table is used for selecting output in the
ouput group for the incoming packet stream.</synopsis>
<typeRef>DispatchTableType</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="5">
<name>IPv4Validor</name>
<synopsis>An LFB Class definition for validates the IPv4 packets.
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>ValidatePktsIn</name>
<synopsis>Port used to receive IPv4 packet for validation.
</synopsis>
<expectation>
<frameExpected>
<ref>IPv4</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort>
<name>SuccessOut</name>
<synopsis>Out port for the packets passing the validation.
</synopsis>
<product>
<frameProduced>
<ref>IPv4</ref>
</frameProduced>
</product>
</outputPort>
<outputPort>
<name>ExceptionOut</name>
<synopsis>Output port for the packets needed to be dealt by
higher level protcol stacks.The following packets are
identified as exception packets:1 Packet with header
length>5;2 Packet with destination address equal to
255.255.255.255;3 Packet with expired TTL (checked after a
forwarding decision is made);4 Packet length error.
</synopsis>
<product>
<frameProduced>
<ref>ExceptionID</ref>
</frameProduced>
</product>
</outputPort>
<outputPort>
<name>FailOutput</name>
<synopsis>Output for packets failed to pass the validation.
</synopsis>
<product>
<frameProduced>
<ref> IPv4 </ref>
</frameProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1">
<name>StatsEnable</name>
<synopsis>whether to gather statistics in this LFB.
</synopsis>
<optional/>
<typeRef>booleanType</typeRef>
<defaultValue>"no"</defaultValue>
</component>
<component componentID="2" access="read-reset">
<name>IPv4ValidatorStats</name>
<synopsis>ipv4 validator LFB statistics</synopsis>
<optional/>
<typeRef>IPv4ValidatorStatisticsType</typeRef>
</component>
</components>
<description>Detailed validation process please refer to RFC1812
and RFC2644.</description>
This is a class definition for an Arbitrary Classifier LFB. The </LFBClassDef>
input is a port group, and the match conditions can include the port <LFBClassDef LFBClassID="6">
in their test. This allows the topology to carry some information if <name>IPv4UcastLPM</name>
desired. The match conditions can select an output from the <synopsis>IPv4 Longest Prefix Match Lookup LFB</synopsis>
SuccessOuput output port group. If no condition matches, the packet <version>1.0</version>
will be sesnt to the FailOutput port. <inputPorts>
<inputPort>
<name>PktIn</name>
<synopsis>The port to receive IPv4 packets from other LFBs
</synopsis>
<expectation>
<frameExpected>
<ref>IPv4</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort>
<name>SuccessOut</name>
<synopsis>Successful output when all is fine.</synopsis>
<product>
<frameProduced>
<ref>IPv4</ref>
</frameProduced>
<metadataProduced>
<ref availability="conditional">NextHopID</ref>
<ref availability="conditional">FEID</ref>
<ref availability="conditional">OutputPortID</ref>
<ref availability="conditional">MTU</ref>
<ref availability="conditional">Flags</ref>
<ref availability="conditional">NexthopIPAddr</ref>
<ref availability="conditional">EncapMethod</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort>
<name>ExceptionOut</name>
<synopsis>Exception output</synopsis>
<product>
<frameProduced>
<ref>IPv4</ref>
</frameProduced>
<metadataProduced>
<ref>InputPortID </ref>
<ref>ExceptionID</ref>
</metadataProduced>
</product>
6. LFB Library Definition </outputPort>
<outputPort>
<name>FailOutput</name>
<synopsis>Dropper</synopsis>
<product>
<frameProduced>
<ref> IPv4 </ref>
</frameProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1">
<name> PrefixTable </name>
<synopsis>IPv4 prefix table</synopsis>
<array type="variable-size">
<typeRef> IPv4PrefixTableEntry </typeRef>
<contentKey contentKeyID="1">
<contentKeyField>IPv4PrefixTableEntry.prefix
</contentKeyField>
</contentKey>
</array>
</component>
<component componentID="2">
<name>Fib</name>
<synopsis>IPv4 unicast forwarding table.</synopsis>
<optional/>
<array type="variable-size">
<typeRef>IPv4FibEntryType</typeRef>
<contentKey contentKeyID="1">
<contentKeyField>IPv4FibEntryType.prefix
</contentKeyField>
</contentKey>
</array>
</component>
<component componentID="3">
<name>LocalIpAddrTable</name>
<synopsis>The table of interfaces's ip address infomation
on the local device</synopsis>
<typeRef>LocalIpAddrType</typeRef>
</component>
<component componentID="4">
<name>IPv4Stats</name>
<synopsis>The IPv4 associated statistics</synopsis>
<optional/>
<typeRef> IPv4UcastLPMStatisticsType </typeRef>
</component>
</components>
<capabilities>
<capability componentID="1">
<name>PrefixTableLimit</name>
<synopsis>maxium number of prefix supported by this LFB
</synopsis>
<typeRef>uint32</typeRef>
</capability>
<capability componentID="2">
<name>LocalIpAddrTableLimit</name>
<synopsis>maxium number of IP address entrys supported by
this LFB</synopsis>
<typeRef>uint32</typeRef>
</capability>
</capabilities>
<description>This LFB represents the IPv4 longest prefix match
lookup operation.
</description>
</LFBClassDef>
<LFBClassDef LFBClassID="7">
<name> IPv4NextHopApplicator </name>
<synopsis>An LFB definition for applicating next hop action to
IPv4 packets,the actions include:TTL operation,checksum
recalculation.</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>PktIn</name>
<synopsis>Port used to receive IPv4 packets from other LFBs
</synopsis>
<expectation>
<frameExpected>
<ref> IPv4 </ref>
</frameExpected>
<metadataExpected>
<ref dependency="optional" defaultValue="0xff">
NextHopID</ref>
<ref dependency="optional" defaultValue="0xff">
FEID</ref>
<ref dependency="optional" defaultValue="0xff">
OutputPortID</ref>
<ref dependency="optional" defaultValue="0xff">
MTU</ref>
<ref dependency="optional" defaultValue="0xff">
Flags</ref>
<ref dependency="optional" defaultValue="0xff">
NexthopIPAddr</ref>
<ref dependency="optional" defaultValue="0xff">
EncapMethod</ref>
<?xml version="1.0" encoding="UTF-8"?> </metadataExpected>
<LFBLibrary provides="Library" xmlns="urn:ietf:params:xml:ns:forces: </expectation>
lfbmodel:1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" </inputPort>
xsi:schemaLocation="urn:ietf:params:xml:ns:forces:lfbmodel:1.0 </inputPorts>
SchemaFile.xsd"> <outputPorts>
<frameDefs> <outputPort>
<frameDef> <name>SuccessOut</name>
<name>EthernetII</name> <synopsis>Output port for packet successfully fulfill the
<synopsis>an Ethernet II frame type</synopsis> nexthop application.</synopsis>
</frameDef> <product>
<frameDef> <frameProduced>
<name>Ethernet802.3</name> <ref> IPv4 </ref>
<synopsis>An Ethernet 802.3 frame type</synopsis> </frameProduced>
</frameDef> <metadataProduced>
<frameDef> <ref>DstFEID</ref>
<name>Ethernet802.2</name> <ref>OutputPortID</ref>
<synopsis>An Ethernet 802.2 frame type</synopsis> <ref availability="conditional">L2Index</ref>
</frameDef> <ref>NextHopIP</ref>
<frameDef> <ref availability="conditional">EncapMethod</ref>
<name>Ethernet802.2SNAP</name> </metadataProduced>
<synopsis>An Ethernet 802.2 with SNAP frame</synopsis> </product>
</frameDef> </outputPort>
<frameDef> <outputPort>
<name>IPv4Frame</name> <name>ExceptionOut</name>
<synopsis>An IPv4 packet</synopsis> <synopsis>Output for packets need deep dealt by higher level
</frameDef> protocol stacks.</synopsis>
<frameDef> <product>
<name>IPv6Frame</name> <frameProduced>
<synopsis>An IPv6 packet</synopsis> <ref> IPv4 </ref>
</frameDef> </frameProduced>
<frameDef> <metadataProduced>
<name>taggedFrame</name> <ref>InputPortID</ref>
<synopsis>A frame of any type with associated metadata</synopsis> <ref>ExceptionID</ref>
</frameDef> </metadataProduced>
<frameDef> </product>
<name>MetadataFrame</name> </outputPort>
<synopsis>Frame only contains meta data</synopsis> <outputPort>
</frameDef> <name>FailOutput</name>
<frameDef> <synopsis>Output for packets failed the nexthop application
<name>Arbitrary</name> operation.</synopsis>
<synopsis>Any kind of frame except Metadata Frame.</synopsis> <product>
</frameDef> <frameProduced>
</frameDefs> <ref> IPv4 </ref>
<dataTypeDefs> </frameProduced>
<dataTypeDef> </product>
<name>ifIndex</name> </outputPort>
<synopsis>A Port Identifier</synopsis> </outputPorts>
<typeRef>uint32</typeRef> <components>
</dataTypeDef> <component componentID="1">
<dataTypeDef> <name> NextHopTable </name>
<name>IEEEMAC</name> <synopsis>Nexthop table</synopsis>
<synopsis>IEEE MAC Address</synopsis> <optional/>
<typeRef>byte[6]</typeRef> <array type="variable-size">
</dataTypeDef> <typeRef> IPv4NextHopInfoType </typeRef>
<dataTypeDef> </array>
<name>NetSpeedType</name> </component>
<synopsis>Network speed values</synopsis> </components>
<atomic> <capabilities>
<baseType>uint32</baseType> <capability componentID="2">
<specialValues> <name>NextHopTableLimit</name>
<specialValue value="0x00000001"> <synopsis>Maxium number of nexthops this LFB supports
<name>LAN_SPEED_10M</name>
<synopsis>10M Ethernet</synopsis>
</specialValue>
<specialValue value="0x00000002">
<name>LAN_SPEED_100M</name>
<synopsis>100M Ethernet</synopsis>
</specialValue>
<specialValue value="0x00000003">
<name>LAN_SPEED_1G</name>
<synopsis>1000M Ethernet</synopsis>
</specialValue>
<specialValue value="0x00000004">
<name>LAN_SPEED_10G</name>
<synopsis>10G Ethernet</synopsis>
</specialValue>
<specialValue value="0x00000005">
<name>LAN_SPEED_AUTO</name>
<synopsis>LAN speed auto</synopsis>
</specialValue>
</specialValues>
<!-- XXX: This doesnt look like the SNMP
definitions. We should look at the SNMP
definitions for guidance; we should not have
limitations that SNMP has such as being
restricted to 32 bits"
"refer to RFC 3635 ifSpeed and ifHighSpeed"
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>IEEENegotiationType</name>
<synopsis>IEEENegotiation types</synopsis>
<atomic>
<baseType>uint32</baseType>
<specialValues>
<specialValue value="0x00000001">
<name>Auto</name>
<synopsis>Auto negotitation.</synopsis>
</specialValue>
<specialValue value="0x00000002">
<name>Half-duplex</name>
<synopsis>port negotitation half duplex</synopsis>
</specialValue>
<specialValue value="0x00000003">
<name>Full-duplex</name>
<synopsis>port negotitation full duplex</synopsis>
</specialValue>
</specialValues>
</atomic>
<!-- XXX: This is very IEEE specific -->
</dataTypeDef>
<dataTypeDef>
<name>PortStatsType</name>
<synopsis>Port statistics</synopsis>
<struct>
<component componentID="1">
<name>InUcastPkts</name>
<synopsis>Number of unicast packets received</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name>InMulticastPkts</name>
<synopsis>Number of multicast packets received</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="3">
<name>InBroadcastPkts</name>
<synopsis>Number of broadcast packets received</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="4">
<name>InOctets</name>
<synopsis>number of octets received</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="5">
<name>OutUcastPkts</name>
<synopsis>Number of unicast packets transmitted</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="6">
<name>OutMulticastPkts</name>
<synopsis>Number of multicast packets transmitted</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="7">
<name>OutBroadcastPkts</name>
<synopsis>Number of broadcast packets transmitted</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="8">
<name>OutOcetes</name>
<synopsis>Number of octets transmitted</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="9">
<name>InErrorPkts</name>
<synopsis>Number of input error packets</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="10">
<name>OutErrorPkts</name>
<synopsis>Number of output error packets</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
<!-- XXX: Make sure we validate with SNMP Port Stats -->
</dataTypeDef>
<dataTypeDef>
<name>PortStatusValues</name>
<synopsis>
The possible values of status. Used for both
administrative and operation status
</synopsis> </synopsis>
<atomic> <typeRef>uint32</typeRef>
<baseType>uchar</baseType> </capability>
<specialValues> </capabilities>
<specialValue value="0"> </LFBClassDef>
<name>Disabled </name> <LFBClassDef LFBClassID="8">
<synopsis>the port is operatively disabled.</synopsis> <name>IPv6Validator</name>
</specialValue> <synopsis>A LFB class definition for validating correctness
<specialValue value="1"> of IPv6 packets</synopsis>
<name>UP</name> <version>1.0</version>
<synopsis>the port is up.</synopsis> <inputPorts>
</specialValue> <inputPort>
<specialValue value="2"> <name>ValidateIn</name>
<name>Down</name> <synopsis>Input port for packets to be validated.</synopsis>
<synopsis>The port is down.</synopsis> <expectation>
<frameExpected>
<ref>IPv6</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort>
<name>SuccessOut</name>
<synopsis>Output port for packets passing the validation.
</synopsis>
<product>
<frameProduced>
<ref>IPv6</ref>
</frameProduced>
</product>
</outputPort>
<outputPort>
<name>ExceptionOut</name>
<synopsis>Output port for exception packet.The following
packets are identified as Exception packet:1 Packet with
next header set to Hop-by-Hop.2 The packet length reported
by link layer is less than the total length field.3 Packet
with a link local destination address;4 The packet received
as limited broadcast.5 Packet with multicast destination
address (the MSB of the destination address is 0xFF);
</synopsis>
<product>
<frameProduced>
<ref>IPv6</ref>
</frameProduced>
<metadataProduced>
<ref>ExceptionID</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort>
<name>FailOut</name>
<synopsis>Output port for packet failing the validation.
</synopsis>
<product>
<frameProduced>
<ref>IPv6</ref>
</frameProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1" access="read-reset">
<name>IPv6ValidatorStats</name>
<synopsis>IPv6 validator LFB statistics</synopsis>
<optional/>
<typeRef>IPv6ValidatorStatisticsType</typeRef>
</component>
</components>
<description>Detailed validation process could refer to RFC2460
and RFC2373.</description>
</LFBClassDef>
<LFBClassDef LFBClassID="9">
<name>IPv6UcastLPM</name>
<synopsis>An LFB class definition for IPv6 longest prefix lookup
function.</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>PktIn</name>
<synopsis>The port to receive IPv6 packets needed to do IPv4
LPM.</synopsis>
</specialValue> <expectation>
</specialValues> <frameExpected>
<!--XXX:Need to conform with Administrative and operational status--> <ref>IPv6</ref>
</atomic> </frameExpected>
</dataTypeDef> </expectation>
<dataTypeDef> </inputPort>
<name>LocalIpAddrType</name> </inputPorts>
<synopsis>Local IP address belonging to FE.</synopsis> <outputPorts>
<struct> <outputPort>
<component componentID="1"> <name>SuccessOut</name>
<name>FEID</name> <synopsis>Output for packets that have find the correct
<synopsis>The FE on which the port ip resides</synopsis> route.</synopsis>
<typeRef>uint32</typeRef> <product>
<!-- XXX: FEID is know to the Object LFB. Do we need it here? --> <frameProduced>
</component> <ref>IPv6</ref>
<component componentID="2"> </frameProduced>
<name>IfIndex</name> <metadataProduced>
<synopsis>port index on the specified FE</synopsis> <ref>NextHopID</ref>
<typeRef>uint32</typeRef> </metadataProduced>
<!-- XXX: We need to support the model that says that a local IP has </product>
multiple ports. Should this be an array of uint32 --> </outputPort>
</component> <outputPort>
<component componentID="3"> <name>FailOutput</name>
<name>IPaddr</name> <synopsis>LPM failed.</synopsis>
<synopsis>IP address of the port</synopsis> <product>
<typeRef>IPAddr</typeRef> <frameProduced>
</component> <ref> IPv6 </ref>
<component componentID="4"> </frameProduced>
<name>netmask</name> </product>
<synopsis>netmask of this ip address</synopsis> </outputPort>
<typeRef>IPAddr</typeRef> </outputPorts>
</component> <components>
<component componentID="5"> <component componentID="1">
<name>BcastAddr</name> <name> PrefixTable </name>
<synopsis>The associated Broadcast address of the ip address <synopsis>IPv6 prefix table</synopsis>
</synopsis> <array type="variable-size">
<typeRef>IPAddr</typeRef> <typeRef> IPv6PrefixTableEntry </typeRef>
</component> <contentKey contentKeyID="1">
</struct> <contentKeyField>IPv6PrefixTableEntry.prefix
</dataTypeDef> </contentKeyField>
<dataTypeDef> </contentKey>
<name>LocalIpv6AddrType</name> </array>
<synopsis>The device local IPv6 address infomation</synopsis> </component>
<struct> <component componentID="2">
<component componentID="1"> <name>LocalIpv6AddrTable</name>
<name>FEID</name> <synopsis>The table of interfaces's ip address infomation on
<synopsis>The FE on which the port ip resides</synopsis> the local device</synopsis>
<typeRef>uint32</typeRef> <typeRef>LocalIpv6AddrType</typeRef>
<!-- XXX: FEID is know to the Object LFB. Do we need it here? --> </component>
</component> <component componentID="3" access="read-reset">
<component componentID="2"> <name>IPv6Stats</name>
<name>IfIndex</name> <synopsis>The IPv6 associated statistics</synopsis>
<synopsis>port index on the specified FE</synopsis> <optional/>
<typeRef>uint32</typeRef> <typeRef> IPv6LPMClassiferStatisticsType </typeRef>
<!-- XXX: We need to support the model that says that a local IP has </component>
multiple ports. Should this be an array of uint32 --> </components>
</component> <capabilities>
<component componentID="3"> <capability componentID="1">
<name>IPv6addr</name> <name>PrefixTableLimit</name>
<synopsis>IP address of the port</synopsis> <synopsis>maxium number of prefix supported by this LFB
<typeRef>IPv6Addr</typeRef> </synopsis>
</component> <typeRef>uint32</typeRef>
<component componentID="4"> </capability>
<name>prefixlen</name> <capability componentID="2">
<synopsis>prefix length of this ip address</synopsis> <name>LocalIpv6AddrTableLimit</name>
<typeRef>uint32</typeRef> <synopsis>maxium number of IPv6 address entrys supported
</component> by this LFB</synopsis>
</struct> <typeRef>uint32</typeRef>
</dataTypeDef> </capability>
<dataTypeDef> </capabilities>
<name>IPv4Addr</name> </LFBClassDef>
<synopsis>IPv4 address</synopsis> <LFBClassDef LFBClassID="10">
<typeRef>byte[4]</typeRef> <name>IPv6UcastNexthopApplicator</name>
</dataTypeDef> <synopsis>An LFB for applicating next hop action to IPv6 packets,
<dataTypeDef> actions mainly inlcude TTL incrementation and checksum
<name>IPv6Addr</name> recalculation.</synopsis>
<synopsis>IPv6 address</synopsis> <version>1.0</version>
<typeRef>byte[16]</typeRef> <inputPorts>
</dataTypeDef> <inputPort>
<dataTypeDef> <name>PktIn</name>
<name>IPv4Prefix</name> <synopsis>Input port for packets to be applicate nexthop.
<synopsis>IPv4 prefix defined by an address and a prefix length </synopsis>
</synopsis> <expectation>
<struct> <frameExpected>
<component componentID="1"> <ref> IPv6 </ref>
<name>address</name> </frameExpected>
<synopsis>Address part</synopsis> <metadataExpected>
<typeRef>IPv4addr</typeRef> <ref>NextHopID</ref>
</component> </metadataExpected>
<component componentID="2"> </expectation>
<name>prefixlen</name> </inputPort>
<synopsis>Prefix length part</synopsis> </inputPorts>
<atomic> <outputPorts>
<baseType>uchar</baseType> <outputPort>
<rangeRestriction> <name>SuccessOut</name>
<allowedRange min="0" max="32"/> <synopsis>Output port for packet successfully fulfill the
nexthop application.</synopsis>
<product>
<frameProduced>
<ref> IPv6 </ref>
</frameProduced>
<metadataProduced>
<ref>FEID</ref>
<ref>OutputPortID</ref>
<ref availability="conditional">L2Index</ref>
<ref>NextHopIPv6</ref>
<ref availability="conditional">EncapMethod</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort>
<name>ExceptionOut</name>
<synopsis>Output port for exception packet.The following
packets are identified as Exception packet:1 Packet with
Hop Limit zero.2 The MTU for outgoing interface is less
than the packet size.3 The outgoing port is same as the
one on which the packet is received.4 The packet is for
a local interface.</synopsis>
<product>
<frameProduced>
<ref> IPv6 </ref>
</frameProduced>
<metadataProduced>
<ref>InputPortID</ref>
<ref>ExceptionID</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort>
<name>FailOutput</name>
<synopsis>Output for packets failed the nexthop application
operation.</synopsis>
<product>
<frameProduced>
<ref> IPv6 </ref>
</frameProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1">
<name> NextHopTable </name>
<synopsis>Nexthop table</synopsis>
<array type="variable-size">
<typeRef> IPv6NextHopInfoType </typeRef>
</array>
</component>
</components>
<capabilities>
<capability componentID="1">
<name>NextHopTableLimit</name>
<synopsis>Maxium number of nexthops this LFB supports
</synopsis>
<typeRef>uint32</typeRef>
</capability>
</capabilities>
</LFBClassDef>
<LFBClassDef LFBClassID="11">
<name>EtherEncap</name>
<synopsis>An LFB classifier definition for completes ethernet
encapsulation fuctions</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>EncapIn</name>
<synopsis>Port for receiving packets needed to build Ethernet
encapsulation.</synopsis>
<expectation>
<frameExpected>
<ref>IPv4</ref>
<ref>IPv6</ref>
</frameExpected>
<metadataExpected>
<ref dependency="optional" defaultValue="0">L2Index</ref>
<one-of>
<ref>NextHopIP</ref>
<ref>NextHopIPv6</ref>
</one-of>
<ref>PacketType</ref>
</metadataExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort>
<name>SuccessOut</name>
<synopsis/>
<product>
<frameProduced>
<ref>EthernetII</ref>
</frameProduced>
</product>
</rangeRestriction> </outputPort>
</atomic> <outputPort group="true">
</component> <name>ExceptionOut</name>
</struct> <synopsis>packet can't find the associated L2 information
</dataTypeDef> </synopsis>
<dataTypeDef> <product>
<name>IPv4NextHopInfoType </name> <frameProduced>
<!-- XXX: Needs more discussion --> <ref>IPv4</ref>
<synopsis>IPv4 nexthop information,include nexthop ip address, <ref>IPv6</ref>
output FE and interface etc.</synopsis> </frameProduced>
<struct> </product>
<component componentID="1"> </outputPort>
<name>NexthopID</name> </outputPorts>
<synopsis>nexthop id</synopsis> <components>
<typeRef>uint32</typeRef> <component componentID="1">
</component> <name>ArpTable</name>
<component componentID="2"> <synopsis>Ethernet arp table.</synopsis>
<name>FEID</name> <array>
<synopsis>output FE id</synopsis> <typeRef>ArpTableEntryType</typeRef>
<typeRef>uint32</typeRef> </array>
</component> </component>
<component componentID="3"> <component componentID="2">
<name>Egress</name> <name>NbrTable</name>
<synopsis>output port index</synopsis> <synopsis>IPv6 neighbour table.</synopsis>
<typeRef>uint32</typeRef> <optional/>
</component> <array>
<component componentID="4"> <typeRef>NbrTableEntryType</typeRef>
<name>MTU</name> </array>
<synopsis>The maximum transmition unit of the nexthop link. </component>
</synopsis> <component componentID="3">
<typeRef>uint32</typeRef> <name>DCHostTablev4</name>
</component> <synopsis>Direct connected host arp table for IPv4.
<component componentID="5"> </synopsis>
<name> Flags </name> <array>
<synopsis>Associated flags of the nexthop,such as local <typeRef>DCHostTableEntryTypev4</typeRef>
delivery,multicast etc.</synopsis> </array>
<typeRef>NextHopFlagsType</typeRef> </component>
</component> <component componentID="4">
<component componentID="6"> <name>DCHostTablev6</name>
<name> NexthopIPaddr </name> <synopsis>Direct connected host arp table for IPv6.
<synopsis>IP address of the nexthop</synopsis> </synopsis>
<typeRef>IPv4Addr</typeRef> <optional/>
</component> <array>
<component componentID="7"> <typeRef>DCHostTableEntryTypev6</typeRef>
<name> L2Index </name> </array>
<synopsis>index into the L2 link layer table,such as IPv4 ARP </component>
table or IPv6 NBR table.</synopsis> </components>
<typeRef>uint32</typeRef> <capabilities>
<capability componentID="1">
<name>ArpTableLimit</name>
<synopsis>Max number of arp entries in arp table.</synopsis>
<typeRef>uint32</typeRef>
</capability>
<capability componentID="2">
<name>NbrTableLimit</name>
<synopsis>Max number of neighbours in neighbour table.
</synopsis>
<optional/>
<typeRef>uint32</typeRef>
</capability>
<capability componentID="3">
<name>DCHostTablev4Limit</name>
<synopsis>The limit on Direct connected host table for IPv4.
</synopsis>
<typeRef>uint32</typeRef>
</capability>
<capability componentID="4">
<name>DCHostTablev6Limit</name>
<synopsis>The limit on Direct connected host table for IPv6.
</synopsis>
<optional/>
<typeRef>uint32</typeRef>
</capability>
</capabilities>
</LFBClassDef>
<LFBClassDef LFBClassID="12">
<name>Scheduler</name>
<synopsis>Base scheduler LFB.</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort group="true">
<name>Watcher</name>
<synopsis>Input for watching the queues to be scheduled.
Queues to be scheduled can transmit packet enqueue and
dequeue infomation to scheduler through these port.
</synopsis>
<expectation>
<frameExpected>
<ref>MetadataFrame</ref>
</frameExpected>
<metadataExpected>
<ref>QueueID</ref>
<ref>PacketLength</ref>
<ref>QueueOperationCmd</ref>
</metadataExpected>
</expectation>
</component> </inputPort>
<component componentID="8"> </inputPorts>
<name> EncapNeeded </name> <outputPorts>
<synopsis>The type of encapsulation needed on the packet. <outputPort group="true">
</synopsis> <name>OutControl</name>
<typeRef>LinkEncapType</typeRef> <synopsis>Control output,this output is used by scheduler
</component> to communicate commands to it's controlled queues such as
</struct> dequeue a packet.</synopsis>
</dataTypeDef> <product>
<dataTypeDef> <frameProduced>
<name>IPv4FibEntryType</name> <ref>MetadataFrame</ref>
<!-- XXX: Needs more discussion --> </frameProduced>
<synopsis>IPv4 forwarding table entry.</synopsis> <metadataProduced>
<struct> <ref>QueueOperationCmd</ref>
<component componentID="1"> </metadataProduced>
<name>prefix</name> </product>
<synopsis>IPv4 prefix.</synopsis> </outputPort>
<typeRef>IPv4Prefix</typeRef> </outputPorts>
</component> <capabilities>
<component componentID="2"> <capability componentID="1">
<name>FEID</name> <name>QueueScheduledLimit</name>
<synopsis>output FE id</synopsis> <synopsis>Max number of queues that can be scheduled by this
<typeRef>uint32</typeRef> scheduler.</synopsis>
</component> <typeRef>uint32</typeRef>
<component componentID="3"> </capability>
<name>Egress</name> </capabilities>
<synopsis>output port index</synopsis> </LFBClassDef>
<typeRef>uint32</typeRef> <LFBClassDef LFBClassID="13">
</component> <name> Queue </name>
<component componentID="4"> <synopsis>Queue LFB.</synopsis>
<name>MTU</name> <version>1.0</version>
<synopsis>The maximum transmition unit of the nexthop link. <inputPorts>
</synopsis> <inputPort>
<typeRef>uint32</typeRef> <name>InControl</name>
</component> <synopsis>Input from scheduler</synopsis>
<component componentID="5"> <expectation>
<name> Flags </name> <metadataExpected>
<synopsis>Associated flags of the nexthop,such as local <ref>QueueOperationCmd</ref>
delivery,multicast etc.</synopsis> </metadataExpected>
<typeRef>NextHopFlagsType</typeRef> </expectation>
</component> </inputPort>
<component componentID="6"> <inputPort>
<name> NexthopIPaddr </name> <name>InData</name>
<synopsis>IP address of the nexthop</synopsis> <synopsis>Input port for data packet.</synopsis>
<typeRef>IPv4Addr</typeRef> <expectation>
</component> <frameExpected>
<component componentID="7"> <ref>Arbitrary</ref>
<name> L2Index </name> </frameExpected>
<synopsis>index into the L2 link layer table,such as IPv4 ARP <metadataExpected>
table or IPv6 NBR table.</synopsis> <ref>PacketLength</ref>
<typeRef>uint32</typeRef> </metadataExpected>
</component> </expectation>
<component componentID="8"> </inputPort>
<name> EncapNeeded </name> </inputPorts>
<synopsis>The type of encapsulation needed on the packet. <outputPorts>
</synopsis> <outputPort>
<typeRef>LinkEncapType</typeRef> <name>OutToController</name>
</component> <synopsis>Output to queue controller</synopsis>
</struct> <product>
</dataTypeDef> <frameProduced>
<dataTypeDef> <ref>MetadataFrame</ref>
<name>IPv4PrefixTableEntry</name> </frameProduced>
<!-- XXX: Needs more discussion --> <metadataProduced>
<synopsis>IPv4 prefix table entry</synopsis> <ref>QueueID</ref>
<struct> <ref>PacketLength</ref>
<component componentID="1"> <ref>QueueOperationCmd</ref>
<name>Prefix</name> </metadataProduced>
<synopsis>IPv4 address prefix</synopsis> </product>
<typeRef> IPv4Prefix </typeRef> </outputPort>
</component> <outputPort>
<component componentID="2"> <name>OutData</name>
<name>NexthopID</name> <synopsis>Data packet output</synopsis>
<synopsis>Index into the nexthop table.</synopsis> <product>
<typeRef>uint32</typeRef> <frameProduced>
</component> <ref>Arbitrary</ref>
</struct> </frameProduced>
</dataTypeDef> </product>
<dataTypeDef> </outputPort>
<name>IPv4UcastLPMStatisticsType </name> </outputPorts>
<!-- XXX: Needs more discussion --> <components>
<synopsis>statistics of IPv4UcastLPM LFB</synopsis> <component componentID="1">
<struct> <name>CurLen</name>
<component componentID="1"> <synopsis>Current length of the queue in number of packets.
<name>InRcvdPkts</name> </synopsis>
<synopsis>The total number of input packets received from <typeRef>uint32</typeRef>
interfaces, including those received in error</synopsis> </component>
<typeRef>uint64</typeRef> </components>
</component> <capabilities>
<component componentID="2"> <capability componentID="1">
<name>FwdPkts</name> <name>QueueLenLimit</name>
<synopsis>IPv4 packet forwarded by this LFB</synopsis> <synopsis>Maximum length of the queue in number of packets.
<typeRef>uint64</typeRef> </synopsis>
</component> <typeRef>uint32</typeRef>
<component componentID="3"> </capability>
<name> NoRoutePkts </name> </capabilities>
<synopsis>The number of IP datagrams discarded because no </LFBClassDef>
route could be found to transmit them to their destination. <LFBClassDef LFBClassID="14">
</synopsis> <name>RedirectSink</name>
<typeRef>uint64</typeRef> <synopsis>This class definition provides for the function of
</component> sinking data packets that needed to be sent to CE. </synopsis>
<component componentID="4"> <version>1.0</version>
<name>InDeliverPkts</name> <inputPorts>
<synopsis>The total number of input datagrams successfully <inputPort group="true">
delivered to IP user-protocols (including ICMP).</synopsis> <name>InFromOtherLFBs</name>
<typeRef>uint64</typeRef> <synopsis>Packets input from other LFBs and needed to sent
</component> to CE.</synopsis>
</struct> <expectation>
</dataTypeDef> <frameExpected>
<dataTypeDef> <ref>IPv4</ref>
<name>IPv4ValidatorStatisticsType</name> <ref>IPv6</ref>
<!-- XXX: Needs more discussion --> </frameExpected>
<synopsis>IPv4 validator LFB statistics type</synopsis> <metadataExpected>
<struct> <ref>InputPortID</ref>
<component componentID="1"> <ref>PacketLength</ref>
<name>badHeaderPkts</name> <ref>PacketType</ref>
<synopsis>The total number of input datagrams with bad ip </metadataExpected>
header</synopsis> </expectation>
<typeRef>uint64</typeRef> </inputPort>
</component> </inputPorts>
<component componentID="2"> </LFBClassDef>
<name>badTotalLengthPkts</name> <LFBClassDef LFBClassID="15">
<synopsis>The total number of input datagrams with bad length <name>RedirectTap</name>
</synopsis> <synopsis>This class provides the function of sinking data
<typeRef>uint64</typeRef> packets that comes from CE and needed to be sent out by this
</component> FE.</synopsis>
<component componentID="3"> <version>1.0</version>
<name>badTTLPkts</name> <outputPorts>
<synopsis>The total number of input datagrams with bad TTL <outputPort group="true">
</synopsis> <name>OutputToOtherLFBs</name>
<typeRef>uint64</typeRef> <synopsis>Packets input received from CE.</synopsis>
</component> <product>
<component componentID="4"> <frameProduced>
<name>badChecksum</name> <ref>IPv4</ref>
<synopsis>The total number of input datagrams with bad <ref>IPv6</ref>
checksum</synopsis> </frameProduced>
<typeRef>uint64</typeRef> <metadataProduced>
</component> <ref>PacketType</ref>
</struct> <ref>OutputPortID</ref>
</dataTypeDef> <ref>PacketLength</ref>
<dataTypeDef> </metadataProduced>
<name>IPv6Prefix</name> </product>
<synopsis>IPv6 prefix</synopsis> </outputPort>
<struct> </outputPorts>
<component componentID="1"> <components>
<name>IPv6addr</name> <component componentID="1">
<synopsis>address part of the prefix</synopsis> <name>DispatchTable</name>
<typeRef>IPv6Addr</typeRef> <synopsis>The table to dispatch the packets to different LFB.
</component> </synopsis>
<component componentID="2"> <typeRef>DispatchTableType</typeRef>
<name>prefixlen</name> </component>
<synopsis>length of the prefix</synopsis> <component componentID="2">
<typeRef>uint32</typeRef> <name>outGroupNumOfPorts</name>
</component> <synopsis>The number of ports in output group.</synopsis>
</struct> <typeRef>uint32</typeRef>
</dataTypeDef> </component>
<dataTypeDef> </components>
<name>IPv6NextHopInfoType</name> <capabilities>
<!-- XXX: Needs more discussion --> <capability componentID="1">
<synopsis>IPv6 nexthop information,include nexthop ip address, <name>MaxNumOfoutGroupPorts</name>
output FE and interface etc.</synopsis> <synopsis>The maxium number of ports in the output group.
<struct> </synopsis>
<component componentID="1"> <typeRef>uint32</typeRef>
<name>NexthopID</name> </capability>
<synopsis>nexthop id</synopsis> </capabilities>
<typeRef>uint32</typeRef> </LFBClassDef>
</component> <LFBClassDef LFBClassID="16">
<component componentID="2"> <name>WRRSched</name>
<name>FEID</name> <synopsis>Weighted round robin scheduler.</synopsis>
<synopsis>output FE id</synopsis> <version>1.0</version>
<typeRef>uint32</typeRef> <derivedFrom>Scheduler</derivedFrom>
</component> <components>
<component componentID="3"> <component componentID="1">
<name>Egress</name> <name>WeightTable</name>
<synopsis>output port index</synopsis> <synopsis>Weight table for queues to be scheduled.</synopsis>
<typeRef>uint32</typeRef> <array type="variable-size">
</component> <typeRef>WeightTableEntryType</typeRef>
<component componentID="4"> </array>
<name>MTU</name> </component>
<synopsis>The maximum transmition unit of the nexthop link. </components>
</synopsis> </LFBClassDef>
<typeRef>uint32</typeRef> <LFBClassDef LFBClassID="17">
</component> <name>IPv6AddrResolution</name>
<component componentID="5"> <synopsis>This LFB class provides the function of IPv6 address
<name> Flags </name> resolution part of neighbor discovery protocol.It provides an
<synopsis>Associated flags of the nexthop,such as local offload of ND protocol processing to FE.It process the following
delivery,multicast etc.</synopsis> ND messages:neighbour solicitation and neighbour advertisement.
<typeRef>NextHopFlagsType</typeRef> </synopsis>
</component> <version>1.0</version>
<component componentID="6"> <inputPorts>
<name> NexthopIPv6addr </name> <inputPort>
<synopsis>IP address of the nexthop</synopsis> <name>AddrResDataPktIn</name>
<typeRef>IPv6Addr</typeRef> <synopsis>The IPv6 data packet that need to do the address
resolution.</synopsis>
<expectation>
<frameExpected>
<ref>IPv6</ref>
</frameExpected>
</expectation>
</inputPort>
<inputPort>
<name>AddrResProtoPktIn</name>
<synopsis>The neighbour discovery packet related to
addresolution.</synopsis>
<expectation>
<frameExpected>
<ref>IPv6</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort>
<name>AddrResDataPktOut</name>
<synopsis>The IPv6 packet that have encapsulated with the
correct ethernet L2 info and need to be sent out to link.
</synopsis>
<product>
<frameProduced>
<ref>EthernetII</ref>
</frameProduced>
</product>
</outputPort>