Internet Engineering Task Force                                  W. Wang
Internet-Draft                             Zhejiang Gongshang University
Intended status: Informational Standards Track                           E. Haleplidis
Expires: September 4, 2010 April 20, 2011                             University of Patras
                                                                K. Ogawa
                                                         NTT Corporation
                                                                  F. Jia
                                              National Digital Switching
                                                            Center(NDSC)
                                                              J. Halpern
                                                                Ericsson
                                                           March 3,
                                                        October 17, 2010

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

Abstract

   The forwarding and Control Element Separation (ForCES) protocol

   This document 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 basic classes of Logical Function Blocks (LFBs), whose structure is
   defined (LFBs)
   used in a model RFC produced by the working group.In order Forwarding and Control Element Separation (ForCES).  It
   is defined according to
   build an actual solution using this protocol, there needs ForCES FE model [RFC5812] and ForCES protocol
   [RFC5810] specifications.  The basis classes of LFBs are defined to be a set
   meet requirements of Logical Function Block definitions that can be instantiated by FEs typical router functions.  Descriptions of
   individual classes of LFBs are presented and controlled by CEs.  This document provides a sample space detailed XML definitions
   are included.  As use instances, several use cases of such
   definitions.  It is anticipated that additional defining documents
   will be produced over time. the defined
   classes of LFBs to meet typical router functions are proposed in the
   document.

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. (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts.
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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 September 4, 2010. April 20, 2011.

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Terminology and Conventions  . . . . . . . . . . . . . . . . .  4
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
   2.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Overview
     3.1.  Scope of the Library . . . . . . . . . . . . . . . . . . .  7
     3.2.  Overview of LFB Classes in the Library . . . . . . . .  8
   5.  Base Types . .  9
     3.3.  Document Structure . . . . . . . . . . . . . . . . . . . . 10
   4.  Base Types . . . . 11
     5.1.  Data Types . . . . . . . . . . . . . . . . . . . . . . 11
     4.1.  Data . . 11
     5.2.  Frame Types . . . . . . . . . . . . . . . . . . . . . . . 13
     5.3.  MetaData Types . . 11
     4.2.  Frame  . . . . . . . . . . . . . . . . . . . . 14
     5.4.  XML Definition for Base Type Library . . . . . . 11
     4.3.  MetaData . . . . . 15
   6.  LFB Classes Description . . . . . . . . . . . . . . . . . . . 39
     6.1.  Core LFBs . 12
     4.4.  XML for Base Type Library  . . . . . . . . . . . . . . . . 12
   5.  LFB Class Description  . . . . . . . 39
       6.1.1.  FE Protocol LFB . . . . . . . . . . . . . 31
     5.1.  Ethernet Processing LFBs . . . . . . 39
       6.1.2.  FE Object LFB . . . . . . . . . . . 31
       5.1.1.  EtherPHYCop  . . . . . . . . . 39
     6.2.  Port LFBs . . . . . . . . . . . . 31
       5.1.2.  EtherMACIn . . . . . . . . . . . . 40
       6.2.1.  Generic Connectivity LFB . . . . . . . . . . 33
       5.1.3.  EtherClassifier  . . . . . 40
       6.2.2.  Ethernet Port LFBs . . . . . . . . . . . . . . 35
       5.1.4.  EtherEncapsulator  . . . . 41
       6.2.3.  POS Port LFBs . . . . . . . . . . . . . . 36
       5.1.5.  EtherMACOut  . . . . . . 41
       6.2.4.  ATM Port . . . . . . . . . . . . . . . 40
     5.2.  IP Packet Validation LFBs  . . . . . . . . . . . . . . . . 40
       5.2.1.  IPv4Validator  . . . . . . . . . . . . . . . . . . . . 41
     6.3.  Address Resolution LFBs
       5.2.2.  IPv6Validator  . . . . . . . . . . . . . . . . . . . . 41
     6.4.  ICMP
     5.3.  IP Forwarding LFBs . . . . . . . . . . . . . . . . . . . . 42
       5.3.1.  IPv4UcastLPM . . . . 42
     6.5.  IP Packet Validation LFBs . . . . . . . . . . . . . . . . 42
     6.6.  Classifier LFBs . 43
       5.3.2.  IPv4NextHopApplicator  . . . . . . . . . . . . . . . . 44
       5.3.3.  IPv6UcastLPM . . . . 42
     6.7.  Forwarding LFBs . . . . . . . . . . . . . . . . . 46
       5.3.4.  IPv6NextHopApplicator  . . . . 43
       6.7.1.  Unicast Longest Prefix Match LFBs . . . . . . . . . . 43
       6.7.2.  Nexthop Applicator . . 46
     5.4.  Address Resolution LFBs  . . . . . . . . . . . . . . . 43
     6.8.  QoS Control LFBs . . 46
       5.4.1.  ARP  . . . . . . . . . . . . . . . . . . . . . 43
       6.8.1.  Scheduler LFBs . . . . 46
       5.4.2.  ND . . . . . . . . . . . . . . . . 44
       6.8.2.  Queue . . . . . . . . . . 48
     5.5.  Redirect LFBs  . . . . . . . . . . . . . . . . . . . . . . 45
     6.9.  Miscellaneous Packet Manipulation 48
       5.5.1.  RedirectIn . . . . . . . . . . . . . . . . . . . . . . 48
       5.5.2.  RedirectOut  . . . . . . . . . . . . . . . . . . . . . 49
     5.6.  General Purpose LFBs . . . . . . . . . . 45
     6.10. Redirect LFB . . . . . . . . . 49
       5.6.1.  BasicMetadataDispatch  . . . . . . . . . . . . . . 45
   7. . . 49
       5.6.2.  GenericScheduler . . . . . . . . . . . . . . . . . . . 50
   6.  XML Definition for Base LFB Library  . . . . . . . . . . . . . 46
   8.  Base LFB Library . . . . . . . . 52
   7.  Use Case Library for Typical Router Functions . . . . 75
     8.1. . . . . . . . 77
     7.1.  IP Forwardings Forwarding  . . . . . . . . . . . . . . . . . . . . . . 75
     8.2. 77
     7.2.  Address Resolution . . . . . . . . . . . . . . . . . . . . 76
     8.3. 78
     7.3.  ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
     8.4. 79
     7.4.  Running Routing Protocol . . . . . . . . . . . . . . . . . 76
     8.5. 79
     7.5.  Network Management . . . . . . . . . . . . . . . . . . . . 76
   9. 79
   8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 77
   10. 80
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 78
   11. 81
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 79
   12. 82
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 80
   13. 83
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 81
     13.1. 84
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 81
     13.2. 84
     12.2. Informative References . . . . . . . . . . . . . . . . . . 81 84
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 82 85

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

   RFC 3746 [RFC3746] specifies Forwarding and Control Element
   Separation (ForCES) defines an
   architectural framework and associated protocols to standardize
   information exchange between framework.  In the control plane framework, Control Elements
   (CEs) configure and the forwarding
   plane in manage one or more separate Forwarding Elements
   (FEs) within a ForCES Network Element (ForCES NE).  [RFC3654]has defined
   the (NE) by use of a ForCES requirements, and [RFC3746] has defined protocol.  RFC
   5810 [RFC5810] specifies the ForCES
   framework.

   The ForCES protocol Protocol FE-protocol FE-protocol
   [I-D.ietf-forces-protocol] defines a protocol for communications
   between Control Elements (CEs) protocol.  RFC 5812 [RFC5812]
   specifies the Forwarding Elements (FEs) and for
   Control Elements to manipulate Element (FE) model.  In the model, resources
   in Forwarding Elements.
   Resources in Forwarding Elements FEs are described by classes of Logical Function Blocks (LFBs).
   The FE model documentFE-MODEL
   [I-D.ietf-forces-model]. specifies defines the structure and abstract semantics of LFBs,
   and provides XML schema for the definitions of LFBs.

   This document comforts to the specifications of the FE modelFE-MODEL
   [I-D.ietf-forces-model] model
   [RFC5812] and specifies detailed definitions of classes of LFBs,
   including detailed XML definitions of LFBs.  These LFBs
   which can form a base
   LFB library for ForCES.  LFBs in the base library are expected to be
   combined to provide functions of form an LFB topology for a typical router.  It
   basically provides functions router to implement IP
   forwarding.  More
   definitions  It should be emphasized that an LFB is an abstraction of
   functions rather than its implementation details.  The purpose of the
   LFB definitions is to represent functions so as to provide
   interoperability between separate CEs and FEs.

   More LFB classes with more functions may be developed in future time
   and documented by IETF, and users IETF.  Vendors may also develop their individual
   LFB classes for purposes of their specific functions according to the FE modelFE-MODEL [I-D.ietf-forces-model].

4.  Overview

   The model [RFC5812] for their specific
   purposes.

3.1.  Scope of the Library

   It is designated that the LFB classes described in this document are
   designed to provide the functions of a typical router.  RFC 1812
   specifies that a typical router [RFC1812] .  They are is expected to provide functions for a typical router to:

   o

   (1) Interface to packet networks and implement the functions required
   by that network.  These functions typically include:

      *

   o  Encapsulating and decapsulating the IP datagrams with the
      connected network framing (e.g., an Ethernet header and
         checksum),

      * checksum).

   o  Sending and receiving IP datagrams up to the maximum size
      supported by that network, this size is the network's Maximum
      Transmission Unit or MTU,

      * MTU.

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

      * and

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

   o

   (2) Conform to specific Internet protocols including the Internet
   Protocol (IPv4 and/or IPv6), Internet Control Message Protocol
   (ICMP), and others as necessary.

   o

   (3) Receive and forwards Internet datagrams.  Important issues in
   this process are buffer management, congestion control, and fairness.

      *

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

      *

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

      *

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

   o

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

   o

   (5) Usually support an interior gateway protocol (IGP) to carry out
   distributed routing and reachability algorithms with the other
   routers in the same autonomous system.  In addition, some routers
   will need to support an exterior gateway protocol (EGP) to exchange
   topological information with other autonomous systems.

   o

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

   According

   Within the ForCES framework, according to the ForCES architecture, all protocol
   [RFC5810] and the FE model [RFC5812] specifications, above typical
   router functions should be implemented upon under the concept of Logical
   Functional Blocks (LFBs).  It is critical  Taking a typical IP forwarding function as
   an example, some port LFBs receive packets and decapsulate the IP
   datagrams to classify above functional form IP level packets.  Different port media have
   different manipulating requirements
   into from CE, therefore various classes of port
   LFBs and construct a typical but also
   flexible enough base LFB library for various IP forwarding
   equipments.  In the process, some principles media may have to be applied:

   o  if defined.  IP packets from port
   LFBs are then validated before being further forwarded.  A kind of
   valildation LFBs are applied for the purpose.  After validation
   process, some LFBs for IP forwarding may then be applied.  In the
   Forwarding LFBs, a Longest Prefix Match LFB is used to look up the
   destination information in a packet and select a next hop index for
   sending the packet onward.  A next hop applicator LFB uses the next
   hop index metadata to apply the proper headers to the IP packets, and
   direct them to the proper egress.

3.2.  Overview of LFB Classes in the Library

   It is critical to classify functional requirements into various
   classes of LFBs and construct a typical but also flexible enough base
   LFB library for various IP forwarding equipments.  In the process,
   some principles may be applied:

   (1)if a function can be designed by either one LFB or two or more
   LFBs with the same cost, it will be designed by two or more LFBs so
   as to provide more flexibility for implementers.

   o  when

   (2)when flexibility is not required, an LFB should take advantage of
   its as much as possible independence and leave least couples with
   other LFBs.  The couples may be from LFB attributes definitions as
   well as physical implementations.

   o  unless

   (3)unless there is a difference in actual functionality, it should
   not represent the same thing in two different fashions.  Or else, it
   may add extra burden on implementation.

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

   For every
   requirements:

   o  A group of LFB classes, a set of Ethernet processing LFBs are defined to abstract the
      packet processing for
   individual function purposes.  Section 6(LFB Descriptions Section)
   describes individual LFBs in every group of LFBs in details.

   Based on Ethernet as the classes of LFBs, port media type.  As the
      most popular media type with rich processing features, Ethernet
      media processing LFBs also provide typical organization of the work for other media
      types.  Definitions for processing path and their interconnections can of other port media types like
      POS or ATM may be established by incorporated in the
   CE using library in future version of
      the ForCES protocol, so as to achieve typical router
   functions.  Taking a typical forwarding function as an example, Port document.

   o  A group of LFBs receive packets and decapsulate the are defined for IP datagrams packet validation process.
      Actually, only one LFB is currently defined specifi for individual
      IPv4 or IPv6 protocol validations.

   o  A group of LFBs are defined to form abstract IP
   level packets.  Different port media have different manipulating
   requirements from CE, therefore various port LFBs for various media
   may have forwarding process.  A
      unicast longest prefix match LFB and a followed next hop
      applicator LFB are applied to be defined. IP forwarding process.  Forwarding
      process for IPv4 and IPv6 packets from port are separated, therefore LFBs
      specifically for IPv4 and IPv6 are then validated
   before being further forwarded. separately defined.

   o  A kind group of valildation address resolution LFBs like IPv4
   validator and/or IPv6 valildator are applied defined for the purpose.  After
   validation, some packets for control purpose will be specifically
   processed, like ARP packets will be processed by an Address to
      abstract the process for address resolution function.  Actually,
      there is only one LFB and ICMP packets by an ICMP LFB.  To separate defined for individual IPv4 or IPv6 address
      resolution or neighbor discovery.  In IPv4 case, the
   control packets, a metadata classifier LFB is applied called
      ARP LFB and in IPv6 case, the process.
   After validation process, Forwarding LFBs can then be applied.  In
   the Forwarding LFBs, a Longest Prefix Match LFB is used called ND(neighbor discovery)
      LFB.

   o  A group of LFBs are defined to look up
   the destination information in a packet, and select abstract the next hop
   index to be used process for sending the redirect
      operation, i.e., data packet onward. transmission between CE and FEs.  A next hop
   applicator
      RedirectIn LFB uses describes the next hop index metadata process for CE to apply the proper
   headers inject packets to the IP packets,
      FE LFB paths, and direct them to a RedirectOut LFB abstracts the proper egress. process for
      various FE LFBs to send data packets to CE.

   o  A group of LFBs are defined for abstracting some general purpose
      packet processing.  These processing processes are usually general
      to many processing locations in some FE LFB topology.  Currently,
      two such LFBs are defined, a generic dispatch LFB and a generic
      scheduler LFB.

3.3.  Document Structure

   For every group of LFB classes, a set of LFBs are defined for
   individual function purposes.  Section 6 (LFB Descriptions Section)
   makes text descriptions in details on individual LFBs.  Note that for
   a complete definition of an LFB, a text description as well as a XML
   definition is required.

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

   To define various LFB classes, a set of base type definitions with
   the data types, packet frame types, and metadata types have to be
   specified in advance.  Section 5 (Base Types Section) provide a
   description on the base types used by this LFB library.  In order to
   provide an extensive use of these base types for other LFB
   definitions, the base type definitions are provided by a specific xml
   file as a base type library which is separate from the LFB definition
   library.

   LFB classes are finally defined by XML with specifications and schema
   from the ForCES FE modelFE-MODEL [I-D.ietf-forces-model]. model[RFC5812].  Section 6 (LFB Definitions
   Section) provide the complete XML definitions of the base LFB classes
   library.

5.

4.  Base Types

   The FE modelFE-MODEL [I-D.ietf-forces-model] model [RFC5812] has specified the following data types as
   predefined (built-in) atomic data-types:

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

   Based on these atomic data types and with the use of type definition
   elements in the FE model XML schema, new data types, packet frame
   types, and metadata types can further be defined.

   To define a base LFB library for typical router functions, a base
   data types, frame types, and metadata types MUST be defined.  This
   section provides a description of these types and a detailed XML
   definitions of for the base types.

   In order for extensive use of the base type definitions for other LFB
   definitions other than this base LFB library, the base type
   definitions are provided with a separate xml library file labeled
   with "BaseTypeLibrary".  Users can refer to this library by the
   statement:

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

5.1.

4.1.  Data Types

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

   1.   ifIndex - A Port Identifier.

   2.   IEEEMAC - IEEE MAC Address.

   3.   NetSpeedType - Network speed values.

   4.   IEEENegotiationType - IEEENegotiation types.

   5.   PortStatsType - Port statistics.

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

   7.   LocalIpAddrType - Local IP address belonging

   (TBD)

4.2.  Frame

   According to FE.

   8.   LocalIpv6AddrType - The device local IPv6 address infomation.

   9.   IPv4Addr - IPv4 address.

   10.  IPv6Addr - IPv6 address.

   11.  IPv4Prefix - IPv4 prefix defined by an address and a prefix
        length.

   12.  IPv4NextHopInfoType - IPv4 nexthop information,include nexthop
        ip address,output FE and interface etc.

   13.  IPv4FibEntryType - IPv4 forwarding table entry.

   14.  IPv4PrefixTableEntry - IPv4 prefix table entry.

   15.  IPv4UcastLPMStatisticsType - Statistics model [RFC5812], frame types are used in LFB
   definitions to define the types of IPv4UcastLPM LFB.

   16.  IPv4ValidatorStatisticsType - IPv4 validator frames the LFB statistics
        type.

   17.  IPv6Prefix - IPv6 prefix defined by an address expects at its
   input port(s) and a prefix
        length.

   18.  IPv6NextHopInfoType - IPv6 next hop information, include next
        hop ip address,output emits at its output port(s).  The <frameDef>
   element in the FE and interfac eetc.

   19.  IPv6PrefixTableEntry - IPv6 prefix table entry.

   20.  IPv6LPMClassiferStatisticsType - Statistics of IPv6 LPM
        ClassifierLFB.

   21.  IPv6ValidatorStatisticsType - IPv6 validator LFB statistics
        type.

   22.  NextHopFlagsType - Flags model 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 a new frame type.

   34.  IPAddress - IP layer address.

   35.  ArpStateType -

   The arp entry state.

   36.  MatchTargetType - Indicator for the kind of field to be matched
        by this entry in a classifier.

   37.  MatchTargetIdentifier - Identify the specific target of a match
        condition.

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

   39.  MatchCondition - Structure for a single condition to be applied.

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

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

   42.  NextHopIndex - An index used by the next hop table Typically
        stored in and generated as metadata by the longest-prefix-match
        LFB.

5.2.  Frame Types

   According to FE modelFE-MODEL [I-D.ietf-forces-model], following frame types are used currently defined and put in LFB definitions to define the base
   type library as base frame types of frames for the LFB
   expects at its input port(s) and emits at its output port(s). library:

   (TBD)

4.3.  MetaData

   LFB Metadata is used to communicate per-packet state from one LFB to
   another.  The
   <frameDef> <metadataDef> element in the FE model is used to define
   a new frame metadata type.

   The following frame metadata types are currently defined and put in the
   base type library as base frame metadata types for the LFB library:

   1.  EthernetII - An library
   definitions:

   (TBD)

4.4.  XML for Base Type Library

 <LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      provides="BaseTypeLibrary">
    <frameDefs>
       <frameDef>
          <name>EthernetII</name>
          <synopsis>An Ethernet II frame type.

   2.  Ethernet802.3 - An Ethernet 802.3 frame type.

   3.  Ethernet802.2 - An Ethernet 802.2 frame type.

   4.  Ethernet802.2SNAP - An Ethernet 802.2 with SNAP frame.

   5.  IPv4Frame - An IPv4 packet.

   6.  IPv6Frame - An IPv6 packet.

   7.  TaggedFrame - A frame of any type with associated metadata.

   8.  MetadataFrame - Frame only contains meta data.

   9.  Arbitrary - Any kind of frame except Metadata Frame.

5.3.  MetaData Types

   LFB Metadata is used to communicate per-packet state from one LFB to
   another.  The <metadataDef> element in the FE model is used to define
   a new metadata type.

   The following metadata types are currently defined and put in the
   base type library as base metadata types for the LFB library
   definitions:

   1.   NextHopID - An index into a Next Hop entry in Nexthop table.

   2.   ExceptionID - Exception Types.

   3.   IngressPort - At which interface the packet arrive.

   4.   EgressPort - The interface out which the packet will emmit.

   5.   NextHopIP - Nexthop IPv4 address.

   6.   NexthopIPv6 - Nexthop IPv6 address.

   7.   PacketLength - The length of the packet in octets.

   8.   IPPacketType - Type of the packet.

   9.   QueueID - The queue ID.

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

   11.  SrcFEID - Source FE ID.

   12.  DstFEID - Destination FE ID.

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

   14.  NHEncapMethod - How should the following LFBs do to encapsulate
        the packets.

   15.  ErrorId - Error Type.

