Internet Engineering Task Force W. Wang
Internet-Draft Zhejiang Gongshang University
Intended status: Informational E. Haleplidis
Expires: September 4, 2010 University of Patras
K. Ogawa
NTT Corporation
F. Jia
National Digital Switching
Center(NDSC)
J. Halpern
Ericsson
March 3, 2010
ForCES LFB Library
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
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
Wang, et al. Expires September 4, 2010 [Page 1]
Internet-Draft ForCES LFB Library March 2010
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 4, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Wang, et al. Expires September 4, 2010 [Page 2]
Internet-Draft ForCES LFB Library March 2010
Table of Contents
1. Terminology and Conventions . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Base Types . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. MetaData Types . . . . . . . . . . . . . . . . . . . . . . 14
5.4. XML Definition for Base Type Library . . . . . . . . . . . 15
6. LFB Classes Description . . . . . . . . . . . . . . . . . . . 39
6.1. Core LFBs . . . . . . . . . . . . . . . . . . . . . . . . 39
6.1.1. FE Protocol LFB . . . . . . . . . . . . . . . . . . . 39
6.1.2. FE Object LFB . . . . . . . . . . . . . . . . . . . . 39
6.2. Port LFBs . . . . . . . . . . . . . . . . . . . . . . . . 40
6.2.1. Generic Connectivity LFB . . . . . . . . . . . . . . . 40
6.2.2. Ethernet Port LFBs . . . . . . . . . . . . . . . . . . 41
6.2.3. POS Port LFBs . . . . . . . . . . . . . . . . . . . . 41
6.2.4. ATM Port LFBs . . . . . . . . . . . . . . . . . . . . 41
6.3. Address Resolution LFBs . . . . . . . . . . . . . . . . . 41
6.4. ICMP LFBs . . . . . . . . . . . . . . . . . . . . . . . . 42
6.5. IP Packet Validation LFBs . . . . . . . . . . . . . . . . 42
6.6. Classifier LFBs . . . . . . . . . . . . . . . . . . . . . 42
6.7. Forwarding LFBs . . . . . . . . . . . . . . . . . . . . . 43
6.7.1. Unicast Longest Prefix Match LFBs . . . . . . . . . . 43
6.7.2. Nexthop Applicator LFBs . . . . . . . . . . . . . . . 43
6.8. QoS Control LFBs . . . . . . . . . . . . . . . . . . . . . 43
6.8.1. Scheduler LFBs . . . . . . . . . . . . . . . . . . . . 44
6.8.2. Queue LFBs . . . . . . . . . . . . . . . . . . . . . . 45
6.9. Miscellaneous Packet Manipulation LFBs . . . . . . . . . . 45
6.10. Redirect LFB . . . . . . . . . . . . . . . . . . . . . . . 45
7. XML Definition for Base LFB Library . . . . . . . . . . . . . 46
8. Base LFB Library Use Case for Typical Router Functions . . . . 75
8.1. IP Forwardings . . . . . . . . . . . . . . . . . . . . . . 75
8.2. Address Resolution . . . . . . . . . . . . . . . . . . . . 76
8.3. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
8.4. Running Routing Protocol . . . . . . . . . . . . . . . . . 76
8.5. Network Management . . . . . . . . . . . . . . . . . . . . 76
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 77
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 78
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79
12. Security Considerations . . . . . . . . . . . . . . . . . . . 80
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 81
13.1. Normative References . . . . . . . . . . . . . . . . . . . 81
13.2. Informative References . . . . . . . . . . . . . . . . . . 81
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 82
Wang, et al. Expires September 4, 2010 [Page 3]
Internet-Draft ForCES LFB Library March 2010
1. Terminology and Conventions
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Wang, et al. Expires September 4, 2010 [Page 4]
Internet-Draft ForCES LFB Library March 2010
2. Definitions
This document follows the terminology defined by the ForCES
Requirements in [RFC3654]and by the ForCES framework in [RFC3746].
The definitions below are repeated below for clarity.
Control Element (CE) - A logical entity that implements the ForCES
protocol and uses it to instruct one or more FEs on how to process
packets. CEs handle functionality such as the execution of
control and signaling protocols.
Forwarding Element (FE) - A logical entity that implements the
ForCES protocol. FEs use the underlying hardware to provide per-
packet processing and handling as directed/controlled by one or
more CEs via the ForCES protocol.
ForCES Network Element (NE) - An entity composed of one or more
CEs and one or more FEs. To entities outside an NE, the NE
represents a single point of management. Similarly, an NE usually
hides its internal organization from external entities.
LFB (Logical Function Block) - The basic building block that is
operated on by the ForCES protocol. The LFB is a well defined,
logically separable functional block that resides in an FE and is
controlled by the CE via ForCES protocol. The LFB may reside at
the FE's datapath and process packets or may be purely an FE
control or configuration entity that is operated on by the CE.
Note that the LFB is a functionally accurate abstraction of the
FE's processing capabilities, but not a hardware-accurate
representation of the FE implementation.
FE Topology - A representation of how the multiple FEs within a
single NE are interconnected. Sometimes this is called inter-FE
topology, to be distinguished from intra-FE topology (i.e., LFB
topology).
LFB Class and LFB Instance - LFBs are categorized by LFB Classes.
An LFB Instance represents an LFB Class (or Type) existence.
There may be multiple instances of the same LFB Class (or Type) in
an FE. An LFB Class is represented by an LFB Class ID, and an LFB
Instance is represented by an LFB Instance ID. As a result, an
LFB Class ID associated with an LFB Instance ID uniquely specifies
an LFB existence.
LFB Metadata - Metadata is used to communicate per-packet state
from one LFB to another, but is not sent across the network. The
FE model defines how such metadata is identified, produced and
consumed by the LFBs. It defines the functionality but not how
Wang, et al. Expires September 4, 2010 [Page 5]
Internet-Draft ForCES LFB Library March 2010
metadata is encoded within an implementation.
LFB Component - Operational parameters of the LFBs that must be
visible to the CEs are conceptualized in the FE model as the LFB
components. The LFB components include, for example, flags,
single parameter arguments, complex arguments, and tables that the
CE can read and/or write via the ForCES protocol (see below).
LFB Topology - Representation of how the LFB instances are
logically interconnected and placed along the datapath within one
FE. Sometimes it is also called intra-FE topology, to be
distinguished from inter-FE topology.
ForCES Protocol - While there may be multiple protocols used
within the overall ForCES architecture, the term "ForCES protocol"
and "protocol" refer to the Fp reference points in the ForCES
Framework in [RFC3746]. This protocol does not apply to CE-to-CE
communication, FE-to-FE communication, or to communication between
FE and CE managers. Basically, the ForCES protocol works in a
master- slave mode in which FEs are slaves and CEs are masters.
This document defines the specifications for this ForCES protocol.
Wang, et al. Expires September 4, 2010 [Page 6]
Internet-Draft ForCES LFB Library March 2010
3. Introduction
Forwarding and Control Element Separation (ForCES) defines an
architectural framework and associated protocols to standardize
information exchange between the control plane and the forwarding
plane in a ForCES Network Element (ForCES NE). [RFC3654]has defined
the ForCES requirements, and [RFC3746] has defined the ForCES
framework.
The ForCES protocol Protocol FE-protocol FE-protocol
[I-D.ietf-forces-protocol] defines a protocol for communications
between Control Elements (CEs) Forwarding Elements (FEs) and for
Control Elements to manipulate resources in Forwarding Elements.
Resources in Forwarding Elements are described by classes of Logical
Function Blocks (LFBs). The FE model documentFE-MODEL
[I-D.ietf-forces-model]. specifies the structure and abstract
semantics of LFBs, and provides XML schema for the definitions of
LFBs.
This document comforts to the specifications of the FE modelFE-MODEL
[I-D.ietf-forces-model] and specifies definitions of classes of LFBs
which can be combined to provide functions of a typical router. It
basically provides functions to implement IP forwarding. More
definitions of LFB classes with more functions may be developed in
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].
Wang, et al. Expires September 4, 2010 [Page 7]
Internet-Draft ForCES LFB Library March 2010
4. Overview
The LFB classes described in this document are designed to provide
the functions of a typical router [RFC1812] . They are expected to
provide functions for a typical router to:
o Interface to packet networks and implement the functions required
by that network. These functions typically include:
* Encapsulating and decapsulating the IP datagrams with the
connected network framing (e.g., an Ethernet header and
checksum),
* Sending and receiving IP datagrams up to the maximum size
supported by that network, this size is the network's Maximum
Transmission Unit or MTU,
* Translating the IP destination address into an appropriate
network-level address for the connected network (e.g., an
Ethernet hardware address), if needed, and.
* Responding to network flow control and error indications, if
any.
o Conform to specific Internet protocols including the Internet
Protocol (IPv4 and/or IPv6), Internet Control Message Protocol
(ICMP), and others as necessary.
o Receive and forwards Internet datagrams. Important issues in this
process are buffer management, congestion control, and fairness.
* Recognizes error conditions and generates ICMP error and
information messages as required.
* Drops datagrams whose time-to-live fields have reached zero.
* Fragments datagrams when necessary to fit into the MTU of the
next network.
o Choose a next-hop destination for each IP datagram, based on the
information in its routing database.
o Usually support an interior gateway protocol (IGP) to carry out
distributed routing and reachability algorithms with the other
routers in the same autonomous system. In addition, some routers
will need to support an exterior gateway protocol (EGP) to
exchange topological information with other autonomous systems.
Wang, et al. Expires September 4, 2010 [Page 8]
Internet-Draft ForCES LFB Library March 2010
o Provide network management and system support facilities,
including loading, debugging, status reporting, exception
reporting and control.
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:
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.
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.
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.
The document intends to meet the above typical router function
requirements by defining groups of LFB classes like Core LFBs,Port
LFBs,etc.
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.
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
Wang, et al. Expires September 4, 2010 [Page 9]
Internet-Draft ForCES LFB Library March 2010
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.
Section 8 provides more detailed descriptions on how various typical
router functions are implemented based on the defined base LFB
classes.
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.
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.
Wang, et al. Expires September 4, 2010 [Page 10]
Internet-Draft ForCES LFB Library March 2010
5. Base Types
The FE modelFE-MODEL [I-D.ietf-forces-model] has specified the
following data types as predefined (built-in) atomic data-types:
char, uchar, int16, uint16, int32, uint32, int64, uint64, string[N],
string, byte[N], boolean, octetstring[N], float16, float32, float64.
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.
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.
2. IEEEMAC - IEEE MAC Address.
3. NetSpeedType - Network speed values.
4. IEEENegotiationType - IEEENegotiation types.
5. PortStatsType - Port statistics.
6. PortStatusValues - The possible values of status Used for both
administrative and operation status.
7. LocalIpAddrType - Local IP address belonging to FE.
8. LocalIpv6AddrType - The device local IPv6 address infomation.
9. IPv4Addr - IPv4 address.
Wang, et al. Expires September 4, 2010 [Page 11]
Internet-Draft ForCES LFB Library March 2010
10. IPv6Addr - IPv6 address.
11. IPv4Prefix - IPv4 prefix defined by an address and a prefix
length.
12. IPv4NextHopInfoType - IPv4 nexthop information,include nexthop
ip address,output FE and interface etc.
13. IPv4FibEntryType - IPv4 forwarding table entry.
14. IPv4PrefixTableEntry - IPv4 prefix table entry.
15. IPv4UcastLPMStatisticsType - Statistics of IPv4UcastLPM LFB.
16. IPv4ValidatorStatisticsType - IPv4 validator LFB statistics
type.
17. IPv6Prefix - IPv6 prefix defined by an address and a prefix
length.
18. IPv6NextHopInfoType - IPv6 next hop information, include next
hop ip address,output FE and interfac eetc.
19. IPv6PrefixTableEntry - IPv6 prefix table entry.
20. IPv6LPMClassiferStatisticsType - Statistics of IPv6 LPM
ClassifierLFB.
21. IPv6ValidatorStatisticsType - IPv6 validator LFB statistics
type.
22. NextHopFlagsType - Flags used to define different next hop
behaviors.
23. WeightTableEntryType - Weight table for queues.
24. NbrState - IPv6 neighbour entry resolution state.
25. ArpTableEntryType - Arp Entry.
26. NbrTableEntryType - IPv6 neighbour table entry.
27. DCHostTableEntryTypev4 - Direct connected ARP table entry for
IPv4.
28. DCHostTableEntryTypev6 - Direct connected ARP table entry for
IPv6.
Wang, et al. Expires September 4, 2010 [Page 12]
Internet-Draft ForCES LFB Library March 2010
29. IPPacketType - The packet type code.
30. IPDispatchTableType - The dispatch table type.
31. MetaType - Metadata type definition.
32. MetadataClassTableType - The meta data classifying table.
33. LinkEncapType - Encapsulation type.
34. IPAddress - IP layer address.
35. ArpStateType - The arp entry state.
36. MatchTargetType - Indicator for the kind of field to be matched
by this entry in a classifier.
37. MatchTargetIdentifier - Identify the specific target of a match
condition.
38. MatchBitString - A bit string for use in a match condition.
39. MatchCondition - Structure for a single condition to be applied.
40. MatchConditiontType - Indicator for the kind of match condition
to be applied.
41. MatchMetaDataAction - An action to set a metadata item to either
a specific value or a field from the incoming meta data or
packet.
42. NextHopIndex - An index used by the next hop table Typically
stored in and generated as metadata by the longest-prefix-match
LFB.
5.2. Frame Types
According to FE modelFE-MODEL [I-D.ietf-forces-model], frame types
are used in LFB definitions to define the types of frames the LFB
expects at its input port(s) and emits at its output port(s). The
<frameDef> element in the FE model is used to define a new frame
type.
The following frame types are currently defined and put in the base
type library as base frame types for the LFB library:
Wang, et al. Expires September 4, 2010 [Page 13]
Internet-Draft ForCES LFB Library March 2010
1. EthernetII - An Ethernet II frame type.
2. Ethernet802.3 - An Ethernet 802.3 frame type.
3. Ethernet802.2 - An Ethernet 802.2 frame type.
4. Ethernet802.2SNAP - An Ethernet 802.2 with SNAP frame.
5. IPv4Frame - An IPv4 packet.
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.
2. ExceptionID - Exception Types.
3. IngressPort - At which interface the packet arrive.
4. EgressPort - The interface out which the packet will emmit.
5. NextHopIP - Nexthop IPv4 address.
6. NexthopIPv6 - Nexthop IPv6 address.
7. PacketLength - The length of the packet in octets.
8. IPPacketType - Type of the packet.
9. QueueID - The queue ID.
10. QueueOperationCmd - The type of operation on the queue,there are
two types defined here: enqueue and dequeue.
Wang, et al. Expires September 4, 2010 [Page 14]
Internet-Draft ForCES LFB Library March 2010
11. SrcFEID - Source FE ID.
12. DstFEID - Destination FE ID.
13. NexthopIndex - Next hop index into the link layer address
resolution table.
14. NHEncapMethod - How should the following LFBs do to encapsulate
the packets.
15. ErrorId - Error Type.
5.4. XML Definition for Base Type Library
<?xml version="1.0" encoding="UTF-8"?>
<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>
Wang, et al. Expires September 4, 2010 [Page 15]
Internet-Draft ForCES LFB Library March 2010
</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>
Wang, et al. Expires September 4, 2010 [Page 16]
Internet-Draft ForCES LFB Library March 2010
<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">
Wang, et al. Expires September 4, 2010 [Page 17]
Internet-Draft ForCES LFB Library March 2010
<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>
Wang, et al. Expires September 4, 2010 [Page 18]
Internet-Draft ForCES LFB Library March 2010
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<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>
Wang, et al. Expires September 4, 2010 [Page 19]
Internet-Draft ForCES LFB Library March 2010
<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>
Wang, et al. Expires September 4, 2010 [Page 20]
Internet-Draft ForCES LFB Library March 2010
<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>
Wang, et al. Expires September 4, 2010 [Page 21]
Internet-Draft ForCES LFB Library March 2010
<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>
Wang, et al. Expires September 4, 2010 [Page 22]
Internet-Draft ForCES LFB Library March 2010
<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
Wang, et al. Expires September 4, 2010 [Page 23]
Internet-Draft ForCES LFB Library March 2010
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">
Wang, et al. Expires September 4, 2010 [Page 24]
Internet-Draft ForCES LFB Library March 2010
<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>
Wang, et al. Expires September 4, 2010 [Page 25]
Internet-Draft ForCES LFB Library March 2010
<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
Wang, et al. Expires September 4, 2010 [Page 26]
Internet-Draft ForCES LFB Library March 2010
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>
Wang, et al. Expires September 4, 2010 [Page 27]
Internet-Draft ForCES LFB Library March 2010
<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>
Wang, et al. Expires September 4, 2010 [Page 28]
Internet-Draft ForCES LFB Library March 2010
<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
Wang, et al. Expires September 4, 2010 [Page 29]
Internet-Draft ForCES LFB Library March 2010
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>
Wang, et al. Expires September 4, 2010 [Page 30]
Internet-Draft ForCES LFB Library March 2010
<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>
Wang, et al. Expires September 4, 2010 [Page 31]
Internet-Draft ForCES LFB Library March 2010
<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>
Wang, et al. Expires September 4, 2010 [Page 32]
Internet-Draft ForCES LFB Library March 2010
<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>
Wang, et al. Expires September 4, 2010 [Page 33]
Internet-Draft ForCES LFB Library March 2010
<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">
Wang, et al. Expires September 4, 2010 [Page 34]
Internet-Draft ForCES LFB Library March 2010
<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>
Wang, et al. Expires September 4, 2010 [Page 35]
Internet-Draft ForCES LFB Library March 2010
</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>
Wang, et al. Expires September 4, 2010 [Page 36]
Internet-Draft ForCES LFB Library March 2010
<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>
Wang, et al. Expires September 4, 2010 [Page 37]
Internet-Draft ForCES LFB Library March 2010
<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>
Wang, et al. Expires September 4, 2010 [Page 38]
Internet-Draft ForCES LFB Library March 2010
6. LFB Classes Description
According to ForCES specifications, LFB (Logical Function Block) is a
well defined, logically separable functional block that resides in an
FE, and is a functionally accurate abstraction of the FE's processing
capabilities. An LFB Class (or type) is a template that represents a
fine-grained, logically separable aspect of FE processing. Most LFBs
relate to packet processing in the data path. LFB classes are the
basic building blocks of the FE model.
Only for better understanding purposes, LFB classes defined in this
document are further categorized into groups of LFBs, including Core
LFBs, Port LFBs, etc.
The following sections describe the LFB classes according to the
groups.
6.1. Core LFBs
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.
6.1.1. FE Protocol 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 definition of the LFB is included in this base LFB library by
using "load" element:
<load library="FEPO", location="..."/>
6.1.2. FE Object LFB
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 definition of the LFB is included in this base LFB library by
Wang, et al. Expires September 4, 2010 [Page 39]
Internet-Draft ForCES LFB Library March 2010
using "load" element:
<load library="FEObject", location="..."/>
6.2. Port LFBs
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.
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.
6.2.1. Generic Connectivity LFB
This LFB Class provides a generic basis for representing connectivity
between the FE and the outside world. The LFB has one or more ports
for packets that the FE processing logic is forwrding 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
FE processing logic. Multiple ports for handline packets are
supported so that protocol specific encapsulation and demultiplexing
can be provided by this LFB. This LFB also has ports for sending
packets to lower layer Connectivity LFBs and receiving packets from
such lower layer Connectivity LFBs. This enables support for the
processing components of interface stacks, such as PPP over Ethernet
or Ethernet over MPLS. For packets arriving from Media or lower
layer connectivity, this LFB will perform appropriate media
validation, then remove media specific headers, and place the
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 Ethernet with VLANs, this meta-data would
indicate which VLAN the packet came from. For packets to be
transmitted, meta-data indicating the destination (destination MAC or
outgoing circuit, etc.) is required. This LFB will also include
statistical components such as the number of octets and packets sent
and received, the number of various input and output errors, etc.
Wang, et al. Expires September 4, 2010 [Page 40]
Internet-Draft ForCES LFB Library March 2010
6.2.2. Ethernet Port LFBs
(TBD)
1. EtherPort LFB
LFB for Ethernet ports
2. EtherDecap LFB
An LFB class for definition of Ethernet decapsulation and
Ethernet filtering functions.
3. EtherEncap LFB
An LFB classifier definition for completes ethernet encapsulation
fuctions.
6.2.3. POS Port LFBs
(TBD)
6.2.4. ATM Port LFBs
(TBD)
6.3. Address Resolution LFBs
(TBD)
This LFB class provides the function of address resolution for IPv4/
IPv6 nodes.
1. ARP
This LFB class provides the function of address resolution for
IPv4 node.
2. IPv6 Address Resolution
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.
Wang, et al. Expires September 4, 2010 [Page 41]
Internet-Draft ForCES LFB Library March 2010
6.4. ICMP LFBs
(TBD)
1. ICMP Geneartor
This LFB class provide some basic ICMP function. It only
generate the following ICMP messages: ICMP destination
unreachable and time excceeded.
2. ICMPv6 Generator
This LFB class provide some basic ICMPv6 function, it only
generate the following ICMP messages for the packets that need
some basic ICMP processing: destination not reachable and time
excceeded.
6.5. IP Packet Validation LFBs
(TBD)
1. IPv4 Validator
An LFB Class definition for validates the IPv4 packet.
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.
2. IPv6 Validator
An LFB Class definition for validates the IPv6 packet.
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.
6.6. Classifier LFBs
(TBD)
1. Metadata Classifier LFB
This LFB class provides the function of classify packets
according to the meta data. Now it only works on one meta data.
2. Arbitrary Classifier LFB
Wang, et al. Expires September 4, 2010 [Page 42]
Internet-Draft ForCES LFB Library March 2010
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.
6.7. Forwarding LFBs
(TBD)
Forwarding LFBs are specifically for implementing IP packet
forwarding tasks.
6.7.1. Unicast Longest Prefix Match 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
queueing and scheduling. Queues are entities which store packets.
Schedulers are entities which react to the state of queues and cause
packets to be emitted from queues.
The actual interaction between queues and schedulers (and their real
world degree of separation) is quite complex. A very complex LFB
Wang, et al. Expires September 4, 2010 [Page 43]
Internet-Draft ForCES LFB Library March 2010
model would be required to represent all the complexity.
Additionally, there is the issue of representing the relationship
between the queue and the scheduler. A simple approach has been
taken in these class definitions.
A queue element consists of an input port (called InData) on which it
receives data packets, and output port (called OutData) on which it
will send packets when permitted by its definition or the scheduler.
Its relationship to scheduluers is represented by a set of output
ports (the group OutCountrol) and an input port (called InControl).
These ports are defined to carry packets consisting only of meta-
data. In fact, these ports are an abstraction, and what one might
call a legal fiction. An element of the OutControl group represents
the fact that a scheduler is aware of the state of that queue
element. The InControl port represents the fact that one or more
schedulers connected to that port are controlling that queue. There
is no meta-data defined for actual exchange on these ports, as their
real world realization is highly implementation dependent. To
complete this picture, a schedule has a group of input ports
(Watchers) representing the connectivity to queues it is aware of,
and a group of output ports (Controllers) representing control over
queues. This allows for the simple case of a controller who monitors
and controls a single set of queues, and more interesting cases where
the control of certain queues may depend upon the state of queues
whihc are not under the control of the scheduler.
The Queues and schedulers LFBs that are defined in this library are:
1. Scheduler
2. Queue
3. WRRSched
6.8.1. Scheduler LFBs
1. Generic 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.
2. WRRSched
Weighted round robin scheduler.
Wang, et al. Expires September 4, 2010 [Page 44]
Internet-Draft ForCES LFB Library March 2010
6.8.2. Queue LFBs
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.
6.9. Miscellaneous Packet Manipulation LFBs
(TBD)
1. Packet Trimmer LFB
LFB removes data from the front of a packet.
2. Duplicator LFB
An LFB Class definition for packet duplicator LFB. Any packet
received on an input port is logically copied and sent to all
output ports.
3. IPv4 Option Proccessing LFB
This LFB class process the IPv4 packet with options, it can
process on the following options: Router-alert option.
4. IPv6 Extend Header Processing LFB
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.
6.10. Redirect LFB
(TBD)
An LFB Class definition for exchanging data packets between the FE
and the CE.
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
that the output port of a RedirectLFB, if it is connected at all,
will be connected to a meta-data redirector.
Wang, et al. Expires September 4, 2010 [Page 45]
Internet-Draft ForCES LFB Library March 2010
7. XML Definition for Base LFB Library
<?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>
Wang, et al. Expires September 4, 2010 [Page 46]
Internet-Draft ForCES LFB Library March 2010
<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>
Wang, et al. Expires September 4, 2010 [Page 47]
Internet-Draft ForCES LFB Library March 2010
</component>
<component componentID="5" access="read-only">
<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">
Wang, et al. Expires September 4, 2010 [Page 48]
Internet-Draft ForCES LFB Library March 2010
<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>
Wang, et al. Expires September 4, 2010 [Page 49]
Internet-Draft ForCES LFB Library March 2010
</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>
Wang, et al. Expires September 4, 2010 [Page 50]
Internet-Draft ForCES LFB Library March 2010
<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>
Wang, et al. Expires September 4, 2010 [Page 51]
Internet-Draft ForCES LFB Library March 2010
</LFBClassDef>
<LFBClassDef LFBClassID="6">
<name>IPv4UcastLPM</name>
<synopsis>IPv4 Longest Prefix Match Lookup LFB</synopsis>
<version>1.0</version>
<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>
Wang, et al. Expires September 4, 2010 [Page 52]
Internet-Draft ForCES LFB Library March 2010
</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>
Wang, et al. Expires September 4, 2010 [Page 53]
Internet-Draft ForCES LFB Library March 2010
<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>
Wang, et al. Expires September 4, 2010 [Page 54]
Internet-Draft ForCES LFB Library March 2010
</metadataExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort>
<name>SuccessOut</name>
<synopsis>Output port for packet successfully fulfill the
nexthop application.</synopsis>
<product>
<frameProduced>
<ref> IPv4 </ref>
</frameProduced>
<metadataProduced>
<ref>DstFEID</ref>
<ref>OutputPortID</ref>
<ref availability="conditional">L2Index</ref>
<ref>NextHopIP</ref>
<ref availability="conditional">EncapMethod</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort>
<name>ExceptionOut</name>
<synopsis>Output for packets need deep dealt by higher level
protocol stacks.</synopsis>
<product>
<frameProduced>
<ref> IPv4 </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> IPv4 </ref>
</frameProduced>
</product>
</outputPort>
</outputPorts>
<components>
Wang, et al. Expires September 4, 2010 [Page 55]
Internet-Draft ForCES LFB Library March 2010
<component componentID="1">
<name> NextHopTable </name>
<synopsis>Nexthop table</synopsis>
<optional/>
<array type="variable-size">
<typeRef> IPv4NextHopInfoType </typeRef>
</array>
</component>
</components>
<capabilities>
<capability componentID="2">
<name>NextHopTableLimit</name>
<synopsis>Maxium number of nexthops this LFB supports
</synopsis>
<typeRef>uint32</typeRef>
</capability>
</capabilities>
</LFBClassDef>
<LFBClassDef LFBClassID="8">
<name>IPv6Validator</name>
<synopsis>A LFB class definition for validating correctness
of IPv6 packets</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>ValidateIn</name>
<synopsis>Input port for packets to be validated.</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
Wang, et al. Expires September 4, 2010 [Page 56]
Internet-Draft ForCES LFB Library March 2010
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>
Wang, et al. Expires September 4, 2010 [Page 57]
Internet-Draft ForCES LFB Library March 2010
<expectation>
<frameExpected>
<ref>IPv6</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort>
<name>SuccessOut</name>
<synopsis>Output for packets that have find the correct
route.</synopsis>
<product>
<frameProduced>
<ref>IPv6</ref>
</frameProduced>
<metadataProduced>
<ref>NextHopID</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort>
<name>FailOutput</name>
<synopsis>LPM failed.</synopsis>
<product>
<frameProduced>
<ref> IPv6 </ref>
</frameProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1">
<name> PrefixTable </name>
<synopsis>IPv6 prefix table</synopsis>
<array type="variable-size">
<typeRef> IPv6PrefixTableEntry </typeRef>
<contentKey contentKeyID="1">
<contentKeyField>IPv6PrefixTableEntry.prefix
</contentKeyField>
</contentKey>
</array>
</component>
<component componentID="2">
<name>LocalIpv6AddrTable</name>
<synopsis>The table of interfaces's ip address infomation on
the local device</synopsis>
<typeRef>LocalIpv6AddrType</typeRef>
Wang, et al. Expires September 4, 2010 [Page 58]
Internet-Draft ForCES LFB Library March 2010
</component>
<component componentID="3" access="read-reset">
<name>IPv6Stats</name>
<synopsis>The IPv6 associated statistics</synopsis>
<optional/>
<typeRef> IPv6LPMClassiferStatisticsType </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>LocalIpv6AddrTableLimit</name>
<synopsis>maxium number of IPv6 address entrys supported
by this LFB</synopsis>
<typeRef>uint32</typeRef>
</capability>
</capabilities>
</LFBClassDef>
<LFBClassDef LFBClassID="10">
<name>IPv6UcastNexthopApplicator</name>
<synopsis>An LFB for applicating next hop action to IPv6 packets,
actions mainly inlcude TTL incrementation and checksum
recalculation.</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>PktIn</name>
<synopsis>Input port for packets to be applicate nexthop.
</synopsis>
<expectation>
<frameExpected>
<ref> IPv6 </ref>
</frameExpected>
<metadataExpected>
<ref>NextHopID</ref>
</metadataExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort>
<name>SuccessOut</name>
<synopsis>Output port for packet successfully fulfill the
Wang, et al. Expires September 4, 2010 [Page 59]
Internet-Draft ForCES LFB Library March 2010
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">
Wang, et al. Expires September 4, 2010 [Page 60]
Internet-Draft ForCES LFB Library March 2010
<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>
Wang, et al. Expires September 4, 2010 [Page 61]
Internet-Draft ForCES LFB Library March 2010
</outputPort>
<outputPort group="true">
<name>ExceptionOut</name>
<synopsis>packet can't find the associated L2 information
</synopsis>
<product>
<frameProduced>
<ref>IPv4</ref>
<ref>IPv6</ref>
</frameProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1">
<name>ArpTable</name>
<synopsis>Ethernet arp table.</synopsis>
<array>
<typeRef>ArpTableEntryType</typeRef>
</array>
</component>
<component componentID="2">
<name>NbrTable</name>
<synopsis>IPv6 neighbour table.</synopsis>
<optional/>
<array>
<typeRef>NbrTableEntryType</typeRef>
</array>
</component>
<component componentID="3">
<name>DCHostTablev4</name>
<synopsis>Direct connected host arp table for IPv4.
</synopsis>
<array>
<typeRef>DCHostTableEntryTypev4</typeRef>
</array>
</component>
<component componentID="4">
<name>DCHostTablev6</name>
<synopsis>Direct connected host arp table for IPv6.
</synopsis>
<optional/>
<array>
<typeRef>DCHostTableEntryTypev6</typeRef>
</array>
</component>
</components>
<capabilities>
Wang, et al. Expires September 4, 2010 [Page 62]
Internet-Draft ForCES LFB Library March 2010
<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>
Wang, et al. Expires September 4, 2010 [Page 63]
Internet-Draft ForCES LFB Library March 2010
</inputPort>
</inputPorts>
<outputPorts>
<outputPort group="true">
<name>OutControl</name>
<synopsis>Control output,this output is used by scheduler
to communicate commands to it's controlled queues such as
dequeue a packet.</synopsis>
<product>
<frameProduced>
<ref>MetadataFrame</ref>
</frameProduced>
<metadataProduced>
<ref>QueueOperationCmd</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<capabilities>
<capability componentID="1">
<name>QueueScheduledLimit</name>
<synopsis>Max number of queues that can be scheduled by this
scheduler.</synopsis>
<typeRef>uint32</typeRef>
</capability>
</capabilities>
</LFBClassDef>
<LFBClassDef LFBClassID="13">
<name> Queue </name>
<synopsis>Queue LFB.</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>InControl</name>
<synopsis>Input from scheduler</synopsis>
<expectation>
<metadataExpected>
<ref>QueueOperationCmd</ref>
</metadataExpected>
</expectation>
</inputPort>
<inputPort>
<name>InData</name>
<synopsis>Input port for data packet.</synopsis>
<expectation>
<frameExpected>
<ref>Arbitrary</ref>
</frameExpected>
Wang, et al. Expires September 4, 2010 [Page 64]
Internet-Draft ForCES LFB Library March 2010
<metadataExpected>
<ref>PacketLength</ref>
</metadataExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort>
<name>OutToController</name>
<synopsis>Output to queue controller</synopsis>
<product>
<frameProduced>
<ref>MetadataFrame</ref>
</frameProduced>
<metadataProduced>
<ref>QueueID</ref>
<ref>PacketLength</ref>
<ref>QueueOperationCmd</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort>
<name>OutData</name>
<synopsis>Data packet output</synopsis>
<product>
<frameProduced>
<ref>Arbitrary</ref>
</frameProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1">
<name>CurLen</name>
<synopsis>Current length of the queue in number of packets.
</synopsis>
<typeRef>uint32</typeRef>
</component>
</components>
<capabilities>
<capability componentID="1">
<name>QueueLenLimit</name>
<synopsis>Maximum length of the queue in number of packets.
</synopsis>
<typeRef>uint32</typeRef>
</capability>
</capabilities>
</LFBClassDef>
Wang, et al. Expires September 4, 2010 [Page 65]
Internet-Draft ForCES LFB Library March 2010
<LFBClassDef LFBClassID="14">
<name>RedirectSink</name>
<synopsis>This class definition provides for the function of
sinking data packets that needed to be sent to CE. </synopsis>
<version>1.0</version>
<inputPorts>
<inputPort group="true">
<name>InFromOtherLFBs</name>
<synopsis>Packets input from other LFBs and needed to sent
to CE.</synopsis>
<expectation>
<frameExpected>
<ref>IPv4</ref>
<ref>IPv6</ref>
</frameExpected>
<metadataExpected>
<ref>InputPortID</ref>
<ref>PacketLength</ref>
<ref>PacketType</ref>
</metadataExpected>
</expectation>
</inputPort>
</inputPorts>
</LFBClassDef>
<LFBClassDef LFBClassID="15">
<name>RedirectTap</name>
<synopsis>This class provides the function of sinking data
packets that comes from CE and needed to be sent out by this
FE.</synopsis>
<version>1.0</version>
<outputPorts>
<outputPort group="true">
<name>OutputToOtherLFBs</name>
<synopsis>Packets input received from CE.</synopsis>
<product>
<frameProduced>
<ref>IPv4</ref>
<ref>IPv6</ref>
</frameProduced>
<metadataProduced>
<ref>PacketType</ref>
<ref>OutputPortID</ref>
<ref>PacketLength</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
Wang, et al. Expires September 4, 2010 [Page 66]
Internet-Draft ForCES LFB Library March 2010
<component componentID="1">
<name>DispatchTable</name>
<synopsis>The table to dispatch the packets to different LFB.
</synopsis>
<typeRef>DispatchTableType</typeRef>
</component>
<component componentID="2">
<name>outGroupNumOfPorts</name>
<synopsis>The number of ports in output group.</synopsis>
<typeRef>uint32</typeRef>
</component>
</components>
<capabilities>
<capability componentID="1">
<name>MaxNumOfoutGroupPorts</name>
<synopsis>The maxium number of ports in the output group.
</synopsis>
<typeRef>uint32</typeRef>
</capability>
</capabilities>
</LFBClassDef>
<LFBClassDef LFBClassID="16">
<name>WRRSched</name>
<synopsis>Weighted round robin scheduler.</synopsis>
<version>1.0</version>
<derivedFrom>Scheduler</derivedFrom>
<components>
<component componentID="1">
<name>WeightTable</name>
<synopsis>Weight table for queues to be scheduled.</synopsis>
<array type="variable-size">
<typeRef>WeightTableEntryType</typeRef>
</array>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="17">
<name>IPv6AddrResolution</name>
<synopsis>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.
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>AddrResDataPktIn</name>
<synopsis>The IPv6 data packet that need to do the address
Wang, et al. Expires September 4, 2010 [Page 67]
Internet-Draft ForCES LFB Library March 2010
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>
<outputPort>
<name>AddrResProtoPktOut</name>
<synopsis>The IPv6 neighbour discovey packet wich has been
encapsulation with the correct ethernet L2 info.</synopsis>
<product>
<frameProduced>
<ref>EthernetII</ref>
</frameProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1">
<name>Nbrtable</name>
<synopsis>This table is an alias to the IPv6 neighbour table
in the EtherEncap LFB.</synopsis>
<alias>NbrTable</alias>
</component>
Wang, et al. Expires September 4, 2010 [Page 68]
Internet-Draft ForCES LFB Library March 2010
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="18">
<name>ICMPv6Generator</name>
<synopsis>This LFB class provide some basic ICMPv6 function,it
only generate the following ICMP messages for the packets that
need some basic icmp processing:destination not reachable and
time excceeded.</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>PktIn</name>
<synopsis>The IPv6 packet that need icmp processing.
</synopsis>
<expectation>
<frameExpected>
<ref>IPv6</ref>
</frameExpected>
<metadataExpected>
<ref>ExceptionID</ref>
</metadataExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort>
<name>ICMPv6PktOut</name>
<synopsis>The output for the ICMPv6 packets generated
according to the input IPv6 packet and the ExceptionID.
</synopsis>
<product>
<frameProduced>
<ref>IPv6</ref>
</frameProduced>
</product>
</outputPort>
</outputPorts>
</LFBClassDef>
<LFBClassDef LFBClassID="19">
<name>ExtendHeaderProc</name>
<synopsis>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.</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>PktIn</name>
<synopsis>The IPv6 packet with extended header in.</synopsis>
Wang, et al. Expires September 4, 2010 [Page 69]
Internet-Draft ForCES LFB Library March 2010
<expectation>
<frameExpected>
<ref>IPv6</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort group="true">
<name>PktOut</name>
<synopsis>According to the Extended header type the packet
may have different next proccesing LFB.Now by default we
send all the packet with extended header to CE.</synopsis>
<product>
<frameProduced>
<ref>IPv6</ref>
</frameProduced>
</product>
</outputPort>
</outputPorts>
</LFBClassDef>
<LFBClassDef LFBClassID="20">
<name>arp</name>
<synopsis>This LFB class provides the function of address
resolution for IPv4 nodes.</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>AddrResDataPktIn</name>
<synopsis>The IPv4 data packet that need to do the address
resolution.</synopsis>
<expectation>
<frameExpected>
<ref>IPv4</ref>
</frameExpected>
</expectation>
</inputPort>
<inputPort>
<name>ArpPktIn</name>
<synopsis>The neighbour discovery packet related to
addresolution.</synopsis>
<expectation>
<frameExpected>
<ref>IPv4</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
Wang, et al. Expires September 4, 2010 [Page 70]
Internet-Draft ForCES LFB Library March 2010
<outputPorts>
<outputPort>
<name>AddrResDataPktOut</name>
<synopsis>The IPv4 packet that have been encapsulated with
the correct ethernet L2 info and need to be sent out to
link.</synopsis>
<product>
<frameProduced>
<ref>EthernetII</ref>
</frameProduced>
</product>
</outputPort>
<outputPort>
<name>ArpOut</name>
<synopsis>The arp packet out.</synopsis>
<product>
<frameProduced>
<ref>EthernetII</ref>
</frameProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1">
<name>Arptable</name>
<synopsis>This table is an alias of the arp table in the
EtherEncap LFB.</synopsis>
<alias>ArpTable</alias>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="21">
<name>ICMPGenerator</name>
<synopsis>This LFB class provide some basic ICMP function,it
only generate the following ICMP messages:ICMP destination
unreachable and time excceeded.</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>PktIn</name>
<synopsis>The IPv4 packet that need icmp processing.
</synopsis>
<expectation>
<frameExpected>
<ref>IPv4</ref>
</frameExpected>
<metadataExpected>
<ref>ExceptionID</ref>
Wang, et al. Expires September 4, 2010 [Page 71]
Internet-Draft ForCES LFB Library March 2010
</metadataExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort>
<name>ICMPPktOut</name>
<synopsis>The output for the ICMP packets generated according
to the input packet and the ExceptionID.</synopsis>
<product>
<frameProduced>
<ref>IPv4</ref>
</frameProduced>
</product>
</outputPort>
</outputPorts>
</LFBClassDef>
<LFBClassDef LFBClassID="22">
<name>MetadataClassifier</name>
<synopsis>This LFB class provides the function of classify
packets according to the meta data.Now it only works on one
meta data.</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>PktIn</name>
<synopsis>Packets need to do the classification.</synopsis>
<expectation>
<frameExpected>
<ref>Arbitrary</ref>
</frameExpected>
<metadataExpected>
<ref>Arbitrary</ref>
</metadataExpected>
<!-- jfg:how to express here that we only need one meta
data of any kind?The model says that variable tag
metadata do this need but doesn't show how to use it.-->
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort group="true">
<name>ClassifiedOut</name>
<synopsis>The output group for the classified packets.
</synopsis>
<product>
<frameProduced>
<ref>Arbitrary</ref>
Wang, et al. Expires September 4, 2010 [Page 72]
Internet-Draft ForCES LFB Library March 2010
</frameProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1">
<name>MetaDataID</name>
<synopsis>The metadata id that this classifier works on.
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>MetaDataName</name>
<synopsis>The name of the meta data that this classifier
works on.</synopsis>
<typeRef>string</typeRef>
</component>
<component componentID="3">
<name>MetadataClassifyTable</name>
<synopsis>The meta data classifying table.</synopsis>
<typeRef>MetadataClassyTableType</typeRef>
</component>
<component componentID="4">
<name>OutNumOfPorts</name>
<synopsis>The number of ports in the output group.</synopsis>
<typeRef>uint32</typeRef>
</component>
</components>
<capabilities>
<capability componentID="1">
<name>MaxOutNumOfPorts</name>
<synopsis>Maxium number of ports in the output group.
</synopsis>
<typeRef>uint32</typeRef>
</capability>
</capabilities>
</LFBClassDef>
<LFBClassDef LFBClassID="23">
<name>OptionProc</name>
<synopsis>This LFB class process the IPv4 packet with options,
it can process on the following options:Router-alert option.
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>PktIn</name>
<synopsis>The IPv4 packet with options in.</synopsis>
<expectation>
Wang, et al. Expires September 4, 2010 [Page 73]
Internet-Draft ForCES LFB Library March 2010
<frameExpected>
<ref>IPv4</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort group="true">
<name>PktOut</name>
<synopsis>According to the Option type the packet may have
different next proccesing LFB.Now by default we send all
the packet with extended header to CE.</synopsis>
<product>
<frameProduced>
<ref>IPv4</ref>
</frameProduced>
</product>
</outputPort>
</outputPorts>
</LFBClassDef>
</LFBClassDefs>
</LFBLibrary>
Wang, et al. Expires September 4, 2010 [Page 74]
Internet-Draft ForCES LFB Library March 2010
8. Base LFB Library Use Case for Typical Router Functions
This section demonstrates examples on how the LFB classes defined by
the Base LFB library in Section 7 are applied to the achievements of
typical router functions.
As mentioned in the overview section, typical router functions can be
categorized in short into the following functions:
o IP forwarding
o address resolution
o ICMP
o network management
o running routing protocol
To achieve the functions, processing paths organized by the LFB
classes with their interconnections should be established in FE. In
general, CE controls and manages the processing paths by use of the
ForCES protocol.
Note that LFB class use cases shown in this section are only as
examples to demonstrate how typical router functions can be
implemented with the defined base LFB library. Users and
implementors of the base LFB library should not be limited by the
examples.
8.1. IP Forwardings
IP packets to be forwarded are from interfaces conneted via a kind of
media to outer networks. A Port LFB receives link layer packets. CE
may control the port LFB status by the LFB components defined in the
library. Link layer packets are delivered to a decapsulation LFB to
decapsulate to IP packets. The LFB also provides IP packet
distinguishing by classifying IP packet according to its types like
IPv4 or IPv6, unicast or multicast, and ARP packet. The packet type
information is included in a IPPacketType metadata and the metadata
is associated with every decapsulated IP packet.
Followed decapsulation LFBs are usually IP validation LFBs which
further validate IP packets according to IP protocol. The LFB also
distinguishes if the IP packets are exceptional packets like ICMP
packets other than IP packets to be further forwarded. The
exceptional packets are then associated with metadata indicating the
packet types and delivered to metadata classifier for specific
Wang, et al. Expires September 4, 2010 [Page 75]
Internet-Draft ForCES LFB Library March 2010
classification and further processing.
Validated IP unicast packets for forwarding are delivered to unicast
Longes Prifix Match(UcastLPM) LFB, which produce nexthop information
for forwarding. The nexthop information is represented by a
nexthopID metadata.
IP packets with associated nexthop metadata are delivered to the
NextHopApplicator LFB. The LFB decides output ports for the IP
packets. Note that when IP packets need to traverse FEs for
forwarding, the LFB may also only decides the local FE output port to
the other FE and makes the packet to carry the nexthop information to
that FE.
IP packets with nexthop applied are then encapsulated by a link layer
encapsulation LFB according to the egress media and put on to the
appropriate output ports. In this process, address resolution LFBs
may have to be applied to decide the link layer output addresses for
the packets. Moreover, the queue management LFBs and scheduler LFBs
may be applied in the process to achieve individual QoS requirements.
Figure 1 shows the typical LFB processing path for the IPv4 unicast
forwarding case.
Figure 1. (TBD)
Figure 2 shows the typical LFB processing path for the IPv6 unicast
forwarding case.
Figure 2. (TBD)
8.2. Address Resolution
TBD
8.3. ICMP
TBD
8.4. Running Routing Protocol
TBD
8.5. Network Management
TBD
Wang, et al. Expires September 4, 2010 [Page 76]
Internet-Draft ForCES LFB Library March 2010
9. Contributors
The authors would like to thank Jamal Hadi Salim and Ligang Dong who
made a major contribution to the development of this document.
Jamal Hadi Salim
Mojatatu Networks
Ottawa, Ontario
Canada
Email: hadi@mojatatu.com
Ligang Dong
Zhejiang Gongshang University
149 Jiaogong Road
Hangzhou 310035
P.R.China
Phone: +86-571-28877751
EMail: donglg@mail.zjgsu.edu.cn
Wang, et al. Expires September 4, 2010 [Page 77]
Internet-Draft ForCES LFB Library March 2010
10. Acknowledgements
This document is based on earlier documents from Joel Halpern, Ligang
Dong, Fenggen Jia and Weiming Wang.
Wang, et al. Expires September 4, 2010 [Page 78]
Internet-Draft ForCES LFB Library March 2010
11. IANA Considerations
(TBD)
Wang, et al. Expires September 4, 2010 [Page 79]
Internet-Draft ForCES LFB Library March 2010
12. Security Considerations
These definitions if used by an FE to support ForCES create
manipulable entities on the FE. Manipulation of such objects can
produce almost unlimited effects on the FE. FEs should ensure that
only properly authenticated ForCES protocol participants are
performing such manipulations. Thus the security issues with this
protocol are defined in the FE-protocol [I-D.ietf-forces-protocol].
Wang, et al. Expires September 4, 2010 [Page 80]
Internet-Draft ForCES LFB Library March 2010
13. References
13.1. Normative References
[I-D.ietf-forces-model]
Halpern, J. and J. Salim, "ForCES Forwarding Element
Model", draft-ietf-forces-model-16 (work in progress),
October 2008.
[I-D.ietf-forces-protocol]
Dong, L., Doria, A., Gopal, R., HAAS, R., Salim, J.,
Khosravi, H., and W. Wang, "ForCES Protocol
Specification", draft-ietf-forces-protocol-22 (work in
progress), March 2009.
13.2. Informative References
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
July 2003.
[RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation
of IP Control and Forwarding", RFC 3654, November 2003.
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal,
"Forwarding and Control Element Separation (ForCES)
Framework", RFC 3746, April 2004.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
Wang, et al. Expires September 4, 2010 [Page 81]
Internet-Draft ForCES LFB Library March 2010
Authors' Addresses
Weiming Wang
Zhejiang Gongshang University
18, Xuezheng Str., Xiasha University Town
Hangzhou, 310018
P.R.China
Phone: +86-571-28877721
Email: wmwang@mail.zjgsu.edu.cn
Evangelos Haleplidis
University of Patras
Patras,
Greece
Email: ehalep@ece.upatras.gr
Kentaro Ogawa
NTT Corporation
Tokyo,
Japan
Email: ogawa.kentaro@lab.ntt.co.jp
Fenggen Jia
National Digital Switching Center(NDSC)
Jianxue Road
Zhengzhou, 452000
P.R.China
Phone: +86-571-28877751
Email: jfg@mail.ndsc.com.cn,fgjia@mail.zjgsu.edu.cn
Halpern Joel
Ericsson
P.O. Box 6049
Leesburg, 20178
VA
Phone: +1 703 371 3043
Email: jhalpern@redback.com
Wang, et al. Expires September 4, 2010 [Page 82]