TOC 
Internet Engineering Task ForceW. Wang
Internet-DraftZhejiang Gongshang University
Intended status: InformationalE. Haleplidis
Expires: January 1, 2010University of Patras
 K. Ogawa
 NTT Corporation
 F. Jia
 National Digital Switching
 Center(NDSC)
 J. Halpern
 Ericsson
 June 30, 2009


ForCES LFB Library
draft-ietf-forces-lfb-lib-00

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.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on January 1, 2010.

Copyright Notice

Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

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.


Table of Contents

1.  Terminology and Conventions
    1.1.  Requirements Language
2.  Definitions
3.  Introduction
4.  Base Definitions
    4.1.  Framedefs
    4.2.  DataTypeDefs
    4.3.  MetaDataDefs
5.  LFB Descriptions
    5.1.  Core LFBs
        5.1.1.  FEObject LFB
        5.1.2.  FEProtocol LFB
    5.2.  Port LFBs
        5.2.1.  GenericConnectivityLFB
        5.2.2.  EtherPort
        5.2.3.  EtherDecap
        5.2.4.  EtherEncap
    5.3.  Address LFBs
        5.3.1.  IPv6AddrResolution
        5.3.2.  Arp
        5.3.3.  ICMPGenerator
        5.3.4.  ICMPv6Generator
        5.3.5.  IPv4Validator
        5.3.6.  IPv6Validator
    5.4.  Forwarding LFBs
        5.4.1.  IPv4UcastLPM
        5.4.2.  IPv4NextHopApplicator
        5.4.3.  IPv6UcastLPM
        5.4.4.  IPv6UcastNexthopApplicator
    5.5.  Queue and scheduler LFBs
        5.5.1.  Scheduler
        5.5.2.  Queue
        5.5.3.  WRRSched
    5.6.  Miscellanious LFBs
        5.6.1.  ExtendHeaderProc
        5.6.2.  MetadataClassifier
        5.6.3.  OptionProc
        5.6.4.  RedirectLFB
        5.6.5.  PacketTrimmer
        5.6.6.  Duplicator
        5.6.7.  ArbitraryClassifierLFB
6.  LFB Library Definition
7.  LFB Use Case
8.  Contributors
9.  Acknowledgements
10.  IANA Considerations
11.  Security Considerations
12.  References
    12.1.  Normative References
    12.2.  Informative References
§  Authors' Addresses



 TOC 

1.  Terminology and Conventions


 TOC 

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).


 TOC 

2.  Definitions

This document follows the terminology defined by the ForCES Requirements in [RFC3654] (Khosravi, H. and T. Anderson, “Requirements for Separation of IP Control and Forwarding,” November 2003.)and by the ForCES framework in [RFC3746] (Yang, L., Dantu, R., Anderson, T., and R. Gopal, “Forwarding and Control Element Separation (ForCES) Framework,” April 2004.). 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 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.


 TOC 

3.  Introduction

XXX: Editorial Note: This is an initial rough copy of the document which will undergo heavy review and modification. It was published to beat the meeting deadline.

Forwarding and Control Element Separation (ForCES) defines an 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] (Khosravi, H. and T. Anderson, “Requirements for Separation of IP Control and Forwarding,” November 2003.)has defined the ForCES requirements, and [RFC3746] (Yang, L., Dantu, R., Anderson, T., and R. Gopal, “Forwarding and Control Element Separation (ForCES) Framework,” April 2004.) has defined the ForCES framework.

The ForCES protocol Protocol FE-protocol (Dong, L., Doria, A., Gopal, R., HAAS, R., Salim, J., Khosravi, H., and W. Wang, “ForCES Protocol Specification,” March 2009.) [I‑D.ietf‑forces‑protocol] defines a protocol by which Control Elements (CEs) communicated with and control the behavior of Forwarding Elements (FEs). That control is expressed in terms of manipulations of components of Logical Function Blocks (LFBs). The structure and abstract semantics of LFBs is defined in Model FE-MODEL (Halpern, J. and J. Salim, “ForCES Forwarding Element Model,” October 2008.) [I‑D.ietf‑forces‑model]. That document also defines a single LFB Class for gaining access to FE properties including the set of LFBs and their interconnection. The Protocol document defines an LFB class for manipulating the protocol properties of the FE.

In order for the protocol to be useful to control any behavior, there must be a set of LFB class definitions for the LFBs which provide that behavior. This document provides a set of such definitions. This document is intended to provide an initial LFB library. It is expected that other definitions will be developed over time, and documented in other RFCs.

An LFB performs a well-defined action or computation on the packets passing through it. Upon completion of its prescribed function, either the packets are modified in certain ways (e.g., decapsulator, marker), or some results are generated and stored, often in the form of metadata (e.g., classifier). Each LFB typically performs a single action. Classifiers, shapers and meters are all examples of such LFBs.

In general, multiple LFBs are contained in one FE. An LFB, may have inputs, outputs and components that can be queried and manipulated by the CE via the ForCES Protocol. An LFB can have one or more inputs. Each input takes a pair of a packet and its associated metadata. The LFB processes the input, and produces one or more outputs, each of which is a pair of a packet and its associated metadata.

For further information regarding the LFB model, the reader is referenced to FE-MODEL (Halpern, J. and J. Salim, “ForCES Forwarding Element Model,” October 2008.) [I‑D.ietf‑forces‑model].

XXX: The above text is redundant. The definition gives some intro to LFBs and the model and all the other docs before this tell us what an LFB is

In this document we first define base structures used in building the LFBs in section 4 then use those base definitions to define various LFBs.

To simplify the understanding of these LFBs - we have chosen to group them by functionality. The following groups of LFBs will be described in section 5:

  1. Core LFBs.
  2. Port LFBs.
  3. Address LFBs.
  4. Forwarding LFBs.
  5. Queue manager and scheduler LFBs.
  6. Miscellanious LFBs.


 TOC 

4.  Base Definitions