5.4.  XML Definition for Base Type Library

  <?xml version="1.0" encoding="UTF-8"?>
  <LFBLibrary provides="BaseTypeLibrary"
   xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="urn:ietf:params:xml:ns:forces:lfbmodel:1.0
  SchemaFile.xsd">
  <description>
  This library provides base types definitions for LFB library.
  </description>
   <frameDefs> frame</synopsis>
       </frameDef>
       <frameDef>
        <name>EthernetII</name>
          <name>ARP</name>
          <synopsis>an Ethernet II frame type</synopsis> arp packet</synopsis>
       </frameDef>
       <frameDef>
        <name>Ethernet802.3</name>
          <name>IPv4</name>
          <synopsis>An Ethernet 802.3 frame type</synopsis> IPv4 packet</synopsis>
       </frameDef>
       <frameDef>
        <name>Ethernet802.2</name>
          <name>IPv6</name>
          <synopsis>An Ethernet 802.2 frame type</synopsis> IPv6 packet</synopsis>
       </frameDef>
       <frameDef>
        <name>Ethernet802.2SNAP</name>
          <name>IPv4Unicast</name>
          <synopsis>An Ethernet 802.2 with SNAP frame</synopsis> IPv4 unicast packet</synopsis>
       </frameDef>
       <frameDef>
        <name>IPv4</name>
          <name>IPv4Multicast</name>
          <synopsis>An IPv4 multicast packet</synopsis>
       </frameDef>
       <frameDef>
        <name>IPv6</name>
          <name>IPv6Unicast</name>
          <synopsis>An IPv6 unicast packet</synopsis>
       </frameDef>
       <frameDef>
        <name>MetadataFrame</name>
        <synopsis>Frame only contains meta data</synopsis>
          <name>IPv6Multicast</name>
          <synopsis>An IPv6 multicast packet</synopsis>
       </frameDef>
       <frameDef>
          <name>Arbitrary</name>
          <synopsis>Any kind kinds of frame except Metadata Frame.</synopsis> frames</synopsis>
       </frameDef>
    </frameDefs>
    <dataTypeDefs>
       <dataTypeDef>
        <name>IEEEMAC</name>
        <synopsis>IEEE mac.</synopsis>
        <typeRef>byte[6]</typeRef>
          <name>IPv4Addr</name>
          <synopsis>IPv4 address</synopsis>
          <typeRef>byte[4]</typeRef>
       </dataTypeDef>
       <dataTypeDef>
        <name>LANSpeedType</name>
        <synopsis>LAN
          <name>IPv6Addr</name>
          <synopsis>IPv6 address</synopsis>
          <typeRef>byte[16]</typeRef>
       </dataTypeDef>
       <dataTypeDef>
          <name>IEEEMAC</name>
          <synopsis>IEEE mac.</synopsis>
          <typeRef>byte[6]</typeRef>
       </dataTypeDef>
       <dataTypeDef>
         <name>LANSpeedType</name>
         <!-- <name>NetSpeedType</name> -->
         <synopsis>Network speed values</synopsis>
         <atomic>
          <baseType>uint32</baseType>
          <specialValues>
            <specialValue value="0x00000001">
             <name>LAN_SPEED_10M</name>
             <synopsis>10M Ethernet</synopsis>
            </specialValue>
            <specialValue value="0x00000002">
             <name>LAN_SPEED_100M</name>
             <synopsis>100M Ethernet</synopsis>
            </specialValue>
            <specialValue value="0x00000003">
             <name>LAN_SPEED_1G</name>
             <synopsis>1000M Ethernet</synopsis>
            </specialValue>
            <specialValue value="0x00000004">
             <name>LAN_SPEED_10G</name>
             <synopsis>10G Ethernet</synopsis>
            </specialValue>
            <specialValue value="0x00000005">
             <name>LAN_SPEED_AUTO</name>
             <synopsis>LAN speed auto</synopsis>
            </specialValue>
          </specialValues>
          <!-- XXX: This doesnt look like the SNMP
      definitions. We should look at the SNMP
      definitions for guidance; we should not have
      limitations that SNMP has such as being
      restricted to 32 bits"
      "refer to RFC 3635 ifSpeed and ifHighSpeed"
          -->
         </atomic>
       </dataTypeDef>
       <dataTypeDef>
        <name>NegotiationType</name>
        <synopsis>Negotiation
         <name>DuplexType</name>
         <!-- <typeRef>IEEENegotiationType</typeRef> -->
         <synopsis>Duplex 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>PortStatusValues</name>
         <synopsis>
               The possible values of status. Used for both
               administrative and operation status
             </synopsis>
         <atomic>
          <baseType>uchar</baseType>
          <specialValues>
            <specialValue value="0">
             <name>Disabled </name>
             <synopsis>the port is operatively disabled.</synopsis>

            </specialValue>
            <specialValue value="1">
             <name>UP</name>
             <synopsis>the port is up.</synopsis>
            </specialValue>
            <specialValue value="2">
             <name>Down</name>
             <synopsis>The port is down.</synopsis>
            </specialValue>
          </specialValues>
          <!-- XXX: We need to conform with Administrative and
               operational status -->
         </atomic>
       </dataTypeDef>
       <dataTypeDef>
         <name>PortStatsType</name>
        <synopsis>port
         <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> transmitted</synopsis>
            <typeRef>uint64</typeRef>
          </component>
          <component componentID="7">
            <name>OutBroadcastPkts</name>
            <synopsis>Number of broadcast packets transmitted
            </synopsis> transmitted</synopsis>
            <typeRef>uint64</typeRef>
          </component>
          <component componentID="8">
            <name>OutOcetes</name>
            <synopsis>Number of octets transmitted</synopsis>
            <typeRef>uint64</typeRef>
          </component>
          <component componentID="9">
            <name>InErrorPkts</name>
            <synopsis>Number of input error packets</synopsis>
            <typeRef>uint64</typeRef>
          </component>
          <component componentID="10">
            <name>OutErrorPkts</name>
            <synopsis>Number of output error packets</synopsis>
            <typeRef>uint64</typeRef>
          </component>
         </struct>
         <!-- XXX: Make sure we validate with SNMP Port Stats -->
       </dataTypeDef>
       <dataTypeDef>
        <name>PortStatusValues</name>
        <synopsis>
               The possible values
          <name>PHYPortStatsType</name>
          <synopsis>The content of status.  Used statistic for both
               administrative and operation status
            </synopsis>
        <atomic>
          <baseType>uchar</baseType>
          <specialValues>
            <specialValue value="0">
              <name>Disabled EtherPHYCop.</synopsis>
          <struct>
             <component componentID="1">
                <name>NumPacketsReceived</name>
                <synopsis>The number of packets received.</synopsis>
                <typeRef>uint64</typeRef>
             </component>
             <component componentID="2">
                <name>NumPacketsTransimtted</name>
                <synopsis>The number of packets transimtted.</synopsis>
                <typeRef>uint64</typeRef>
             </component>
             <component componentID="3">
                <name>NumPacketsDroped   </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>
        </atomic> number of packets droped.</synopsis>
                <typeRef>uint64</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
        <name>IPAddr</name>
        <synopsis>IPv4 address</synopsis>
        <typeRef>uint32</typeRef>
          <name>MACStatsType</name>
          <synopsis>The content of statistic for EtherPHYCop.</synopsis>
          <typeRef>contents</typeRef>

       </dataTypeDef>
       <dataTypeDef>
        <name>MacFilterTableEntryType</name>
        <synopsis>MAC filter
          <name>EtherDispatchTableType</name>
          <synopsis>the type of etherDispatch table entry</synopsis>
        <typeRef>IEEEMAC</typeRef>
      </dataTypeDef>
      <dataTypeDef>
        <name>LocalIpAddrType</name>
        <synopsis>The device local IP address infomation</synopsis> entry.</synopsis>
          <struct>
             <component componentID="1">
            <name>FEID</name>
            <synopsis>The FE on which the
                <name>LogicalPortID</name>
                <synopsis>Logical port ip resides</synopsis> ID.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="2">
            <name>IfIndex</name>
            <synopsis>port index on
                <name>EtherType</name>
                <synopsis>The EtherType value in the specified FE</synopsis> Ether head.
                </synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="3">
            <name>IPaddr</name>
            <synopsis>IP address of the port</synopsis>
            <typeRef>IPAddr</typeRef>
          </component>
          <component componentID="4">
            <name>netmask</name>
            <synopsis>netmask of this ip address</synopsis>
            <typeRef>IPAddr</typeRef>
          </component>
          <component componentID="5">
            <name>BcastAddr</name>
            <synopsis>The associated Broadcast address of the ip
            address </synopsis>
            <typeRef>IPAddr</typeRef>
                <name>OutputIndex</name>
                <synopsis>Group output port index.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
        <name>LocalIpv6AddrType</name>
        <synopsis>The device local IPv6 address infomation</synopsis>
          <name>VlanInputTableType</name>
          <synopsis>VLAN Output table entry type.</synopsis>
          <struct>
             <component componentID="1">
            <name>FEID</name>
                <name>IncomingPortID</name>
                <synopsis>The FE on which the incoming port ip resides</synopsis> ID.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="2">
            <name>IfIndex</name>
            <synopsis>port index on the specified FE</synopsis>
                <name>VlanID</name>
                <synopsis>VLAN ID.</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>
                <name>LogicalPortID</name>
                <synopsis>logical port ID.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
        <name>IPv4Addr</name>
        <synopsis>IPv4 address</synopsis>
        <typeRef> uint32</typeRef>
      </dataTypeDef>
      <dataTypeDef>
        <name>IPv6Addr</name>
        <synopsis>IPv6 address</synopsis>
        <typeRef>byte[16]</typeRef>
      </dataTypeDef>
      <dataTypeDef>
        <name>IPv4Prefix</name>
        <synopsis>
             prefix defined by an address and a prefix length
             </synopsis>
          <name>EtherClassifyStatsType</name>
          <synopsis>VLAN Output table entry type.</synopsis>
          <struct>
             <component componentID="1">
            <name>address</name>
            <synopsis>Address part</synopsis>
            <typeRef>IPv4addr</typeRef>
                <name>EtherType</name>
                <synopsis>The EtherType value</synopsis>
                <typeRef>uint32</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>PacketsNum</name>
                <synopsis>Packets number</synopsis>
                <typeRef>uint64</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
        <name> IPv4NextHopInfoType </name>
        <synopsis>IPv4 nexthop information,include nexthop ip address,
        output FE and interface etc.</synopsis>
          <name>IPv4ValidatorStatisticsType</name>
          <synopsis>Statistics type in IPv4validator.</synopsis>
          <struct>
             <component componentID="1">
            <name>NexthopID</name>
            <synopsis>nexthop id</synopsis>
                <name>badHeaderPkts</name>
                <synopsis>Number of bad header packets.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="2">
            <name>FEID</name>
            <synopsis>output FE id</synopsis>
                <name>badTotalLengthPkts</name>
                <synopsis>Number of bad total length packets.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="3">
            <name>OutputPortID</name>
            <synopsis>output port index</synopsis>
                <name>badTTLPkts</name>
                <synopsis>Number of bad TTL packets.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="4">
            <name>MTU</name>
            <synopsis>The maximum transmition unit
                <name>badChecksum</name>
                <synopsis>Number of the nexthop
            link.</synopsis> bad checksum packets.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
          <name>IPv6ValidatorStatisticsType</name>
          <synopsis>Statistics type in IPv6validator.</synopsis>
          <struct>
             <component componentID="5">
            <name> Flags </name>
            <synopsis>Associated flags componentID="1">
                <name>badHeaderPkts</name>
                <synopsis>Number of the nexthop,such as local
            delivery,multicast etc.</synopsis>
            <typeRef>NextHopFlagsType</typeRef> bad header packets.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="6">
            <name> NexthopIPaddr </name>
            <synopsis>IP address componentID="2">
                <name>badTotalLengthPkts</name>
                <synopsis>Number of the nexthop</synopsis>
            <typeRef>IPv4Addr</typeRef>
          </component>
          <component componentID="7">
            <name> L2Index </name>
            <synopsis>index into the L2 link layer table,such as IPv4
            ARP table or IPv6 NBR table.</synopsis> bad total length packets.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="8">
            <name> EncapNeeded </name>
            <synopsis>The type componentID="3">
                <name>badHopLimitPkts</name>
                <synopsis>Number of encapsulation needed on the packet.
            </synopsis>
            <typeRef>EncapType</typeRef> bad Hop limit packets.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
        <name>IPv4FibEntryType</name>
        <synopsis>IPv4 forwarding table entry.</synopsis>
          <name>IPv4PrefixTableType</name>
          <synopsis>Each row of the IPv4 Prefix Table</synopsis>
          <struct>
             <component componentID="1">
            <name>prefix</name>
            <synopsis>IPv4 prefix.</synopsis>
            <typeRef>IPv4Prefix</typeRef>
                <name>IPv4Address</name>
                <synopsis>An IPv4 Address</synopsis>
                <typeRef>IPv4Addr</typeRef>
             </component>
             <component componentID="2">
            <name>FEID</name>
            <synopsis>output FE id</synopsis>
            <typeRef>uint32</typeRef>
                <name>Prefixlen</name>
                <synopsis>The prefix length</synopsis>
                <atomic>
                   <baseType>uchar</baseType>
                   <rangeRestriction>
                      <allowedRange min="0" max="32"/>
                   </rangeRestriction>
                </atomic>
             </component>
             <component componentID="3">
            <name>OutputPortID</name>
            <synopsis>output port index</synopsis>
                <name>HopSelector</name>
                <synopsis>HopSelector is the nexthop ID which points to
                the nexthop table</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="4">
            <name>MTU</name>
            <synopsis>The maximum transmition unit of the nexthop link.
                <name>ECMPFlag</name>
                <synopsis>An ECMP Flag for this route</synopsis>
                <atomic>
                   <baseType>boolean</baseType>
                   <specialValues>
                      <specialValue value="false">
                         <name>False</name>
                         <synopsis>This route does not have multiple
                         nexthops.</synopsis>
                      </specialValue>
                      <specialValue value="true">
                         <name>True</name>
                         <synopsis>This route has multiple nexthops.
                         </synopsis>
            <typeRef>uint32</typeRef>
                      </specialValue>
                   </specialValues>
                </atomic>
             </component>
             <component componentID="5">
            <name> Flags </name>
            <synopsis>Associated flags of
                <name>DefaultRouteFlag</name>
                <synopsis>A Default Route Flag for supporting loose RPF.
                </synopsis>
                <atomic>
                   <baseType>boolean</baseType>
                   <specialValues>
                      <specialValue value="false">
                         <name>False</name>
                         <synopsis>This is not a default route.
                         </synopsis>
                      </specialValue>
                      <specialValue value="true">
                         <name>True</name>
                         <synopsis>This route is a default route. for
                         supporting the nexthop,such as local
             delivery,multicast etc.</synopsis>
            <typeRef>NextHopFlagsType</typeRef>
          </component>
          <component componentID="6">
            <name> NexthopIPaddr </name>
            <synopsis>IP address of the nexthop</synopsis>
            <typeRef>IPv4Addr</typeRef>
          </component>
          <component componentID="7">
            <name> L2Index </name>
            <synopsis>index into the L2 link layer table,such as IPv4
             ARP table or IPv6 NBR table.</synopsis>
            <typeRef>uint32</typeRef>
          </component>
          <component componentID="8">
            <name> EncapNeeded </name>
            <synopsis>The type of encapsulation needed on the packet.
            </synopsis>
            <typeRef>EncapType</typeRef> loose RPF.</synopsis>
                      </specialValue>
                   </specialValues>
                </atomic>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
        <name>IPv4PrefixTableEntry</name>
        <synopsis>IPv4 prefix table entry</synopsis>
          <name>IPv6PrefixTableType</name>
          <synopsis>Each row of the IPv6 Prefix Table</synopsis>
          <struct>
             <component componentID="1">
            <name> Prefix </name>
            <synopsis>IPv4 address prefix</synopsis>
            <typeRef> IPv4Prefix </typeRef>
                <name>IPv6Address</name>
                <synopsis>An IPv6 Address</synopsis>
                <typeRef>IPv6Addr</typeRef>
             </component>
             <component componentID="2">
            <name> NexthopID </name>
            <synopsis>Index into
                <name>Prefixlen</name>
                <synopsis>The prefix length</synopsis>
                <atomic>
                   <baseType>uchar</baseType>
                   <rangeRestriction>
                      <allowedRange min="0" max="128"/>
                   </rangeRestriction>
                </atomic>
             </component>
             <component componentID="3">
                <name>HopSelector</name>
                <synopsis>HopSelector is the nexthop table.</synopsis> ID which points
                to the nexthop table</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="4">
                <name>ECMPFlag</name>
                <synopsis>An ECMP Flag for this route</synopsis>
                <atomic>
                   <baseType>boolean</baseType>
                   <specialValues>
                      <specialValue value="false">
                         <name>False</name>
                         <synopsis>This route does not have multiple
                         nexthops.</synopsis>
                      </specialValue>
                      <specialValue value="true">
                         <name>True</name>
                         <synopsis>This route has multiple nexthops.
                         </synopsis>
                      </specialValue>
                   </specialValues>
                </atomic>
             </component>
             <component componentID="5">
                <name>DefaultRouteFlag</name>
                <synopsis>A Default Route Flag.</synopsis>
                <atomic>
                   <baseType>boolean</baseType>
                   <specialValues>
                      <specialValue value="false">
                         <name>False</name>
                         <synopsis>This is not a default route.
                         </synopsis>
                      </specialValue>
                      <specialValue value="true">
                         <name>True</name>
                         <synopsis>This route is a default route.
                         </synopsis>
                      </specialValue>
                   </specialValues>
                </atomic>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
        <name> IPv4UcastLPMStatisticsType </name>
        <synopsis>statistics
          <name>NexthopOptionType</name>
          <synopsis>Special Values of IPv4UcastLPM LFB</synopsis> NextHopOption Type</synopsis>
          <atomic>
             <baseType>uint8</baseType>
             <specialValues>
                <specialValue value="1">
                   <name>Normal</name>
                   <synopsis>Normal Forwarding</synopsis>
                </specialValue>
                <specialValue value="2">
                   <name>Local</name>
                   <synopsis>The packet need to be forwarded to locally
                   attached host</synopsis>
                </specialValue>
             </specialValues>
          </atomic>
       </dataTypeDef>
       <dataTypeDef>
          <name>IPv4NextHopTableType</name>
          <synopsis>Each row of the IPv4 NextHop Table</synopsis>
          <struct>
             <component componentID="1">
            <name> InRcvdPkts </name>
            <synopsis>The total number
                <name>NexthopID</name>
                <synopsis>ID of input packets received from
             interfaces, including those received in error</synopsis>
            <typeRef>uint64</typeRef> the NextHop</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="2">
            <name> FwdPkts </name>
            <synopsis>IPv4 packet forwarded by this LFB</synopsis>
            <typeRef>uint64</typeRef>
                <name>OutputLogicalPortID</name>
                <synopsis>The ID of the Logical OutputPort</synopsis>
                <typeRef>uint32</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>
                <name>MTU</name>
                <synopsis>Maximum Transmission Unit for out going port.
               It is for desciding whether the packet need fragmentation
                </synopsis>
                <typeRef>uint32</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>
                <name>NexthopIPAddr</name>
                <synopsis>Next Hop IPv4 Address</synopsis>
                <typeRef>IPv4Addr</typeRef>
             </component>
             <component componentID="5">
                <name>NexthopOption</name>
                <synopsis>Next Hop Option</synopsis>
                <typeRef>NexthopOptionType</typeRef>
             </component>
             <component componentID="6">
                <name>EncapOutputIndex</name>
                <synopsis>Group output port index</synopsis>
                <typeRef>uint32</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
        <name> IPv4ValidatorStatisticsType </name>
        <synopsis>IPv4 validator LFB statistics type</synopsis>
          <name>ArpTableType</name>
          <synopsis>ARP table entry type.</synopsis>
          <struct>
             <component componentID="1">
            <name> badHeaderPkts </name>
            <synopsis>The total number of input datagrams with bad ip
            header</synopsis>
            <typeRef>uint64</typeRef>
                <name>LogicalPortID</name>
                <synopsis>Logical port ID.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="2">
            <name> badTotalLengthPkts </name>
            <synopsis>The total number of input datagrams with bab
            length</synopsis>
            <typeRef>uint64</typeRef>
                <name>DstIPv4Address</name>
                <synopsis>Destination IPv4 address.</synopsis>
                <typeRef>IPv4Addr</typeRef>
             </component>
             <component componentID="3">
            <name> badTTLPkts </name>
            <synopsis>The total number
                <name>DstMac</name>
                <synopsis>Mac of input datagrams with bad TTL
            </synopsis>
            <typeRef>uint64</typeRef> the Neighbor.</synopsis>
                <typeRef>IEEEMAC</typeRef>
             </component>
             <component componentID="4">
            <name> badChecksum</name>
            <synopsis>The total number of input datagrams with bad
             checksum</synopsis>
            <typeRef>uint64</typeRef>
                <name>SrcMac</name>
                <synopsis>Source MAC.</synopsis>
                <typeRef>IEEEMAC</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
        <name>IPv6Prefix</name>
          <name>NbrTableType</name>
          <synopsis>IPv6 prefix</synopsis> neighbour table entry type.</synopsis>
          <struct>
             <component componentID="1">
            <name>IPv6addr</name>
            <synopsis>address part of the prefix</synopsis>
            <typeRef>IPv6Addr</typeRef>
                <name>LogicalPortID</name>
                <synopsis>Logical port ID.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="2">
            <name>prefixlen</name>
            <synopsis>length
                <name>DstIPv6Address</name>
                <synopsis>Destination IPv4 address.</synopsis>
                <typeRef>IPv6Addr</typeRef>
             </component>
             <component componentID="3">
                <name>DstMac</name>
                <synopsis>Mac of the prefix</synopsis>
            <typeRef>uint32</typeRef> Neighbor.</synopsis>
                <typeRef>IEEEMAC</typeRef>
             </component>
             <component componentID="4">
                <name>SrcMac</name>
                <synopsis>Source MAC.</synopsis>
                <typeRef>IEEEMAC</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
        <name> IPv6NextHopInfoType </name>
        <synopsis>IPv4 nexthop information,include nexthop ip address,
        output FE and interface etc.</synopsis>
          <name>VlanOutputTableType</name>
          <synopsis>Vlan Output table entry type.</synopsis>
          <struct>
             <component componentID="1">
            <name>NexthopID</name>
            <synopsis>nexthop id</synopsis>
                <name>LogicalPortID</name>
                <synopsis>Logical port ID.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="2">
            <name>FEID</name>
            <synopsis>output FE id</synopsis>
                <name>VlanID</name>
                <synopsis>VLAN ID.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="3">
            <name>OutputPortID</name>
            <synopsis>output
                <name>OutputLogicalPortID</name>
                <synopsis>Output logical port index</synopsis> ID.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
          <name>Portv4AddressInforType</name>
          <synopsis>Port address information, for v4 port.</synopsis>
          <struct>
             <component componentID="4">
            <name>MTU</name>
            <synopsis>The maximum transmition unit of the nexthop link.
            </synopsis>
            <typeRef>uint32</typeRef> componentID="1">
                <name>IPv4Address</name>
                <synopsis>IPv4 address</synopsis>
                <typeRef>IPv4Addr</typeRef>
             </component>
             <component componentID="5">
            <name> Flags </name>
            <synopsis>Associated flags of the nexthop,such as local
             delivery,multicast etc.</synopsis>
            <typeRef>NextHopFlagsType</typeRef> componentID="2">
                <name>IPv4NetMask</name>
                <synopsis>IPv4 net mask length</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="6">
            <name> NexthopIPv6addr </name>
            <synopsis>IP address of the nexthop</synopsis>
            <typeRef>IPv6Addr</typeRef> componentID="3">
                <name>SrcMAC</name>
                <synopsis>Source Mac address</synopsis>
                <typeRef>IEEEMAC</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
          <name>Portv4AddrInfoTableType</name>
          <synopsis>Logical port (v4) address information table type
          </synopsis>
          <struct>
             <component componentID="7">
            <name> L2Index </name>
            <synopsis>index into the L2 table</synopsis> componentID="1">
                <name>LogicalPortID</name>
                <synopsis>Logical port id.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="8">
            <name> EncapNeeded </name>
            <synopsis>The type of encapsulation needed on the packet.
            </synopsis>
            <typeRef>EncapType</typeRef> componentID="2">
                <name>Portv4AddrInfo</name>
                <synopsis></synopsis>
                <array>
                   <typeRef>Portv4AddressInforType</typeRef>
                </array>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
        <name>IPv6PrefixTableEntry</name>
        <synopsis>IPv6 prefix
          <name>MetadataDispatchTableType</name>
          <synopsis>Metadata dispatch table entry</synopsis> type.</synopsis>
          <struct>
             <component componentID="1">
            <name> Prefix </name>
            <synopsis>IPv6 address prefix</synopsis>
            <typeRef> IPv6Prefix </typeRef>
                <name>MetadataID</name>
                <synopsis>metadata ID</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="2">
            <name> NexthopID </name>
            <synopsis>index to the nexthop table.</synopsis>
                <name>MetadataValue</name>
                <synopsis>metadata value.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="3">
                <name>OutputIndex</name>
                <synopsis>group output port index.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
        <name> IPv6LPMClassiferStatisticsType </name>
        <synopsis>statistics
          <name>SchdDisciplineType</name>
          <synopsis>scheduling discipline type.</synopsis>
          <atomic>
             <baseType>uint32</baseType>
             <specialValues>
                <specialValue value="1">
                   <name>FIFO</name>
                   <synopsis>First In First Out scheduler.</synopsis>
                </specialValue>
                <specialValue value="2">
                   <name>RR</name>
                   <synopsis>Round Robin.</synopsis>
                </specialValue>
             </specialValues>
          </atomic>
       </dataTypeDef>
       <dataTypeDef>
          <name>QueueDepthType</name>
          <synopsis>the Depth of IPv6LPMClassifier LFB</synopsis> Queue.</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>
                <name>QueueID</name>
                <synopsis>Queue ID</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="2">
            <name> FwdPkts </name>
            <synopsis>IPv4 packet forwarded by this LFB</synopsis>
            <typeRef>uint64</typeRef>
                <name>QueueDepthInPackets</name>
                <synopsis>the Queue Depth when the depth units
                are packets.</synopsis>
                <typeRef>uint32</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>
                <name>QueueDepthInBytes</name>
                <synopsis>the Queue Depth when the depth units
                are bytes.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
        <name> IPv6ValidatorStatisticsType </name>
        <synopsis>IPv6 validator LFB statistics type</synopsis>
          <name>MetaDispatchTableType</name>
          <synopsis>Metadata dispatch table type.</synopsis>
          <struct>
             <component componentID="1">
            <name> badHeaderPkts </name>
            <synopsis>The total number of input datagrams with bad ip
             header</synopsis>
            <typeRef>uint64</typeRef>
                <name>metadataID</name>
                <synopsis>metadata ID</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="2">
            <name> badTotalLengthPkts </name>
            <synopsis>The total number of input datagrams with bab
             length</synopsis>
            <typeRef>uint64</typeRef>
                <name>MetadataValue</name>
                <synopsis>metadata value.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="3">
            <name> badTTLPkts </name>
                <name>OutputIndex</name>
                <synopsis>group output port index.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
          </struct>
       </dataTypeDef>
    </dataTypeDefs>
    <metadataDefs>
       <metadataDef>
          <name>PHYPortID</name>
          <synopsis>The total number physical port ID that a packet has entered.
          </synopsis>
          <metadataID>1</metadataID>
          <typeRef>uint32</typeRef>
       </metadataDef>
       <metadataDef>
          <name>SrcMAC</name>
          <synopsis>Source MAC Address</synopsis>
          <metadataID>2</metadataID>
          <typeRef>IEEEMAC</typeRef>
       </metadataDef>
       <metadataDef>
          <name>DstMAC</name>
          <synopsis>Destination MAC Address</synopsis>
          <metadataID>3</metadataID>
          <typeRef>IEEEMAC</typeRef>
       </metadataDef>
       <metadataDef>
          <name>LogicalPortID</name>
          <synopsis>ID of input datagrams with bad
             TTL</synopsis>
            <typeRef>uint64</typeRef>
          </component>
          <component componentID="4">
            <name> badChecksum</name> logical port.</synopsis>
          <metadataID>4</metadataID>
          <typeRef>uint32</typeRef>
       </metadataDef>
       <metadataDef>
          <name>EtherType</name>
          <synopsis>The total number value of input datagrams with bad
             checksum</synopsis>
            <typeRef>uint64</typeRef>
          </component>
        </struct>
      </dataTypeDef>
      <dataTypeDef>
        <name> NextHopFlagsType </name>
        <synopsis>Flags used EtherType.</synopsis>
          <metadataID>5</metadataID>
          <typeRef>uint32</typeRef>
       </metadataDef>
       <metadataDef>
          <name>VlanID</name>
          <synopsis>Vlan ID.</synopsis>
          <metadataID>6</metadataID>
          <typeRef>uint32</typeRef>
       </metadataDef>
       <metadataDef>
          <name>VlanPriority</name>
          <synopsis>The priority of Vlan.</synopsis>
          <metadataID>7</metadataID>
          <typeRef>uint32</typeRef>
       </metadataDef>
       <metadataDef>
          <name>NexthopIPv4Addr</name>
          <synopsis>Nexthop IP address.</synopsis>
          <metadataID>8</metadataID>
          <typeRef>IPv4Addr</typeRef>
       </metadataDef>
       <metadataDef>
          <name>NexthopIPv6Addr</name>
          <synopsis>Nexthop IP address.</synopsis>
          <metadataID>9</metadataID>
          <typeRef>IPv6Addr</typeRef>
       </metadataDef>
       <metadataDef>
          <name>HopSelector</name>
          <synopsis>HopSelector is the nexthop ID which points to define different the
          nexthop behaviors table </synopsis>
          <metadataID>10</metadataID>
          <typeRef>uint32</typeRef>
       </metadataDef>
       <metadataDef>
       <name>ExceptionID</name>
       <!-- XXX: Needs more discussion. See that it applies to
         all LFBs. -->
       <synopsis>Exception Types</synopsis>
       <metadataID>11</metadataID>
       <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> value="0">
                <name>Other</name>
                <synopsis>Any other exception.</synopsis>
             </specialValue>
             <specialValue value="0x00000002">
              <name>drop</name>
              <synopsis>Packets match the nexthop entry value="1">
                <name>BroadCastPacket</name>
                <synopsis>Packet with this flag
               are destination address equal to be
              dropped.</synopsis>
                255.255.255.255</synopsis>
             </specialValue>
             <specialValue value="0x00000004">
              <name>broadcast</name> value="2">
                <name>BadTTL</name>
                <synopsis>The route associated packet can't be forwarded as the TTL has
                expired.</synopsis>
             </specialValue>
             <specialValue value="3">
                <name>IPv4HeaderLengthMismatch</name>
                <synopsis>IPv4 Packet with this nexthop is a
               broadcast.</synopsis> header length > 5</synopsis>
             </specialValue>
             <specialValue value="0x00000008">
              <name>multicast</name> value="4">
                <name>LengthMismatch</name>
                <synopsis>The route associated with this nexthop packet length reported by link layer is
               multicast.</synopsis>
                less than the total length field.</synopsis>
             </specialValue>
          </specialValues>
        </atomic>
      </dataTypeDef>
      <dataTypeDef>
        <name>WeightTableEntryType</name>
        <synopsis>Weight table for queues.</synopsis>
        <struct>
          <component componentID="1">
            <name>QueueID</name>
            <synopsis>queue id</synopsis>
            <typeRef>uint32</typeRef>
          </component>
          <component componentID="2">
            <name>weight</name>
            <synopsis>weight of the queue.</synopsis>
            <typeRef>uint32</typeRef>
          </component>
        </struct>
      </dataTypeDef>
      <dataTypeDef>
        <name>NbrState</name>
        <synopsis>IPv6 neighbour entry resolution state.</synopsis>
        <atomic>
          <baseType>uchar</baseType>
          <specialValues>
             <specialValue value="0x01">
              <name>INCOMPLETE </name>
              <synopsis>Address resolution value="5">
                <name>RouterAlertOptions</name>
                <synopsis>Packet IP head include Router Alert options.
                </synopsis>
             </specialValue>
             <specialValue value="6">
                <name>RouteInTableNotFound</name>
                <synopsis>There is being performed on no route in the
               entry.Specifically, a Neighbor Solicitation has been
               sent route table
                corresponding to the solicited-node multicast packet destination address of the
               target,but the corresponding Neighbor Advertisement
               has not yet been received.</synopsis>
                </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> value="7">
                <name>NextHopInvalid</name>
                <synopsis>The NexthopID is invalid</synopsis>
             </specialValue>
             <specialValue value="0x03">
              <name>STALE</name>
              <synopsis>More value="8">
                <name>FragRequired</name>
                <synopsis>The MTU for outgoing interface is less 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 size.</synopsis>
             </specialValue>
             <specialValue value="9">
                <name>LocalDelivery</name>
                <synopsis>The 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 for 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. local interface.
                </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 value="10">
                <name>GenerateICMP</name>
                <synopsis>ICMP packet was sent within the last
               DELAY_FIRST_PROBE_TIME seconds.  If no reachability
               confirmation needs to be generated.</synopsis>
             </specialValue>
             <specialValue value="11">
                <name>PrefixIndexInvalid</name>
                <synopsis>The prefixIndex is received within DELAY_FIRST_PROBE_TIME
                seconds of entering wrong.</synopsis>
             </specialValue>
             <specialValue value="12">
                <name>ArpTableL2NotFound</name>
                <synopsis>Packet can't find the DELAY state, send a Neighbor
                Solicitation and change associated L2
                information in the state to PROBE.</synopsis> Arptable</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> value="13">
                <name>OutputLogiclPortIDNotFound</name>
                <synopsis>Packet can't find OutputLogicalPortID in
                VLANOutputTable</synopsis>
             </specialValue>
             <specialValue value="14">
                <name>IPv6HopLimitZero</name>
                <synopsis>Packet with Hop Limit zero </synopsis>
             </specialValue>
             <specialValue value="15">
                <name>IPv6NextHeaderHBH</name>
                <synopsis>Packet with next header set to Hop-by-Hop
                </synopsis>
             </specialValue>
          </specialValues>
       </atomic>
      </dataTypeDef>
      <dataTypeDef>
        <name>ArpTableEntryType</name>
        <synopsis>Arp entry.</synopsis>
        <struct>
          <component componentID="1">
            <name>Index</name>
            <synopsis>Index
       </metadataDef>
       <metadataDef>
          <name>OutputLogicalPortID</name>
          <synopsis>ID of the arp table.</synopsis> output logical port.</synopsis>
          <metadataID>12</metadataID>
          <typeRef>uint32</typeRef>
          </component>
          <component componentID="2">
            <name>NeighborIP</name>
            <synopsis>IP address of the neighbour.</synopsis>
            <typeRef>IPv4Addr</typeRef>
          </component>
          <component componentID="3">
            <name>SrcMac</name>
            <synopsis>Source MAC.</synopsis>
            <typeRef>IEEEMAC</typeRef>
          </component>
          <component componentID="4">
            <name>NeighborMac</name>
            <synopsis>Mac of the Neighbor.</synopsis>
            <typeRef>IEEEMAC</typeRef>
          </component>
          <component componentID="5">
            <name>State</name>
            <synopsis>The state of the address resolution progress.
            </synopsis>
            <typeRef>ArpStateType</typeRef>
          </component>
        </struct>
      </dataTypeDef>
      <dataTypeDef>
        <name>NbrTableEntryType</name>
        <synopsis>IPv6 neighbour table entry.</synopsis>
        <struct>
          <component componentID="1">
            <name>Index</name>
            <synopsis>Index
       </metadataDef>
       <metadataDef>
          <name>RedirectIndex</name>
          <synopsis>Redirect Output port index.</synopsis>
          <metadataID>13</metadataID>
          <typeRef>uint32</typeRef>
       </metadataDef>
    </metadataDefs>
 </LFBLibrary>

