Internet Engineering Task Force                                  W. Wang
Internet-Draft                             Zhejiang Gongshang University
Intended status: Informational                             E. Haleplidis
Expires: December 31, 2009 September 4, 2010                          University of Patras
                                                                K. Ogawa
                                                         NTT Corporation
                                                                  F. Jia
                                              National Digital Switching
                                                            Center(NDSC)
                                                              J. Halpern
                                                                Ericsson
                                                           June 29, 2009
                                                           March 3, 2010

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

Abstract

   The forwarding and Control Element Separation (ForCES) protocol
   defines a standard communication and control mechanism through which
   a Control Element (CE) can control the behavior of a Forwarding
   Element (FE).  That control is accomplished through manipulating
   components of Logical Function Blocks (LFBs), whose structure is
   defined in a model RFC produced by the working group.In order to
   build an actual solution using this protocol, there needs to be a set
   of Logical Function Block definitions that can be instantiated by FEs
   and controlled by CEs.  This document provides a sample space of such
   definitions.  It is anticipated that additional defining documents
   will be produced over time.

Status of this Memo

   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 December 31, 2009. September 4, 2010.

Copyright Notice

   Copyright (c) 2009 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info). document.  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  Code Components extracted from 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 must
   include Simplified BSD License text as described in Section 4.e of such
   definitions.  It is anticipated that additional defining documents
   will be produced over time.
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.

Table of Contents

   1.  Terminology and Conventions  . . . . . . . . . . . . . . . . .   5  4
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .   5  4
   2.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .   6  5
   3.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .   8
   4.  Base Definitions  . .  7
   4.  Overview . . . . . . . . . . . . . . . . . . . .  10
     4.1.  Framedefs . . . . . . .  8
   5.  Base Types . . . . . . . . . . . . . . . . .  10
     4.2.  DataTypeDefs . . . . . . . . . 11
     5.1.  Data Types . . . . . . . . . . . . .  11
     4.3.  MetaDataDefs . . . . . . . . . . . . . . . . . . . . . .  38
   5.  LFB Descriptions  . . . . . . . . . . 11
     5.2.  Frame Types  . . . . . . . . . . . .  44
     5.1.  Core LFBs . . . . . . . . . . . 13
     5.3.  MetaData Types . . . . . . . . . . . . .  44
       5.1.1.  FEObject LFB . . . . . . . . . 14
     5.4.  XML Definition for Base Type Library . . . . . . . . . . .  44
       5.1.2.  FEProtocol 15
   6.  LFB Classes Description  . . . . . . . . . . . . . . . . . . .  45
     5.2.  Port 39
     6.1.  Core LFBs  . . . . . . . . . . . . . . . . . . . . . . . .  45
       5.2.1.  GenericConnectivityLFB  . 39
       6.1.1.  FE Protocol LFB  . . . . . . . . . . . . . .  45
       5.2.2.  EtherPort . . . . . 39
       6.1.2.  FE Object LFB  . . . . . . . . . . . . . . . . .  45
       5.2.3.  EtherDecap . . . 39
     6.2.  Port LFBs  . . . . . . . . . . . . . . . . . .  46
       5.2.4.  EtherEncap . . . . . . 40
       6.2.1.  Generic Connectivity LFB . . . . . . . . . . . . . . .  46
     5.3.  Address 40
       6.2.2.  Ethernet Port LFBs . . . . . . . . . . . . . . . . . . . . . .  46
       5.3.1.  IPv6AddrResolution  . . . 41
       6.2.3.  POS Port LFBs  . . . . . . . . . . . . . .  46
       5.3.2.  Arp . . . . . . 41
       6.2.4.  ATM Port LFBs  . . . . . . . . . . . . . . . . . . .  46
       5.3.3.  ICMPGenerator . 41
     6.3.  Address Resolution LFBs  . . . . . . . . . . . . . . . . . 41
     6.4.  ICMP LFBs  . .  46
       5.3.4.  ICMPv6Generator . . . . . . . . . . . . . . . . . . .  46
       5.3.5.  IPv4Validator . . . 42
     6.5.  IP Packet Validation LFBs  . . . . . . . . . . . . . . . . 42
     6.6.  Classifier LFBs  .  47
       5.3.6.  IPv6Validator . . . . . . . . . . . . . . . . . . . .  47
     5.4. 42
     6.7.  Forwarding LFBs  . . . . . . . . . . . . . . . . . . . . .  47
       5.4.1.  IPv4UcastLPM  . . . . . . . . . . . . . . . . . . . .  47
       5.4.2.  IPv4NextHopApplicator . . . . . . . . . . . . . . . .  47
       5.4.3.  IPv6UcastLPM  . . . 43
       6.7.1.  Unicast Longest Prefix Match LFBs  . . . . . . . . . . 43
       6.7.2.  Nexthop Applicator LFBs  . . . . . . .  47
       5.4.4.  IPv6UcastNexthopApplicator . . . . . . . . 43
     6.8.  QoS Control LFBs . . . . .  47
     5.5.  Queue and scheduler LFBs . . . . . . . . . . . . . . . .  48
       5.5.1. 43
       6.8.1.  Scheduler LFBs . . . . . . . . . . . . . . . . . . . . . .  48
       5.5.2. 44
       6.8.2.  Queue LFBs . . . . . . . . . . . . . . . . . . . . . . . .  49
       5.5.3.  WRRSched  . . . . . . . . . . . . . . . . . . . . . .  49
     5.6.  Miscellanious 45
     6.9.  Miscellaneous Packet Manipulation LFBs . . . . . . . . . . 45
     6.10. Redirect LFB . . . . . . . . .  49
       5.6.1.  ExtendHeaderProc  . . . . . . . . . . . . . . . . . 45
   7.  XML Definition for Base LFB Library  .  49
       5.6.2.  MetadataClassifier . . . . . . . . . . . . 46
   8.  Base LFB Library Use Case for Typical Router Functions . . . . 75
     8.1.  IP Forwardings .  49
       5.6.3.  OptionProc . . . . . . . . . . . . . . . . . . . . .  49
       5.6.4.  RedirectLFB 75
     8.2.  Address Resolution . . . . . . . . . . . . . . . . . . . . 76
     8.3.  ICMP .  50
       5.6.5.  PacketTrimmer . . . . . . . . . . . . . . . . . . . .  50
       5.6.6.  Duplicator . . . . . . 76
     8.4.  Running Routing Protocol . . . . . . . . . . . . . . .  50
       5.6.7.  ArbitraryClassifierLFB . . 76
     8.5.  Network Management . . . . . . . . . . . . .  50
   6.  LFB Library Definition . . . . . . . 76
   9.  Contributors . . . . . . . . . . . .  51
   7.  LFB Use Case . . . . . . . . . . . . . 77
   10. Acknowledgements . . . . . . . . . . . 112
   8.  Contributors . . . . . . . . . . . . 78
   11. IANA Considerations  . . . . . . . . . . . . 113
   9.  Acknowledgements . . . . . . . . . 79
   12. Security Considerations  . . . . . . . . . . . . . 114
   10. IANA Considerations . . . . . . 80
   13. References . . . . . . . . . . . . . . . 115
   11. Security Considerations . . . . . . . . . . . 81
     13.1. Normative References . . . . . . . . 116
   12. References . . . . . . . . . . . 81
     13.2. Informative References . . . . . . . . . . . . . . 117
     12.1. Normative References . . . . 81
   Authors' Addresses . . . . . . . . . . . . . . 117
     12.2. Informative References . . . . . . . . . . . . . . . . . 117
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 118 82

1.  Terminology and Conventions

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Definitions

   This document follows the terminology defined by the ForCES
   Requirements in [RFC3654]and by the ForCES framework in [RFC3746].
   The definitions below are repeated below for clarity.

      Control Element (CE) - A logical entity that implements the ForCES
      protocol and uses it to instruct one or more FEs on how to process
      packets.  CEs handle functionality such as the execution of
      control and signaling protocols.

      Forwarding Element (FE) - A logical entity that implements the
      ForCES protocol.  FEs use the underlying hardware to provide per-
      packet processing and handling as directed/controlled by one or
      more CEs via the ForCES protocol.

      ForCES Network Element (NE) - An entity composed of one or more
      CEs and one or more FEs.  To entities outside an NE, the NE
      represents a single point of management.  Similarly, an NE usually
      hides its internal organization from external entities.

      LFB (Logical Function Block) - The basic building block that is
      operated on by the ForCES protocol.  The LFB is a well defined,
      logically separable functional block that resides in an FE and is
      controlled by the CE via ForCES protocol.  The LFB may reside at
      the FE's datapath and process packets or may be purely an FE
      control or configuration entity that is operated on by the CE.
      Note that the LFB is a functionally accurate abstraction of the
      FE's processing capabilities, but not a hardware-accurate
      representation of the FE implementation.

      FE Topology - A representation of how the multiple FEs within a
      single NE are interconnected.  Sometimes this is called inter-FE
      topology, to be distinguished from intra-FE topology (i.e., LFB
      topology).

      LFB Class and LFB Instance - LFBs are categorized by LFB Classes.
      An LFB Instance represents an LFB Class (or Type) existence.
      There may be multiple instances of the same LFB Class (or Type) in
      an FE.  An LFB Class is represented by an LFB Class ID, and an LFB
      Instance is represented by an LFB Instance ID.  As a result, an
      LFB Class ID associated with an LFB Instance ID uniquely specifies
      an LFB existence.

      LFB Metadata - Metadata is used to communicate per-packet state
      from one LFB to another, but is not sent across the network.  The
      FE model defines how such metadata is identified, produced and
      consumed by the LFBs.  It defines the functionality but not how
      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.

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]has defined
   the ForCES requirements, and [RFC3746] has defined the ForCES
   framework.

   The ForCES protocol Protocol FE-protocol FE-protocol
   [I-D.ietf-forces-protocol] defines a protocol by which for communications
   between Control Elements (CEs) communicated with
   and control the behavior of Forwarding Elements (FEs).  That control
   is expressed (FEs) and for
   Control Elements to manipulate resources in terms of manipulations of components Forwarding Elements.
   Resources in Forwarding Elements are described by classes of Logical
   Function Blocks (LFBs).  The FE model documentFE-MODEL
   [I-D.ietf-forces-model]. specifies the structure and abstract
   semantics of LFBs
   is defined in Model FE-MODEL [I-D.ietf-forces-model].  That document
   also defines a single LFB Class LFBs, and provides XML schema for gaining access to FE properties
   including the set definitions of LFBs and their interconnection.  The Protocol
   LFBs.

   This document defines an LFB class for manipulating comforts to the protocol
   properties specifications of the FE.

   In order for the protocol to be useful to control any behavior, there
   must be a set of LFB class FE modelFE-MODEL
   [I-D.ietf-forces-model] and specifies definitions for the of classes of LFBs
   which provide
   that behavior.  This document provides a set of such definitions.
   This document is intended can be combined to provide an initial LFB library. functions of a typical router.  It is
   expected that other
   basically provides functions to implement IP forwarding.  More
   definitions will of LFB classes with more functions may be developed over time, in
   future time and documented in other RFCs.

   An by IETF, and users may also develop
   individual LFB performs a well-defined action or computation on the packets
   passing through it.  Upon completion classes for purposes of its prescribed function,
   either their specific functions
   according to the packets are modified FE modelFE-MODEL [I-D.ietf-forces-model].

4.  Overview

   The LFB classes described in certain ways (e.g., decapsulator,
   marker), or some results this document are generated and stored, often in designed to provide
   the form functions 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 typical router [RFC1812] .  They 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 expected to
   provide functions for a typical router to:

   o  Interface to packet networks and its associated metadata.  The
   LFB processes implement the input, and produces one or more outputs, each of
   which is a pair of a packet functions required
      by that network.  These functions typically include:

      *  Encapsulating and its associated metadata.

   For further information regarding decapsulating the LFB model, IP datagrams with the reader is
   referenced
         connected network framing (e.g., an Ethernet header and
         checksum),

      *  Sending and receiving IP datagrams up to FE-MODEL [I-D.ietf-forces-model].

   XXX: The above text the maximum size
         supported by that network, this size is redundant.  The definition gives some intro the network's Maximum
         Transmission Unit or MTU,

      *  Translating the IP destination address into an appropriate
         network-level address for the connected network (e.g., an
         Ethernet hardware address), if needed, and.

      *  Responding to
   LFBs network flow control and error indications, if
         any.

   o  Conform to specific Internet protocols including the model Internet
      Protocol (IPv4 and/or IPv6), Internet Control Message Protocol
      (ICMP), and all the other docs before this tell us what an
   LFB is

   In others as necessary.

   o  Receive and forwards Internet datagrams.  Important issues in this document we first define base structures used
      process are buffer management, congestion control, and fairness.

      *  Recognizes error conditions and generates ICMP error and
         information messages as required.

      *  Drops datagrams whose time-to-live fields have reached zero.

      *  Fragments datagrams when necessary to fit into the MTU of the
         next network.

   o  Choose a next-hop destination for each IP datagram, based on the
      information in building its routing database.

   o  Usually support an interior gateway protocol (IGP) to carry out
      distributed routing and reachability algorithms with the
   LFBs other
      routers in section 4 then use those base definitions the same autonomous system.  In addition, some routers
      will need to define various
   LFBs.

   To simplify support an exterior gateway protocol (EGP) to
      exchange topological information with other autonomous systems.

   o  Provide network management and system support facilities,
      including loading, debugging, status reporting, exception
      reporting and control.

   According to ForCES architecture, all above typical router functions
   should be implemented upon the understanding concept of these LFBs - we have chosen Logical Functional Blocks
   (LFBs).  It is critical to group
   them by functionality.  The following groups classify above functional requirements
   into various classes 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.