This section povides a base set of LFB frame, data type, and meta data definitions for use by all any LFB Class definitions (in this or other documents. This section provides no actual LFB Class definitions.

These are then used in each subsequent definition by the statement: 

<load library="Base"/>


 TOC 

4.1.  Framedefs

The following Frames are defined:

  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. 

<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>IPv4Frame</name>
    <synopsis>An IPv4 packet</synopsis>
  </frameDef>
  <frameDef>
    <name>IPv6Frame</name>
    <synopsis>An IPv6 packet</synopsis>
  </frameDef>
  <frameDef>
    <name>taggedFrame</name>
    <synopsis>A frame of any type with associated metadata.</synopsis>
  </frameDef>
  <frameDef>
    <name>MetadataFrame</name>
    <synopsis>Frame only contains meta data</synopsis>
  </frameDef>
  <frameDef>
    <name>Arbitrary</name>
    <synopsis>Any kind of frame except Metadata Frame.</synopsis>
  </frameDef>
</frameDefs>


 TOC 

4.2.  DataTypeDefs

The following Data Types are defined:

  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.
  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.
  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. 

<dataTypeDefs>
  <dataTypeDef>
    <name>ifIndex</name>
    <synopsis>A Port Identifier</synopsis>
    <typeRef>uint32</typeRef>
  </dataTypeDef>
  <dataTypeDef>
    <name>IEEEMAC</name>
    <synopsis>IEEE MAC Address</synopsis>
    <typeRef>byte[6]</typeRef>
  </dataTypeDef>
  <dataTypeDef>
    <name>NetSpeedType</name>
    <synopsis>Network speed values</synopsis>
    <atomic>
      <baseType>uint32</baseType>
      <specialValues>
        <specialValue value="0x00000001">
          <name>LAN_SPEED_10M</name>
          <synopsis>10M Ethernet</synopsis>
        </specialValue>
        <specialValue value="0x00000002">
          <name>LAN_SPEED_100M</name>
          <synopsis>100M Ethernet</synopsis>
        </specialValue>
        <specialValue value="0x00000003">
          <name>LAN_SPEED_1G</name>
          <synopsis>1000M Ethernet</synopsis>
        </specialValue>
        <specialValue value="0x00000004">
          <name>LAN_SPEED_10G</name>
          <synopsis>10G Ethernet</synopsis>
        </specialValue>
        <specialValue value="0x00000005">
          <name>LAN_SPEED_AUTO</name>
          <synopsis>LAN speed auto</synopsis>
        </specialValue>
      </specialValues>
<!--XXX:This doesnt look like the SNMP
  definitions. We should look at the SNMP
  definitions for guidance; we should not have
  limitations that SNMP has such as being
  restricted to 32 bits"
  "refer to RFC 3635 ifSpeed and ifHighSpeed"
-->
   </atomic>
  </dataTypeDef>
  <dataTypeDef>
    <name>IEEENegotiationType</name>
    <synopsis>IEEENegotiation types</synopsis>
    <atomic>
      <baseType>uint32</baseType>
      <specialValues>
        <specialValue value="0x00000001">
          <name>Auto</name>
          <synopsis>Auto negotitation.</synopsis>
        </specialValue>
        <specialValue value="0x00000002">
          <name>Half-duplex</name>
          <synopsis>port negotitation half duplex</synopsis>
        </specialValue>
        <specialValue value="0x00000003">
          <name>Full-duplex</name>
          <synopsis>port negotitation full duplex</synopsis>
        </specialValue>
      </specialValues>
    </atomic>
<!--XXX:This is very IEEE specific-->
  </dataTypeDef>
  <dataTypeDef>
    <name>PortStatsType</name>
    <synopsis>Port statistics</synopsis>
    <struct>
      <component componentID="1">
        <name>InUcastPkts</name>
        <synopsis>Number of unicast packets received</synopsis>
        <typeRef>uint64</typeRef>
      </component>
      <component componentID="2">
        <name>InMulticastPkts</name>
        <synopsis>Number of multicast packets received</synopsis>
        <typeRef>uint64</typeRef>
      </component>
      <component componentID="3">
        <name>InBroadcastPkts</name>
        <synopsis>Number of broadcast packets received</synopsis>
        <typeRef>uint64</typeRef>
      </component>
      <component componentID="4">
        <name>InOctets</name>
        <synopsis>number of octets received</synopsis>
        <typeRef>uint64</typeRef>
      </component>
      <component componentID="5">
        <name>OutUcastPkts</name>
        <synopsis>Number of unicast packets transmitted</synopsis>
        <typeRef>uint64</typeRef>
      </component>
      <component componentID="6">
        <name>OutMulticastPkts</name>
        <synopsis>Number of multicast packets transmitted</synopsis>
        <typeRef>uint64</typeRef>
      </component>
      <component componentID="7">
        <name>OutBroadcastPkts</name>
        <synopsis>Number of broadcast packets transmitted</synopsis>
        <typeRef>uint64</typeRef>
      </component>
      <component componentID="8">
        <name>OutOcetes</name>
        <synopsis>Number of octets transmitted</synopsis>
        <typeRef>uint64</typeRef>
      </component>
      <component componentID="9">
        <name>InErrorPkts</name>
        <synopsis>Number of input error packets</synopsis>
        <typeRef>uint64</typeRef>
      </component>
      <component componentID="10">
        <name>OutErrorPkts</name>
        <synopsis>Number of output error packets</synopsis>
        <typeRef>uint64</typeRef>
      </component>
    </struct>
<!--XXX:Make sure we validate with SNMP Port Stats-->
  </dataTypeDef>
  <dataTypeDef>
    <name>PortStatusValues</name>
    <synopsis>
            The possible values of status.  Used for both
            administrative and operation status</synopsis>
    <atomic>
      <baseType>uchar</baseType>
      <specialValues>
        <specialValue value="0">
          <name>Disabled</name>
          <synopsis>the port is operatively disabled.</synopsis>
        </specialValue>
        <specialValue value="1">
          <name>UP</name>
          <synopsis>the port is up.</synopsis>
        </specialValue>
        <specialValue value="2">
          <name>Down</name>
          <synopsis>The port is down.</synopsis>
        </specialValue>
      </specialValues>
<!--XXX:Need to conform with Administrative and operational status-->
    </atomic>
  </dataTypeDef>
  <dataTypeDef>
    <name>LocalIpAddrType</name>
    <synopsis>Local IP address belonging to FE.</synopsis>
    <struct>
      <component componentID="1">
        <name>FEID</name>
        <synopsis>The FE on which the port ip resides</synopsis>
        <typeRef>uint32</typeRef>
<!--XXX:FEID is know to the Object LFB. Do we need it here?-->
      </component>
      <component componentID="2">
        <name>IfIndex</name>
        <synopsis>port index on the specified FE</synopsis>
        <typeRef>uint32</typeRef>
<!--XXX:We need to support the model that says that a local IP has
multiple ports. Should this be an array of uint32-->
      </component>
      <component componentID="3">
        <name>IPaddr</name>
        <synopsis>IP address of the port</synopsis>
        <typeRef>IPAddr</typeRef>
      </component>
      <component componentID="4">
        <name>netmask</name>
        <synopsis>netmask of this ip address</synopsis>
        <typeRef>IPAddr</typeRef>
      </component>
      <component componentID="5">
       <name>BcastAddr</name>
        <synopsis>The associated Broadcast address of the
                                                  ip address</synopsis>
        <typeRef>IPAddr</typeRef>
      </component>
    </struct>
  </dataTypeDef>
  <dataTypeDef>
    <name>LocalIpv6AddrType</name>
    <synopsis>The device local IPv6 address infomation</synopsis>
    <struct>
      <component componentID="1">
        <name>FEID</name>
        <synopsis>The FE on which the port ip resides</synopsis>
        <typeRef>uint32</typeRef>
<!--XXX:FEID is know to the Object LFB. Do we need it here?-->
      </component>
      <component componentID="2">
        <name>IfIndex</name>
        <synopsis>port index on the specified FE</synopsis>
        <typeRef>uint32</typeRef>
<!--XXX:We need to support the model that says that a local IP has
multiple ports. Should this be an array of uint32-->
      </component>
      <component componentID="3">
        <name>IPv6addr</name>
        <synopsis>IP address of the port</synopsis>
        <typeRef>IPv6Addr</typeRef>
      </component>
      <component componentID="4">
        <name>prefixlen</name>
        <synopsis>prefix length of this ip address</synopsis>
        <typeRef>uint32</typeRef>
      </component>
    </struct>
  </dataTypeDef>
  <dataTypeDef>
    <name>IPv4Addr</name>
    <synopsis>IPv4 address</synopsis>
    <typeRef>byte[4]</typeRef>
  </dataTypeDef>
  <dataTypeDef>
    <name>IPv6Addr</name>
    <synopsis>IPv6 address</synopsis>
    <typeRef>byte[16]</typeRef>
  </dataTypeDef>
  <dataTypeDef>
    <name>IPv4Prefix</name>
    <synopsis>IPv4 prefix defined by an address and a prefix length
                                                            </synopsis>
    <struct>
      <component componentID="1">
        <name>address</name>
        <synopsis>Address part</synopsis>
        <typeRef>IPv4addr</typeRef>
      </component>
      <component componentID="2">
        <name>prefixlen</name>
        <synopsis>Prefix length part</synopsis>
        <atomic>
          <baseType>uchar</baseType>
          <rangeRestriction>
            <allowedRange min="0" max="32"/>
          </rangeRestriction>
        </atomic>
      </component>
    </struct>
  </dataTypeDef>
  <dataTypeDef>
    <name>IPv4NextHopInfoType</name>
<!--XXX:Needs more discussion-->
    <synopsis>IPv4 nexthop information,include nexthop ip address,
                                output FE and interface etc.</synopsis>
    <struct>
      <component componentID="1">
        <name>NexthopID</name>
        <synopsis>nexthop id</synopsis>
        <typeRef>uint32</typeRef>
      </component>
      <component componentID="2">
        <name>FEID</name>
        <synopsis>output FE id</synopsis>
        <typeRef>uint32</typeRef>
      </component>
      <component componentID="3">
        <name>Egress</name>
        <synopsis>output port index</synopsis>
        <typeRef>uint32</typeRef>
      </component>
      <component componentID="4">
        <name>MTU</name>
        <synopsis>The maximum transmition unit of the nexthop link.
                                                            </synopsis>
        <typeRef>uint32</typeRef>
      </component>
      <component componentID="5">
        <name>Flags</name>
        <synopsis>Associated flags of the nexthop,such as local
                                     delivery,multicast etc.</synopsis>
        <typeRef>NextHopFlagsType</typeRef>
      </component>
      <component componentID="6">
        <name>NexthopIPaddr</name>
        <synopsis>IP address of the nexthop</synopsis>
        <typeRef>IPv4Addr</typeRef>
      </component>
      <component componentID="7">
        <name>L2Index</name>
        <synopsis>index into the L2 link layer table,such as IPv4 ARP
                                    table or IPv6 NBR table.</synopsis>
        <typeRef>uint32</typeRef>
      </component>
      <component componentID="8">
        <name>EncapNeeded</name>
        <synopsis>The type of encapsulation needed on the packet.
                                                            </synopsis>
        <typeRef>LinkEncapType</typeRef>
      </component>
    </struct>
  </dataTypeDef>
  <dataTypeDef>
    <name>IPv4FibEntryType</name>
<!--XXX:Needs more discussion-->
    <synopsis>IPv4 forwarding table entry.</synopsis>
    <struct>
      <component componentID="1">
        <name>prefix</name>
        <synopsis>IPv4 prefix.</synopsis>
        <typeRef>IPv4Prefix</typeRef>
      </component>
      <component componentID="2">
        <name>FEID</name>
        <synopsis>output FE id</synopsis>
        <typeRef>uint32</typeRef>
      </component>
      <component componentID="3">
        <name>Egress</name>
        <synopsis>output port index</synopsis>
        <typeRef>uint32</typeRef>
      </component>
      <component componentID="4">
        <name>MTU</name>
        <synopsis>The maximum transmition unit of the nexthop link.
                                                            </synopsis>
        <typeRef>uint32</typeRef>
      </component>
      <component componentID="5">
        <name>Flags</name>
        <synopsis>Associated flags of the nexthop,such as local
                                     delivery,multicast etc.</synopsis>
        <typeRef>NextHopFlagsType</typeRef>
      </component>
      <component componentID="6">
        <name>NexthopIPaddr</name>
        <synopsis>IP address of the nexthop</synopsis>
        <typeRef>IPv4Addr</typeRef>
      </component>
      <component componentID="7">
        <name>L2Index</name>
        <synopsis>index into the L2 link layer table,such as IPv4 ARP
                                    table or IPv6 NBR table.</synopsis>
        <typeRef>uint32</typeRef>
      </component>
      <component componentID="8">
        <name>EncapNeeded</name>
        <synopsis>Type of encapsulation needed on the packet</synopsis>
        <typeRef>LinkEncapType</typeRef>
      </component>
    </struct>
  </dataTypeDef>
  <dataTypeDef>
    <name>IPv4PrefixTableEntry</name>
<!--XXX:Needs more discussion-->
    <synopsis>IPv4 prefix table entry</synopsis>
    <struct>
      <component componentID="1">
        <name>Prefix</name>
        <synopsis>IPv4 address prefix</synopsis>
        <typeRef>IPv4Prefix</typeRef>
      </component>
      <component componentID="2">
        <name>NexthopID</name>
        <synopsis>Index into the nexthop table.</synopsis>
        <typeRef>uint32</typeRef>
      </component>
    </struct>
  </dataTypeDef>
  <dataTypeDef>
    <name>IPv4UcastLPMStatisticsType</name>
<!--XXX:Needs more discussion-->
    <synopsis>statistics of IPv4UcastLPM LFB</synopsis>
    <struct>
      <component componentID="1">
        <name>InRcvdPkts</name>
        <synopsis>The total number of input packets received from
               interfaces, including those received in error</synopsis>
        <typeRef>uint64</typeRef>
      </component>
      <component componentID="2">
        <name>FwdPkts</name>
        <synopsis>IPv4 packet forwarded by this LFB</synopsis>
        <typeRef>uint64</typeRef>
      </component>
      <component componentID="3">
        <name>NoRoutePkts</name>
        <synopsis>The number of IP datagrams discarded because no route
       could be found to transmit them to their destination.</synopsis>
        <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>
<!--XXX:Needs more discussion-->
    <synopsis>IPv4 validator LFB statistics type</synopsis>
    <struct>
      <component componentID="1">
        <name>badHeaderPkts</name>
        <synopsis>The total number of input datagrams with bad ip
                                                      header</synopsis>
        <typeRef>uint64</typeRef>
      </component>
      <component componentID="2">
        <name>badTotalLengthPkts</name>
        <synopsis>The total number of input datagrams with bad length
                                                            </synopsis>
        <typeRef>uint64</typeRef>
      </component>
      <component componentID="3">
        <name>badTTLPkts</name>
        <synopsis>The total number of input datagrams with bad TTL
                                                            </synopsis>
        <typeRef>uint64</typeRef>
      </component>
      <component componentID="4">
        <name>badChecksum</name>
        <synopsis>The total number of input datagrams with bad checksum
                                                            </synopsis>
        <typeRef>uint64</typeRef>
      </component>
    </struct>
  </dataTypeDef>
  <dataTypeDef>
    <name>IPv6Prefix</name>
    <synopsis>IPv6 prefix</synopsis>
    <struct>
      <component componentID="1">
        <name>IPv6addr</name>
        <synopsis>address part of the prefix</synopsis>
        <typeRef>IPv6Addr</typeRef>
      </component>
      <component componentID="2">
        <name>prefixlen</name>
        <synopsis>length of the prefix</synopsis>
        <typeRef>uint32</typeRef>
      </component>
    </struct>
  </dataTypeDef>
  <dataTypeDef>
    <name>IPv6NextHopInfoType</name>
<!--XXX:Needs more discussion-->
    <synopsis>IPv6 nexthop information,including nexthop ip address,
                                output FE and interface etc.</synopsis>
    <struct>
      <component componentID="1">
        <name>NexthopID</name>
        <synopsis>nexthop id</synopsis>
        <typeRef>uint32</typeRef>
      </component>
      <component componentID="2">
        <name>FEID</name>
        <synopsis>output FE id</synopsis>
        <typeRef>uint32</typeRef>
      </component>
      <component componentID="3">
        <name>Egress</name>
        <synopsis>output port index</synopsis>
        <typeRef>uint32</typeRef>
      </component>
      <component componentID="4">
        <name>MTU</name>
        <synopsis>The maximum transmition unit of the nexthop link.
                                                            </synopsis>
        <typeRef>uint32</typeRef>
      </component>
      <component componentID="5">
        <name>Flags</name>
        <synopsis>Associated flags of the nexthop,such as local
                                     delivery,multicast etc.</synopsis>
        <typeRef>NextHopFlagsType</typeRef>
      </component>
      <component componentID="6">
        <name>NexthopIPv6addr</name>
        <synopsis>IP address of the nexthop</synopsis>
        <typeRef>IPv6Addr</typeRef>
      </component>
      <component componentID="7">
        <name>L2Index</name>
        <synopsis>index into the L2 table</synopsis>
        <typeRef>uint32</typeRef>
      </component>
      <component componentID="8">
        <name>EncapNeeded</name>
        <synopsis>Type of encapsulation needed on the packet</synopsis>
        <typeRef>LinkEncapType</typeRef>
      </component>
    </struct>
  </dataTypeDef>
  <dataTypeDef>
    <name>IPv6PrefixTableEntry</name>
<!--XXX:Needs more discussion-->
    <synopsis>IPv6 prefix table entry</synopsis>
    <struct>
      <component componentID="1">
        <name>Prefix</name>
        <synopsis>IPv6 address prefix</synopsis>
        <typeRef>IPv6Prefix</typeRef>
      </component>
      <component componentID="2">
        <name>NexthopID</name>
        <synopsis>index to the nexthop table.</synopsis>
        <typeRef>uint32</typeRef>
      </component>
    </struct>
  </dataTypeDef>
  <dataTypeDef>
    <name>IPv6LPMClassiferStatisticsType</name>
<!--XXX:Needs more discussion-->
    <synopsis>statistics of IPv6LPMClassifier LFB</synopsis>
    <struct>
      <component componentID="1">
        <name>InRcvdPkts</name>
        <synopsis>The total number of input packets received from
               interfaces, including those received in error</synopsis>
        <typeRef>uint64</typeRef>
      </component>
      <component componentID="2">
        <name>FwdPkts</name>
        <synopsis>IPv4 packet forwarded by this LFB</synopsis>
        <typeRef>uint64</typeRef>
      </component>
      <component componentID="3">
        <name>NoRoutePkts</name>
        <synopsis>The number of IP datagrams discarded because no route
       could be found to transmit them to their destination.</synopsis>
        <typeRef>uint64</typeRef>
      </component>
      <component componentID="4">
        <name>InDeliverPkts</name>
        <synopsis>The total number of input datagrams successfully
         delivered to IP user-protocols (including ICMP).</synopsis>
        <typeRef>uint64</typeRef>
      </component>
    </struct>
  </dataTypeDef>
  <dataTypeDef>
    <name>IPv6ValidatorStatisticsType</name>
<!--XXX:Needs more discussion-->
    <synopsis>IPv6 validator LFB statistics type</synopsis>
    <struct>
      <component componentID="1">
        <name>badHeaderPkts</name>
        <synopsis>The total number of input datagrams with bad ip
                                                      header</synopsis>
        <typeRef>uint64</typeRef>
      </component>
      <component componentID="2">
        <name>badTotalLengthPkts</name>
        <synopsis>The total number of input datagrams with bad length
                                                            </synopsis>
        <typeRef>uint64</typeRef>
      </component>
      <component componentID="3">
        <name>badTTLPkts</name>
        <synopsis>The total number of input datagrams with bad TTL
                                                            </synopsis>
        <typeRef>uint64</typeRef>
      </component>
      <component componentID="4">
        <name>badChecksum</name>
        <synopsis>The total number of input datagrams with bad checksum
                                                            </synopsis>
        <typeRef>uint64</typeRef>
      </component>
    </struct>
  </dataTypeDef>
  <dataTypeDef>
    <name>NextHopFlagsType</name>
<!--XXX:Needs more discussion-->
    <synopsis>Flags to define different nexthop behaviors</synopsis>
    <atomic>
      <baseType>uint32</baseType>
      <specialValues>
        <specialValue value="0x00000001">
          <name>local</name>
          <synopsis>Packets match the nexthop entry with this flag are
                   delivered to the higher level protocols.</synopsis>
        </specialValue>
        <specialValue value="0x00000002">
          <name>drop</name>
          <synopsis>Packets match the nexthop entry with this flag are
                                             to be dropped.</synopsis>
        </specialValue>
        <specialValue value="0x00000004">
          <name>broadcast</name>
          <synopsis>The route associated with this nexthop is a
                                                  broadcast.</synopsis>
        </specialValue>
        <specialValue value="0x00000008">
          <name>multicast</name>
          <synopsis>The route associated with this nexthop is multicast
                                                            </synopsis>
        </specialValue>
      </specialValues>
    </atomic>
  </dataTypeDef>
  <dataTypeDef>
    <name>WeightTableEntryType</name>
<!--XXX:Needs more discussion-->
    <synopsis>Weight table for queues.</synopsis>
    <struct>
      <component componentID="1">
        <name>QueueID</name>
        <synopsis>queue id</synopsis>
        <typeRef>uint32</typeRef>
      </component>
      <component componentID="2">
        <name>weight</name>
        <synopsis>weight of the queue.</synopsis>
        <typeRef>uint32</typeRef>
      </component>
    </struct>
  </dataTypeDef>
  <dataTypeDef>
    <name>NbrState</name>
<!--XXX:Needs more discussion-->
    <synopsis>IPv6 neighbour entry resolution state.</synopsis>
    <atomic>
      <baseType>uchar</baseType>
      <specialValues>
        <specialValue value="0x01">
          <name>INCOMPLETE</name>
          <synopsis>Address resolution is being performed on the entry.
                Specifically, a Neighbor Solicitation has been sent to
                the solicited-node multicast address of the target,
                but the corresponding Neighbor Advertisement has not
                yet been received.</synopsis>
        </specialValue>
        <specialValue value="0x02">
          <name>REACHABLE</name>
          <synopsis>Positive confirmation was received within the last
            ReachableTime milliseconds that the forward path to the
            neighbor was functioning properly. While REACHABLE, no
            special action takes place as packets are sent.</synopsis>
        </specialValue>
        <specialValue value="0x03">
          <name>STALE</name>
          <synopsis>More than ReachableTime milliseconds have elapsed
                since the last positive confirmation was received that
                the forward path was functioning properly.  While
                stale, no action takes place until a packet is sent.
                The STALE state is entered upon receiving an
                unsolicited Neighbor Discovery message that updates
                the cached link-layer address.  Receipt of such a
                message does not confirm reachability, and entering
                the STALE state insures reachability is verified
                quickly if the entry is actually being used.  However,
                reachability is not actually verified until the entry
                is actually used.</synopsis>
        </specialValue>
        <specialValue value="0x04">
          <name>DELAY</name>
          <synopsis>More than ReachableTime milliseconds have elapsed
                since the last positive confirmation was received that
                the forward path was functioning properly, and a
                packet was sent within the last DELAY_FIRST_PROBE_TIME
                seconds.  If no reachability confirmation is received
                within DELAY_FIRST_PROBE_TIME seconds of entering the
                DELAY state, send a Neighbor Solicitation and change
                the state to PROBE.</synopsis>
        </specialValue>
        <specialValue value="0x05">
          <name>PROBE</name>
          <synopsis>A reachability confirmation is actively sought by
                retransmitting Neighbor Solicitations every
                RetransTimer milliseconds until a reachability
                confirmation is received.</synopsis>
        </specialValue>
      </specialValues>
    </atomic>
  </dataTypeDef>
  <dataTypeDef>
    <name>ArpTableEntryType</name>
<!--XXX:Needs more discussion-->
    <synopsis>Arp entry.</synopsis>
    <struct>
      <component componentID="1">
        <name>Index</name>
        <synopsis>Index of the arp table.</synopsis>
        <typeRef>uint32</typeRef>
      </component>
      <component componentID="2">
        <name>NeighborIP</name>
        <synopsis>IP address of the neighbour.</synopsis>
        <typeRef>IPv4Addr</typeRef>
      </component>
      <component componentID="3">
        <name>SrcMac</name>
        <synopsis>Source MAC.</synopsis>
        <typeRef>IEEEMAC</typeRef>
      </component>
      <component componentID="4">
        <name>NeighborMac</name>
        <synopsis>Mac of the Neighbor.</synopsis>
        <typeRef>IEEEMAC</typeRef>
      </component>
      <component componentID="5">
        <name>State</name>
        <synopsis>State of the address resolution progress.</synopsis>
        <typeRef>ArpStateType</typeRef>
      </component>
    </struct>
  </dataTypeDef>
  <dataTypeDef>
    <name>NbrTableEntryType</name>
<!--XXX:Needs more discussion-->
    <synopsis>IPv6 neighbour table entry.</synopsis>
    <struct>
      <component componentID="1">
        <name>Index</name>
        <synopsis>Index of the arp table.</synopsis>
        <typeRef>uint32</typeRef>
      </component>
      <component componentID="2">
        <name>NeighborIPv6</name>
        <synopsis>IP address of the neighbour.</synopsis>
        <typeRef>IPv6Addr</typeRef>
      </component>
      <component componentID="3">
        <name>SrcMac</name>
        <synopsis>Source MAC.</synopsis>
        <typeRef>IEEEMAC</typeRef>
      </component>
      <component componentID="4">
        <name>NeighborMac</name>
        <synopsis>Mac of the Neighbor.</synopsis>
        <typeRef>IEEEMAC</typeRef>
      </component>
      <component componentID="5">
        <name>State</name>
        <synopsis>State of the entry's resolution progress.</synopsis>
        <typeRef>NbrState</typeRef>
      </component>
    </struct>
  </dataTypeDef>
  <dataTypeDef>
    <name>DCHostTableEntryTypev4</name>
<!--XXX:Needs more discussion-->
    <synopsis>Direct connected arp table entry for IPv4.</synopsis>
    <struct>
      <component componentID="1">
        <name>NeighbourIP</name>
        <synopsis>IP address of the neighbour.</synopsis>
        <typeRef>IPv4Addr</typeRef>
      </component>
      <component componentID="2">
        <name>SrcMac</name>
        <synopsis>Source MAC.</synopsis>
        <typeRef>IEEEMAC</typeRef>
      </component>
      <component componentID="3">
        <name>NeighborMac</name>
        <synopsis>Mac of the Neighbor.</synopsis>
        <typeRef>IEEEMAC</typeRef>
      </component>
    </struct>
  </dataTypeDef>
  <dataTypeDef>
    <name>DCHostTableEntryTypev6</name>
<!--XXX:Needs more discussion-->
    <synopsis>Direct connected arp table entry for IPv6.</synopsis>
    <struct>
      <component componentID="1">
        <name>NeighbourIPv6</name>
        <synopsis>IP address of the neighbour.</synopsis>
        <typeRef>IPv6Addr</typeRef>
      </component>
      <component componentID="2">
        <name>SrcMac</name>
        <synopsis>Source MAC.</synopsis>
        <typeRef>IEEEMAC</typeRef>
      </component>
      <component componentID="3">
        <name>NeighborMac</name>
        <synopsis>Mac of the Neighbor.</synopsis>
        <typeRef>IEEEMAC</typeRef>
      </component>
    </struct>
  </dataTypeDef>
  <dataTypeDef>
    <name>IPPacketType</name>
<!--XXX:Needs more discussion-->
    <synopsis>The packet type code.</synopsis>
    <atomic>
      <baseType>uchar</baseType>
      <specialValues>
        <specialValue value="1">
          <name>IPv4Ucast</name>
          <synopsis>IPv4 unicast packet.</synopsis>
        </specialValue>
        <specialValue value="2">
          <name>IPv4Mcast</name>
          <synopsis>IPv4 multicast packet.</synopsis>
        </specialValue>
        <specialValue value="3">
          <name>IPv6Ucast</name>
          <synopsis>IPv6 unicast packet.</synopsis>
        </specialValue>
        <specialValue value="4">
          <name>IPv6Mcast</name>
          <synopsis>IPv6 multicast packet.</synopsis>
        </specialValue>
      </specialValues>
    </atomic>
  </dataTypeDef>
  <dataTypeDef>
    <name>IPDispatchTableType</name>
<!--XXX:Needs more discussion-->
    <synopsis>The dispatch table type.</synopsis>
    <struct>
      <component componentID="1">
        <name>IPPacketType</name>
        <synopsis>The type of the packet.IPv4Uncast,IPv6Ucast,
                                IPv4Mulcast,IPv6Mulcast etc.</synopsis>
        <typeRef>IPPacketType</typeRef>
      </component>
      <component componentID="2">
        <name>index</name>
        <synopsis>The index of the output group to output the packets
                                                            </synopsis>
        <typeRef>uint32</typeRef>
      </component>
    </struct>
  </dataTypeDef>
  <dataTypeDef>
    <name>MetaType</name>
    <synopsis>Metadata type definition.</synopsis>
    <struct>
      <component componentID="1">
        <name>MetadataID</name>
        <synopsis>The ID of the metadata,the value is standardalized in
                      the corresponding LFB definition RFCs.</synopsis>
        <typeRef>uint32</typeRef>
      </component>
      <component componentID="2">
        <name>MetadataName</name>
        <synopsis>The name of the metadata.</synopsis>
        <typeRef>String</typeRef>
      </component>
    </struct>
  </dataTypeDef>
  <dataTypeDef>
    <name>MetadataClassTableType</name>
<!--XXX:Needs more discussion-->
    <synopsis>The meta data classifying table.</synopsis>
    <struct>
      <component componentID="1">
        <name>value</name>
        <synopsis>Value of the meta data.</synopsis>
        <typeRef>uint32</typeRef>
      </component>
      <component componentID="2">
        <name>index</name>
        <synopsis>The index of the port in the output group to use for
                                      outputing the packets.</synopsis>
        <typeRef>uint32</typeRef>
      </component>
    </struct>
  </dataTypeDef>
  <dataTypeDef>
    <name>LinkEncapType</name>
<!--XXX:Needs more discussion-->
    <synopsis>Encapsulation type.</synopsis>
    <atomic>
      <baseType>uchar</baseType>
      <specialValues>
        <specialValue value="1">
          <name>Link</name>
          <synopsis>Link layer encapsulation such as Ethernet and PPP.
                                                            </synopsis>
        </specialValue>
        <specialValue value="2">
          <name>InterFE</name>
          <synopsis>Inter FE communication encapsulation.</synopsis>
        </specialValue>
        <specialValue value="3">
          <name>Tunnel</name>
          <synopsis>Tunnel encapsulation such as IP-in-IP.</synopsis>
        </specialValue>
      </specialValues>
    </atomic>
  </dataTypeDef>
  <dataTypeDef>
    <name>IPAddress</name>
<!--XXX:Do we need a union of IPAddressess?-->
    <synopsis>IP layer address.</synopsis>
    <union>
      <component componentID="1">
        <name>Ipv4</name>
        <synopsis>IPv4 address.</synopsis>
        <typeRef>IPv4Addr</typeRef>
      </component>
      <component componentID="2">
        <name>Ipv6</name>
        <synopsis>IPv6 address.</synopsis>
        <typeRef>IPv6Addr</typeRef>
      </component>
    </union>
  </dataTypeDef>
  <dataTypeDef>
    <name>ArpStateType</name>
<!--XXX:Needs more discussion-->
    <synopsis>The arp entry state.</synopsis>
    <atomic>
      <baseType>uchar</baseType>
      <specialValues>
        <specialValue value="1">
          <name>Manual</name>
          <synopsis>The entry is manually set.</synopsis>
        </specialValue>
        <specialValue value="2">
          <name>InSolicit</name>
          <synopsis>The peer's level 2 address is still in requesting.
                                                            </synopsis>
        </specialValue>
        <specialValue value="4">
          <name>Valid</name>
          <synopsis>The address resolution have been completed
         successfully.Now it can be used in the data packets forwarding
                                                            </synopsis>
        </specialValue>
      </specialValues>
    </atomic>
  </dataTypeDef>
  <dataTypeDef>
   <name>MatchTargetType</name>
<!--XXX:Needs more discussion-->
    <synopsis>
       Indicator for the kind of field to be matched by this
       entry in a classifier.</synopsis>
    <atomic>
      <baseType>uchar</baseType>
      <specialValues>
        <specialValue value="0">
          <name>MatchNone</name>
          <synopsis>A matcher against no field</synopsis>
        </specialValue>
        <specialValue value="1">
          <name>MatchMetaData</name>
          <synopsis>A matcher against a metadata item</synopsis>
        </specialValue>
        <specialValue value="2">
          <name>MatchPacketField</name>
          <synopsis>A matcher that works against an identified packet
                                                      field.</synopsis>
        </specialValue>
        <specialValue value="3">
          <name>MatchOffsetLength</name>
          <synopsis>
             The match target is a specified portion of the packet.
          </synopsis>
        </specialValue>
      </specialValues>
    </atomic>
  </dataTypeDef>
  <dataTypeDef>
    <name>MatchTargetIdentifier</name>
<!--XXX:Needs more discussion-->
    <synopsis>
       Identify the specific target of a match condition.
    </synopsis>
    <union>
      <component componentID="1">
        <name>MetaDataID</name>
        <synopsis>The ID of a metadata item</synopsis>
        <typeRef>uint32</typeRef>
      </component>
      <component componentID="2">
        <name>packetFieldID</name>
        <synopsis>
           The identifier for a packet Field, such as SA, DA,
           Protocol, SPort, DPort, etc.  These identifiers allow
           references to fields with varialbe amounts before them.
        </synopsis>
        <typeRef>uint32</typeRef>
      </component>
      <component componentID="3">
        <name>OffSetLengthPacketField</name>
        <synopsis>
           A field in the packet identified by its offset and
           length in bits.  This does not allow for matching fields
           whose position depends upon earlier field sizes.
        </synopsis>
        <struct>
          <component componentID="1">
            <name>fieldOffset</name>
            <synopsis>The offset in bits from the start of the packet
                                  to the start of the field.</synopsis>
            <typeRef>uint32</typeRef>
          </component>
          <component componentID="2">
           <name>fieldLength</name>
            <synopsis>The length of the field, in bits</synopsis>
            <typeRef>uint32</typeRef>
          </component>
        </struct>
      </component>
    </union>
  </dataTypeDef>
  <dataTypeDef>
    <name>MatchBitString</name>
<!--XXX:Needs more discussion-->
    <synopsis>A bit string for use in a match condition.</synopsis>
    <struct>
      <component componentID="1">
        <name>MatchBits</name>
        <synopsis>The bits to match</synopsis>
        <typeRef>octetstring[16]</typeRef>
      </component>
      <component componentID="2">
        <name>MatchLength</name>
        <synopsis>The number of bits to match</synopsis>
        <typeRef>uchar</typeRef>
      </component>
    </struct>
  </dataTypeDef>
  <dataTypeDef>
<!--XXX:Needs more discussion-->
    <name>MatchCondition</name>
    <synopsis>Structure for a single condition to be applied</synopsis>
    <struct>
      <component componentID="1">
        <name>TargetType</name>
        <synopsis>The category of target to match</synopsis>
        <typeRef>MatchTargetType</typeRef>
      </component>
      <component componentID="2">
        <name>TargetID</name>
        <synopsis>The specific target to compare</synopsis>
        <typeRef>MatchTargetIdentifier</typeRef>
      </component>
      <component componentID="3">
        <name>MatchType</name>
        <synopsis>The kind of match to apply.</synopsis>
        <typeRef>MatchConditionType</typeRef>
      </component>
      <component componentID="4">
        <name>MatchParamOne</name>
        <synopsis>The first parameter for the match</synopsis>
        <optional/>
        <typeRef>MatchBitString</typeRef>
      </component>
      <component componentID="5">
        <name>MatchParamTwo</name>
        <synopsis>The second parameter for the match</synopsis>
        <optional/>
        <typeRef>MatchBitString</typeRef>
      </component>
    </struct>
  </dataTypeDef>
  <dataTypeDef>
    <name>MatchConditiontType</name>
<!--XXX:Needs more discussion-->
    <synopsis>
       Indicator for the kind of match condition to be applied.
    </synopsis>
    <atomic>
      <baseType>uchar</baseType>
      <specialValues>
        <specialValue value="0">
          <name>MatchNone</name>
          <synopsis>A matcher which always fails</synopsis>
        </specialValue>
        <specialValue value="1">
          <name>MatchExact</name>
          <synopsis>
             The target and the match value must be the same, with no
             padding. Only the first value of the match condition is
             used.  The first match value must be occur.
          </synopsis>
        </specialValue>
        <specialValue value="2">
          <name>MatchLeft</name>
          <synopsis>
             The target must begin with the first match value.
             If there is a second match value, the remainder of the
             target must match repeated occurrances of the second
             value.  Thus, this can be used to allow any terminal
             content, or specific ending pad. The first match value
             must occur.</synopsis>
        </specialValue>
        <specialValue value="3">
          <name>MatchRight</name>
          <synopsis>
             The target must end with the first match value.
             If there is a second match value, the preceding part
             of the target must match repeated occurrances of the
             second value.  Thus, this can be used to allow any
             leading content, or specific leading fill.  The first
             match value must occur.</synopsis>
        </specialValue>
        <specialValue value="4">
          <name>MatchRange</name>
          <synopsis>
             The match values will be considered as numbers, and
             the target must be greater than or equal to the
             first match value, and less than or equal to the
             second match value.  An omitted match value means
             that end of the range is unlimitted.</synopsis>
        </specialValue>
        <specialValue value="5">
          <name>MatchMaskedValue</name>
          <synopsis>
             The target the the first value are each anded with the
             second value.  The match succeeds if the results of these
             and operations are identical.  Both values are required.
          </synopsis>
        </specialValue>
        <specialValue value="6">
          <name>MatchSucceed</name>
          <synopsis>A Match which always succeeds</synopsis>
        </specialValue>
      </specialValues>
    </atomic>
  </dataTypeDef>
  <dataTypeDef>
<!--XXX:Needs more discussion-->
    <name>MatchMetaDataAction</name>
    <synopsis>
       An action to set a metadata item to either a specific value
       or a field from the incoming meta data or packet.</synopsis>
    <struct>
      <component componentID="1">
        <name>MetaDataToSet</name>
        <synopsis>The Meta Data Item to set</synopsis>
        <typeRef>uint32</typeRef>
      </component>
      <component componentID="2">
        <name>ExplicitValueToSet</name>
        <synopsis>A value to set the metadata to</synopsis>
        <optional/>
        <typeRef>octetstring[16]</typeRef>
      </component>
      <component componentID="3">
        <name>ValueFromCondition</name>
        <synopsis>
           This is an index into the corresponding match conditions,
           and the meta data will be set to the value that was tested
           by that condition.</synopsis>
        <optional/>
        <typeRef>uint32</typeRef>
      </component>
    </struct>
  </dataTypeDef>
  <dataTypeDef>
    <name>NextHopIndex</name>
    <synopsis>
       An index used by the next hop table.
       Typically stored in and generated as metadata by
       the longest-prefix-match LFB.</synopsis>
     <typeRef>int32</typeRef>
  </dataTypeDef>
</dataTypeDefs>


 TOC 

4.3.  MetaDataDefs

The following MetaData Types are defined:

  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.
  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. 

<metadataDefs>
  <metadataDef>
    <name>NextHopID</name>
    <synopsis>An index into a Next Hop entry in Nexthop table</synopsis>
    <metadataID>1</metadataID>
    <typeRef>NextHopIndex</typeRef>
 </metadataDef>
 <metadataDef>
   <name>ExceptionID</name>
<!--XXX:Needs more discussion. See that it applies to all LFBs.-->
    <synopsis>Exception Types</synopsis>
    <metadataID>2</metadataID>
    <atomic>
      <baseType>uint32</baseType>
      <specialValues>
        <specialValue value="0x00000001">
          <name>Options</name>
          <synopsis>Packets with options,for IPv6 Packet with
                    next-header set to hop-by-hop header(0).</synopsis>
        </specialValue>
        <specialValue value="0x00000002">
          <name>LengthMismatch</name>
          <synopsis>The packet length reported by link layer is less
                                than the total length field.</synopsis>
        </specialValue>
        <specialValue value="0x00000003">
          <name>BadTTL</name>
          <synopsis>The packet can't be forwarded as the TTL has
                                                    expired.</synopsis>
        </specialValue>
        <specialValue value="0x00000004">
          <name>Multicast</name>
          <synopsis>Packet received is a multicast packet.</synopsis>
        </specialValue>
        <specialValue value="0x00000005">
          <name>FragRequired</name>
          <synopsis>The MTU for outgoing interface is less than the
                                                packet size.</synopsis>
        </specialValue>
        <specialValue value="0x00000006">
          <name>Redirect</name>
          <synopsis>The outgoing port is same as the one on which the
                                         packet is received.</synopsis>
        </specialValue>
        <specialValue value="0x00000007">
          <name>LocalDelivery</name>
          <synopsis>The packet is for a local interface.</synopsis>
        </specialValue>
        <specialValue value="0x00000008">
          <name>LimitedBroadcast</name>
          <synopsis>The packet received as limited broadcast</synopsis>
        </specialValue>
      </specialValues>
    </atomic>
  </metadataDef>
  <metadataDef>
    <name>IngressPort</name>
    <synopsis>At which interface the packet arrive.</synopsis>
    <metadataID>3</metadataID>
    <typeRef>ifIndex</typeRef>
  </metadataDef>
  <metadataDef>
    <name>EgressPort</name>
    <synopsis>The interface out which the packet will emmit.</synopsis>
    <metadataID>4</metadataID>
    <typeRef>ifIndex</typeRef>
  </metadataDef>
  <metadataDef>
    <name>NextHopIP</name>
<!--XXX:Needs more discussion if this is metadata-->
    <synopsis>Nexthop IPv4 address</synopsis>
    <metadataID>5</metadataID>
    <typeRef>IP4Addr</typeRef>
  </metadataDef>
  <metadataDef>
    <name>NexthopIPv6</name>
<!--XXX:Needs more discussion if this is metadata-->
    <synopsis>Nexthop IPv6 address</synopsis>
    <metadataID>6</metadataID>
    <typeRef>IPv6Addr</typeRef>
  </metadataDef>
  <metadataDef>
    <name>PacketLength</name>
    <synopsis>The length of the packet in octets.</synopsis>
    <metadataID>7</metadataID>
    <typeRef>uint32</typeRef>
  </metadataDef>
  <metadataDef>
    <name>IPPacketType</name>
<!--XXX: Needs more discussion. Should match frameDefs.-->
    <synopsis>Type of the packet</synopsis>
    <metadataID>8</metadataID>
    <atomic>
      <baseType>uint32</baseType>
      <specialValues>
        <specialValue value="0x8000">
          <name>IPv4</name>
          <synopsis>IPv4 packet</synopsis>
        </specialValue>
        <specialValue value="0x86DD">
          <name>IPv6</name>
          <synopsis>IPv6 packet</synopsis>
        </specialValue>
        <specialValue value="3">
          <name>TaggedFrame</name>
          <synopsis>packet with metadata</synopsis>
        </specialValue>
        <specialValue value="4">
          <name>MetaDataFrame</name>
          <synopsis>meta data only</synopsis>
        </specialValue>
      </specialValues>
    </atomic>
  </metadataDef>
  <metadataDef>
    <name>QueueID</name>
<!--XXX:Needs more discussion-->
    <synopsis>The queue ID</synopsis>
    <metadataID>9</metadataID>
    <typeRef>uint32</typeRef>
  </metadataDef>
  <metadataDef>
    <name>QueueOperationCmd</name>
<!--XXX:Needs more discussion-->
    <synopsis>The type of operation on the queue,there are two types
                          defined here: enqueue and dequeue.</synopsis>
    <metadataID>10</metadataID>
    <atomic>
      <baseType>uchar</baseType>
      <specialValues>
        <specialValue value="1">
          <name>Enqueue</name>
          <synopsis>Enqueue command.</synopsis>
        </specialValue>
        <specialValue value="2">
          <name>Dequeue</name>
          <synopsis>Dequeue command.</synopsis>
        </specialValue>
      </specialValues>
    </atomic>
  </metadataDef>
  <metadataDef>
    <name>SrcFEID</name>
    <synopsis>Source FE ID.</synopsis>
    <metadataID>11</metadataID>
    <typeRef>uint32</typeRef>
  </metadataDef>
  <metadataDef>
     <name>DstFEID</name>
    <synopsis>Destination FE ID.</synopsis>
    <metadataID>12</metadataID>
    <typeRef>uint32</typeRef>
  </metadataDef>
  <metadataDef>
    <name>NexthopIndex</name>
<!--XXX:This should be removed-->
    <synopsis>Nexthop index into the link layer address resolution
                                                      table.</synopsis>
    <metadataID>13</metadataID>
    <typeRef>uint</typeRef>
  </metadataDef>
  <metadataDef>
    <name>NHEncapMethod</name>
<!--XXX: Is there any value in this?-->
    <synopsis>how should the following LFBs do to encapsulate the
    packets,such as link encapsulation which means the packets need to
    encapsulate link layer header before sending to media;inter FE
    communication encapsulation which means the packets need to first
    encapsulate inter FE communication header before transimiting to
    other FEs;tunnel encapsulation which means the packet need do extra
    tunnel encapsulation before sending out to media.</synopsis>
    <metadataID>14</metadataID>
    <typeRef>LinkEncapType</typeRef>
  </metadataDef>
  <metadataDef>
    <name>ErrorId</name>
<!--XXX:Needs more discussion-->
    <synopsis>Error Type.</synopsis>
    <metadataID>15</metadataID>
    <atomic>
      <baseType>int32</baseType>
      <specialValues>
        <specialValue value="0x00030001">
          <name>WrongIpVersion</name>
          <synopsis>the IP version wrong</synopsis>
        </specialValue>
        <specialValue value="0x00030002">
          <name>WrongLength</name>
          <synopsis>
               the packet length is not as long as
               the header indicates</synopsis>
        </specialValue>
        <specialValue value="0x000300FF">
          <name>otherError</name>
          <synopsis>The errors we not defined now</synopsis>
        </specialValue>
      </specialValues>
    </atomic>
  </metadataDef>
</metadataDefs>


 TOC 

5.  LFB Descriptions

As specified in section 3.1.2 the LFBs have been grouped together for better understanding. The following groups have been created

  1. Core LFBs, including FE Object LFB and FE Protocol LFB.
  2. Port LFBs. These LFBs are intended to provide media and encapsulation oriented capabilities associated with an interface. The interfaces may be between FEs inside NE or to the outside world. Allowing for the complicated features of different interface technology.
  3. Address LFBs. LFBs to model Addresses like IPv4, IPv6 addresses.
  4. Forwarding LFBs. LFBs to model the IPv4 and IPv6 forwarding function, e.g., IPv4Validor LFB, IPv4UcastLPM LFB, IPv4NextHopApplicator LFB, ARP LFB, ICMPProc LFB, OptionProc LFB, IPv6Validator LFB, IPv6UcastLPM LFB, ExtendHeaderProc LFB, IPv6NexthopApplicator LFB,IPv6AddrResolutionLFB LFB, ICMPv6Proc LFB.
  5. Queue manager and scheduler LFBs. LFB that model queues and schedulers. A basic queue LFB and scheduler LFB are defined. Queues and scheduler can be cascaded together to build more complicated schedulers.
  6. Miscellanious LFBs. LFBs that capture the functionality broadly used in FEs but are not part of any category, e.g., RedirectSink LFB, RedirectSource LFB, MetaClassifier LFB, GeneralClassifier LFB.


 TOC 

5.1.  Core LFBs

Currently there are only two core LFBs defined. These two LFBs are core LFBs for ForCES. It's required that each FE must implement these two LFBs for CE to control it.

  1. FEObjectLFB
  2. FEProtocolLFB


 TOC 

5.1.1.  FEObject LFB

The FEObject LFB is described in detail in the FE-MODEL (Halpern, J. and J. Salim, “ForCES Forwarding Element Model,” October 2008.) [I‑D.ietf‑forces‑model]. The reader is refered there for further detail.


 TOC 

5.1.2.  FEProtocol LFB

The FEProtocol LFB is described in detail in the FE-protocol (Dong, L., Doria, A., Gopal, R., HAAS, R., Salim, J., Khosravi, H., and W. Wang, “ForCES Protocol Specification,” March 2009.) [I‑D.ietf‑forces‑protocol]. The reader is refered there for further detail.


 TOC 

5.2.  Port LFBs

The Port LFBs that are defined in this library are:

  1. GenericConnectivityLFB
  2. EtherPort
  3. EtherDecap
  4. EtherEncap


 TOC 

5.2.1.  GenericConnectivityLFB

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.


 TOC 

5.2.2.  EtherPort

LFB for Ethernet ports


 TOC 

5.2.3.  EtherDecap

An LFB class for definition of Ethernet decapsulation and Ethernet filtering functions.


 TOC 

5.2.4.  EtherEncap

An LFB classifier definition for completes ethernet encapsulation fuctions.


 TOC 

5.3.  Address LFBs

The Address LFBs that are defined in this library are:

  1. IPv6AddrResolution
  2. Arp
  3. ICMPGenerator
  4. ICMPv6Generator
  5. IPv4Validator
  6. IPv6Validator


 TOC 

5.3.1.  IPv6AddrResolution

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.


 TOC 

5.3.2.  Arp

This LFB class provides the function of address resolution for IPv4 nodes.


 TOC 

5.3.3.  ICMPGenerator

This LFB class provide some basic ICMP function,it only generate the following ICMP messages:ICMP destination unreachable and time excceeded.


 TOC 

5.3.4.  ICMPv6Generator

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.


 TOC 

5.3.5.  IPv4Validator

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.


 TOC 

5.3.6.  IPv6Validator

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.


 TOC 

5.4.  Forwarding LFBs

The Forwarding LFBs that are defined in this library are:

  1. IPv4UcastLPM
  2. IPv4NextHopApplicator
  3. IPv6UcastLPM
  4. IPv6UcastNexthopApplicator


 TOC 

5.4.1.  IPv4UcastLPM

IPv4 Longest Prefix Match Lookup LFB


 TOC 

5.4.2.  IPv4NextHopApplicator

An LFB definition for applicating next hop action to IPv4 packets,the actions include:TTL operation,checksum recalculation.


 TOC 

5.4.3.  IPv6UcastLPM

An LFB class definition for IPv6 longest prefix lookup function.


 TOC 

5.4.4.  IPv6UcastNexthopApplicator

An LFB for applicating next hop action to IPv6 packets,actions mainly inlcude TTL incrementation and checksum recalculation.


 TOC 

5.5.  Queue and scheduler LFBs

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 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


 TOC 

5.5.1.  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.


 TOC 

5.5.2.  Queue

Queues have a packet input, a packet output, a control input, and a group of control outputs. The control ports represent the control relationships with scheduluers.


 TOC 

5.5.3.  WRRSched

Weighted round robin scheduler.


 TOC 

5.6.  Miscellanious LFBs

The Miscellanious LFBs that are defined in this library are:

  1. ExtendHeaderProc
  2. MetadataClassifier
  3. OptionProc
  4. RedirectLFB
  5. PacketTrimmer
  6. Duplicator
  7. ArbitraryClassifierLfb


 TOC 

5.6.1.  ExtendHeaderProc

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.


 TOC 

5.6.2.  MetadataClassifier

This LFB class provides the function of classify packets according to the meta data.Now it only works on one meta data.


 TOC 

5.6.3.  OptionProc

This LFB class process the IPv4 packet with options,it can process on the following options:Router-alert option.


 TOC 

5.6.4.  RedirectLFB

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.


 TOC 

5.6.5.  PacketTrimmer

LFB removes data from the front of a packet.


 TOC 

5.6.6.  Duplicator

An LFB Class definition for packet duplicator LFB. Any packet received on an input port is logically copied and sent to all output ports.


 TOC 

5.6.7.  ArbitraryClassifierLFB

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.


 TOC 

6.  LFB Library Definition

<?xml version="1.0" encoding="UTF-8"?>
<LFBLibrary provides="Library" 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">
  <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>IPv4Frame</name>
      <synopsis>An IPv4 packet</synopsis>
    </frameDef>
    <frameDef>
      <name>IPv6Frame</name>
      <synopsis>An IPv6 packet</synopsis>
    </frameDef>
    <frameDef>
      <name>taggedFrame</name>
      <synopsis>A frame of any type with associated metadata</synopsis>
    </frameDef>
    <frameDef>
      <name>MetadataFrame</name>
      <synopsis>Frame only contains meta data</synopsis>
    </frameDef>
    <frameDef>
      <name>Arbitrary</name>
      <synopsis>Any kind of frame except Metadata Frame.</synopsis>
    </frameDef>
  </frameDefs>
  <dataTypeDefs>
    <dataTypeDef>
      <name>ifIndex</name>
      <synopsis>A Port Identifier</synopsis>
      <typeRef>uint32</typeRef>
    </dataTypeDef>
    <dataTypeDef>
      <name>IEEEMAC</name>
      <synopsis>IEEE MAC Address</synopsis>
      <typeRef>byte[6]</typeRef>
    </dataTypeDef>
    <dataTypeDef>
      <name>NetSpeedType</name>
      <synopsis>Network speed values</synopsis>
      <atomic>
        <baseType>uint32</baseType>
        <specialValues>
          <specialValue value="0x00000001">
            <name>LAN_SPEED_10M</name>
            <synopsis>10M Ethernet</synopsis>
          </specialValue>
          <specialValue value="0x00000002">
            <name>LAN_SPEED_100M</name>
            <synopsis>100M Ethernet</synopsis>
          </specialValue>
          <specialValue value="0x00000003">
            <name>LAN_SPEED_1G</name>
            <synopsis>1000M Ethernet</synopsis>
          </specialValue>
          <specialValue value="0x00000004">
            <name>LAN_SPEED_10G</name>
            <synopsis>10G Ethernet</synopsis>
          </specialValue>
          <specialValue value="0x00000005">
            <name>LAN_SPEED_AUTO</name>
            <synopsis>LAN speed auto</synopsis>
          </specialValue>
        </specialValues>
        <!-- XXX: This doesnt look like the SNMP
  definitions. We should look at the SNMP
  definitions for guidance; we should not have
  limitations that SNMP has such as being
  restricted to 32 bits"
  "refer to RFC 3635 ifSpeed and ifHighSpeed"
-->
      </atomic>
    </dataTypeDef>
    <dataTypeDef>
      <name>IEEENegotiationType</name>
      <synopsis>IEEENegotiation types</synopsis>
      <atomic>
        <baseType>uint32</baseType>
        <specialValues>
          <specialValue value="0x00000001">
            <name>Auto</name>
            <synopsis>Auto negotitation.</synopsis>
          </specialValue>
          <specialValue value="0x00000002">
            <name>Half-duplex</name>
            <synopsis>port negotitation half duplex</synopsis>
          </specialValue>
          <specialValue value="0x00000003">
            <name>Full-duplex</name>
            <synopsis>port negotitation full duplex</synopsis>
          </specialValue>
        </specialValues>
      </atomic>
      <!-- XXX: This is very IEEE specific -->
    </dataTypeDef>
    <dataTypeDef>
      <name>PortStatsType</name>
      <synopsis>Port statistics</synopsis>
      <struct>
        <component componentID="1">
          <name>InUcastPkts</name>
          <synopsis>Number of unicast packets received</synopsis>
          <typeRef>uint64</typeRef>
        </component>
        <component componentID="2">
          <name>InMulticastPkts</name>
          <synopsis>Number of multicast packets received</synopsis>
          <typeRef>uint64</typeRef>
        </component>
        <component componentID="3">
          <name>InBroadcastPkts</name>
          <synopsis>Number of broadcast packets received</synopsis>
          <typeRef>uint64</typeRef>
        </component>
        <component componentID="4">
          <name>InOctets</name>
          <synopsis>number of octets received</synopsis>
          <typeRef>uint64</typeRef>
        </component>
        <component componentID="5">
          <name>OutUcastPkts</name>
          <synopsis>Number of unicast packets transmitted</synopsis>
          <typeRef>uint64</typeRef>
        </component>
        <component componentID="6">
          <name>OutMulticastPkts</name>
          <synopsis>Number of multicast packets transmitted</synopsis>
          <typeRef>uint64</typeRef>
        </component>
        <component componentID="7">
          <name>OutBroadcastPkts</name>
          <synopsis>Number of broadcast packets transmitted</synopsis>
          <typeRef>uint64</typeRef>
        </component>
        <component componentID="8">
          <name>OutOcetes</name>
          <synopsis>Number of octets transmitted</synopsis>
          <typeRef>uint64</typeRef>
        </component>
        <component componentID="9">
          <name>InErrorPkts</name>
          <synopsis>Number of input error packets</synopsis>
          <typeRef>uint64</typeRef>
        </component>
        <component componentID="10">
          <name>OutErrorPkts</name>
          <synopsis>Number of output error packets</synopsis>
          <typeRef>uint64</typeRef>
        </component>
      </struct>
      <!-- XXX: Make sure we validate with SNMP Port Stats -->
    </dataTypeDef>
    <dataTypeDef>
      <name>PortStatusValues</name>
      <synopsis>
              The possible values of status.  Used for both
              administrative and operation status
           </synopsis>
      <atomic>
        <baseType>uchar</baseType>
        <specialValues>
          <specialValue value="0">
            <name>Disabled </name>
            <synopsis>the port is operatively disabled.</synopsis>
          </specialValue>
          <specialValue value="1">
            <name>UP</name>
            <synopsis>the port is up.</synopsis>
          </specialValue>
          <specialValue value="2">
            <name>Down</name>
            <synopsis>The port is down.</synopsis>
          </specialValue>
        </specialValues>
<!--XXX:Need to conform with Administrative and operational status-->
      </atomic>
    </dataTypeDef>
    <dataTypeDef>
      <name>LocalIpAddrType</name>
      <synopsis>Local IP address belonging to FE.</synopsis>
      <struct>
        <component componentID="1">
          <name>FEID</name>
          <synopsis>The FE on which the port ip resides</synopsis>
          <typeRef>uint32</typeRef>
<!-- XXX: FEID is know to the Object LFB. Do we need it here? -->
        </component>
        <component componentID="2">
          <name>IfIndex</name>
          <synopsis>port index on the specified FE</synopsis>
          <typeRef>uint32</typeRef>
<!-- XXX: We need to support the model that says that a local IP has
multiple ports. Should this be an array of uint32 -->
        </component>
        <component componentID="3">
          <name>IPaddr</name>
          <synopsis>IP address of the port</synopsis>
          <typeRef>IPAddr</typeRef>
        </component>
        <component componentID="4">
          <name>netmask</name>
          <synopsis>netmask of this ip address</synopsis>
          <typeRef>IPAddr</typeRef>
        </component>
        <component componentID="5">
          <name>BcastAddr</name>
          <synopsis>The associated Broadcast address of the ip address
          </synopsis>
          <typeRef>IPAddr</typeRef>
        </component>
      </struct>
    </dataTypeDef>
    <dataTypeDef>
      <name>LocalIpv6AddrType</name>
      <synopsis>The device local IPv6 address infomation</synopsis>
      <struct>
        <component componentID="1">
          <name>FEID</name>
          <synopsis>The FE on which the port ip resides</synopsis>
          <typeRef>uint32</typeRef>
<!-- XXX: FEID is know to the Object LFB. Do we need it here? -->
        </component>
        <component componentID="2">
          <name>IfIndex</name>
          <synopsis>port index on the specified FE</synopsis>
          <typeRef>uint32</typeRef>
<!-- XXX: We need to support the model that says that a local IP has
multiple ports. Should this be an array of uint32 -->
        </component>
        <component componentID="3">
          <name>IPv6addr</name>
          <synopsis>IP address of the port</synopsis>
          <typeRef>IPv6Addr</typeRef>
        </component>
        <component componentID="4">
          <name>prefixlen</name>
          <synopsis>prefix length of this ip address</synopsis>
          <typeRef>uint32</typeRef>
        </component>
      </struct>
    </dataTypeDef>
    <dataTypeDef>
      <name>IPv4Addr</name>
      <synopsis>IPv4 address</synopsis>
      <typeRef>byte[4]</typeRef>
    </dataTypeDef>
    <dataTypeDef>
      <name>IPv6Addr</name>
      <synopsis>IPv6 address</synopsis>
      <typeRef>byte[16]</typeRef>
    </dataTypeDef>
    <dataTypeDef>
      <name>IPv4Prefix</name>
      <synopsis>IPv4 prefix defined by an address and a prefix length
      </synopsis>
      <struct>
        <component componentID="1">
          <name>address</name>
          <synopsis>Address part</synopsis>
          <typeRef>IPv4addr</typeRef>
        </component>
        <component componentID="2">
          <name>prefixlen</name>
          <synopsis>Prefix length part</synopsis>
          <atomic>
            <baseType>uchar</baseType>
            <rangeRestriction>
              <allowedRange min="0" max="32"/>
            </rangeRestriction>
          </atomic>
        </component>
      </struct>
    </dataTypeDef>
    <dataTypeDef>
      <name>IPv4NextHopInfoType </name>
      <!-- XXX: Needs more discussion -->
      <synopsis>IPv4 nexthop information,include nexthop ip address,
      output FE and interface etc.</synopsis>
      <struct>
        <component componentID="1">
          <name>NexthopID</name>
          <synopsis>nexthop id</synopsis>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="2">
          <name>FEID</name>
          <synopsis>output FE id</synopsis>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="3">
          <name>Egress</name>
          <synopsis>output port index</synopsis>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="4">
          <name>MTU</name>
          <synopsis>The maximum transmition unit of the nexthop link.
          </synopsis>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="5">
          <name> Flags </name>
          <synopsis>Associated flags of the nexthop,such as local
          delivery,multicast etc.</synopsis>
          <typeRef>NextHopFlagsType</typeRef>
        </component>
        <component componentID="6">
          <name> NexthopIPaddr </name>
          <synopsis>IP address of the nexthop</synopsis>
          <typeRef>IPv4Addr</typeRef>
        </component>
        <component componentID="7">
          <name> L2Index </name>
          <synopsis>index into the L2 link layer table,such as IPv4 ARP
          table or IPv6 NBR table.</synopsis>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="8">
          <name> EncapNeeded </name>
          <synopsis>The type of encapsulation needed on the packet.
          </synopsis>
          <typeRef>LinkEncapType</typeRef>
        </component>
      </struct>
    </dataTypeDef>
    <dataTypeDef>
      <name>IPv4FibEntryType</name>
      <!-- XXX: Needs more discussion -->
      <synopsis>IPv4 forwarding table entry.</synopsis>
      <struct>
        <component componentID="1">
          <name>prefix</name>
          <synopsis>IPv4 prefix.</synopsis>
          <typeRef>IPv4Prefix</typeRef>
        </component>
        <component componentID="2">
          <name>FEID</name>
          <synopsis>output FE id</synopsis>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="3">
          <name>Egress</name>
          <synopsis>output port index</synopsis>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="4">
          <name>MTU</name>
          <synopsis>The maximum transmition unit of the nexthop link.
          </synopsis>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="5">
          <name> Flags </name>
          <synopsis>Associated flags of the nexthop,such as local
          delivery,multicast etc.</synopsis>
          <typeRef>NextHopFlagsType</typeRef>
        </component>
        <component componentID="6">
          <name> NexthopIPaddr </name>
          <synopsis>IP address of the nexthop</synopsis>
          <typeRef>IPv4Addr</typeRef>
        </component>
        <component componentID="7">
          <name> L2Index </name>
          <synopsis>index into the L2 link layer table,such as IPv4 ARP
          table or IPv6 NBR table.</synopsis>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="8">
          <name> EncapNeeded </name>
          <synopsis>The type of encapsulation needed on the packet.
          </synopsis>
          <typeRef>LinkEncapType</typeRef>
        </component>
      </struct>
    </dataTypeDef>
    <dataTypeDef>
      <name>IPv4PrefixTableEntry</name>
      <!-- XXX: Needs more discussion -->
      <synopsis>IPv4 prefix table entry</synopsis>
      <struct>
        <component componentID="1">
          <name>Prefix</name>
          <synopsis>IPv4 address prefix</synopsis>
          <typeRef> IPv4Prefix </typeRef>
        </component>
        <component componentID="2">
          <name>NexthopID</name>
          <synopsis>Index into the nexthop table.</synopsis>
          <typeRef>uint32</typeRef>
        </component>
      </struct>
    </dataTypeDef>
    <dataTypeDef>
      <name>IPv4UcastLPMStatisticsType </name>
      <!-- XXX: Needs more discussion -->
      <synopsis>statistics of IPv4UcastLPM LFB</synopsis>
      <struct>
        <component componentID="1">
          <name>InRcvdPkts</name>
          <synopsis>The total number of input packets received from
          interfaces, including those received in error</synopsis>
          <typeRef>uint64</typeRef>
        </component>
        <component componentID="2">
          <name>FwdPkts</name>
          <synopsis>IPv4 packet forwarded by this LFB</synopsis>
          <typeRef>uint64</typeRef>
        </component>
        <component componentID="3">
          <name> NoRoutePkts </name>
          <synopsis>The number of IP datagrams discarded because no
          route could be found to transmit them to their destination.
          </synopsis>
          <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>
      <!-- XXX: Needs more discussion -->
      <synopsis>IPv4 validator LFB statistics type</synopsis>
      <struct>
        <component componentID="1">
          <name>badHeaderPkts</name>
          <synopsis>The total number of input datagrams with bad ip
          header</synopsis>
          <typeRef>uint64</typeRef>
        </component>
        <component componentID="2">
          <name>badTotalLengthPkts</name>
          <synopsis>The total number of input datagrams with bad length
          </synopsis>
          <typeRef>uint64</typeRef>
        </component>
        <component componentID="3">
          <name>badTTLPkts</name>
          <synopsis>The total number of input datagrams with bad TTL
          </synopsis>
          <typeRef>uint64</typeRef>
        </component>
        <component componentID="4">
          <name>badChecksum</name>
          <synopsis>The total number of input datagrams with bad
          checksum</synopsis>
          <typeRef>uint64</typeRef>
        </component>
      </struct>
    </dataTypeDef>
    <dataTypeDef>
      <name>IPv6Prefix</name>
      <synopsis>IPv6 prefix</synopsis>
      <struct>
        <component componentID="1">
          <name>IPv6addr</name>
          <synopsis>address part of the prefix</synopsis>
          <typeRef>IPv6Addr</typeRef>
        </component>
        <component componentID="2">
          <name>prefixlen</name>
          <synopsis>length of the prefix</synopsis>
          <typeRef>uint32</typeRef>
        </component>
      </struct>
    </dataTypeDef>
    <dataTypeDef>
      <name>IPv6NextHopInfoType</name>
      <!-- XXX: Needs more discussion -->
      <synopsis>IPv6 nexthop information,include nexthop ip address,
      output FE and interface etc.</synopsis>
      <struct>
        <component componentID="1">
          <name>NexthopID</name>
          <synopsis>nexthop id</synopsis>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="2">
          <name>FEID</name>
          <synopsis>output FE id</synopsis>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="3">
          <name>Egress</name>
          <synopsis>output port index</synopsis>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="4">
          <name>MTU</name>
          <synopsis>The maximum transmition unit of the nexthop link.
          </synopsis>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="5">
          <name> Flags </name>
          <synopsis>Associated flags of the nexthop,such as local
          delivery,multicast etc.</synopsis>
          <typeRef>NextHopFlagsType</typeRef>
        </component>
        <component componentID="6">
          <name> NexthopIPv6addr </name>
          <synopsis>IP address of the nexthop</synopsis>
          <typeRef>IPv6Addr</typeRef>
        </component>
        <component componentID="7">
          <name> L2Index </name>
          <synopsis>index into the L2 table</synopsis>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="8">
          <name> EncapNeeded </name>
          <synopsis>The type of encapsulation needed on the packet.
          </synopsis>
          <typeRef>LinkEncapType</typeRef>
        </component>
      </struct>
    </dataTypeDef>
    <dataTypeDef>
      <name>IPv6PrefixTableEntry</name>
      <!-- XXX: Needs more discussion -->
      <synopsis>IPv6 prefix table entry</synopsis>
      <struct>
        <component componentID="1">
          <name> Prefix </name>
          <synopsis>IPv6 address prefix</synopsis>
          <typeRef> IPv6Prefix </typeRef>
        </component>
        <component componentID="2">
          <name> NexthopID </name>
          <synopsis>index to the nexthop table.</synopsis>
          <typeRef>uint32</typeRef>
        </component>
      </struct>
    </dataTypeDef>
    <dataTypeDef>
      <name> IPv6LPMClassiferStatisticsType </name>
      <!-- XXX: Needs more discussion -->
      <synopsis>statistics of IPv6LPMClassifier LFB</synopsis>
      <struct>
        <component componentID="1">
          <name> InRcvdPkts </name>
          <synopsis>The total number of input packets received from
          interfaces, including those received in error</synopsis>
          <typeRef>uint64</typeRef>
        </component>
        <component componentID="2">
          <name> FwdPkts </name>
          <synopsis>IPv4 packet forwarded by this LFB</synopsis>
          <typeRef>uint64</typeRef>
        </component>
        <component componentID="3">
          <name> NoRoutePkts </name>
          <synopsis>The number of IP datagrams discarded because no
          route could be found to transmit them to their destination.
          </synopsis>
          <typeRef>uint64</typeRef>
        </component>
        <component componentID="4">
          <name>InDeliverPkts</name>
          <synopsis>The total number of input datagrams successfully
          delivered to IP user-protocols (including ICMP).</synopsis>
          <typeRef>uint64</typeRef>
        </component>
      </struct>
    </dataTypeDef>
    <dataTypeDef>
      <name> IPv6ValidatorStatisticsType </name>
      <!-- XXX: Needs more discussion -->
      <synopsis>IPv6 validator LFB statistics type</synopsis>
      <struct>
        <component componentID="1">
          <name> badHeaderPkts </name>
          <synopsis>The total number of input datagrams with bad ip
          header</synopsis>
          <typeRef>uint64</typeRef>
        </component>
        <component componentID="2">
          <name> badTotalLengthPkts </name>
          <synopsis>The total number of input datagrams with bad length
          </synopsis>
          <typeRef>uint64</typeRef>
        </component>
        <component componentID="3">
          <name> badTTLPkts </name>
          <synopsis>The total number of input datagrams with bad TTL
          </synopsis>
          <typeRef>uint64</typeRef>
        </component>
        <component componentID="4">
          <name> badChecksum</name>
          <synopsis>The total number of input datagrams with bad
          checksum</synopsis>
          <typeRef>uint64</typeRef>
        </component>
      </struct>
    </dataTypeDef>
    <dataTypeDef>
      <name> NextHopFlagsType </name>
      <!-- XXX: Needs more discussion -->
      <synopsis>Flags used to define different nexthop behaviors
      </synopsis>
      <atomic>
        <baseType>uint32</baseType>
        <specialValues>
          <specialValue value="0x00000001">
            <name>local</name>
            <synopsis>Packets match the nexthop entry with this flag
            are delivered to the higher level protocols.</synopsis>
          </specialValue>
          <specialValue value="0x00000002">
            <name>drop</name>
            <synopsis>Packets match the nexthop entry with this flag
            are to be dropped.</synopsis>
          </specialValue>
          <specialValue value="0x00000004">
            <name>broadcast</name>
            <synopsis>The route associated with this nexthop is a
            broadcast.</synopsis>
          </specialValue>
          <specialValue value="0x00000008">
            <name>multicast</name>
            <synopsis>The route associated with this nexthop is
            multicast.</synopsis>
          </specialValue>
        </specialValues>
      </atomic>
    </dataTypeDef>
    <dataTypeDef>
      <name>WeightTableEntryType</name>
      <!-- XXX: Needs more discussion -->
      <synopsis>Weight table for queues.</synopsis>
      <struct>
        <component componentID="1">
          <name>QueueID</name>
          <synopsis>queue id</synopsis>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="2">
          <name>weight</name>
          <synopsis>weight of the queue.</synopsis>
          <typeRef>uint32</typeRef>
        </component>
      </struct>
    </dataTypeDef>
    <dataTypeDef>
      <name>NbrState</name>
      <!-- XXX: Needs more discussion -->
      <synopsis>IPv6 neighbour entry resolution state.</synopsis>
      <atomic>
        <baseType>uchar</baseType>
        <specialValues>
          <specialValue value="0x01">
            <name>INCOMPLETE </name>
            <synopsis>Address resolution is being performed on entry.
            Specifically,a Neighbor Solicitation has been sent to the
            solicited-node multicast address of the target, but the
            corresponding Neighbor Advertisement has not yet been
            received.</synopsis>
          </specialValue>
          <specialValue value="0x02">
            <name>REACHABLE</name>
            <synopsis>Positive confirmation was received within the
            last reachableTime milliseconds that the forward path to
            the neighbor was functioning properly. While reachable, no
            special action takes place as packets are sent.</synopsis>
          </specialValue>
          <specialValue value="0x03">
            <name>STALE</name>
            <synopsis>More than ReachableTime milliseconds have elapsed
            since the last positive confirmation was received that the
            forward path was functioning properly. While STALE, no
            action takes place until a packet is sent. The STALE state
            is entered upon receiving an unsolicited Neighbor Discovery
            message that updates the cached link-layer address. Receipt
            of such a message does not confirm reachability, and
            entering the STALE state insures reachability is verified
            quickly if the entry is actually being used. However,
            reachability is not actually verified until the entry is
            actually used.</synopsis>
          </specialValue>
          <specialValue value="0x04">
            <name>DELAY</name>
            <synopsis>More than ReachableTime milliseconds have elapsed
            since the last positive confirmation was received that the
            forward path was functioning properly, and a packet was
            sent within the last DELAY_FIRST_PROBE_TIME seconds. If no
            reachability confirmation is received within
            DELAY_FIRST_PROBE_TIME seconds of entering the DELAY state,
            send a Neighbor Solicitation and change the state to PROBE.
            </synopsis>
          </specialValue>
          <specialValue value="0x05">
            <name>PROBE</name>
            <synopsis>A reachability confirmation is actively sought by
            retransmitting Neighbor Solicitations every RetransTimer
            milliseconds until a reachability confirmation is received.
            </synopsis>
          </specialValue>
        </specialValues>
      </atomic>
    </dataTypeDef>
    <dataTypeDef>
      <name>ArpTableEntryType</name>
      <!-- XXX: Needs more discussion -->
      <synopsis>Arp entry.</synopsis>
      <struct>
        <component componentID="1">
          <name>Index</name>
          <synopsis>Index of the arp table.</synopsis>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="2">
          <name>NeighborIP</name>
          <synopsis>IP address of the neighbour.</synopsis>
          <typeRef>IPv4Addr</typeRef>
        </component>
        <component componentID="3">
          <name>SrcMac</name>
          <synopsis>Source MAC.</synopsis>
          <typeRef>IEEEMAC</typeRef>
        </component>
        <component componentID="4">
          <name>NeighborMac</name>
          <synopsis>Mac of the Neighbor.</synopsis>
          <typeRef>IEEEMAC</typeRef>
        </component>
        <component componentID="5">
          <name>State</name>
          <synopsis>State of the address resolution progress</synopsis>
          <typeRef>ArpStateType</typeRef>
        </component>
      </struct>
    </dataTypeDef>
    <dataTypeDef>
      <name>NbrTableEntryType</name>
      <!-- XXX: Needs more discussion -->
      <synopsis>IPv6 neighbour table entry.</synopsis>
      <struct>
        <component componentID="1">
          <name>Index</name>
          <synopsis>Index of the arp table.</synopsis>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="2">
          <name>NeighborIPv6</name>
          <synopsis>IP address of the neighbour.</synopsis>
          <typeRef>IPv6Addr</typeRef>
        </component>
        <component componentID="3">
          <name>SrcMac</name>
          <synopsis>Source MAC.</synopsis>
          <typeRef>IEEEMAC</typeRef>
        </component>
        <component componentID="4">
          <name>NeighborMac</name>
          <synopsis>Mac of the Neighbor.</synopsis>
          <typeRef>IEEEMAC</typeRef>
        </component>
        <component componentID="5">
          <name>State</name>
          <synopsis>State of the entry's resolution progress</synopsis>
          <typeRef>NbrState</typeRef>
        </component>
      </struct>
    </dataTypeDef>
    <dataTypeDef>
      <name>DCHostTableEntryTypev4</name>
      <!-- XXX: Needs more discussion -->
      <synopsis>Direct connected arp table entry for IPv4. </synopsis>
      <struct>
        <component componentID="1">
          <name>NeighbourIP</name>
          <synopsis>IP address of the neighbour.</synopsis>
          <typeRef>IPv4Addr</typeRef>
        </component>
        <component componentID="2">
          <name>SrcMac</name>
          <synopsis>Source MAC.</synopsis>
          <typeRef>IEEEMAC</typeRef>
        </component>
        <component componentID="3">
          <name>NeighborMac</name>
          <synopsis>Mac of the Neighbor.</synopsis>
          <typeRef>IEEEMAC</typeRef>
        </component>
      </struct>
    </dataTypeDef>
    <dataTypeDef>
      <name>DCHostTableEntryTypev6</name>
      <!-- XXX: Needs more discussion -->
      <synopsis>Direct connected arp table entry for IPv6. </synopsis>
      <struct>
        <component componentID="1">
          <name>NeighbourIPv6</name>
          <synopsis>IP address of the neighbour.</synopsis>
          <typeRef>IPv6Addr</typeRef>
        </component>
        <component componentID="2">
          <name>SrcMac</name>
          <synopsis>Source MAC.</synopsis>
          <typeRef>IEEEMAC</typeRef>
        </component>
        <component componentID="3">
          <name>NeighborMac</name>
          <synopsis>Mac of the Neighbor.</synopsis>
          <typeRef>IEEEMAC</typeRef>
        </component>
      </struct>
    </dataTypeDef>
    <dataTypeDef>
      <name>IPPacketType</name>
      <!-- XXX: Needs more discussion -->
      <synopsis>The packet type code.</synopsis>
      <atomic>
        <baseType>uchar</baseType>
        <specialValues>
          <specialValue value="1">
            <name>IPv4Ucast</name>
            <synopsis>IPv4 unicast packet.</synopsis>
          </specialValue>
          <specialValue value="2">
            <name>IPv4Mcast</name>
            <synopsis>IPv4 multicast packet.</synopsis>
          </specialValue>
          <specialValue value="3">
            <name>IPv6Ucast</name>
            <synopsis>IPv6 unicast packet.</synopsis>
          </specialValue>
          <specialValue value="4">
            <name>IPv6Mcast</name>
            <synopsis>IPv6 multicast packet.</synopsis>
          </specialValue>
        </specialValues>
      </atomic>
    </dataTypeDef>
    <dataTypeDef>
      <name>IPDispatchTableType</name>
      <!-- XXX: Needs more discussion -->
      <synopsis>The dispatch table type.</synopsis>
      <struct>
        <component componentID="1">
          <name>IPPacketType</name>
          <synopsis>The type of the packet.IPv4Uncast,IPv6Ucast,
          IPv4Mulcast,IPv6Mulcast etc.</synopsis>
          <typeRef>IPPacketType</typeRef>
        </component>
        <component componentID="2">
          <name>index</name>
          <synopsis>The index of the output group to output the packets
          </synopsis>
          <typeRef>uint32</typeRef>
        </component>
      </struct>
    </dataTypeDef>
    <dataTypeDef>
      <name>MetaType</name>
      <synopsis>Metadata type definition.</synopsis>
      <struct>
        <component componentID="1">
          <name>MetadataID</name>
          <synopsis>The ID of the metadata,the value is standardalized
          in the corresponding LFB definition RFCs.</synopsis>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="2">
          <name>MetadataName</name>
          <synopsis>The name of the metadata.</synopsis>
          <typeRef>String</typeRef>
        </component>
      </struct>
    </dataTypeDef>
    <dataTypeDef>
      <name>MetadataClassTableType</name>
      <!-- XXX: Needs more discussion -->
      <synopsis>The meta data classifying table.</synopsis>
      <struct>
        <component componentID="1">
          <name>value</name>
          <synopsis>Value of the meta data.</synopsis>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="2">
          <name>index</name>
          <synopsis>The index of the port in the output group to use
          for outputing the packets.</synopsis>
          <typeRef>uint32</typeRef>
        </component>
      </struct>
    </dataTypeDef>
    <dataTypeDef>
      <name>LinkEncapType</name>
      <!-- XXX: Needs more discussion -->
      <synopsis>Encapsulation type.</synopsis>
      <atomic>
        <baseType>uchar</baseType>
        <specialValues>
          <specialValue value="1">
            <name>Link</name>
            <synopsis>Link layer encapsulation such as Ethernet and
            PPP.</synopsis>
          </specialValue>
          <specialValue value="2">
            <name>InterFE</name>
            <synopsis>Inter FE communication encapsulation.</synopsis>
          </specialValue>
          <specialValue value="3">
            <name>Tunnel</name>
            <synopsis>Tunnel encapsulation such as IP-in-IP.</synopsis>
          </specialValue>
        </specialValues>
      </atomic>
    </dataTypeDef>
    <dataTypeDef>
      <name>IPAddress</name>
      <!-- XXX: Do we need a union of IPAddressess?-->
      <synopsis>IP layer address.</synopsis>
      <union>
        <component componentID="1">
          <name>Ipv4</name>
          <synopsis>IPv4 address.</synopsis>
          <typeRef>IPv4Addr</typeRef>
        </component>
        <component componentID="2">
          <name>Ipv6</name>
          <synopsis>IPv6 address.</synopsis>
          <typeRef>IPv6Addr</typeRef>
        </component>
      </union>
    </dataTypeDef>
    <dataTypeDef>
      <name>ArpStateType</name>
      <!-- XXX: Needs more discussion -->
      <synopsis>The arp entry state.</synopsis>
      <atomic>
        <baseType>uchar</baseType>
        <specialValues>
          <specialValue value="1">
            <name>Manual</name>
            <synopsis>The entry is manually set.</synopsis>
          </specialValue>
          <specialValue value="2">
            <name>InSolicit</name>
            <synopsis>The peer's level 2 address is still in requesting
            </synopsis>
          </specialValue>
          <specialValue value="4">
            <name>Valid</name>
            <synopsis>The address resolution have been completed
            successfully,it now can be used in the data packets
            forwarding.</synopsis>
          </specialValue>
        </specialValues>
      </atomic>
    </dataTypeDef>
    <dataTypeDef>
      <name>MatchTargetType</name>
      <!-- XXX: Needs more discussion -->
      <synopsis>
         Indicator for the kind of field to be matched by this
         entry in a classifier.
       </synopsis>
      <atomic>
        <baseType>uchar</baseType>
        <specialValues>
          <specialValue value="0">
            <name>MatchNone</name>
            <synopsis>A matcher against no field</synopsis>
          </specialValue>
          <specialValue value="1">
            <name>MatchMetaData</name>
            <synopsis>A matcher against a metadata item</synopsis>
          </specialValue>
          <specialValue value="2">
            <name>MatchPacketField</name>
            <synopsis> A matcher that works against an identified
            packet field.</synopsis>
          </specialValue>
          <specialValue value="3">
            <name>MatchOffsetLength</name>
            <synopsis>The match target is a specified portion of the
            packet.</synopsis>
          </specialValue>
        </specialValues>
      </atomic>
    </dataTypeDef>
    <dataTypeDef>
      <name>MatchTargetIdentifier</name>
      <!-- XXX: Needs more discussion -->
      <synopsis>
         Identify the specific target of a match condition.
       </synopsis>
      <union>
        <component componentID="1">
          <name>MetaDataID</name>
          <synopsis>The ID of a metadata item</synopsis>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="2">
          <name>packetFieldID</name>
          <synopsis>The identifier for a packet Field, such as SA, DA,
          Protocol, SPort, DPort, etc.  These identifiers allow
          references to fields with varialbe amounts before them.
          </synopsis>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="3">
          <name>OffSetLengthPacketField</name>
          <synopsis>A field in the packet identified by its offset and
          length in bits.  This does not allow for matching fields
          whose position depends upon earlier field sizes.</synopsis>
          <struct>
            <component componentID="1">
              <name>fieldOffset</name>
              <synopsis>The offset in bits from the start of the packet
               to the start of the field.</synopsis>
              <typeRef>uint32</typeRef>
            </component>
            <component componentID="2">
              <name>fieldLength</name>
              <synopsis>The length of the field, in bits</synopsis>
              <typeRef>uint32</typeRef>
            </component>
          </struct>
        </component>
      </union>
    </dataTypeDef>
    <dataTypeDef>
      <name>MatchBitString</name>
      <!-- XXX: Needs more discussion -->
      <synopsis>A bit string for use in a match condition.</synopsis>
      <struct>
        <component componentID="1">
          <name>MatchBits</name>
          <synopsis>The bits to match</synopsis>
          <typeRef>octetstring[16]</typeRef>
        </component>
        <component componentID="2">
          <name>MatchLength</name>
          <synopsis>The number of bits to match</synopsis>
          <typeRef>uchar</typeRef>
        </component>
      </struct>
    </dataTypeDef>
    <dataTypeDef>
      <name>MatchCondition</name>
      <!-- XXX: Needs more discussion -->
      <synopsis>
         structure for a single condition to be applied.
       </synopsis>
      <struct>
        <component componentID="1">
          <name>TargetType</name>
          <synopsis>The category of target to match</synopsis>
          <typeRef>MatchTargetType</typeRef>
        </component>
        <component componentID="2">
          <name>TargetID</name>
          <synopsis>The specific target to compare</synopsis>
          <typeRef>MatchTargetIdentifier</typeRef>
        </component>
        <component componentID="3">
          <name>MatchType</name>
          <synopsis>The kind of match to apply.</synopsis>
          <typeRef>MatchConditionType</typeRef>
        </component>
        <component componentID="4">
          <name>MatchParamOne</name>
          <synopsis>The first parameter for the match</synopsis>
          <optional/>
          <typeRef>MatchBitString</typeRef>
        </component>
        <component componentID="5">
          <name>MatchParamTwo</name>
          <synopsis>The second parameter for the match</synopsis>
          <optional/>
          <typeRef>MatchBitString</typeRef>
        </component>
      </struct>
    </dataTypeDef>
    <dataTypeDef>
      <name>MatchConditiontType</name>
      <!-- XXX: Needs more discussion -->
      <synopsis>
         Indicator for the kind of match condition to be applied.
       </synopsis>
      <atomic>
        <baseType>uchar</baseType>
        <specialValues>
          <specialValue value="0">
            <name>MatchNone</name>
            <synopsis>A matcher which always fails</synopsis>
          </specialValue>
          <specialValue value="1">
            <name>MatchExact</name>
            <synopsis> The target and the match value must be the same,
             with no padding.Only the first value of the match condition
             is used. The first match value must be occur.</synopsis>
          </specialValue>
          <specialValue value="2">
            <name>MatchLeft</name>
            <synopsis>The target must begin with the first match value.
            If there is a second match value, the remainder of the
            target must match repeated occurrances of the second value.
            Thus, this can be used to allow any terminal content, or
            specific ending pad. The first match value must occur.
            </synopsis>
          </specialValue>
          <specialValue value="3">
            <name>MatchRight</name>
            <synopsis> The target must end with the first match value.
            If there is a second match value, the preceding part of the
            target must match repeated occurrances of the second value.
            Thus, this can be used to allow any leading content, or
            specific leading fill. The first match value must occur.
            </synopsis>
          </specialValue>
          <specialValue value="4">
            <name>MatchRange</name>
            <synopsis> The match values will be considered as numbers,
            and the target must be greater than or equal to the first
            match value, and less than or equal to the second match
            value. An omitted match value means that end of the range
            is unlimitted.</synopsis>
          </specialValue>
          <specialValue value="5">
            <name>MatchMaskedValue</name>
            <synopsis> The target the the first value are each anded
            with the second value. The match succeeds if the results of
            these and operations are identical. Both values are
            required.</synopsis>
          </specialValue>
          <specialValue value="6">
            <name>MatchSucceed</name>
            <synopsis>A Match which always succeeds</synopsis>
          </specialValue>
        </specialValues>
      </atomic>
    </dataTypeDef>
    <dataTypeDef>
      <name>MatchMetaDataAction</name>
      <!-- XXX: Needs more discussion -->
      <synopsis>An action to set a metadata item to either a specific
      value or a field from the incoming meta data or packet</synopsis>
      <struct>
        <component componentID="1">
          <name>MetaDataToSet</name>
          <synopsis>The Meta Data Item to set</synopsis>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="2">
          <name>ExplicitValueToSet</name>
          <synopsis>A value to set the metadata to</synopsis>
          <optional/>
          <typeRef>octetstring[16]</typeRef>
        </component>
        <component componentID="3">
          <name>ValueFromCondition</name>
          <synopsis> This is an index into the corresponding match
          conditions, and the meta data will be set to the value that
          was tested by that condition. </synopsis>
          <optional/>
          <typeRef>uint32</typeRef>
        </component>
      </struct>
    </dataTypeDef>
    <dataTypeDef>
      <name>NextHopIndex</name>
      <synopsis>An index used by the next hop table.Typically stored in
      and generated as metadata by the longest-prefix-match LFB
      </synopsis>
      <typeRef>int32</typeRef>
    </dataTypeDef>
  </dataTypeDefs>
  <metadataDefs>
    <metadataDef>
      <name>NextHopID</name>
      <synopsis>Index into a Next Hop entry in Nexthop table</synopsis>
      <metadataID>1</metadataID>
      <typeRef>NextHopIndex</typeRef>
    </metadataDef>
    <metadataDef>
      <name>ExceptionID</name>
<!-- XXX: Needs more discussion. See that it applies to all LFBs. -->
      <synopsis>Exception Types</synopsis>
      <metadataID>2</metadataID>
      <atomic>
        <baseType>uint32</baseType>
        <specialValues>
          <specialValue value="0x00000001">
            <name>Options</name>
            <synopsis>Packets with options,for IPv6 Packet with
            next-header set to hop-by-hop header(0).</synopsis>
          </specialValue>
          <specialValue value="0x00000002">
            <name>LengthMismatch</name>
            <synopsis>The packet length reported by link layer is less
            than the total length field.</synopsis>
          </specialValue>
          <specialValue value="0x00000003">
            <name> BadTTL </name>
            <synopsis>The packet can't be forwarded as the TTL has
            expired.</synopsis>
          </specialValue>
          <specialValue value="0x00000004">
            <name> Multicast </name>
            <synopsis>The packet received is a multicast packet.
            </synopsis>
          </specialValue>
          <specialValue value="0x00000005">
            <name>FragRequired</name>
            <synopsis>The MTU for outgoing interface is less than the
            packet size.</synopsis>
          </specialValue>
          <specialValue value="0x00000006">
            <name>Redirect</name>
            <synopsis>The outgoing port is same as the one on which the
            packet is received.</synopsis>
          </specialValue>
          <specialValue value="0x00000007">
            <name>LocalDelivery</name>
            <synopsis>The packet is for a local interface.</synopsis>
          </specialValue>
          <specialValue value="0x00000008">
            <name>LimitedBroadcast</name>
            <synopsis>Packet received as limited broadcast.</synopsis>
          </specialValue>
        </specialValues>
      </atomic>
    </metadataDef>
    <metadataDef>
      <name>IngressPort</name>
      <synopsis>At which interface the packet arrive.</synopsis>
      <metadataID>3</metadataID>
      <typeRef>ifIndex</typeRef>
    </metadataDef>
    <metadataDef>
      <name>EgressPort</name>
      <synopsis>Interface out which the packet will emmit.</synopsis>
      <metadataID>4</metadataID>
      <typeRef>ifIndex</typeRef>
    </metadataDef>
    <metadataDef>
      <name>NextHopIP</name>
      <!-- XXX: Needs more discussion if this is metadata-->
      <synopsis>Nexthop IPv4 address</synopsis>
      <metadataID>5</metadataID>
      <typeRef>IP4Addr </typeRef>
    </metadataDef>
    <metadataDef>
      <name>NexthopIPv6</name>
      <!-- XXX: Needs more discussion if this is metadata-->
      <synopsis>Nexthop IPv6 address</synopsis>
      <metadataID>6</metadataID>
      <typeRef>IPv6Addr</typeRef>
    </metadataDef>
    <metadataDef>
      <name>PacketLength</name>
      <synopsis>The length of the packet in octets.</synopsis>
      <metadataID>7</metadataID>
      <typeRef>uint32</typeRef>
    </metadataDef>
    <metadataDef>
      <name>IPPacketType </name>
      <!--XXX: Needs more discussion. Should match frameDefs.-->
      <synopsis>Type of the packet</synopsis>
      <metadataID>8</metadataID>
      <atomic>
        <baseType>uint32</baseType>
        <specialValues>
          <specialValue value="0x8000">
            <name> IPv4 </name>
            <synopsis>IPv4 packet</synopsis>
          </specialValue>
          <specialValue value="0x86DD">
            <name> IPv6 </name>
            <synopsis>IPv6 packet</synopsis>
          </specialValue>
          <specialValue value="3">
            <name> TaggedFrame </name>
            <synopsis>packet with metadata</synopsis>
          </specialValue>
          <specialValue value="4">
            <name> MetaDataFrame </name>
            <synopsis>meta data only</synopsis>
          </specialValue>
        </specialValues>
      </atomic>
    </metadataDef>
    <metadataDef>
      <name>QueueID </name>
      <!-- XXX: Needs more discussion -->
      <synopsis>The queue ID</synopsis>
      <metadataID>9</metadataID>
      <typeRef> uint32</typeRef>
    </metadataDef>
    <metadataDef>
      <name>QueueOperationCmd</name>
      <!-- XXX: Needs more discussion -->
      <synopsis>The type of operation on the queue,there are two types
      defined here: enqueue and dequeue.</synopsis>
      <metadataID>10</metadataID>
      <atomic>
        <baseType>uchar</baseType>
        <specialValues>
          <specialValue value="1">
            <name>Enqueue</name>
            <synopsis>Enqueue command.</synopsis>
          </specialValue>
          <specialValue value="2">
            <name>Dequeue</name>
            <synopsis>Dequeue command.</synopsis>
          </specialValue>
        </specialValues>
      </atomic>
    </metadataDef>
    <metadataDef>
      <name>SrcFEID</name>
      <synopsis>Source FE ID.</synopsis>
      <metadataID>11</metadataID>
      <typeRef>uint32</typeRef>
    </metadataDef>
    <metadataDef>
      <name>DstFEID</name>
      <synopsis>Destination FE ID.</synopsis>
      <metadataID>12</metadataID>
      <typeRef>uint32</typeRef>
    </metadataDef>
    <metadataDef>
      <name>NexthopIndex</name>
      <!-- XXX: This should be removed -->
      <synopsis>Nexthop index into the link layer address resolution
      table.</synopsis>
      <metadataID>13</metadataID>
      <typeRef>uint</typeRef>
    </metadataDef>
    <metadataDef>
      <name>NHEncapMethod</name>
      <!--XXX: Is there any value in this?-->
      <synopsis>how should the following LFBs do to encapsulate the
      packets,such as link encapsulation which means the packets need
      to encapsulate link layer header before sending to media;inter FE
      communication encapsulation which means the packets need to first
      encapsulate inter FE communication header before transimiting to
      other FEs;tunnel encapsulation which means the packet need do
      extra tunnel encapsulation before sending out to media</synopsis>
      <metadataID>14</metadataID>
      <typeRef>LinkEncapType</typeRef>
    </metadataDef>
    <metadataDef>
      <name>ErrorId</name>
      <!-- XXX: Needs more discussion -->
      <synopsis>Error Type.</synopsis>
      <metadataID>15</metadataID>
      <atomic>
        <baseType>int32</baseType>
        <specialValues>
          <specialValue value="0x00030001">
            <name>WrongIpVersion</name>
            <synopsis>the IP version wrong</synopsis>
          </specialValue>
          <specialValue value="0x00030002">
            <name>WrongLength</name>
            <synopsis>
                 the packet length is not as long as
                 the header indicates
               </synopsis>
          </specialValue>
          <specialValue value="0x000300FF">
            <name>otherError</name>
            <synopsis>The errors we not defined now</synopsis>
          </specialValue>
        </specialValues>
      </atomic>
    </metadataDef>
  </metadataDefs>
  <LFBClassDefs>
    <LFBClassDef LFBClassID="3">
      <name>EtherPort</name>
      <!--XXX:Should this be one LFB merged with the other Ether LFBs-->
      <synopsis>LFB for Ethernet ports</synopsis>
      <version>1.0</version>
      <derivedFrom>GenericConnectivityLFB</derivedFrom>
      <inputPorts>
        <inputPort>
          <name>PacketsFromProcessingUnit</name>
          <synopsis>Ports for receiving packets from processing unit
          such as NP,that will be sent to media.</synopsis>
          <expectation>
            <frameExpected>
              <ref>EthernetII</ref>
            </frameExpected>
            <metadataExpected>
              <ref>OutputPort</ref>
            </metadataExpected>
          </expectation>
        </inputPort>
        <inputPort>
          <name>PacketsFromMedia</name>
          <synopsis>Ports for receiving packets from ethernet media.
          </synopsis>
          <expectation>
            <frameExpected>
              <ref>EthernetII</ref>
            </frameExpected>
          </expectation>
        </inputPort>
      </inputPorts>
      <outputPorts>
        <outputPort>
          <name>PacketsToProcessingUnit</name>
          <synopsis>Ports for sending packets to processing unit such
          as NP for further processing.</synopsis>
          <product>
            <frameProduced>
              <ref>EthernetII</ref>
            </frameProduced>
            <metadataProduced>
              <ref>InputPort</ref>
            </metadataProduced>
          </product>
        </outputPort>
        <outputPort>
          <name>PacketsToMedia</name>
          <synopsis>Ports for sending packets to media.</synopsis>
          <product>
            <frameProduced>
              <ref>EthernetII</ref>
            </frameProduced>
          </product>
        </outputPort>
      </outputPorts>
      <components>
        <component componentID="1">
          <name>IfIndex</name>
          <synopsis>A unique value for each interface. Its value ranges
          between 1 and the value of total number of interfaces in the
          system. The value for each interface must remain constant at
          least from one re-initialization of the entity's network
          management system to the next re-initialization.</synopsis>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="2">
          <name>IfName</name>
          <synopsis>Name of this port</synopsis>
          <typeRef>string[16]</typeRef>
        </component>
        <component componentID="3">
          <name>LinkSpeed</name>
          <synopsis>Speed of this port</synopsis>
          <typeRef>NetSpeedType</typeRef>
        </component>
        <component componentID="4">
          <name>MTU</name>
          <synopsis>Maximum transmition unit</synopsis>
          <typeRef>uint32</typeRef>
        </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>IEEENegotiationType</typeRef>
          <defaultValue>"auto"</defaultValue>
        </component>
        <component componentID="10">
          <name>SrcNegotiationTypeMACAddr</name>
          <synopsis>source MAC</synopsis>
          <typeRef>IEEEMAC</typeRef>
        </component>
        <component componentID="11">
          <name>MacAliasTable</name>
          <synopsis>A series of MACs that the port can receive frame
          on.</synopsis>
          <array>
            <typeRef>IEEEMAC</typeRef>
          </array>
        </component>
        <component componentID="12">
          <name>StatsEnable</name>
          <synopsis>whether enable the statistics in this LFB.
          </synopsis>
          <optional/>
          <typeRef>booleanType</typeRef>
          <defaultValue>"no"</defaultValue>
        </component>
        <component componentID="13" access="read-reset">
          <name>PortStats</name>
          <synopsis>port statistics.</synopsis>
          <optional/>
          <typeRef>PortStatsType</typeRef>
        </component>
        <component componentID="14">
          <name>Ipaddr</name>
          <synopsis>IP layer Address.</synopsis>
          <typeRef>IPAddress</typeRef>
        </component>
      </components>
      <events baseID="100">
        <event eventID="1">
          <name>PortStatusChanged</name>
          <synopsis>Port status has changed since last time reporting.
          </synopsis>
          <eventTarget>
            <eventField>OperaStatus</eventField>
          </eventTarget>
          <eventChanged/>
          <eventReports>
            <eventReport>
              <eventField>OperaStatus</eventField>
            </eventReport>
          </eventReports>
        </event>
      </events>
    </LFBClassDef>
    <LFBClassDef LFBClassID="4">
      <name>EtherDecap</name>
      <!--XXX:Should this be merged with the EtherPort?-->
      <synopsis>An LFB class for definition of Ethernet decapsulation
      and Ethernet filtering functions</synopsis>
      <version>1.0</version>
      <derivedFrom>GenericConnectivityLFB</derivedFrom>
      <inputPorts>
        <inputPort>
          <name>PacketsIn</name>
          <synopsis>Packets from other LFB.</synopsis>
          <expectation>
            <frameExpected>
              <ref>EthernetII</ref>
            </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>IPDispatchTableType</typeRef>
        </component>
      </components>
    </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">Egress</ref>
              <ref availability="conditional">MTU</ref>
              <ref availability="conditional">Flags</ref>
              <ref availability="conditional">NexthopIPAddr</ref>
              <ref availability="conditional">NHEncapMethod</ref>
            </metadataProduced>
          </product>
        </outputPort>
        <outputPort>
          <name>ExceptionOut</name>
          <synopsis>Exception output</synopsis>
          <product>
            <frameProduced>
              <ref>IPv4</ref>
            </frameProduced>
            <metadataProduced>
              <ref>Ingress </ref>
              <ref>ExceptionID</ref>
            </metadataProduced>
          </product>
        </outputPort>
        <outputPort>
          <name>FailOutput</name>
          <synopsis>Dropper</synopsis>
          <product>
            <frameProduced>
              <ref> IPv4 </ref>
            </frameProduced>
          </product>
        </outputPort>
      </outputPorts>
      <components>
        <component componentID="1">
          <name> PrefixTable </name>
          <synopsis>IPv4 prefix table</synopsis>
          <array type="variable-size">
            <typeRef> IPv4PrefixTableEntry </typeRef>
            <contentKey contentKeyID="1">
              <contentKeyField>IPv4PrefixTableEntry.prefix
              </contentKeyField>
            </contentKey>
          </array>
        </component>
        <component componentID="2">
          <name>Fib</name>
          <synopsis>IPv4 unicast forwarding table.</synopsis>
          <optional/>
          <array type="variable-size">
            <typeRef>IPv4FibEntryType</typeRef>
            <contentKey contentKeyID="1">
              <contentKeyField>IPv4FibEntryType.prefix
              </contentKeyField>
            </contentKey>
          </array>
        </component>
        <component componentID="3">
          <name>LocalIpAddrTable</name>
          <synopsis>The table of interfaces's ip address infomation on
          the local device</synopsis>
          <typeRef>LocalIpAddrType</typeRef>
        </component>
        <component componentID="4">
          <name>IPv4Stats</name>
          <synopsis>The IPv4 associated statistics</synopsis>
          <optional/>
          <typeRef> IPv4UcastLPMStatisticsType </typeRef>
        </component>
      </components>
      <capabilities>
        <capability componentID="1">
          <name>PrefixTableLimit</name>
          <synopsis>maxium number of prefix supported by this LFB
          </synopsis>
          <typeRef>uint32</typeRef>
        </capability>
        <capability componentID="2">
          <name>LocalIpAddrTableLimit</name>
          <synopsis>maxium number of IP address entrys supported by
          this LFB</synopsis>
          <typeRef>uint32</typeRef>
        </capability>
      </capabilities>
      <description>This LFB represents the IPv4 longest prefix match
      lookup operation.</description>
    </LFBClassDef>
    <LFBClassDef LFBClassID="7">
      <name> IPv4NextHopApplicator </name>
      <synopsis>An LFB definition for applicating next hop action to
      IPv4 packets,the actions include:TTL operation,checksum
      recalculation.</synopsis>
      <version>1.0</version>
      <inputPorts>
        <inputPort>
          <name>PktIn</name>
          <synopsis>Port used to receive IPv4 packets from other LFBs
          </synopsis>
          <expectation>
            <frameExpected>
              <ref> IPv4 </ref>
            </frameExpected>
            <metadataExpected>
              <ref dependency="optional" defaultValue="0xff">NextHopID
              </ref>
              <ref dependency="optional" defaultValue="0xff">FEID</ref>
              <ref dependency="optional" defaultValue="0xff">Egress
              </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">
              NHEncapMethod</ref>
            </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>Egress</ref>
              <ref availability="conditional">L2Index</ref>
              <ref>NextHopIP</ref>
              <ref availability="conditional">NHEncapMethod</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>Ingress</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>
        <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="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>
          <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>
        </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
          nexthop application.</synopsis>
          <product>
            <frameProduced>
              <ref> IPv6 </ref>
            </frameProduced>
            <metadataProduced>
              <ref>FEID</ref>
              <ref>Egress</ref>
              <ref availability="conditional">L2Index</ref>
              <ref>NextHopIPv6</ref>
              <ref availability="conditional">NHEncapMethod</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>Ingress</ref>
              <ref>ExceptionID</ref>
            </metadataProduced>
          </product>
        </outputPort>
        <outputPort>
          <name>FailOutput</name>
          <synopsis>Output for packets failed the nexthop application
          operation.</synopsis>
          <product>
            <frameProduced>
              <ref> IPv6 </ref>
            </frameProduced>
          </product>
        </outputPort>
      </outputPorts>
      <components>
        <component componentID="1">
          <name> NextHopTable </name>
          <synopsis>Nexthop table</synopsis>
          <array type="variable-size">
            <typeRef> IPv6NextHopInfoType </typeRef>
          </array>
        </component>
      </components>
      <capabilities>
        <capability componentID="1">
          <name>NextHopTableLimit</name>
          <synopsis>Maxium number of nexthops this LFB supports
          </synopsis>
          <typeRef>uint32</typeRef>
        </capability>
      </capabilities>
    </LFBClassDef>
    <LFBClassDef LFBClassID="11">
      <name>EtherEncap</name>
      <!--XXX:Should this be merged with the EtherPort?-->
      <synopsis>An LFB classifier definition for completes ethernet
      encapsulation fuctions</synopsis>
      <version>1.0</version>
      <derivedFrom>GenericConnectivityLFB</derivedFrom>
      <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>IPPacketType</ref>
            </metadataExpected>
          </expectation>
        </inputPort>
      </inputPorts>
      <outputPorts>
        <outputPort>
          <name>SuccessOut</name>
          <synopsis/>
          <product>
            <frameProduced>
              <ref>EthernetII</ref>
            </frameProduced>
          </product>
        </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>
        <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>
        </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>
      <description>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.
                                                      </description>
    </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>
            <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>
      <description>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.
                                                         </description>
    </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
          resolution.</synopsis>
          <expectation>
            <frameExpected>
              <ref>IPv6</ref>
            </frameExpected>
          </expectation>
        </inputPort>
        <inputPort>
          <name>AddrResProtoPktIn</name>
          <synopsis>The neighbour discovery packet related to address
          resolution.</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>
      </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>
          <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 address
          resolution.</synopsis>
          <expectation>
            <frameExpected>
              <ref>IPv4</ref>
            </frameExpected>
          </expectation>
        </inputPort>
      </inputPorts>
      <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>IPv4 packet that need icmp processing.</synopsis>
          <expectation>
            <frameExpected>
              <ref>IPv4</ref>
            </frameExpected>
            <metadataExpected>
              <ref>ExceptionID</ref>
            </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>
<!-- XXX: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>Output group for the classified packets.</synopsis>
          <product>
            <frameProduced>
              <ref>Arbitrary</ref>
            </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>MetadataClassTableType</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>
            <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>
    <LFBClassDef LFBClassID="65537">
      <name>GenericConnectivityLFB</name>
      <synopsis>
           An LFB Class for providing connectivity between an FE and
           communications media.
         </synopsis>
      <version>1.0</version>
      <description>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.</description>
    </LFBClassDef>
    <LFBClassDef LFBClassID="65538">
      <name>RedirectLFB</name>
      <synopsis>An LFB Class definition for exchanging data packets
      between the FE and the CE.</synopsis>
      <version>1.0</version>
      <inputPorts>
        <inputPort>
          <name>RedirectToCE</name>
          <synopsis>
               Port for frames to send to the CE.
             </synopsis>
          <expectation>
            <frameExpected>
              <ref>taggedFrame</ref>
            </frameExpected>
          </expectation>
        </inputPort>
      </inputPorts>
      <outputPorts>
        <outputPort>
          <name>RedirectFromCE</name>
          <synopsis>
               Port for frames to send to the CE
             </synopsis>
          <product>
            <frameProduced>
              <ref>taggedFrame</ref>
            </frameProduced>
          </product>
        </outputPort>
      </outputPorts>
      <description>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</description>
    </LFBClassDef>
    <LFBClassDef LFBClassID="65539">
      <name>IPv4Validator</name>
      <synopsis>An LFB Class definition for validates the IPv4 packet.
      </synopsis>
      <version>1.0</version>
      <inputPorts>
        <inputPort>
          <name>ValidatorIn</name>
          <synopsis>
               Normal packet input.
             </synopsis>
          <expectation>
            <frameExpected>
              <ref>IPv4</ref>
            </frameExpected>
          </expectation>
        </inputPort>
      </inputPorts>
      <outputPorts>
        <outputPort>
          <name>ValidatorOut</name>
          <synopsis>
               Normal packet Output.
             </synopsis>
          <product>
            <frameProduced>
              <ref>IPv4packet</ref>
            </frameProduced>
          </product>
        </outputPort>
        <outputPort>
          <name>FailOutput</name>
          <synopsis>The port to send packets that do not match any
          entries.</synopsis>
          <product>
            <frameProduced>
              <ref>taggedFrame</ref>
            </frameProduced>
            <metadataProduced>
              <ref>errorid</ref>
            </metadataProduced>
          </product>
        </outputPort>
      </outputPorts>
      <description>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.</description>
    </LFBClassDef>
    <LFBClassDef LFBClassID="65540">
      <name>IPv6Validator</name>
      <synopsis>An LFB Class definition for validates the IPv6 packet.
      </synopsis>
      <version>1.0</version>
      <inputPorts>
        <inputPort>
          <name>ValidatorIn</name>
          <synopsis>
               Normal packet input.
             </synopsis>
          <expectation>
            <frameExpected>
              <ref>IPv6</ref>
            </frameExpected>
          </expectation>
        </inputPort>
      </inputPorts>
      <outputPorts>
        <outputPort>
          <name>ValidatorOut</name>
          <synopsis>
               Normal packet Output.
             </synopsis>
          <product>
            <frameProduced>
              <ref>IPv6packet</ref>
            </frameProduced>
          </product>
        </outputPort>
        <outputPort>
          <name>FailOutput</name>
          <synopsis>The port to send packets that do not match any
          entries.</synopsis>
          <product>
            <frameProduced>
              <ref>taggedFrame</ref>
            </frameProduced>
            <metadataProduced>
              <ref>errorid</ref>
            </metadataProduced>
          </product>
        </outputPort>
      </outputPorts>
      <description>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.</description>
    </LFBClassDef>
    <LFBClassDef LFBClassID="65541">
      <name>PacketTrimmer</name>
      <!--XXX:Needs further discussion-->
      <synopsis>LFB removes data from the front of a packet.</synopsis>
      <version>1.0</version>
      <inputPorts>
        <inputPort>
          <name>PacketIn</name>
          <synopsis>
               Normal packet input.
             </synopsis>
          <expectation>
            <frameExpected>
              <ref>Packet</ref>
            </frameExpected>
          </expectation>
        </inputPort>
      </inputPorts>
      <outputPorts>
        <outputPort>
          <name>PacketOut</name>
          <synopsis>
               Normal packet Output.
             </synopsis>
          <product>
            <frameProduced>
              <ref>Packet</ref>
            </frameProduced>
          </product>
        </outputPort>
        <outputPort>
          <name>FailOut</name>
          <synopsis>
               For packets without enough bytes to remove
             </synopsis>
          <product>
            <frameProduced>
              <ref>Packet</ref>
            </frameProduced>
          </product>
        </outputPort>
      </outputPorts>
      <components>
        <component componentID="1" access="read-write">
          <name>TrimLength</name>
          <synopsis>amount to trim from each packet</synopsis>
          <typeRef>uint32</typeRef>
        </component>
      </components>
    </LFBClassDef>
    <LFBClassDef LFBClassID="65543">
      <name>Duplicator</name>
      <!--XXX:Needs further discussion-->
      <synopsis>An LFB Class definition for packet duplicator LFB. Any
      packet received on an input port is logically copied and sent to
      all output ports.</synopsis>
      <version>1.0</version>
      <inputPorts>
        <inputPort>
          <name>PacketIn</name>
          <synopsis>
                  Normal packet input.
                </synopsis>
          <expectation>
            <frameExpected>
              <ref>IPv4</ref>
              <ref>IPv6</ref>
            </frameExpected>
          </expectation>
        </inputPort>
      </inputPorts>
      <outputPorts>
        <outputPort group="true">
          <name>PacketOut</name>
          <synopsis>Normal packet output port group</synopsis>
          <product>
            <frameProduced>
              <ref>IPv4</ref>
              <ref>IPv6</ref>
            </frameProduced>
          </product>
        </outputPort>
      </outputPorts>
    </LFBClassDef>
    <LFBClassDef LFBClassID="65544">
      <name>ArbitraryClassifierLFB</name>
      <!--XXX:Needs further discussion-->
      <synopsis>A classifier which can test packet or metadata, and on
      that basis set meta-data a pick an output port.</synopsis>
      <version>1.0</version>
      <inputPorts>
        <inputPort group="true">
          <name>PacketsToClassify</name>
          <synopsis>
               The group of ports to received packets over
             </synopsis>
          <expectation>
            <frameExpected>
              <ref>taggedFrame</ref>
            </frameExpected>
<!-- no metadataExpected item as any and all meta data is allowed -->
          </expectation>
        </inputPort>
      </inputPorts>
      <outputPorts>
        <outputPort group="true">
          <name>SuccessOutput</name>
          <synopsis>
               The group of ports used by the classifer for output
               when a successful match is found.
             </synopsis>
          <product>
            <frameProduced>
              <ref>taggedFrame</ref>
            </frameProduced>
            <!-- no metaDataProduced as anything can be produced -->
          </product>
        </outputPort>
        <outputPort group="false">
          <name>FailOutput</name>
          <synopsis>
               The port to send packets that do not match any entries.
             </synopsis>
          <product>
            <frameProduced>
              <ref>taggedFrame</ref>
            </frameProduced>
            <!-- no metaDataProduced as anything can be produced -->
          </product>
        </outputPort>
      </outputPorts>
      <components>
        <component componentID="1" access="read-write">
          <name>ClassifierTable</name>
          <synopsis>The table of classifier entries. Each entry is
          tested until one succeeds. Each entry contains an optional
          port test, an array of packet and meta data tests, an array
          of metadata actions, and an exit selection.</synopsis>
          <array type="variable-size">
            <struct>
              <component componentID="1">
                <name>InputPortTest</name>
                <synopsis>If present,this match will only match packets
                arriving over the specified port.</synopsis>
                <optional/>
                <typeRef>uint32</typeRef>
              </component>
              <component componentID="2">
                <name>TestConditions</name>
                <synopsis>The array of conditions to test</synopsis>
                <array type="variable-size">
                  <typeRef>MatchCondition</typeRef>
                </array>
              </component>
              <component componentID="3">
                <name>MetaDataActions</name>
                <synopsis>The array of meta data modifications to make
                when the match succeeds.</synopsis>
                <array type="variable-size">
                  <typeRef>MatchMetaDataAction</typeRef>
                </array>
              </component>
              <component componentID="4">
                <name>MatchOutputPort</name>
                <synopsis>The port within the success group to send
                packets which match these tests.</synopsis>
                <typeRef>uint32</typeRef>
              </component>
            </struct>
          </array>
        </component>
      </components>
    </LFBClassDef>
  </LFBClassDefs>
</LFBLibrary>


 TOC 

7.  LFB Use Case

Editorial:This section is supposed to discuss how we can build some basic applications define by WG charter such as IPV4 forwarding etc.

Putting together LFBs to form a specific packet processing application


 TOC 

8.  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


 TOC 

9.  Acknowledgements

This document is based on earlier documents from Joel Halpern, Ligang Dong, Fenggen Jia and Weiming Wang.


 TOC 

10.  IANA Considerations

This memo includes no request to IANA.


 TOC 

11.  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 (Dong, L., Doria, A., Gopal, R., HAAS, R., Salim, J., Khosravi, H., and W. Wang, “ForCES Protocol Specification,” March 2009.) [I‑D.ietf‑forces‑protocol].


 TOC 

12.  References


 TOC 

12.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 (TXT).
[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 (TXT).

 TOC 

12.2. Informative References

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC2629] Rose, M., “Writing I-Ds and RFCs using XML,” RFC 2629, June 1999 (TXT, HTML, XML).
[RFC3552] Rescorla, E. and B. Korver, “Guidelines for Writing RFC Text on Security Considerations,” BCP 72, RFC 3552, July 2003 (TXT).
[RFC3654] Khosravi, H. and T. Anderson, “Requirements for Separation of IP Control and Forwarding,” RFC 3654, November 2003 (TXT).
[RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, “Forwarding and Control Element Separation (ForCES) Framework,” RFC 3746, April 2004 (TXT).
[RFC5226] Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” BCP 26, RFC 5226, May 2008 (TXT).

 TOC 

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