5.  LFB Class Description

   According to ForCES specifications, LFB (Logical Function Block) is a
   well defined, logically separable functional block that resides in an
   FE, and is a functionally accurate abstraction of the FE's processing
   capabilities.  An LFB Class (or type) is a template that represents a
   fine-grained, logically separable aspect of FE processing.  Most LFBs
   are related to packet processing in the data path.  LFB classes are
   the basic building blocks of the FE model.  Note that RFC 5810 has
   already defined an 'FE Protocol LFB' that is defined as a logical
   entity in each FE to control the ForCES protocol.  RFC 5812 has
   already defined an 'FE Object LFB' that is defined to make the FE
   information easily accessible to CE.  Information like the FE Name,
   FE ID, FE State, LFB Topology in the FE are represented in this LFB.

   As mentioned in section 3, this document intends to provide a base
   LFB library for implementing typical router functions, especially for
   IP forwarding functions.  As a result, LFB classes defined here are
   base LFBs to implement router forwarding.

5.1.  Ethernet Processing LFBs

   As the most popular physical and data link layer protocols, Ethernets
   are widely deployed.  It becomes a basic requirement for a router to
   be able to process various Ethernet data packets.

   Note that there exist different versions of Ethernet protocols, like
   Ethernet V2, 802.3 RAW, IEEE 802.3/802.2, IEEE 802.3/802.2 SNAP.
   There also exist varieties of LAN techniques based on Ethernet, like
   various VLANs, MACinMAC, etc.  Ethernet processing LFBs defined here
   are intended to be able to cope with all these variations of Ethernet
   technology.

   There are also various types of Ethernet physical interface media.
   Among them, copper and fiber media may be the most popular ones.  As
   a base LFB definition and a start work, the document only defines an
   Ethernet physical LFB with copper media.  For other media interfaces,
   specific LFBs may be defined in the future versions of the library.

5.1.1.  EtherPHYCop

   EtherPHYCop LFB abstracts an Ethernet interface at its physical
   layer.  It limits the physical media to copper.

   The LFB is defined with one singleton input.  The input data of the
   LFB are expected to be Ethernet packets.  Note that Ethernet packets
   here cover all packets encapsulated with different versions of
   Ethernet protocols, like Ethernet V2, 802.3 RAW, IEEE 802.3/802.2,
   IEEE 802.3/802.2 SNAP.  It also includes packets encapsulated with
   varieties of LAN techniques based on Ethernet, like various VLANs,
   MACinMAC, etc.  As a result, we define various Ethernet frames as a
   frame name called 'EthernetAll'.  In an LFB abstracted processing
   path in an FE, usually the Ethernet packets are from an upstream LFB
   like an EtherMACOut LFB.  It is not expected that an input Ethernet
   packet be associated with some metadata.  After the LFB receives the
   Ethernet packets, it will further process the packets at physical
   layer and eventually put them on the physical media wire for
   transmission.  Note that the media wire transmission process in the
   LFB is abstracted as a default function of the LFB rather than an
   input or output interface of the LFB.

   The LFB is also defined with one singleton output.  The output data
   produced are also with 'EthernetAll' frame type.  Every output data
   packet is associated with a 'PHYPortID' metadata to indicate later
   processing LFBs of which physical port the packet is from.  Note that
   all the data packets are originated from media wire inside the LFB,
   which is defined as a default function of the LFB.  As a physical
   layer abstraction module, the LFB does not possess the ability to
   specify encapsulations of types of Ethernet, rather, it produces
   various Ethernet types just according to what it receives from
   Ethernet media wire.  In an LFB-based processing path topology,
   packets output from the EtherPHYCop lFB will usually go to an LFB
   like EtherMACIn LFB for further Ethernet processing.

   Note that as a base definition, functions like multiple virtual
   physical layers are not supported in this LFB version.  It may be
   supported in the future by defining a subclass or a new version of
   this LFB.

   Several components are defined for the LFB.

   AdminStatus is defined for CE to administratively manage the status
   of the LFB.  Via the component, CE may startup or shutdown the LFB.
   The default status is set to 'Down'.  Note that as a physical layer
   LFB for whole Ethernet processing, the administrative status
   configuration of this LFB will simultaneously affect status of
   related Ethernet processing LFBs.  An 'Up' or 'Down' of the LFB
   actually mean the whole Ethernet interface 'Up' or 'Down' with all
   the Ethernet processing ability.  To meet this, A OperStatus
   component is defined in all Ethernet related processing LFBs like
   EtherMACIn, EtherClassifier, EtherEncap, and EtherMACOut LFBs to
   reflect the physical layer administrative status.  A
   PHYPortStatusChanged event is defined for the LFB to report to CE
   whenever there is a port status change during operation.

   PHYPortID component is defined for CE to assign an ID to the physical
   port.  The component will be used to produce a metadata associated
   with every Ethernet packet the LFB receives from media and is going
   to hand to later LFBs for further processing.

   A group of components are defined for link speed management.  The
   AdminLinkSpeed is for CE to configure proper link speed for the port
   and the OperLinkSpeed is for CE to query the actual link speed in
   operation.  The default value for the AdminLinkSpeed is set to auto-
   negotiation mode.  A SupportedLinkSpeed capability attribute is also
   defined for CE to query the link speed ability.  A LinkSpeedChanged
   event is defined for the LFB to report to CE whenever there is a link
   speed change during operation.

   A group of components are defined for duplex mode management.  The
   AdminDuplexMode is for CE to configure proper duplex mode for the
   port and the OperDuplexMode is for CE to query the actual duplex mode
   in operation.  The default value for the AdminDuplexMode is set to
   auto-negotiation mode.  A SupportedDuplexMode capability is also
   defined for CE to query the port duplex mode ability.

   There are also some other components, capabilities, events defined in
   the LFB for various purposes.  See section 6 for detailed XML
   definitions of the LFB.

5.1.2.  EtherMACIn

   EtherMACIn LFB abstracts an Ethernet port at MAC data link layer.  It
   specifically describes Ethernet processing functions like MAC address
   locality check, deciding if the Ethernet packets should be bridged,
   provide Ethernet layer flow control, etc.

   The LFB is defined with one singleton input.  The input is expected
   to receive all types of Ethernet packets which are usually output
   from some Ethernet physical abstraction layer LFB, like an
   EtherPHYCop LFB.  Every input packet is associated with a metadatum
   indicating the physical port ID that the packet comes.

   Input Ethernet packets will usually be checked for locality.  A
   LocalMACAddresses component is defined for the LFB so that CE is able
   to configure one or more Ethernet MAC addresses to the LFB for the
   use of locality check.  All packets that do not pass through the
   locality check will be dropped in the LFB.  A PromiscuousMode
   component in the LFB is further defined to decide if the LFB should
   work in a promiscuous mode.  In this mode, the LFB will not do the
   locality check and all Ethernet packets will pass through the LFB
   without being dropped.

   The LFB is defined with two separate singleton outputs.  All Output
   packets are in Ethernet format, possibly with various Ethernet types.
   One singleton output is called NormalPathOut.  It usually outputs
   Ethernet packets to some LFB like an EtherClassifier LFB for further
   L3 forwarding process.  Metadata associated with every packet from
   this output is PHYPortID, which keeps indicating which physical port
   the packet is from.

   Another singleton output is called L2BridgingPathOut.  Although this
   LFB library is basically defined to meet typical router functions, it
   is with natural requirement that the definitions here should provide
   reasonable compatibility considerations for future wider use.  The
   L2BridgingPathOut is defined to meet the requirement that L2 bridging
   functions may be optionally supported simultaneously with L3
   processing and Some L2 bridging LFBs may be defined in the future.  A
   Boolean flag component called L2BridgingPathEnable is defined to make
   the L2 bridging output as optional.  An FE that does not support
   bridging will internally set this flag to false, and additionally
   sets the flag property as read-only.  In this case CE then can read
   the flag to know that the FE does not support bridging function and
   the L2 bridging output is always disabled.  An FE that supports L2
   bridging will internally set the flag property as read-write.  In
   this case, CE then can choose to enable or disable the
   L2BridgingPathOut output by setting this flag as desired.  If the
   flag is set to true, by also instantiating some L2 bridging LFB
   instances following the L2BridgingPathOut, FE are expected to fulfill
   L2 bridging functions.  Whereas, in this case, the default value for
   the flag is defined as false, meaning L2 bridging output is closed by
   default.  Note that, when enabled, l2BridgingPathOut will output
   packets exactly the same as that in the NormalPathOut
   output(Editorial note: need more discussions here on if the L2 output
   is the same as normal output).  The metadata associated with every
   packet is also PHYPortID.

   Ethernet layer flow control is usually implemented cooperatively by
   EtherMACIn LFB and EtherMACOut LFB.  How the flow control is
   implemented is vendor-specific.  As an abstraction, this LFB defines
   two flag components for CE to enable or disable the flow control
   functions.  The flow control is further distinguished by Tx flow
   control and Rx flow control, separately for sending process and
   receiving process flow controls.  A TxFlowControl flag and a
   RxFlowControl flag are then separately defined.  In order for
   EtherMACOut LFB able to cooperatively work for flow control, the
   flags are also referenced in the EtherMACOut LFB as aliases in this
   LFB.

   An OperStatus component is also defined in the LFB for CE to read
   operation status of the LFB.  Note that the status will be
   administratively managed via AdminStatus in the physical port LFB
   that the LFB usually rely on. /*how to describe the relationship
   between the adminstatus and the operstatus is still a problem */

   Note that as a base definition, functions like multiple virtual MAC
   layers are not supported in this LFB version.  It may be supported in
   the future by defining a subclass or a new version of this LFB.

   There are also some other components, capabilities, events defined in
   the LFB for various purposes.  See section 6 for detailed XML
   definitions of the LFB.

5.1.3.  EtherClassifier

   EtherClassifier LFB abstracts the process to decapsulate Ethernet
   packets and classify the data packets into various network layer data
   packets according to information included in the Ethernet packets
   headers.

   Input of the LFB expects all types of Ethernet packets, including
   VLAN Ethernet types.  The input is a singleton input which may
   connect to an upstream LFB like EtherMACIn LFB.  The input is also
   capable of multiplexing to allow for multiple upstream LFBs being
   connected.  For instance, when L2 bridging function is enabled in
   EtherMACIn LFB, some L2 bridging LFBs may be applied.  In this case,
   some Ethernet packets after L2 processing may have to be input to
   EtherClassifier LFB for classification, while simultaneously packets
   directly output from EtherMACIn may also need to input to this LFB.
   Input of this LFB is capable of handling this case.  Usually, every
   input Ethernet packet is expected to be associated with a PHYPortID
   metadatum, indicating the physical port the packet comes from.  In
   some cases, for instance, like in an MACinMAC case, a LogicalPortID
   metadatum may be expected to associate with the Ethernet packet to
   further indicate which logical port the Ethernet packet belongs to.
   Note that PHYPortID metadata is always expected while LogicalPortID
   metadata is optionally expected.

   A VLANInputTable component is defined in the LFB to classify VLAN
   Ethernet packets.  According to IEEE VLAN specifications, all
   Ethernet packets can be recognized as VLAN types by defining that if
   there is no VLAN encapsulation in a packet, a case with VLAN tag 0 is
   considered.  Therefore the table actually applies to every input
   packet of the LFB.  The table assigns every input packet with a new
   LogicalPortID according to the packet incoming port ID and the VLAN
   ID.  A packet incoming port ID is defined as a physical port ID if
   there is no logical port ID associated with the packet, or a logical
   port ID if there is a logical port ID associated with the packet.
   The VLAN ID is exactly the Vlan ID in the packet if it is a VLAN
   packet, or 0 if it is not a VLAN packet.  Note that a logical port ID
   of a packet may be rewritten with a new one by the VLANInputTable
   processing.

   An EtherDispatchTable component is defined to dispatch every Ethernet
   packet to a group of outputs according to the logical port ID
   assigned by VLANInputTable to the packet and the Ethernet type in the
   Ethernet packet header.  By CE configuring the dispatch table, the
   LFB can be expected to classify various network layer protocol type
   packets and make them output at different output port.  It is then
   easily expected that the LFB classify packets according to protocols
   like IPv4, IPv6, MPLS, ARP, ND, etc.

   Output of the LFB is hence defined as a group output.  Because there
   may be various types of protocol packets at the output ports, the
   frameproduced is defined as arbitrary for the purpose of wide
   extensibility in the future.  In order for downstream LFBs to use, a
   bunch of metadata is produced to associate with every output packet.
   The medatdata contain normal information like PHYPortID.  It also
   contains information on Ethernet type, source MAC address, and
   destination MAC address of its original Ethernet packet.  Moreover,
   it contains information of logical port ID assigned by this LFB.
   This metadata may be used by downstream LFBs for packet processing.
   Lastly, it may conditionally contain information like VlanID and
   VlanPriority with the condition that the packet is a VLAN packet.

   A MaxOutPutPorts is defined as the capability of the LFB to indicate
   how many classification output ports the LFB is capable.
   /*discussion*/

   Note that logical port ID and physical port ID mentioned above are
   all originally configured by CE, and are globally effective within an
   ForCES NE (Network Element).  To distinguish a physical port ID from
   a logical port ID in the incoming port ID field of the
   VLANInputTable, physical port ID and logical port ID must be assigned
   with separate number spaces. /*discussion */

   There are also some other components, capabilities, events defined in
   the LFB for various purposes.  See section 6 for detailed XML
   definitions of the LFB.