4.  Base Definitions

   This section povides construct a typical but also
   flexible enough base set of LFB frame, data type, and meta
   data definitions library for use various IP forwarding
   equipments.  In the process, some principles may be applied:

   o  if a function can be designed by all any either one LFB Class definitions (in this or two or more
      LFBs with the same cost, it will be designed by two or more LFBs
      so as to provide more flexibility for implementers.

   o  when flexibility is not required, an LFB should take advantage of
      its as much as possible independence and leave least couples with
      other documents.  This section provides no actual LFBs.  The couples may be from LFB Class
   definitions.

   These are then used attributes definitions as
      well as physical implementations.

   o  unless there is a difference in each subsequent definition by actual functionality, it should
      not represent the statement:

   <load library="Base"/>

4.1.  Framedefs same thing in two different fashions.  Or else,
      it may add extra burden on implementation.

   The following Frames document intends to meet the above typical router function
   requirements by defining groups of LFB classes like Core LFBs,Port
   LFBs,etc.

   For every group of LFB classes, a set of LFBs are defined:

   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 defined for
   individual function purposes.  Section 6(LFB Descriptions Section)
   describes individual LFBs in every group of any type with associated metadata.

   8.  MetadataFrame - Frame only contains meta data.

   9.  Arbitrary - Any kind LFBs in details.

   Based on the classes 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 LFBs, the typical organization of frame except Metadata Frame.</synopsis>
    </frameDef>
  </frameDefs>

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 - the
   processing path and their interconnections can be established by the
   CE using the ForCES protocol, so as to achieve typical router
   functions.  Taking a typical forwarding function as an example, Port statistics.

   6.   PortStatusValues - The possible values of status Used for both
        administrative
   LFBs receive packets and operation status.

   7.   LocalIpAddrType - Local decapsulate the IP address belonging datagrams to FE.

   8.   LocalIpv6AddrType - The device local IPv6 address infomation.

   9.   IPv4Addr - form IP
   level packets.  Different port media have different manipulating
   requirements from CE, therefore various port LFBs for various media
   may have to be defined.  IP packets from port LFBs are then validated
   before being further forwarded.  A kind of valildation LFBs like IPv4 address.

   10.  IPv6Addr -
   validator and/or IPv6 address.

   11.  IPv4Prefix - IPv4 prefix defined valildator are applied for the purpose.  After
   validation, some packets for control purpose will be specifically
   processed, like ARP packets will be processed by an address Address
   resolution LFB and ICMP packets by an ICMP LFB.  To separate the
   control packets, 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 metadata classifier LFB statistics
        type.

   17.  IPv6Prefix - IPv6 prefix defined by an address and is applied in the process.
   After validation process, Forwarding LFBs can then be applied.  In
   the Forwarding LFBs, 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 Longest Prefix Match LFB statistics
        type.

   22.  NextHopFlagsType - Flags is 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 look up
   the kind of field to be matched
        by this entry destination information in a classifier.

   37.  MatchTargetIdentifier - Identify packet, and select 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 next hop
   index to be applied.

   40.  MatchConditiontType - Indicator used for sending the kind of match condition packet onward.  A next hop
   applicator LFB uses the next hop index metadata to be applied.

   41.  MatchMetaDataAction - An action apply the proper
   headers to set the IP packets, and direct them to the proper egress.

   Section 8 provides more detailed descriptions on how various typical
   router functions are implemented based on the defined base LFB
   classes.

   To define various LFB classes, a set of base type definitions with
   the data types, packet frame types, and metadata item types have to either
        a specific value or be
   specified in advance.  Section 5 (Base Types Section) provide a field from
   description on the incoming meta data or
        packet.

   42.  NextHopIndex - An index base types used by this LFB library.  In order to
   provide an extensive use of these base types for other LFB
   definitions, the next hop table Typically
        stored in and generated as metadata base type definitions are provided by a specific xml
   file as a base type library which is separate from 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 LFB definition
   library.

   LFB classes are finally defined by XML with specifications and schema
   from the SNMP
   definitions. We should look at ForCES FE modelFE-MODEL [I-D.ietf-forces-model].  Section 6
   (LFB Definitions Section) provide the SNMP complete XML definitions for guidance; we should not have
   limitations that SNMP of the
   base LFB classes library.

5.  Base Types

   The FE modelFE-MODEL [I-D.ietf-forces-model] has such specified the
   following data types as being
   restricted to 32 bits"
   "refer to RFC 3635 ifSpeed predefined (built-in) atomic data-types:

   char, uchar, int16, uint16, int32, uint32, int64, uint64, string[N],
   string, byte[N], boolean, octetstring[N], float16, float32, float64.

   Based on these atomic data types and 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 with the use of broadcast packets transmitted</synopsis>
         <typeRef>uint64</typeRef>
       </component>
       <component componentID="8">
         <name>OutOcetes</name>
         <synopsis>Number type definition
   elements in the FE model XML schema, new data types, packet frame
   types, and metadata types can further be defined.

   To define a base LFB library for typical router functions, a base
   data types, frame types, and metadata types MUST be defined.  This
   section provides a description of octets transmitted</synopsis>
         <typeRef>uint64</typeRef>
       </component>
       <component componentID="9">
         <name>InErrorPkts</name>
         <synopsis>Number these types and a detailed XML
   definitions of input error packets</synopsis>
         <typeRef>uint64</typeRef>
       </component>
       <component componentID="10">
         <name>OutErrorPkts</name>
         <synopsis>Number the base types.

   In order for extensive use of output error packets</synopsis>
         <typeRef>uint64</typeRef>
       </component>
     </struct>
 <!--XXX:Make sure we validate the base type definitions for other LFB
   definitions than this base LFB library, the base type definitions are
   provided with a separate xml library file labeled with SNMP
   "BaseTypeLibrary".  Users can refer to this library by the statement:

   <load library="BaseTypeLibrary", location="..."/>

5.1.  Data Types

   The following data types are currently defined and put in the base
   type library:

   1.   ifIndex - A Port Stats-->
   </dataTypeDef>
   <dataTypeDef>
     <name>PortStatusValues</name>
     <synopsis> 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. 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 status.

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

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

   9.   IPv4Addr - IPv4 address.

   10.  IPv6Addr - IPv6 address.

   11.  IPv4Prefix - 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
        length.

   12.  IPv4NextHopInfoType - IPv4 nexthop information,include nexthop
        ip address,
                                 output 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 etc.

   13.  IPv4FibEntryType - 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 entry.

   14.  IPv4PrefixTableEntry - 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 entry.

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

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

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

5.1.1.  FEObject LFB

   The FEObject LFB is described in detail in the FE-MODEL
   [I-D.ietf-forces-model].  The reader is refered there for further
   detail.

5.1.2.  FEProtocol LFB

   The FEProtocol LFB is described in detail in the FE-protocol
   [I-D.ietf-forces-protocol].  The reader is refered there for further
   detail.

5.2.  Port LFBs

   The Port LFBs that are defined in this library are:

   1.  GenericConnectivityLFB

   2.  EtherPort

   3.  EtherDecap

   4.  EtherEncap

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.

5.2.2.  EtherPort

   LFB for Ethernet ports

5.2.3.  EtherDecap

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

5.2.4.  EtherEncap

   An LFB classifier definition for completes ethernet encapsulation
   fuctions.

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

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.

5.3.2.  Arp

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

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.

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.

5.3.5.  IPv4Validator

   An LFB Class definition for validates the LFB.

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

5.3.6.  IPv6Validator

   An validator LFB Class definition for validates the statistics
        type.

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

5.4.  Forwarding LFBs

   The Forwarding LFBs that are prefix defined in this library are:

   1.  IPv4UcastLPM

   2.  IPv4NextHopApplicator

   3.  IPv6UcastLPM

   4.  IPv6UcastNexthopApplicator

5.4.1.  IPv4UcastLPM

   IPv4 Longest Prefix Match Lookup LFB

5.4.2.  IPv4NextHopApplicator

   An LFB definition for applicating by an address and a prefix
        length.

   18.  IPv6NextHopInfoType - IPv6 next hop action to IPv4 packets,the
   actions include:TTL operation,checksum recalculation.

5.4.3.  IPv6UcastLPM

   An LFB class definition for information, include next
        hop ip address,output FE and interfac eetc.

   19.  IPv6PrefixTableEntry - IPv6 longest prefix lookup function.

5.4.4.  IPv6UcastNexthopApplicator

   An table entry.

   20.  IPv6LPMClassiferStatisticsType - Statistics of IPv6 LPM
        ClassifierLFB.

   21.  IPv6ValidatorStatisticsType - IPv6 validator LFB for applicating statistics
        type.

   22.  NextHopFlagsType - Flags used to define different next hop action to
        behaviors.

   23.  WeightTableEntryType - Weight table for queues.

   24.  NbrState - IPv6 packets,actions mainly
   inlcude TTL incrementation and checksum recalculation.

5.5.  Queue and scheduler LFBs

   To build an actual forwarder, one must include some limited 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 of
   queueing and scheduling.  Queues are entities which store packets.
   Schedulers are entities which react to the state kind of queues and cause
   packets field to be emitted from queues.

   The actual interaction between queues and schedulers (and their real
   world degree matched
        by this entry in a classifier.

   37.  MatchTargetIdentifier - Identify the specific target of separation) is quite complex.  A very complex LFB
   model would be required a match
        condition.

   38.  MatchBitString - A bit string for use in a match condition.

   39.  MatchCondition - Structure for a single condition to represent all the complexity.
   Additionally, there is be applied.

   40.  MatchConditiontType - Indicator for the issue kind of representing match condition
        to be applied.

   41.  MatchMetaDataAction - An action to set a metadata item to either
        a specific value or a field from the relationship
   between incoming meta data or
        packet.

   42.  NextHopIndex - An index used by the queue next hop table Typically
        stored in and generated as metadata by the scheduler.  A simple approach has been
   taken longest-prefix-match
        LFB.

5.2.  Frame Types

   According to FE modelFE-MODEL [I-D.ietf-forces-model], frame types
   are used in these class definitions.

   A queue element consists LFB definitions to define the types of an frames the LFB
   expects at its input port (called InData) on which it
   receives data packets, port(s) and output port (called OutData) on which it
   will send packets when permitted by emits at its definition or output port(s).  The
   <frameDef> element in the scheduler.
   Its relationship to scheduluers FE model is represented by used to define a set of output
   ports (the group OutCountrol) and an input port (called InControl).
   These ports new frame
   type.

   The following frame types are currently defined to carry packets consisting and put in the base
   type library as base frame types for the LFB library:

   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 of meta- contains meta data.  In fact, these ports are an abstraction, and what one might
   call a legal fiction.  An element

   9.  Arbitrary - Any kind of the OutControl group represents
   the fact that a scheduler frame except Metadata Frame.

5.3.  MetaData Types

   LFB Metadata is aware of the used to communicate per-packet state of that queue
   element. from one LFB to
   another.  The InControl port represents <metadataDef> element in the fact that one or more
   schedulers connected FE model is used to that port define
   a new metadata type.

   The following metadata types are controlling that queue.  There
   is no meta-data currently 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 put in the
   base type library as base metadata types for the simple case of a controller who monitors
   and controls LFB library
   definitions:

   1.   NextHopID - An index into a single set 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 queues, and more interesting cases where the control packet in octets.

   8.   IPPacketType - Type of certain queues may depend upon the state packet.

   9.   QueueID - The queue ID.

   10.  QueueOperationCmd - The type of queues
   whihc operation on the queue,there are not under
        two types defined here: enqueue and dequeue.

   11.  SrcFEID - Source FE ID.

   12.  DstFEID - Destination FE ID.

   13.  NexthopIndex - Next hop index into the control of link layer address
        resolution table.

   14.  NHEncapMethod - How should the scheduler.

   The Queues and schedulers following LFBs that are defined in this library are:

   1.  Scheduler

   2.  Queue

   3.  WRRSched

5.5.1.  Scheduler do to encapsulate
        the packets.

   15.  ErrorId - Error Type.

5.4.  XML Definition for Base Type Library

  <?xml version="1.0" encoding="UTF-8"?>
  <LFBLibrary provides="BaseTypeLibrary"
   xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="urn:ietf:params:xml:ns:forces:lfbmodel:1.0
  SchemaFile.xsd">
  <description>
  This defines a library provides base LFB class for schedulers.  Schedulers have an
   Input Port group called Watchers types definitions for representing the queues they
   watch, and an Output Port group called Controllers fro representing
   the queues they control.

5.5.2.  Queue

   Queues have a packet input, a packet output, a control input, and a
   group LFB library.
  </description>
   <frameDefs>
      <frameDef>
        <name>EthernetII</name>
        <synopsis>an Ethernet II frame type</synopsis>
      </frameDef>
      <frameDef>
        <name>Ethernet802.3</name>
        <synopsis>An Ethernet 802.3 frame type</synopsis>
      </frameDef>
      <frameDef>
        <name>Ethernet802.2</name>
        <synopsis>An Ethernet 802.2 frame type</synopsis>
      </frameDef>
      <frameDef>
        <name>Ethernet802.2SNAP</name>
        <synopsis>An Ethernet 802.2 with SNAP frame</synopsis>
      </frameDef>
      <frameDef>
        <name>IPv4</name>
        <synopsis>An IPv4 packet</synopsis>
      </frameDef>
      <frameDef>
        <name>IPv6</name>
        <synopsis>An IPv6 packet</synopsis>

      </frameDef>
      <frameDef>
        <name>MetadataFrame</name>
        <synopsis>Frame only contains meta data</synopsis>
      </frameDef>
      <frameDef>
        <name>Arbitrary</name>
        <synopsis>Any kind of frame except Metadata Frame.</synopsis>
      </frameDef>
    </frameDefs>
    <dataTypeDefs>
      <dataTypeDef>
        <name>IEEEMAC</name>
        <synopsis>IEEE mac.</synopsis>
        <typeRef>byte[6]</typeRef>
      </dataTypeDef>
      <dataTypeDef>
        <name>LANSpeedType</name>
        <synopsis>LAN speed values</synopsis>
        <atomic>
          <baseType>uint32</baseType>
          <specialValues>
            <specialValue value="0x00000001">
              <name>LAN_SPEED_10M</name>
              <synopsis>10M Ethernet</synopsis>
            </specialValue>
            <specialValue value="0x00000002">
              <name>LAN_SPEED_100M</name>
              <synopsis>100M Ethernet</synopsis>
            </specialValue>
            <specialValue value="0x00000003">
              <name>LAN_SPEED_1G</name>
              <synopsis>1000M Ethernet</synopsis>
            </specialValue>
            <specialValue value="0x00000004">
              <name>LAN_SPEED_10G</name>
              <synopsis>10G Ethernet</synopsis>
            </specialValue>
            <specialValue value="0x00000005">
              <name>LAN_SPEED_AUTO</name>
              <synopsis>LAN speed auto</synopsis>
            </specialValue>
          </specialValues>
        </atomic>
      </dataTypeDef>
      <dataTypeDef>
        <name>NegotiationType</name>
        <synopsis>Negotiation types</synopsis>
        <atomic>
          <baseType>uint32</baseType>
          <specialValues>
            <specialValue value="0x00000001">
              <name>Auto</name>
              <synopsis>Auto negotitation.</synopsis>
            </specialValue>
            <specialValue value="0x00000002">
              <name>Half-duplex</name>
              <synopsis>port negotitation half duplex</synopsis>
            </specialValue>
            <specialValue value="0x00000003">
              <name>Full-duplex</name>
              <synopsis>port negotitation full duplex</synopsis>
            </specialValue>
          </specialValues>
        </atomic>
      </dataTypeDef>
      <dataTypeDef>
        <name>PortStatsType</name>
        <synopsis>port statistics</synopsis>
        <struct>
          <component componentID="1">
            <name>InUcastPkts</name>
            <synopsis>Number of control outputs.  The control ports represent the control
   relationships with scheduluers.

5.5.3.  WRRSched

   Weighted round robin scheduler.

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

5.6.1.  ExtendHeaderProc

   This LFB class process the IPv6 packet with extended header,For the
   moment,the unicast packets to this LFB are redirect to RedirectSink LFB by
   default.

5.6.2.  MetadataClassifier

   This LFB class provides the function received</synopsis>
            <typeRef>uint64</typeRef>
          </component>
          <component componentID="2">
            <name>InMulticastPkts</name>
            <synopsis>Number of classify multicast packets according to
   the meta data.Now it only works on one meta data.

5.6.3.  OptionProc

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

5.6.4.  RedirectLFB

   An LFB Class definition for exchanging data received</synopsis>
            <typeRef>uint64</typeRef>
          </component>
          <component componentID="3">
            <name>InBroadcastPkts</name>
            <synopsis>Number of broadcast packets between the FE
   and the CE.

   This LFB represents a point received</synopsis>
            <typeRef>uint64</typeRef>
          </component>
          <component componentID="4">
            <name>InOctets</name>
            <synopsis>number of exchagne octets received</synopsis>
            <typeRef>uint64</typeRef>
          </component>
          <component componentID="5">
            <name>OutUcastPkts</name>
            <synopsis>Number of data unicast packets between the
   CE and the FE.  Packets with meta-data are exchanged.  It is expected
   that the output port transmitted</synopsis>
            <typeRef>uint64</typeRef>
          </component>
          <component componentID="6">
            <name>OutMulticastPkts</name>
            <synopsis>Number of a RedirectLFB, if it is connected at all,
   will be connected to a meta-data redirector.

5.6.5.  PacketTrimmer

   LFB removes data from the front 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 a packet.

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 error packets</synopsis>
            <typeRef>uint64</typeRef>
          </component>
          <component componentID="10">
            <name>OutErrorPkts</name>
            <synopsis>Number of output
   ports.

5.6.7.  ArbitraryClassifierLFB

   This is a class definition for an Arbitrary Classifier LFB. error packets</synopsis>
            <typeRef>uint64</typeRef>
          </component>
        </struct>
      </dataTypeDef>
      <dataTypeDef>
        <name>PortStatusValues</name>
        <synopsis>
               The
   input 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 a operatively disabled.</synopsis>
            </specialValue>
            <specialValue value="1">
              <name>UP</name>
              <synopsis>the port group, and the match conditions can include the is up.</synopsis>
            </specialValue>
            <specialValue value="2">
              <name>Down</name>
              <synopsis>The port
   in their test.  This allows the topology to carry some information if
   desired.  The match conditions can select an output from is down.</synopsis>

            </specialValue>
          </specialValues>
        </atomic>
      </dataTypeDef>
      <dataTypeDef>
        <name>IPAddr</name>
        <synopsis>IPv4 address</synopsis>
        <typeRef>uint32</typeRef>
      </dataTypeDef>
      <dataTypeDef>
        <name>MacFilterTableEntryType</name>
        <synopsis>MAC filter table entry</synopsis>
        <typeRef>IEEEMAC</typeRef>
      </dataTypeDef>
      <dataTypeDef>
        <name>LocalIpAddrType</name>
        <synopsis>The device local IP address infomation</synopsis>
        <struct>
          <component componentID="1">
            <name>FEID</name>
            <synopsis>The FE on which the
   SuccessOuput output port group.  If no condition matches, ip resides</synopsis>
            <typeRef>uint32</typeRef>
          </component>
          <component componentID="2">
            <name>IfIndex</name>
            <synopsis>port index on the packet
   will be sesnt to specified FE</synopsis>
            <typeRef>uint32</typeRef>
          </component>
          <component componentID="3">
            <name>IPaddr</name>
            <synopsis>IP address of the FailOutput port.

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 port</synopsis>
            <typeRef>IPAddr</typeRef>
          </component>
          <component componentID="4">
            <name>netmask</name>
            <synopsis>netmask of any type with this ip address</synopsis>
            <typeRef>IPAddr</typeRef>
          </component>
          <component componentID="5">
            <name>BcastAddr</name>
            <synopsis>The associated metadata</synopsis>
    </frameDef>
    <frameDef>
      <name>MetadataFrame</name>
      <synopsis>Frame only contains meta data</synopsis>
    </frameDef>
    <frameDef>
      <name>Arbitrary</name>
      <synopsis>Any kind Broadcast address of frame except Metadata Frame.</synopsis>
    </frameDef>
  </frameDefs>
  <dataTypeDefs> the ip
            address </synopsis>
            <typeRef>IPAddr</typeRef>
          </component>
        </struct>
      </dataTypeDef>
      <dataTypeDef>
      <name>ifIndex</name>
      <synopsis>A Port Identifier</synopsis>
        <name>LocalIpv6AddrType</name>
        <synopsis>The device local IPv6 address infomation</synopsis>
        <struct>
          <component componentID="1">
            <name>FEID</name>
            <synopsis>The FE on which the port ip resides</synopsis>
            <typeRef>uint32</typeRef>
          </component>
          <component componentID="2">
            <name>IfIndex</name>
            <synopsis>port index on the specified FE</synopsis>
            <typeRef>uint32</typeRef>
          </component>
          <component componentID="3">
            <name>IPv6addr</name>
            <synopsis>IP address of the port</synopsis>
            <typeRef>IPv6Addr</typeRef>
          </component>
          <component componentID="4">
            <name>prefixlen</name>
            <synopsis>prefix length of this ip address</synopsis>
            <typeRef>uint32</typeRef>
          </component>
        </struct>
      </dataTypeDef>
      <dataTypeDef>
      <name>IEEEMAC</name>
      <synopsis>IEEE MAC Address</synopsis>
      <typeRef>byte[6]</typeRef>
        <name>IPv4Addr</name>
        <synopsis>IPv4 address</synopsis>
        <typeRef> uint32</typeRef>
      </dataTypeDef>
      <dataTypeDef>
      <name>NetSpeedType</name>
      <synopsis>Network speed values</synopsis>
        <name>IPv6Addr</name>
        <synopsis>IPv6 address</synopsis>
        <typeRef>byte[16]</typeRef>
      </dataTypeDef>
      <dataTypeDef>
        <name>IPv4Prefix</name>
        <synopsis>
             prefix defined by an address and a prefix length
             </synopsis>
        <struct>
          <component componentID="1">
            <name>address</name>
            <synopsis>Address part</synopsis>
            <typeRef>IPv4addr</typeRef>
          </component>
          <component componentID="2">
            <name>prefixlen</name>
            <synopsis>Prefix length part</synopsis>
            <atomic>
        <baseType>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
              <baseType>uchar</baseType>
              <rangeRestriction>
                <allowedRange min="0" max="32"/>
              </rangeRestriction>
            </atomic>
          </component>
        </struct>
      </dataTypeDef>
      <dataTypeDef>
        <name> IPv4NextHopInfoType </name>
        <synopsis>IPv4 nexthop information,include nexthop ip address,
        output FE and interface etc.</synopsis>
        <struct>
          <component componentID="1">
            <name>NexthopID</name>
            <synopsis>nexthop id</synopsis>
            <typeRef>uint32</typeRef>
          </component>
          <component componentID="2">
            <name>FEID</name>
            <synopsis>output FE id</synopsis>
            <typeRef>uint32</typeRef>
          </component>
          <component componentID="3">
            <name>OutputPortID</name>
            <synopsis>output port index</synopsis>
            <typeRef>uint32</typeRef>
          </component>
          <component componentID="4">
            <name>MTU</name>
            <synopsis>The maximum transmition unit of the nexthop
            link.</synopsis>
            <typeRef>uint32</typeRef>
          </component>
          <component componentID="5">
            <name> Flags </name>
            <synopsis>Associated flags of the nexthop,such as local
            delivery,multicast etc.</synopsis>
            <typeRef>NextHopFlagsType</typeRef>
          </component>
          <component componentID="6">
            <name> NexthopIPaddr </name>
            <synopsis>IP address of the SNMP
  definitions. We should look at nexthop</synopsis>
            <typeRef>IPv4Addr</typeRef>
          </component>
          <component componentID="7">
            <name> L2Index </name>
            <synopsis>index into the SNMP
  definitions for guidance; we should not have
  limitations that SNMP has such L2 link layer table,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 --> IPv4
            ARP table or IPv6 NBR table.</synopsis>
            <typeRef>uint32</typeRef>
          </component>
          <component componentID="8">
            <name> EncapNeeded </name>
            <synopsis>The type of encapsulation needed on the packet.
            </synopsis>
            <typeRef>EncapType</typeRef>
          </component>
        </struct>
      </dataTypeDef>
      <dataTypeDef>
      <name>PortStatsType</name>
      <synopsis>Port statistics</synopsis>
        <name>IPv4FibEntryType</name>
        <synopsis>IPv4 forwarding table entry.</synopsis>
        <struct>
          <component componentID="1">
          <name>InUcastPkts</name>
          <synopsis>Number of unicast packets received</synopsis>
          <typeRef>uint64</typeRef>
            <name>prefix</name>
            <synopsis>IPv4 prefix.</synopsis>
            <typeRef>IPv4Prefix</typeRef>
          </component>
          <component componentID="2">
          <name>InMulticastPkts</name>
          <synopsis>Number of multicast packets received</synopsis>
          <typeRef>uint64</typeRef>
            <name>FEID</name>
            <synopsis>output FE id</synopsis>
            <typeRef>uint32</typeRef>
          </component>
          <component componentID="3">
          <name>InBroadcastPkts</name>
          <synopsis>Number of broadcast packets received</synopsis>
          <typeRef>uint64</typeRef>
            <name>OutputPortID</name>
            <synopsis>output port index</synopsis>
            <typeRef>uint32</typeRef>
          </component>
          <component componentID="4">
          <name>InOctets</name>
          <synopsis>number
            <name>MTU</name>
            <synopsis>The maximum transmition unit of octets received</synopsis>
          <typeRef>uint64</typeRef> the nexthop link.
            </synopsis>
            <typeRef>uint32</typeRef>
          </component>
          <component componentID="5">
          <name>OutUcastPkts</name>
          <synopsis>Number
            <name> Flags </name>
            <synopsis>Associated flags of unicast packets transmitted</synopsis>
          <typeRef>uint64</typeRef> the nexthop,such as local
             delivery,multicast etc.</synopsis>
            <typeRef>NextHopFlagsType</typeRef>
          </component>
          <component componentID="6">
          <name>OutMulticastPkts</name>
          <synopsis>Number
            <name> NexthopIPaddr </name>
            <synopsis>IP address of multicast packets transmitted</synopsis>
          <typeRef>uint64</typeRef> the nexthop</synopsis>
            <typeRef>IPv4Addr</typeRef>
          </component>
          <component componentID="7">
            <name> L2Index </name>
            <synopsis>index into the L2 link layer table,such as IPv4
             ARP table or IPv6 NBR table.</synopsis>
            <typeRef>uint32</typeRef>
          </component>
          <component componentID="8">
            <name> EncapNeeded </name>
            <synopsis>The type of encapsulation needed on the packet.
            </synopsis>
            <typeRef>EncapType</typeRef>
          </component>
        </struct>
      </dataTypeDef>
      <dataTypeDef>
        <name>IPv4PrefixTableEntry</name>
        <synopsis>IPv4 prefix table entry</synopsis>
        <struct>
          <component componentID="1">
            <name> Prefix </name>
            <synopsis>IPv4 address prefix</synopsis>
            <typeRef> IPv4Prefix </typeRef>
          </component>
          <component componentID="2">
            <name> NexthopID </name>
            <synopsis>Index into the nexthop table.</synopsis>
            <typeRef>uint32</typeRef>
          </component>
        </struct>
      </dataTypeDef>
      <dataTypeDef>
        <name> IPv4UcastLPMStatisticsType </name>
        <synopsis>statistics of IPv4UcastLPM LFB</synopsis>
        <struct>
          <component componentID="7">
          <name>OutBroadcastPkts</name>
          <synopsis>Number componentID="1">
            <name> InRcvdPkts </name>
            <synopsis>The total number of broadcast input packets transmitted</synopsis> received from
             interfaces, including those received in error</synopsis>
            <typeRef>uint64</typeRef>
          </component>
          <component componentID="8">
          <name>OutOcetes</name>
          <synopsis>Number of octets transmitted</synopsis> componentID="2">
            <name> FwdPkts </name>
            <synopsis>IPv4 packet forwarded by this LFB</synopsis>
            <typeRef>uint64</typeRef>
          </component>
          <component componentID="9">
          <name>InErrorPkts</name>
          <synopsis>Number componentID="3">
            <name> NoRoutePkts </name>
            <synopsis>The number of input error packets</synopsis> IP datagrams discarded because no
             route could be found to transmit them to their
             destination.</synopsis>
            <typeRef>uint64</typeRef>
          </component>
          <component componentID="10">
          <name>OutErrorPkts</name>
          <synopsis>Number componentID="4">
            <name>InDeliverPkts</name>
            <synopsis>The total number of output error packets</synopsis> input datagrams successfully
             delivered to IP user-protocols (including ICMP).
             </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> IPv4ValidatorStatisticsType </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>
        <synopsis>IPv4 validator LFB statistics type</synopsis>
        <struct>
          <component componentID="1">
          <name>FEID</name>
            <name> badHeaderPkts </name>
            <synopsis>The FE on which the port total number of input datagrams with bad ip resides</synopsis>
          <typeRef>uint32</typeRef>
<!-- XXX: FEID is know to the Object LFB. Do we need it here? -->
            header</synopsis>
            <typeRef>uint64</typeRef>
          </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
            <name> badTotalLengthPkts </name>
            <synopsis>The total number of uint32 --> input datagrams with bab
            length</synopsis>
            <typeRef>uint64</typeRef>
          </component>
          <component componentID="3">
          <name>IPaddr</name>
          <synopsis>IP address
            <name> badTTLPkts </name>
            <synopsis>The total number of the port</synopsis>
          <typeRef>IPAddr</typeRef> 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="4">
          <name>netmask</name>
          <synopsis>netmask componentID="1">
            <name>IPv6addr</name>
            <synopsis>address part of this ip address</synopsis>
          <typeRef>IPAddr</typeRef> the prefix</synopsis>
            <typeRef>IPv6Addr</typeRef>
          </component>
          <component componentID="5">
          <name>BcastAddr</name>
          <synopsis>The associated Broadcast address componentID="2">
            <name>prefixlen</name>
            <synopsis>length of the ip address
          </synopsis>
          <typeRef>IPAddr</typeRef> prefix</synopsis>
            <typeRef>uint32</typeRef>
          </component>
        </struct>
      </dataTypeDef>
      <dataTypeDef>
      <name>LocalIpv6AddrType</name>
      <synopsis>The device local IPv6 address infomation</synopsis>
        <name> IPv6NextHopInfoType </name>
        <synopsis>IPv4 nexthop information,include nexthop ip address,
        output FE and interface etc.</synopsis>
        <struct>
          <component componentID="1">
            <name>NexthopID</name>
            <synopsis>nexthop id</synopsis>
            <typeRef>uint32</typeRef>
          </component>
          <component componentID="2">
            <name>FEID</name>
          <synopsis>The
            <synopsis>output FE on which the id</synopsis>
            <typeRef>uint32</typeRef>
          </component>
          <component componentID="3">
            <name>OutputPortID</name>
            <synopsis>output port ip resides</synopsis> index</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 componentID="4">
            <name>MTU</name>
            <synopsis>The maximum transmition unit of the specified FE</synopsis> nexthop link.
            </synopsis>
            <typeRef>uint32</typeRef>
<!-- XXX: We need to support
          </component>
          <component componentID="5">
            <name> Flags </name>
            <synopsis>Associated flags of the model that says that a nexthop,such as local IP has
multiple ports. Should this be an array of uint32 -->
             delivery,multicast etc.</synopsis>
            <typeRef>NextHopFlagsType</typeRef>
          </component>
          <component componentID="3">
          <name>IPv6addr</name> componentID="6">
            <name> NexthopIPv6addr </name>
            <synopsis>IP address of the port</synopsis> nexthop</synopsis>
            <typeRef>IPv6Addr</typeRef>
          </component>
          <component componentID="4">
          <name>prefixlen</name>
          <synopsis>prefix length of this ip address</synopsis> componentID="7">
            <name> L2Index </name>
            <synopsis>index into the L2 table</synopsis>
            <typeRef>uint32</typeRef>
          </component>
          <component componentID="8">
            <name> EncapNeeded </name>
            <synopsis>The type of encapsulation needed on the packet.
            </synopsis>
            <typeRef>EncapType</typeRef>
          </component>
        </struct>
      </dataTypeDef>
      <dataTypeDef>
      <name>IPv4Addr</name>
      <synopsis>IPv4 address</synopsis>
      <typeRef>byte[4]</typeRef>
    </dataTypeDef>
    <dataTypeDef>
      <name>IPv6Addr</name>
        <name>IPv6PrefixTableEntry</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> table entry</synopsis>
        <struct>
          <component componentID="1">
          <name>address</name>
          <synopsis>Address part</synopsis>
          <typeRef>IPv4addr</typeRef>
            <name> Prefix </name>
            <synopsis>IPv6 address prefix</synopsis>
            <typeRef> IPv6Prefix </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>
            <name> NexthopID </name>
            <synopsis>index to the nexthop table.</synopsis>
            <typeRef>uint32</typeRef>
          </component>
        </struct>
      </dataTypeDef>
      <dataTypeDef>
      <name>IPv4NextHopInfoType
        <name> IPv6LPMClassiferStatisticsType </name>
      <!-- XXX: Needs more discussion -->
      <synopsis>IPv4 nexthop information,include nexthop ip address,
      output FE and interface etc.</synopsis>
        <synopsis>statistics of IPv6LPMClassifier LFB</synopsis>
        <struct>
          <component componentID="1">
          <name>NexthopID</name>
          <synopsis>nexthop id</synopsis>
          <typeRef>uint32</typeRef>
            <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>FEID</name>
          <synopsis>output FE id</synopsis>
          <typeRef>uint32</typeRef>
            <name> FwdPkts </name>
            <synopsis>IPv4 packet forwarded by this LFB</synopsis>
            <typeRef>uint64</typeRef>
          </component>
          <component componentID="3">
          <name>Egress</name>
          <synopsis>output port index</synopsis>
          <typeRef>uint32</typeRef>
            <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>MTU</name>
            <name>InDeliverPkts</name>
            <synopsis>The maximum transmition unit total number of the nexthop link. input datagrams successfully
             delivered to IP user-protocols (including ICMP).
             </synopsis>
          <typeRef>uint32</typeRef>
            <typeRef>uint64</typeRef>
          </component>
        </struct>
      </dataTypeDef>
      <dataTypeDef>
        <name> IPv6ValidatorStatisticsType </name>
        <synopsis>IPv6 validator LFB statistics type</synopsis>
        <struct>
          <component componentID="5"> componentID="1">
            <name> Flags badHeaderPkts </name>
          <synopsis>Associated flags
            <synopsis>The total number of the nexthop,such as local
          delivery,multicast etc.</synopsis>
          <typeRef>NextHopFlagsType</typeRef> input datagrams with bad ip
             header</synopsis>
            <typeRef>uint64</typeRef>
          </component>
          <component componentID="6"> componentID="2">
            <name> NexthopIPaddr badTotalLengthPkts </name>
          <synopsis>IP address
            <synopsis>The total number of the nexthop</synopsis>
          <typeRef>IPv4Addr</typeRef> input datagrams with bab
             length</synopsis>
            <typeRef>uint64</typeRef>
          </component>
          <component componentID="7"> componentID="3">
            <name> L2Index badTTLPkts </name>
          <synopsis>index into the L2 link layer table,such as IPv4 ARP
          table or IPv6 NBR table.</synopsis>
          <typeRef>uint32</typeRef>
            <synopsis>The total number of input datagrams with bad
             TTL</synopsis>
            <typeRef>uint64</typeRef>
          </component>
          <component componentID="8"> componentID="4">
            <name> EncapNeeded </name> badChecksum</name>
            <synopsis>The type total number of encapsulation needed on the packet.
          </synopsis>
          <typeRef>LinkEncapType</typeRef> input datagrams with bad
             checksum</synopsis>
            <typeRef>uint64</typeRef>
          </component>
        </struct>
      </dataTypeDef>
      <dataTypeDef>
      <name>IPv4FibEntryType</name>
      <!-- XXX: Needs more discussion -->
      <synopsis>IPv4 forwarding
        <name> NextHopFlagsType </name>
        <synopsis>Flags used to define different nexthop behaviors
        </synopsis>
        <atomic>
          <baseType>uint32</baseType>
          <specialValues>
            <specialValue value="0x00000001">
              <name>local</name>
              <synopsis>Packets match the nexthop entry with this flag
               are delivered
               to the higher level protocols.</synopsis>
            </specialValue>
            <specialValue value="0x00000002">
              <name>drop</name>
              <synopsis>Packets match the nexthop entry with this flag
               are to be
              dropped.</synopsis>
            </specialValue>
            <specialValue value="0x00000004">
              <name>broadcast</name>
              <synopsis>The route associated with this nexthop is a
               broadcast.</synopsis>
            </specialValue>
            <specialValue value="0x00000008">
              <name>multicast</name>
              <synopsis>The route associated with this nexthop is
               multicast.</synopsis>
            </specialValue>
          </specialValues>
        </atomic>
      </dataTypeDef>
      <dataTypeDef>
        <name>WeightTableEntryType</name>
        <synopsis>Weight table entry.</synopsis> for queues.</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
            <name>QueueID</name>
            <synopsis>queue 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 componentID="2">
            <name>weight</name>
            <synopsis>weight of the nexthop link.
          </synopsis> queue.</synopsis>
            <typeRef>uint32</typeRef>
          </component>
        <component componentID="5">
          <name> Flags
        </struct>
      </dataTypeDef>
      <dataTypeDef>
        <name>NbrState</name>
        <synopsis>IPv6 neighbour entry resolution state.</synopsis>
        <atomic>
          <baseType>uchar</baseType>
          <specialValues>
            <specialValue value="0x01">
              <name>INCOMPLETE </name>
          <synopsis>Associated flags of
              <synopsis>Address resolution is being performed on the nexthop,such as local
          delivery,multicast etc.</synopsis>
          <typeRef>NextHopFlagsType</typeRef>
        </component>
        <component componentID="6">
          <name> NexthopIPaddr </name>
          <synopsis>IP
               entry.Specifically, a Neighbor Solicitation has been
               sent to the solicited-node multicast address of the nexthop</synopsis>
          <typeRef>IPv4Addr</typeRef>
        </component>
        <component componentID="7">
          <name> L2Index </name>
          <synopsis>index into
               target,but the L2 link layer table,such 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 IPv4 ARP
          table or IPv6 NBR table.</synopsis>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="8">
          <name> EncapNeeded </name>
          <synopsis>The type 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 encapsulation needed on such a message
              does not confirm reachability, and entering the packet. 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>
          <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
            </specialValue>
            <specialValue value="0x04">
              <name>DELAY</name>
              <synopsis>More than ReachableTime milliseconds have
               elapsed since 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 last positive confirmation was
               received in error</synopsis>
          <typeRef>uint64</typeRef>
        </component>
        <component componentID="2">
          <name>FwdPkts</name>
          <synopsis>IPv4 that the forward path was functioning
               properly,and a packet forwarded by this LFB</synopsis>
          <typeRef>uint64</typeRef>
        </component>
        <component componentID="3">
          <name> NoRoutePkts </name>
          <synopsis>The number of IP datagrams discarded because was sent within the last
               DELAY_FIRST_PROBE_TIME seconds.  If 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 reachability
               confirmation is received within DELAY_FIRST_PROBE_TIME
                seconds of input datagrams successfully
          delivered entering the DELAY state, send a Neighbor
                Solicitation and change the state 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> 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>IPv6Prefix</name>
      <synopsis>IPv6 prefix</synopsis>
      <dataTypeDef>
        <name>ArpTableEntryType</name>
        <synopsis>Arp entry.</synopsis>
        <struct>
          <component componentID="1">
          <name>IPv6addr</name>
          <synopsis>address part
            <name>Index</name>
            <synopsis>Index of the prefix</synopsis>
          <typeRef>IPv6Addr</typeRef> arp table.</synopsis>
            <typeRef>uint32</typeRef>
          </component>
          <component componentID="2">
          <name>prefixlen</name>
          <synopsis>length
            <name>NeighborIP</name>
            <synopsis>IP address of the prefix</synopsis>
          <typeRef>uint32</typeRef> neighbour.</synopsis>
            <typeRef>IPv4Addr</typeRef>
          </component>
          <component componentID="3">
            <name>SrcMac</name>
            <synopsis>Source MAC.</synopsis>
            <typeRef>IEEEMAC</typeRef>
          </component>
          <component componentID="4">
            <name>NeighborMac</name>
            <synopsis>Mac of the Neighbor.</synopsis>
            <typeRef>IEEEMAC</typeRef>
          </component>
          <component componentID="5">
            <name>State</name>
            <synopsis>The state of the address resolution progress.
            </synopsis>
            <typeRef>ArpStateType</typeRef>
          </component>
        </struct>
      </dataTypeDef>
      <dataTypeDef>
      <name>IPv6NextHopInfoType</name>
      <!-- XXX: Needs more discussion -->
        <name>NbrTableEntryType</name>
        <synopsis>IPv6 nexthop information,include nexthop ip address,
      output FE and interface etc.</synopsis> neighbour table entry.</synopsis>
        <struct>
          <component componentID="1">
          <name>NexthopID</name>
          <synopsis>nexthop id</synopsis>
            <name>Index</name>
            <synopsis>Index of the arp table.</synopsis>
            <typeRef>uint32</typeRef>
          </component>
          <component componentID="2">
          <name>FEID</name>
          <synopsis>output FE id</synopsis>
          <typeRef>uint32</typeRef>
            <name>NeighborIPv6</name>
            <synopsis>IP address of the neighbour.</synopsis>
            <typeRef>IPv6Addr</typeRef>
          </component>
          <component componentID="3">
          <name>Egress</name>
          <synopsis>output port index</synopsis>
          <typeRef>uint32</typeRef>
            <name>SrcMac</name>
            <synopsis>Source MAC.</synopsis>
            <typeRef>IEEEMAC</typeRef>
          </component>
          <component componentID="4">
          <name>MTU</name>
          <synopsis>The maximum transmition unit
            <name>NeighborMac</name>
            <synopsis>Mac of the nexthop link.
          </synopsis>
          <typeRef>uint32</typeRef> Neighbor.</synopsis>
            <typeRef>IEEEMAC</typeRef>
          </component>
          <component componentID="5">
          <name> Flags </name>
          <synopsis>Associated flags
            <name>State</name>
            <synopsis>The state of the nexthop,such as local
          delivery,multicast etc.</synopsis>
          <typeRef>NextHopFlagsType</typeRef> entry's resolution progress.
            </synopsis>
            <typeRef>NbrState</typeRef>
          </component>
        </struct>
      </dataTypeDef>
      <dataTypeDef>
        <name>DCHostTableEntryTypev4</name>
        <synopsis>Direct connected arp table entry for IPv4.</synopsis>
        <struct>
          <component componentID="6">
          <name> NexthopIPv6addr </name> componentID="1">
            <name>NeighbourIP</name>
            <synopsis>IP address of the nexthop</synopsis>
          <typeRef>IPv6Addr</typeRef> neighbour.</synopsis>
            <typeRef>IPv4Addr</typeRef>
          </component>
          <component componentID="7">
          <name> L2Index </name>
          <synopsis>index into the L2 table</synopsis>
          <typeRef>uint32</typeRef> componentID="2">
            <name>SrcMac</name>
            <synopsis>Source MAC.</synopsis>
            <typeRef>IEEEMAC</typeRef>
          </component>
          <component componentID="8">
          <name> EncapNeeded </name>
          <synopsis>The type componentID="3">
            <name>NeighborMac</name>
            <synopsis>Mac of encapsulation needed on the packet.
          </synopsis>
          <typeRef>LinkEncapType</typeRef> Neighbor.</synopsis>
            <typeRef>IEEEMAC</typeRef>
          </component>
        </struct>
      </dataTypeDef>
      <dataTypeDef>
      <name>IPv6PrefixTableEntry</name>
      <!-- XXX: Needs more discussion -->
      <synopsis>IPv6 prefix
        <name>DCHostTableEntryTypev6</name>
        <synopsis>Direct connected arp table entry</synopsis> entry for IPv4.</synopsis>
        <struct>
          <component componentID="1">
          <name> Prefix </name>
          <synopsis>IPv6
            <name>NeighbourIPv6</name>
            <synopsis>IP address prefix</synopsis>
          <typeRef> IPv6Prefix </typeRef> of the neighbour.</synopsis>
            <typeRef>IPv4Addr</typeRef>
          </component>
          <component componentID="2">
          <name> NexthopID </name>
          <synopsis>index to
            <name>SrcMac</name>
            <synopsis>Source MAC.</synopsis>
            <typeRef>IEEEMAC</typeRef>
          </component>
          <component componentID="3">
            <name>NeighborMac</name>
            <synopsis>Mac of the nexthop table.</synopsis>
          <typeRef>uint32</typeRef> Neighbor.</synopsis>
            <typeRef>IEEEMAC</typeRef>
          </component>
        </struct>
      </dataTypeDef>
      <dataTypeDef>
      <name> IPv6LPMClassiferStatisticsType </name>
      <!-- XXX: Needs more discussion -->
      <synopsis>statistics of IPv6LPMClassifier LFB</synopsis>
        <name>PacketType</name>
        <synopsis>The packet type code.</synopsis>
        <atomic>
          <baseType>uchar</baseType>
          <specialValues>
            <specialValue value="1">
              <name>IPv4Ucast</name>
              <synopsis>IPv4 unicast packet.</synopsis>
            </specialValue>
            <specialValue value="2">
              <name>IPv4Mcast</name>
              <synopsis>IPv4 multicast packet.</synopsis>
            </specialValue>
            <specialValue value="3">
              <name>IPv6Ucast</name>
              <synopsis>IPv6 unicast packet.</synopsis>
            </specialValue>
            <specialValue value="4">
              <name>IPv6Mcast</name>
              <synopsis>IPv6 multicast packet.</synopsis>
            </specialValue>
          </specialValues>
        </atomic>
      </dataTypeDef>
      <dataTypeDef>
        <name>DispatchTableType</name>
        <synopsis>The dispatch table type.</synopsis>
        <struct>
          <component componentID="1">
          <name> InRcvdPkts </name>
            <name>PacketType</name>
            <synopsis>The total number type of input packets received from
          interfaces, including those received in error</synopsis>
          <typeRef>uint64</typeRef> the packet.IPv4Uncast,IPv6Ucast,
            IPv4Mulcast,IPv6Mulcast etc.</synopsis>
            <typeRef>PacketType</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>
            <name>index</name>
            <synopsis>The total number index of input datagrams successfully
          delivered the output group to IP user-protocols (including ICMP).</synopsis>
          <typeRef>uint64</typeRef> output the
            packets.</synopsis>
            <typeRef>uint32</typeRef>
          </component>
        </struct>
      </dataTypeDef>
      <dataTypeDef>
      <name> IPv6ValidatorStatisticsType </name>
      <!-- XXX: Needs more discussion -->
      <synopsis>IPv6 validator LFB statistics type</synopsis>
        <name>MetaType</name>
        <synopsis>Metadata type definition.</synopsis>
        <struct>
          <component componentID="1">
          <name> badHeaderPkts </name>
            <name>MetadataID</name>
            <synopsis>The total number ID of input datagrams with bad ip
          header</synopsis>
          <typeRef>uint64</typeRef> the metadata,the value is
            standardalized in the corresponding
             LFB definition RFCs.</synopsis>
            <typeRef>uint32</typeRef>
          </component>
          <component componentID="2">
          <name> badTotalLengthPkts </name>
            <name>MetadataName</name>
            <synopsis>The total number name of input datagrams with bad length
          </synopsis>
          <typeRef>uint64</typeRef> the metadata.</synopsis>
            <typeRef>String</typeRef>
          </component>
        <component componentID="3">
          <name> badTTLPkts </name>
        </struct>
      </dataTypeDef>
      <dataTypeDef>
        <name>MetadataClassyTableType</name>
        <synopsis>The total number meta data classifying table.</synopsis>
        <struct>
          <component componentID="1">
            <name>value</name>
            <synopsis>Value of input datagrams with bad TTL
          </synopsis>
          <typeRef>uint64</typeRef> the meta data.</synopsis>
            <typeRef>uint32</typeRef>
          </component>
          <component componentID="4">
          <name> badChecksum</name> componentID="2">
            <name>index</name>
            <synopsis>The total number index 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 port in the nexthop entry with this flag
            are output group to be dropped.</synopsis> use
            for outputing the packets.</synopsis>
            <typeRef>uint32</typeRef>
          </component>
        </struct>
      </dataTypeDef>
      <dataTypeDef>
        <name>EncapType</name>
        <synopsis>Encapsulation type.</synopsis>
        <atomic>
          <baseType>uchar</baseType>
          <specialValues>
            <specialValue value="1">
              <name>Link</name>
              <synopsis>Link layer encapsulation such as Ethernet and
              PPP.</synopsis>
            </specialValue>
            <specialValue value="0x00000004">
            <name>broadcast</name>
            <synopsis>The route associated with this nexthop is a
            broadcast.</synopsis> value="2">
              <name>InterFE</name>
              <synopsis>Inter FE communication encapsulation.
              </synopsis>
            </specialValue>
            <specialValue value="0x00000008">
            <name>multicast</name>
            <synopsis>The route associated with this nexthop is
            multicast.</synopsis> value="3">
              <name>Tunnel</name>
              <synopsis>Tunnel encapsulation such as IP-in-IP.
              </synopsis>
            </specialValue>
          </specialValues>
        </atomic>
      </dataTypeDef>
      <dataTypeDef>
      <name>WeightTableEntryType</name>
      <!-- XXX: Needs more discussion -->
      <synopsis>Weight table for queues.</synopsis>
      <struct>
        <name>IPAddress</name>
        <synopsis>IP layer address.</synopsis>
        <union>
          <component componentID="1">
          <name>QueueID</name>
          <synopsis>queue id</synopsis>
          <typeRef>uint32</typeRef>
            <name>Ipv4</name>
            <synopsis>IPv4 address.</synopsis>
            <typeRef>IPv4Addr</typeRef>
          </component>
          <component componentID="2">
          <name>weight</name>
          <synopsis>weight of the queue.</synopsis>
          <typeRef>uint32</typeRef>
            <name>Ipv6</name>
            <synopsis>IPv6 address.</synopsis>
            <typeRef>IPv6Addr</typeRef>
          </component>
      </struct>
        </union>
      </dataTypeDef>
      <dataTypeDef>
      <name>NbrState</name>
      <!-- XXX: Needs more discussion -->
      <synopsis>IPv6 neighbour
        <name>ArpStateType</name>
        <synopsis>The arp entry resolution state.</synopsis>
        <atomic>
          <baseType>uchar</baseType>
          <specialValues>
            <specialValue value="0x01">
            <name>INCOMPLETE </name>
            <synopsis>Address resolution value="1">
              <name>Mannul</name>
              <synopsis>The entry is being performed on entry.
            Specifically,a Neighbor Solicitation has mannully set.</synopsis>
            </specialValue>
            <specialValue value="2">
              <name>InSolicit</name>
              <synopsis>The peer's level 2 address is still in
              requesting.</synopsis>
            </specialValue>
            <specialValue value="4">
              <name>Vaild</name>
              <synopsis>The address resolution have been sent completed
              successfully,it now can be used in the data packets
              forwarding.</synopsis>
            </specialValue>
          </specialValues>
        </atomic>
      </dataTypeDef>
    </dataTypeDefs>
    <metadataDefs>
      <metadataDef>
        <name>NextHopID</name>
        <synopsis>An index into a Next Hop entry in Nexthop table
        </synopsis>
        <metadataID>1</metadataID>
        <typeRef>int32</typeRef>
      </metadataDef>
      <metadataDef>
        <name>ExceptionID</name>
        <synopsis>Exception Types</synopsis>
        <metadataID>2</metadataID>
        <atomic>
          <baseType>uint32</baseType>
          <specialValues>
            <specialValue value="0x00000001">
              <name>Options</name>
              <synopsis>Packets with options,for IPv6 Packet with
              next-header set to hop-by-hop header(0).</synopsis>
            </specialValue>
            <specialValue value="0x00000002">
              <name>LengthMismatch</name>
              <synopsis>The packet length reported by link layer is
              less than the
            solicited-node multicast address of total length field.</synopsis>
            </specialValue>
            <specialValue value="0x00000003">
              <name> BadTTL </name>
              <synopsis>The packet can't be forwarded as the target, but 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
            corresponding Neighbor Advertisement has not yet been
            received.</synopsis>
              packet size.</synopsis>
            </specialValue>
            <specialValue value="0x02">
            <name>REACHABLE</name>
            <synopsis>Positive confirmation was received within the
            last reachableTime milliseconds that value="0x00000006">
              <name>Redirect</name>
              <synopsis>The outgoing port is same as the forward path to one on which
              the neighbor was functioning properly. While reachable, no
            special action takes place as packets are sent.</synopsis> packet is received.</synopsis>
            </specialValue>
            <specialValue value="0x03">
            <name>STALE</name>
            <synopsis>More than ReachableTime milliseconds have elapsed
            since the last positive confirmation was 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 that as limited broadcast.
              </synopsis>
            </specialValue>
          </specialValues>
        </atomic>
      </metadataDef>
      <metadataDef>
        <name>InputPortID</name>
        <synopsis>At which interface 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 arrive.</synopsis>
        <metadataID>3</metadataID>
        <typeRef> uint32</typeRef>
      </metadataDef>
      <metadataDef>
        <name>OutputPortID</name>
        <synopsis>The interface out which the cached link-layer address. Receipt packet will emmit.
        </synopsis>
        <metadataID>4</metadataID>
        <typeRef> uint32</typeRef>
      </metadataDef>
      <metadataDef>
        <name> NextHopIP </name>
        <synopsis>Nexthop IPv4 address.</synopsis>
        <metadataID>5</metadataID>
        <typeRef> IP4Addr </typeRef>
      </metadataDef>
      <metadataDef>
        <name>NexthopIPv6</name>
        <synopsis>Nexthop IPv6 address</synopsis>
        <metadataID>6</metadataID>
        <typeRef>IPv6Addr</typeRef>
      </metadataDef>
      <metadataDef>
        <name>PacketLength</name>
        <synopsis>The length of such a message does not confirm reachability, and
            entering the STALE state insures reachability is verified
            quickly if packet in octets.</synopsis>
        <metadataID>7</metadataID>
        <typeRef>uint32</typeRef>
      </metadataDef>
      <metadataDef>
        <name> PacketType </name>
        <synopsis>Type of the entry is actually being used. However,
            reachability is not actually verified until packet</synopsis>
        <metadataID>8</metadataID>
        <atomic>
          <baseType>uint32</baseType>
          <specialValues>
            <specialValue value="0x8000">
              <name> IPv4 </name>
              <synopsis>IPv4 packet</synopsis>
            </specialValue>
            <specialValue value="0x86DD">
              <name> IPv6 </name>
              <synopsis>IPv6 packet</synopsis>
            </specialValue>
            <specialValue value="3">
              <name> TaggedFrame </name>
              <synopsis>packet with metadata</synopsis>
            </specialValue>
            <specialValue value="4">
              <name> MetaDataFrame </name>
              <synopsis>meta data only</synopsis>
            </specialValue>
          </specialValues>
        </atomic>
      </metadataDef>
      <metadataDef>
        <name> QueueID </name>
        <synopsis>The queue ID</synopsis>
        <metadataID>9</metadataID>
        <typeRef> uint32</typeRef>
      </metadataDef>
      <metadataDef>
        <name>QueueOperationCmd</name>
        <synopsis>The type of operation on the entry is
            actually used.</synopsis> 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="0x04">
            <name>DELAY</name>
            <synopsis>More than ReachableTime milliseconds have elapsed
            since value="2">
              <name>Dequeue</name>
              <synopsis>Dequeue command.</synopsis>
            </specialValue>
          </specialValues>
        </atomic>
      </metadataDef>
      <metadataDef>
        <name>SrcFEID</name>
        <synopsis>Source blade ID.</synopsis>
        <metadataID>11</metadataID>
        <typeRef>uchar</typeRef>
      </metadataDef>
      <metadataDef>
        <name>DstFEID</name>
        <synopsis>Destination blade ID.</synopsis>
        <metadataID>12</metadataID>
        <typeRef>uchar</typeRef>
      </metadataDef>
      <metadataDef>
        <name>NexthopIndex</name>
        <synopsis>Nexthop index into the last positive confirmation was received that link layer address resolution
        table.</synopsis>
        <metadataID>13</metadataID>
        <typeRef>uint</typeRef>
      </metadataDef>
      <metadataDef>
        <name>EncapMethod</name>
        <synopsis>how should the
            forward path was functioning properly, and a packet was
            sent within following LFBs do to encapsulate the last DELAY_FIRST_PROBE_TIME seconds. If no
            reachability confirmation is received within
            DELAY_FIRST_PROBE_TIME seconds of entering
        packets,such as link encapsulation which means the DELAY state,
            send a Neighbor Solicitation and change packets need
        to encapsulate link layer header before sending to media;inter
        FE communication encapsulation which means the state 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 PROBE.
        media. </synopsis>
          </specialValue>
          <specialValue value="0x05">
            <name>PROBE</name>
            <synopsis>A reachability confirmation
        <metadataID>14</metadataID>
        <typeRef>EncapType</typeRef>
      </metadataDef>
    </metadataDefs>
  </LFBLibrary>

6.  LFB Classes Description

   According to ForCES specifications, LFB (Logical Function Block) 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
   well defined, logically separable functional block that resides in an
   FE, and is a functionally accurate abstraction of the Neighbor.</synopsis>
          <typeRef>IEEEMAC</typeRef>
        </component>
        <component componentID="5">
          <name>State</name>
          <synopsis>State FE's processing
   capabilities.  An LFB Class (or type) is a template that represents a
   fine-grained, logically separable aspect of FE processing.  Most LFBs
   relate to packet processing in the 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 data path.  LFB classes are the arp table.</synopsis>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="2">
          <name>NeighborIPv6</name>
          <synopsis>IP address
   basic building blocks 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 FE model.

   Only for better understanding purposes, LFB classes defined in this
   document are further categorized into groups of LFBs, including Core
   LFBs, Port LFBs, etc.

   The following sections describe the Neighbor.</synopsis>
          <typeRef>IEEEMAC</typeRef>
        </component>
        <component componentID="5">
          <name>State</name>
          <synopsis>State of LFB classes according to 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
   groups.

6.1.  Core LFBs

   The core LFBs provide basic ForCES functionality for IPv4. </synopsis>
      <struct>
        <component componentID="1">
          <name>NeighbourIP</name>
          <synopsis>IP address of FE in a ForCES
   system.  Two core LFBs are defined: 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 FE Protocol LFB and 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 FE
   Object LFB.

6.1.1.  FE Protocol LFB

   The FE Protocol LFB is defined as a logical entity in each FE that is
   used to control the ForCES protocol.  It repsesents FE Protocol
   attributes like supportable ForCES protocol versions, current running
   version, FE restart policy, CE failover policy, etc.  The ForCES
   protocol specification document FE-MODEL [I-D.ietf-forces-model]
   defines the LFB in details and specifes that every FE must have one
   FE Protocol LFB.

   The definition of the 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 LFB is included in this base LFB library by
   using "load" element:

   <load library="FEPO", location="..."/>

6.1.2.  FE Object LFB

   The FE Object LFB is defined to make the 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 FE information easily
   accessible.  Information like the FE Name, FE ID, FE State, LFB
   Topology in the FE are represented in the class of LFB.  The FE model
   documentFE-MODEL [I-D.ietf-forces-model] defines the packet.IPv4Uncast,IPv6Ucast,
          IPv4Mulcast,IPv6Mulcast etc.</synopsis>
          <typeRef>IPPacketType</typeRef>
        </component>
        <component componentID="2">
          <name>index</name>
          <synopsis>The index LFB in details
   and specifies that every FE must have one FE Object LFB.

   The definition of the output group LFB is included in this base LFB library by
   using "load" element:

   <load library="FEObject", location="..."/>

6.2.  Port LFBs

   Classes of Port LFBs are LFBs that are related 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 operation of the metadata,the value is standardalized FE
   media interfaces linked to outer networks or other FEs in the corresponding LFB definition RFCs.</synopsis>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="2">
          <name>MetadataName</name>
          <synopsis>The name same
   ForCES system.  According to different media types, different media
   port LFBs may have to be defined.  For every type of media port, it
   usually needs to implement encapsulating and decapsulating the 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 IP
   datagrams with the connected network framing.  For the sake of the meta data.</synopsis>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="2">
          <name>index</name>
          <synopsis>The index
   flexibility, the function of encapsulating and decapsulating are
   usually categorized in LFB classes as separate LFBs.

   Even if ports with different media may have different logical
   abstracts for the attributes, a general description for different
   ports still exist.  A Generic Connectivity LFB is defined for this
   sake.  By use of an FE model XML schema <derivedFrom> element,
   specific media port LFBs are then defined in a easier way.

6.2.1.  Generic Connectivity LFB

   This LFB Class provides a generic basis for representing connectivity
   between the output group to use FE and the outside world.  The LFB has one or more ports
   for outputing packets that the packets.</synopsis>
          <typeRef>uint32</typeRef>
        </component>

      </struct>
    </dataTypeDef>
    <dataTypeDef>
      <name>LinkEncapType</name>
      <!-- XXX: Needs FE processing logic is forwrding for
   transmission by this Connectivity LFB.  It has one or more discussion -->
      <synopsis>Encapsulation type.</synopsis>
      <atomic>
        <baseType>uchar</baseType>
        <specialValues>
          <specialValue value="1">
            <name>Link</name>
            <synopsis>Link layer encapsulation such as Ethernet ports for
   packets that the Connectivity LFB has received and
            PPP.</synopsis>
          </specialValue>
          <specialValue value="2">
            <name>InterFE</name>
            <synopsis>Inter is handing to the
   FE communication encapsulation.</synopsis>
          </specialValue>
          <specialValue value="3">
            <name>Tunnel</name>
            <synopsis>Tunnel processing logic.  Multiple ports for handline packets are
   supported so that protocol specific 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 and demultiplexing
   can be used in the data provided by this LFB.  This LFB also has ports for sending
   packets
            forwarding.</synopsis>
          </specialValue>
        </specialValues>
      </atomic>
    </dataTypeDef>
    <dataTypeDef>
      <name>MatchTargetType</name>
      <!-- XXX: Needs more discussion -->
      <synopsis>
         Indicator to lower layer Connectivity LFBs and receiving packets from
   such lower layer Connectivity LFBs.  This enables support for the kind
   processing components of field to be matched by interface stacks, such as PPP over Ethernet
   or Ethernet over MPLS.  For packets arriving from Media or lower
   layer connectivity, 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 LFB will perform appropriate media
   validation, then remove media specific headers, and place the
            packet.</synopsis>
          </specialValue>
        </specialValues>

      </atomic>
    </dataTypeDef>
    <dataTypeDef>
      <name>MatchTargetIdentifier</name>
      <!-- XXX: Needs more discussion -->
      <synopsis>
         Identify
   relevant information in meta-data.  For ethernet, the specific target of a match condition.
       </synopsis>
      <union>
        <component componentID="1">
          <name>MetaDataID</name>
          <synopsis>The ID of Source MAC
   would be in meta-data.  For Frame Relay or ATM, a metadata item</synopsis>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="2">
          <name>packetFieldID</name>
          <synopsis>The circuit identifier for a
   would be in meta-data.  For Ethernet with VLANs, this meta-data would
   indicate which VLAN the packet Field, 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 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 number of octets 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 packets sent
   and received, the start number of various input and output errors, etc.

6.2.2.  Ethernet Port LFBs

   (TBD)

   1.  EtherPort LFB

       LFB for Ethernet ports

   2.  EtherDecap LFB

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

   3.  EtherEncap LFB

       An LFB classifier definition for completes ethernet encapsulation
       fuctions.

6.2.3.  POS Port LFBs

   (TBD)

6.2.4.  ATM Port LFBs

   (TBD)

6.3.  Address Resolution LFBs

   (TBD)

   This LFB class provides the packet
               to the start function of address resolution for IPv4/
   IPv6 nodes.

   1.  ARP

       This LFB class provides the field.</synopsis>
              <typeRef>uint32</typeRef>
            </component>
            <component componentID="2">
              <name>fieldLength</name>
              <synopsis>The length function 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 address resolution 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
       IPv4 node.

   2.  IPv6 Address Resolution

       This LFB class provides the function 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 IPv6 address resolution
       part 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 neighbor discovery protocol.It provides an offload of match ND
       protocol processing to apply.</synopsis>
          <typeRef>MatchConditionType</typeRef>
        </component>
        <component componentID="4">
          <name>MatchParamOne</name>
          <synopsis>The first parameter for FE.It process the match</synopsis>
          <optional/>
          <typeRef>MatchBitString</typeRef>
        </component>
        <component componentID="5">
          <name>MatchParamTwo</name>
          <synopsis>The second parameter for following ND messages:
       neighbour solicitation and neighbour advertisement.

6.4.  ICMP LFBs

   (TBD)

   1.  ICMP Geneartor

       This LFB class provide some basic ICMP function.  It only
       generate the match</synopsis>
          <optional/>
          <typeRef>MatchBitString</typeRef>
        </component>
      </struct>
    </dataTypeDef>
    <dataTypeDef>
      <name>MatchConditiontType</name>
      <!-- XXX: Needs more discussion -->
      <synopsis>
         Indicator following ICMP messages: ICMP destination
       unreachable and time excceeded.

   2.  ICMPv6 Generator

       This LFB class provide some basic ICMPv6 function, it only
       generate the following ICMP messages for the 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 packets that need
       some basic ICMP processing: destination not reachable and time
       excceeded.

6.5.  IP Packet Validation LFBs

   (TBD)

   1.  IPv4 Validator

       An LFB Class definition for validates the IPv4 packet.

       This LFB validates the IP version and header length fields,
       including verifying that the match value must be packet length is at least as long as
       the same,
             with no padding.Only header indicates.

   2.  IPv6 Validator

       An LFB Class definition for validates the first value of IPv6 packet.

       This LFB validates 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 IP version and header length fields,
       including verifying that the first match value.
            If there packet length is a second match value, at least as long as
       the remainder of header indicates.

6.6.  Classifier LFBs

   (TBD)

   1.  Metadata Classifier LFB

       This LFB class provides the
            target must match repeated occurrances function of the second value.
            Thus, this can be used classify packets
       according 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 meta data.  Now it only works on one meta data.

   2.  Arbitrary Classifier LFB
       This is a second match value, the preceding part of class definition for an Arbitrary Classifier LFB.  The
       input is a port group, and the
            target must match repeated occurrances of the second value.
            Thus, this conditions 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 include the target must be greater than or equal to
       port in their test.  This allows the first
            match value, and less than or equal topology to the second match
            value. An omitted carry some
       information if desired.  The match value means that end of conditions can select an
       output from the range
            is unlimitted.</synopsis>
          </specialValue>
          <specialValue value="5">
            <name>MatchMaskedValue</name>
            <synopsis> The target SuccessOuput output port group.  If no condition
       matches, the packet will be sesnt to the first value FailOutput port.

6.7.  Forwarding LFBs

   (TBD)

   Forwarding LFBs are each anded
            with the second value. The match succeeds if specifically for implementing IP packet
   forwarding tasks.

6.7.1.  Unicast Longest Prefix Match LFBs

   1.  IPv4UcastLPM

       IPv4 Longest Prefix Match Lookup LFB

   2.  IPv6UcastLPM

       An LFB class definition for IPv6 longest prefix lookup function.

6.7.2.  Nexthop Applicator LFBs

   1.  IPv4 NextHop Applicator

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

   2.  IPv6UcastNexthopApplicator

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

6.8.  QoS Control LFBs

   (TBD)

   To build an actual forwarder, one must include some limited for of
            these
   queueing and operations scheduling.  Queues are identical. Both values entities which store packets.
   Schedulers are
            required.</synopsis>
          </specialValue>
          <specialValue value="6">
            <name>MatchSucceed</name>
            <synopsis>A Match entities which always succeeds</synopsis>
          </specialValue>
        </specialValues>
      </atomic>
    </dataTypeDef>
    <dataTypeDef>
      <name>MatchMetaDataAction</name>
      <!-- XXX: Needs more discussion -->
      <synopsis>An action to set a metadata item react 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 state of queues and cause
   packets to set</synopsis>
          <typeRef>uint32</typeRef>
        </component>
        <component componentID="2">
          <name>ExplicitValueToSet</name>
          <synopsis>A value 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 set represent all the metadata to</synopsis>
          <optional/>
          <typeRef>octetstring[16]</typeRef>
        </component>
        <component componentID="3">
          <name>ValueFromCondition</name>
          <synopsis> This complexity.
   Additionally, there is an index into the corresponding match
          conditions, and issue of representing the meta data will be set to relationship
   between 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 queue and the next hop table.Typically stored 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 generated as metadata output port (called OutData) on which it
   will send packets when permitted by its definition or 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 scheduler.
   Its relationship 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 scheduluers is represented by a set of output
   ports (the group OutCountrol) and an input port (called InControl).
   These ports are defined 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 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 total length field.</synopsis>
          </specialValue>
          <specialValue value="0x00000003">
            <name> BadTTL </name>
            <synopsis>The packet can't be forwarded as OutControl group represents
   the TTL has
            expired.</synopsis>
          </specialValue>
          <specialValue value="0x00000004">
            <name> Multicast </name>
            <synopsis>The packet received is fact that a multicast packet.
            </synopsis>
          </specialValue>
          <specialValue value="0x00000005">
            <name>FragRequired</name>
            <synopsis>The MTU for outgoing interface scheduler is less than aware of the
            packet size.</synopsis>
          </specialValue>
          <specialValue value="0x00000006">
            <name>Redirect</name>
            <synopsis>The outgoing state of that queue
   element.  The InControl port is same as 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 which 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
            packet is received.</synopsis>
          </specialValue>
          <specialValue value="0x00000007">
            <name>LocalDelivery</name>
            <synopsis>The packet 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 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 controller who monitors
   and controls a single set of queues, and more interesting cases where
   the packet arrive.</synopsis>
      <metadataID>3</metadataID>
      <typeRef>ifIndex</typeRef>
    </metadataDef>
    <metadataDef>
      <name>EgressPort</name>
      <synopsis>Interface out which control of certain queues may depend upon 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 state of queues
   whihc are not under the control of the packet scheduler.

   The Queues and schedulers LFBs that are defined in octets.</synopsis>
      <metadataID>7</metadataID>
      <typeRef>uint32</typeRef>
    </metadataDef>
    <metadataDef>
      <name>IPPacketType </name>
      <!--XXX: Needs more discussion. Should match frameDefs.-->
      <synopsis>Type this library are:

   1.  Scheduler

   2.  Queue

   3.  WRRSched

6.8.1.  Scheduler LFBs

   1.  Generic Scheduler

       This defines a base LFB class for schedulers.  Schedulers have an
       Input Port group called Watchers for representing the queues they
       watch, and an Output Port group called Controllers fro
       representing the queues they control.

   2.  WRRSched

       Weighted round robin scheduler.

6.8.2.  Queue LFBs

   Queues have a packet input, a packet output, a control input, and a
   group of control outputs.  The control ports represent the 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 control
   relationships with scheduluers.

6.9.  Miscellaneous Packet Manipulation LFBs

   (TBD)

   1.  Packet Trimmer LFB

       LFB removes 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 from the front of operation a packet.

   2.  Duplicator LFB

       An LFB Class definition for packet duplicator LFB.  Any packet
       received on the queue,there are two types
      defined here: enqueue an input port is logically copied 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: sent to all
       output ports.

   3.  IPv4 Option Proccessing LFB

       This should be removed -->
      <synopsis>Nexthop index into LFB class process 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 IPv4 packet with options, it can
       process on the following LFBs do to encapsulate options: Router-alert option.

   4.  IPv6 Extend Header Processing LFB

       This LFB class process the
      packets,such as link encapsulation which means IPv6 packet with extended header, For
       the moment, the packets need to encapsulate link layer header before sending this LFB are redirect to media;inter FE
      communication encapsulation which means the RedirectSink
       LFB by default.

6.10.  Redirect LFB

   (TBD)

   An LFB Class definition for exchanging data packets need to first
      encapsulate inter between the FE communication header before transimiting to
      other FEs;tunnel encapsulation which means
   and 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> CE.

   This LFB represents a point of exchagne of data packets between the packet length
   CE and the FE.  Packets with meta-data are exchanged.  It is not as long as expected
   that the header indicates
               </synopsis>
          </specialValue>
          <specialValue value="0x000300FF">
            <name>otherError</name>
            <synopsis>The errors we not defined now</synopsis>
          </specialValue>
        </specialValues>
      </atomic>
    </metadataDef>
  </metadataDefs> output port of a RedirectLFB, if it is connected at all,
   will be connected to a meta-data redirector.

7.  XML Definition for Base LFB Library

 <?xml version="1.0" encoding="UTF-8"?>
 <LFBLibrary provides="BaseLFBLibrary"
  xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="urn:ietf:params:xml:ns:forces:lfbmodel:1.0
  SchemaFile.xsd">
 <description>
 This library provides base LFB class definitions.
 </description>
    <load library="BaseTypeLibrary", location="..."/>
   <LFBClassDefs>
     <LFBClassDef LFBClassID="3">
       <name>EtherPort</name>
      <!--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
           <synopsis>
                    Ports for receiving packets from processing unit
                     such as NP,that will be sent to media.</synopsis> media.
           </synopsis>
           <expectation>
             <frameExpected>
               <ref>EthernetII</ref>
             </frameExpected>
             <metadataExpected>
               <ref>OutputPort</ref>
             </metadataExpected>
           </expectation>
         </inputPort>
         <inputPort>
           <name>PacketsFromMedia</name>
          <synopsis>Ports
           <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> processing. </synopsis>
           <product>
             <frameProduced>
               <ref>EthernetII</ref>
             </frameProduced>
             <metadataProduced>
               <ref>InputPort</ref>
             </metadataProduced>
           </product>
         </outputPort>
         <outputPort>
           <name>PacketsToMedia</name>
          <synopsis>Ports
           <synopsis>
                    Ports for sending packets to media.</synopsis> 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> 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>
           <typeRef>LANSpeedType</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>
           <typeRef>NegotiationType</typeRef>
           <defaultValue>"auto"</defaultValue>
         </component>
         <component componentID="10">
          <name>SrcNegotiationTypeMACAddr</name>
           <name>SrcMACAddr</name>
           <synopsis>source MAC</synopsis>
           <typeRef>IEEEMAC</typeRef>
         </component>
         <component componentID="11">
           <name>MacAliasTable</name>
           <synopsis>A series of MACs that the port can receive frame
           on.</synopsis>
           <array>
             <typeRef>IEEEMAC</typeRef>
           </array>
         </component>
         <component componentID="12">
           <name>StatsEnable</name>
           <synopsis>whether enable the statistics in this LFB.
           </synopsis>
           <optional/>
           <typeRef>booleanType</typeRef>
           <defaultValue>"no"</defaultValue>
         </component>
         <component componentID="13" access="read-reset">
           <name>PortStats</name>
           <synopsis>port statistics.</synopsis>
           <optional/>
           <typeRef>PortStatsType</typeRef>
         </component>
         <component componentID="14">
           <name>Ipaddr</name>
           <synopsis>IP layer Address.</synopsis>
           <typeRef>IPAddress</typeRef>
         </component>
       </components>
       <events baseID="100">
         <event eventID="1">
           <name>PortStatusChanged</name>
           <synopsis>Port status has changed since last time reporting.
           </synopsis>
           <eventTarget>
             <eventField>OperaStatus</eventField>
           </eventTarget>
           <eventChanged/>
           <eventReports>
             <eventReport>
               <eventField>OperaStatus</eventField>
             </eventReport>
           </eventReports>
         </event>
       </events>
     </LFBClassDef>
     <LFBClassDef LFBClassID="4">
       <name>EtherDecap</name>
      <!--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>

             </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="3">
          <name>LocalIpAddrTable</name>
          <synopsis>The componentID="1">
           <name>DispatchTable</name>
           <synopsis>This table of interfaces's ip address infomation on is used for selecting output in the local device</synopsis>
          <typeRef>LocalIpAddrType</typeRef>
        </component>
        <component componentID="4">
          <name>IPv4Stats</name>
          <synopsis>The IPv4 associated statistics</synopsis>
          <optional/>
          <typeRef> IPv4UcastLPMStatisticsType </typeRef>
           ouput group for the incoming packet stream.</synopsis>
           <typeRef>DispatchTableType</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> LFBClassID="5">
       <name>IPv4Validor</name>
       <synopsis>An LFB Class definition for applicating next hop action to validates the IPv4 packets,the actions include:TTL operation,checksum
      recalculation.</synopsis> packets.
       </synopsis>
       <version>1.0</version>
       <inputPorts>
         <inputPort>
          <name>PktIn</name>
           <name>ValidatePktsIn</name>
           <synopsis>Port used to receive IPv4 packets from other LFBs packet for validation.
           </synopsis>
           <expectation>
             <frameExpected>
              <ref> IPv4 </ref>
               <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
           <synopsis>Out port for packet successfully fulfill the
          nexthop application.</synopsis> packets passing the validation.
           </synopsis>
           <product>
             <frameProduced>
              <ref> IPv4 </ref>
               <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 port for the packets need deep needed to be dealt by
           higher level
          protocol stacks.</synopsis> protcol stacks.The following packets are
           identified as exception packets:1 Packet with header
           length>5;2 Packet with destination address equal to
           255.255.255.255;3 Packet with expired TTL (checked after a
           forwarding decision is made);4 Packet length error.
           </synopsis>
           <product>
             <frameProduced>
              <ref> IPv4 </ref>
            </frameProduced>
            <metadataProduced>
              <ref>Ingress</ref>
               <ref>ExceptionID</ref>
            </metadataProduced>
             </frameProduced>
           </product>
         </outputPort>
         <outputPort>
           <name>FailOutput</name>
           <synopsis>Output for packets failed to pass the nexthop application
          operation.</synopsis> validation.
           </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
           <name>StatsEnable</name>
           <synopsis>whether to gather statistics in this LFB supports LFB.
           </synopsis>
          <typeRef>uint32</typeRef>
        </capability>
      </capabilities>
           <optional/>
           <typeRef>booleanType</typeRef>
           <defaultValue>"no"</defaultValue>
         </component>
         <component componentID="2" access="read-reset">
           <name>IPv4ValidatorStats</name>
           <synopsis>ipv4 validator LFB statistics</synopsis>
           <optional/>
           <typeRef>IPv4ValidatorStatisticsType</typeRef>
         </component>
       </components>
       <description>Detailed validation process please refer to RFC1812
       and RFC2644.</description>

     </LFBClassDef>
     <LFBClassDef LFBClassID="9">
      <name>IPv6UcastLPM</name>
      <synopsis>An LFB class definition for IPv6 longest prefix lookup
      function.</synopsis> 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 IPv6 packets needed to do IPv4
          LPM.</synopsis> packets from other LFBs
           </synopsis>
           <expectation>
             <frameExpected>
              <ref>IPv6</ref>
               <ref>IPv4</ref>
             </frameExpected>
           </expectation>
         </inputPort>
       </inputPorts>
       <outputPorts>
         <outputPort>
           <name>SuccessOut</name>
          <synopsis>Output for packets that have find the correct
          route.</synopsis>
           <synopsis>Successful output when all is fine.</synopsis>
           <product>
             <frameProduced>
              <ref>IPv6</ref>
               <ref>IPv4</ref>
             </frameProduced>
             <metadataProduced>
              <ref>NextHopID</ref>
               <ref availability="conditional">NextHopID</ref>
               <ref availability="conditional">FEID</ref>
               <ref availability="conditional">OutputPortID</ref>
               <ref availability="conditional">MTU</ref>
               <ref availability="conditional">Flags</ref>
               <ref availability="conditional">NexthopIPAddr</ref>
               <ref availability="conditional">EncapMethod</ref>
             </metadataProduced>
           </product>
         </outputPort>
         <outputPort>
           <name>ExceptionOut</name>
           <synopsis>Exception output</synopsis>
           <product>
             <frameProduced>
               <ref>IPv4</ref>
             </frameProduced>
             <metadataProduced>
               <ref>InputPortID </ref>
               <ref>ExceptionID</ref>
             </metadataProduced>
           </product>

         </outputPort>
         <outputPort>
           <name>FailOutput</name>
          <synopsis>LPM failed.</synopsis>
           <synopsis>Dropper</synopsis>
           <product>
             <frameProduced>
               <ref> IPv6 IPv4 </ref>
             </frameProduced>
           </product>
         </outputPort>
       </outputPorts>
       <components>
         <component componentID="1">
           <name> PrefixTable </name>
          <synopsis>IPv6
           <synopsis>IPv4 prefix table</synopsis>
           <array type="variable-size">
             <typeRef> IPv6PrefixTableEntry IPv4PrefixTableEntry </typeRef>
             <contentKey contentKeyID="1">
              <contentKeyField>IPv6PrefixTableEntry.prefix
               <contentKeyField>IPv4PrefixTableEntry.prefix
               </contentKeyField>
             </contentKey>
           </array>
         </component>
         <component componentID="2">
          <name>LocalIpv6AddrTable</name>
           <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>LocalIpv6AddrType</typeRef>
           <typeRef>LocalIpAddrType</typeRef>
         </component>
         <component componentID="3" access="read-reset">
          <name>IPv6Stats</name> componentID="4">
           <name>IPv4Stats</name>
           <synopsis>The IPv6 IPv4 associated statistics</synopsis>
           <optional/>
           <typeRef> IPv6LPMClassiferStatisticsType 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>LocalIpv6AddrTableLimit</name>
           <name>LocalIpAddrTableLimit</name>
           <synopsis>maxium number of IPv6 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="10">
      <name>IPv6UcastNexthopApplicator</name> LFBClassID="7">
       <name> IPv4NextHopApplicator </name>
       <synopsis>An LFB definition for applicating next hop action to IPv6 packets,
        IPv4 packets,the actions mainly inlcude TTL incrementation and checksum include:TTL operation,checksum
         recalculation.</synopsis>
       <version>1.0</version>
       <inputPorts>
         <inputPort>
           <name>PktIn</name>
          <synopsis>Input port for packets
           <synopsis>Port used to be applicate nexthop. receive IPv4 packets from other LFBs
           </synopsis>
           <expectation>
             <frameExpected>
               <ref> IPv6 IPv4 </ref>
             </frameExpected>
             <metadataExpected>
              <ref>NextHopID</ref>
               <ref dependency="optional" defaultValue="0xff">
               NextHopID</ref>
               <ref dependency="optional" defaultValue="0xff">
               FEID</ref>
               <ref dependency="optional" defaultValue="0xff">
               OutputPortID</ref>
               <ref dependency="optional" defaultValue="0xff">
               MTU</ref>
               <ref dependency="optional" defaultValue="0xff">
               Flags</ref>
               <ref dependency="optional" defaultValue="0xff">
               NexthopIPAddr</ref>
               <ref dependency="optional" defaultValue="0xff">
               EncapMethod</ref>

             </metadataExpected>
           </expectation>
         </inputPort>
       </inputPorts>
       <outputPorts>
         <outputPort>
           <name>SuccessOut</name>
           <synopsis>Output port for packet successfully fulfill the
            nexthop application.</synopsis>
           <product>
             <frameProduced>
               <ref> IPv6 IPv4 </ref>
             </frameProduced>
             <metadataProduced>
              <ref>FEID</ref>
              <ref>Egress</ref>
               <ref>DstFEID</ref>
               <ref>OutputPortID</ref>
               <ref availability="conditional">L2Index</ref>
              <ref>NextHopIPv6</ref>
               <ref>NextHopIP</ref>
               <ref availability="conditional">NHEncapMethod</ref> availability="conditional">EncapMethod</ref>
             </metadataProduced>
           </product>
        </outputPort>
        <outputPort>
          <name>ExceptionOut</name>
          <synopsis>Output port for exception packet.The following
          packets are identified as Exception packet:1 Packet with Hop
          Limit zero.2 The MTU for outgoing interface is less than the
          packet size.3 The outgoing port is same as the one on which
          the packet is received.4 The packet is
         </outputPort>
         <outputPort>
           <name>ExceptionOut</name>
           <synopsis>Output for a local interface.
          </synopsis> packets need deep dealt by higher level
            protocol stacks.</synopsis>
           <product>
             <frameProduced>
               <ref> IPv6 IPv4 </ref>
             </frameProduced>
             <metadataProduced>
              <ref>Ingress</ref>
               <ref>InputPortID</ref>
               <ref>ExceptionID</ref>
             </metadataProduced>
           </product>
         </outputPort>
         <outputPort>
           <name>FailOutput</name>
           <synopsis>Output for packets failed the nexthop application
            operation.</synopsis>
           <product>
             <frameProduced>
               <ref> IPv6 IPv4 </ref>
             </frameProduced>
           </product>
         </outputPort>
       </outputPorts>
       <components>
         <component componentID="1">
           <name> NextHopTable </name>
           <synopsis>Nexthop table</synopsis>
           <optional/>
           <array type="variable-size">
             <typeRef> IPv6NextHopInfoType IPv4NextHopInfoType </typeRef>
           </array>
         </component>
       </components>
       <capabilities>
         <capability componentID="1"> componentID="2">
           <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 LFBClassID="8">
       <name>IPv6Validator</name>
       <synopsis>A LFB classifier class definition for completes ethernet
      encapsulation fuctions</synopsis> validating correctness
        of IPv6 packets</synopsis>
       <version>1.0</version>
      <derivedFrom>GenericConnectivityLFB</derivedFrom>
       <inputPorts>
         <inputPort>
          <name>EncapIn</name>
          <synopsis>Port
           <name>ValidateIn</name>
           <synopsis>Input port for receiving packets needed to build Ethernet
          encapsulation.</synopsis> be validated.</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/>
           <synopsis>Output port for packets passing the validation.
           </synopsis>
           <product>
             <frameProduced>
              <ref>EthernetII</ref>
               <ref>IPv6</ref>
             </frameProduced>
           </product>
         </outputPort>
        <outputPort group="true">
         <outputPort>
           <name>ExceptionOut</name>
          <synopsis>packet can't find
           <synopsis>Output port for exception packet.The following
            packets are identified as Exception packet:1 Packet with
            next header set to Hop-by-Hop.2 The packet length reported
            by link layer is less than the associated L2 information total length field.3 Packet
            with a link local destination address;4 The packet  received
            as limited broadcast.5 Packet with multicast destination
            address (the MSB of the destination address is 0xFF);
            </synopsis>
           <product>
             <frameProduced>
              <ref>IPv4</ref>
               <ref>IPv6</ref>
             </frameProduced>
             <metadataProduced>
               <ref>ExceptionID</ref>
             </metadataProduced>
           </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
         <outputPort>
           <name>FailOut</name>
           <synopsis>Output port for IPv6. packet failing the validation.
           </synopsis>
           <product>
             <frameProduced>
               <ref>IPv6</ref>
             </frameProduced>
           </product>
         </outputPort>
       </outputPorts>
       <components>
         <component componentID="1" access="read-reset">
           <name>IPv6ValidatorStats</name>
           <synopsis>IPv6 validator LFB statistics</synopsis>
           <optional/>
          <typeRef>uint32</typeRef>
        </capability>
      </capabilities>
           <typeRef>IPv6ValidatorStatisticsType</typeRef>
         </component>
       </components>
       <description>Detailed validation process could refer to RFC2460
        and RFC2373.</description>
     </LFBClassDef>
     <LFBClassDef LFBClassID="12">
      <name>Scheduler</name>
      <synopsis>Base scheduler LFB.</synopsis> LFBClassID="9">
       <name>IPv6UcastLPM</name>
       <synopsis>An LFB class definition for IPv6 longest prefix lookup
        function.</synopsis>
       <version>1.0</version>
       <inputPorts>
        <inputPort group="true">
          <name>Watcher</name>
          <synopsis>Input for watching the queues to be scheduled.
          Queues
         <inputPort>
           <name>PktIn</name>
           <synopsis>The port to be scheduled can transmit packet enqueue and
          dequeue infomation receive IPv6 packets needed to scheduler through these port</synopsis> do IPv4
            LPM.</synopsis>

           <expectation>
             <frameExpected>
              <ref>MetadataFrame</ref>
               <ref>IPv6</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>
         <outputPort>
           <name>SuccessOut</name>
           <synopsis>Output for packets that have find the correct
            route.</synopsis>
           <product>
             <frameProduced>
              <ref>MetadataFrame</ref>
               <ref>IPv6</ref>
             </frameProduced>
             <metadataProduced>
              <ref>QueueOperationCmd</ref>
               <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>QueueScheduledLimit</name>
          <synopsis>Max
           <name>PrefixTableLimit</name>
           <synopsis>maxium number of queues that can be scheduled prefix supported by this
          scheduler.</synopsis> 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>
      <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> 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>InControl</name>
          <synopsis>Input from scheduler</synopsis>
          <expectation>
            <metadataExpected>
              <ref>QueueOperationCmd</ref>
            </metadataExpected>
          </expectation>
        </inputPort>
        <inputPort>
          <name>InData</name>
           <name>PktIn</name>
           <synopsis>Input port for data packet.</synopsis> packets to be applicate nexthop.
           </synopsis>
           <expectation>
             <frameExpected>
              <ref>Arbitrary</ref>
               <ref> IPv6 </ref>
             </frameExpected>
             <metadataExpected>
              <ref>PacketLength</ref>
               <ref>NextHopID</ref>
             </metadataExpected>
           </expectation>
         </inputPort>
       </inputPorts>
       <outputPorts>
         <outputPort>
          <name>OutToController</name>
           <name>SuccessOut</name>
           <synopsis>Output to queue controller</synopsis> port for packet successfully fulfill the
            nexthop application.</synopsis>
           <product>
             <frameProduced>
              <ref>MetadataFrame</ref>
               <ref> IPv6 </ref>
             </frameProduced>
             <metadataProduced>
              <ref>QueueID</ref>
              <ref>PacketLength</ref>
              <ref>QueueOperationCmd</ref>
               <ref>FEID</ref>
               <ref>OutputPortID</ref>
               <ref availability="conditional">L2Index</ref>
               <ref>NextHopIPv6</ref>
               <ref availability="conditional">EncapMethod</ref>
             </metadataProduced>
           </product>
         </outputPort>
         <outputPort>
          <name>OutData</name>
          <synopsis>Data
           <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 output</synopsis>
          <product>
            <frameProduced>
              <ref>Arbitrary</ref>
            </frameProduced>
          </product>
        </outputPort>
      </outputPorts>
      <components>
        <component componentID="1">
          <name>CurLen</name>
          <synopsis>Current length of size.3 The outgoing port is same as the queue in number of packets.
          </synopsis>
          <typeRef>uint32</typeRef>
        </component>
      </components>
      <capabilities>
        <capability componentID="1">
          <name>QueueLenLimit</name>
          <synopsis>Maximum length of
              one on which the queue in number of packets.
          </synopsis>
          <typeRef>uint32</typeRef>
        </capability>
      </capabilities>
      <description>Queues have a packet input, a is received.4 The packet output, a
      control input, and is for
               a group of control outputs. The control ports
      represent local interface.</synopsis>
           <product>
             <frameProduced>
               <ref> IPv6 </ref>
             </frameProduced>
             <metadataProduced>
               <ref>InputPortID</ref>
               <ref>ExceptionID</ref>
             </metadataProduced>
           </product>
         </outputPort>
         <outputPort>
           <name>FailOutput</name>
           <synopsis>Output for packets failed the 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> nexthop application
            operation.</synopsis>
           <product>
             <frameProduced>
               <ref> IPv6 </ref>
             </frameProduced>
           </product>
         </outputPort>
       </outputPorts>
       <components>
         <component componentID="1">
          <name>WeightTable</name>
          <synopsis>Weight table for queues to be scheduled.
          </synopsis>
           <name> NextHopTable </name>
           <synopsis>Nexthop table</synopsis>
           <array type="variable-size">
            <typeRef>WeightTableEntryType</typeRef>
             <typeRef> IPv6NextHopInfoType </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
       <capabilities>
         <capability componentID="1">
           <name>NextHopTableLimit</name>
           <synopsis>Maxium number of ND protocol processing to FE.It process the following
      ND messages:neighbour solicitation and neighbour advertisement. nexthops this LFB supports
           </synopsis>
           <typeRef>uint32</typeRef>
         </capability>
       </capabilities>
     </LFBClassDef>
     <LFBClassDef LFBClassID="11">
       <name>EtherEncap</name>
       <synopsis>An LFB classifier definition for completes ethernet
        encapsulation fuctions</synopsis>
       <version>1.0</version>
       <inputPorts>
         <inputPort>
          <name>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
           <name>EncapIn</name>
           <synopsis>Port for receiving packets needed to address
          resolution.</synopsis> build Ethernet
            encapsulation.</synopsis>
           <expectation>
             <frameExpected>
               <ref>IPv4</ref>
               <ref>IPv6</ref>
             </frameExpected>
             <metadataExpected>
               <ref dependency="optional" defaultValue="0">L2Index</ref>
               <one-of>
                 <ref>NextHopIP</ref>
                 <ref>NextHopIPv6</ref>
               </one-of>
               <ref>PacketType</ref>
             </metadataExpected>
           </expectation>
         </inputPort>
       </inputPorts>
       <outputPorts>
         <outputPort>
          <name>AddrResDataPktOut</name>
          <synopsis>The IPv6 packet that have encapsulated with the
          correct ethernet L2 info and need to be sent out to link.
          </synopsis>
           <name>SuccessOut</name>
           <synopsis/>
           <product>
             <frameProduced>
               <ref>EthernetII</ref>
             </frameProduced>
           </product>

         </outputPort>
        <outputPort>
          <name>AddrResProtoPktOut</name>
          <synopsis>The IPv6 neighbour discovey packet wich has been
          encapsulation with
         <outputPort group="true">
           <name>ExceptionOut</name>
           <synopsis>packet can't find the correct ethernet associated L2 info.</synopsis> information
           </synopsis>
           <product>
             <frameProduced>
              <ref>EthernetII</ref>
               <ref>IPv4</ref>
               <ref>IPv6</ref>
             </frameProduced>
           </product>
         </outputPort>
       </outputPorts>
       <components>
         <component componentID="1">
          <name>Nbrtable</name>
          <synopsis>This table is an alias to the IPv6
           <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
          in the EtherEncap LFB.</synopsis>
          <alias>NbrTable</alias> for IPv4.
           </synopsis>
           <array>
             <typeRef>DCHostTableEntryTypev4</typeRef>
           </array>
         </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
         <component componentID="4">
           <name>DCHostTablev6</name>
           <synopsis>Direct connected host arp table 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> 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 IPv6 packet that need icmp processing. limit on Direct connected host table for IPv4.
           </synopsis>
          <expectation>
            <frameExpected>
              <ref>IPv6</ref>
            </frameExpected>
            <metadataExpected>
              <ref>ExceptionID</ref>
            </metadataExpected>
          </expectation>
        </inputPort>
      </inputPorts>
      <outputPorts>
        <outputPort>
          <name>ICMPv6PktOut</name>
           <typeRef>uint32</typeRef>
         </capability>
         <capability componentID="4">
           <name>DCHostTablev6Limit</name>
           <synopsis>The output limit on Direct connected host table for the ICMPv6 packets generated
          according to the input IPv6 packet and the ExceptionID. IPv6.
           </synopsis>
          <product>
            <frameProduced>
              <ref>IPv6</ref>
            </frameProduced>
          </product>
        </outputPort>
      </outputPorts>
           <optional/>
           <typeRef>uint32</typeRef>
         </capability>
       </capabilities>
     </LFBClassDef>
     <LFBClassDef LFBClassID="19">
      <name>ExtendHeaderProc</name>
      <synopsis>This LFB class process the IPv6 packet with extended
      header,For 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 moment,the packets queues to this LFB are redirect be scheduled.
           Queues to
      RedirectSink LFB by default.</synopsis>
      <version>1.0</version>
      <inputPorts>
        <inputPort>
          <name>PktIn</name>
          <synopsis>The IPv6 be scheduled can transmit packet with extended header in.</synopsis> enqueue and
           dequeue infomation to scheduler through these port.
           </synopsis>
           <expectation>
             <frameExpected>
              <ref>IPv6</ref>
               <ref>MetadataFrame</ref>
             </frameExpected>
             <metadataExpected>
               <ref>QueueID</ref>
               <ref>PacketLength</ref>
               <ref>QueueOperationCmd</ref>
             </metadataExpected>
           </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
           <name>OutControl</name>
           <synopsis>Control output,this output is used by default we send
          all the packet with extended header scheduler
           to CE.</synopsis> communicate commands to it's controlled queues such as
           dequeue a packet.</synopsis>
           <product>
             <frameProduced>
              <ref>IPv6</ref>
               <ref>MetadataFrame</ref>
             </frameProduced>
             <metadataProduced>
               <ref>QueueOperationCmd</ref>
             </metadataProduced>
           </product>
         </outputPort>
       </outputPorts>
       <capabilities>
         <capability componentID="1">
           <name>QueueScheduledLimit</name>
           <synopsis>Max number of queues that can be scheduled by this
           scheduler.</synopsis>
           <typeRef>uint32</typeRef>
         </capability>
       </capabilities>
     </LFBClassDef>
     <LFBClassDef LFBClassID="20">
      <name>arp</name>
      <synopsis>This LFB class provides the function of address
      resolution for IPv4 nodes.</synopsis> LFBClassID="13">
       <name> Queue </name>
       <synopsis>Queue LFB.</synopsis>
       <version>1.0</version>
       <inputPorts>
         <inputPort>
          <name>AddrResDataPktIn</name>
          <synopsis>The IPv4 data packet that need to do the address
          resolution.</synopsis>
           <name>InControl</name>
           <synopsis>Input from scheduler</synopsis>
           <expectation>
            <frameExpected>
              <ref>IPv4</ref>
            </frameExpected>
             <metadataExpected>
               <ref>QueueOperationCmd</ref>
             </metadataExpected>
           </expectation>
         </inputPort>
         <inputPort>
          <name>ArpPktIn</name>
          <synopsis>The neighbour discovery packet related to address
          resolution.</synopsis>
           <name>InData</name>
           <synopsis>Input port for data packet.</synopsis>
           <expectation>
             <frameExpected>
              <ref>IPv4</ref>
               <ref>Arbitrary</ref>
             </frameExpected>
             <metadataExpected>
               <ref>PacketLength</ref>
             </metadataExpected>
           </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
           <name>OutToController</name>
           <synopsis>Output to link.
          </synopsis> queue controller</synopsis>
           <product>
             <frameProduced>
              <ref>EthernetII</ref>
               <ref>MetadataFrame</ref>
             </frameProduced>
             <metadataProduced>
               <ref>QueueID</ref>
               <ref>PacketLength</ref>
               <ref>QueueOperationCmd</ref>
             </metadataProduced>
           </product>
         </outputPort>
         <outputPort>
          <name>ArpOut</name>
          <synopsis>The arp
           <name>OutData</name>
           <synopsis>Data packet out.</synopsis> output</synopsis>
           <product>
             <frameProduced>
              <ref>EthernetII</ref>
               <ref>Arbitrary</ref>
             </frameProduced>
           </product>
         </outputPort>
       </outputPorts>
       <components>
         <component componentID="1">
          <name>Arptable</name>
          <synopsis>This table is an alias
           <name>CurLen</name>
           <synopsis>Current length of the arp table queue in the
          EtherEncap LFB.</synopsis>
          <alias>ArpTable</alias> number of packets.
           </synopsis>
           <typeRef>uint32</typeRef>
         </component>
       </components>
       <capabilities>
         <capability componentID="1">
           <name>QueueLenLimit</name>
           <synopsis>Maximum length of the queue in number of packets.
           </synopsis>
           <typeRef>uint32</typeRef>
         </capability>
       </capabilities>
     </LFBClassDef>
     <LFBClassDef LFBClassID="21">
      <name>ICMPGenerator</name> LFBClassID="14">
       <name>RedirectSink</name>
       <synopsis>This LFB class provide some basic ICMP function,it only
      generate definition provides for the following ICMP messages:ICMP destination
      unreachable and time excceeded.</synopsis> function of
       sinking data packets that needed to be sent to CE. </synopsis>
       <version>1.0</version>
       <inputPorts>
        <inputPort>
          <name>PktIn</name>
          <synopsis>IPv4 packet that need icmp processing.</synopsis>
         <inputPort group="true">
           <name>InFromOtherLFBs</name>
           <synopsis>Packets input from other LFBs and needed to sent
           to CE.</synopsis>
           <expectation>
             <frameExpected>
               <ref>IPv4</ref>
               <ref>IPv6</ref>
             </frameExpected>
             <metadataExpected>
              <ref>ExceptionID</ref>
               <ref>InputPortID</ref>
               <ref>PacketLength</ref>
               <ref>PacketType</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> LFBClassID="15">
       <name>RedirectTap</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 sinking data of any
kind?The model says
       packets that variable  tag metadata do this need but
doesn't show how comes from CE and needed to use it.-->
          </expectation>
        </inputPort>
      </inputPorts> be sent out by this
       FE.</synopsis>
       <version>1.0</version>
       <outputPorts>
        <outputPort group="true">
          <name>ClassifiedOut</name>
          <synopsis>Output group for the classified packets.</synopsis>
         <outputPort group="true">
           <name>OutputToOtherLFBs</name>
           <synopsis>Packets input received from CE.</synopsis>
           <product>
             <frameProduced>
              <ref>Arbitrary</ref>
               <ref>IPv4</ref>
               <ref>IPv6</ref>
             </frameProduced>
             <metadataProduced>
               <ref>PacketType</ref>
               <ref>OutputPortID</ref>
               <ref>PacketLength</ref>
             </metadataProduced>
           </product>
         </outputPort>
       </outputPorts>
       <components>
         <component componentID="1">
          <name>MetaDataID</name>
           <name>DispatchTable</name>
           <synopsis>The metadata id that this classifier works on. table to dispatch the packets to different LFB.
           </synopsis>
          <typeRef>uint32</typeRef>
           <typeRef>DispatchTableType</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>
           <name>outGroupNumOfPorts</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
           <name>MaxNumOfoutGroupPorts</name>
           <synopsis>The maxium number of ports in the output group.
           </synopsis>
           <typeRef>uint32</typeRef>
         </capability>
       </capabilities>
     </LFBClassDef>
     <LFBClassDef LFBClassID="23">
      <name>OptionProc</name> 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 process provides the IPv4 packet with options,it
      can function of IPv6 address
       resolution part of neighbor discovery protocol.It provides an
       offload of ND protocol processing to FE.It process on the following options:Router-alert option.
       ND messages:neighbour solicitation and neighbour advertisement.
       </synopsis>
       <version>1.0</version>
       <inputPorts>
         <inputPort>
          <name>PktIn</name>
           <name>AddrResDataPktIn</name>
           <synopsis>The IPv4 IPv6 data packet with options in.</synopsis> that need to do the address
           resolution.</synopsis>
           <expectation>
             <frameExpected>
              <ref>IPv4</ref>
               <ref>IPv6</ref>
             </frameExpected>
           </expectation>
         </inputPort>
         <inputPort>
           <name>AddrResProtoPktIn</name>
           <synopsis>The neighbour discovery packet related to
           addresolution.</synopsis>
           <expectation>
             <frameExpected>
               <ref>IPv6</ref>
             </frameExpected>
           </expectation>
         </inputPort>
       </inputPorts>
       <outputPorts>
        <outputPort group="true">
          <name>PktOut</name>
          <synopsis>According to the Option type the
         <outputPort>
           <name>AddrResDataPktOut</name>
           <synopsis>The IPv6 packet may that have
          different next proccesing LFB.Now by default we send all the
          packet encapsulated 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
           correct ethernet L2 info 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 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 one or more ports for packets that been
           encapsulation with the Connectivity LFB has
      received and 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 handing an alias 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 IPv6 neighbour table
           in the EtherEncap LFB.</synopsis>
           <alias>NbrTable</alias>
         </component>

       </components>
     </LFBClassDef>
     <LFBClassDef LFBClassID="18">
       <name>ICMPv6Generator</name>
       <synopsis>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 class provide some basic ICMPv6 function,it
       only generate the following ICMP messages 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, that
       need some basic icmp processing:destination not reachable 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
       time excceeded.</synopsis>
       <version>1.0</version>
       <inputPorts>
         <inputPort>
           <name>PktIn</name>
           <synopsis>The IPv6 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 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 number of octets and ICMPv6 packets sent and received, generated
           according to the number of various input IPv6 packet and output
      errors, etc.</description> the ExceptionID.
           </synopsis>
           <product>
             <frameProduced>
               <ref>IPv6</ref>
             </frameProduced>
           </product>
         </outputPort>
       </outputPorts>
     </LFBClassDef>
     <LFBClassDef LFBClassID="65538">
      <name>RedirectLFB</name>
      <synopsis>An LFBClassID="19">
       <name>ExtendHeaderProc</name>
       <synopsis>This LFB Class definition for exchanging data packets
      between class process the FE and IPv6 packet with extended
       header,For the CE.</synopsis> moment,the packets to this LFB are redirect to
       RedirectSink LFB by default.</synopsis>
       <version>1.0</version>
       <inputPorts>
         <inputPort>
          <name>RedirectToCE</name>
          <synopsis>
               Port for frames to send to the CE.
             </synopsis>
           <name>PktIn</name>
           <synopsis>The IPv6 packet with extended header in.</synopsis>
           <expectation>
             <frameExpected>
              <ref>taggedFrame</ref>
               <ref>IPv6</ref>
             </frameExpected>
           </expectation>
         </inputPort>
       </inputPorts>
       <outputPorts>
        <outputPort>
          <name>RedirectFromCE</name>
          <synopsis>
               Port for frames
         <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 to all the CE
             </synopsis> packet with extended header to CE.</synopsis>
           <product>
             <frameProduced>
              <ref>taggedFrame</ref>
               <ref>IPv6</ref>
             </frameProduced>
           </product>
         </outputPort>
       </outputPorts>
      <description>This
     </LFBClassDef>
     <LFBClassDef LFBClassID="20">
       <name>arp</name>
       <synopsis>This LFB represents a point of exchagne class provides the function of address
       resolution for IPv4 nodes.</synopsis>
       <version>1.0</version>
       <inputPorts>
         <inputPort>
           <name>AddrResDataPktIn</name>
           <synopsis>The IPv4 data
      packets between the CE and packet that need to do the FE. Packets with meta-data are
      exchanged.  It is expected address
           resolution.</synopsis>
           <expectation>
             <frameExpected>
               <ref>IPv4</ref>
             </frameExpected>
           </expectation>
         </inputPort>
         <inputPort>
           <name>ArpPktIn</name>
           <synopsis>The neighbour discovery packet related to
           addresolution.</synopsis>
           <expectation>
             <frameExpected>
               <ref>IPv4</ref>
             </frameExpected>
           </expectation>
         </inputPort>
       </inputPorts>
       <outputPorts>
         <outputPort>
           <name>AddrResDataPktOut</name>
           <synopsis>The IPv4 packet that have been encapsulated with
           the output port of a RedirectLFB,
      if it is connected at all, will correct ethernet L2 info and need to be connected sent out to a meta-data
      redirector</description>
           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="65539">
      <name>IPv4Validator</name>
      <synopsis>An LFBClassID="21">
       <name>ICMPGenerator</name>
       <synopsis>This LFB Class definition for validates class provide some basic ICMP function,it
       only generate the IPv4 packet.
      </synopsis> following ICMP messages:ICMP destination
       unreachable and time excceeded.</synopsis>
       <version>1.0</version>
       <inputPorts>
         <inputPort>
          <name>ValidatorIn</name>
          <synopsis>
               Normal
           <name>PktIn</name>
           <synopsis>The IPv4 packet input. that need icmp processing.
           </synopsis>
           <expectation>
             <frameExpected>
               <ref>IPv4</ref>
             </frameExpected>
             <metadataExpected>
               <ref>ExceptionID</ref>

             </metadataExpected>
           </expectation>
         </inputPort>
       </inputPorts>
       <outputPorts>
         <outputPort>
          <name>ValidatorOut</name>
          <synopsis>
               Normal
           <name>ICMPPktOut</name>
           <synopsis>The output for the ICMP packets generated according
           to the input packet Output.
             </synopsis> and the ExceptionID.</synopsis>
           <product>
             <frameProduced>
              <ref>IPv4packet</ref>
               <ref>IPv4</ref>
             </frameProduced>
           </product>
         </outputPort>
        <outputPort>
          <name>FailOutput</name>
          <synopsis>The port to send
       </outputPorts>
     </LFBClassDef>
     <LFBClassDef LFBClassID="22">
       <name>MetadataClassifier</name>
       <synopsis>This LFB class provides the function of classify
       packets that 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 not match the classification.</synopsis>
           <expectation>
             <frameExpected>
               <ref>Arbitrary</ref>
             </frameExpected>
             <metadataExpected>
               <ref>Arbitrary</ref>
             </metadataExpected>
             <!-- jfg:how to express here that we only need one meta
             data of any
          entries.</synopsis> kind?The model says that variable  tag
             metadata do this need but doesn't show how to use it.-->
           </expectation>
         </inputPort>
       </inputPorts>
       <outputPorts>
         <outputPort group="true">
           <name>ClassifiedOut</name>
           <synopsis>The output group for the classified packets.
           </synopsis>
           <product>
             <frameProduced>
              <ref>taggedFrame</ref>
               <ref>Arbitrary</ref>

             </frameProduced>
            <metadataProduced>
              <ref>errorid</ref>
            </metadataProduced>
           </product>
         </outputPort>
       </outputPorts>
      <description>This LFB validates
       <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 IP version and header length
      fields, including verifying meta data that this classifier
           works on.</synopsis>
           <typeRef>string</typeRef>
         </component>
         <component componentID="3">
           <name>MetadataClassifyTable</name>
           <synopsis>The meta data classifying table.</synopsis>
           <typeRef>MetadataClassyTableType</typeRef>
         </component>
         <component componentID="4">
           <name>OutNumOfPorts</name>
           <synopsis>The number of ports in the packet length is at least as
      long as output group.</synopsis>
           <typeRef>uint32</typeRef>
         </component>
       </components>
       <capabilities>
         <capability componentID="1">
           <name>MaxOutNumOfPorts</name>
           <synopsis>Maxium number of ports in the header indicates.</description> output group.
           </synopsis>
           <typeRef>uint32</typeRef>
         </capability>
       </capabilities>
     </LFBClassDef>
     <LFBClassDef LFBClassID="65540">
      <name>IPv6Validator</name>
      <synopsis>An LFBClassID="23">
       <name>OptionProc</name>
       <synopsis>This LFB Class definition for validates class process the IPv6 packet. IPv4 packet with options,
       it can process on the following options:Router-alert option.
       </synopsis>
       <version>1.0</version>
       <inputPorts>
         <inputPort>
          <name>ValidatorIn</name>
          <synopsis>
               Normal
           <name>PktIn</name>
           <synopsis>The IPv4 packet input.
             </synopsis> with options in.</synopsis>
           <expectation>
             <frameExpected>
              <ref>IPv6</ref>
               <ref>IPv4</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
         <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 packets that do not match any
          entries.</synopsis> all
           the packet with extended header to CE.</synopsis>
           <product>
             <frameProduced>
              <ref>taggedFrame</ref>
               <ref>IPv4</ref>
             </frameProduced>
            <metadataProduced>
              <ref>errorid</ref>
            </metadataProduced>
           </product>
         </outputPort>
       </outputPorts>
      <description>This
     </LFBClassDef>
   </LFBClassDefs>
 </LFBLibrary>

8.  Base LFB validates Library Use Case for Typical Router Functions

   This section demonstrates examples on how the LFB classes defined by
   the Base LFB library in Section 7 are applied to the achievements of
   typical router functions.

   As mentioned in the overview section, typical router functions can be
   categorized in short into the following functions:

   o  IP version forwarding

   o  address resolution

   o  ICMP

   o  network management

   o  running routing protocol

   To achieve the functions, processing paths organized by the LFB
   classes with their interconnections should be established in FE.  In
   general, CE controls and header length
      fields, including verifying that manages the packet length is at least as
       long as processing paths by use of the header indicates.</description>
    </LFBClassDef>
    <LFBClassDef LFBClassID="65541">
      <name>PacketTrimmer</name>
      <!--XXX:Needs further discussion-->
      <synopsis>LFB removes data from
   ForCES protocol.

   Note that LFB class use cases shown in this section are only as
   examples to demonstrate how typical router functions can be
   implemented with the front defined base LFB library.  Users and
   implementors of the base LFB library should not be limited by the
   examples.

8.1.  IP Forwardings

   IP packets to be forwarded are from interfaces conneted via a 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 kind of
   media to outer networks.  A Port LFB receives link layer packets.  CE
   may control the port LFB status by the LFB components defined in the
   library.  Link layer packets without enough bytes are delivered to remove
             </synopsis>
          <product>
            <frameProduced>
              <ref>Packet</ref>
            </frameProduced>
          </product>
        </outputPort>
      </outputPorts>
      <components>
        <component componentID="1" access="read-write">
          <name>TrimLength</name>
          <synopsis>amount a decapsulation LFB to trim from each packet</synopsis>
          <typeRef>uint32</typeRef>
        </component>
      </components>
    </LFBClassDef>
    <LFBClassDef LFBClassID="65543">
      <name>Duplicator</name>
      <!--XXX:Needs further discussion-->
      <synopsis>An
   decapsulate to IP packets.  The LFB Class definition for also provides IP packet duplicator LFB. Any
   distinguishing by classifying IP packet received on an input port is logically copied and sent according 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 its types like
   IPv4 or IPv6, unicast or metadata, multicast, 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> ARP packet.  The group of ports to received packets over
             </synopsis>
          <expectation>
            <frameExpected>
              <ref>taggedFrame</ref>
            </frameExpected>
<!-- no metadataExpected item as any packet type
   information is included in a IPPacketType metadata and all meta data the metadata
   is allowed -->
          </expectation>
        </inputPort>
      </inputPorts>
      <outputPorts>
        <outputPort group="true">
          <name>SuccessOutput</name>
          <synopsis> associated with every decapsulated IP packet.

   Followed decapsulation LFBs are usually IP validation LFBs which
   further validate IP packets according to IP protocol.  The group of ports used by LFB also
   distinguishes if the classifer for output
               when a successful match is found.
             </synopsis>
          <product>
            <frameProduced>
              <ref>taggedFrame</ref>
            </frameProduced>
            <!-- no metaDataProduced as anything can IP packets are exceptional packets like ICMP
   packets other than IP packets to be produced -->
          </product>
        </outputPort>
        <outputPort group="false">
          <name>FailOutput</name>
          <synopsis> further forwarded.  The port to send
   exceptional 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 are then associated with metadata indicating the
   packet types and meta data tests, an array
          of delivered to metadata actions, classifier for specific
   classification and an exit selection.</synopsis>
          <array type="variable-size">
            <struct>
              <component componentID="1">
                <name>InputPortTest</name>
                <synopsis>If present,this match will only match further processing.

   Validated IP unicast packets
                arriving over the specified port.</synopsis>
                <optional/>
                <typeRef>uint32</typeRef>
              </component>
              <component componentID="2">
                <name>TestConditions</name>
                <synopsis>The array of conditions for forwarding are delivered 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 unicast
   Longes Prifix Match(UcastLPM) LFB, which produce nexthop information
   for forwarding.  The nexthop information is represented by a
   nexthopID metadata.

   IP packets with associated nexthop metadata are delivered to make the
   NextHopApplicator LFB.  The LFB decides output ports for the IP
   packets.  Note that when IP packets need to traverse FEs for
   forwarding, the match succeeds.</synopsis>
                <array type="variable-size">
                  <typeRef>MatchMetaDataAction</typeRef>
                </array>
              </component>
              <component componentID="4">
                <name>MatchOutputPort</name>
                <synopsis>The LFB may also only decides the local FE output port within to
   the success group other FE and makes the packet to send carry the nexthop information to
   that FE.

   IP packets which match these tests.</synopsis>
                <typeRef>uint32</typeRef>
              </component>
            </struct>
          </array>
        </component>

      </components>
    </LFBClassDef>
  </LFBClassDefs>
</LFBLibrary>
7. with nexthop applied are then encapsulated by a link layer
   encapsulation LFB Use Case

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

   Putting together the egress media and put on to the
   appropriate output ports.  In this process, address resolution LFBs
   may have to form a specific packet be applied to decide the link layer output addresses for
   the packets.  Moreover, the queue management LFBs and scheduler LFBs
   may be applied in the process to achieve individual QoS requirements.

   Figure 1 shows the typical LFB processing
   application

8. path for the IPv4 unicast
   forwarding case.

   Figure 1.  (TBD)

   Figure 2 shows the typical LFB processing path for the IPv6 unicast
   forwarding case.

   Figure 2.  (TBD)

8.2.  Address Resolution

   TBD

8.3.  ICMP

   TBD

8.4.  Running Routing Protocol

   TBD

8.5.  Network Management

   TBD

9.  Contributors

   The authors would like to thank Jamal Hadi Salim and Ligang Dong who
   made a major contribution to the development of this document.

      Jamal Hadi Salim
      Mojatatu Networks
      Ottawa, Ontario
      Canada
      Email: hadi@mojatatu.com

      Ligang Dong
      Zhejiang Gongshang University
      149 Jiaogong Road
      Hangzhou 310035
      P.R.China
      Phone: +86-571-28877751
      EMail: donglg@mail.zjgsu.edu.cn

9.

10.  Acknowledgements

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

10.

11.  IANA Considerations

   This memo includes no request to IANA.

11.

   (TBD)

12.  Security Considerations

   These definitions if used by an FE to support ForCES create
   manipulable entities on the FE.  Manipulation of such objects can
   produce almost unlimited effects on the FE.  FEs should ensure that
   only properly authenticated ForCES protocol participants are
   performing such manipulations.  Thus the security issues with this
   protocol are defined in the FE-protocol [I-D.ietf-forces-protocol].

12.

13.  References

12.1.

13.1.  Normative References

   [I-D.ietf-forces-model]
              Halpern, J. and J. Salim, "ForCES Forwarding Element
              Model", draft-ietf-forces-model-16 (work in progress),
              October 2008.

   [I-D.ietf-forces-protocol]
              Dong, L., Doria, A., Gopal, R., HAAS, R., Salim, J.,
              Khosravi, H., and W. Wang, "ForCES Protocol
              Specification", draft-ietf-forces-protocol-22 (work in
              progress), March 2009.

12.2.

13.2.  Informative References

   [RFC1812]  Baker, F., "Requirements for IP Version 4 Routers",
              RFC 1812, June 1995.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              July 2003.

   [RFC3654]  Khosravi, H. and T. Anderson, "Requirements for Separation
              of IP Control and Forwarding", RFC 3654, November 2003.

   [RFC3746]  Yang, L., Dantu, R., Anderson, T., and R. Gopal,
              "Forwarding and Control Element Separation (ForCES)
              Framework", RFC 3746, April 2004.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

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