5.1.4.  EtherEncapsulator

   EtherEncapsulator LFB abstracts the process to encapsulate IP packets
   to Ethernet packets.

   Input of the LFB expects types of IP packets, including IPv4 and IPv6
   types.  The input is a singleton one which may connect to an upstream
   LFB like an IPv4NextHopApplicator, an IPv6NextHopApplicator, or any
   LFB which requires to output packets for Ethernet encapsulation.  The
   input is capable of multiplexing to allow for multiple upstream LFBs
   being connected.  For instance, an IPv4NextHopApplicator or an
   IPv6NextHopApplicator may concurrently exist, and some L2 bridging
   LFBs may also output packets to this LFB simultaneously.  Input of
   this LFB is capable of handling this case.  Usually, every input
   Ethernet packet is expected to be associated with an output logical
   port ID and a next hop IP address as its metadata.  In the case when
   L2 bridging function is implemented, an input packet may also
   optionally receive a VLAN priority as its metadata.  In this case,
   default value for this metadata is set to 0.

   There are several outputs for this LFB.  One singleton output is for
   normal success packet output.  Packets which have found Ethernet L2
   information and have been successfully encapsulated to an Ethernet
   packet will output from this port to downstream LFB.  Note that this
   LFB specifies to use Ethernet II as its Ethernet encapsulation type.
   Success output also produces an output logical port ID as metadatum
   of every output packet for a downstream LFB to decide which logical
   port the packet should go out.  The downstream LFB usually dispatches
   the packets based on its associated output logical port ID.  Hence, a
   generic dispatch LFB as defined in Section 5.6.1 may be adopted for
   dispatching packets based on output logical port ID.

   Note that in some implementations of LFBs topology, the processing to
   dispatch packets based on an output logical port ID may also take
   place before an Ethernet encapsulation,i.e., packets coming into the
   encapsulator LFB have already been switched to individual logical
   output port paths.  In this case, the EtherEncap LFB success output
   may be directly connected to a downstream LFB like an EtherMACOut
   LFB.

   Another singleton output is for IPv4 packets that are unfortunately
   unable to find Ethernet L2 encapsulation information by ARP table in
   the LFB.  In this case, a copy of the packets may need to be
   redirected to an ARP LFB in the FE, or to CE if ARP function is
   implemented by CE.  More importantly, a next hop IP address metadata
   should be associated with every packet output here.  When an ARP LFB
   or CE receives these packets and associated next hop IP address
   metadata, it may be expected to generate ARP protocol messages based
   on these packets next hop IP addresses to try to get L2 information
   for these packets.  Refreshed L2 information is then able to be added
   in ARP table in this encapsulator LFB by ARP LFB or by CE.  As a
   result, these packets are then able to successfully find L2
   information and be encapsulated to Ethernet packets, and output via
   the normal success output to downstream LFB.  (Editorial note1: may
   need discussion on what more metadata this output packets need?  Note
   that the packets may be redirected to CE and CE should know what the
   purpose of the packets for.  A metadata may need to indicate this.
   Editorial note2: we may adopt another way to address the case of
   packets unable to do ARP.  The packets may be redirected to ARP LFB
   or CE without keeping a copy of them in this encapsulator LFB.  We
   expect that after ARP LFB or CE have processed ARP requests based on
   the packets, the packets will be redirected back from ARP LFB or CE
   to this encapsulator LFB for Ethernet encapsulation.  At this time,
   it is hoped the ARP table has been refreshed with new L2 information
   that will make these packets able to find)

   A more singleton output is for IPv6 packets that are unfortunately
   unable to find Ethernet L2 encapsulation information by Neighbor
   table in the LFB.  In this case, a copy of the packets may need to be
   redirected to an ND LFB in the FE, or to CE if IPv6 Neighbor
   discovery function is implemented by CE.  More importantly, a next
   hop IP address metadata should be associated with every packet output
   here.  When the ND LFB or CE receives these packets and associated
   next hop IP address metadata, it may be expected to generate neighbor
   discovery protocol messages based on these packets next hop IP
   addresses to try to get L2 information for these packets.  Refreshed
   L2 information is then able to be added in neighbor table in this LFB
   by ND LFB or by CE.  As a result, these packets are then able to
   successfully find L2 information and be encapsulated to Ethernet
   packets, and output via the normal success output to downstream
   LFB.(Editorial note: may need discussion on what more metadata this
   output packets need?  Note that the packets may be redirected to CE
   and CE should know what the purpose of the packets for.  A metadata
   may need to indicate this)

   A singleton output is specifically defined for exception packets
   output.  All packets that are abnormal during the operations in this
   LFB are output via this port.  Currently, only one abnormal case is
   defined, that is, packets can not find proper information in a VLAN
   output table.

   The VLAN output table is defined as the component of the LFB.  The
   table uses a logical port ID as an index to find a VLAN ID and a new
   output logical port ID.  In reality, the logical port ID applied here
   is the output logical port ID received from every input packet in its
   associated metadata.  According to IEEE VLAN specifications, all
   Ethernet packets can be recognized as VLAN types by defining that if
   there is no VLAN encapsulation in a packet, a case with VLAN tag 0 is
   considered.  Therefore, every input IP packet actually has to look up
   the VLAN output table to find out a VLAN ID and a new output logical
   port ID according to its original logical port ID.

   The ARP table in the LFB is defined as a component of the LFB.  The
   table is for IPv4 packet to find its next hop Ethernet layer MAC
   addresses.  Input IPv4 packet will use an output logical port ID
   which is got by looking up the VLAN output table, and a next hop IPv4
   address which is got by upstream next hop applicator LFB, to look up
   the ARP table to find the Ethernet L2 information, i.e., the source
   MAC address and destination MAC address.

   The neighbor table is defined as another component of the LFB.  The
   table is for IPv6 packet to find its next hop Ethernet layer MAC
   addresses.  Like the ARP table, input IPv6 packet will use its output
   logical port ID got from looking up the VLAN output table, and the
   packet next hop IPv4 address got by upstream next hop applicator LFB,
   to look up the neighbor table to find the Ethernet source MAC address
   and destination MAC address.

   As will be described in the address resolution LFBs section (section
   5.4), Layer 2 address resolution protocols may be implemented with
   two choices.  One is by FE with specific address resolution LFB, like
   an ARP LFB or an ND LFB.  The other is to redirect address resolution
   protocol messages to CE for CE to implement the function.

   As described in section 5.4, the ARP LFB defines the ARP table in
   this encapsulator LFB as its alias, and the ND LFB defines the
   neighbor table as its alias.  This means that the ARP table or the
   neighbor table will be maintained or refreshed by the ARP LFB or the
   ND LFB when the LFBs are used.

   Note that the ARP table and the neighbor table defined in this LFB
   are all with property of read-write.  CE can also configure the
   tables by ForCES protocol [RFC5810].  This makes possible that IPv4
   ARP protocol or IPv6 Neighbor Discovery protocol may be implemented
   at CE side,i.e., after CE manages an ARP or Neighbor discovery
   protocol and gets address resolution results, CE can configure them
   to an ARP or neighbor table in FE.

   With all the information got from VLAN table and ARP or Neighbor
   table, input IPv4 or IPv6 packets are then able to be encapsulated to
   Ethernet layer packets.  Note that according to IEEE 802.1Q, if input
   packets are with non-zero VLAN priority metadata, the packets will
   always be encapsulated with a VLAN tag, no matter the value of VLAN
   ID is zero or not.  If the VLAN priority and the VLAN ID are all
   zero, the packets will be encapsulated without a VLAN tag.
   Successfully encapsulated packets are then output via success output
   port.

   There are also some other components, capabilities, events defined in
   the LFB for various purposes.  See section 6 for detailed XML
   definitions of the LFB.

5.1.5.  EtherMACOut

   EtherMACOut LFB abstracts an Ethernet port at MAC data link layer.
   It specifically describes Ethernet packet output process.  Ethernet
   output functions are closely related to Ethernet input functions,
   therefore many components defined in this LFB are actually alias of
   EtherMACIn LFB.

   The LFB is defined with one singleton input(Editorial note: do we
   need another input for L2 bridging input?).  The input is expected to
   receive all types of Ethernet packets which are usually output from
   some Ethernet encapsulation LFB.  Every input packet is associated
   with a metadatum indicating the physical port ID that the packet will
   go(Editorial note: Ethernet encapsulation LFB actually generate
   logical port ID metadata, how has it been changed to physical port
   ID?).

   The LFB is defined with a singleton output.  All Output packets are
   in Ethernet format, possibly with various Ethernet types.  Downstream
   LFB the output links to is usually Ethernet physical LFBs like
   EtherPHYcop LFB.  Metadata associated with every packet from this
   output is PHYPortID, which keeps indicating which physical port the
   packet is to.

   Ethernet layer flow control is usually implemented cooperatively by
   EtherMACIn LFB and EtherMACOut LFB.  How the flow control is
   implemented is vendor-specific.  As an abstraction, this LFB defines
   two flag components for CE to enable or disable the flow control
   functions, a TxFlowControl flag and a RxFlowControl flag, and they
   are all defined as aliases of EtherMACIn LFB.

   An OperStatus component is also defined in the LFB as an alias of
   EtherMACIn LFB, so as for CE to read operation status of the LFB.

   Note that as a base definition, functions like multiple virtual MAC
   layers are not supported in this LFB version.  It may be supported in
   the future by defining a subclass or a new version of this LFB.

   There are also some other components, capabilities, events defined in
   the LFB for various purposes.  See section 6 for detailed XML
   definitions of the LFB.

5.2.  IP Packet Validation LFBs

   An LFB is defined to abstract IP packet validation process.  An
   IPv4Validator LFB is specifically for IPv4 protocol validation and an
   IPv6Validator LFB for IPv6.

5.2.1.  IPv4Validator

   This LFB performs IPv4 packets validation according to RFC 1812 and
   RFC 2644.

   Input of the LFB always expects packets which have been indicated as
   IPv4 packets by an upstream LFB, like an EtherClassifier LFB.  There
   is no specific metadata expected by the input of the validator LFB.

   Note that, as a default provision of RFC 5812, in FE model, all
   metadata produced by upstream LFBs will pass through all downstream
   LFBs by default without being specified by input port or output port.
   Only those metadata that will be used(consumed) by an LFB will be
   explicitly marked in input of the LFB as expected metadata.  For
   instance, in this LFB, even there is no specific metadata expected,
   metadata like PHYPortID produced by some upstreaming PHY LFBs will
   always pass through this LFB.  In some cases, if some component in
   the LFB may use the metadata, it actually still can use it regardless
   of whether the metadata has been expected or not.

   Four output ports are defined to output various validation results.
   All validated IPv4 unicast packets will be output at the singleton
   IPv4UnicastOut port.  All validated IPv4 multicast packets will be
   output at the singleton IPv4MulticastOut port.  There is no metadata
   specifically required to be produced at these output ports.

   A singleton ExceptionOut port is defined to output packets which have
   been validated as exceptional packets.  An exception ID metadata is
   produced to indicate which causes it exceptional.  Currently defined
   exception types include cases like, packet with destination address
   equal to 255.255.255.255, Packet with expired TTL, Packet with header
   length more than 5 words, and packet IP head including Router Alert
   options, etc.  Note that even TTL is checked for validity here,
   actual operation like decrease of TTL will not be made here, rather
   made by followed forwarding LFB.

   A singleton output is defined for all packets which have failed the
   packet validation.  A validate error ID is associated to every failed
   packet to indicate the reasons like an invalid packet size, wrong IP
   protocol version, wrong checksum, etc.

   There are also some other components defined in the LFB for various
   purposes.  See section 6 for detailed XML definitions of the LFB.

5.2.2.  IPv6Validator

   This LFB performs IPv6 packets validation according to RFC 2460 and
   RFC 4291.

   Input of the LFB always expects packets which have been indicated as
   IPv6 packets by an upstream LFB like an EtherClassifier LFB.  There
   is no specific metadata expected by the input of the validator LFB.

   Similar to IPv4 validator LFB, IPv6Validator LFB has also defined
   four output ports to output various validation results.  All
   validated IPv6 unicast packets will be output at the singleton
   IPv6UnicastOut port.  All validated IPv6 multicast packets will be
   output at the singleton IPv6MulticastOut port.  There is no metadata
   specifically required to be produced at these output ports.  A
   singleton ExceptionOut port is defined to output packets which have
   been validated as exceptional packets.  An exception ID is produced
   to indicate which causes it exceptional.  Currently, exception types
   include the following cases:

      a packet with hop limit to zero

      a packet with a link-local destination address.

      a packet with a link-local source address.

      a packet with destination all-routers.

      a packet with destination all-nodes.

      a packet with next header set to Hop-by-Hop.

   A singleton output is defined for packets which have failed the
   packet validation.  A validate error ID is associated to every failed
   packet to indicate the reasons for the failures.  The reasons may
   include an invalid packet size, wrong IPv6 protocol version, wrong
   source or destination IPv6 addresses, etc.

   There are also some other components defined in the LFB for various
   purposes.  See section 6 for detailed XML definitions of the arp table.</synopsis>
            <typeRef>uint32</typeRef>
          </component>
          <component componentID="2">
            <name>NeighborIPv6</name>
            <synopsis>IP address LFB.

5.3.  IP Forwarding LFBs

   IP Forwarding LFBs are specifically defined to abstract the IP
   forwarding processes.  As definitions for a base LFB library, this
   document restricts its LFB definition scope for IP forwarding jobs
   only to IP unicast forwarding.  LFBs for jobs like IP multicast may
   be defined in future versions 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 document.

   A typical IP unicast forwarding job is usually realized by looking up
   some forwarding information table to find some next hop information,
   and then based on the next hop information, forwarding packets to
   specific output ports.  It usually takes two steps to do so, firstly
   to look up a forwarding information table by means of Longest Prefix
   Matching(LPM) rule to find a next hop index, then to use the index to
   look up a next hop information table to find enough information to
   submit packets to output ports.  This document abstracts the
   forwarding processes mainly based on the two steps model.  However,
   there actually exists other models, like one which may only have a
   forwarding information base that have conjoined next hop information
   together with forwarding information.  In this case, if ForCES
   technology is to be applied, some translation work will have to be
   done in FE to translate attributes defined by this document into real
   attributes the implementation has actually applied.

   Based on the Neighbor.</synopsis>
            <typeRef>IEEEMAC</typeRef>
          </component>
          <component componentID="5">
            <name>State</name>
            <synopsis>The state IP forwarding abstraction, two kind of typical IP
   unicast forwarding LFBs are defined, Unicast LPM lookup LFB and next
   hop application LFB.  They are further distinguished by IPv4 and IPv6
   protocols.

5.3.1.  IPv4UcastLPM

   The LFB abstracts the entry's resolution progress.
            </synopsis>
            <typeRef>NbrState</typeRef>
          </component>
        </struct>
      </dataTypeDef>
      <dataTypeDef>
        <name>DCHostTableEntryTypev4</name>
        <synopsis>Direct connected arp table entry process 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 IPv4 unicast LPM table looking up.

   Input of the Neighbor.</synopsis>
            <typeRef>IEEEMAC</typeRef>
          </component>
        </struct>
      </dataTypeDef>
      <dataTypeDef>
        <name>DCHostTableEntryTypev6</name>
        <synopsis>Direct connected arp LFB always expects to receive IPv4 unicast packets.  An
   IPv4 prefix table entry is defined as a component for IPv4.</synopsis>
        <struct>
          <component componentID="1">
            <name>NeighbourIPv6</name>
            <synopsis>IP the LFB to provide
   forwarding information for every input packet.  The destination IPv4
   address of every packet is as 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 index to look up the Neighbor.</synopsis>
            <typeRef>IEEEMAC</typeRef>
          </component>
        </struct>
      </dataTypeDef>
      <dataTypeDef>
        <name>PacketType</name>
        <synopsis>The packet type code.</synopsis>
        <atomic>
          <baseType>uchar</baseType>
          <specialValues>
            <specialValue value="1">
              <name>IPv4Ucast</name>
              <synopsis>IPv4 unicast packet.</synopsis>
            </specialValue>
            <specialValue value="2">
              <name>IPv4Mcast</name>
              <synopsis>IPv4 multicast packet.</synopsis>
            </specialValue>
            <specialValue value="3">
              <name>IPv6Ucast</name>
              <synopsis>IPv6 unicast packet.</synopsis>
            </specialValue>
            <specialValue value="4">
              <name>IPv6Mcast</name>
              <synopsis>IPv6 multicast packet.</synopsis>
            </specialValue>
          </specialValues>
        </atomic>
      </dataTypeDef>
      <dataTypeDef>
        <name>DispatchTableType</name>
        <synopsis>The dispatch table type.</synopsis>
        <struct>
          <component componentID="1">
            <name>PacketType</name>
            <synopsis>The type of with the packet.IPv4Uncast,IPv6Ucast,
            IPv4Mulcast,IPv6Mulcast etc.</synopsis>
            <typeRef>PacketType</typeRef>
          </component>
          <component componentID="2">
            <name>index</name>
            <synopsis>The index
   rule of longest prefix matching(LPM).  A hop selector is the matching
   result, which will be output group to downstream LFBs as an index for next
   hop information.

   Normal 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 LFB is
            standardalized in a singleton output, which will output
   IPv4 unicast packet that has passed the corresponding
             LFB definition RFCs.</synopsis>
            <typeRef>uint32</typeRef>
          </component>
          <component componentID="2">
            <name>MetadataName</name>
            <synopsis>The name of LPM lookup and got a hop
   selector as the lookup result.  The hop selector is associated with
   the metadata.</synopsis>
            <typeRef>String</typeRef>
          </component>
        </struct>
      </dataTypeDef>
      <dataTypeDef>
        <name>MetadataClassyTableType</name>
        <synopsis>The meta data classifying table.</synopsis>
        <struct>
          <component componentID="1">
            <name>value</name>
            <synopsis>Value of packet as a metadatum.  Followed the meta data.</synopsis>
            <typeRef>uint32</typeRef>
          </component>
          <component componentID="2">
            <name>index</name>
            <synopsis>The index normal output of the port in LPM LFB
   is usually a next hop applicator LFB.  The LFB receives packets with
   their next hop IDs and based on the output group next hop IDs to use
            for outputing forward the packets.</synopsis>
            <typeRef>uint32</typeRef>
          </component>
        </struct>
      </dataTypeDef>
      <dataTypeDef>
        <name>EncapType</name>
        <synopsis>Encapsulation type.</synopsis>
        <atomic>
          <baseType>uchar</baseType>
          <specialValues>
            <specialValue value="1">
              <name>Link</name>
              <synopsis>Link layer encapsulation such as Ethernet and
              PPP.</synopsis>
            </specialValue>
            <specialValue value="2">
              <name>InterFE</name>
              <synopsis>Inter FE communication encapsulation.
              </synopsis>
            </specialValue>
            <specialValue value="3">
              <name>Tunnel</name>
              <synopsis>Tunnel encapsulation such
   packets.  A hop selector associated with every packet from the normal
   output will directly act as IP-in-IP.
              </synopsis>
            </specialValue>
          </specialValues>
        </atomic>
      </dataTypeDef>
      <dataTypeDef>
        <name>IPAddress</name>
        <synopsis>IP layer address.</synopsis>
        <union>
          <component componentID="1">
            <name>Ipv4</name>
            <synopsis>IPv4 address.</synopsis>
            <typeRef>IPv4Addr</typeRef>
          </component>
          <component componentID="2">
            <name>Ipv6</name>
            <synopsis>IPv6 address.</synopsis>
            <typeRef>IPv6Addr</typeRef>
          </component>
        </union>
      </dataTypeDef>
      <dataTypeDef>
        <name>ArpStateType</name>
        <synopsis>The arp entry state.</synopsis>
        <atomic>
          <baseType>uchar</baseType>
          <specialValues>
            <specialValue value="1">
              <name>Mannul</name>
              <synopsis>The entry is mannully set.</synopsis>
            </specialValue>
            <specialValue value="2">
              <name>InSolicit</name>
              <synopsis>The peer's level 2 address a next hop ID for a next hop applicator
   LFB.

   The LFB is still in
              requesting.</synopsis>
            </specialValue>
            <specialValue value="4">
              <name>Vaild</name>
              <synopsis>The address resolution defined to provide some facilities to support users to
   implement equal-cost multi-path routing (ECMP) or reverse path
   forwarding (RPF).  However, this LFB itself does not provide ECMP or
   RPF.  To implement ECMP or RPF, additional specific LFBs, like a
   specific ECMP LFB, will have been completed
              successfully,it now can to be used defined.  This work may be done in
   the data packets
              forwarding.</synopsis>
            </specialValue>
          </specialValues>
        </atomic>
      </dataTypeDef>
    </dataTypeDefs>
    <metadataDefs>
      <metadataDef>
        <name>NextHopID</name>
        <synopsis>An index into a Next Hop entry future version of the document.

   For the LFB to support ECMP, an ECMP flag is defined in Nexthop the prefix
   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 entries.  When the flag is set to hop-by-hop header(0).</synopsis>
            </specialValue>
            <specialValue value="0x00000002">
              <name>LengthMismatch</name>
              <synopsis>The packet length reported by link layer true, it indicates this table
   entry is
              less than for ECMP only.  In this case, the total length field.</synopsis>
            </specialValue>
            <specialValue value="0x00000003">
              <name> BadTTL </name>
              <synopsis>The packet can't hop selector in this table
   entry will be forwarded used as the TTL has
              expired.</synopsis>
            </specialValue>
            <specialValue value="0x00000004">
              <name> Multicast </name>
              <synopsis>The packet received is a multicast packet.
              </synopsis>

            </specialValue>
            <specialValue value="0x00000005">
              <name>FragRequired</name>
              <synopsis>The MTU an index for outgoing interface a downstream specific ECMP LFB to
   find its correspondent next hop IDs.  When ECMP is less than the
              packet size.</synopsis>
            </specialValue>
            <specialValue value="0x00000006">
              <name>Redirect</name>
              <synopsis>The outgoing port applied, it will
   usually get multiple next hops information.

   To distinguish normal output from ECMP case output, a specific ECMP
   output is same as the one on defined.  A packet, which has passed through prefix table
   entry lookup with true ECMP flag, will always output from this port,
   with the packet is received.</synopsis>
            </specialValue>
            <specialValue value="0x00000007">
              <name>LocalDelivery</name>
              <synopsis>The packet is for hop selector being its lookup result.  The output will
   usually directly go to a local interface.</synopsis>
            </specialValue>
            <specialValue value="0x00000008">
              <name>LimitedBroadcast</name>
              <synopsis>The packet received as limited broadcast.
              </synopsis>
            </specialValue>
          </specialValues>
        </atomic>
      </metadataDef>
      <metadataDef>
        <name>InputPortID</name>
        <synopsis>At which interface downstream ECMP processing LFB.  In the packet arrive.</synopsis>
        <metadataID>3</metadataID>
        <typeRef> uint32</typeRef>
      </metadataDef>
      <metadataDef>
        <name>OutputPortID</name>
        <synopsis>The interface out which ECMP
   LFB, based on the packet will emmit.
        </synopsis>
        <metadataID>4</metadataID>
        <typeRef> uint32</typeRef>
      </metadataDef>
      <metadataDef>
        <name> NextHopIP </name>
        <synopsis>Nexthop IPv4 address.</synopsis>
        <metadataID>5</metadataID>
        <typeRef> IP4Addr </typeRef>
      </metadataDef>
      <metadataDef>
        <name>NexthopIPv6</name>
        <synopsis>Nexthop IPv6 address</synopsis>
        <metadataID>6</metadataID>
        <typeRef>IPv6Addr</typeRef>
      </metadataDef>
      <metadataDef>
        <name>PacketLength</name>
        <synopsis>The length of hop selector, multiple next hop IDs may be found,
   and more ECMP algorithms may be applied to optimize the packet in octets.</synopsis>
        <metadataID>7</metadataID>
        <typeRef>uint32</typeRef>
      </metadataDef>
      <metadataDef>
        <name> PacketType </name>
        <synopsis>Type of route.  As
   the packet</synopsis>
        <metadataID>8</metadataID>
        <atomic>
          <baseType>uint32</baseType>
          <specialValues>
            <specialValue value="0x8000">
              <name> IPv4 </name>
              <synopsis>IPv4 packet</synopsis>
            </specialValue>
            <specialValue value="0x86DD">
              <name> IPv6 </name>
              <synopsis>IPv6 packet</synopsis>
            </specialValue>
            <specialValue value="3">
              <name> TaggedFrame </name>
              <synopsis>packet with metadata</synopsis>
            </specialValue>
            <specialValue value="4">
              <name> MetaDataFrame </name>
              <synopsis>meta data only</synopsis>
            </specialValue>
          </specialValues>
        </atomic>
      </metadataDef>
      <metadataDef>
        <name> QueueID </name>
        <synopsis>The queue ID</synopsis>
        <metadataID>9</metadataID>
        <typeRef> uint32</typeRef>
      </metadataDef>
      <metadataDef>
        <name>QueueOperationCmd</name>
        <synopsis>The type result of operation on the queue,there are two
        types ECMP LFB, it will output optimized one or multiple
   next hop IDs to its downstream LFB that is usually a next hop
   applicator LFB.

   For the LFB to support RPF, a default route flag is defined here: enqueue and dequeue.</synopsis>
        <metadataID>10</metadataID>
        <atomic>
          <baseType>uchar</baseType>
          <specialValues>
            <specialValue value="1">
              <name>Enqueue</name>
              <synopsis>Enqueue command.</synopsis>
            </specialValue>
            <specialValue value="2">
              <name>Dequeue</name>
              <synopsis>Dequeue command.</synopsis>
            </specialValue>
          </specialValues>
        </atomic>
      </metadataDef>
      <metadataDef>
        <name>SrcFEID</name>
        <synopsis>Source blade ID.</synopsis>
        <metadataID>11</metadataID>
        <typeRef>uchar</typeRef>
      </metadataDef>
      <metadataDef>
        <name>DstFEID</name>
        <synopsis>Destination blade ID.</synopsis>
        <metadataID>12</metadataID>
        <typeRef>uchar</typeRef>
      </metadataDef>
      <metadataDef>
        <name>NexthopIndex</name>
        <synopsis>Nexthop index into in the link layer address resolution
        table.</synopsis>
        <metadataID>13</metadataID>
        <typeRef>uint</typeRef>
      </metadataDef>
      <metadataDef>
        <name>EncapMethod</name>
        <synopsis>how should
   prefix table entry.  When set true, the following prefix entry is identified as
   a default route, and also as a forbidden route for RPF.  To implement
   various RPF, one or more specific LFBs do have to encapsulate be defined.  This job
   may be done for the
        packets,such as link encapsulation which means future version of the packets need
        to encapsulate link layer header before sending library.

   An exception output is defined to media;inter
        FE communication encapsulation which means the allow some exceptional packets need to
        first encapsulate inter FE communication header before
        transimiting to
   output here.  Exceptions include cases like packets can not find any
   routes by the prefix table.

   There are also some other FEs;tunnel encapsulation which means components defined in the
        packet need do extra tunnel encapsulation before sending out to
        media. </synopsis>
        <metadataID>14</metadataID>
        <typeRef>EncapType</typeRef>
      </metadataDef>
    </metadataDefs>
  </LFBLibrary>

6. LFB Classes Description

   According for various
   purposes.  See section 6 for detailed XML definitions of the LFB.

5.3.2.  IPv4NextHopApplicator

   This LFB abstracts the process of next hop information application to ForCES specifications,
   IPv4 packets.

   The LFB (Logical Function Block) is a
   well defined, logically separable functional block that resides in receives an
   FE, IPv4 packet with an associated next hop ID, and is
   uses the ID to look up a functionally accurate abstraction next hop table to find an appropriate output
   port from the LFB.  Simultaneously, the LFB also implements TTL
   operation and checksum recalculation of every IPv4 packet received.

   Input of the FE's processing
   capabilities.  An LFB Class (or type) is a template that represents a
   fine-grained, logically separable aspect of FE processing.  Most LFBs
   relate singleton one which expects to packet processing in receive IPv4
   unicast packets and hop selector metadata from an upstream LFB.
   Usually, the data path. upstream LFB classes are the
   basic building blocks of the FE model.

   Only for better understanding purposes, is directly an IPv4UnicastLPM LFB.  While
   it is possible some other upstream LFB classes defined in this
   document are further categorized into groups of LFBs, including Core
   LFBs, Port LFBs, etc.

   The following sections describe may be applied.  For instance,
   when ECMP is supported, the upstream LFB classes according to the
   groups.

6.1.  Core LFBs may be some specific ECMP
   LFB.

   The core LFBs provide basic ForCES functionality for FE next hop ID in hop selector metadata of a ForCES
   system.  Two core LFBs are defined: the FE Protocol LFB and the FE
   Object LFB.

6.1.1.  FE Protocol LFB

   The FE Protocol LFB packet is defined then used as
   an index to look up a logical entity next hop table defined in each FE that the LFB.  Via this
   table and the next hop index, important information for forwarding
   the packet is found.  The information includes:

      output logical port ID, which will be used by downstream LFBs to control
      find proper output port.

      next hop option, which decides if the ForCES protocol.  It repsesents FE Protocol
   attributes like supportable ForCES protocol versions, current running
   version, FE restart policy, packet should be locally
      processed or not.  For packets that will be redirected to CE failover policy, etc.  The ForCES
   protocol specification document FE-MODEL [I-D.ietf-forces-model]
   defines the LFB in details and specifes for
      processing or that every FE must have one need FE Protocol LFB.

   The definition of the LFB is included in this base LFB library local processing, next hop option will
      be marked as 'forwarded to locally attached host' .  Packets that
      will be normally forwarded will be marked as 'normal forwarding'.

      next hop IP address, which will be used by
   using "load" element:

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

6.1.2.  FE Object LFB

   The FE Object downstream LFB is defined to make the FE information easily
   accessible.  Information like the FE Name, FE ID, FE State, LFB
   Topology in find
      proper output port IP address for this packet.

      encapsulation output index, which is used by the FE packet to find
      proper output of this LFB.

   There are represented two output ports.  One is for success output and another is
   for exception output.  Success output is a group output, with an
   index to indicate which output instance in the class of LFB. group is adopted.  The FE model
   documentFE-MODEL [I-D.ietf-forces-model] defines
   index is the LFB in details
   and specifies that every FE must have one FE Object LFB.

   The definition of encapsulation output index described above.  Downstream
   LFBs connected to the LFB is included in this base LFB library by
   using "load" element:

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

6.2.  Port success output group may be various LFBs

   Classes of Port for
   encapsulation like LFBs are for Ethernet encapsulation and for PPP
   encapsulation, various LFBs that are related for local processing, and LFBs for
   redirecting packets to CE for processing.  Next hop table uses the operation of FE
   media interfaces linked
   encapsulation output index to outer networks or other FEs indicate which port instance in the same
   ForCES system.  According to different media types, different media
   output group a packet should go.

   Every port LFBs may have to be defined.  For every type instance of media port, it
   usually needs to implement encapsulating the success output group will produce metadata
   of output logical port ID and decapsulating next hop IP address for every output
   packet.  These metadata will be used by downstream LFBs to further
   implementing forwarding process.

   Note that for next hop option marked as local host processing, the
   next hop IP
   datagrams with address for the connected network framing.  For packet is exactly the sake destination IP
   address of the
   flexibility, the function packet.

   The exception output of encapsulating and decapsulating are
   usually categorized in the LFB classes as separate LFBs.

   Even if ports is a singleton output.  It outputs
   packets with different media may have different logical
   abstracts for exceptional cases.  An exception ID further indicates
   the attributes, exception reasons.  Exception may happen when a general description for different
   ports still exist.  A Generic Connectivity LFB hop selector is defined for this
   sake.  By use of an FE model XML schema <derivedFrom> element,
   specific media port LFBs
   found invalid, or ICMP packets need to be generated (Editorial note:
   more discussions here), etc.  The exception ID is also produced as a
   metadata by the output to be transmitted to a downstream LFB.

   There are then also some other components defined in a easier way.

6.2.1.  Generic Connectivity LFB

   This the LFB Class provides a generic basis for representing connectivity
   between the FE and various
   purposes.  See section 6 for detailed XML definitions of the outside world. LFB.

5.3.3.  IPv6UcastLPM

   The LFB has one or more ports
   for packets that abstracts the FE processing logic process for IPv6 unicast LPM table looking up.

   Definitions of this IPv6UcastLPM LFB is forwrding very identical to
   IPv4UcastLPM LFB except that all IP addresses related are changed
   from IPv4 addresses to IPv6 addresses.  See section 6 for
   transmission by detailed
   XML definitions of this Connectivity LFB.  It has one or more ports for
   packets that

5.3.4.  IPv6NextHopApplicator

   This LFB abstracts the Connectivity process of next hop information application to
   IPv6 packets.

   Definitions of this IPv6NextHopApplicator LFB has received and is handing very identical to
   IPv4NextHopApplicator LFB except that all IP addresses related are
   changed from IPv4 addresses to IPv6 addresses.  See section 6 for
   detailed XML definitions of this LFB.

5.4.  Address Resolution LFBs

   The address resolution LFBs abstracts the
   FE processing logic.  Multiple ports process for handline packets are
   supported so that address
   resolution functions.  In the process, address resolution protocols,
   like ARP protocol specific encapsulation for IPv4 and demultiplexing
   can be provided by this LFB.  This LFB also has ports neighbor discovery protocol for sending
   packets IPv6,
   are applied.

   There exist two schema under ForCES architecture to lower layer Connectivity LFBs and receiving packets from
   such lower layer Connectivity LFBs.  This enables support implement address
   resolution function.  One is for FE to implement the
   processing components address
   resolution by use of interface stacks, such address resolution LFBs as PPP over Ethernet
   or Ethernet over MPLS.  For packets arriving defined in this
   section.  The other is to offload the address resolution from Media or lower
   layer connectivity, FE to
   CE.  In this LFB case, address resolution LFBs will perform appropriate media
   validation, then remove media specific headers, and place the
   relevant information in meta-data.  For ethernet, the Source MAC
   would not be in meta-data.  For Frame Relay or ATM, a circuit identifier
   would used.  All
   address resolution protocol messages FE has received will be in meta-data.  For Ethernet with VLANs, this meta-data would
   indicate which VLAN the packet came from.  For packets
   redirected to be
   transmitted, meta-data indicating the destination (destination MAC or
   outgoing circuit, etc.) CE via ForCES protocol [RFC5810].  CE is required.  This LFB responsible to
   process the protocol messages and generate new address resolution
   messages to send to outer network via FE using ForCES prococol
   [RFC5810].  CE will also include
   statistical components such as use ForCES protocol to manage the number of octets and packets sent
   and received, address
   resolution tables, like the number of various input ARP table and output errors, etc.

6.2.2. the neighbor table, in
   Ethernet Port LFBs

   (TBD)

   1.  EtherPort LFB

       LFB encapsulator LFB.

   According to address resolution individually for Ethernet ports

   2.  EtherDecap LFB

       An IPv4 or IPv6
   packets, an ARP LFB class for definition of Ethernet decapsulation and
       Ethernet filtering functions.

   3.  EtherEncap LFB

       An an ND(neighbor discovery) 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 are defined as
   below.

5.4.1.  ARP

   The ARP LFB class provides the function of address resolution for IPv4/
   IPv6 IPv4
   nodes.

   1.  Two singleton inputs are defined for the LFB.  One is for ARP

       This
   protocol packet input.  The packets are usually come from upstream
   LFBs like an Ethernet classifier LFB class provides where ARP protocol messages are
   categorized.  The frame type hence expected is the function of address resolution ARP protocol
   message type.  The other singleton input is for IPv4 node.

   2.  IPv6 Address Resolution

       This packets that
   usually come from Ethernet encapsulator LFB class provides the function of IPv6 address resolution
       part of neighbor discovery protocol.It provides an offload of ND
       protocol processing and are unable to find L2
   information to FE.It finish encapsulation process in that LFB.  The
   associated metadata include a next hop IPv4 address, which is the following ND messages:
       neighbour solicitation and neighbour advertisement.

6.4.  ICMP LFBs

   (TBD)

   1.  ICMP Geneartor

       This
   encapsulator LFB class provide some basic ICMP function.  It only
       generate can not find its binding Ethernet MAC address, the following ICMP messages: ICMP destination
       unreachable
   logical port ID, and time excceeded.

   2.  ICMPv6 Generator the VLAN ID (Editorial note: need more
   discussions on what metadata these inputs should expect.)

   There are two components defined in the ARP LFB.  One is the ARP
   table.  Note that ARP table in this LFB is defined as an alias
   component of ARP table in Ethernet encapsulator LFB.  This means
   management of the ARP table will be shared by both of the LFBs.  The
   ARP LFB class provide some basic ICMPv6 function, it only
       generate will manage the following ICMP messages for table and refresh the packets that need
       some basic ICMP processing: table entries based on
   the ARP protocol messages received.  The protocol messages provide
   bindings of IPv4 addresses with destination MAC addresses.  The ARP
   table fields include destination not reachable and time
       excceeded.

6.5. IP Packet Validation LFBs

   (TBD)

   1. address, logical port ID, source
   MAC address, and destination MAC address (Editorial note: need more
   discussions on what fields needed).

   Another component defined is the local IPv4 Validator

       An LFB Class definition address table for validates all
   ports of the FE.  An FE port here is indexed by a logical port ID.
   Note that every physical port may be capable of multiple logical
   ports with multiple IP or MAC addresses.  The port IPv4 packet.

       This LFB validates the address table
   provides binding of a logical port to an IP version address and header length fields,
       including verifying that the packet length a MAC address
   (Editorial note: is at least as long as it possible one logical port binds multiple IP
   addresses?).  The table will be used by the header indicates.

   2.  IPv6 Validator

       An ARP LFB Class definition for validates to check locality
   of arrived ARP protocol messages.  Usually the IPv6 packet.

       This LFB validates table will be
   configured by CE via ForCES protocol.(Editorial note: need more
   discussions on what fields the port IP version address table needs and header length fields,
       including verifying that how
   the packet length is at least as long as logical port ID and MAC address take effect in the header indicates.

6.6.  Classifier LFBs

   (TBD)

   1.  Metadata Classifier LFB

       This LFB class provides process).

   Two singleton outputs are defined for the function of classify ARP LFB.  One is for ARP
   protocol message output.  All ARP request and response packets
       according are
   sent out from here to the meta data.  Now it only works on one meta data.

   2.  Arbitrary Classifier LFB
       This downstream LFB, which usually is Ethernet
   encapsulation LFB.

   Another output is a class definition for sending all packets that are input to this LFB
   because they can not find L2 encapsulation information when doing
   encapsulation in an Arbitrary Classifier Ethernet encapsulation LFB.  The
       input is a port group, and  They are just sent
   back to the match conditions can include LFB for encapsulation again with the
       port expected refreshed
   ARP table contents.  (Editorial note: need more discussions on how
   the mechanism should be defined for those packets unable to do
   encapsulation in their test.  This allows the topology encapsulation LFB.  An alternative schema is to carry some
       information if desired.  The match conditions can select an
       output from let
   the SuccessOuput ARP LFB to do encapsulation rather than send them back to
   encapsulation LFB, then output port group.  If no condition
       matches, the packet will be sesnt packets directly to an LFB after
   the FailOutput port.

6.7.  Forwarding LFBs encapsulation LFB).

5.4.2.  ND

   (TBD)

   Forwarding

5.5.  Redirect LFBs are specifically for implementing IP packet
   forwarding tasks.

6.7.1.  Unicast Longest Prefix Match

   Redirect 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 abstract data packets transportation process between CE
   and FE.  Some packets output from some LFBs

   1.  IPv4 NextHop Applicator

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

   2.  IPv6UcastNexthopApplicator

       An LFB for applicating next hop action be delivered
   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 CE for of
   queueing and scheduling.  Queues are entities which store packets.
   Schedulers are entities which react to the state of queues further processing, and cause some packets generated by CE may
   have to be emitted from queues.

   The actual interaction between queues and schedulers (and their real
   world degree of separation) is quite complex.  A very complex LFB
   model would be required delivered to represent all the complexity.
   Additionally, there is the issue of representing the relationship
   between the queue FE and the scheduler.  A simple approach has been
   taken in these class definitions.

   A queue element consists of an input port (called InData) on which it
   receives further to some specific LFBs for data
   path processing.  According to RFC 5810 [RFC5810], data packets, and output port (called OutData) on which it
   will send packets when permitted by its definition or the scheduler.
   Its relationship and
   their associated metadata are encapsulated in ForCES redirect message
   for transportation between CE and FE.  We define two LFBs to scheduluers is represented by abstract
   the process, a set of output
   ports (the group OutCountrol) RedirectIn LFB and a RedirectOut LFB.  Usually, in an input port (called InControl).
   These ports are defined to carry packets consisting only
   LFB topology of meta-
   data.  In fact, these ports are an abstraction, FE, only one RedirectIn LFB instance and what one might
   call a legal fiction.  An element of
   RedirectOut LFB instance exist.

5.5.1.  RedirectIn

   A RedirectIn LFB abstracts the OutControl group represents process for CE to inject data packets
   into FE LFB topology so as to input data packets into FE data paths.
   From LFB topology point of view, the fact that RedirectIn LFB acts as a scheduler is aware of source
   point for data packets coming from CE, therefore the state RedirectIn LFB
   is defined with only one output, while without any input.

   Output of that queue
   element.  The InControl port represents the fact that one or more
   schedulers connected to that port are controlling that queue.  There RedirectIn LFB is no meta-data defined for actual exchange on these ports, as their
   real world realization is highly implementation dependent.  To
   complete this picture, a schedule has a group of input ports
   (Watchers) representing output.  Packets
   produced by the connectivity to queues it is aware of,
   and a group of output ports (Controllers) representing control over
   queues.  This allows for will have arbitrary frame types decided by CE
   which generates the simple case of packets.  Possible frames may include IPv4, IPv6,
   or ARP protocol packets.  CE may associate some metadata to indicate
   the frame types.  CE may also associate other metadata to data
   packets to indicate various information on the packets.  Among them,
   there MUST exist a controller who monitors 'RedirectIndex' metadata, which is an integer
   acting as an index.  When CE transmits the metadata and controls a single set of queues, and more interesting cases where binging
   packet to a RedirectIn LFB, the control of certain queues may depend upon LFB will read the state metadata and output
   the packet to one of queues
   whihc are not under its group output port instance, whose port index
   is just as indicated by the control metadata.  Detailed XML definition of the scheduler.

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

   1.  Scheduler

   2.  Queue

   3.  WRRSched

6.8.1.  Scheduler LFBs

   1.  Generic Scheduler

       This defines a base LFB class for schedulers.  Schedulers have an
       Input Port group called Watchers the XML for representing base type library as in Section 4.4.

   All metadata from CE other than the queues they
       watch, and an Output Port group called Controllers fro
       representing 'RedirectIndex' metadata will
   output from the queues they control.

   2.  WRRSched

       Weighted round robin scheduler.

6.8.2.  Queue LFBs

   Queues have a packet input, RedirectIn LFB along with their binding packets.
   Note that, a packet output, a control input, and without a
   group 'RedirectIndex' metadata associated
   will be dropped by the LFB.

   There is no component defined for current version of RedirectIn LFB.
   Detailed XML definitions of control outputs.  The control ports represent the control
   relationships with scheduluers.

6.9.  Miscellaneous Packet Manipulation LFBs

   (TBD)

   1.  Packet Trimmer LFB can be found in Section 6.

5.5.2.  RedirectOut

   A RedirectOut LFB removes data from abstracts the front of a packet.

   2.  Duplicator process for LFBs in FE to deliver
   data packets to CE.  From LFB

       An topology point of view, the RedirectOut
   LFB Class definition acts as a sink point for packet duplicator LFB.  Any packet
       received on an input port is logically copied and sent data packets going to all
       output ports.

   3.  IPv4 Option Proccessing CE, therefore the
   RedirectOut LFB

       This is defined with only one input, while without any
   output.

   Input of the RedirectOut LFB class process is defined as a singleton input, but it
   is capable of receiving packets from multiple LFBs by multiplexing
   the IPv4 packet singleton input.  Packets expected by the input will have
   arbitrary frame types.  All metadata associated with options, it can
       process on the following options: Router-alert option.

   4.  IPv6 Extend Header Processing input
   packets will be delivered to CE via a ForCES protocol redirect
   message [RFC5810].  The input will expect all types of metadata.

   There is no component defined for current version of RedirectOut LFB.
   Detailed XML definitions of the LFB

       This can be found in Section 6.

5.6.  General Purpose LFBs

5.6.1.  BasicMetadataDispatch

   A basic medatata dispatch LFB class is defined to abstract a process the IPv6 in
   which a packet with extended header, For
       the moment, the packets to this LFB are redirect is dispatched to RedirectSink
       LFB by default.

6.10.  Redirect LFB

   (TBD)

   An LFB Class definition for exchanging data packets between the FE
   and the CE.

   This some path based on its associated
   metadata value.

   The LFB represents is with a point of exchagne singleton input.  Packets of data packets between the
   CE and arbitrary frame types
   can input into the FE.  Packets with meta-data are exchanged.  It LFB.  Whereas, every input packet is expected
   that the output port of required to
   be associated with a RedirectLFB, if it is connected at all, metadata that will be connected used by the LFB to do
   dispatch.  If 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>
       <synopsis>LFB for Ethernet ports</synopsis>
       <version>1.0</version>
       <inputPorts>
         <inputPort>
           <name>PacketsFromProcessingUnit</name>
           <synopsis>
                    Ports for receiving packets from processing unit packet is not associated with such as NP,that metadata, the
   packet will be sent to media.
           </synopsis>
           <expectation>
             <frameExpected>
               <ref>EthernetII</ref>
             </frameExpected>
             <metadataExpected>
               <ref>OutputPort</ref>
             </metadataExpected>
           </expectation>
         </inputPort>
         <inputPort>
           <name>PacketsFromMedia</name>
           <synopsis>
                    Ports for receiving packets from ethernet media.
                </synopsis>
           <expectation>
             <frameExpected>
               <ref>EthernetII</ref>
             </frameExpected>
           </expectation>
         </inputPort>
       </inputPorts>
       <outputPorts>
         <outputPort>
           <name>PacketsToProcessingUnit</name>
           <synopsis>Ports for sending packets dropped inside the LFB.

   A group of output is defined to processing unit such
            as NP for further processing. </synopsis>
           <product>
             <frameProduced>
               <ref>EthernetII</ref>
             </frameProduced>
             <metadataProduced>
               <ref>InputPort</ref>
             </metadataProduced>
           </product>
         </outputPort>
         <outputPort>
           <name>PacketsToMedia</name>
           <synopsis>
                    Ports for sending output packets according to media.
                </synopsis>
           <product>
             <frameProduced>
               <ref>EthernetII</ref>
             </frameProduced>
           </product>
         </outputPort>
       </outputPorts>
       <components>
         <component componentID="1">
           <name>IfIndex</name>
           <synopsis>A unique value for each interface. Its value ranges
            between 1 and the value of total number of interfaces a
   MetaDispatchTable as defined a component in the
            system. LFB.  The value for each interface must remain constant at
            least from one re-initialization table
   contains the fields of a metadata ID, a metadata value, and an output
   port index.  A packet, if it is associated with a metadata with the entity's network
            management system
   metadata ID, will be output to the next re-initialization. </synopsis>
           <typeRef>uint32</typeRef>
         </component>
         <component componentID="2">
           <name>IfName</name>
           <synopsis>Name of this port</synopsis>
           <typeRef>string[16]</typeRef>
         </component>
         <component componentID="3">
           <name>LinkSpeed</name>
           <synopsis>Speed of this port</synopsis>
           <typeRef>LANSpeedType</typeRef>
         </component>
         <component componentID="4">
           <name>MTU</name>
           <synopsis>Maximum transmition unit</synopsis>
           <typeRef>uint32</typeRef>

         </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 group port instance with the interface is index
   corresponding to the metadata value in promiscuous mode
           </synopsis>
           <typeRef>booleanType</typeRef>
           <defaultValue>"no"</defaultValue>
         </component>
         <component componentID="8" access="read-only">
           <name>CarrierStatus</name>
           <synopsis>whether the port table.  The metadata value
   ussed by the table is linked required with an connector.
           </synopsis>
           <typeRef>booleanType</typeRef>
           <defaultValue>"no"</defaultValue>
         </component>
         <component componentID="9">
           <name>OperMode</name>
           <synopsis>The port operation mode,must interger data type.  This
   means this LFB currently only allow a metadata with an interger value
   to be used for dispatch.

   Moreover, the LFB is defined with only one of metadata adopted for
   dispatch, i.e., the
           following values:Auto,Half-duplex,Full-duplex</synopsis>
           <typeRef>NegotiationType</typeRef>
           <defaultValue>"auto"</defaultValue>
         </component>
         <component componentID="10">
           <name>SrcMACAddr</name>
           <synopsis>source MAC</synopsis>
           <typeRef>IEEEMAC</typeRef>
         </component>
         <component componentID="11">
           <name>MacAliasTable</name>
           <synopsis>A series of MACs that metadata ID in the port can receive frame
           on.</synopsis>
           <array>
             <typeRef>IEEEMAC</typeRef>
           </array>
         </component>
         <component componentID="12">
           <name>StatsEnable</name>
           <synopsis>whether enable dispatch table is always the statistics
   same for all table rows.

   A more complex metadata dispatch LFB may be defined in future version
   of the library.  In that LFB, multiple tuples of metadata may be
   adopted to dispatch packets.

5.6.2.  GenericScheduler

   There exist various kinds of scheduling strategies with various
   implementations.  As a base LFB library, this LFB.
           </synopsis>
           <optional/>
           <typeRef>booleanType</typeRef>
           <defaultValue>"no"</defaultValue>
         </component>
         <component componentID="13" access="read-reset">
           <name>PortStats</name>
           <synopsis>port statistics.</synopsis>
           <optional/>
           <typeRef>PortStatsType</typeRef>
         </component>
         <component componentID="14">
           <name>Ipaddr</name>
           <synopsis>IP layer Address.</synopsis>
           <typeRef>IPAddress</typeRef>
         </component>
       </components>
       <events baseID="100">
         <event eventID="1">
           <name>PortStatusChanged</name>
           <synopsis>Port status has changed since last time reporting.
           </synopsis>
           <eventTarget>
             <eventField>OperaStatus</eventField>
           </eventTarget>
           <eventChanged/>
           <eventReports>
             <eventReport>
               <eventField>OperaStatus</eventField>
             </eventReport>
           </eventReports>
         </event>
       </events>
     </LFBClassDef>
     <LFBClassDef LFBClassID="4">
       <name>EtherDecap</name>
       <synopsis>An document only defines a
   preliminary generic scheduler LFB class for definition of Ethernet decapsulation
       and Ethernet filtering functions</synopsis>
       <version>1.0</version>
       <inputPorts>
         <inputPort>
           <name>PacketsIn</name>
           <synopsis>Packets from other LFB.</synopsis>
           <expectation>
             <frameExpected>
               <ref>EthernetII</ref>

             </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 abstracting a simple scheduling
   process.  The generic scheduler LFB is used for selecting output the one.  Users may use this
   LFB as a basic scheduler LFB to further construct more complex
   scheduler LFBs by means of inheritance as described in RFC 5812
   [RFC5812].

   The LFB describes scheduling process in the
           ouput following model:

   o  It is with a group input and expects packets with arbitrary frame
      types to arrive for the incoming packet stream.</synopsis>
           <typeRef>DispatchTableType</typeRef>
         </component>
       </components>
     </LFBClassDef>
     <LFBClassDef LFBClassID="5">
       <name>IPv4Validor</name>
       <synopsis>An scheduling.  The group input is capable of
      multiple input port instances.  Each port instance may be
      connected to different upstream LFB Class definition output.  No metadata is
      expected for validates each input packet.

   o  Multiple queues reside at the IPv4 packets.
       </synopsis>
       <version>1.0</version>
       <inputPorts>
         <inputPort>
           <name>ValidatePktsIn</name>
           <synopsis>Port used to receive IPv4 packet for validation.
           </synopsis>
           <expectation>
             <frameExpected>
               <ref>IPv4</ref>
             </frameExpected>
           </expectation>
         </inputPort>
       </inputPorts>
       <outputPorts>
         <outputPort>
           <name>SuccessOut</name>
           <synopsis>Out input side, with every input port for
      instance connected to one queue.

   o  Every queue is marked with a queue ID, and the packets passing queue ID is exactly
      the validation.
           </synopsis>
           <product>
             <frameProduced>
               <ref>IPv4</ref>
             </frameProduced>
           </product>
         </outputPort>
         <outputPort>
           <name>ExceptionOut</name>
           <synopsis>Output port for same as the packets needed index of corresponding input port instance.

   o  Scheduling disciplines are applied to be dealt by
           higher level protcol stacks.The following all queues and also all
      packets in the queues.

   o  Scheduled 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 output from a
           forwarding decision is made);4 Packet length error.
           </synopsis>
           <product>
             <frameProduced>
               <ref>ExceptionID</ref>
             </frameProduced>
           </product>
         </outputPort>
         <outputPort>
           <name>FailOutput</name>
           <synopsis>Output singleton output port of the
      LFB.

   Two LFB components are defined to further describe above model.  A
   scheduling discipline component is defined for packets failed CE to pass the validation.
           </synopsis>
           <product>
             <frameProduced>
               <ref> IPv4 </ref>
             </frameProduced>
           </product>
         </outputPort>
       </outputPorts>
       <components>
         <component componentID="1">
           <name>StatsEnable</name>
           <synopsis>whether specify a
   scheduling discipline to gather statistics in this the LFB.
           </synopsis>
           <optional/>
           <typeRef>booleanType</typeRef>
           <defaultValue>"no"</defaultValue>
         </component>
         <component componentID="2" access="read-reset">
           <name>IPv4ValidatorStats</name>
           <synopsis>ipv4 validator LFB statistics</synopsis>
           <optional/>
           <typeRef>IPv4ValidatorStatisticsType</typeRef>
         </component>
       </components>
       <description>Detailed validation process please refer to RFC1812  Currently defined scheduling
   disciplines only include FIFO and RFC2644.</description>

     </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 round robin(RR).  For FIFO, we
   limit above model that when a FIFO discipline is applied, it is
   require that there is only one input port to receive IPv4 instance for the group
   input.  If user accidentally defines multiple input port instances
   for FIFO scheduling, only packets from other LFBs
           </synopsis>
           <expectation>
             <frameExpected>
               <ref>IPv4</ref>
             </frameExpected>
           </expectation>
         </inputPort>
       </inputPorts>
       <outputPorts>
         <outputPort>
           <name>SuccessOut</name>
           <synopsis>Successful in the input port with lowest port
   index will be scheduled to output when port, and all packets in other
   input port instances will just ignored.

   We specify that if the generic scheduler LFB is fine.</synopsis>
           <product>
             <frameProduced>
               <ref>IPv4</ref>
             </frameProduced>
             <metadataProduced>
               <ref availability="conditional">NextHopID</ref>
               <ref availability="conditional">FEID</ref>
               <ref availability="conditional">OutputPortID</ref>
               <ref availability="conditional">MTU</ref>
               <ref availability="conditional">Flags</ref>
               <ref availability="conditional">NexthopIPAddr</ref>
               <ref availability="conditional">EncapMethod</ref>
             </metadataProduced>
           </product>
         </outputPort>
         <outputPort>
           <name>ExceptionOut</name>
           <synopsis>Exception output</synopsis>
           <product>
             <frameProduced>
               <ref>IPv4</ref>
             </frameProduced>
             <metadataProduced>
               <ref>InputPortID </ref>
               <ref>ExceptionID</ref>
             </metadataProduced>
           </product>

         </outputPort>
         <outputPort>
           <name>FailOutput</name>
           <synopsis>Dropper</synopsis>
           <product>
             <frameProduced>
               <ref> IPv4 </ref>
             </frameProduced>
           </product>
         </outputPort>
       </outputPorts>
       <components>
         <component componentID="1">
           <name> PrefixTable </name>
           <synopsis>IPv4 prefix table</synopsis>
           <array type="variable-size">
             <typeRef> IPv4PrefixTableEntry </typeRef>
             <contentKey contentKeyID="1">
               <contentKeyField>IPv4PrefixTableEntry.prefix
               </contentKeyField>
             </contentKey>
           </array>
         </component>
         <component componentID="2">
           <name>Fib</name>
           <synopsis>IPv4 unicast forwarding table.</synopsis>
           <optional/>
           <array type="variable-size">
             <typeRef>IPv4FibEntryType</typeRef>
             <contentKey contentKeyID="1">
               <contentKeyField>IPv4FibEntryType.prefix
               </contentKeyField>
             </contentKey>
           </array>
         </component>
         <component componentID="3">
           <name>LocalIpAddrTable</name>
           <synopsis>The table defined only one
   input port instance, the default scheduling discipline is FIFO.  If
   the LFB is defined with more than one input port instances, the
   default scheduling discipline is round robin (RR).

   A current queue depth component is defined to allow CE to query every
   queue status of interfaces's ip address infomation
            on the local device</synopsis>
           <typeRef>LocalIpAddrType</typeRef>
         </component>
         <component componentID="4">
           <name>IPv4Stats</name>
           <synopsis>The IPv4 associated statistics</synopsis>
           <optional/>
           <typeRef> IPv4UcastLPMStatisticsType </typeRef>
         </component>
       </components>
       <capabilities>
         <capability componentID="1">
           <name>PrefixTableLimit</name>
           <synopsis>maxium scheduler.  Using the queue ID as the index, CE
   can query every queue for its used length in unit of packets or
   bytes.

   Several capabilities are defined for the LFB.  A queue number of prefix limit
   is defined which limits the scheduler maximum supported by this LFB
           </synopsis>
           <typeRef>uint32</typeRef>
         </capability>
         <capability componentID="2">
           <name>LocalIpAddrTableLimit</name>
           <synopsis>maxium queue number,
   which is also the maximum number of IP address entrys input port instances.  Capability
   of disciplines supported provides scheduling discipline types
   supported by the FE to CE.  Queue length limit provides the
   capability of storage ability for every queue.

   More complex scheduler LFB may be defined with more complex
   scheduling discipline by succeeding this LFB</synopsis>
           <typeRef>uint32</typeRef>
         </capability>
       </capabilities>
       <description>This LFB.  For instance, a
   priority scheduler LFB represents the IPv4 longest prefix match
        lookup operation.
          </description>
     </LFBClassDef>
     <LFBClassDef LFBClassID="7">
       <name> IPv4NextHopApplicator </name>
       <synopsis>An may be defined only by inheriting this LFB definition for applicating next hop action to
        IPv4 packets,the actions include:TTL operation,checksum
         recalculation.</synopsis>
       <version>1.0</version>
       <inputPorts>
         <inputPort>
           <name>PktIn</name>
           <synopsis>Port used and
   define a component to receive IPv4 packets from other LFBs
           </synopsis>
           <expectation>
             <frameExpected>
               <ref> IPv4 </ref>
             </frameExpected>
             <metadataExpected>
               <ref dependency="optional" defaultValue="0xff">
               NextHopID</ref>
               <ref dependency="optional" defaultValue="0xff">
               FEID</ref>
               <ref dependency="optional" defaultValue="0xff">
               OutputPortID</ref>
               <ref dependency="optional" defaultValue="0xff">
               MTU</ref>
               <ref dependency="optional" defaultValue="0xff">
               Flags</ref>
               <ref dependency="optional" defaultValue="0xff">
               NexthopIPAddr</ref>
               <ref dependency="optional" defaultValue="0xff">
               EncapMethod</ref>

             </metadataExpected>
           </expectation>
         </inputPort>
       </inputPorts>
       <outputPorts>
         <outputPort>
           <name>SuccessOut</name>
           <synopsis>Output port indicate priorities for packet successfully fulfill the
            nexthop application.</synopsis>
           <product>
             <frameProduced>
               <ref> IPv4 </ref>
             </frameProduced>
             <metadataProduced>
               <ref>DstFEID</ref>
               <ref>OutputPortID</ref>
               <ref availability="conditional">L2Index</ref>
               <ref>NextHopIP</ref>
               <ref availability="conditional">EncapMethod</ref>
             </metadataProduced>
           </product>
         </outputPort>
         <outputPort>
           <name>ExceptionOut</name>
           <synopsis>Output all input queues.

   See Section 6 for packets need deep dealt by higher level
            protocol stacks.</synopsis>
           <product>
             <frameProduced>
               <ref> IPv4 </ref>
             </frameProduced>
             <metadataProduced>
               <ref>InputPortID</ref>
               <ref>ExceptionID</ref>
             </metadataProduced>
           </product>
         </outputPort>
         <outputPort>
           <name>FailOutput</name>
           <synopsis>Output detailed XML definition for packets failed the nexthop application
            operation.</synopsis>
           <product>
             <frameProduced>
               <ref> IPv4 </ref>
             </frameProduced>
           </product>
         </outputPort>
       </outputPorts>
       <components>
         <component componentID="1">
           <name> NextHopTable </name>
           <synopsis>Nexthop table</synopsis>
           <optional/>
           <array type="variable-size">
             <typeRef> IPv4NextHopInfoType </typeRef>
           </array>
         </component>
       </components>
       <capabilities>
         <capability componentID="2">
           <name>NextHopTableLimit</name>
           <synopsis>Maxium number of nexthops this LFB.

6.  XML for LFB Library

 <LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      provides="BaseLFBLibrary">
    <load library="BaseTypeLibrary"/>
    <LFBClassDefs>
       <LFBClassDef LFBClassID="3">
          <name>EtherPHYCop</name>
          <synopsis>The LFB describes an Ethernet port abstracted at
          physical layer.It limits its physical media to copper.
          Multiple virtual PHYs isn't supported in this LFB supports version.
          </synopsis>
           <typeRef>uint32</typeRef>
         </capability>
       </capabilities>
     </LFBClassDef>
     <LFBClassDef LFBClassID="8">
       <name>IPv6Validator</name>
       <synopsis>A LFB class definition for validating correctness
        of IPv6 packets</synopsis>
          <version>1.0</version>
          <inputPorts>
             <inputPort>
           <name>ValidateIn</name>
           <synopsis>Input port for packets to be validated.</synopsis>
                <name>EtherPHYIn</name>
                <synopsis>The Input Port of the EtherPHYLFB. It
                expects any kind of Ethernet frame.</synopsis>
                <expectation>
                   <frameExpected>
               <ref>IPv6</ref>
                      <ref>EthernetAll</ref>
                   </frameExpected>
                </expectation>
             </inputPort>
          </inputPorts>
          <outputPorts>
             <outputPort>
           <name>SuccessOut</name>
           <synopsis>Output port for packets passing
                <name>EtherPHYOut</name>
                <synopsis>The Output Port of the validation.
           </synopsis> EtherPHYLFB. It can
                produce any kind of Ethernet frame and along with
                the frame passes the ID of the Physical Port as
                metadata to be used by the next LFBs.</synopsis>
                <product>
                   <frameProduced>
               <ref>IPv6</ref>
                      <ref>EthernetII</ref>
                   </frameProduced>
                   <metadataProduced>
                      <ref>PHYPortID</ref>
                   </metadataProduced>
                </product>
             </outputPort>
         <outputPort>
           <name>ExceptionOut</name>
           <synopsis>Output
          </outputPorts>
          <components>
             <component componentID="1" access="read-write">
                <name>PHYPortID</name>
                <synopsis>The ID of the physical port for exception packet.The following
            packets are identified as Exception packet:1 Packet that this LFB
                handles.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="2" access="read-write">
                <name>AdminLinkSpeed</name>
                <synopsis>The link speed that the admin has requested.
                </synopsis>
                <typeRef>LANSpeedType</typeRef>
                <defaultValue>0x00000005</defaultValue>
             </component>
             <component componentID="3" access="read-only">
                <name>OperLinkSpeed</name>
                <synopsis>The actual operational link speed.</synopsis>
                <typeRef>LANSpeedType</typeRef>
             </component>
             <component componentID="4" access="read-write">
                <name>AdminDuplexMode</name>
                <synopsis>The duplex mode that the admin has requested.
                </synopsis>
                <typeRef>DuplexType</typeRef>
                <defaultValue>0x00000001</defaultValue>
             </component>
             <component componentID="5" access="read-only">
                <name>OperDuplexMode</name>
                <synopsis>The actual duplex mode.</synopsis>
                <typeRef>DuplexType</typeRef>
             </component>
             <component componentID="6" access="read-write">
                <name>AdminStatus</name>
                <synopsis>Status of the port</synopsis>
                <typeRef>PortStatusValues</typeRef>
                <defaultValue>2</defaultValue>
             </component>
             <component componentID="7" access="read-only">
                <name>CarrierStatus</name>
                <synopsis>The status of the Carrier. Whether the port
                is linked with
            next header set to Hop-by-Hop.2 The packet length reported
            by an operational connector.</synopsis>
                <typeRef>boolean</typeRef>
                <defaultValue>0</defaultValue>
             </component>
             <component componentID="8" access="read-reset">
                <name>PHYPortStats</name>
                <synopsis>Statistics of the Physical Port.</synopsis>
                <typeRef>PHYPortStatsType</typeRef>
             </component>
          </components>
          <capabilities>
             <capability componentID="30">
                <name>SupportedLinkSpeed</name>
                <synopsis>Supported Link Speeds</synopsis>
                <array>
                   <typeRef>LANSpeedType</typeRef>
                </array>
             </capability>
             <capability componentID="31">
                <name>SupportedDuplexMode</name>
                <synopsis>Supported Duplex Modes</synopsis>
                <array>
                   <typeRef>DuplexType</typeRef>
                </array>
             </capability>
          </capabilities>
          <events baseID="60">
             <event eventID="1">
                <name>PHYPortStatusChanged</name>
                <synopsis>When the status of the Physical port is
                changed,the LFB sends the new status.</synopsis>
                <eventTarget>
                   <eventField>AdminStatus</eventField>
                </eventTarget>
                <eventChanged/>
                <eventReports>
                   <eventReport>
                      <eventField>AdminStatus</eventField>
                   </eventReport>
                </eventReports>
             </event>
             <event eventID="2">
                <name>LinkSpeedChanged</name>
                <synopsis>When the operational speed of the link layer
                is less than changed, the LFB sends the new operational link
                speed.</synopsis>
                <eventTarget>
                   <eventField>OperLinkSpeed</eventField>
                </eventTarget>
                <eventChanged/>
                <eventReports>
                   <eventReport>
                      <eventField>OperLinkSpeed</eventField>
                   </eventReport>
                </eventReports>
             </event>
          </events>
       </LFBClassDef>
       <LFBClassDef LFBClassID="4">
          <name>EtherMACIn</name>
          <synopsis>a LFB abstracts an Ethernet port at MAC data link
          layer. Multiple virtual MACs isn't supported in this LFB
          version.</synopsis>
          <version>1.0</version>
          <inputPorts>
             <inputPort group="false">
                <name>EtherMACIn</name>
                <synopsis>The Input Port of the EtherMACIn. It
                expects any kind of Ethernet frame.</synopsis>
                <expectation>
                   <frameExpected>
                      <ref>EthernetAll</ref>
                   </frameExpected>
                   <metadataExpected>
                      <ref>PHYPortID</ref>
                   </metadataExpected>
                </expectation>
             </inputPort>
          </inputPorts>
          <outputPorts>
             <outputPort group="false">
                <name>NormalPathOut</name>
                <synopsis>The Normal Output Port of the total length field.3 Packet
            with a link local destination address;4 The packet  received
            as limited broadcast.5 Packet EtherMACIn.
                It can produce any kind of Ethernet frame and along
                with multicast destination
            address (the MSB the frame passes the ID of the destination address is 0xFF);
            </synopsis> Physical Port as
                metadata to be used by the next LFBs.</synopsis>
                <product>
                   <frameProduced>
               <ref>IPv6</ref>
                      <ref>EthernetAll</ref>
                   </frameProduced>
                   <metadataProduced>
               <ref>ExceptionID</ref>
                      <ref>PHYPortID</ref>
                   </metadataProduced>
                </product>
             </outputPort>
             <outputPort>
           <name>FailOut</name>
           <synopsis>Output port for packet failing
                <name>L2BridgingPathOut</name>
                <synopsis>The Bridging Output Port of the validation.
           </synopsis> EtherMACIn.
                It can produce any kind of Ethernet frame and along
                with the frame passes the ID of the Physical Port as
                metadata to be used by the next LFBs.</synopsis>
                <product>
                   <frameProduced>
               <ref>IPv6</ref>
                      <ref>EthernetAll</ref>
                   </frameProduced>
                   <metadataProduced>
                      <ref>PHYPortID</ref>
                   </metadataProduced>

                </product>
             </outputPort>
          </outputPorts>
          <components>
             <component componentID="1" access="read-reset">
           <name>IPv6ValidatorStats</name>
           <synopsis>IPv6 validator access="read-only">
                <name>OperStatus</name>
                <synopsis>Operational Status of the LFB.</synopsis>
                <typeRef>PortStatusValues</typeRef>
             </component>
             <component componentID="2" access="read-write">
                <name>LocalMACAddresses</name>
                <synopsis>Local Mac Addresses</synopsis>
                <array>
                   <typeRef>IEEEMAC</typeRef>
                </array>
             </component>
             <component componentID="3" access="read-write">
                <name>L2BridgingPathEnable</name>
                <synopsis>Is the LFB doing L2 Bridging?</synopsis>
                <typeRef>boolean</typeRef>
                <defaultValue>false</defaultValue>
             </component>
             <component componentID="4" access="read-write">
                <name>PromiscuousMode</name>
                <synopsis>Is the LFB in Promiscuous Mode?</synopsis>
                <typeRef>boolean</typeRef>
                <defaultValue>false</defaultValue>
             </component>
             <component componentID="5" access="read-only">
                <name>TxFlowControl</name>
                <synopsis>Transmit Flow control</synopsis>
                <typeRef>boolean</typeRef>
                <defaultValue>false</defaultValue>
             </component>
             <component componentID="6" access="read-write">
                <name>RxFlowControl</name>
                <synopsis>Receive Flow control</synopsis>
                <typeRef>boolean</typeRef>
                <defaultValue>false</defaultValue>
             </component>
             <component componentID="7" access="read-write">
                <name>MTU</name>
                <synopsis>Maximum Transmission Unit</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="8" access="read-reset">
                <name>MACStats</name>
                <synopsis>MAC statistics</synopsis>
           <optional/>
           <typeRef>IPv6ValidatorStatisticsType</typeRef>
                <typeRef>MACStatsType</typeRef>
             </component>
          </components>
       <description>Detailed validation process could refer to RFC2460
        and RFC2373.</description>
       </LFBClassDef>
        <LFBClassDef LFBClassID="9">
       <name>IPv6UcastLPM</name>
       <synopsis>An LFB class definition for IPv6 longest prefix lookup
        function.</synopsis> LFBClassID="5">
          <name>EtherClassifier</name>
          <synopsis>LFB that decapsulates Ethernet II packets and
          classifies them.</synopsis>
          <version>1.0</version>
          <inputPorts>
             <inputPort>
           <name>PktIn</name>
           <synopsis>The
                <name>EtherPktsIn</name>
                <synopsis>Input port to receive IPv6 packets needed to do IPv4
            LPM.</synopsis> for data packet.</synopsis>
                <expectation>
                   <frameExpected>
               <ref>IPv6</ref>
                      <ref>Arbitrary</ref>
                   </frameExpected>
                </expectation>
             </inputPort>
          </inputPorts>
          <outputPorts>
         <outputPort>
           <name>SuccessOut</name>
           <synopsis>Output for packets that have find the correct
            route.</synopsis>
           <product>
             <frameProduced>
               <ref>IPv6</ref>
             </frameProduced>
             <metadataProduced>
               <ref>NextHopID</ref>
             </metadataProduced>
           </product>
         </outputPort>
         <outputPort>
           <name>FailOutput</name>
           <synopsis>LPM failed.</synopsis>
             <outputPort group="true">
                <name>ClassifyOut</name>
                <synopsis>Classify Out</synopsis>
                <product>
                   <frameProduced>
               <ref> IPv6 </ref>
                      <ref>Arbitrary</ref>
                   </frameProduced>
                </product>
             </outputPort>
          </outputPorts>
          <components>
             <component access="read-write" componentID="1">
           <name> PrefixTable </name>
           <synopsis>IPv6 prefix
                <name>EtherDispatchTable</name>
                <synopsis>Ether classify dispatch table</synopsis>
           <array type="variable-size">
             <typeRef> IPv6PrefixTableEntry </typeRef>
             <contentKey contentKeyID="1">
               <contentKeyField>IPv6PrefixTableEntry.prefix
               </contentKeyField>
             </contentKey>
                <array>
                   <typeRef>EtherDispatchTableType</typeRef>
                </array>
             </component>
             <component access="read-write" componentID="2">
           <name>LocalIpv6AddrTable</name>
           <synopsis>The table of interfaces's ip address infomation on
            the local device</synopsis>
           <typeRef>LocalIpv6AddrType</typeRef>
                <name>VlanInputTable</name>
                <synopsis>Vlan input table</synopsis>
                <array>
                   <typeRef>VlanInputTableType</typeRef>
                </array>
             </component>
                <component componentID="3" access="read-reset">
           <name>IPv6Stats</name>
           <synopsis>The IPv6 associated statistics</synopsis>
           <optional/>
           <typeRef> IPv6LPMClassiferStatisticsType </typeRef> access="read-reset" componentID="3">
                <name>EtherClassifyStats</name>
                <synopsis>Ether Classify statistic table</synopsis>
                <array>
                   <typeRef>EtherClassifyStatsType</typeRef>
                </array>
             </component>
          </components>
       <capabilities>
         <capability componentID="1">
           <name>PrefixTableLimit</name>
           <synopsis>maxium number of prefix supported by this LFB
           </synopsis>
           <typeRef>uint32</typeRef>
         </capability>
         <capability componentID="2">
           <name>LocalIpv6AddrTableLimit</name>
           <synopsis>maxium number of IPv6 address entrys supported
            by this LFB</synopsis>
          <capabilities>
             <capability componentID="30">
                <name>MaxOutPutPorts</name>
                <synopsis>Maximum number of ports in the output
                group.</synopsis>
                <typeRef>uint32</typeRef>
             </capability>
          </capabilities>
        </LFBClassDef>
       <LFBClassDef LFBClassID="10">
       <name>IPv6UcastNexthopApplicator</name>
       <synopsis>An LFBClassID="6">
          <name>EtherEncapsulator</name>
          <synopsis>A LFB for applicating next hop action to IPv6 packets,
       actions mainly inlcude TTL incrementation and checksum
        recalculation.</synopsis> that performs packets ethernet L2
          encapsulation.</synopsis>
          <version>1.0</version>
          <inputPorts>
         <inputPort>
           <name>PktIn</name>
           <synopsis>Input port for packets to be applicate nexthop.
           </synopsis>
             <inputPort group="false">
                <name>EncapIn</name>
                <synopsis>A Single Packet Input</synopsis>
                <expectation>
                <frameExpected>
               <ref> IPv6 </ref>
                   <ref>IPv4</ref>
                   <ref>IPv6</ref>
                </frameExpected>
                <metadataExpected>
               <ref>NextHopID</ref>
                   <one-of>
                      <ref>NexthopIPv4Addr</ref>
                      <ref>NexthopIPv6Addr</ref>
                   </one-of>
                   <ref>OutputLogicalPortID</ref>
                   <ref dependency="optional" defaultValue="0">
                   VlanPriority</ref>
                </metadataExpected>
                </expectation>
             </inputPort>
          </inputPorts>
          <outputPorts>
         <outputPort>
             <outputPort group="false">
                <name>SuccessOut</name>
                <synopsis>Output port for packet Packets which have found
                Ethernet L2 information and have been successfully fulfill the
            nexthop application.</synopsis>
                encapsulated to an Ethernet packet.</synopsis>
                <product>
                   <frameProduced>
               <ref> IPv6 </ref>
                      <ref>IPv4</ref>
                      <ref>IPv6</ref>
                   </frameProduced>
                   <metadataProduced>
               <ref>FEID</ref>
               <ref>OutputPortID</ref>
               <ref availability="conditional">L2Index</ref>
               <ref>NextHopIPv6</ref>
               <ref availability="conditional">EncapMethod</ref>
                      <ref>OutputLogicalPortID</ref>
                   </metadataProduced>
                </product>
             </outputPort>
         <outputPort>
           <name>ExceptionOut</name>
             <outputPort group="false">
                <name>PakcetNoARPOut</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 can't find the
              one on which
                associated L2 information in the packet is received.4 The packet is for
               a local interface.</synopsis> ARP table.</synopsis>
                <product>
                   <frameProduced>
               <ref> IPv6 </ref>
                      <ref>IPv4</ref>
                   </frameProduced>
                   <metadataProduced>
               <ref>InputPortID</ref>
               <ref>ExceptionID</ref>
                      <ref>OutputLogicalPortID</ref>
                      <ref>NexthopIPAddr</ref>
                      <ref availability="conditional">VlanPriority</ref>
                   </metadataProduced>
                </product>
             </outputPort>
         <outputPort>
           <name>FailOutput</name>
             <outputPort group="false">
                <name>PakcetNoNbrOut</name>
                <synopsis>Output port for packets failed can't find the nexthop application
            operation.</synopsis>
                associated L2 information in the Nbr table.</synopsis>
                <product>
                   <frameProduced>
               <ref> IPv6 </ref>
                      <ref>IPv6</ref>
                   </frameProduced>
                   <metadataProduced>
                      <ref>OutputLogicalPortID</ref>
                      <ref>NexthopIPAddr</ref>
                      <ref availability="conditional">VlanPriority</ref>
                   </metadataProduced>
                </product>
             </outputPort>
             <outputPort group="false">
                <name>ExceptionOut</name>
                <synopsis>All packets that fail with the other
                operations in this LFB are output via this port.
                </synopsis>
                <product>
                   <frameProduced>
                      <ref>IPv4</ref>
                      <ref>IPv6</ref>

                   </frameProduced>
                   <metadataProduced>
                      <ref>ExceptionID</ref>
                      <ref>OutputLogicalPortID</ref>
                      <ref>NexthopIPAddr</ref>
                      <ref availability="conditional">VlanPriority</ref>
                   </metadataProduced>
                </product>
             </outputPort>
          </outputPorts>
          <components>
             <component componentID="1">
           <name> NextHopTable </name>
           <synopsis>Nexthop table</synopsis> componentID="1" access="read-write">
                <name>ArpTable</name>
                <synopsis>ARP table.</synopsis>
                <array type="variable-size">
                   <typeRef>ArpTableType</typeRef>
                </array>
             </component>
             <component componentID="2" access="read-write">
                <name>NbrTable</name>
                <synopsis>Nbr table.</synopsis>
                <array type="variable-size">
             <typeRef> IPv6NextHopInfoType </typeRef>
                   <typeRef>NbrTableType</typeRef>
                </array>
             </component>
             <component componentID="3" access="read-write">
                <name>VLANOutputTable</name>
                <synopsis>VLAN output table.</synopsis>
                <array type="variable-size">
                   <typeRef>VLANOutputTableType</typeRef>
                </array>
             </component>
          </components>
       <capabilities>
         <capability componentID="1">
           <name>NextHopTableLimit</name>
           <synopsis>Maxium number of nexthops this LFB supports
           </synopsis>
           <typeRef>uint32</typeRef>
         </capability>
       </capabilities>
       </LFBClassDef>
       <LFBClassDef LFBClassID="11">
       <name>EtherEncap</name>
       <synopsis>An LFBClassID="7">
          <name>EtherMACOut</name>
          <synopsis>EtherMACOut LFB classifier definition for completes ethernet
        encapsulation fuctions</synopsis> abstracts an Ethernet port at MAC
          data link layer. It specifically describes Ethernet packet
          output process. Ethernet output functions are closely related
          to Ethernet input functions, therefore many components
          defined in this LFB are actually alias of EtherMACIn LFB.
          </synopsis>
          <version>1.0</version>
          <inputPorts>
         <inputPort>
           <name>EncapIn</name>
           <synopsis>Port for receiving packets needed to build
             <inputPort group="false">
                <name>EtherPacketsIn</name>
                <synopsis>The Input Port of the EtherMACIn. It expects
                any kind of Ethernet
            encapsulation.</synopsis> frame.</synopsis>
                <expectation>
                   <frameExpected>
               <ref>IPv4</ref>
               <ref>IPv6</ref>
                      <ref>EthernetAll</ref>
                   </frameExpected>
                   <metadataExpected>
               <ref dependency="optional" defaultValue="0">L2Index</ref>
               <one-of>
                 <ref>NextHopIP</ref>
                 <ref>NextHopIPv6</ref>
               </one-of>
               <ref>PacketType</ref>
                      <ref>PHYPortID</ref>
                   </metadataExpected>
                </expectation>
             </inputPort>
          </inputPorts>
          <outputPorts>
         <outputPort>
           <name>SuccessOut</name>
           <synopsis/>
           <product>
             <frameProduced>
               <ref>EthernetII</ref>
             </frameProduced>
           </product>

         </outputPort>
             <outputPort group="true">
           <name>ExceptionOut</name>
           <synopsis>packet can't find group="false">
                <name>EtherMACOut</name>
                <synopsis>The Normal Output Port of the associated L2 information
           </synopsis> EtherMACOut. It
                can produce any kind of Ethernet frame and along with
                the frame passes the ID of the Physical Port as
                metadata to be used by the next LFBs.</synopsis>
                <product>
                   <frameProduced>
               <ref>IPv4</ref>
               <ref>IPv6</ref>
                      <ref>EthernetAll</ref>
                   </frameProduced>
                   <metadataProduced>
                      <ref>PHYPortID</ref>
                   </metadataProduced>
                </product>
             </outputPort>
          </outputPorts>
          <components>
             <component componentID="1">
           <name>ArpTable</name>
           <synopsis>Ethernet arp table.</synopsis>
           <array>
             <typeRef>ArpTableEntryType</typeRef>
           </array> componentID="1" access="read-only">
                <name>OperStatus</name>
                <synopsis>Operational Status of the LFB.</synopsis>
                <typeRef>PortStatusValues</typeRef>
             </component>
             <component componentID="2">
           <name>NbrTable</name>
           <synopsis>IPv6 neighbour table.</synopsis>
           <optional/>
           <array>
             <typeRef>NbrTableEntryType</typeRef>
           </array> componentID="2" access="read-only">
                <name>TxFlowControl</name>
                <synopsis>Transmit Flow control</synopsis>
                <typeRef>boolean</typeRef>
                <defaultValue>false</defaultValue>
             </component>
             <component componentID="3">
           <name>DCHostTablev4</name>
           <synopsis>Direct connected host arp table for IPv4.
           </synopsis>
           <array>
             <typeRef>DCHostTableEntryTypev4</typeRef>
           </array> componentID="3" access="read-write">
                <name>RxFlowControl</name>
                <synopsis>Receive Flow control</synopsis>
                <typeRef>boolean</typeRef>
                <defaultValue>false</defaultValue>
             </component>
             <component componentID="4">
           <name>DCHostTablev6</name>
           <synopsis>Direct connected host arp table for IPv6.
           </synopsis>
           <optional/>
           <array>
             <typeRef>DCHostTableEntryTypev6</typeRef>
           </array> componentID="4" access="read-reset">
                <name>MACStats</name>
                <synopsis>MAC statistics</synopsis>
                <typeRef>MACStatsType</typeRef>
             </component>
          </components>
       <capabilities>
         <capability componentID="1">
           <name>ArpTableLimit</name>
           <synopsis>Max number of arp entries in arp table.</synopsis>
           <typeRef>uint32</typeRef>
         </capability>
         <capability componentID="2">
           <name>NbrTableLimit</name>
           <synopsis>Max number of neighbours in neighbour table.
           </synopsis>
           <optional/>
           <typeRef>uint32</typeRef>
         </capability>
         <capability componentID="3">
           <name>DCHostTablev4Limit</name>
           <synopsis>The limit on Direct connected host table for IPv4.
           </synopsis>
           <typeRef>uint32</typeRef>
         </capability>
         <capability componentID="4">
           <name>DCHostTablev6Limit</name>
           <synopsis>The limit on Direct connected host table for IPv6.
           </synopsis>
           <optional/>
           <typeRef>uint32</typeRef>
         </capability>
       </capabilities>
       </LFBClassDef>
        <LFBClassDef LFBClassID="12">
       <name>Scheduler</name>
       <synopsis>Base scheduler LFB.</synopsis> LFBClassID="8">
          <name>IPv4Validator</name>
          <synopsis>a LFB that performs IPv4 packets validation
          according to RFC1812 and RFC2644.</synopsis>
          <version>1.0</version>
          <inputPorts>
         <inputPort group="true">
           <name>Watcher</name>
             <inputPort>
                <name>ValidatePktsIn</name>
                <synopsis>Input port for watching the queues to be scheduled.
           Queues to be scheduled can transmit packet enqueue and
           dequeue infomation to scheduler through these port.
           </synopsis> data packet.</synopsis>
                <expectation>
                   <frameExpected>
               <ref>MetadataFrame</ref>
                      <ref>Arbitrary</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
             <outputPort>
                <name>IPv4UnicastOut</name>
                <synopsis>Output for IPv4 unicast packet.</synopsis>
                <product>
                   <frameProduced>
                      <ref>IPv4Unicast</ref>
                   </frameProduced>
                </product>
             </outputPort>
             <outputPort>
                <name>IPv4MulticastOut</name>
                <synopsis>Output for IPv4 multicast packet.</synopsis>
                <product>
                   <frameProduced>
                      <ref>IPv4Multicast</ref>
                   </frameProduced>
                </product>
             </outputPort>
             <outputPort>
                <name>ExceptionOut</name>
                <synopsis>Output for exception packet.</synopsis>
                <product>
                   <frameProduced>
               <ref>MetadataFrame</ref>
                      <ref>IPv4</ref>
                   </frameProduced>
                   <metadataProduced>
                      <ref>ExceptionID</ref>

                   </metadataProduced>
                </product>
             </outputPort>
             <outputPort>
                <name>FailOutput</name>
                <synopsis>Output for failed validation packet.
                </synopsis>
                <product>
                   <frameProduced>
                      <ref>IPv4</ref>
                   </frameProduced>
                   <metadataProduced>
               <ref>QueueOperationCmd</ref>
                      <ref>ValidateErrorID</ref>
                   </metadataProduced>
                </product>
             </outputPort>
          </outputPorts>
       <capabilities>
         <capability
          <components>
             <component access="read-write" componentID="1">
           <name>QueueScheduledLimit</name>
           <synopsis>Max number of queues that can be scheduled by this
           scheduler.</synopsis>
           <typeRef>uint32</typeRef>
         </capability>
       </capabilities>
                <name>IPv4ValidatorStats</name>
                <synopsis>Ether classify dispatch table</synopsis>
                <typeRef>IPv4ValidatorStatisticsType</typeRef>
             </component>
          </components>
        </LFBClassDef>
        <LFBClassDef LFBClassID="13">
       <name> Queue </name>
       <synopsis>Queue LFB.</synopsis> LFBClassID="9">
          <name>IPv6Validator</name>
          <synopsis>A LFB that performs IPv6 packets validation
          according to RFC2460 and RFC4291.</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>ValidatePktsIn</name>
                <synopsis>Input port for data packet.</synopsis>
                <expectation>
                   <frameExpected>
                      <ref>Arbitrary</ref>
                   </frameExpected>
             <metadataExpected>
               <ref>PacketLength</ref>
             </metadataExpected>
                </expectation>
             </inputPort>
          </inputPorts>
          <outputPorts>
             <outputPort>
           <name>OutToController</name>
                <name>IPv6UnicastOut</name>
                <synopsis>Output to queue controller</synopsis> for IPv6 unicast packet.</synopsis>
                <product>
                   <frameProduced>
                      <ref>IPv6Unicast</ref>

                   </frameProduced>
                </product>
             </outputPort>
             <outputPort>
                <name>IPv6MulticastOut</name>
                <synopsis>Output for IPv6 multicast packet.</synopsis>
                <product>
                   <frameProduced>
                      <ref>IPv6Multicast</ref>
                   </frameProduced>
                </product>
             </outputPort>
             <outputPort>
                <name>ExceptionOut</name>
                <synopsis>Output for exception packet.</synopsis>
                <product>
                   <frameProduced>
               <ref>MetadataFrame</ref>
                      <ref>IPv6</ref>
                   </frameProduced>
                   <metadataProduced>
               <ref>QueueID</ref>
               <ref>PacketLength</ref>
               <ref>QueueOperationCmd</ref>
                      <ref>ExceptionID</ref>
                   </metadataProduced>
                </product>
             </outputPort>
             <outputPort>
           <name>OutData</name>
           <synopsis>Data packet output</synopsis>
                <name>FailOutput</name>
                <synopsis>Output for failed validation packet.
                </synopsis>
                <product>
                   <frameProduced>
               <ref>Arbitrary</ref>
                      <ref>IPv6</ref>
                   </frameProduced>
                   <metadataProduced>
                      <ref>ValidateErrorID</ref>
                   </metadataProduced>
                </product>
             </outputPort>
          </outputPorts>
          <components>
             <component access="read-write" componentID="1">
           <name>CurLen</name>
           <synopsis>Current length of the queue in number of packets.
           </synopsis>
           <typeRef>uint32</typeRef>
                <name>IPv6ValidatorStats</name>
                <synopsis>Ether classify dispatch table</synopsis>
                <typeRef>IPv6ValidatorStatisticsType</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="14">
       <name>RedirectSink</name>
       <synopsis>This class definition provides for the function of
       sinking data packets LFBClassID="10">
          <name>IPv4UcastLPM </name>
          <synopsis>a LFB that needed to be sent to CE. </synopsis> performs IPv4 Longest Prefix Match
          Lookup.</synopsis>
          <version>1.0</version>
          <inputPorts>
             <inputPort group="true">
           <name>InFromOtherLFBs</name>
           <synopsis>Packets input from other LFBs and needed to sent
           to CE.</synopsis> group="false">
                <name>PktIn</name>
                <synopsis>A Single Packet Input</synopsis>
                <expectation>
                <frameExpected>
               <ref>IPv4</ref>
               <ref>IPv6</ref>
                   <ref>IPv4Unicast</ref>
                </frameExpected>
                <metadataExpected>
               <ref>InputPortID</ref>
               <ref>PacketLength</ref>
               <ref>PacketType</ref>
                   <ref>DstIPv4Address</ref>
                </metadataExpected>
                </expectation>
             </inputPort>
          </inputPorts>
     </LFBClassDef>
     <LFBClassDef LFBClassID="15">
       <name>RedirectTap</name>
          <outputPorts>
             <outputPort group="false">
                <name>NormalOut</name>
                <synopsis>This class provides output port is connected with
                IPv4NextHopApplicator LFB</synopsis>
                <product>
                   <frameProduced>
                      <ref>IPv4Unicast</ref>
                   </frameProduced>
                   <metadataProduced>
                      <ref>HopSelector</ref>
                   </metadataProduced>
                </product>
             </outputPort>
             <outputPort group="false">
                <name>ECMPOut</name>
                <synopsis>This output port is connected with ECMP LFB,
                if there is ECMP LFB in the function of sinking data
       packets that comes from CE and needed to be sent out by this FE.</synopsis>
       <version>1.0</version>
       <outputPorts>
                <product>
                   <frameProduced>
                      <ref>IPv4Unicast</ref>
                   </frameProduced>
                   <metadataProduced>
                      <ref>HopSelector</ref>
                   </metadataProduced>
                </product>
             </outputPort>
             <outputPort group="true">
           <name>OutputToOtherLFBs</name>
           <synopsis>Packets input received from CE.</synopsis> group="false">
                <name>ExceptionOut</name>
                <synopsis>The output for the packet if an exception
                occurs</synopsis>
                <product>
                   <frameProduced>
               <ref>IPv4</ref>
               <ref>IPv6</ref>
                      <ref>IPv4Unicast</ref>
                   </frameProduced>
                   <metadataProduced>
               <ref>PacketType</ref>
               <ref>OutputPortID</ref>
               <ref>PacketLength</ref>
                      <ref>ExceptionID</ref>
                   </metadataProduced>
                </product>
             </outputPort>
          </outputPorts>
          <components>
             <component componentID="1">
           <name>DispatchTable</name>
           <synopsis>The table to dispatch the packets to different LFB.
           </synopsis>
           <typeRef>DispatchTableType</typeRef>
         </component>
         <component componentID="2">
           <name>outGroupNumOfPorts</name>
           <synopsis>The number of ports in output group.</synopsis>
           <typeRef>uint32</typeRef>
         </component>
       </components>
       <capabilities>
         <capability componentID="1">
           <name>MaxNumOfoutGroupPorts</name> componentID="1" access="read-write">
                <name>IPv4PrefixTable</name>
                <synopsis>The maxium number of ports in the output group.
           </synopsis>
           <typeRef>uint32</typeRef>
         </capability>
       </capabilities>
     </LFBClassDef>
     <LFBClassDef LFBClassID="16">
       <name>WRRSched</name>
       <synopsis>Weighted round robin scheduler.</synopsis>
       <version>1.0</version>
       <derivedFrom>Scheduler</derivedFrom>
       <components>
         <component componentID="1">
           <name>WeightTable</name>
           <synopsis>Weight table for queues to be scheduled.</synopsis> IPv4 Prefix Table.</synopsis>
                <array type="variable-size">
             <typeRef>WeightTableEntryType</typeRef>
                   <typeRef>IPv4PrefixTableType</typeRef>
                </array>
             </component>
             <component componentID="2" access="read-reset">
                <name>IPv4UcastLPMStats</name>
                <synopsis>Statistics for IPv4 Unicast Longest Prefix
                Match</synopsis>
                <typeRef>IPv4UcastLPMStatsType</typeRef>
             </component>
          </components>
       </LFBClassDef>
       <LFBClassDef LFBClassID="17">
       <name>IPv6AddrResolution</name>
       <synopsis>This LFBClassID="11">
          <name>IPv6UcastLPM </name>
          <synopsis>A LFB class provides the function of that performs IPv6 address
       resolution part of neighbor discovery protocol.It provides an
       offload of ND protocol processing to FE.It process the following
       ND messages:neighbour solicitation and neighbour advertisement.
       </synopsis> Longest Prefix Match
          Lookup.</synopsis>
          <version>1.0</version>
          <inputPorts>
         <inputPort>
           <name>AddrResDataPktIn</name>
           <synopsis>The IPv6 data packet that need to do the address
           resolution.</synopsis>
           <expectation>
             <frameExpected>
               <ref>IPv6</ref>
             </frameExpected>
           </expectation>
         </inputPort>
         <inputPort>
           <name>AddrResProtoPktIn</name>
           <synopsis>The neighbour discovery packet related to
           addresolution.</synopsis>
             <inputPort group="false">
                <name>PktIn</name>
                <synopsis>A Single Packet Input</synopsis>
                <expectation>
                <frameExpected>
               <ref>IPv6</ref>
                   <ref>IPv6Unicast</ref>
                </frameExpected>
                <metadataExpected>
                   <ref>DstIPv6Address</ref>
                </metadataExpected>
                </expectation>
             </inputPort>
          </inputPorts>
          <outputPorts>
         <outputPort>
           <name>AddrResDataPktOut</name>
           <synopsis>The IPv6 packet that have encapsulated
             <outputPort group="false">
                <name>NormalOut</name>
                <synopsis>This output port is connected with
                IPv6NextHopApplicator LFB</synopsis>
                <product>
                   <frameProduced>
                      <ref>IPv6Unicast</ref>
                   </frameProduced>
                   <metadataProduced>
                      <ref>HopSelector</ref>
                   </metadataProduced>
                </product>
             </outputPort>
             <outputPort group="false">
                <name>ECMPOut</name>
                <synopsis>This output port is connected with ECMP LFB,
                if there is ECMP LFB in the
           correct ethernet L2 info and need to be sent out to link.
           </synopsis> FE.</synopsis>
                <product>
                   <frameProduced>
               <ref>EthernetII</ref>
                      <ref>IPv6Unicast</ref>
                   </frameProduced>
                   <metadataProduced>
                      <ref>HopSelector</ref>
                   </metadataProduced>
                </product>
             </outputPort>
         <outputPort>
           <name>AddrResProtoPktOut</name>
             <outputPort group="false">
                <name>ExceptionOut</name>
                <synopsis>The IPv6 neighbour discovey packet wich has been
           encapsulation with output for the correct ethernet L2 info.</synopsis> packet if an exception
                occurs</synopsis>
                <product>
                   <frameProduced>
               <ref>EthernetII</ref>
                      <ref>IPv6Unicast</ref>
                   </frameProduced>
                   <metadataProduced>
                      <ref>ExceptionID</ref>
                   </metadataProduced>
                </product>
             </outputPort>
          </outputPorts>
          <components>
             <component componentID="1">
           <name>Nbrtable</name>
           <synopsis>This table is an alias to the componentID="1" access="read-write">
                <name>IPv6PrefixTable</name>
                <synopsis>The IPv6 neighbour table
           in the EtherEncap LFB.</synopsis>
           <alias>NbrTable</alias> Prefix Table.</synopsis>
                <array type="variable-size">
                   <typeRef>IPv6PrefixTableType</typeRef>
                </array>
             </component>
             <component componentID="2" access="read-reset">
                <name>IPv6UcastLPMStats</name>
                <synopsis>Statistics for IPv6 Unicast Longest Prefix
                Match</synopsis>
                <typeRef>IPv6UcastLPMStatsType</typeRef>
             </component>
          </components>
       </LFBClassDef>
       <LFBClassDef LFBClassID="18">
       <name>ICMPv6Generator</name>
       <synopsis>This LFBClassID="12">
          <name>IPv4NextHopApplicator</name>
          <synopsis>A LFB class provide some basic ICMPv6 function,it
       only generate for applicating next hop action to IPv4
          packets,the actions include:TTL operation,checksum
          recalculation. The input packets with the following ICMP messages for metadata
          "HopSelector"(the nexthop ID), get the packets that
       need some basic icmp processing:destination not reachable and
       time excceeded.</synopsis> nexthop
          information through looking up nexthop table.</synopsis>
          <version>1.0</version>
          <inputPorts>
         <inputPort>
             <inputPort group="false">
                <name>PktIn</name>
           <synopsis>The IPv6 packet that need icmp processing.
           </synopsis>
                <synopsis>A Single Packet Input</synopsis>
                <expectation>
                <frameExpected>
               <ref>IPv6</ref>
                   <ref>IPv4Unicast</ref>
                </frameExpected>
                <metadataExpected>
               <ref>ExceptionID</ref>
                   <ref>HopSelector</ref>
                </metadataExpected>
                </expectation>
             </inputPort>
          </inputPorts>
          <outputPorts>
         <outputPort>
           <name>ICMPv6PktOut</name>
             <outputPort group="true">
                <name>SuccessOut</name>
                <synopsis>The output for the ICMPv6 packets generated
           according packet if it is valid to be
                forwarded</synopsis>
                <product>
                   <frameProduced>
                      <ref>IPv4Unicast</ref>
                   </frameProduced>
                   <metadataProduced>
                      <ref>OutputLogicalPortID</ref>
                      <ref>NextHopIPv4Addr</ref>
                   </metadataProduced>
                </product>
             </outputPort>
             <outputPort group="false">
                <name>ExceptionOut</name>
                <synopsis>The output for the input IPv6 packet and the ExceptionID.
           </synopsis> if an exception
                occurs</synopsis>
                <product>
                   <frameProduced>
               <ref>IPv6</ref>
                      <ref>IPv4Unicast</ref>
                   </frameProduced>
                   <metadataProduced>
                      <ref>ExceptionID</ref>
                   </metadataProduced>
                </product>
             </outputPort>
          </outputPorts>
          <components>
             <component componentID="1">
                <name>IPv4NextHopTable</name>
                <synopsis>The Next Hop Table.</synopsis>
                <array>
                   <typeRef>IPv4NextHopTableType</typeRef>
                </array>
             </component>
          </components>
          <capabilities>
             <capability componentID="30">
                <name>MaxOutPutPorts</name>
                <synopsis>Maximum number of ports in the output group.
                </synopsis>
                <typeRef>uint32</typeRef>
             </capability>
          </capabilities>
       </LFBClassDef>
       <LFBClassDef LFBClassID="19">
       <name>ExtendHeaderProc</name>
       <synopsis>This LFBClassID="13">
          <name>IPv6NextHopApplicator</name>
          <synopsis>A LFB class process the definition for applicating next hop action to
           IPv6 packet packets,the actions include:TTL operation,checksum
           recalculation. The input packets with extended
       header,For the moment,the packets to this LFB are redirect to
       RedirectSink LFB by default.</synopsis> metadata
           "HopSelector"(the nexthop ID), get the nexthop information
          through looking up nexthop table.</synopsis>
          <version>1.0</version>
          <inputPorts>
         <inputPort>
             <inputPort group="false">
                <name>PktIn</name>
           <synopsis>The IPv6 packet with extended header in.</synopsis>
                <synopsis>A Single Packet Input</synopsis>
                <expectation>
                <frameExpected>
               <ref>IPv6</ref>
                   <ref>IPv6Unicast</ref>
                </frameExpected>
                <metadataExpected>
                   <ref>HopSelector</ref>
                </metadataExpected>
                </expectation>
             </inputPort>

          </inputPorts>
          <outputPorts>
             <outputPort group="true">
           <name>PktOut</name>
           <synopsis>According to the Extended header type
                <name>SuccessOut</name>
                <synopsis>The output for the packet
           may have different next proccesing LFB.Now by default we
           send all if it is valid to
                be forwarded</synopsis>
                <product>
                   <frameProduced>
                      <ref>IPv6Unicast</ref>
                   </frameProduced>
                   <metadataProduced>
                      <ref>OutputLogicalPortID</ref>
                      <ref>NextHopIPv6Addr</ref>
                   </metadataProduced>
                </product>
             </outputPort>
             <outputPort group="false">
                <name>ExceptionOut</name>
                <synopsis>The output for the packet with extended header to CE.</synopsis> if an exception
                occurs</synopsis>
                <product>
                   <frameProduced>
               <ref>IPv6</ref>
                      <ref>IPv6Unicast</ref>
                   </frameProduced>
                   <metadataProduced>
                      <ref>ExceptionID</ref>
                   </metadataProduced>
                </product>
             </outputPort>
          </outputPorts>
          <components>
             <component componentID="1">
                <name>IPv6NextHopTable</name>
                <synopsis>The Next Hop Table.</synopsis>
                <array>
                   <typeRef>IPv6NextHopTableType</typeRef>
                </array>
             </component>
          </components>
          <capabilities>
             <capability componentID="30">
                <name>MaxOutPutPorts</name>
                <synopsis>Maximum number of ports in the output group.
                </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="14">
          <name>ARP</name>
          <synopsis>ARP</synopsis>
          <version>1.0</version>
          <inputPorts>
         <inputPort>
           <name>AddrResDataPktIn</name>
             <inputPort group="false">
                <name>ArpPktsIn</name>
                <synopsis>The IPv4 data packet that need to do the address
           resolution.</synopsis> input port for ARP packets.</synopsis>
                <expectation>
                      <frameExpected>
               <ref>IPv4</ref>
                         <ref>ARP</ref>
                      </frameExpected>
                      <metadataExpected>
                         <ref>PHYPortID</ref>
                         <ref>LogicalPortID</ref>
                         <ref>SrcMAC</ref>
                         <ref>DstMAC</ref>
                      </metadataExpected>
                   </expectation>
                </inputPort>
         <inputPort>
           <name>ArpPktIn</name>
             <inputPort group="false">
                <name>AddrResDataPktIn</name>
                <synopsis>The neighbour discovery input port for the packet related to
           addresolution.</synopsis> which need
                address resolution..</synopsis>
                <expectation>
                      <frameExpected>
                         <ref>IPv4</ref>
                      </frameExpected>
                      <metadataExpected>
                         <ref>NexthopIPv4Addr</ref>
                         <ref>OutputLogicalPortID</ref>
                         <ref dependency="optional" defaultValue="0">
                         VlanID</ref>
                         <ref dependency="optional" defaultValue="0">
                         VlanPriority</ref>
                      </metadataExpected>
                   </expectation>
                </inputPort>
             </inputPorts>
          <outputPorts>
         <outputPort>
             <outputPort group="false">
                <name>ArpOut</name>
                <synopsis>The output port for Arp packets.</synopsis>
                <product>
                   <frameProduced>
                      <ref>EthernetII</ref>
                   </frameProduced>
                   <metadataProduced>
                      <ref>OutputLogicalPortID</ref>
                   </metadataProduced>
                </product>
             </outputPort>
             <outputPort group="false">
                <name>AddrResDataPktOut</name>
                <synopsis>The IPv4 output port for the packet that have which has been
                encapsulated with the correct ethernet L2 info and need to be sent out to
           link.</synopsis> head.</synopsis>
                <product>
                   <frameProduced>
                      <ref>EthernetII</ref>
                   </frameProduced>
                   <metadataProduced>
                      <ref>OutputLogicalPortID</ref>
                   </metadataProduced>
                </product>
             </outputPort>
         <outputPort>
           <name>ArpOut</name>
          </outputPorts>
          <components>
             <component componentID="1">
                <name>PortV4AddrInfoTable</name>
                <synopsis>The arp IPv4 address for all local ports.
                </synopsis>
                <array>
                   <typeRef>Portv4AddrInfoTableType</typeRef>
                </array>
             </component>
          </components>
       </LFBClassDef>
       <LFBClassDef LFBClassID="15">
          <name>ND</name>
          <synopsis>TBD</synopsis>
          <version>1.0</version>
       </LFBClassDef>
       <LFBClassDef LFBClassID="16">
          <name>RedirectIn</name>
          <synopsis>The RedirectIn LFB abstracts the process for CE to
          inject data packets into FE LFB topology so as to input data
           packets into FE data paths. From LFB topology point of view,
           the RedirectIn LFB acts as a source point for data packets
           coming from CE, therefore the RedirectIn LFB is defined with
          only one output, while without any input. Output of the
          RedirectIn LFB is defined as a group output. Packets produced
          by the output will have arbitrary frame types decided by CE
          which generates the packets. Possible frames may include IPv4,
          IPv6, or ARP protocol packets. CE may associate some metadata
          to indicate the frame types. CE may also associate other
          metadata to data packets to indicate various information on
          the packets. Among them, there MUST exist a 'RedirectIndex'
          metadata, which is an integer acting as an index. When CE
          transmits the metadata and a binging packet to a RedirectIn
          LFB, the LFB will read the metadata and output the packet to
          one of its group output port instance, whose port index is
          just as indicated by the metadata.All metadata from CE other
          than the 'RedirectIndex' metadata will output from the
          RedirectIn LFB along with their binding packets. Note that,
          a packet without a 'RedirectIndex' metadata associated
          will be dropped by the LFB.</synopsis>
          <version>1.0</version>
          <outputPorts>
             <outputPort group="true">
                <name>PacketOut</name>
                <synopsis>This output group sends the redirected packet out.</synopsis>
                 in the data path.</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
          <capabilities>
             <capability componentID="30">
                <name>MaxOutPutPorts</name>
                <synopsis>Maximum number of the arp table ports in the
           EtherEncap LFB.</synopsis>
           <alias>ArpTable</alias>
         </component>
       </components> output group
                </synopsis>
                <typeRef>uint32</typeRef>
             </capability>
          </capabilities>
       </LFBClassDef>
       <LFBClassDef LFBClassID="21">
       <name>ICMPGenerator</name>
       <synopsis>This LFBClassID="17">
          <name>RedirectOut</name>
          <synopsis>A RedirectOut LFB class provide some basic ICMP function,it abstracts the process for LFBs in
          FE to deliver data packets to CE. From LFB topology point of
          view, the RedirectOut LFB acts as a sink point for data
          packets going to CE, therefore the RedirectOut LFB is defined
          with only generate one input, while without any output.Input of the following ICMP messages:ICMP destination
       unreachable and time excceeded.</synopsis>
          RedirectOut LFB is defined as a singleton input, but it is
          capable of receiving packets from multiple LFBs by
          multiplexing the singleton input. Packets expected by the
          input will have arbitrary frame types. All metadata
          associated with the input packets will be delivered to CE
          via the redirect message of ForCES protocol [RFC5810],
          therefore the input will expect all types of metadata.
          </synopsis>
          <version>1.0</version>
          <inputPorts>
         <inputPort>
           <name>PktIn</name>
           <synopsis>The IPv4 packet that need icmp processing.
           </synopsis>
             <inputPort group="false">
                <name>PacketIn</name>
                <synopsis>This input group receives packets to send to
                the CE.</synopsis>
                <expectation>
                   <frameExpected>
               <ref>IPv4</ref>
                      <ref>Arbitrary</ref>
                   </frameExpected>
             <metadataExpected>
               <ref>ExceptionID</ref>

             </metadataExpected>
                </expectation>
             </inputPort>
          </inputPorts>
       <outputPorts>
         <outputPort>
           <name>ICMPPktOut</name>
           <synopsis>The output for the ICMP packets generated according
           to the input packet and the ExceptionID.</synopsis>
           <product>
             <frameProduced>
               <ref>IPv4</ref>
             </frameProduced>
           </product>
         </outputPort>
       </outputPorts>
       </LFBClassDef>
        <LFBClassDef LFBClassID="22">
       <name>MetadataClassifier</name> LFBClassID="18">
          <name>BasicMetadataDispatch</name>
          <synopsis>This LFB class provides the function of classify to dispatch input
          packets to a group output according to the meta data.Now it only works on one
       meta data.</synopsis> a metadata and a
          dispatch table.</synopsis>
          <version>1.0</version>
          <inputPorts>
             <inputPort>
           <name>PktIn</name>
           <synopsis>Packets need to do the classification.</synopsis>
                <name>PacketsIn</name>
                <synopsis>Input port for data packet.</synopsis>
                <expectation>
                   <frameExpected>
                      <ref>Arbitrary</ref>
                   </frameExpected>
                   <metadataExpected>
                      <ref>Arbitrary</ref>
                   </metadataExpected>
             <!-- jfg:how to express here that we only need one meta
             data of any kind?The model says that variable  tag
             metadata do this need but doesn't show how to use it.-->
                </expectation>
             </inputPort>
          </inputPorts>
          <outputPorts>
             <outputPort group="true">
           <name>ClassifiedOut</name>
           <synopsis>The output group for the classified packets.
           </synopsis> group="true">
                <name>PacketsOut</name>
                <synopsis>Data packet output</synopsis>
                <product>
                   <frameProduced>
                      <ref>Arbitrary</ref>
                   </frameProduced>
                </product>
             </outputPort>
          </outputPorts>
          <components>
             <component access="read-write" componentID="1">
           <name>MetaDataID</name>
           <synopsis>The metadata id that this classifier works on.
           </synopsis>
           <typeRef>uint32</typeRef>
         </component>
         <component componentID="2">
           <name>MetaDataName</name>
           <synopsis>The name of the meta data that this classifier
           works on.</synopsis>
           <typeRef>string</typeRef>
         </component>
         <component componentID="3">
           <name>MetadataClassifyTable</name>
           <synopsis>The meta data classifying
                <name>MetadataDispatchTable</name>
                <synopsis>metadata dispatch table.</synopsis>
           <typeRef>MetadataClassyTableType</typeRef>
         </component>
         <component componentID="4">
           <name>OutNumOfPorts</name>
           <synopsis>The number of ports in the output group.</synopsis>
           <typeRef>uint32</typeRef>
                <typeRef>MetadataDispatchTableType</typeRef>
             </component>
          </components>
          <capabilities>
             <capability componentID="1">
           <name>MaxOutNumOfPorts</name> componentID="30">
                <name>MaxOutPutPorts</name>
                <synopsis>Maxium number of ports in the output group.
                </synopsis>
                <typeRef>uint32</typeRef>
             </capability>
          </capabilities>
        </LFBClassDef>
        <LFBClassDef LFBClassID="23">
       <name>OptionProc</name>
       <synopsis>This LFB class process the IPv4 packet with options,
       it can process on the following options:Router-alert option.
       </synopsis> LFBClassID="19">
          <name>GenericScheduler</name>
          <synopsis>Generic Scheduler LFB.</synopsis>
          <version>1.0</version>
          <inputPorts>
         <inputPort>
           <name>PktIn</name>
           <synopsis>The IPv4 packet with options in.</synopsis>
             <inputPort group="true">
                <name>PacketsIn</name>
                <synopsis>Input port for data packet.</synopsis>
                <expectation>
                   <frameExpected>
               <ref>IPv4</ref>
                      <ref>Arbitrary</ref>
                   </frameExpected>
                </expectation>
             </inputPort>
          </inputPorts>
          <outputPorts>
         <outputPort group="true">
           <name>PktOut</name>
           <synopsis>According to the Option type the packet may have
           different next proccesing LFB.Now by default we send all
           the
             <outputPort>
                <name>PacketsOut</name>
                <synopsis>Data packet with extended header to CE.</synopsis> output</synopsis>
                <product>
                   <frameProduced>
               <ref>IPv4</ref>
                      <ref>Arbitrary</ref>
                   </frameProduced>
                </product>
             </outputPort>
          </outputPorts>
     </LFBClassDef>
   </LFBClassDefs>
 </LFBLibrary>

8.  Base LFB Library Use Case for Typical Router Functions

   This section demonstrates examples on how the LFB classes defined by
   the Base LFB library in Section 7 are applied to the achievements
          <components>
             <component access="read-only" componentID="1">
                <name>QueueCount</name>
                <synopsis>the number of
   typical router functions.

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

   o  IP forwarding

   o  address resolution

   o  ICMP

   o  network management

   o  running routing protocol

   To achieve the functions, processing paths organized by the LFB
   classes with their interconnections should queues to be established in FE.  In
   general, CE controls and manages the processing paths by use scheduled.
                </synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component access="read-write" componentID="2">
                <name>SchedulingDiscipline</name>
                <synopsis>the Scheduler discipline.</synopsis>
                <typeRef>SchdDisciplineType</typeRef>
             </component>
             <component access="read-only" componentID="3">
                <name>CurrentQueueDepth</name>
                <synopsis>Current Depth of the
   ForCES protocol.

   Note all queues</synopsis>
                <array>
                   <typeRef>QueueDepth</typeRef>
                </array>
             </component>
          </components>
          <capabilities>
             <capability componentID="30">
                <name>QueueLenLimit</name>
                <synopsis>Maximum length of each queue,the unit is
                byte.</synopsis>
                <typeRef>uint32</typeRef>
             </capability>
             <capability componentID="31">
                <name>QueueScheduledLimit</name>
                <synopsis>Max number of queues that LFB class use cases shown in can be scheduled by
                this scheduluer.</synopsis>
                <typeRef>uint32</typeRef>
             </capability>
             <capability componentID="32">
                <name>DisciplinesSupported</name>
                <synopsis>the scheduling disciplines supported.
                </synopsis>
                <array type="variable-size" maxLength="6">
                   <typeRef>SchdDisciplineType</typeRef>
                </array>
             </capability>
          </capabilities>
        </LFBClassDef>
    </LFBClassDefs>
 </LFBLibrary>

7.  Use Library for Typical Router Functions

   This section are only as demonstrates examples to demonstrate on how typical router functions can be
   implemented with the defined base LFB library.  Users and
   implementors of the base LFB library should not be limited by the
   examples.

8.1.  IP Forwardings

   IP packets to be forwarded are from interfaces conneted via a kind of
   media to outer networks.  A Port LFB receives link layer packets.  CE
   may control the port LFB status classes defined by
   the Base LFB components defined library in the
   library.  Link layer packets Section 6 are delivered to a decapsulation LFB to
   decapsulate to IP packets.  The LFB also provides IP packet
   distinguishing by classifying IP packet according applied to its types like
   IPv4 or IPv6, unicast or multicast, and ARP packet.  The packet type
   information is included achieve typical
   router functions.

   As mentioned in a IPPacketType metadata and the metadata
   is associated with every decapsulated IP packet.

   Followed decapsulation LFBs are usually IP validation LFBs which
   further validate IP packets according to IP protocol.  The LFB also
   distinguishes if the IP packets are exceptional packets like ICMP
   packets other than IP packets to overview section, typical router functions can be further forwarded.  The
   exceptional packets are then associated with metadata indicating the
   packet types and delivered to metadata classifier for specific
   classification and further processing.

   Validated IP unicast packets for forwarding are delivered to unicast
   Longes Prifix Match(UcastLPM) LFB, which produce nexthop information
   for forwarding.  The nexthop information is represented by a
   nexthopID metadata.

   IP packets with associated nexthop metadata are delivered to the
   NextHopApplicator LFB.  The LFB decides output ports for
   categorized in short into the following functions:

   o  IP
   packets.  Note that when IP packets need to traverse FEs for
   forwarding, the LFB may also only decides forwarding

   o  address resolution

   o  ICMP

   o  network management

   o  running routing protocol

   To achieve the local FE output port to functions, processing paths organized by the other FE LFB
   classes with their interconnections should be established in FE.  In
   general, CE controls and makes manages the packet to carry processing paths by use of the nexthop information to
   ForCES protocol.

   Note that FE.

   IP packets with nexthop applied are then encapsulated by a link layer
   encapsulation LFB according to the egress media and put on to the
   appropriate output ports.  In class use cases shown in this process, address resolution LFBs
   may have section are only as
   examples to demonstrate how typical router functions can be applied to decide the link layer output addresses for
   the packets.  Moreover,
   implemented with the queue management LFBs defined base LFB library.  Users and scheduler LFBs
   may
   implementers should not be applied in limited by the process to achieve individual QoS requirements. examples.

7.1.  IP Forwarding

   Figure 1 shows the typical LFB processing path for the IPv4 unicast
   forwarding case. case with Ethernet media interfaces.

         +-----+                +------+
         |     |                |      |
         |     |<---------------|Ether |<----------------------------+
         |     |                |MACOut|                             |
         |     |                |      |                             |
         |Ether|                +------+                             |
         |MAC  |                                                     |
         |Cop  |            +---+                                    |
         |#1   |  +-----+   |   |----->IPv6 Packets                  |
         |     |  |     |   |   |    +----+                          |
         |     |  |Ether|   |   |    |    |                          |
         |     |->|MACIn|-->|   |IPv4|    |                          |
         +-----+  |     |   |   |-+->|    |                 +---+    |
                  +-----+   +--+  |  |    |unicast +-----+  |   |    |
                        Ether     |  |    |------->|     |  |   |    |
            .           Classifier|  |    |packet  |IPv4 |  |   |    |
            .                     |  |    |        |Ucast|->|   |--+ |
            .                     |  |    |        |LPM  |  |   |  | |
                            +---+ |  +----+        +-----+  |   |  | |
                  +-----+   |   | |   IPv4                  +---+  | |
                  |     |   |   | |   Validator              IPv4  | |
         +-----+  |Ether|   |   |-+                        NextHop | |
         |     |->|MACIn|-->|   |IPv4                    Applicator| |
         |     |  |     |   |   |----->IPv6 Packets                | |
         |Ether|  +-----+   +---+              +----+              | |
         |MAC  |           Ether               |    |              | |
         |Cop  |          Classifier           |    |   +-------+  | |
         |#n   |                               |    |   |       |  | |
         |     |                +------+       |    |<--| Ether |<-+ |
         |     |                |      |<------|    |   | Encap |    |
         |     |<---------------|Ether |    ...|    |   +-------+    |
         |     |                |MACOut|   +---|    |                |
         |     |                |      |   |   +----+                |
         +-----+                +------+   | BasicMetadataDispatch   |
                                           +-------------------------+

                      Figure 1.  (TBD) 1  IPv4 Forwarding case

   Figure 2 shows the typical LFB processing path for the IPv6 unicast
   forwarding case. case with media ports not considered.

   Figure 2.  (TBD)

8.2.

7.2.  Address Resolution

   TBD

8.3.

7.3.  ICMP

   TBD

8.4.

7.4.  Running Routing Protocol

   TBD

8.5.

7.5.  Network Management

   TBD

9.

8.  Contributors

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

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

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

10.

9.  Acknowledgements

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

11.

10.  IANA Considerations

   (TBD)

12.

11.  Security Considerations

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

13. ForCES protocol [RFC5810].

12.  References

13.1.

12.1.  Normative References

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

   [I-D.ietf-forces-protocol]
              Dong, L.,

   [RFC5810]  Doria, A., Gopal, R., HAAS, R., Hadi Salim, J., Haas, R., Khosravi, H., and W. Wang, "ForCES
              W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and
              Control Element Separation (ForCES) Protocol
              Specification", draft-ietf-forces-protocol-22 (work in
              progress), RFC 5810, March 2010.

   [RFC5812]  Halpern, J. and J. Hadi Salim, "Forwarding and Control
              Element Separation (ForCES) Forwarding Element Model",
              RFC 5812, March 2009.

13.2. 2010.

12.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 wmwang@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 joel.halpern@ericsson.com