Internet Engineering Task Force                                  W. Wang
Internet-Draft                             Zhejiang Gongshang University
Intended status: Standards Track                           E. Haleplidis
Expires: December 4, 2011 January 11, 2012                           University of Patras
                                                                K. Ogawa
                                                         NTT Corporation
                                                                   C. Li
                                                  Hangzhou BAUD Networks
                                                              J. Halpern
                                                                Ericsson
                                                            June 2,
                                                           July 10, 2011

              ForCES Logical Function Block (LFB) Library
                      draft-ietf-forces-lfb-lib-04
                      draft-ietf-forces-lfb-lib-05

Abstract

   This document defines basic classes of Logical Function Blocks (LFBs)
   used in the Forwarding and Control Element Separation (ForCES).  It
   is  The
   basic LFB classes are defined according to ForCES FE model [RFC5812]
   and ForCES protocol [RFC5810] specifications.  These basic LFB classes specifications, and are scoped to meet
   requirements of typical router functions and considered as the basic
   LFB library for ForCES.  Descriptions  The library includes the descriptions of individual the
   LFBs are
   presented and detailed XML definitions are included in the library.
   Several use cases of the defined LFB classes are also proposed. XML definitions.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   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."

   This Internet-Draft will expire on December 4, 2011. January 11, 2012.

Copyright Notice

   Copyright (c) 2011 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
     3.1.  Scope of the Library . . . . . . . . . . . . . . . . . . .  7
     3.2.  Overview of LFB Classes in the Library . . . . . . . . . .  9
       3.2.1.  LFB Design Choices . . . . . . . . . . . . . . . . . .  9
       3.2.2.  LFB Class Groupings  . . . . . . . . . . . . . . . . .  9
       3.2.3.  Sample LFB Class Application . . . . . . . . . . . . . 11
     3.3.  Document Structure . . . . . . . . . . . . . . . . . . . . 12
   4.  Base Types . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     4.1.  Data . . . Types . . . . . . . . . . . . . . . . . . . . . . . . 14
     4.2.  Frame
       4.1.1.  Atomic . . . . . . . . . . . . . . . . . . . . . . . . 14
       4.1.2.  Compound struct  . . 14
     4.3.  MetaData . . . . . . . . . . . . . . . . . 15
       4.1.3.  Compound array . . . . . . . . 15
     4.4.  XML for Base Type Library . . . . . . . . . . . . 15
     4.2.  Frame Types  . . . . 15
   5.  LFB Class Description . . . . . . . . . . . . . . . . . . . 16
     4.3.  MetaData Types . 36
     5.1.  Ethernet Processing LFBs . . . . . . . . . . . . . . . . . 36
       5.1.1.  EtherPHYCop . . . . 16
     4.4.  XML for Base Type Library  . . . . . . . . . . . . . . . . 17
   5.  LFB Class Description  . 36
         5.1.1.1.  Data Handling . . . . . . . . . . . . . . . . . . 36
         5.1.1.2.  Components . 38
     5.1.  Ethernet Processing LFBs . . . . . . . . . . . . . . . . . 38
       5.1.1.  EtherPHYCop  . . 37
         5.1.1.3.  Capabilities . . . . . . . . . . . . . . . . . . . 38
         5.1.1.4.  Events
       5.1.2.  EtherMACIn . . . . . . . . . . . . . . . . . . . . . . 38
       5.1.2.  EtherMACIn 40
       5.1.3.  EtherClassifier  . . . . . . . . . . . . . . . . . . . 42
       5.1.4.  EtherEncap . . . 38
         5.1.2.1.  Data Handling . . . . . . . . . . . . . . . . . . 38
         5.1.2.2.  Components . 44
       5.1.5.  EtherMACOut  . . . . . . . . . . . . . . . . . . . 39
         5.1.2.3.  Capabilities . . 46
     5.2.  IP Packet Validation LFBs  . . . . . . . . . . . . . . . . 47
       5.2.1.  IPv4Validator  . 40
         5.1.2.4.  Events . . . . . . . . . . . . . . . . . . . 47
       5.2.2.  IPv6Validator  . . . 40
       5.1.3.  EtherClassifier . . . . . . . . . . . . . . . . . 49
     5.3.  IP Forwarding LFBs . . 40
       5.1.4.  EtherEncapsulator . . . . . . . . . . . . . . . . . . 42
       5.1.5.  EtherMACOut 51
       5.3.1.  IPv4UcastLPM . . . . . . . . . . . . . . . . . . . . . 45
         5.1.5.1.  Data Handling 51
       5.3.2.  IPv4NextHop  . . . . . . . . . . . . . . . . . . 45
         5.1.5.2.  Components . . . 53
       5.3.3.  IPv6UcastLPM . . . . . . . . . . . . . . . . . 45
         5.1.5.3.  Capabilities . . . . 55
       5.3.4.  IPv6NextHop  . . . . . . . . . . . . . . . 46
         5.1.5.4.  Events . . . . . . 57
     5.4.  Redirect LFBs  . . . . . . . . . . . . . . . . 46
     5.2.  IP Packet Validation LFBs . . . . . . 58
       5.4.1.  RedirectIn . . . . . . . . . . 46
       5.2.1.  IPv4Validator . . . . . . . . . . . . 59
       5.4.2.  RedirectOut  . . . . . . . . 46
         5.2.1.1.  Data Handling . . . . . . . . . . . . . 59
     5.5.  General Purpose LFBs . . . . . 46
         5.2.1.2.  Components . . . . . . . . . . . . . . 60
       5.5.1.  BasicMetadataDispatch  . . . . . . 48
         5.2.1.3.  Capabilities . . . . . . . . . . 60
       5.5.2.  GenericScheduler . . . . . . . . . 48
         5.2.1.4.  Events . . . . . . . . . . 61
   6.  XML for LFB Library  . . . . . . . . . . . . 48
       5.2.2.  IPv6Validator . . . . . . . . . 64
   7.  LFB Class Use Cases  . . . . . . . . . . . 48
         5.2.2.1.  Data Handling . . . . . . . . . . 86
     7.1.  IPv4 Forwarding  . . . . . . . . 48
         5.2.2.2.  Components . . . . . . . . . . . . . 86
     7.2.  ARP processing . . . . . . . 50
         5.2.2.3.  Capabilities . . . . . . . . . . . . . . . 87
   8.  Contributors . . . . 50
         5.2.2.4.  Events . . . . . . . . . . . . . . . . . . . . . 90
   9.  Acknowledgements . 50
     5.3.  IP Forwarding LFBs . . . . . . . . . . . . . . . . . . . . 50
       5.3.1.  IPv4UcastLPM . . 91
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . 51
       5.3.2.  IPv4NextHop . . 92
     10.1. LFB Class Names and LFB Class Identifiers  . . . . . . . . 92
     10.2. Metadata ID  . . . . . . . . . . . 52
       5.3.3.  IPv6UcastLPM . . . . . . . . . . . . 94
     10.3. Exception ID . . . . . . . . . 54
       5.3.4.  IPv6NextHop . . . . . . . . . . . . . . 94
     10.4. Validate Error ID  . . . . . . . 54
     5.4.  Redirect LFBs . . . . . . . . . . . . . 95
   11. Security Considerations  . . . . . . . . . 54
       5.4.1.  RedirectIn . . . . . . . . . . 97
   12. References . . . . . . . . . . . . 54
       5.4.2.  RedirectOut . . . . . . . . . . . . . . 98
     12.1. Normative References . . . . . . . 55
     5.5.  General Purpose LFBs . . . . . . . . . . . . 98
     12.2. Informative References . . . . . . . 55
       5.5.1.  BasicMetadataDispatch . . . . . . . . . . . 98
   Authors' Addresses . . . . . 56
       5.5.2.  GenericScheduler . . . . . . . . . . . . . . . . . . . 56
   6.  XML 99

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 for LFB Library  . . . . . . . . . . . . . . . . . . . . . 58
   7.  LFB Class Use Cases  . . . . . . . . . . . . . . . . . . . . . 80
     7.1.  IP 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  . . . . . . . . . . . . . . . . . . . . . . 80
   8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 81
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 82
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 83
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 84
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 85
     12.2. Informative References . . . . . . . . . . . . . . . . . . 85
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 86

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

      Control Element (CE) (FE) - A logical entity that implements the
      ForCES
      protocol and uses it protocol.  FEs use the underlying hardware to instruct provide per-
      packet processing and handling as directed/controlled by 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 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) framework.  In the framework, Control Elements
   (CEs) configure and manage one or more separate Forwarding Elements
   (FEs) within a Network Element (NE) by use of a ForCES protocol.  RFC
   5810 [RFC5810] specifies the ForCES protocol.  RFC 5812 [RFC5812]
   specifies the Forwarding Element (FE) model.  In the model, resources
   in FEs are described by classes of Logical Function Blocks (LFBs).
   The FE model defines the structure and abstract semantics of LFBs,
   and provides XML schema for the definitions of LFBs.

   This document conforms to the specifications of the FE model
   [RFC5812] and specifies detailed definitions of classes of LFBs,
   including detailed XML definitions of LFBs.  These LFBs form a base
   LFB library for ForCES.  LFBs in the base library are expected to be
   combined to form an LFB topology for a typical router to implement IP
   forwarding.  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.  Vendors may also develop proprietary LFB
   classes as described in the FE model [RFC5812].

3.1.  Scope of the Library

   It is intended 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 is expected to provide functions to:

   (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),

   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,

   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

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

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

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

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

   (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.  For all
   routers, it is essential to provide ability to manage static routing
   items.

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

   The classical IP router utilizing the ForCES framework constitutes a
   CE running some controlling IGP and/or EGP function and FEs
   implementing using Logical Function Blocks (LFBs) conforming to the
   FE model[RFC5812] specifications.  The CE, in conformance to the
   ForCES protocol[RFC5810] and the FE model [RFC5812] specifications,
   instructs the LFBs on the FE how to treat received/sent packets.

   Packets in an IP router are received and transmitted on physical
   media typically referred to as "ports".  Different physical port
   media will have different way for encapsulating outgoing frames and
   decapsulating incoming frames.  The different physical media will
   also have different attributes that influence its behavior and how
   frames get encapsulated or decapsulated.  This document will only
   deal with Ethernet physical media.  Other future documents may deal
   with other types of media.  This document will also interchangeably
   refer to a port to be an abstraction that constitutes a PHY and a MAC
   as described by the LFBs like EtherPHYCop, EtherMACIn, and
   EtherMACOut.

   IP packets emanating from port LFBs are then processed by a
   validation LFB before being further forwarded to the next LFB.  After
   the validation process the packet is passed to an LFB where IP
   forwarding decision is made.  In the IP 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 LFB uses the next hop index metadata to apply the proper
   headers to the IP packets, and direct them to the proper egress.
   Note that in the process of IP packets processing, in this document,
   we are adhering to the weak-host model[RFC1122] since that is the
   most usable model for a packet processing Network Element.

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.

3.2.1.  LFB Design Choices

   A few design principles were factored into choosing how the base LFBs
   looked like.  These are:

   o  if a function can be designed by either one LFB or two or more
      LFBs with the same cost, the choice is to go with two or more LFBs
      so as to provide more flexibility for implementers.

   o  when flexibility is not required, an LFB should take advantage of
      its independence as much as possible and have minimal coupling
      with other LFBs.  The coupling may be from LFB attributes
      definitions as well as physical implementations.

   o  unless there is a clear difference in functionality, similar
      packet processing should not be represented as two or more
      different LFBs.  Or else, it may add extra burden on
      implementation to achieve interoperability.

3.2.2.  LFB Class Groupings

   The document defines groups of LFBs for typical router function
   requirements:

   (1) A group of Ethernet processing LFBs are defined to abstract the
   packet processing for Ethernet as the port media type.  As the most
   popular media type with rich processing features, Ethernet media
   processing LFBs was a natural choice.  Definitions for processing of
   other port media types like POS or ATM may be incorporated in the
   library in future version of the document or in a future separate
   document.

   The following LFBs are defined for Ethernet processing:

      EtherPHYCop (section 5.1.1)

      EtherMACIn (section 5.1.2)

      EtherClassifier (section 5.1.3)

      EtherEncapsulator (section 5.1.4)

      EtherMACOut (section 5.1.5)

   (2) A group of LFBs are defined for IP packet validation process.

   The following LFBs are defined for IP Validation processing:

      IPv4Validator (section 5.2.1)

      IPv6Validator (section 5.2.2)

   (3) A group of LFBs are defined to abstract IP forwarding process.

   The following LFBs are defined for IP Forwarding processing:

      IPv4UcastLPM (section 5.3.1)

      IPv4NextHop (section 5.3.2)

      IPv6UcastLPM (section 5.3.4)

      IPv6NextHop (section 5.3.4)

   (4) A group of LFBs are defined to abstract the process for redirect
   operation, i.e., data packet transmission between CE and FEs.

   The following LFBs are defined for redirect processing:

      RedirectIn (section 5.5.1) 5.4.1)

      RedirectOut (section 5.5.2) 5.4.2)

   (5) A group of LFBs are defined for abstracting some general purpose
   packet processing.  These processing processes are usually general to
   many processing locations in an FE LFB topology.

   The following LFBs are defined for redirect processing:

      BasicMetadataDispatch (section 5.6.1) 5.5.1)

      GenericScheduler (section 5.6.2) 5.5.2)

3.2.3.  Sample LFB Class Application

   Although section 7 will present use cases for LFBs defined in this
   document, this section shows a sample LFB class application in
   advance so that readers can get a quick overlook of the LFB classes
   with the usage.

   Figure 1 shows the typical LFB processing path for an IPv4 unicast
   forwarding case with Ethernet media interfaces.  To focus on the IP
   forwarding function, some inputs or outputs of LFBs in the figure
   that are not related to the function are missed. ignored.  Section 7.1 will
   describe the LFB topology figure in more details.

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

                Figure 1: AIPv4 Forwarding Case  LFB use case for IPv4 forwarding

3.3.  Document Structure

   Base type definitions, including data types, packet frame types, and
   etadata types are presented in advance for definitions of various LFB
   classes.  Section 4 (Base Types Section) provide a description on the
   base types used by this LFB library.  In order for an extensive use
   of these base types for other LFB class definitions, the base type
   definitions are provided by an xml file in a way as a library which
   is separate from the LFB definition library.

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

   LFB classes are finally defined by XML with specifications and schema
   defined in the ForCES FE model[RFC5812].  Section 6 (XML LFB
   Definitions Section) provide the complete XML definitions of the base
   LFB classes library..

   Section 7 provides several use cases on how some typical router
   functions can be implemented using the base LFB library defined in
   this document.

4.  Base Types

   TThe FE model [RFC5812] has specified the following data types as predefined (built-in) atomic data-types:
   data-types as below:

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

   Based on these the 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 set of
   base data types, frame types, and metadata types MUST should be defined.
   This section provides a brief description of these the base types and detailed a
   full XML
   definitions for the base types.

   In order for extensive use definition of the base type definitions for LFB
   definitions other than this base LFB library, the them as well.

   The base type XML definitions are provided with a separate xml XML
   library file labeled
   with named "BaseTypeLibrary".  Users can refer to this
   library by the statement:

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

4.1.  Data Types

   Data types defined in the base type library are categorized by types
   of atomic, compound struct, and compound array.

4.1.1.  Atomic

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

   (TBD)

4.2.  Frame

   According to FE model [RFC5812], frame types are used in LFB
   definitions to define the

      Data Type Name      Brief Description
      --------------      -----------------
      IPv4Addr            IPv4 address
      IPv6Addr            IPv6 address
      IEEEMAC             IEEE mac address.
      LANSpeedType        Network speed values
      DuplexType          Duplex types of frames the LFB expects at its
   input port(s) and emits at its output port(s).
      PortStatusValues    The <frameDef>
   element in the FE model is possible values of port status, used to define a new frame for
                          both administrative and operative status.
      SchdDisciplineType  Scheduling discipline type.

4.1.2.  Compound struct

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

   (TBD)

4.3.  MetaData

   LFB Metadata is used to communicate per-packet state from one

   Data Type Name           Brief Description
   --------------           -----------------
   EtherDispatchEntryType   Entry type for Ethernet dispatch table.
   VlanInputTableEntryType  Entry type for VLAN input table.
   EncapTableEntryType      Entry type for Ethernet encapsulation table.
   MACInStatsType           Statistics type for EtherMACIn LFB.
   MACOutStatsType          Statistics type for EtherMACOut LFB.
   EtherClassifyStatsType   Entry type for statistics table in
                            EtherClassifier LFB.
   IPv4PrefixInfoType       Entry type for IPv4 prefix table.
   IPv6PrefixInfoType       Entry type for IPv6 prefix table
   IPv4NextHopInfoType      Entry type for IPv4 next hop table.
   IPv6NextHopInfoType      Entry type for IPv6 next hop table.
   IPv4ValidatorStatsType   Statistics type in IPv4validator LFB.
   IPv6ValidatorStatsType   Statistics type in IPv6validator LFB.
   IPv4UcastLPMStatsType    Statistics type in IPv4Unicast LFB.
   IPv6UcastLPMStatsType    Statistics type in IPv6Unicast LFB.
   QueueDepthType           Entry type for queue depth table.
   MetadataDispatchType     Entry type for metadata dispatch table.

4.1.3.  Compound array

   Compound array types are mostly created based on compound struct
   types for LFB table components.  The following compound array types
   are defined in this base type library:

    Data Type Name               Brief Description
    --------------               -----------------
    EtherClassifyStatsTableType  Type for Ethernet classifier statistics
                                  information table
    EtherDispatchTableType       Type for Ethernet dispatch table.
    VlanInputTableType           Type for VLAN input table.
    EncapTableType               Type for Ethernet encapsulation table.
    IPv4PrefixTableType          Type for IPv4 prefix table.
    IPv6PrefixTableType          Type for IPv6 prefix table.
    IPv4NextHopTableType         Type for IPv4 next hop table.
    IPv6NextHopTableType         Type for IPv6 next hop table.
    MetadataDispatchTableType    Type for Metadata dispatch table.
    QueueDepthTableType          Type for Queue depth table.

4.2.  Frame Types

   According to FE model [RFC5812], frame types are used in LFB
   definitions to
   another. define the types of frames the LFB expects at its
   input port and emits at its output port.  The <metadataDef> <frameDef> element in
   the FE model is used to define a new metadata frame type.

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

   (TBD)

4.4.  XML for Base Type Library

 <?xml version="1.0" encoding="UTF-8"?>
 <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>EthernetAll</name>
          <synopsis>An kinds of Ethernet frame</synopsis>
       </frameDef>
       <frameDef>
          <name>EthernetII</name>
          <synopsis>An library:

      Frame Name           Brief Description
      --------------        ----------------
      EthernetII           An Ethernet II frame</synopsis>
       </frameDef>
       <frameDef>
          <name>ARP</name>
          <synopsis>an arp packet</synopsis>
       </frameDef>
       <frameDef>
          <name>IPv4</name>
          <synopsis>An frame
      ARP                  An ARP packet
      IPv4 packet</synopsis>
       </frameDef>
       <frameDef>
          <name>IPv6</name>
          <synopsis>An                 An IPv4 packet
      IPv6 packet</synopsis>
       </frameDef>
       <frameDef>
          <name>IPv4Unicast</name>
          <synopsis>An                 An IPv6 packet
      IPv4Unicast          An IPv4 unicast packet</synopsis>
       </frameDef>
       <frameDef>
          <name>IPv4Multicast</name>
          <synopsis>An packet
      IPv4Multicast        An IPv4 multicast packet</synopsis>
       </frameDef>
       <frameDef>
          <name>IPv6Unicast</name>
          <synopsis>An packet
      IPv6Unicast          An IPv6 unicast packet</synopsis>
       </frameDef>
       <frameDef>
          <name>IPv6Multicast</name>
          <synopsis>An packet
      IPv6Multicast        An IPv6 multicast packet</synopsis>
       </frameDef>
       <frameDef>
          <name>Arbitrary</name>
          <synopsis>Any kinds of frames</synopsis>
       </frameDef>
    </frameDefs>
    <dataTypeDefs>
       <dataTypeDef>
          <name>IPv4Addr</name>
          <synopsis>IPv4 address</synopsis>
          <typeRef>byte[4]</typeRef>
       </dataTypeDef>
       <dataTypeDef>
          <name>IPv6Addr</name>
          <synopsis>IPv6 address</synopsis>
          <typeRef>byte[16]</typeRef>
       </dataTypeDef>
       <dataTypeDef>
          <name>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>
         </atomic>
       </dataTypeDef>
       <dataTypeDef>
         <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 packet
      Arbitrary            Any types of status. Used for both
               administrative and operation status.</synopsis>
         <atomic>
          <baseType>uchar</baseType>
          <specialValues>
            <specialValue value="0">
             <name>Disabled </name>
             <synopsis>the port packet frames

4.3.  MetaData Types

   LFB Metadata is operatively disabled.</synopsis>
            </specialValue>
            <specialValue value="1">
             <name>UP</name>
             <synopsis>the port used to communicate per-packet state from one LFB to
   another.  The <metadataDef> element in the FE model is up.</synopsis>

            </specialValue>
            <specialValue value="2">
             <name>Down</name>
             <synopsis>The used to define
   a new metadata type.

   The following metadata types are currently defined in the base type
   library.

  Metadata Name  Metadata ID  Brief Description
  ------------   ----------   -------------
  PHYPortID           1      The physical port ID that the packet is down.</synopsis>
            </specialValue>
          </specialValues>
         </atomic>
       </dataTypeDef>
       <dataTypeDef>
          <name>MACInStatsType</name>
          <synopsis>The content
                             inputted.
  SrcMAC              2      Source MAC address of statistic the packet.
  DstMAC              3      Destination MAC address of the packet.
  LogicalPortID       4      ID of a logical port for EtherMACIn.</synopsis>
          <struct>
             <component componentID="1">
                <name>NumPacketsReceived</name>
                <synopsis>The number the packet.
  EtherType           5      Indicating the Ethernet type of packets received.</synopsis>
                <typeRef>uint64</typeRef>
             </component>
             <component componentID="2">
                <name>NumPacketsDropped</name>
                <synopsis>The number the
                             Ethernet packet.
  VlanID              6      The VLAN ID of packets dropped.</synopsis>
                <typeRef>uint64</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
          <name>MACOutStatsType</name>
          <synopsis>The content the Ethernet packet.
  VlanPriority        7      The priority of statistic the Ethernet packet.
  NexthopIPv4Addr     8      Nexthop IPv4 address the packet is sent to.
  NexthopIPv6Addr     9      Nexthop IPv6 address the packet is sent to.
  HopSelector         10     An index the packet can use to look up a
                             nexthop table for EtherMACOut.</synopsis>
          <struct>
             <component componentID="1">
                <name>NumPacketsTransmitted</name>
                <synopsis>The number next hop information of packets transmitted.</synopsis>
                <typeRef>uint64</typeRef>
             </component>
             <component componentID="2">
                <name>NumPacketsDropped</name>
                <synopsis>The number
                             the packet.
  ExceptionID         11     Indicating exception type of packets dropped.</synopsis>
                <typeRef>uint64</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
          <name>EtherDispatchEntryType</name>
          <synopsis>the the packet
                             which is exceptional for some processing.
  ValidateErrorID     12     Indicating error type of EtherDispatch table entry.</synopsis>
          <struct>
             <component componentID="1">
                <name>LogicalPortID</name>
                <synopsis>Logical the packet failed
                             some validation process.
  L3PortID            13     ID of L3 port.
  RedirectIndex       14     A metadata CE sends to RedirectIn LFB for
                             the associated packet to select output
                             port ID.</synopsis>
                <typeRef>uint32</typeRef>

             </component>
             <component componentID="2">
                <name>EtherType</name>
                <synopsis>The EtherType value in the Ether head.
                </synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="3">
                <name>OutputIndex</name>
                <synopsis>Group LFB group output port index.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
          <name>EtherDispatchTableType</name>
          <synopsis>the type of EtherDispatch table.</synopsis>
          <array type="variable-size">
            <typeRef>EtherDispatchEntryType</typeRef>
          </array>
       </dataTypeDef>
       <dataTypeDef>
          <name>VlanInputTableEntryType</name>
          <synopsis>Vlan input "PktsOut".
  MediaEncapInfoIndex 15     An index the packet uses to look up a media
                              encapsulation table entry type.</synopsis>
          <struct>
             <component componentID="1">
                <name>IncomingPortID</name>
                <synopsis>The incoming port ID.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="2">
                <name>VlanID</name>
                <synopsis>Vlan ID.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="3">
                <name>LogicalPortID</name>
                <synopsis>logical port ID.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
          </struct>
       </dataTypeDef> to select its
                              encapsulation media as well as followed
                              encapsulation LFB.

4.4.  XML for Base Type Library

 <?xml version="1.0" encoding="UTF-8"?>
 <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>EthernetAll</name>
          <synopsis>All kinds of Ethernet frame</synopsis>
       </frameDef>
       <frameDef>
          <name>EthernetII</name>
          <synopsis>An Ethernet II frame</synopsis>
       </frameDef>
       <frameDef>
          <name>ARP</name>
          <synopsis>An arp packet</synopsis>

       </frameDef>
       <frameDef>
          <name>IPv4</name>
          <synopsis>An IPv4 packet</synopsis>
       </frameDef>
       <frameDef>
          <name>IPv6</name>
          <synopsis>An IPv6 packet</synopsis>
       </frameDef>
       <frameDef>
          <name>IPv4Unicast</name>
          <synopsis>An IPv4 unicast packet</synopsis>
       </frameDef>
       <frameDef>
          <name>IPv4Multicast</name>
          <synopsis>An IPv4 multicast packet</synopsis>
       </frameDef>
       <frameDef>
          <name>IPv6Unicast</name>
          <synopsis>An IPv6 unicast packet</synopsis>
       </frameDef>
       <frameDef>
          <name>IPv6Multicast</name>
          <synopsis>An IPv6 multicast packet</synopsis>
       </frameDef>
       <frameDef>
          <name>Arbitrary</name>
          <synopsis>Any types of packet frames</synopsis>
       </frameDef>
    </frameDefs>
    <dataTypeDefs>
       <dataTypeDef>
          <name>VlanInputTableType</name>
          <synopsis>Vlan input table type.</synopsis>
          <array type="variable-size">
            <typeRef>VlanInputTableEntryType</typeRef>
          </array>
          <name>IPv4Addr</name>
          <synopsis>IPv4 address</synopsis>
          <typeRef>byte[4]</typeRef>
       </dataTypeDef>
       <dataTypeDef>
          <name>EtherClassifyStatsType</name>
          <synopsis>Ether classify statistic information.</synopsis>
          <struct>
             <component componentID="1">
                <name>EtherType</name>
                <synopsis>The EtherType value</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="2">
                <name>PacketsNum</name>
                <synopsis>Packets number</synopsis>
                <typeRef>uint64</typeRef>
             </component>
          </struct>
          <name>IPv6Addr</name>
          <synopsis>IPv6 address</synopsis>
          <typeRef>byte[16]</typeRef>
       </dataTypeDef>
       <dataTypeDef>
          <name>EtherClassifyStatsTableType</name>
          <synopsis>Ether classify statistic information
           table type.</synopsis>
          <array type="variable-size">
            <typeRef>EtherClassifyStatsType</typeRef>
          </array>
          <name>IEEEMAC</name>
          <synopsis>IEEE mac address.</synopsis>
          <typeRef>byte[6]</typeRef>
       </dataTypeDef>
       <dataTypeDef>
          <name>IPv4ValidatorStatisticsType</name>
          <synopsis>Statistics type in IPv4validator.</synopsis>
          <struct>
             <component componentID="1">
                <name>badHeaderPkts</name>
                <synopsis>Number of bad header packets.</synopsis>
                <typeRef>uint64</typeRef>
             </component>
             <component componentID="2">
                <name>badTotalLengthPkts</name>
                <synopsis>Number of bad total length packets.</synopsis>
                <typeRef>uint64</typeRef>
             </component>
             <component componentID="3">
                <name>badTTLPkts</name>
                <synopsis>Number of bad TTL packets.</synopsis>
                <typeRef>uint64</typeRef>
             </component>
             <component componentID="4">
                <name>badChecksumPkts</name>
                <synopsis>Number of bad checksum packets.</synopsis>
                <typeRef>uint64</typeRef>

             </component>
          </struct>
         <name>LANSpeedType</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>
         </atomic>
       </dataTypeDef>
       <dataTypeDef>
          <name>IPv6ValidatorStatisticsType</name>
          <synopsis>Statistics type in IPv6validator.</synopsis>
          <struct>
             <component componentID="1">
                <name>badHeaderPkts</name>
                <synopsis>Number of bad header packets.</synopsis>
                <typeRef>uint64</typeRef>
             </component>
             <component componentID="2">
                <name>badTotalLengthPkts</name>
                <synopsis>Number of bad total length packets.</synopsis>
                <typeRef>uint64</typeRef>
             </component>
             <component componentID="3">
                <name>badHopLimitPkts</name>
                <synopsis>Number of bad Hop limit packets.</synopsis>
                <typeRef>uint64</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
          <name>IPv4PrefixInfoType</name>
          <synopsis>IPv4 Prefix information,entry type for
           IPv4 prefix table.</synopsis>
          <struct>
             <component componentID="1">
                <name>IPv4Address</name>
                <synopsis>An IPv4 Address</synopsis>
                <typeRef>IPv4Addr</typeRef>
             </component>
             <component componentID="2">
                <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>HopSelector</name>
                <synopsis>HopSelector is the nexthop 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>
         <name>DuplexType</name>
         <synopsis>Duplex types</synopsis>
         <atomic>
                   <baseType>boolean</baseType>
          <baseType>uint32</baseType>
          <specialValues>
            <specialValue value="false">
                         <name>False</name>
                         <synopsis>This route does not have multiple
                         nexthops.</synopsis> value="0x00000001">
             <name>Auto</name>
             <synopsis>Auto negotitation.</synopsis>
            </specialValue>
            <specialValue value="true">
                         <name>True</name>
                         <synopsis>This route has multiple nexthops.
                         </synopsis> 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>
             </component>
             <component componentID="5">
                <name>DefaultRouteFlag</name>
                <synopsis>A Default Route Flag
         <!-- XXX: This is very IEEE specific -->

       </dataTypeDef>
       <dataTypeDef>
         <name>PortStatusValues</name>
         <synopsis>The possible values of port status, used for supporting loose RPF.
                </synopsis> both
               administrative and operative status.</synopsis>
         <atomic>
                   <baseType>boolean</baseType>
          <baseType>uchar</baseType>
          <specialValues>
            <specialValue value="false">
                         <name>False</name>
                         <synopsis>This value="0">
             <name>Disabled </name>
             <synopsis>the port is not a default route.
                         </synopsis> operatively disabled.</synopsis>
            </specialValue>
            <specialValue value="true">
                         <name>True</name>
                         <synopsis>This route value="1">
             <name>UP</name>
             <synopsis>the port is a default route. for
                         supporting the loose RPF.</synopsis> up.</synopsis>
            </specialValue>
            <specialValue value="2">
             <name>Down</name>
             <synopsis>The port is down.</synopsis>
            </specialValue>
          </specialValues>
         </atomic>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
          <name>IPv4PrefixTableType</name>
          <synopsis>IPv4 prefix table type.</synopsis>
          <array type="variable-size">
            <typeRef>IPv4PrefixInfoType</typeRef>

          </array>
       </dataTypeDef>
       <dataTypeDef>
          <name>IPv4UcastLPMStatsType</name>
          <name>MACInStatsType</name>
          <synopsis>Statistics type in IPv4Unicast.</synopsis> EtherMACIn.</synopsis>
          <struct>
             <component componentID="1">
                <name>InRcvdPkts</name>
                <name>NumPacketsReceived</name>
                <synopsis>The total number of input packets
                received</synopsis> received.</synopsis>
                <typeRef>uint64</typeRef>
             </component>
             <component componentID="2">
                <name>FwdPkts</name>
                <synopsis>IPv4 packets forwarded by this LFB</synopsis>
                <typeRef>uint64</typeRef>
             </component>
             <component componentID="3">
                <name>NoRoutePkts</name>
                <name>NumPacketsDropped</name>
                <synopsis>The number of IP datagrams discarded because
                no route could be found.</synopsis> packets dropped.</synopsis>
                <typeRef>uint64</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
          <name>IPv6PrefixInfoType</name>
          <synopsis>IPv6 Prefix information,entry
          <name>MACOutStatsType</name>
          <synopsis>Statistics type for
           IPv6 prefix table</synopsis> in EtherMACOut.</synopsis>
          <struct>
             <component componentID="1">
                <name>IPv6Address</name>
                <synopsis>An IPv6 Address</synopsis>
                <typeRef>IPv6Addr</typeRef>
             </component>
             <component componentID="2">
                <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 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>IPv6PrefixTableType</name>
          <synopsis>IPv6 prefix table type.</synopsis>
          <array type="variable-size">
            <typeRef>IPv6PrefixInfoType</typeRef>

          </array>
       </dataTypeDef>
       <dataTypeDef>
          <name>IPv6UcastLPMStatsType</name>
          <synopsis>Statistics type in IPv6Unicast.</synopsis>
          <struct>
             <component componentID="1">
                <name>InRcvdPkts</name>
                <name>NumPacketsTransmitted</name>
                <synopsis>The total number of input packets
                received</synopsis> transmitted.</synopsis>
                <typeRef>uint64</typeRef>
             </component>
             <component componentID="2">
                <name>FwdPkts</name>
                <synopsis>IPv6 packets forwarded by this LFB</synopsis>
                <typeRef>uint64</typeRef>
             </component>
             <component componentID="3">
                <name>NoRoutePkts</name>
                <name>NumPacketsDropped</name>
                <synopsis>The number of IP datagrams discarded because
                no route could be found.</synopsis> packets dropped.</synopsis>
                <typeRef>uint64</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
          <name>IPv4NextHopInfoType</name>
          <synopsis>IPv4 next hop information. Entry
          <name>EtherDispatchEntryType</name>
          <synopsis>Entry type for the
             IPv4 next hop Ethernet dispatch table.</synopsis>
          <struct>
             <component componentID="1">
                <name>L3PortID</name>
                <synopsis>The ID of the Logical/physical Output Port
                that we pass onto the neighboring LFB instance. This
                ID indicates what
                <name>LogicalPortID</name>
                <synopsis>Logical port to the neighbor is as defined
                by L3.</synopsis> ID.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="2">
                <name>MTU</name>
                <synopsis>Maximum Transmission Unit for out going port.
                 It is for desciding whether
                <name>EtherType</name>
                <synopsis>The EtherType value in the packet need
                 fragmentation Ether head.
                </synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="3">
                <name>NextHopIPAddr</name>
                <synopsis>Next Hop IPv4 Address</synopsis>
                <typeRef>IPv4Addr</typeRef>
             </component>
             <component componentID="4">
                <name>MediaEncapInfoIndex</name>
                <synopsis>The index we pass onto the neighboring LFB
                instance. This index is used to lookup a table
                (typically media encapsulatation related) further
                downstream.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="5">
                <name>LFBOutputSelectIndex</name>
                 <synopsis>LFB Group output port index to select
                 downstream LFB port. Some possibilities of downstream
                 LFB instances are:
                    a) EtherEncapsulator IPv4Validator
                    b) Other type of media LFB IPv6Validator
                    c) A metadata Dispatcher RedirectOut
                    d) A redirect LFB
                    e) etc
                 Note: LFBOutputSelectIndex is the FromPortIndex for
                 the port group "successout" "ClassifyOut" in the table LFBTopology
                 (of FEObject LFB) as defined for the NH LFB.
                 </synopsis> EtherClassifier
                 LFB.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
          <name>IPv4NextHopTableType</name>
          <synopsis>IPv4 next hop table type</synopsis>
          <name>EtherDispatchTableType</name>
          <synopsis>Type for Ethernet dispatch table.</synopsis>
          <array type="variable-size">
            <typeRef>IPv4NextHopInfoType</typeRef>
            <typeRef>EtherDispatchEntryType</typeRef>
          </array>
       </dataTypeDef>
       <dataTypeDef>
          <name>IPv6NextHopInfoType</name>
          <synopsis>IPv6 next hop information. Entry
          <name>VlanInputTableEntryType</name>
          <synopsis>Entry type for the
             IPv6NextHopTable.</synopsis> VLAN input table.</synopsis>
          <struct>
             <component componentID="1">
                <name>L3PortID</name>
                <name>IncomingPortID</name>
                <synopsis>The ID of the Logical/physical Output Port
                that we pass onto the neighboring LFB instance. This
                ID indicates what incoming port to the neighbor is as defined
                by L3.</synopsis> ID.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="2">
                <name>MTU</name>
                <synopsis>Maximum Transmission Unit for out going port.
                 It is for desciding whether the packet need
                 fragmentation.</synopsis>
                <name>VlanID</name>
                <synopsis>Vlan ID.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="3">
                <name>NextHopIPAddr</name>
                <synopsis>Next Hop IPv6 Address</synopsis>
                <typeRef>IPv6Addr</typeRef>
             </component>
             <component componentID="4">
                <name>MediaEncapInfoIndex</name>
                <synopsis>The index we pass onto the neighboring LFB
                instance. This index is used to lookup a table
                (typically media encapsulatation related) further
                downstream.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="5">
                <name>LFBOutputSelectIndex</name>
                 <synopsis>LFB Group output port index to select
                 downstream LFB port. Some possibilities of downstream
                 LFB instances are:
                    a) EtherEncapsulator
                    b) Other type of media LFB
                    c) A metadata Dispatcher
                    d) A redirect LFB
                    e) etc
                 Note: LFBOutputSelectIndex is the FromPortIndex for
                 the
                <name>LogicalPortID</name>
                <synopsis>logical port group "successout" in the table LFBTopology
                (of FEObject LFB) as defined for the NH LFB.
                 </synopsis> ID.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
          <name>IPv6NextHopTableType</name>
          <synopsis>IPv6 next hop table type</synopsis>
          <name>VlanInputTableType</name>
          <synopsis>Type for VLAN input table.</synopsis>
          <array type="variable-size">
            <typeRef>IPv6NextHopInfoType</typeRef>
            <typeRef>VlanInputTableEntryType</typeRef>
          </array>
       </dataTypeDef>
       <dataTypeDef>
          <name>EncapTableEntryType</name>
          <synopsis>Ethernet encapsulation
          <name>EtherClassifyStatsType</name>
          <synopsis>Entry type for statistics table entry type.</synopsis> in EtherClassifier
           LFB.</synopsis>
          <struct>
             <component componentID="1">
                <name>DstMac</name>
                <synopsis>Ethernet Mac of the Neighbor</synopsis>
                <typeRef>IEEEMAC</typeRef>
             </component>
             <component componentID="2">
                <name>SrcMac</name>
                <synopsis>Source MAC used in encapsulation</synopsis>
                <typeRef>IEEEMAC</typeRef>
             </component>
             <component componentID="3">
                <name>VlanID</name>
                <synopsis>VLAN ID.</synopsis>
                <name>EtherType</name>
                <synopsis>The EtherType value</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="4">
                <name>L2PortID</name>
                <synopsis>Output logical L2 port ID.</synopsis>
                <typeRef>uint32</typeRef> componentID="2">
                <name>PacketsNum</name>
                <synopsis>Packets number</synopsis>
                <typeRef>uint64</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
          <name>EncapTableType</name>
          <synopsis>Ethernet encapsulation table type</synopsis>
          <name>EtherClassifyStatsTableType</name>
          <synopsis>Type for Ethernet classifier statistics
          information table.</synopsis>
          <array type="variable-size">
            <typeRef>EncapTableEntryType</typeRef>
            <typeRef>EtherClassifyStatsType</typeRef>
          </array>
       </dataTypeDef>
       <dataTypeDef>
          <name>MetadataDispatchType</name>
          <synopsis>The entry
          <name>IPv4ValidatorStatsType</name>
          <synopsis>Statistics type for Metadata dispatch table.
          </synopsis> in IPv4validator.</synopsis>
          <struct>
             <component componentID="1">
                <name>MetadataID</name>
                <synopsis>metadata ID</synopsis>
                <typeRef>uint32</typeRef>
                <name>badHeaderPkts</name>
                <synopsis>Number of bad header packets.</synopsis>
                <typeRef>uint64</typeRef>
             </component>
             <component componentID="2">
                <name>MetadataValue</name>
                <synopsis>metadata value.</synopsis>
                <typeRef>uint32</typeRef>
                <name>badTotalLengthPkts</name>
                <synopsis>Number of bad total length packets.</synopsis>
                <typeRef>uint64</typeRef>
             </component>
             <component componentID="3">
                <name>OutputIndex</name>
                <synopsis>group output port index.</synopsis>
                <typeRef>uint32</typeRef>
                <name>badTTLPkts</name>
                <synopsis>Number of bad TTL packets.</synopsis>
                <typeRef>uint64</typeRef>
             </component>
             <component componentID="4">
                <name>badChecksumPkts</name>
                <synopsis>Number of bad checksum packets.</synopsis>
                <typeRef>uint64</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
          <name>MetadataDispatchTableType</name>
          <synopsis> Metadata dispatch table type.</synopsis>
          <array type="variable-size">
            <typeRef>MetadataDispatchType</typeRef>
          </array>
       </dataTypeDef>
       <dataTypeDef>
          <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 entry
          <name>IPv6ValidatorStatsType</name>
          <synopsis>Statistics type for queue depth
          table.</synopsis> in IPv6validator.</synopsis>
          <struct>
             <component componentID="1">
                <name>QueueID</name>
                <synopsis>Queue ID</synopsis>
                <typeRef>uint32</typeRef>
                <name>badHeaderPkts</name>
                <synopsis>Number of bad header packets.</synopsis>
                <typeRef>uint64</typeRef>
             </component>
             <component componentID="2">
                <name>QueueDepthInPackets</name>
                <synopsis>the Queue Depth when the depth units
                are
                <name>badTotalLengthPkts</name>
                <synopsis>Number of bad total length packets.</synopsis>
                <typeRef>uint32</typeRef>
                <typeRef>uint64</typeRef>
             </component>
             <component componentID="3">
                <name>QueueDepthInBytes</name>
                <synopsis>the Queue Depth when the depth units
                are bytes.</synopsis>
                <typeRef>uint32</typeRef>
                <name>badHopLimitPkts</name>
                <synopsis>Number of bad Hop limit packets.</synopsis>
                <typeRef>uint64</typeRef>
             </component>

          </struct>
       </dataTypeDef>
       <dataTypeDef>
          <name>QueueDepthTableType</name>
          <synopsis>the Depth of Queue table type.</synopsis>
          <array type="variable-size">
            <typeRef>QueueDepthType</typeRef>
          </array>
       </dataTypeDef>
    </dataTypeDefs>
    <metadataDefs>
       <metadataDef>
          <name>PHYPortID</name>
          <name>IPv4PrefixInfoType</name>
          <synopsis>Entry type for IPv4 prefix table.</synopsis>
          <struct>
             <component componentID="1">
                <name>IPv4Address</name>
                <synopsis>An IPv4 Address</synopsis>
                <typeRef>IPv4Addr</typeRef>
             </component>
             <component componentID="2">
                <name>Prefixlen</name>
                <synopsis>The physical port prefix length</synopsis>
                <atomic>
                   <baseType>uchar</baseType>
                   <rangeRestriction>
                      <allowedRange min="0" max="32"/>
                   </rangeRestriction>
                </atomic>
             </component>
             <component componentID="3">
                <name>HopSelector</name>
                <synopsis>HopSelector is the nexthop 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 logical port.</synopsis>
          <metadataID>4</metadataID> which points to
                the nexthop table</synopsis>
                <typeRef>uint32</typeRef>
       </metadataDef>
       <metadataDef>
          <name>EtherType</name>
             </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>IPv4PrefixTableType</name>
          <synopsis>Type for IPv4 prefix table.</synopsis>
          <array type="variable-size">
            <typeRef>IPv4PrefixInfoType</typeRef>
          </array>
       </dataTypeDef>
       <dataTypeDef>
          <name>IPv4UcastLPMStatsType</name>
          <synopsis>Statistics type in IPv4Unicast LFB.</synopsis>
          <struct>
             <component componentID="1">
                <name>InRcvdPkts</name>
                <synopsis>The value total number of 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> input packets received.
                </synopsis>
                <typeRef>uint64</typeRef>
             </component>
             <component componentID="2">
                <name>FwdPkts</name>
                <synopsis>IPv4 packets forwarded by this LFB</synopsis>
                <typeRef>uint64</typeRef>
             </component>
             <component componentID="3">
                <name>NoRoutePkts</name>
                <synopsis>The priority number 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> datagrams discarded because
                no route could be found.</synopsis>
                <typeRef>uint64</typeRef>
             </component>
          </struct>

       </dataTypeDef>
       <dataTypeDef>
          <name>IPv6PrefixInfoType</name>
          <synopsis>Entry type for IPv6 prefix table.</synopsis>
          <struct>
             <component componentID="1">
                <name>IPv6Address</name>
                <synopsis>An IPv6 Address</synopsis>
                <typeRef>IPv6Addr</typeRef>
       </metadataDef>
       <metadataDef>
             </component>
             <component componentID="2">
                <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 ID which points
                to the nexthop table </synopsis>
          <metadataID>10</metadataID> table</synopsis>
                <typeRef>uint32</typeRef>
       </metadataDef>
       <metadataDef>
          <name>ExceptionID</name>
          <synopsis>Exception Types</synopsis>
          <metadataID>11</metadataID>
             </component>
             <component componentID="4">
                <name>ECMPFlag</name>
                <synopsis>An ECMP Flag for this route</synopsis>
                <atomic>
             <baseType>uint32</baseType>
                   <baseType>boolean</baseType>
                   <specialValues>
                      <specialValue value="0">
                   <name>Other</name>
                   <synopsis>Any other exception.</synopsis>
                   </specialValue>
                 <specialValue value="1">
                   <name>BroadCastPacket</name>
                   <synopsis>Packet with destination address equal to
                   255.255.255.255</synopsis> value="false">
                         <name>False</name>
                         <synopsis>This route does not have multiple
                         nexthops.</synopsis>
                      </specialValue>
                      <specialValue value="2">
                   <name>BadTTL</name>
                   <synopsis>The packet can't be forwarded as the TTL value="true">
                         <name>True</name>
                         <synopsis>This route has expired.</synopsis> multiple nexthops.
                         </synopsis>
                      </specialValue>
                 <specialValue value="3">
                   <name>IPv4HeaderLengthMismatch</name>
                   <synopsis>IPv4 Packet's header length
                   </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 less
                   than 5.</synopsis> not a default route.
                         </synopsis>
                      </specialValue>
                      <specialValue value="4">
                    <name>LengthMismatch</name>
                    <synopsis>The packet length reported by link layer value="true">
                         <name>True</name>
                         <synopsis>This route is less than the total length field.</synopsis> a default route.
                         </synopsis>
                      </specialValue>
                 <specialValue value="5">
                    <name>RouterAlertOptions</name>
                    <synopsis>Packet
                   </specialValues>
                </atomic>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
          <name>IPv6PrefixTableType</name>
          <synopsis>Type for IPv6 prefix table.</synopsis>
          <array type="variable-size">
            <typeRef>IPv6PrefixInfoType</typeRef>
          </array>
       </dataTypeDef>
       <dataTypeDef>
          <name>IPv6UcastLPMStatsType</name>
          <synopsis>Statistics type in IPv6Unicast LFB.</synopsis>
          <struct>
             <component componentID="1">
                <name>InRcvdPkts</name>
                <synopsis>The total number of input packets
                received</synopsis>
                <typeRef>uint64</typeRef>
             </component>
             <component componentID="2">
                <name>FwdPkts</name>
                <synopsis>IPv6 packets forwarded by this LFB</synopsis>
                <typeRef>uint64</typeRef>
             </component>
             <component componentID="3">
                <name>NoRoutePkts</name>
                <synopsis>The number of IP head include Router Alert
                    options.</synopsis>
                 </specialValue>
                 <specialValue value="6">
                    <name>RouteInTableNotFound</name>
                    <synopsis>There is datagrams discarded because
                no route in could be found.</synopsis>
                <typeRef>uint64</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
          <name>IPv4NextHopInfoType</name>
          <synopsis>Entry type for IPv4 next hop table.</synopsis>
          <struct>
             <component componentID="1">
                <name>L3PortID</name>
                <synopsis>The ID of the route table
                    corresponding Logical/physical Output Port
                that we pass onto the neighboring LFB instance. This
                ID indicates what port to the packet destination address
                    </synopsis>
                 </specialValue>
                 <specialValue value="7">
                    <name>NextHopInvalid</name>
                    <synopsis>The NexthopID neighbor is invalid</synopsis>
                 </specialValue>
                 <specialValue value="8">
                    <name>FragRequired</name>
                    <synopsis>The MTU as defined
                by L3.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="2">
                <name>MTU</name>
                <synopsis>Maximum Transmission Unit for outgoing interface out going port.
                 It is less
                    than for desciding whether the packet size.</synopsis>
                 </specialValue>
                 <specialValue value="9">
                    <name>LocalDelivery</name> need
                 fragmentation </synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="3">
                <name>NextHopIPAddr</name>
                <synopsis>Next Hop IPv4 Address</synopsis>
                <typeRef>IPv4Addr</typeRef>
             </component>
             <component componentID="4">
                <name>MediaEncapInfoIndex</name>
                <synopsis>The packet index we pass onto the neighboring LFB
                instance. This index is for a local interface.
                    </synopsis>
                 </specialValue>
                 <specialValue value="10">
                    <name>GenerateICMP</name>
                    <synopsis>ICMP packet needs used to be generated.
                    </synopsis>
                 </specialValue>
                 <specialValue value="11">
                    <name>PrefixIndexInvalid</name>
                    <synopsis>The prefixIndex lookup a table
                (typically media encapsulatation related) further
                downstream.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="5">
                <name>LFBOutputSelectIndex</name>
                 <synopsis>LFB Group output port index to select
                 downstream LFB port. Some possibilities of downstream
                 LFB instances are:
                    a) EtherEncap
                    b) Other type of media LFB
                    c) A metadata Dispatcher
                    d) A redirect LFB
                    e) etc
                 Note: LFBOutputSelectIndex is wrong.</synopsis>
                 </specialValue>
                 <specialValue value="12">
                    <name>IPv6HopLimitZero</name>
                    <synopsis>Packet with Hop Limit zero the FromPortIndex for
                 the port group "SuccessOut" in the table LFBTopology
                 (of FEObject LFB) as defined for the IPv4NextHop LFB.
                 </synopsis>
                 </specialValue>
                 <specialValue value="13">
                    <name>IPv6NextHeaderHBH</name>
                    <synopsis>Packet with
                <typeRef>uint32</typeRef>
             </component>

          </struct>
       </dataTypeDef>
       <dataTypeDef>
          <name>IPv4NextHopTableType</name>
          <synopsis>Type for IPv4 next header set hop table.</synopsis>
          <array type="variable-size">
            <typeRef>IPv4NextHopInfoType</typeRef>
          </array>
       </dataTypeDef>
       <dataTypeDef>
          <name>IPv6NextHopInfoType</name>
          <synopsis>Entry type for IPv6 next hop table.</synopsis>
          <struct>
             <component componentID="1">
                <name>L3PortID</name>
                <synopsis>The ID of the Logical/physical Output Port
                that we pass onto the neighboring LFB instance. This
                ID indicates what port to Hop-by-Hop
                    </synopsis>
                 </specialValue>
              </specialValues>
           </atomic>
       </metadataDef>
       <metadataDef>
           <name>ValidateErrorID</name>
           <synopsis>Validate Error Types</synopsis>
           <metadataID>12</metadataID>
           <atomic>
              <baseType>uint32</baseType>
              <specialValues>
                 <specialValue value="0">
                    <name>Other</name>
                    <synopsis>Any other validation error.</synopsis>
                 </specialValue>
                 <specialValue value="1">
                    <name>InvalidIPv4PacketSize</name>
                    <synopsis>Packet size reported the neighbor is less than 20
                    bytes.</synopsis>
                 </specialValue>
                 <specialValue value="2">
                    <name>NotIPv4Packet</name>
                    <synopsis>Packet as defined
                by L3.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="2">
                <name>MTU</name>
                <synopsis>Maximum Transmission Unit for out going port.
                 It is not IP version 4.</synopsis>
                 </specialValue>
                 <specialValue value="3">
                    <name>InvalidIPv4HeaderLengthSize</name>
                    <synopsis>Packet's header length for desciding whether the packet need
                 fragmentation.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="3">
                <name>NextHopIPAddr</name>
                <synopsis>Next Hop IPv6 Address</synopsis>
                <typeRef>IPv6Addr</typeRef>
             </component>
             <component componentID="4">
                <name>MediaEncapInfoIndex</name>
                <synopsis>The index we pass onto the neighboring LFB
                instance. This index is less than 5.
                    </synopsis>
                 </specialValue>
                 <specialValue value="4">
                    <name>InvalidIPv4Checksum</name>
                    <synopsis>Packet with invalid checksum.</synopsis>
                 </specialValue>
                 <specialValue value="5">
                    <name>InvalidIPv4SrcAddr1</name>
                    <synopsis>Packet with source address equal to
                    255.255.255.255.</synopsis>
                 </specialValue>
                 <specialValue value="6">
                    <name>InvalidIPv4SrcAddr2</name>
                    <synopsis>Packet with source address 0.</synopsis>
                 </specialValue>
                 <specialValue value="7">
                    <name>InvalidIPv4SrcAddr3</name>
                    <synopsis>Packet with source address of form
                    127.any.</synopsis>
                 </specialValue>
                 <specialValue value="8">
                    <name>InvalidIPv4SrcAddr4</name>
                    <synopsis>Packet with source address in Class E
                    domain.</synopsis>
                 </specialValue>
                 <specialValue value="9">
                    <name>InvalidIPv6PakcetSize</name>
                    <synopsis>Packet size reported is less than 40
                    bytes.</synopsis>
                 </specialValue>
                 <specialValue value="10">
                    <name>NotIPv6Packet</name>
                    <synopsis>Packet is not IP version 6.</synopsis>
                 </specialValue>
                 <specialValue value="11">
                    <name>InvalidIPv6SrcAddr1</name>
                    <synopsis>Packet with multicast source address (the
                    MSB of the source address is 0xFF).</synopsis>
                 </specialValue>
                 <specialValue value="12">
                    <name>InvalidIPv6SrcAddr2</name>
                    <synopsis>Packet with source address set to
                    loopback(::1).</synopsis>
                 </specialValue>
                 <specialValue value="13">
                    <name>InvalidIPv6DstAddr1</name>
                    <synopsis>Packet with destination set used to 0 or ::1.
                    </synopsis>
                 </specialValue>
              </specialValues>
           </atomic>
       </metadataDef>
       <metadataDef>
          <name>L3PortID</name>
          <synopsis>ID of L3 port.</synopsis>
          <metadataID>13</metadataID> lookup a table
                (typically media encapsulatation related) further
                downstream.</synopsis>
                <typeRef>uint32</typeRef>
       </metadataDef>
       <metadataDef>
          <name>RedirectIndex</name>
          <synopsis>Redirect Output
             </component>
             <component componentID="5">
                <name>LFBOutputSelectIndex</name>
                 <synopsis>LFB Group output port index.</synopsis>
          <metadataID>14</metadataID>
          <typeRef>uint32</typeRef>
       </metadataDef>
       <metadataDef>
          <name>MediaEncapInfoIndex</name>
          <synopsis>The index for media encap table in Media encap LFB.
          </synopsis>
          <metadataID>15</metadataID>
          <typeRef>uint32</typeRef>
       </metadataDef>
    </metadataDefs>
 </LFBLibrary>

5.  LFB Class Description

   According to ForCES specifications, select
                 downstream LFB (Logical Function Block) is a
   well defined, logically separable functional block that resides in an
   FE, and is a functionally accurate abstraction port. Some possibilities of the FE's processing
   capabilities.  An downstream
                 LFB Class (or type) is a template that represents a
   fine-grained, logically separable aspect instances are:
                    a) EtherEncap
                    b) Other type of FE processing.  Most LFBs
   are related to packet processing in the data path. media LFB classes are
                    c) A metadata Dispatcher
                    d) A redirect LFB
                    e) etc
                 Note: LFBOutputSelectIndex is the basic building blocks of FromPortIndex for
                 the FE model.  Note that RFC 5810 has
   already defined an 'FE Protocol LFB' which is as a logical entity port group "SuccessOut" in
   each FE to control the ForCES protocol.  RFC 5812 has already table LFBTopology
                (of FEObject LFB) as defined
   an 'FE Object LFB'.  Information like the FE Name, FE ID, FE State,
   LFB Topology in for the FE are represented in this IPv6NextHop LFB.

   As specified in Section 3.1, this document focuses the base LFB
   library for implementing typical router functions, especially
                 </synopsis>
                <typeRef>uint32</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
          <name>IPv6NextHopTableType</name>
          <synopsis>Type for IP
   forwarding functions.  As a result, LFB classes in the library are
   all 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 IPv6 next hop table.</synopsis>
          <array type="variable-size">
            <typeRef>IPv6NextHopInfoType</typeRef>
          </array>
       </dataTypeDef>
       <dataTypeDef>
          <name>EncapTableEntryType</name>
          <synopsis>Entry type 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 encapsulation table.
          </synopsis>
          <struct>
             <component componentID="1">
                <name>DstMac</name>
                <synopsis>Ethernet Mac 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 Neighbor</synopsis>
                <typeRef>IEEEMAC</typeRef>
             </component>
             <component componentID="2">
                <name>SrcMac</name>
                <synopsis>Source MAC used in the future versions of the library.

5.1.1.  EtherPHYCop

   EtherPHYCop LFB abstracts an encapsulation</synopsis>
                <typeRef>IEEEMAC</typeRef>
             </component>
             <component componentID="3">
                <name>VlanID</name>
                <synopsis>VLAN ID.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="4">
                <name>L2PortID</name>
                <synopsis>Output logical L2 port ID.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
          <name>EncapTableType</name>
          <synopsis>Type for Ethernet interface physical layer with
   media limited to copper.

5.1.1.1.  Data Handling

   This LFB is encapsulation table.</synopsis>
          <array type="variable-size">
            <typeRef>EncapTableEntryType</typeRef>
          </array>
       </dataTypeDef>
       <dataTypeDef>
          <name>MetadataDispatchType</name>
          <synopsis>Entry type for metadata dispatch table.</synopsis>
          <struct>
             <component componentID="1">
                <name>MetadataID</name>
                <synopsis>metadata ID</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="2">
                <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>MetadataDispatchTableType</name>
          <synopsis>Type for Metadata dispatch table.</synopsis>
          <array type="variable-size">
            <typeRef>MetadataDispatchType</typeRef>
          </array>
       </dataTypeDef>
       <dataTypeDef>
          <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>Entry type for queue depth table.</synopsis>
          <struct>
             <component componentID="1">
                <name>QueueID</name>
                <synopsis>Queue ID</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="2">
                <name>QueueDepthInPackets</name>
                <synopsis>the Queue Depth when the interface to depth units
                are packets.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="3">
                <name>QueueDepthInBytes</name>
                <synopsis>the Queue Depth when the Ethernet depth units
                are bytes.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
          <name>QueueDepthTableType</name>
          <synopsis>Type for Queue depth table.</synopsis>
          <array type="variable-size">
            <typeRef>QueueDepthType</typeRef>
          </array>
       </dataTypeDef>
    </dataTypeDefs>
    <metadataDefs>
       <metadataDef>
          <name>PHYPortID</name>
          <synopsis>The physical media.  The LFB
   handles ethernet frames coming in from or going out port ID that a packet has entered.
          </synopsis>
          <metadataID>1</metadataID>
          <typeRef>uint32</typeRef>
       </metadataDef>
       <metadataDef>
          <name>SrcMAC</name>
          <synopsis>Source MAC address of the FE. packet.</synopsis>
          <metadataID>2</metadataID>
          <typeRef>IEEEMAC</typeRef>
       </metadataDef>
       <metadataDef>
          <name>DstMAC</name>
          <synopsis>Destination MAC address of the packet.</synopsis>
          <metadataID>3</metadataID>
          <typeRef>IEEEMAC</typeRef>
       </metadataDef>
       <metadataDef>
          <name>LogicalPortID</name>
          <synopsis>ID of a logical port for the packet.</synopsis>
          <metadataID>4</metadataID>
          <typeRef>uint32</typeRef>
       </metadataDef>
       <metadataDef>
          <name>EtherType</name>
          <synopsis>Indicating the Ethernet frames sent and received cover all packets encapsulated with
   different versions type of the Ethernet protocols, like Ethernet V2, 802.3
   RAW, IEEE 802.3/802.2,IEEE 802.3/802.2 SNAP, including packets
   encapsulated with varieties packet.
          </synopsis>
          <metadataID>5</metadataID>
          <typeRef>uint32</typeRef>
       </metadataDef>
       <metadataDef>
          <name>VlanID</name>
          <synopsis>The Vlan ID of LAN techniques based on Ethernet, like
   various VLANs, MACinMAC, etc.  Therefore in the XML an EthernetAll
   frame type has been introduced.

   Ethernet frames are received from the physical media port and passed
   downstream to LFBs such as EtherMACIn via a singleton output known as
   "EtherPHYOut".  A 'PHYPortID' metadatum, to indicate which physical
   port the frame came into from the external world, is passed along
   with the frame. Ethernet packets are received by this LFB from upstream LFBs such
   EtherMacOut via the singleton input known as "EtherPHYIn" before
   being sent out onto the external world.

5.1.1.2.  Components

   The AdminStatus component is defined for CE to administratively
   manage the status packet.</synopsis>
          <metadataID>6</metadataID>
          <typeRef>uint32</typeRef>
       </metadataDef>
       <metadataDef>
          <name>VlanPriority</name>
          <synopsis>The priority of the LFB.  The CE may adminstratively startup or
   shutdown the LFB by changing Ethernet packet.</synopsis>
          <metadataID>7</metadataID>
          <typeRef>uint32</typeRef>
       </metadataDef>
       <metadataDef>
          <name>NexthopIPv4Addr</name>
          <synopsis>Nexthop IPv4 address the value of AdminStatus.  The default
   value packet is set to 'Down'.

   An OperStatus component captures sent to.
          </synopsis>
          <metadataID>8</metadataID>
          <typeRef>IPv4Addr</typeRef>
       </metadataDef>
       <metadataDef>
          <name>NexthopIPv6Addr</name>
          <synopsis>Nexthop IPv6 address the physical port operational
   status.  A PHYPortStatusChanged event packet is defined so sent to.
          </synopsis>
          <metadataID>9</metadataID>
          <typeRef>IPv6Addr</typeRef>
       </metadataDef>
       <metadataDef>
          <name>HopSelector</name>
          <synopsis>An index the LFB packet can
   report use to look up a nexthop
          table for next hop information of the CE whenever there is an operational status change packet.</synopsis>
          <metadataID>10</metadataID>
          <typeRef>uint32</typeRef>
       </metadataDef>
       <metadataDef>
          <name>ExceptionID</name>
          <synopsis>Indicating exception type of the physical port.

   The PHYPortID component packet which is a unique identification
          exceptional for a physical
   port.  It is defined as 'read-only' by CE.  Its value is enumerated
   by FE.  The component will be used to produce a 'PHYPortID' metadatum
   at the LFB output and to associate it some processing.</synopsis>
          <metadataID>11</metadataID>
          <atomic>
             <baseType>uint32</baseType>
             <specialValues>
                 <specialValue value="0">
                   <name>AnyUnrecognizedExceptionCase</name>
                   <synopsis>any unrecognized exception case.</synopsis>
                   </specialValue>
                 <specialValue value="1">
                   <name>BroadCastPacket</name>
                   <synopsis>Packet with destination address equal to every Ethernet
                   255.255.255.255</synopsis>
                 </specialValue>
                 <specialValue value="2">
                   <name>BadTTL</name>
                   <synopsis>The packet this
   LFB receives.  The metadatum will can't be handed to downstream LFBs for
   them to use forwarded as the PHYPortID.

   A group of components are defined for link speed management.  The
   AdminLinkSpeed TTL
                   has expired.</synopsis>
                 </specialValue>
                 <specialValue value="3">
                   <name>IPv4HeaderLengthMismatch</name>
                   <synopsis>IPv4 Packet's header length is for CE to configure less
                   than 5.</synopsis>
                 </specialValue>
                 <specialValue value="4">
                    <name>LengthMismatch</name>
                    <synopsis>The packet length reported by link speed for the port and the
   OperLinkSpeed layer
                    is for CE to query less than the actual link speed total length field.</synopsis>
                 </specialValue>
                 <specialValue value="5">
                    <name>RouterAlertOptions</name>
                    <synopsis>Packet IP head include Router Alert
                    options.</synopsis>
                 </specialValue>
                 <specialValue value="6">
                    <name>RouteInTableNotFound</name>
                    <synopsis>There is no route in operation.
   The default value for the AdminLinkSpeed is set to auto-negotiation
   mode.

   A group of components are defined for duplex mode management.  The
   AdminDuplexMode is for CE route table
                    corresponding to configure proper duplex mode for the
   port and the OperDuplexMode packet destination address
                    </synopsis>
                 </specialValue>
                 <specialValue value="7">
                    <name>NextHopInvalid</name>
                    <synopsis>The NexthopID is invalid</synopsis>

                 </specialValue>
                 <specialValue value="8">
                    <name>FragRequired</name>
                    <synopsis>The MTU for CE to query the actual duplex mode
   in operation.  The default value for the AdminDuplexMode outgoing interface is set to
   auto-negotiation mode.

   A CarrierStatus component captures the status of the carrier and
   specifies whether less
                    than the port packet size.</synopsis>
                 </specialValue>
                 <specialValue value="9">
                    <name>LocalDelivery</name>
                    <synopsis>The packet is linked with an operational connector.
   The default value for the CarrierStatus is 'false'.

5.1.1.3.  Capabilities

   The capability information for this LFB includes the link speeds that
   are supported by the FE (SupportedLinkSpeed) as well as the supported
   duplex modes (SupportedDuplexMode).

5.1.1.4.  Events

   This LFB is defined a local interface.
                    </synopsis>
                 </specialValue>
                 <specialValue value="10">
                    <name>GenerateICMP</name>
                    <synopsis>ICMP packet needs to be able generated.
                    </synopsis>
                 </specialValue>
                 <specialValue value="11">
                    <name>PrefixIndexInvalid</name>
                    <synopsis>The prefixIndex is wrong.</synopsis>
                 </specialValue>
                 <specialValue value="12">
                    <name>IPv6HopLimitZero</name>
                    <synopsis>Packet with Hop Limit zero </synopsis>
                 </specialValue>
                 <specialValue value="13">
                    <name>IPv6NextHeaderHBH</name>
                    <synopsis>Packet with next header set to generate several events in which Hop-by-Hop
                    </synopsis>
                 </specialValue>
              </specialValues>
           </atomic>
       </metadataDef>
       <metadataDef>
           <name>ValidateErrorID</name>
           <synopsis>Indicating error type of the CE may be interested.  There packet failed some
           validation process.</synopsis>
           <metadataID>12</metadataID>
           <atomic>
              <baseType>uint32</baseType>
              <specialValues>
                 <specialValue value="0">
                    <name> AnyUnrecognizedValidateErrorCase</name>
                    <synopsis> Any unrecognized validate error case.
                    </synopsis>
                 </specialValue>
                 <specialValue value="1">
                    <name>InvalidIPv4PacketSize</name>
                    <synopsis>Packet size reported is an event for changes in the
   status less than 20
                    bytes.</synopsis>
                 </specialValue>
                 <specialValue value="2">
                    <name>NotIPv4Packet</name>
                    <synopsis>Packet is not IP version 4.</synopsis>
                 </specialValue>
                 <specialValue value="3">
                    <name>InvalidIPv4HeaderLengthSize</name>
                    <synopsis>Packet's header length is less than 5.
                    </synopsis>
                 </specialValue>
                 <specialValue value="4">
                    <name>InvalidIPv4Checksum</name>
                    <synopsis>Packet with invalid checksum.</synopsis>
                 </specialValue>
                 <specialValue value="5">
                    <name>InvalidIPv4SrcAddrCase1</name>
                    <synopsis>Packet with source address equal to
                    255.255.255.255.</synopsis>
                 </specialValue>
                 <specialValue value="6">
                    <name>InvalidIPv4SrcAddrCase2</name>
                    <synopsis>Packet with source address 0.</synopsis>
                 </specialValue>
                 <specialValue value="7">
                    <name>InvalidIPv4SrcAddrCase3</name>
                    <synopsis>Packet with source address of the physical port (PhyPortStatusChanged).  Such an event
   will notify that the physical port status has been changed and the
   report will include the new status form
                    127.any.</synopsis>
                 </specialValue>
                 <specialValue value="8">
                    <name>InvalidIPv4SrcAddrCase4</name>
                    <synopsis>Packet with source address in Class E
                    domain.</synopsis>
                 </specialValue>
                 <specialValue value="9">
                    <name>InvalidIPv6PakcetSize</name>
                    <synopsis>Packet size reported is less than 40
                    bytes.</synopsis>
                 </specialValue>
                 <specialValue value="10">
                    <name>NotIPv6Packet</name>
                    <synopsis>Packet is not IP version 6.</synopsis>
                 </specialValue>
                 <specialValue value="11">
                    <name>InvalidIPv6SrcAddrCase1</name>
                    <synopsis>Packet with multicast source address (the
                    MSB of the physical port.

   Another event captures changes source address is 0xFF).</synopsis>
                 </specialValue>
                 <specialValue value="12">
                    <name>InvalidIPv6SrcAddrCase2</name>
                    <synopsis>Packet with source address set to
                    loopback(::1).</synopsis>
                 </specialValue>
                 <specialValue value="13">
                    <name>InvalidIPv6DstAddrCase1</name>
                    <synopsis>Packet with destination set to 0 or ::1.
                    </synopsis>
                 </specialValue>
              </specialValues>
           </atomic>
       </metadataDef>
       <metadataDef>
          <name>L3PortID</name>
          <synopsis>ID of L3 port.</synopsis>
          <metadataID>13</metadataID>
          <typeRef>uint32</typeRef>
       </metadataDef>
       <metadataDef>
          <name>RedirectIndex</name>
          <synopsis>metadata CE sends to RedirectIn LFB for the
          associated packet to select output port in the operational link speed
   (LinkSpeedChanged).  Such an event will notify LFB group
          output "PktsOut".</synopsis>
          <metadataID>14</metadataID>
          <typeRef>uint32</typeRef>
       </metadataDef>
       <metadataDef>
          <name>MediaEncapInfoIndex</name>
          <synopsis>An index the CE packet uses to look up a media
          encapsulation table to select its encapsulation media as
          well as followed encapsulation LFB.</synopsis>
          <metadataID>15</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 the
   operational speed has been changed resides in an
   FE, and is a functionally accurate abstraction of the report will include the
   new negotiated operational speed.

   A final event captures changes 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 duplex mode
   (DuplexModeChanged).  Such an event will notify data path.  LFB classes are
   the CE that basic building blocks of the
   duplex mode FE model.  Note that RFC 5810 has been changed and
   already defined an 'FE Protocol LFB' which is as a logical entity in
   each FE to control the report will include ForCES protocol.  RFC 5812 has already defined
   an 'FE Object LFB'.  Information like the new
   negotiated duplex mode.

5.1.2.  EtherMACIn

   EtherMACIn FE Name, FE ID, FE State,
   LFB abstracts an Topology in the FE are represented in this LFB.

   As specified in Section 3.1, this document focuses the base LFB
   library for implementing typical router functions, especially for IP
   forwarding functions.  As a result, LFB classes in the library are
   all base LFBs to implement router forwarding.

5.1.  Ethernet port at MAC Processing LFBs

   As the most popular physical and data link layer. layer protocols, Ethernets
   are widely deployed.  It
   specifically describes becomes a basic requirement for a router to
   be able to process various Ethernet processing functions like MAC address
   locality check, deciding if the data packets.

   Note that there exist different versions of Ethernet packets should be bridged,
   provide protocols, like
   Ethernet layer flow control, 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.

5.1.2.1.  Data Handling

   The LFB is expected  Ethernet processing LFBs defined here
   are intended to receive be able to cope with all types these variations of Ethernet packets, via a
   singleton input known as "EtherMACIn", which
   technology.

   There are usually output from
   some also various types of Ethernet physical layer LFB, like an EtherPHYCop LFB, alongside
   with interface media.
   Among them, copper and fiber media may be the most popular ones.  As
   a metadatum indicating base LFB definition and a start work, the document only defines an
   Ethernet physical port ID that the packet
   comes.

   The LFB is defined with two separate singleton outputs.  All Output
   packets are copper media.  For other media interfaces,
   specific LFBs may be defined in Ethernet format, as received from the physical layer
   LFB and cover all types future versions of the library.

5.1.1.  EtherPHYCop

   EtherPHYCop LFB abstracts an Ethernet packets.

   The first singleton output is known as "NormalPathOut".  It usually
   outputs Ethernet packets interface physical layer with
   media limited to some copper.

5.1.1.1.  Data Handling

   This LFB like an EtherClassifier is the interface to the Ethernet physical media.  The LFB for
   further L3 forwarding process alongside
   handles ethernet frames coming in from or going out of the FE.
   Ethernet frames sent and received 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, including packets
   encapsulated with varieties of LAN techniques based on Ethernet, like
   various VLANs, MACinMAC, etc.  Therefore in the XML an EthernetAll
   frame type has been introduced.

   Ethernet frames are received from the physical media port and passed
   downstream to LFBs such as EtherMACIn via a PHYPortID metadata
   indicating singleton output known as
   "EtherPHYOut".  A 'PHYPortID' metadatum, to indicate which physical
   port the packet frame came from.

   The second singleton output into from the external world, is passed along
   with the frame.

   Ethernet packets are received by this LFB from upstream LFBs such
   EtherMacOut via the singleton input known as "L2BridgingPathOut".
   Although "EtherPHYIn" before
   being sent out onto the LFB library this document defines is basically to meet
   typical router functions, it will attempt to be forward compatible
   with future router functions. external world.

5.1.1.2.  Components

   The "L2BridgingPathOut" AdminStatus component is defined for CE to
   meet administratively
   manage the requirement that L2 bridging functions may be optionally
   supported simultaneously with L3 processing and some L2 bridging LFBs
   that status of the LFB.  The CE may be defined in adminstratively startup or
   shutdown the future.  If LFB by changing the FE supports L2 bridging,
   the CE can enable or disable it by means value of a "L2BridgingPathEnable"
   component in the FE.  If it AdminStatus.  The default
   value is enabled, by also instantiating some L2
   bridging LFB instances following the L2BridgingPathOut, FEs are
   expected set to fulfill L2 bridging functions.  L2BridgingPathOut will
   output packets exactly 'Down'.

   An OperStatus component captures the same as that in physical port operational
   status.  A PHYPortStatusChanged event is defined so the NormalPathOut output.

   This LFB can be set to work in a Promiscuous Mode, allowing all
   packets
   report to pass through the LFB without being dropped.  Otherwise, CE whenever there is an operational status change of
   the physical port.

   The PHYPortID component is a
   locality check unique identification for a physical
   port.  It is defined as 'read-only' by CE.  Its value is enumerated
   by FE.  The component will be performed based on the local MAC addresses.
   All packets that do not pass through used to produce a 'PHYPortID' metadatum
   at the locality check will be
   dropped.

   This LFB can perform output and to associate it to every Ethernet layer flow control.  This is usually
   implemented cooperatively by the EtherMACIn packet this
   LFB and the EtherMACOut
   LFB. receives.  The flow control is further distinguished by Tx flow control
   and Rx flow control, separately metadatum will be handed to downstream LFBs for sending process and receiving
   process flow controls.

5.1.2.2.  Components
   them to use the PHYPortID.

   A group of components are defined for link speed management.  The AdminStatus component
   AdminLinkSpeed is defined for CE to administratively
   manage configure link speed for the status of port and the LFB.  The
   OperLinkSpeed is for CE may administratively startup or
   shutdown to query the LFB by changing the value of AdminStatus. actual link speed in operation.
   The default value for the AdminLinkSpeed is set to 'Down'. auto-negotiation
   mode.

   A group of components are defined for duplex mode management.  The LocalMACAddresses component specifies the local MAC addresses
   based on which locality checks will be made.  This component
   AdminDuplexMode is an
   array of MAC addresses, for CE to configure proper duplex mode for the
   port and of 'read-write' access permission.

   An L2BridgingPathEnable component captures whether the LFB OperDuplexMode is set to
   work as a L2 bridge.  An FE that does not support bridging will
   internally set this flag for CE to false, and additionally set query the flag
   property as read-only. actual duplex mode
   in operation.  The default value for is 'false'.

   The PromiscuousMode component specifies whether the LFB AdminDuplexMode is set to
   work as in a promiscuous
   auto-negotiation mode.  The default value for is 'false'.

   The TxFlowControl

   A CarrierStatus component defines whether captures the LFB is performing
   flow control on sending packets.  The default value for is 'false'

   The RxFlowControl component defines status of the carrier and
   specifies whether the LFB port is performing
   flow contron on receiving packets. linked with an operational connector.
   The default value for the CarrierStatus is 'false'.

   A struct component, MACInStats, defines a set of statistics

5.1.1.3.  Capabilities

   The capability information for this
   LFB, including LFB includes the number of received packets and link speeds that
   are supported by the number of
   dropped packets.

5.1.2.3.  Capabilities

   This LFB does not have a list of capabilities.

5.1.2.4. FE (SupportedLinkSpeed) as well as the supported
   duplex modes (SupportedDuplexMode).

5.1.1.4.  Events

   This LFB does not have any is defined to be able to generate several events specified.

5.1.3.  EtherClassifier

   EtherClassifier LFB abstracts in which
   the process to decapsulate Ethernet
   packets and classify CE may be interested.  There is an event for changes in the data packets into various network layer data
   packets according to information included
   status of the physical port (PhyPortStatusChanged).  Such an event
   will notify that the physical port status has been changed and the
   report will include the new status of the physical port.

   Another event captures changes in the operational link speed
   (LinkSpeedChanged).  Such an event will notify the CE that the
   operational speed has been changed and the report will include the
   new negotiated operational speed.

   A final event captures changes in the duplex mode
   (DuplexModeChanged).  Such an event will notify the CE that the
   duplex mode has been changed and the report will include the new
   negotiated duplex mode.

5.1.2.  EtherMACIn

   EtherMACIn LFB abstracts an Ethernet packets
   headers.

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

5.1.2.1.  Data Handling

   The LFB expects is expected to receive all types of Ethernet packets, including
   VLAN Ethernet types.  The input is via a
   singleton input known as "EtherMACIn", which may
   connect to an upstream LFB are usually output from
   some Ethernet physical layer LFB, like EtherMACIn LFB. an EtherPHYCop LFB, alongside
   with a metadatum indicating the physical port ID that the packet
   comes.

   The input LFB is also
   capable defined with two separate singleton outputs.  All Output
   packets are in Ethernet format, as received from the physical layer
   LFB and cover all types of multiplexing Ethernet packets.

   The first singleton output is known as "NormalPathOut".  It usually
   outputs Ethernet packets 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 LFB like an 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
   further L3 forwarding process alongside with a PHYPortID
   metadatum, metadata
   indicating the which physical port the packet comes came from.  In
   some cases, for instance, like in an MACinMAC case, a LogicalPortID
   metadatum may be expected

   The second singleton output is known as "L2BridgingPathOut".
   Although the LFB library this document defines is basically to associate meet
   typical router functions, it will attempt to be forward compatible
   with the Ethernet packet future router functions.  The "L2BridgingPathOut" is defined to
   further indicate which logical port
   meet the Ethernet packet belongs to.
   Note requirement that PHYPortID metadata is always expected while LogicalPortID
   metadata is L2 bridging functions may be optionally expected.

   A VLANInputTable component is
   supported simultaneously with L3 processing and some L2 bridging LFBs
   that may be defined in the future.  If the FE supports L2 bridging,
   the CE can enable or disable it by means of a "L2BridgingPathEnable"
   component in the FE.  If it is enabled, by also instantiating some L2
   bridging LFB instances following the L2BridgingPathOut, FEs are
   expected to classify VLAN
   Ethernet packets.  According to IEEE VLAN specifications, all
   Ethernet fulfill L2 bridging functions.  L2BridgingPathOut will
   output packets can be recognized exactly the same 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 NormalPathOut output.

   This LFB can be set to every input
   packet of the LFB.  The table assigns every input packet with work in a new
   LogicalPortID according Promiscuous Mode, allowing all
   packets to pass through the packet incoming port ID and the VLAN
   ID.  A packet incoming port ID is defined as LFB without being dropped.  Otherwise, a physical port ID if
   there is no logical port ID associated with
   locality check will be performed based on the packet, or a logical
   port ID if there is a logical port ID associated with local MAC addresses.
   All packets that do not pass through the packet.
   The VLAN ID locality check will be
   dropped.

   This LFB can perform Ethernet layer flow control.  This is exactly usually
   implemented cooperatively by the Vlan ID in EtherMACIn LFB and the packet if it is a VLAN
   packet, or 0 if it EtherMACOut
   LFB.  The flow control is not a VLAN packet.  Note that a logical port ID
   of a packet may be rewritten with a new one further distinguished by the VLANInputTable
   processing.

   An EtherDispatchTable Tx flow control
   and Rx flow control, separately for sending process and receiving
   process flow controls.

5.1.2.2.  Components

   The AdminStatus component is defined for CE to dispatch every Ethernet
   packet to a group of outputs according to the logical port ID
   assigned by VLANInputTable to the packet and administratively
   manage the Ethernet type in status of the
   Ethernet packet header.  By LFB.  The CE configuring the dispatch table, may administratively startup or
   shutdown 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 by changing the LFB classify packets according value of AdminStatus.  The default
   value is set to protocols
   like IPv4, IPv6, MPLS, ARP, ND, etc.

   Output 'Down'.

   The LocalMACAddresses component specifies the local MAC addresses
   based on which locality checks will be made.  This component is an
   array of MAC addresses, and of 'read-write' access permission.

   An L2BridgingPathEnable component captures whether the LFB is hence defined set to
   work as a group output.  Because there
   may be various types of protocol packets at the output ports, L2 bridge.  An FE that does not support bridging will
   internally set this flag to false, and additionally set the
   frameproduced is defined flag
   property as arbitrary for the purpose of wide
   extensibility in the future.  In order read-only.  The default value for downstream LFBs to use, a
   bunch of metadata is produced to associate with every output packet. 'false'.

   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 PromiscuousMode component specifies whether the packet LFB is set to
   work as in a VLAN packet.

   A MaxOutPutPorts promiscuous mode.  The default value for is defined as the capability of the LFB to indicate
   how many classification output ports 'false'.

   The TxFlowControl component defines whether 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 performing
   flow control on sending packets.  The default value for is 'false'

   The RxFlowControl component defines whether the incoming port ID field LFB is performing
   flow contron on receiving packets.  The default value for is 'false'.

   A struct component, MACInStats, defines a set of statistics for this
   LFB, including 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 of received packets and the number of
   dropped packets.

5.1.2.3.  Capabilities

   This LFB for various purposes.  See section 6 for detailed XML
   definitions does not have a list of the LFB.

5.1.4.  EtherEncapsulator

   EtherEncapsulator capabilities.

5.1.2.4.  Events

   This LFB does not have any events specified.

5.1.3.  EtherClassifier

   EtherClassifier LFB abstracts the process to encapsulate IP packets
   to decapsulate Ethernet packets.

   Input
   packets and classify them.

5.1.3.1.  Data Handling

   This LFB describes the process of decapsulating Ethernet packets and
   classify them into various network layer data packets according to
   information included in the Ethernet packets headers.

   TThe LFB expects is expected to receive all types of IP Ethernet packets,
   including IPv4 and IPv6
   types.  The input is VLAN Ethernet types, via a singleton one input known as
   "EtherPktsIn", which may connect to are usually output from an upstream LFB like an IPv4NextHop, an IPv6NextHop, or any LFB which requires to
   output packets for Ethernet encapsulation.  The
   EtherMACIn LFB.  This input is also capable of multiplexing to allow
   for multiple upstream LFBs being connected.  For instance, an IPv4NextHop or an IPv6NextHop may concurrently
   exist, and when L2
   bridging function is enabled in EtherMACIn LFB, some L2 bridging LFBs
   may also output be applied.  In this case, some Ethernet packets after L2
   processing may have to this be input to EtherClassifier LFB
   simultaneously.  Input of for
   classification, while simultaneously packets directly output from
   EtherMACIn may also need to input to this LFB LFB.  This input is capable
   of handling this case.  Usually, every input Ethernet packet is all expected to Ethernet Packets will
   be associated with an output logical port ID and a next hop IP address as its
   metadata.  In PHYPortID metadatum, indicating the physical
   port the case when L2 bridging function is implemented, an
   input packet may also optionally receive a VLAN priority as its
   metadata. comes from.  In this case, default value for this metadata is set to 0.

   There are several outputs for this LFB.  One singleton output is some cases, 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 instance, like in a
   MACinMAC case, a LogicalPortID metadatum may be expected to use Ethernet II as its associate
   with the Ethernet encapsulation type.
   Success output also produces an output logical port ID as metadatum
   of every output packet for a downstream LFB to decide further indicate which logical port the
   Ethernet packet should go out. belongs to.  Note that PHYPortID metadata is always
   expected while LogicalPortID metadata is optionally expected.

   The downstream LFB usually dispatches
   the packets based on its associated output logical port ID.  Hence, is defined with a
   generic dispatch LFB group output known as defined in Section 5.6.1 "ClassifyOut".
   Because there may be adopted for
   dispatching various types of protocol packets based on at the output logical port ID.

   Note that in some implementations of LFBs topology,
   ports, the processing to
   dispatch packets based on an produced output logical port ID may also take
   place before an Ethernet encapsulation,i.e., packets coming into frame is defined as arbitrary for the
   encapsulator LFB have already been switched to individual logical
   output port paths.  In this case,
   purpose of wide extensibility in the EtherEncap LFB success future.  In order for downstream
   LFBs to use, a bunch of metadata is produced to associate with every
   output packet.  The medatdata, which may be directly connected to a used by downstream LFB like an EtherMACOut
   LFB.

   Another singleton output is LFBs
   for IPv4 packets that are unfortunately
   unable to find packet processing, contains the PHYPortID and it also contains
   information on Ethernet L2 encapsulation type, source MAC address, and destination MAC
   address of its original Ethernet packet.  Moreover, it contains
   information of logical port ID assigned by ARP table in
   the LFB.  In this case, LFB.  Lastly, it may
   conditionally contain information like VlanID and VlanPriority with
   the condition that the packet is a copy of VLAN packet.

5.1.3.2.  Components

   An EtherDispatchTable array component is defined in the packets may need LFB to be
   redirected
   dispatch every Ethernet packet to an ARP LFB in the FE, or output group according to CE if ARP function is
   implemented the
   logical port ID assigned by CE.  More importantly, a next hop IP address metadata
   should be associated with every the VLANInputTable to the packet output here.  When and the
   Ethernet type in the Ethernet packet header.  Each row of the array
   is a struct containing a Logical Port ID, an ARP LFB
   or CE receives these packets EtherType and associated next hop IP address
   metadata, it may an Output
   Index.  With the CE configuring the dispatch table, the LFB can 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 classify various network layer protocol type 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 them at different output packets need?  Note ports.  It is expected that the LFB
   classify packets may be redirected according to CE and CE should know what the
   purpose of the packets for. protocols like IPv4, IPv6, MPLS, ARP,
   ND, etc.

   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 VLANInputTable array component is defined 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 classify
   VLAN Ethernet encapsulation.  At this time,
   it is hoped packets.  Each row of the ARP table has been refreshed with new L2 information
   that will make these packets able to find)

   A more singleton output array is for IPv6 packets that are unfortunately
   unable a strcut containing
   an Incoming Port ID, a VLAN ID and a Logical Port ID.  According to find
   IEEE VLAN specifications, all Ethernet L2 encapsulation information packets can be recognized as
   VLAN types by Neighbor
   table defining that if there is no VLAN encapsulation 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,
   packet, a next
   hop IP address metadata should be associated case with VLAN tag 0 is considered.  Therefore the table
   actually applies to every input packet output
   here.  When of 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 LFB.  Every input
   packet is then able to be added in neighbor table in this LFB
   by ND LFB or by CE.  As assigned with 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 new LogicalPortID according 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 packet
   incoming port ID and CE should know what the purpose of the packets for.  A metadata
   may need to indicate this) VLAN ID.  A singleton output packet incoming port ID 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 as a VLAN
   output table.

   The VLAN output table physical port ID if there is defined as the component of no logical port ID
   associated with the LFB.  The
   table uses packet, or a logical port ID as an index to find if there is a VLAN ID and a new
   output
   logical port ID.  In reality, ID associated with the logical port packet.  The VLAN ID applied here is exactly
   the output logical port Vlan 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 the packet if
   there it is no VLAN encapsulation in a packet, a case with VLAN tag packet, or 0 if it is
   considered.  Therefore, every input IP packet actually has to look up
   the VLAN output table to find out not a
   VLAN packet.  Note that a logical port ID and of a packet may be
   rewritten with a new output one by the VLANInputTable processing.

   Note that the logical port ID according to its original 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..

   The ARP table ID in the LFB is defined as a component incoming port ID field 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
   VLANInputTable, physical port ID
   which is got by looking up the VLAN output table, and logical port ID must be assigned
   with separate number spaces.

   An array component, EtherClassifyStats, defines a next hop IPv4
   address which is got by upstream next hop applicator set of statistics
   for this LFB, to look up
   the ARP table to find the Ethernet L2 information, i.e., measuring the source
   MAC address and destination MAC address.

   The neighbor table is defined as another component number of packets per EtherType.  Each
   row of the LFB.  The
   table array is for IPv6 packet a struct containing an EtherType and a Packet
   number.

5.1.3.3.  Capabilities

   This LFB does not have a list of capabilities.

5.1.3.4.  Events

   This LFB has no events specified.

5.1.4.  EtherEncap

   The EtherEncap LFB abstracts the process to find its next hop replace or attach
   appropriate Ethernet layer MAC
   addresses.  Like the ARP table, input IPv6 packet will use its output
   logical port ID got from looking up headers to the VLAN output table, and packet.

5.1.4.1.  Data Handling

   This LFB abstracts the
   packet next hop IPv4 address got by upstream next hop applicator LFB, process to look up the neighbor table encapsulate IP packets to find the Ethernet source MAC address
   and destination MAC address.

   As will be described in
   packets according to the address resolution LFBs section (section
   5.4), Layer 2 address resolution protocols L2 information.

   The LFB is expected to receive types of IP packets, including IPv4
   and IPv6 types, via a singleton one known as "EncapIn" which may be implemented with
   two choices.  One is by FE with specific address resolution LFB, like
   connected to an ARP upstream LFB or like an ND LFB.  The other is to redirect address resolution
   protocol messages IPv4NextHop, an IPv6NextHop,
   BasicMetadataDispatch, or any LFB which requires to CE output packets
   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 Ethernet encapsulation.  The LFB defines always expects from upstream
   LFBs the
   neighbor table MediaEncapInfoIndex metadata which is used as its alias.  This means that the ARP table or an index to
   lookup the
   neighbor table will Encapsulation Table.  Optinally an input packet may be maintained or refreshed
   accompanied by a Vlan priority metadata.  In this case, default value
   for the ARP LFB or the
   ND LFB when the LFBs metadata is 0.

   Two singleton output ports are used.

   Note that the ARP defined to output results.

   The first singleton output known as "SuccessOut".  Upon a successful
   table lookup, the destination and source MAC addresses, and the neighbor table defined in this LFB
   logical media port (L2PortID) are all with property of read-write.  CE can also configure found in 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 matching table entry.
   The CE may set the VlanId in FE.

   With all case VLANs are used.  By default 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 entry for VlanId of 0 is used as per IEEE 802.1Q, rules.  Whatever the
   value of VlanID is, if input
   packets are with non-zero VLAN priority metadata, the packets Input metadata VlanPriority is non-zero,
   the packet will
   always be encapsulated with have a VLAN tag, no matter the value of VLAN
   ID is zero or not. tag.  If the VLAN priority VlanPriority and the VLAN ID VlanID
   are all zero, the packets will be encapsulated without a there is no VLAN tag.

   Successfully encapsulated packets are then output via success output
   port.

   There are also some other components, capabilities, events defined in tag to this packet.  After replacing
   or attaching the LFB for various purposes.  See section 6 for detailed XML
   definitions of appropriate Ethernet headers to the LFB.

5.1.5.  EtherMACOut

   EtherMACOut packet is
   complete, the packet is passed out on the "SuccessOut" LFB abstracts an Ethernet port at MAC data link layer.
   This LFB describes Ethernet packet output process.  Ethernet output
   functions are closely related to Ethernet input functions, therefore
   many components defined in this LFB are as aliases of EtherMACIn a
   downstream LFB
   components.

5.1.5.1.  Data Handling instance alongside with the L2PortID.

   The LFB is expected to receive all types of Ethernet packets, via a second singleton input output known as "EtherPktsIn", "ExceptionOut", which are usually will
   output from
   an Ethernet encapsulation LFB, alongside with a metadatum indicating packets for which the physical port ID that table lookup fails, along with an
   additional ExceptionID metadata.  Currently defined exception types
   only include the packet will go through(editorial note:
   need more discussion on following case:

   o  MediaEncapInfoIndex value is not allocated in the port ID being physical layer or L2
   layer). EncapTable.

   The upstream LFB is defined with may be programmed by the CE to pass along a singleton output.  All Output packets are
   MediaEncapInfoIndex that does not exist in Ethernet format, possibly with various Ethernet types, alongside
   with a metadatum indicating the physical port ID the packet EncapTable.  That is
   to go
   through.  This output links allow for resolution of the L2 headers, if needed, to be made at
   the L2 encapsulation level in this case(ethernet) via ARP, or ND (or
   other methods depending on the link layer technology) when a downstream table
   miss occurs.

   For neighbor L2 header resolution(table miss exception), the
   processing LFB that is usually an
   Ethernet physical may pass this packet to the CE via the redirect LFB like EtherPHYcop LFB.

   This or
   FE software or another LFB can perform Ethernet layer flow control.  This is usually
   implemented cooperatively by instance for further resolution.  In such
   a case the EtherMACIn metadata NexthopIPv4Addr or NexthopIPv6Addr generated by
   Nexthop LFB and the EtherMACOut
   LFB.  The flow control is further distinguished by Tx flow control
   and Rx flow control, separately for sending process and receiving
   process flow control.

   Note that as a base definition, functions like multiple virtual MAC
   layers are not supported in this LFB version.  It may be supported in also passed to the future by defining a subclass exception handling.  Such an IP
   address could be used to do activities such as ARP or a new version of this LFB

5.1.5.2.  Components ND by the
   handler it is passed to.

   The AdminStatus component result of the L2 resolution is defined for CE to administratively
   manage update the status of EncapTable as well
   as the LFB. Nexthop LFB so subsequent packets do not fail EncapTable
   lookup.  The EtherEncap LFB does not make any assumptions of how the
   EncapTable is updated by the CE may administratively startup (or whether ARP/ND is used
   dynamically or
   shutdown the static maps exist).

   Downstream neighboring LFB by changing instances could be either an EtherMACOut
   type or a BasicMetadataDispatch type.  If the value of AdminStatus.  The default
   value final packet L2
   processing is set possible to 'Down'.  Note that this be on per-media-port basis or resides on a
   different FE or in cases where L2 header resolution is needed, then
   the model makes sense to use a BasicMetadataDispatch LFB to fanout to
   different LFB instances.  If there is a direct egress port point,
   then the model makes sense to have a downstream LFB instance be an
   EtherMACOut.

5.1.4.2.  Components

   This LFB has only one component named EncapTable which is defined as
   an
   alias array.  Each row of the AdminStatus component in array is a struct containing the EtherMACIn LFB.  This
   infers that an EtherMACOut LFB usually coexists
   destination MAC address, the source MAC address, the VLAN ID with an EtherMACIn
   LFB, both a
   default value of which share the same administrative status management by
   CE.  Alias properties as defined in zero and the ForCES FE model (RFC 5812)
   will be used by CE to declare the target component this alias refers,
   which include the target LFB class and instance IDs as well as the
   path to the target component.  Whereas, these properties are set by
   CE only when a system runs, which are outside the XML definitions of
   this LFB.

   The MTU component defines the maximum transmission unit

   The TxFlowControl component defines whether the LFB is performing
   flow control on sending packets.  The default value for is 'false'.
   Note that this component is defined as an alias of TxFlowControl
   component in the EtherMACIn LFB.

   The RxFlowControl component defines whether the LFB is performing
   flow control on receiving packets.  The default value for is 'false'.
   Note that this component is defined as an alias of RxFlowControl
   component in the EtherMACIn LFB.

   A struct component, MACOutStats, defines a set of statistics for this
   LFB, including the number of transmitted packets and the number of
   dropped packets.

5.1.5.3. output logical L2 port ID.

5.1.4.3.  Capabilities

   This LFB does not have a list of capabilities.

5.1.5.4.

5.1.4.4.  Events

   This LFB does not have any events specified.

5.2.  IP Packet Validation LFBs

   The LFBs are defined to abstract IP packet validation process.  An
   IPv4Validator

5.1.5.  EtherMACOut

   EtherMACOut LFB is specifically for IPv4 protocol validation and abstracts an
   IPv6Validator LFB for IPv6.

5.2.1.  IPv4Validator

   The IPv4Validator Ethernet port at MAC data link layer.
   This LFB performs IPv4 packets validation according describes Ethernet packet output process.  Ethernet output
   functions are closely related to
   RFC 1812.

5.2.1.1. Ethernet input functions, therefore
   many components defined in this LFB are as aliases of EtherMACIn LFB
   components.

5.1.5.1.  Data Handling

   This

   The LFB performs IPv4 validation according is expected to RFC 1812.  Then the
   IPv4 packet will be receive all types of Ethernet packets, via a
   singleton input known as "EtherPktsIn", which are usually output to from
   an Ethernet encapsulation LFB, alongside with a metadatum indicating
   the corresponding physical port regarding of the
   validation result, whether ID that the packet will go through(editorial note:
   need more discussion on the port ID being physical layer or L2
   layer).

   The LFB is defined with a unicast or singleton output.  All Output packets are
   in Ethernet format, possibly with various Ethernet types, alongside
   with a multicast
   one, an exception has occurred or metadatum indicating the validation failed. physical port ID the packet is to go
   through.  This output links to a downstream LFB always expects, as input, packets which have been indicated
   as IPv4 packets by that is usually an upstream LFB,
   Ethernet physical LFB like an EtherClassifier EtherPHYcop LFB.
   There

   This LFB can perform Ethernet layer flow control.  This is no specific metadata expected usually
   implemented cooperatively by the input of EtherMACIn LFB and the EtherMACOut
   LFB.  The flow control is further distinguished by Tx flow control
   and Rx flow control, separately for sending process and receiving
   process flow control.

   Note that, that as a default provision of RFC 5812, base definition, functions like multiple virtual MAC
   layers are not supported 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 this LFB will version.  It may be
   explicitly marked supported in input of
   the LFB as expected metadata.  For
   instance, in future by defining a subclass or a new version of this LFB, even there LFB

5.1.5.2.  Components

   The AdminStatus component is no specific metadata expected,
   metadata like PHYPortID produced defined for CE to administratively
   manage the status of the LFB.  The CE may administratively startup or
   shutdown the LFB by some upstream physical layer LFBs
   will always pass through changing the value of AdminStatus.  The default
   value is set to 'Down'.  Note that this LFB.  In some cases, if some component is defined as an
   alias of the AdminStatus component in the EtherMACIn LFB.  This
   infers that an EtherMACOut LFB may use the metadata, it actually still can use it
   regardless usually coexists with an EtherMACIn
   LFB, both of whether which share the metadata has been expected or not.

   Four output ports are same administrative status management by
   CE.  Alias properties as defined to output various validation results.

   All validated IPv4 unicast packets will be output at in the singleton
   port known as "IPv4UnicastOut".  All validated IPv4 multicast packets ForCES FE model (RFC 5812)
   will be output at used by CE to declare the singleton port known target component this alias refers,
   which include the target LFB class and instance IDs as "IPv4MulticastOut"
   port.  There is no metadata specifically required to produce at these
   output ports.

   A singleton port known well as "ExceptionOut" is defined the
   path to output packets the target component.  Whereas, these properties are set by
   CE only when a system runs, which have been validated as exception packets.  An exception ID
   metadatum is produced to indicate what has caused are outside the exception.
   Currently defined exception types include:

   o  Packet with destination address equal to 255.255.255.255

   o  Packet with expired TTL

   o  Packet with header length more than 5 words

   o  Packet IP head including Router Alert options

   Note that, although TTL is checked in XML definitions of
   this LFB.

   The MTU component defines the maximum transmission unit

   The TxFlowControl component defines whether the LFB is performing
   flow control on sending packets.  The default value for validity,
   operations to TTL like TTL decreasing will be made only is 'false'.
   Note that this component is defined as an alias of TxFlowControl
   component in a followed
   forwarding the EtherMACIn LFB.

   The final singleton port known as "FailOut" is defined for all
   packets which have failed RxFlowControl component defines whether the validation process.  A validate error
   ID LFB is associated to every failed packet to indicate the reason.
   Currently defined reasons include:

   o  Packet size reported performing
   flow control on receiving packets.  The default value for is less than 20 bytes

   o  Packet with version 'false'.
   Note that this component is not IPv4

   o  Packet with header length < 5

   o  Packet with total length field < 20

   o  Packet with invalid checksum

   o  Packet with source address equal to 255.255.255.255

   o  Packet with source address 0

   o  Packet with source address defined as an alias of form {127, <any>}

   o  Packet with source address RxFlowControl
   component in Class E domain

5.2.1.2.  Components

   This LFB has only one the EtherMACIn LFB.

   A struct component, the
   IPv4ValidatorStatisticsType, which MACOutStats, defines a set of statistics for
   validation process, this
   LFB, including the number of bad header packets, the
   number of bad total length packets, the number of bad TTL packets, transmitted packets and the number of bad checksum
   dropped packets.

5.2.1.3.

5.1.5.3.  Capabilities

   This LFB does not have a list of capabilities

5.2.1.4. capabilities.

5.1.5.4.  Events

   This LFB does not have any events specified.

5.2.2.  IPv6Validator

   The IPv6Validator LFB performs IPv6

5.2.  IP Packet Validation LFBs

   The LFBs are 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

   The IPv4Validator LFB performs IPv4 packets validation according to
   RFC 2460.

5.2.2.1. 1812.

5.2.1.1.  Data Handling

   This LFB performs IPv6 IPv4 validation according to RFC 2460. 1812.  Then the
   IPv6
   IPv4 packet will be output to the corresponding port regarding of the
   validation result, whether the packet is a unicast or a multicast
   one, an exception has occurred or the validation failed.

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

   Similar to

   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 IPv4validator LFB as expected metadata.  For
   instance, in this LFB, IPv6Validator even there is no specific metadata expected,
   metadata like PHYPortID produced by some upstream physical layer 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 also defined four been expected or not.

   Four output ports are defined to output packets for various validation results.

   All validated IPv6 IPv4 unicast packets will be output at the singleton
   port known as "IPv6UnicastOut". "IPv4UnicastOut".  All validated IPv6 IPv4 multicast packets
   will be output at the singleton port known as "IPv6MulticastOut" "IPv4MulticastOut"
   port.  There is no metadata specifically required to produce at these
   output ports.

   A singleton port known as "ExceptionOut" is defined to output packets
   which have been validated as exception packets.  An exception ID
   metadata
   metadatum is produced to indicate what has caused the exception.
   Currently defined exception types include:

   o  Packet with hop limit to zero

   o  Packet with a link-local destination address equal to 255.255.255.255

   o  Packet with a link-local source address

   o  Packet with destination all-routers expired TTL

   o  Packet with destination all-nodes header length more than 5 words

   o  Packet with next header set IP head including Router Alert options

   Note that, although TTL is checked in this LFB for validity,
   operations to Hop-by-Hop TTL like TTL decreasing will be made only in a followed
   forwarding LFB.

   The final singleton port known as "FailOut" is defined for all
   packets which have failed the validation process.  A validate error
   ID is associated to every failed packet to indicate the reason.
   Currently defined reasons include:

   o  Packet size reported is less than 40 20 bytes

   o  Packet with version is not IPv6 IPv4
   o  Packet with header length < 5

   o  Packet with total length field < 20

   o  Packet with invalid checksum

   o  Packet with multicast source address (the MSB of the equal to 255.255.255.255

   o  Packet with source address is 0xFF) 0

   o  Packet with destination source address set to 0 or ::1 of form {127, <any>}

   o  Packet with source address set to loopback (::1).

   Note that in the base type library, definitions for exception ID and
   validate error ID metadata are applied to both IPv4Validator and
   IPv6Validator LFBs, i.e., the two LFBs share the same medadata
   definition, with different ID assignment inside.

5.2.2.2. Class E domain

5.2.1.2.  Components

   This LFB has only one struct component, the
   IPv6ValidatorStatisticsType,
   IPv4ValidatorStatisticsType, which defines a set of statistics for
   validation process, including the number of bad header packets, the
   number of bad total length packets, the number of bad TTL packets,
   and the number of bad hop limit checksum packets.

5.2.2.3.

5.2.1.3.  Capabilities

   This LFB does not have a list of capabilities

5.2.2.4.

5.2.1.4.  Events

   This LFB does not have any events specified.

5.3.  IP Forwarding LFBs

   IP Forwarding LFBs are specifically defined to abstract the IP
   forwarding processes.  As definitions for a base

5.2.2.  IPv6Validator

   The IPv6Validator LFB library, this
   document restricts its performs IPv6 packets validation according to
   RFC 2460.

5.2.2.1.  Data Handling

   This LFB definition scope for IP forwarding jobs
   only performs IPv6 validation according to IP unicast forwarding.  LFBs for jobs like IP multicast may RFC 2460.  Then the
   IPv6 packet will be defined in future versions output to the corresponding port regarding of the document.

   A typical IP
   validation result, whether the packet is a unicast forwarding job or a multicast
   one, an exception has occurred or the validation failed.

   This LFB always expects, as input, packets which have been indicated
   as IPv6 packets by an upstream LFB, like an EtherClassifier LFB.
   There is usually realized no specific metadata expected by looking up
   some forwarding information table to find some next hop information,
   and then based on the next hop information, forwarding packets input of the LFB.

   Similar to
   specific the IPv4validator LFB, IPv6Validator has also defined four
   output ports.  It usually takes two steps ports to do so, firstly output packets for various validation results.

   All validated IPv6 unicast packets will be output at the singleton
   port known as "IPv6UnicastOut".  All validated IPv6 multicast packets
   will be output at the singleton port known as "IPv6MulticastOut"
   port.  There is no metadata specifically required to look up a forwarding information table by means of Longest Prefix
   Matching(LPM) rule produce at these
   output ports.

   A singleton port known as "ExceptionOut" is defined to find a next hop index, then output packets
   which have been validated as exception packets.  An exception ID
   metadata is produced to use indicate what caused the index exception.
   Currently defined exception types include:

   o  Packet with hop limit to
   look up zero

   o  Packet with a link-local destination address

   o  Packet with a link-local source address

   o  Packet with destination all-routers

   o  Packet with destination all-nodes

   o  Packet with next hop information table to find enough information header set to
   submit Hop-by-Hop

   The final singleton port known as "FailOut" is defined for all
   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 failed the validation process.  A validate error
   ID is associated to be applied, some translation work will have to be
   done in FE every failed packet to translate attributes defined by this document into real
   attributes the implementation has actually applied.

   Based on indicate the 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 reason.
   Currently defined reasons include:

   o  Packet size reported is less than 40 bytes

   o  Packet with version is not IPv6
   protocols.

5.3.1.  IPv4UcastLPM

   The LFB abstracts the process for IPv4 unicast LPM table looking up.

   Input

   o  Packet with multicast source address (the MSB of the LFB always expects to receive IPv4 unicast packets.  An
   IPv4 prefix table source
      address is defined as a component for the LFB to provide
   forwarding information for every input packet.  The 0xFF)

   o  Packet with destination IPv4 address of every packet is as the index set to look up the table 0 or ::1

   o  Packet with source address set to loopback (::1).

   Note that in the
   rule of longest prefix matching(LPM).  A hop selector is the matching
   result, which will be output base type library, definitions for exception ID and
   validate error ID metadata are applied to downstream both IPv4Validator and
   IPv6Validator LFBs, i.e., the two LFBs as an index for next
   hop information.

   Normal output of share the same medadata
   definition, with different ID assignment inside.

5.2.2.2.  Components

   This LFB is a singleton output, which will output
   IPv4 unicast packet that has passed only one struct component, the LPM lookup and got
   IPv6ValidatorStatisticsType, which defines a hop
   selector as set of statistics for
   validation process, including the lookup result.  The hop selector is associated with number of bad header packets, the packet as a metadatum.  Followed
   number of bad total length packets, and the normal output number of bad hop limit
   packets.

5.2.2.3.  Capabilities

   This LFB does not have a list of capabilities

5.2.2.4.  Events

   This LFB does not have any events specified.

5.3.  IP Forwarding LFBs

   IP Forwarding LFBs are specifically defined to abstract the LPM 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 document.

   A typical IP unicast forwarding job is usually a next hop applicator LFB.  The LFB receives packets with
   their realized by looking up
   some forwarding information table to find some next hop IDs information,
   and then based on the next hop IDs information, forwarding packets to forward the
   packets.  A hop selector associated with every packet from the normal
   specific output will directly act as 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 ID for index, then to use the index to
   look up a next hop applicator
   LFB..

   The LFB is defined information table to provide some facilities find enough information to support users
   submit packets to
   implement equal-cost multi-path routing (ECMP) or reverse path output ports.  This document abstracts the
   forwarding (RPF). processes mainly based on the two steps model.  However, this LFB itself does not provide ECMP or
   RPF.  To implement ECMP or RPF, additional specific LFBs,
   there actually exists other models, like one which may only have a
   specific ECMP LFB, will
   forwarding information base that have to be 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 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 IPv4UcastLPM LFB abstracts the IPv4 unicast Longest Prefix Match
   (LPM) process..

   This LFB also provides 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
   fully implement ECMP or RPF, additional specific LFBs, like a
   specific ECMP LFB or an RPF LFB, will have to be defined.  This work
   may be done in the future version of the document.

   For

5.3.1.1.  Data Handling

   This LFB performs the IPv4 unicast LPM table looking up.  It always
   expects as input IPv4 unicast packets from one singleton input known
   as "PktsIn".  Then the LFB uses the destination IPv4 address of every
   packet as index to support ECMP, an ECMP flag is defined in look up the IPv4 prefix table entries.  When and generate a hop
   selector as the flag is set matching result.  This result will associate to true, it indicates this table
   entry is for ECMP only.  In this case, the hop selector in this table
   entry
   packet as a metadatum to output to downstream LFBs, and will usually
   be used there as an index for a downstream specific ECMP LFB to find its correspondent more next hop IDs.  When ECMP is applied, it will
   usually get multiple next hops information.

   To distinguish normal

   Three singleton output from ECMP case output, ports are defined to output LPM results.

   The first singleton output known as "NormalOut", which will output
   IPv4 unicast packets that has passed the LPM lookup and got a specific ECMP hop
   selector as the lookup result.  The hop selector is associated with
   the packet as a metadatum.  Followed the normal output of the LPM LFB
   is defined. usually a next hop application LFB, like an IPv4NextHop LFB.

   The second singleton output known as "ECMPOut" is defined to provide
   support for users wishing to implement ECMP.

   An ECMP flag is defined in the LPM table to enable the LFB to support
   ECMP.  When a table entry is created with the flag set true, it
   indicates this table entry is for ECMP only.  A packet, which has
   passed through this prefix table
   entry lookup with true ECMP flag, lookup, will always output from this "ECMPOut"
   output port, with the hop selector being its lookup result.  The
   output will usually directly go to a downstream ECMP processing LFB.  In the ECMP LFB, based on
   where the hop selector, multiple next hop IDs may be found,
   and more ECMP algorithms may be applied to optimize the route.  As
   the result of the ECMP LFB, it will output selector can usually further generate 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 routes by use of ECMP algorithms.

   A default route flag is defined in the
   prefix LPM table entry. to enable the LFB to
   support a default route, and loose RPF also.  When set true, the prefix
   table entry is identified as a default route, route and also as a forbidden route
   for RPF.  To RPF also.  If a user wants to implement
   various RPF, one or more RPF on FE, a specific LFBs RPF
   LFB will have to be defined.  This job
   may  In such RPF LFB, a component can be done for the future version
   defined as an alias of the library.

   An exception prefix table component of this LFB as
   described below.

   The final singleton output is known as "ExceptionOut" and is defined
   to allow some exceptional exception packets to output here.  Exceptions include cases like packets
   like:

   o  Packets can not find any routes by in the prefix table.

   There are also some other components

   The upstream neighboring LFB of this LFB is usually IPv4Validator
   LFB.  If RPF is to be adopted, the upstream can be an RPF LFB, when
   defined.

   The downstream neighboring LFB is usually IPv4NextHop LFB.  If ECMP
   is adopted, the downstream can be an ECMP LFB, when defined.

5.3.1.2.  Components

   This LFB has two components.

   The IPv4PrefixTable component is defined in as an array component of the
   LFB.  Each row of the array contains an IPv4 adrress, a Prefix
   length, a Hop Selector, an ECMP flag and a Default Route flag.  The
   LFB uses the destination IPv4 address of every input packet as index
   to look up this table to get a hop selector as the result.  The ECMP
   flag is for various
   purposes.  See section 6 the LFB to support ECMP.The default route flag is for detailed XML definitions the
   LFB to support a default route and for loose RPF.

   The IPv4UcastLPMStats component is a struct component which collects
   statistics information, including the total number of input packets
   received, the LFB. IPv4 packets forwarded by this LFB and the number of IP
   datagrams discarded due to no route found.

5.3.1.3.  Capabilities

   This LFB does not have a list of capabilities

5.3.1.4.  Events

   This LFB does not have any events specified.

5.3.2.  IPv4NextHop

   This LFB abstracts the process of selecting ipv4 next hop action.

5.3.2.1.  Data Handling

   The LFB abstracts the process of next hop information application to
   IPv4 packets.

   The LFB  It receives an IPv4 packet with an associated next hop
   ID, and uses the ID to look up a 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

   The LFB is a singleton one which expects expected to receive IPv4 unicast packets and hop selector metadata from an upstream LFB.
   Usually, the upstream LFB is directly an IPv4UnicastLPM LFB_while it
   is possible some other upstream LFB may be applied.  For instance,
   when ECMP is supported, the upstream LFB may be some specific ECMP
   LFB.

   The next hop ID in hop selector metadata of IPv4 packets, via a packet singleton
   input known as "PcktsIn" along with a HopSelector metadata which is then
   used as an index to look up a next hop table defined in lookup the LFB.  Via this
   table and NextHop table.  Data processing
   involves the next hop index, important information for forwarding
   the packet is found.  Every next hop table entry includes the
   following information:

      output logical port ID, which will be used by downstream LFBs to
      find proper TTL decrement and checksum recalculation.

   Two output port.

      next hop option, which decides if packets with next hop of this
      table entry are destinated to locally attached hosts or not.
      Locally attached hosts ports are hosts in the same subnet with this
      router.  Next hop option is marked as 'forwarded defined to locally
      attached host' if the next hop entry output results.

   The first output is for locally attached hosts
      delivery.  All other next hop entry will be marked with 'normal
      forwarding'.  If a group output port known as "SuccessOut".  On
   successful data packet passes through next hop entries
      with its next hop option marked with forwarded to locally attached
      host, the next hop IP address metadata associated with processing the data packet when output is sent out an LFB-port from
   within the LFB will be forced to set to port group as selected by the
      destination IP address LFBOutputSelectIndex
   value of the data packet.  If a data matched table entry.  The packet
      passes through is sent to a next hop entry downstream
   LFB alongside with its option being normal
      forwarding, the next hop IP address metadata at L3PortID and MediaEncapInfoIndex metadata.

   The second output is a singleton output port known as "ExceptionOut",
   which will be set
      to output packets for which the next hop IP address as indicated by this next hop entry.
      Advantage data processing failed, along
   with an additional ExceptionID metadata to define this next hop option for locally attached
      hosts is, in this way, the next hop entry number may be greatly
      reduced in indicate what caused the case there are a vast number of locally attached
      hosts.

      next hop IP address, which will be used by downstream LFB to find
      proper output port IP address for this packet.  Note that when
      next hop option
   exception.  Currently defined exception types include:

   o  The HopSelector is set to 'forwarded to locally attached host',
      this entry field becomes invalid.  In this case the next hop IP
      address invalid

   o  The MTU for outgoing interface is assigned directly by destination IP address of less than the data packet pass through this entry check.

      encapsulation output index, which is used by data size

   o  ICMP packet needs to find
      proper output of this LFB.  Usually, this index can be used to
      indicate which encapsulation followed the generated

   Downstream neighboring LFB may instances could be applied to
      data packets pass through this next hop entry check and to
      classify the packets to different instance of either a group output port.
      Moreover, this index can also be
   BasicMetadataDispatch type, used to purely indicate output
      port instance fanout to act different LFB instances
   or a media encapsulation related type, such as an EtherEncap type or
   a classifier based on next hop IDs. RedirectOut type.  For
      instance, a next hop table entry example, there are Ethernet and other tunnel
   Encapsulation, then BasicMetadataDispatch can be defined with its
      encapsulation output index being directed use the L3PortID
   metadata to an output port which
      is followed with LFBs that will redirect data dispatch packets to Control
      Element(CE).  A next hop entry can also be different Encapsulator.

5.3.2.2.  Components

   This LFB has only one component named IPv4NextHopTable which is
   defined for some data
      packets that need special local processing as an array.  Each row of the Forwarding
      Element(FE).  In this case it array is not really acting as an
      encapsulation index, rather a pure output index.

   As a result, struct containing:

   o  The L3PortID, which is the ID of the Logical Output Port that is
      passed onto the neighboring LFB instance.  This ID indicates what
      port to the neighbor is as defined with two output ports.  One is for
   success output and another is by L3.

   o  MTU, the Maximum Transmission Unit for exception output.  Success output
   is a group output, with an the outgoing port.

   o  NextHopIPAddr, the IPv4 next hop Address.

   o  MediaEncapInfoIndex, the index to indicate which output instance in we pass onto the group neighboring LFB
      instance.  This index is adopted. used to lookup a table (typically media
      encapsulatation related) further downstream.  The index CE sets it to a
      value that is exactly the encapsulation output
   index described above.  Downstream LFBs connected not allocated in downstream LFB tables.  (If a
      downstream LFB lookup fails to the success
   output group find it, it indicates some other
      way to resolve it may be various LFBs for encapsulation like LFBs for
   Ethernet encapsulation and for PPP encapsulation, various LFBs for
   local processing, and LFBs for redirecting packets to CE for
   processing.  Next hop table uses needed.)

   o  LFBOutputSelectIndex, the encapsulation LFB Group output port index to
   indicate which select
      downstream LFB port.  This index exactly is the FromPortIndex for
      the port instance group "SuccessOut" in the output group table LFBTopology of FEObject
      LFB as defined for the Nexthop LFB.

5.3.2.3.  Capabilities

   This LFB does not have a packet should go.

   Every port instance list of capabilities

5.3.2.4.  Events

   This LFB does not have any events specified.

5.3.3.  IPv6UcastLPM

   The IPv6UcastLPM LFB abstracts the success output group will produce metadata IPv6 unicast Longest Prefix Match
   (LPM) process.  The definition of output logical port ID and next hop IP address for every output
   packet.  These metadata will be used by downstream LFBs to further
   implementing forwarding or local processing.  Note that for next hop
   option marked as local host processing, the next hop IP address
   metadata for the packet this LFB is exactly substituted with similar to the destination
   IPv4UcastLPM LFB except that all IP address of the packet.

   The exception output of the addresses refer to IPv6
   addresses.

   This LFB is a singleton output.  It outputs
   packets with exceptional cases.  An exception ID further indicates
   the exception reasons.  Exception may happen when also provides 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
   fully implement ECMP or RPF, additional specific LFBs, like a hop selector is
   found invalid,
   specific ECMP LFB or ICMP packets need an RPF LFB, will have to be generated (Editorial note:
   more discussions here), etc.  The exception ID is also produced as a
   metadata by the output to defined.  This work
   may be transmitted to a downstream LFB.

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

5.3.3.  IPv6UcastLPM

   The document.

5.3.3.1.  Data Handling

   This LFB abstracts performs the process for IPv6 unicast LPM table looking up.

   Definitions of this IPv6UcastLPM LFB is very identical to
   IPv4UcastLPM LFB except that all IP addresses related are changed
   from IPv4 addresses to  It always
   expects as input IPv6 addresses.  See section 6 for detailed
   XML definitions of this LFB.

5.3.4.  IPv6NextHop

   This unicast packets from one singleton input known
   as "PktsIn".  Then the LFB abstracts uses the process destination IPv6 address of next hop information application every
   packet as index to look up the IPv6 packets.

   Definitions of this IPv6NextHop LFB is very identical prefix table and generate a hop
   selector as the matching result.  This result will associate to IPv4NextHop
   LFB except that all IP addresses related are changed from IPv4
   addresses the
   packet as a metadatum to IPv6 addresses.  See section 6 for detailed XML
   definitions of this LFB.

5.4.  Redirect LFBs

   Redirect LFBs abstract data packets transportation process between CE
   and FE.  Some packets output from some LFBs may have to be delivered to CE for further processing, downstream LFBs, and some packets generated by CE may
   have to will usually
   be delivered to FE and further used there as an index to some specific LFBs for data
   path processing.  According find more next hop information.

   Three singleton output ports are defined to RFC 5810 [RFC5810], data output LPM results.

   The first singleton output known as "NormalOut", which will output
   IPv6 unicast packets that has passed the LPM lookup and
   their got a hop
   selector as the lookup result.  The hop selector is associated metadata are encapsulated in ForCES redirect message
   for transportation between CE and FE.  We define two LFBs to abstract with
   the process, packet as a RedirectIn metadatum.  Followed the normal output of the LPM LFB and
   is usually a RedirectOut LFB.  Usually, in an
   LFB topology of next hop application LFB, like an FE, only one RedirectIn LFB instance and one
   RedirectOut LFB instance exist.

5.4.1.  RedirectIn

   A RedirectIn LFB abstracts the process IPv6NextHop LFB.

   The second singleton output known as "ECMPOut" is defined to provide
   support for CE users wishing to inject data packets
   into FE LFB topology so as implement ECMP.

   An ECMP flag is defined in the LPM table to input data packets into FE data paths.

   From LFB topology point of view, enable the RedirectIn LFB acts as to support
   ECMP.  When a source
   point for data packets coming from CE, therefore the RedirectIn LFB table entry is defined created with only one output, while without any input.

   Output of the RedirectIn LFB flag set true, it
   indicates this table entry is defined as a group output.  Packets
   produced by for ECMP only.  A packet, which has
   passed through this prefix lookup, will always output from "ECMPOut"
   output port, with the hop selector being its lookup result.  The
   output will have arbitrary frame types decided by CE
   which generates usually directly go to a downstream ECMP processing LFB,
   where the packets.  Possible frames may include IPv4, IPv6, hop selector can usually further generate optimized one or ARP protocol packets.  CE may associate some metadata to indicate
   multiple next hop routes by use of ECMP algorithms.

   A default route flag is defined in the frame types.  CE may also associate other metadata to data
   packets LPM table to indicate various information on enable the packets.  Among them,
   there MUST exist LFB to
   support a 'RedirectIndex' metadata, which is an integer
   acting as an index. default route, and loose RPF also.  When CE transmits set true, the metadata
   table entry is identified a default route and as a binging
   packet forbidden route
   for RPF also.  If a user wants to implement RPF on FE, a RedirectIn LFB, the specific RPF
   LFB will read the metadata and output
   the packet have to one be defined.  In such RPF LFB, a component can be
   defined as an alias of its group output port instance, whose port index
   is just as indicated by the metadata.  Detailed XML definition prefix table component of the
   metadata this LFB as
   described below.

   The final singleton output is in the XML for base type library known as in Section 4.4.

   All metadata from CE other than the 'RedirectIndex' metadata will "ExceptionOut" and is defined
   to allow exception packets to output from here.  Exceptions include cases
   like:

   o  Packets can not find any routes in the RedirectIn prefix table.

   The upstream neighboring LFB along with their binding packets.
   Note that, a packet without a 'RedirectIndex' metadata associated
   will of this LFB is usually IPv6Validator
   LFB.  If RPF is to be dropped by adopted, the upstream can be an RPF LFB, when
   defined.

   The downstream neighboring LFB is usually an IPv6NextHop LFB.

   There  If
   ECMP is no adopted, the downstream can be an ECMP LFB, when defined.

5.3.3.2.  Components

   This LFB has two components.

   The IPv6PrefixTable component is defined for current version as an array component of RedirectIn the
   LFB.
   Detailed XML definitions  Each row of the array contains an IPv6 adrress, a Prefix
   length, a Hop Selector, an ECMP flag and a Default Route flag.  The
   LFB can be found in Section 6.

5.4.2.  RedirectOut

   A RedirectOut LFB abstracts uses the process for LFBs in FE to deliver
   data packets to CE.  From LFB topology point destination IPv6 address of view, the RedirectOut
   LFB acts every input packet as index
   to look up this table to get a sink point hop selector as the result.  The ECMP
   flag is for data packets going to CE, therefore the
   RedirectOut LFB to support ECMP.  The default route flag is defined with only one input, while without any
   output.

   Input of for
   the RedirectOut LFB is defined as to support a singleton input, but it default route and for loose RPF.

   The IPv6UcastLPMStats component is capable a struct component which collects
   statistics information, including the total number of receiving input packets from multiple LFBs by multiplexing
   received, the singleton input.  Packets expected IPv6 packets forwarded by this LFB and the input will have
   arbitrary frame types.  All metadata associated with the input
   packets will be delivered number of IP
   datagrams discarded due to CE via no route found.

5.3.3.3.  Capabilities

   This LFB does not have a ForCES protocol redirect
   message [RFC5810].  The input will expect all types list of metadata.

   There is no component defined for current version capabilities

5.3.3.4.  Events

   This LFB does not have any events specified.

5.3.4.  IPv6NextHop

   This LFB abstracts the process of RedirectOut LFB.
   Detailed XML definitions selecting IPv6 next hop action.

5.3.4.1.  Data Handling

   The LFB abstracts the process of next hop information application to
   IPv6 packets.  It receives an IPv6 packet with an associated next hop
   ID, and uses the LFB can be found in Section 6.

5.5.  General Purpose LFBs
5.5.1.  BasicMetadataDispatch

   A basic medatata dispatch LFB is defined ID to abstract a process in
   which look up a packet is dispatched next hop table to some path based on its associated
   metadata value. find an
   appropriate output port from the LFB.

   The LFB is with expected to receive unicast IPv6 packets, via a singleton input.  Packets of arbitrary frame types
   can input into the LFB.  Whereas, every
   input packet is required to
   be associated known as "PcktsIn" along with a HopSelector metadata that will be which is
   used by as an index to lookup the LFB NextHop table.

   Two output ports are defined to do
   dispatch.  If output results.

   The first output is a group output port known as "SuccessOut".  On
   successful data processing the packet is not associated with such metadata, the
   packet will be dropped inside sent out an LFB-port from
   within the LFB.

   A LFB port group as selected by the LFBOutputSelectIndex
   value of output the matched table entry.  The packet is defined to output packets according sent to a
   MetaDispatchTable as defined a component in the LFB.  The table
   contains downstream
   LFB alongside with the fields of a metadata ID, a metadata value, L3PortID and an MediaEncapInfoIndex metadata.

   The second output
   port index.  A packet, if it is associated with a metadata with the
   metadata ID, singleton output port known as "ExceptionOut",
   which will be output to packets for which the group port instance data processing failed, along
   with the index
   corresponding to the an additional ExceptionID metadata value in to indicate what caused the table.
   exception.  Currently defined exception types include:

   o  The metadata value
   ussed by the table HopSelector is required with invalid

   o  The MTU for outgoing interface is less than the packet size

   o  ICMP packet needs to be generated

   Downstream neighboring LFB instances could be either a
   BasicMetadataDispatch type, used to fanout to different LFB instances
   or a media encapsulatation related type, such as an interger data EtherEncap type
   or a RedirectOut type.  For example, there are Ethernet and other
   tunnel Encapsulation, then BasicMetadataDispatch can use the L3PortID
   metadata to dispatch packets to different Encapsulator.

5.3.4.2.  Components

   This
   means this LFB currently has only allow a metadata with one component named IPv6NextHopTable which is
   defined as an interger value
   to be used for dispatch.

   Moreover, array.  Each row of the LFB array is a struct containing:

   o  The L3PortID, which is defined with only one metadata adopted for
   dispatch, i.e., the metadata ID in of the dispatch table Logical Output Port that is always
      passed onto the
   same for all table rows.

   A more complex metadata dispatch neighboring LFB may be instance.  This ID indicates what
      port to the neighbor is as defined in future version
   of by L3.

   o  MTU, the library.  In that LFB, multiple tuples of metadata may be
   adopted to dispatch packets.

5.5.2.  GenericScheduler

   There exist various kinds of scheduling strategies with various
   implementations.  As a base LFB library, this document only defines a
   preliminary generic scheduler LFB Maximum Transmission Unit for abstracting a simple scheduling
   process.  The generic scheduler LFB is the one.  Users may use this
   LFB as a basic scheduler outgoing port.

   o  NextHopIPAddr, the IPv6 next hop Address.

   o  MediaEncapInfoIndex, the index we pass onto the neighboring LFB
      instance.  This index is used to lookup a table (typically media
      encapsulatation related) further construct more complex
   scheduler LFBs by means of inheritance as described in RFC 5812
   [RFC5812]. downstream.  The LFB describes scheduling process in the following model:

   o  It CE sets it to a
      value that is with not allocated in downstream LFB tables.  (If a group input and expects packets with arbitrary frame
      types
      downstream LFB lookup fails to arrive for scheduling.  The group input is capable of
      multiple input port instances.  Each port instance find it, it indicates some other
      way to resolve it may be
      connected to different upstream LFB output.  No metadata is
      expected for each input packet. needed.)

   o  Multiple queues reside at  LFBOutputSelectIndex, the input side, with every input LFB Group output port
      instance connected index to one queue.

   o  Every queue is marked with a queue ID, and the queue ID is select
      downstream LFB port.  This index exactly is the same as FromPortIndex for
      the index of corresponding input port instance.

   o  Scheduling disciplines are applied to all queues and also all
      packets group "SuccessOut" in the queues.

   o  Scheduled packets are output from a singleton output port table LFBTopology of FEObject
      LFB as defined for the Nexthop LFB.

   Two

5.3.4.3.  Capabilities

   This LFB components are defined does not have a list of capabilities

5.3.4.4.  Events

   This LFB does not have any events specified.

5.4.  Redirect LFBs

   Redirect LFBs abstract data packets transportation process between CE
   and FE.  Some packets output from some LFBs may have to further describe above model.  A
   scheduling discipline component is defined be delivered
   to CE for further processing, and some packets generated by CE may
   have to specify a
   scheduling discipline be delivered to FE and further to some specific LFBs for data
   path processing.  According to RFC 5810 [RFC5810], data packets and
   their associated metadata are encapsulated in ForCES redirect message
   for transportation between CE and FE.  We define two LFBs to abstract
   the LFB.  Currently defined scheduling
   disciplines only include FIFO process, a RedirectIn LFB and round robin(RR).  For FIFO, we
   limit above model that when a FIFO discipline is applied, it is
   require that there is RedirectOut LFB.  Usually, in an
   LFB topology of an FE, only one input port RedirectIn LFB instance for and one
   RedirectOut LFB instance exist.

5.4.1.  RedirectIn

   RedirectIn LFB abstracts the group
   input.  If user accidentally defines multiple input port instances process for FIFO scheduling, only packets in the input port with lowest port
   index will be scheduled CE to output port, and all inject data
   packets in other
   input port instances will just ignored.

   We specify that if into the generic scheduler FE data path.

5.4.1.1.  Data Handling

   A RedirectIn LFB is defined only one
   input port instance, abstracts the default scheduling discipline is FIFO.  If process for 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 the scheduler.  Using inject data
   packets into the queue ID FE LFB topology so as to input data packets into FE
   data paths.  From LFB topology point of view, the index, CE
   can query every queue RedirectIn LFB acts
   as a source point for its used length in unit of data packets or
   bytes.

   Several capabilities are defined for coming from CE, therefore the LFB.  A queue number limit
   RedirectIn LFB is defined which limits the scheduler maximum supported queue number,
   which is also the maximum number of input port instances.  Capability
   of disciplines supported provides scheduling discipline with only one output, while without any
   input.

   The RedirectIn LFB has only one output defined as a group output
   known as "PktsOut".  Packets produced by this output will have
   arbitrary frame types
   supported decided by the FE CE which generated the packets.
   Possible frames may include IPv4, IPv6, or ARP protocol packets.  The
   CE may associate some metadata to CE.  Queue length limit provides indicate the
   capability of storage ability for every queue.

   More complex scheduler LFB frame types and may be defined
   also associate other metadata to indicate various information on the
   packets.  Among them, there MUST exist a 'RedirectIndex' metadata,
   which is an integer acting as an index.  When the CE transmits the
   metadata along with more complex
   scheduling discipline by succeeding this LFB.  For instance, the packet to a
   priority scheduler LFB may be defined only by inheriting this RedirectIn LFB, the LFB will read
   the RedirectIndex metadata and
   define a component to indicate priorities for all input queues.

   See Section 6 for detailed XML definition for 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 version.
         </synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort>
               <name>EtherPHYIn</name>
               <synopsis>The input port of output the EtherPHYCop LFB. It
               expects any kind packet to one of Ethernet frame.</synopsis>
               <expectation>
                  <frameExpected>
                     <ref>EthernetAll</ref>
                  </frameExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort>
               <name>EtherPHYOut</name>
               <synopsis>The its group
   output port of instance, whose port index is indicated by the EtherPHYCop LFB. It
               can produce any kind of Ethernet frame and along with metadata.

   All metadata from the frame passes CE other than the ID of 'RedirectIndex' metadata will
   output from the Physical Port as RedirectIn LFB along with their binding packets.
   Note that, a packet without a 'RedirectIndex' metadata to associated
   will be used dropped by the next LFBs.</synopsis>
               <product>
                  <frameProduced>
                     <ref>EthernetAll</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>PHYPortID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component componentID="1" access="read-only">
               <name>PHYPortID</name>
               <synopsis>The ID of LFB.

5.4.1.2.  Components

   There are no components defined for the physical port that this current version of RedirectIn
   LFB.

5.4.1.3.  Capabilities

   This LFB
               handles.</synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="2" access="read-write">
               <name>AdminStatus</name>
               <synopsis>Admin status does not have a list of capabilities

5.4.1.4.  Events

   This LFB does not have any events specified.

5.4.2.  RedirectOut

   RedirectOut LFB abstracts the LFB</synopsis>
               <typeRef>PortStatusValues</typeRef>
               <defaultValue>2</defaultValue>
            </component>
            <component componentID="3" access="read-only">
               <name>OperStatus</name>
               <synopsis>Operational status of process for LFBs in the LFB.</synopsis>
               <typeRef>PortStatusValues</typeRef>
            </component>
            <component componentID="4" access="read-write">
               <name>AdminLinkSpeed</name>
               <synopsis>The link speed that FE to deliver
   data packets to the admin has requested.
               </synopsis>
               <typeRef>LANSpeedType</typeRef>
               <defaultValue>0x00000005</defaultValue>
            </component>
            <component componentID="5" access="read-only">
               <name>OperLinkSpeed</name>
               <synopsis>The actual operational link speed.</synopsis>
               <typeRef>LANSpeedType</typeRef>
            </component>
            <component componentID="6" access="read-write">
               <name>AdminDuplexMode</name>
               <synopsis>The duplex mode that CE.

5.4.2.1.  Data Handling

   A RedirectOut LFB abstracts the admin has requested.
               </synopsis>
               <typeRef>DuplexType</typeRef>
               <defaultValue>0x00000001</defaultValue>
            </component>
            <component componentID="7" access="read-only">
               <name>OperDuplexMode</name>
               <synopsis>The actual duplex mode.</synopsis>
               <typeRef>DuplexType</typeRef>
            </component>
            <component componentID="8" access="read-only">
               <name>CarrierStatus</name>
               <synopsis>The status of process for LFBs in the Carrier. Whether FE to deliver
   data packets to the port
               is linked with an operational connector.</synopsis>
               <typeRef>boolean</typeRef>
               <defaultValue>false</defaultValue>
            </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 CE.  From the status LFB's topology point of view, the Physical port is
               changed,the
   RedirectOut LFB sends the new status.</synopsis>
               <eventTarget>
                  <eventField>OperStatus</eventField>
               </eventTarget>
               <eventChanged/>
               <eventReports>
                  <eventReport>
                     <eventField>OperStatus</eventField>
                  </eventReport>
               </eventReports>
            </event>
            <event eventID="2">
               <name>LinkSpeedChanged</name>
               <synopsis>When acts as a sink point for data packets going to the operational speed of
   CE, therefore the link RedirectOut LFB is changed, the defined with only one input,
   while without any output.

   The RedirectOut LFB sends has only one singleton input known as "PktsIn",
   but is capable of receiving packets from multiple LFBs by
   multiplexing this input.  The input expects any kind of frame type
   therefore the new operational link
               speed.</synopsis>
               <eventTarget>
                  <eventField>OperLinkSpeed</eventField>
               </eventTarget>
               <eventChanged/>
               <eventReports>
                  <eventReport>
                     <eventField>OperLinkSpeed</eventField>
                  </eventReport>
               </eventReports>
            </event>
            <event eventID="3">
               <name>DuplexModeChanged</name>
               <synopsis>When frame type has been specified as arbitrary and also all
   types of metadata are expected.  All metadata associated with the operational duplex mode
               is changed,
   input packets will be delivered to CE via the LFB sends ForCES protocol
   redirect message [RFC5810].

5.4.2.2.  Components

   There are no components defined for the new operational mode.

               </synopsis>
               <eventTarget>
                  <eventField>OperDuplexMode</eventField>
               </eventTarget>
               <eventChanged/>
               <eventReports>
                  <eventReport>
                     <eventField>OperDuplexMode</eventField>
                  </eventReport>
               </eventReports>
            </event>
         </events>
      </LFBClassDef>
      <LFBClassDef LFBClassID="4">
         <name>EtherMACIn</name>
         <synopsis>An current version of
   RedirectOut LFB.

5.4.2.3.  Capabilities

   This LFB abstracts an Ethernet port at MAC data link
         layer. It specifically describes Ethernet processing functions
          like MAC address locality check, deciding if does not have a list of capabilities

5.4.2.4.  Events

   This LFB does not have any events specified.

5.5.  General Purpose LFBs

5.5.1.  BasicMetadataDispatch

   A basic medatata dispatch LFB is defined to abstract the Ethernet
         packets should be bridged, provide Ethernet layer flow control,
          etc.Multiple virtual MACs isn't supported process in this
   which a packet is dispatched to some path based on its associated
   metadata value.

5.5.1.1.  Data Handling

   The BasicMetadataDispatch LFB
         version.</synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort group="false">
               <name>EtherMACIn</name>
               <synopsis>The input port of provides 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 function to dispatch input
   packets to a group output port of the EtherMACIn.
               It can produce according to a metadata and a dispatch
   table.

   The BasicMetadataDispatch has only one singleton input known as
   "PktsIn" and expects any kind of Ethernet frame and type, therefore it has been
   specified as arbitrary, along with the frame passes the ID of the Physical Port as a metadata to that will be used by
   the next LFBs.</synopsis>
               <product>
                  <frameProduced>
                     <ref>EthernetAll</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>PHYPortID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
            <outputPort>
               <name>L2BridgingPathOut</name>
               <synopsis>The Bridging Output Port of LFB to do the EtherMACIn.
               It can produce any kind of Ethernet frame and along dispatch.  If a packet is not associated with such
   a metadata, the frame passes packet will be dropped inside the ID of the Physical Port LFB.

   The BasicMetadataDispatch LFB has only one output defined as a group
   output known as "PktsOut".  A packet, if it is associated with a
   metadata to with the metadata ID, will be used by output to the next LFBs.</synopsis>
               <product>
                  <frameProduced>
                     <ref>EthernetAll</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>PHYPortID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component componentID="1" access="read-write">
               <name>AdminStatus</name>
               <synopsis>Admin status of group port
   instance with the port</synopsis>
               <typeRef>PortStatusValues</typeRef>
               <defaultValue>2</defaultValue>
            </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 index corresponding to the LFB doing L2 Bridging?</synopsis>
               <typeRef>boolean</typeRef>
               <defaultValue>false</defaultValue>
            </component>
            <component componentID="4" access="read-write">
               <name>PromiscuousMode</name>
               <synopsis>Is metadata value in the
   Metadata Dispatch table.  Currently the BasicMetadataDispatch only
   allows an interger value for the metadata to be used for dispatch.

   The BasicMetadataDispatch LFB is currently defined with only one
   metadata adopted for dispatch, i.e., the metadata ID in Promiscuous Mode?</synopsis>
               <typeRef>boolean</typeRef>
               <defaultValue>false</defaultValue>
            </component>
            <component componentID="5" access="read-write">
               <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-reset">
               <name>MACInStats</name>
               <synopsis>MACIn statistics</synopsis>
               <typeRef>MACInStatsType</typeRef>
            </component>
         </components>
      </LFBClassDef>
      <LFBClassDef LFBClassID="5">
         <name>EtherClassifier</name>
         <synopsis>This the dispatch
   table is always the same for all table rows.

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

5.5.1.2.  Components

   This LFB has only one component named MetadataDispatchTable which is
   defined as an array.  Each row of the array is a struct containing a
   Metadata ID, a Metadata value and classify the data packets into
          various network layer data packets according OutputIndex to information
           included in selectt the Ethernet packets headers.</synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort>
               <name>EtherPktsIn</name>
               <synopsis>Input port for data packet.</synopsis>
               <expectation>
                  <frameExpected>
                     <ref>EthernetAll</ref>
                  </frameExpected>
                  <metadataExpected>
                     <ref>PHYPortID</ref>
                     <ref dependency="optional" defaultValue="0">
                  LogicalPortID</ref>
                  </metadataExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort group="true">
               <name>ClassifyOut</name>
               <synopsis>Output
   output port for classification.</synopsis>
               <product>
                  <frameProduced>
                     <ref>Arbitrary</ref>

                  </frameProduced>
                  <metadataProduced>
                     <ref>PHYPortID</ref>
                     <ref>SrcMAC</ref>
                     <ref>DstMAC</ref>
                     <ref>EtherType</ref>
                     <ref availability="conditional">VlanID</ref>
                     <ref availability="conditional">VlanPriority</ref>
                  </metadataProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component access="read-write" componentID="1">
               <name>EtherDispatchTable</name>
               <synopsis>Ether classify dispatch table</synopsis>
               <typeRef>EtherDispatchTableType</typeRef>
            </component>
            <component access="read-write" componentID="2">
               <name>VlanInputTable</name>
               <synopsis>Vlan input table</synopsis>
               <typeRef>VlanInputTableType</typeRef>
            </component>
            <component access="read-reset" componentID="3">
               <name>EtherClassifyStats</name>
               <synopsis>Ether classify statistic table</synopsis>
               <typeRef>EtherClassifyStatsTableType</typeRef>
            </component>
         </components>
       </LFBClassDef>
      <LFBClassDef LFBClassID="6">
         <name>EtherEncapsulator</name>
         <synopsis>This LFB abstracts the process to encapsulate IP
         packets to Ethernet packets according to from the L2 information.
         </synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort group="false">
               <name>EncapIn</name>
               <synopsis>A Single Packet Input</synopsis>
               <expectation>
               <frameExpected>
                  <ref>IPv4</ref>
                  <ref>IPv6</ref>
               </frameExpected>
               <metadataExpected>
                  <ref>MediaEncapInfoIndex</ref>
                  <ref dependency="optional" defaultValue="0">
                  VlanPriority</ref>
               </metadataExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort group="false">
               <name>SuccessOut</name>
               <synopsis>Output port for Packets which group.

5.5.1.3.  Capabilities

   This LFB does not have found
               Ethernet L2 information and a list of capabilities

5.5.1.4.  Events

   This LFB does not have been successfully
               encapsulated to an Ethernet packet.</synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv4</ref>
                     <ref>IPv6</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>L2PortID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
            <outputPort group="false">
               <name>ExceptionOut</name>
               <synopsis>All packets that fail any events specified.

5.5.2.  GenericScheduler

   This is a preliminary generic scheduler LFB for abstracting a simple
   scheduling process.

5.5.2.1.  Data Handling

   There exist various kinds of scheduling strategies with the other
               operations in this various
   implementations.  As a base LFB are output via library, this port.
               </synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv4</ref>
                     <ref>IPv6</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>ExceptionID</ref>
                     <ref>MediaEncapInfoIndex</ref>
                     <ref availability="conditional">VlanPriority</ref>
                  </metadataProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component componentID="1" access="read-write">
               <name>EncapTable</name>
               <synopsis>Ethernet Encapsulation table.</synopsis>
               <typeRef>EncapTableType</typeRef>
            </component>
         </components>
      </LFBClassDef>
      <LFBClassDef LFBClassID="7">
         <name>EtherMACOut</name>
         <synopsis>EtherMACOut document only defines a
   preliminary generic scheduler LFB abstracts an Ethernet port at MAC
         data link layer. It specifically describes Ethernet packet
         output for abstracting a simple scheduling
   process. Ethernet output functions are closely related
         to Ethernet input functions, therefore some components
         defined in  Users may use this LFB are actually alias of EtherMACIn LFB.
         </synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort group="false">
               <name>EtherPktsIn</name>
               <synopsis>The Input Port of the EtherMACIn. It expects
               any kind as a basic scheduler LFB to further
   construct more complex scheduler LFBs by means of Ethernet frame.</synopsis>
               <expectation>
                  <frameExpected>
                     <ref>EthernetAll</ref>
                  </frameExpected>
                  <metadataExpected>
                     <ref>PHYPortID</ref>
                  </metadataExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort group="false">
               <name>EtherMACOut</name>
               <synopsis>The Normal Output Port inheritance as
   described in RFC 5812 [RFC5812].

   Packets of the EtherMACOut. It
               can produce any kind of Ethernet arbitrary frame and along type are received via a group input
   known as "PktsIn" with no additional metadata expected.  This group
   input is capable of multiple input port instances.  Each port
   instance may be connected to different upstream LFB output.

   Multiple queues reside at the frame passes input side, with every input port
   instance connected to one queue.  Every queue is marked with a queue
   ID, and the queue ID of is exactly the Physical Port same as
               metadata to be used by the next LFBs.</synopsis>
               <product>
                  <frameProduced>
                     <ref>EthernetAll</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>PHYPortID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component componentID="1" access="read-write">
               <name>AdminStatus</name>
               <synopsis>Admin status index of
   corresponding input port instance.  Scheduling disciplines are
   applied to all queues and also all packets in the port. It is the alias queues.

   Scheduled packets are output from a singleton output port of
               "AdminStatus" component the LFB
   knows as "PktsOut" with no corresponding metadata.

   More complex scheduler LFBs may be defined in EtherMACIn.
               </synopsis>
               <alias>PortStatusValues</alias>
            </component>
            <component componentID="2" access="read-write">
               <name>MTU</name>
               <synopsis>Maximum transmission unit.</synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="3" access="read-write">
               <name>TxFlowControl</name>
               <synopsis>Transmit flow control. It with more complex
   scheduling disciplines by succeeding this LFB.  For instance, a
   priority scheduler LFB may be defined only by inheriting this LFB and
   defining a component to indicate priorities for all input queues.

5.5.2.2.  Components

   The QueueCount component is defined to specify the alias number of
               "TxFlowControl" queues
   to be scheduled.

   The SchedulingDiscipline component defined in EtherMACIn.
               </synopsis>
               <alias>boolean</alias>
            </component>
            <component componentID="4" access="read-write">
               <name>RxFlowControl</name>
               <synopsis>Receive flow control. It is for the alias of
               "RxFlowControl" component CE to specify a
   scheduling discipline to the LFB.  Currently defined in EtherMACIn.
               </synopsis>
               <alias>boolean</alias>
            </component>
            <component componentID="5" access="read-reset">
               <name>MACOutStats</name>
               <synopsis>MACOut statistics</synopsis>
               <typeRef>MACOutStatsType</typeRef>
            </component>
         </components>
      </LFBClassDef>
      <LFBClassDef LFBClassID="8">
         <name>IPv4Validator</name>
         <synopsis>An LFB scheduling
   disciplines only include FIFO and Round Robin (RR).  When a FIFO
   discipline is applied, it is requires that performs IPv4 there is only one input
   port instance for the group input.  If the user accidentally defines
   multiple input port instances for FIFO scheduling, only packets validation
         according to RFC1812. At in
   the same time, ipv4 unicast input port with lowest port index will be scheduled to output
   port, and
         multicast are classified all packets in this LFB.</synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort>
               <name>ValidatePktsIn</name>
               <synopsis>Input other input port for data packet.</synopsis>
               <expectation>
                  <frameExpected>
                     <ref>Arbitrary</ref>
                  </frameExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <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>IPv4</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>ExceptionID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
            <outputPort>
               <name>FailOut</name>
               <synopsis>Output for failed validation packet.
               </synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv4</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>ValidateErrorID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component access="read-write" componentID="1">
               <name>IPv4ValidatorStats</name>
               <synopsis>IPv4 validator statistics information.
               </synopsis>
               <typeRef>IPv4ValidatorStatisticsType</typeRef>
            </component>
         </components>

       </LFBClassDef>
      <LFBClassDef LFBClassID="9">
         <name>IPv6Validator</name>
         <synopsis>An LFB instances will just
   ignored.  Note that performs IPv6 packets validation
         according to RFC2460. At if the same time, ipv6 unicast and
         multicast are classified in this LFB.</synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort>
               <name>ValidatePktsIn</name>
               <synopsis>Input port for data packet.</synopsis>
               <expectation>
                  <frameExpected>
                     <ref>Arbitrary</ref>
                  </frameExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort>
               <name>IPv6UnicastOut</name>
               <synopsis>Output 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>IPv6</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>ExceptionID</ref>
                  </metadataProduced>
               </product>

            </outputPort>
            <outputPort>
               <name>FailOut</name>
               <synopsis>Output for failed validation packet.
               </synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv6</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>ValidateErrorID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component access="read-write" componentID="1">
               <name>IPv6ValidatorStats</name>
               <synopsis>IPv6 validator statistics information.
               </synopsis>
               <typeRef>IPv6ValidatorStatisticsType</typeRef>
            </component>
         </components>
       </LFBClassDef>
      <LFBClassDef LFBClassID="10">
         <name>IPv4UcastLPM </name>
         <synopsis>An generic scheduler LFB that performs IPv4 Longest Prefix Match
         Lookup.It is defined to provide some facilities to support
         users to implement equal-cost multi-path routing(ECMP) or
         reverse path forwarding (RPF).</synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort group="false">
               <name>PktsIn</name>
               <synopsis>A Single Packet Input</synopsis>
               <expectation>
               <frameExpected>
                  <ref>IPv4Unicast</ref>
               </frameExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort group="false">
               <name>NormalOut</name>
               <synopsis>This output only one
   input port instance, the default scheduling discipline is connected FIFO.  If
   the LFB is defined with
               IPv4NextHop LFB</synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv4Unicast</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>HopSelector</ref>
                  </metadataProduced>
               </product>
            </outputPort>
            <outputPort group="false">
               <name>ECMPOut</name>
               <synopsis>This output more than one input port instances, the
   default scheduling discipline is connected with ECMP LFB,
               if there round robin (RR).

   The CurrentQueueDepth component is ECMP LFB in defined to allow CE to query every
   queue status of the FE.</synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv4Unicast</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>HopSelector</ref>
                  </metadataProduced>
               </product>
            </outputPort>
            <outputPort group="false">
               <name>ExceptionOut</name>
               <synopsis>The output scheduler.  It is an array component and each row
   of the array is a struct containing a queue ID, the queue depth in
   packets and the queue depth in bytes.  Using the queue ID as the
   index, the CE can query every queue for its used length in unit of
   packets or bytes.

5.5.2.3.  Capabilities

   Three capabilities are currently defined for the packet if GenericScheduler.

   o  A queue number limit, which specify the limit of the maximum
      supported number of queues, which is also the maximum number of
      input port instances.

   o  The supported scheduling disciplines types by the FE, currently
      maximum 6.

   o  The queue length limit providing the storage ability for every
      queue.

5.5.2.4.  Events

   This LFB does not have any events specified.

6.  XML for LFB Library

<?xml version="1.0" encoding="UTF-8"?>
<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 exception
               occurs</synopsis> Ethernet port abstracted at
         physical layer.It limits its physical media to copper.
         Multiple virtual PHYs isn't supported in this LFB version.
         </synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort>
               <name>EtherPHYIn</name>
               <synopsis>The input port of the EtherPHYCop LFB. It
               expects any kind of Ethernet frame.</synopsis>
               <expectation>
                  <frameExpected>
                     <ref>EthernetAll</ref>
                  </frameExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort>
               <name>EtherPHYOut</name>
               <synopsis>The output port of the EtherPHYCop LFB. 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>IPv4Unicast</ref>
                     <ref>EthernetAll</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>ExceptionID</ref>
                     <ref>PHYPortID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component componentID="1" access="read-write">
               <name>IPv4PrefixTable</name> access="read-only">
               <name>PHYPortID</name>
               <synopsis>The IPv4 prefix table.</synopsis>
               <typeRef>IPv4PrefixTableType</typeRef> ID of the physical port that this LFB
               handles.</synopsis>
               <typeRef>uint32</typeRef>
            </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="11">
         <name>IPv6UcastLPM </name>
         <synopsis>An LFB that performs IPv6 Longest Prefix Match
         Lookup.It is defined to provide some facilities to support
         users to implement equal-cost multi-path routing(ECMP) or
         reverse path forwarding (RPF).</synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort group="false">
               <name>PktsIn</name>
               <synopsis>A Single Packet Input</synopsis>
               <expectation>
               <frameExpected>
                  <ref>IPv6Unicast</ref>
               </frameExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort group="false">
               <name>NormalOut</name>
               <synopsis>This output port is connected with
               IPv6NextHop access="read-write">
               <name>AdminStatus</name>
               <synopsis>Admin status of the 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
               <typeRef>PortStatusValues</typeRef>
               <defaultValue>2</defaultValue>
            </component>
            <component componentID="3" access="read-only">
               <name>OperStatus</name>
               <synopsis>Operational status of the FE.</synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv6Unicast</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>HopSelector</ref>
                  </metadataProduced>
               </product>
            </outputPort>
            <outputPort group="false">
               <name>ExceptionOut</name> LFB.</synopsis>
               <typeRef>PortStatusValues</typeRef>
            </component>
            <component componentID="4" access="read-write">
               <name>AdminLinkSpeed</name>
               <synopsis>The output for link speed that the packet if an exception
               occurs</synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv6Unicast</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>ExceptionID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components> admin has requested.
               </synopsis>
               <typeRef>LANSpeedType</typeRef>
               <defaultValue>0x00000005</defaultValue>
            </component>
            <component componentID="1" componentID="5" access="read-only">
               <name>OperLinkSpeed</name>
               <synopsis>The actual operational link speed.</synopsis>
               <typeRef>LANSpeedType</typeRef>
            </component>
            <component componentID="6" access="read-write">
               <name>IPv6PrefixTable</name>
               <name>AdminDuplexMode</name>
               <synopsis>The IPv6 prefix table.</synopsis>
               <typeRef>IPv6PrefixTableType</typeRef> duplex mode that the admin has requested.
               </synopsis>
               <typeRef>DuplexType</typeRef>
               <defaultValue>0x00000001</defaultValue>
            </component>
            <component componentID="2" access="read-reset">
               <name>IPv6UcastLPMStats</name>
               <synopsis>Statistics for IPv6 Unicast Longest Prefix
               Match</synopsis>
               <typeRef>IPv6UcastLPMStatsType</typeRef> componentID="7" access="read-only">
               <name>OperDuplexMode</name>
               <synopsis>The actual duplex mode.</synopsis>
               <typeRef>DuplexType</typeRef>
            </component>
         </components>
      </LFBClassDef>
      <LFBClassDef LFBClassID="12">
         <name>IPv4NextHop</name>
         <synopsis>This LFB abstracts the process
            <component componentID="8" access="read-only">
               <name>CarrierStatus</name>
               <synopsis>The status of selecting ipv4
         next hop action. It receives an IPv4 packet the Carrier. Whether the port
               is linked with an
         associated next hop ID, and uses the ID to look up a next
         hop table to find an appropriate output operational connector.</synopsis>
               <typeRef>boolean</typeRef>
               <defaultValue>false</defaultValue>
            </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 from is
               changed,the LFB sends the LFB. new status.</synopsis>
               <eventTarget>
                  <eventField>OperStatus</eventField>
               </eventTarget>
               <eventChanged/>
               <eventReports>
                  <eventReport>
                     <eventField>OperStatus</eventField>
                  </eventReport>
               </eventReports>
            </event>
            <event eventID="2">
               <name>LinkSpeedChanged</name>
               <synopsis>When the operational speed of the link
               is changed, the LFB sends the new operational link
               speed.</synopsis>
               <eventTarget>
                  <eventField>OperLinkSpeed</eventField>
               </eventTarget>
               <eventChanged/>
               <eventReports>
                  <eventReport>
                     <eventField>OperLinkSpeed</eventField>
                  </eventReport>
               </eventReports>
            </event>
            <event eventID="3">
               <name>DuplexModeChanged</name>
               <synopsis>When the operational duplex mode
               is changed, the LFB sends the new operational mode.
               </synopsis>
               <eventTarget>
                  <eventField>OperDuplexMode</eventField>
               </eventTarget>
               <eventChanged/>
               <eventReports>
                  <eventReport>
                     <eventField>OperDuplexMode</eventField>
                  </eventReport>
               </eventReports>
            </event>
         </events>
      </LFBClassDef>
      <LFBClassDef LFBClassID="4">
         <name>EtherMACIn</name>
         <synopsis>An 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.Multiple virtual MACs isn't supported in this LFB
         version.</synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort group="false">
               <name>PktsIn</name>
               <synopsis>A Single Packet Input</synopsis>
               <name>EtherMACIn</name>
               <synopsis>The input port of the EtherMACIn. It
               expects any kind of Ethernet frame.</synopsis>
               <expectation>
                  <frameExpected>
                  <ref>IPv4Unicast</ref>
                     <ref>EthernetAll</ref>
                  </frameExpected>
                  <metadataExpected>
                  <ref>HopSelector</ref>
                     <ref>PHYPortID</ref>
                  </metadataExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort group="true">
               <name>SuccessOut</name> group="false">
               <name>NormalPathOut</name>
               <synopsis>The normal output for port of the packet if it is valid 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
               forwarded</synopsis> used by the next LFBs.</synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv4Unicast</ref>
                     <ref>EthernetAll</ref>

                  </frameProduced>
                  <metadataProduced>
                     <ref>OutputLogicalPortID</ref>
                     <ref>NextHopIPv4Addr</ref>
                     <ref>PHYPortID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
            <outputPort group="false">
               <name>ExceptionOut</name>
            <outputPort>
               <name>L2BridgingPathOut</name>
               <synopsis>The output for Bridging Output Port of the packet if an exception
               occurs</synopsis>
               <product> 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>IPv4Unicast</ref>
                     <ref>EthernetAll</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>ExceptionID</ref>
                     <ref>PHYPortID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component componentID="1">
               <name>IPv4NextHopTable</name>
               <synopsis>The next hop table.</synopsis>
               <typeRef>IPv4NextHopTableType</typeRef> componentID="1" access="read-write">
               <name>AdminStatus</name>
               <synopsis>Admin status of the port</synopsis>
               <typeRef>PortStatusValues</typeRef>
               <defaultValue>2</defaultValue>
            </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-write">
               <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-reset">
               <name>MACInStats</name>
               <synopsis>MACIn statistics</synopsis>
               <typeRef>MACInStatsType</typeRef>
            </component>
         </components>
      </LFBClassDef>
      <LFBClassDef LFBClassID="13">
         <name>IPv6NextHop</name>
         <synopsis>The LFBClassID="5">
         <name>EtherClassifier</name>
         <synopsis>This LFB abstracts the process of next hop
         information application to IPv6 packets. It receives an IPv4
         packet with an associated next hop ID, decapsulate
          Ethernet packets and uses classify the ID to
         look up a next hop table data packets into
          various network layer data packets according to find an appropriate output port
         from information
           included in the LFB..</synopsis> Ethernet packets headers.</synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort group="false">
               <name>PktsIn</name>
               <synopsis>A single packet input.</synopsis>
            <inputPort>
               <name>EtherPktsIn</name>
               <synopsis>Input port for data packet.</synopsis>
               <expectation>
                  <frameExpected>
                  <ref>IPv6Unicast</ref>
                     <ref>EthernetAll</ref>
                  </frameExpected>
                  <metadataExpected>
                  <ref>HopSelector</ref>
                     <ref>PHYPortID</ref>
                     <ref dependency="optional" defaultValue="0">
                  LogicalPortID</ref>
                  </metadataExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort group="true">
               <name>SuccessOut</name>
               <synopsis>The output for the packet 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
               <name>ClassifyOut</name>
               <synopsis>Output port for the packet if an exception
               occurs</synopsis> classification.</synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv6Unicast</ref>
                     <ref>Arbitrary</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>ExceptionID</ref>
                     <ref>PHYPortID</ref>
                     <ref>SrcMAC</ref>
                     <ref>DstMAC</ref>
                     <ref>EtherType</ref>
                     <ref availability="conditional">VlanID</ref>
                     <ref availability="conditional">VlanPriority</ref>
                  </metadataProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component access="read-write" componentID="1">
               <name>IPv6NextHopTable</name>
               <synopsis>The next hop table.</synopsis>
               <typeRef>IPv6NextHopTableType</typeRef>
            </component>
         </components>
      </LFBClassDef>
      <LFBClassDef LFBClassID="14">
         <name>RedirectIn</name>
         <synopsis>The RedirectIn LFB abstracts the process for CE to
         inject data packets into FE LFB topology, so as to
               <name>EtherDispatchTable</name>
               <synopsis>Ether classify dispatch table</synopsis>
               <typeRef>EtherDispatchTableType</typeRef>
            </component>
            <component access="read-write" componentID="2">
               <name>VlanInputTable</name>
               <synopsis>Vlan input data
          packets into FE data paths. CE may associate some
         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 output port index.
         </synopsis>
         <version>1.0</version>
         <outputPorts>
            <outputPort group="true">
               <name>PktsOut</name>
               <synopsis>This output group sends the redirected packet
                in the data path.</synopsis>
               <product>
                  <frameProduced>
                     <ref>Arbitrary</ref>
                  </frameProduced>
               </product>
            </outputPort>
         </outputPorts> table</synopsis>
               <typeRef>VlanInputTableType</typeRef>
            </component>
            <component access="read-reset" componentID="3">
               <name>EtherClassifyStats</name>
               <synopsis>Ether classify statistic table</synopsis>
               <typeRef>EtherClassifyStatsTableType</typeRef>
            </component>
         </components>
       </LFBClassDef>
      <LFBClassDef LFBClassID="15">
         <name>RedirectOut</name>
         <synopsis>The LFBClassID="6">
         <name>EtherEncap</name>
         <synopsis>This LFB abstracts the process for LFBs in
         FE to deliver data encapsulate IP
         packets to CE. All metadata
         associated with the input Ethernet packets will be delivered according to CE
         via the redirect message of ForCES protocol [RFC5810]. L2 information.
         </synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort group="false">
               <name>PktsIn</name>
               <synopsis>This input receives packets to send to
               the CE.</synopsis>
               <expectation>
                  <frameExpected>
                     <ref>Arbitrary</ref>
                  </frameExpected>
               </expectation>
            </inputPort>
         </inputPorts>
      </LFBClassDef>
      <LFBClassDef LFBClassID="16">
         <name>BasicMetadataDispatch</name>
         <synopsis>This LFB provides the function to dispatch input
         packets to a group output according to a metadata and a
         dispatch table.This LFB currently only allow a metadata with
          an interger value to be used for dispatch. </synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort>
               <name>PktsIn</name>
               <synopsis>Input port for data packet.</synopsis>
               <name>EncapIn</name>
               <synopsis>A Single Packet Input</synopsis>
               <expectation>
               <frameExpected>
                     <ref>Arbitrary</ref>
                  <ref>IPv4</ref>
                  <ref>IPv6</ref>
               </frameExpected>
               <metadataExpected>
                     <ref>Arbitrary</ref>
                  <ref>MediaEncapInfoIndex</ref>
                  <ref dependency="optional" defaultValue="0">
                  VlanPriority</ref>
               </metadataExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort group="true">
               <name>PktsOut</name>
               <synopsis>Data packet output</synopsis> group="false">
               <name>SuccessOut</name>
               <synopsis>Output port for Packets which have found
               Ethernet L2 information and have been successfully
               encapsulated to an Ethernet packet.</synopsis>
               <product>
                  <frameProduced>
                     <ref>Arbitrary</ref>
                     <ref>IPv4</ref>
                     <ref>IPv6</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>L2PortID</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>MediaEncapInfoIndex</ref>
                     <ref availability="conditional">VlanPriority</ref>
                  </metadataProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component access="read-write" componentID="1">
               <name>MetadataDispatchTable</name>
               <synopsis>Metadata dispatch componentID="1" access="read-write">
               <name>EncapTable</name>
               <synopsis>Ethernet Encapsulation table.</synopsis>
               <typeRef>MetadataDispatchTableType</typeRef>
               <typeRef>EncapTableType</typeRef>
            </component>
         </components>
      </LFBClassDef>
      <LFBClassDef LFBClassID="17">
         <name>GenericScheduler</name>
         <synopsis>This is a preliminary generic scheduler LFBClassID="7">
         <name>EtherMACOut</name>
         <synopsis>EtherMACOut LFB for
         abstracting a simple scheduling process.Users may use 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 some components
         defined in this LFB as a basic scheduler LFB to further construct more
          complex scheduler LFBs by means are actually alias of inheritance as described
           in RFC 5812.</synopsis> EtherMACIn LFB.
         </synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort group="true">
               <name>PktsIn</name>
               <synopsis>Input port for data packet.</synopsis> group="false">
               <name>EtherPktsIn</name>
               <synopsis>The Input Port of the EtherMACIn. It expects
               any kind of Ethernet frame.</synopsis>
               <expectation>
                  <frameExpected>
                     <ref>Arbitrary</ref>
                     <ref>EthernetAll</ref>
                  </frameExpected>
                  <metadataExpected>
                     <ref>PHYPortID</ref>
                  </metadataExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort>
               <name>PktsOut</name>
               <synopsis>Data packet output.</synopsis>
            <outputPort group="false">
               <name>EtherMACOut</name>
               <synopsis>The Normal Output Port of the 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>Arbitrary</ref>
                     <ref>EthernetAll</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>PHYPortID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component access="read-only" componentID="1">
               <name>QueueCount</name>
               <synopsis>The number componentID="1" access="read-write">
               <name>AdminStatus</name>
               <synopsis>Admin status of queues to be scheduled. the port. It is the alias of
               "AdminStatus" component defined in EtherMACIn.
               </synopsis>
               <typeRef>uint32</typeRef>
               <alias>PortStatusValues</alias>

            </component>
            <component access="read-write" componentID="2">
               <name>SchedulingDiscipline</name>
               <synopsis>the Scheduler discipline.</synopsis>
               <typeRef>SchdDisciplineType</typeRef> componentID="2" access="read-write">
               <name>MTU</name>
               <synopsis>Maximum transmission unit.</synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component access="read-only" componentID="3">
               <name>CurrentQueueDepth</name>
               <synopsis>Current Depth of all queues</synopsis>
               <typeRef>QueueDepthTableType</typeRef>
            </component>
         </components>
         <capabilities>
            <capability componentID="30">
               <name>QueueLenLimit</name>
               <synopsis>Maximum length componentID="3" access="read-write">
               <name>TxFlowControl</name>
               <synopsis>Transmit flow control. It is the alias of each queue,the unit
               "TxFlowControl" component defined in EtherMACIn.
               </synopsis>
               <alias>boolean</alias>
            </component>
            <component componentID="4" access="read-write">
               <name>RxFlowControl</name>
               <synopsis>Receive flow control. It is
               byte.</synopsis>
               <typeRef>uint32</typeRef>
            </capability>
            <capability componentID="31">
               <name>QueueScheduledLimit</name>
               <synopsis>Max number the alias of queues
               "RxFlowControl" component defined in EtherMACIn.
               </synopsis>
               <alias>boolean</alias>
            </component>
            <component componentID="5" access="read-reset">
               <name>MACOutStats</name>
               <synopsis>MACOut statistics</synopsis>
               <typeRef>MACOutStatsType</typeRef>
            </component>
         </components>
      </LFBClassDef>
      <LFBClassDef LFBClassID="8">
         <name>IPv4Validator</name>
         <synopsis>An LFB that can be scheduled
                by performs IPv4 packets validation
         according to RFC1812. At the same time, ipv4 unicast and
         multicast are classified in this scheduluer.</synopsis>
               <typeRef>uint32</typeRef>

            </capability>
            <capability componentID="32">
               <name>DisciplinesSupported</name>
               <synopsis>the scheduling disciplines supported. LFB.</synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort>
               <name>ValidatePktsIn</name>
               <synopsis>Input port for data packet.</synopsis>
               <expectation>
                  <frameExpected>
                     <ref>Arbitrary</ref>
                  </frameExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <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>IPv4</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>ExceptionID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
            <outputPort>
               <name>FailOut</name>
               <synopsis>Output for failed validation packet.
               </synopsis>
               <array type="variable-size" maxLength="6">
                  <typeRef>SchdDisciplineType</typeRef>
               </array>
            </capability>
         </capabilities>
               <product>
                  <frameProduced>
                     <ref>IPv4</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>ValidateErrorID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component access="read-write" componentID="1">
               <name>IPv4ValidatorStats</name>
               <synopsis>IPv4 validator statistics information.
               </synopsis>
               <typeRef>IPv4ValidatorStatsType</typeRef>
            </component>

         </components>
       </LFBClassDef>
   </LFBClassDefs>
</LFBLibrary>
7.
      <LFBClassDef LFBClassID="9">
         <name>IPv6Validator</name>
         <synopsis>An LFB Class Use Cases

   This section demonstrates examples on how that performs IPv6 packets validation
         according to RFC2460. At the LFB classes defined by same time, ipv6 unicast and
         multicast are classified in this LFB.</synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort>
               <name>ValidatePktsIn</name>
               <synopsis>Input port for data packet.</synopsis>
               <expectation>
                  <frameExpected>
                     <ref>Arbitrary</ref>
                  </frameExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort>
               <name>IPv6UnicastOut</name>
               <synopsis>Output 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>IPv6</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>ExceptionID</ref>
                  </metadataProduced>

               </product>
            </outputPort>
            <outputPort>
               <name>FailOut</name>
               <synopsis>Output for failed validation packet.
               </synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv6</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>ValidateErrorID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component access="read-write" componentID="1">
               <name>IPv6ValidatorStats</name>
               <synopsis>IPv6 validator statistics information.
               </synopsis>
               <typeRef>IPv6ValidatorStatsType</typeRef>
            </component>
         </components>
       </LFBClassDef>
      <LFBClassDef LFBClassID="10">
         <name>IPv4UcastLPM </name>
         <synopsis>An LFB that performs IPv4 Longest Prefix Match
         Lookup.It is defined to provide some facilities to support
         users to implement equal-cost multi-path routing(ECMP) or
         reverse path forwarding (RPF).</synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort group="false">
               <name>PktsIn</name>
               <synopsis>A Single Packet Input</synopsis>
               <expectation>
               <frameExpected>
                  <ref>IPv4Unicast</ref>
               </frameExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort group="false">
               <name>NormalOut</name>
               <synopsis>This output port is connected with
               IPv4NextHop 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 FE.</synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv4Unicast</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>HopSelector</ref>
                  </metadataProduced>
               </product>
            </outputPort>
            <outputPort group="false">
               <name>ExceptionOut</name>
               <synopsis>The output for the packet if an exception
               occurs</synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv4Unicast</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>ExceptionID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component componentID="1" access="read-write">
               <name>IPv4PrefixTable</name>
               <synopsis>The IPv4 prefix table.</synopsis>
               <typeRef>IPv4PrefixTableType</typeRef>
            </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="11">
         <name>IPv6UcastLPM </name>
         <synopsis>An LFB that performs IPv6 Longest Prefix Match
         Lookup.It is defined to provide some facilities to support
         users to implement equal-cost multi-path routing(ECMP) or
         reverse path forwarding (RPF).</synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort group="false">
               <name>PktsIn</name>
               <synopsis>A Single Packet Input</synopsis>
               <expectation>
               <frameExpected>
                  <ref>IPv6Unicast</ref>
               </frameExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort group="false">
               <name>NormalOut</name>
               <synopsis>This output port is connected with
               IPv6NextHop 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 FE.</synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv6Unicast</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>HopSelector</ref>
                  </metadataProduced>
               </product>
            </outputPort>
            <outputPort group="false">
               <name>ExceptionOut</name>
               <synopsis>The output for the packet if an exception
               occurs</synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv6Unicast</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>ExceptionID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component componentID="1" access="read-write">
               <name>IPv6PrefixTable</name>
               <synopsis>The IPv6 prefix table.</synopsis>
               <typeRef>IPv6PrefixTableType</typeRef>
            </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="12">
         <name>IPv4NextHop</name>
         <synopsis>This LFB abstracts the process of selecting ipv4
         next hop action. It receives an IPv4 packet with an
         associated next hop ID, and uses the ID to look up a next
         hop table to find an appropriate output port from the LFB.
         </synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort group="false">
               <name>PktsIn</name>
               <synopsis>A Single Packet Input</synopsis>
               <expectation>
               <frameExpected>
                  <ref>IPv4Unicast</ref>
               </frameExpected>
               <metadataExpected>
                  <ref>HopSelector</ref>
               </metadataExpected>
               </expectation>
            </inputPort>

         </inputPorts>
         <outputPorts>
            <outputPort group="true">
               <name>SuccessOut</name>
               <synopsis>The output for the packet if it is valid to be
               forwarded</synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv4Unicast</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>L3PortID</ref>
                     <ref>NextHopIPv4Addr</ref>
                     <ref availability="conditional">
                     MediaEncapInfoIndex</ref>
                  </metadataProduced>
               </product>
            </outputPort>
            <outputPort group="false">
               <name>ExceptionOut</name>
               <synopsis>The output for the packet if an exception
               occurs</synopsis>
               <product>
                  <frameProduced>
                     <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>
               <typeRef>IPv4NextHopTableType</typeRef>
            </component>
         </components>
      </LFBClassDef>
      <LFBClassDef LFBClassID="13">
         <name>IPv6NextHop</name>
         <synopsis>The LFB abstracts the process of next hop
         information application to IPv6 packets. It receives an IPv4
         packet with an associated next hop ID, and uses the ID to
         look up a next hop table to find an appropriate output port
         from the LFB..</synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort group="false">
               <name>PktsIn</name>
               <synopsis>A single packet input.</synopsis>
               <expectation>
               <frameExpected>
                  <ref>IPv6Unicast</ref>
               </frameExpected>
               <metadataExpected>
                  <ref>HopSelector</ref>
               </metadataExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort group="true">
               <name>SuccessOut</name>
               <synopsis>The output for the packet if it is valid to
               be forwarded</synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv6Unicast</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>L3PortID</ref>
                     <ref>NextHopIPv6Addr</ref>
                     <ref availability="conditional">
                     MediaEncapInfoIndex</ref>
                  </metadataProduced>
               </product>
            </outputPort>
            <outputPort group="false">
               <name>ExceptionOut</name>
               <synopsis>The output for the packet if an exception
               occurs</synopsis>
               <product>
                  <frameProduced>
                     <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>
               <typeRef>IPv6NextHopTableType</typeRef>
            </component>
         </components>
      </LFBClassDef>
      <LFBClassDef LFBClassID="14">
         <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. CE may associate some
         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 output port index.
         </synopsis>
         <version>1.0</version>
         <outputPorts>
            <outputPort group="true">
               <name>PktsOut</name>
               <synopsis>This output group sends the redirected packet
                in the data path.</synopsis>
               <product>
                  <frameProduced>
                     <ref>Arbitrary</ref>
                  </frameProduced>
               </product>
            </outputPort>
         </outputPorts>
      </LFBClassDef>
      <LFBClassDef LFBClassID="15">
         <name>RedirectOut</name>
         <synopsis>The LFB abstracts the process for LFBs in
         FE to deliver data packets to CE. All metadata
         associated with the input packets will be delivered to CE
         via the redirect message of ForCES protocol [RFC5810].
         </synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort group="false">
               <name>PktsIn</name>
               <synopsis>This input receives packets to send to
               the CE.</synopsis>
               <expectation>
                  <frameExpected>
                     <ref>Arbitrary</ref>
                  </frameExpected>
               </expectation>
            </inputPort>
         </inputPorts>

      </LFBClassDef>
      <LFBClassDef LFBClassID="16">
         <name>BasicMetadataDispatch</name>
         <synopsis>This LFB provides the function to dispatch input
         packets to a group output according to a metadata and a
         dispatch table.This LFB currently only allow a metadata with
          an interger value to be used for dispatch. </synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort>
               <name>PktsIn</name>
               <synopsis>Input port for data packet.</synopsis>
               <expectation>
                  <frameExpected>
                     <ref>Arbitrary</ref>
                  </frameExpected>
                  <metadataExpected>
                     <ref>Arbitrary</ref>
                  </metadataExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort group="true">
               <name>PktsOut</name>
               <synopsis>Data packet output</synopsis>
               <product>
                  <frameProduced>
                     <ref>Arbitrary</ref>
                  </frameProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component access="read-write" componentID="1">
               <name>MetadataDispatchTable</name>
               <synopsis>Metadata dispatch table.</synopsis>
               <typeRef>MetadataDispatchTableType</typeRef>
            </component>
         </components>
       </LFBClassDef>
      <LFBClassDef LFBClassID="17">
         <name>GenericScheduler</name>
         <synopsis>This is a preliminary generic scheduler LFB for
         abstracting a simple scheduling process.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.</synopsis>

         <version>1.0</version>
         <inputPorts>
            <inputPort group="true">
               <name>PktsIn</name>
               <synopsis>Input port for data packet.</synopsis>
               <expectation>
                  <frameExpected>
                     <ref>Arbitrary</ref>
                  </frameExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort>
               <name>PktsOut</name>
               <synopsis>Data packet output.</synopsis>
               <product>
                  <frameProduced>
                     <ref>Arbitrary</ref>
                  </frameProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component access="read-only" componentID="1">
               <name>QueueCount</name>
               <synopsis>The number of queues to be 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 all queues</synopsis>
               <typeRef>QueueDepthTableType</typeRef>
            </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 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.  LFB Class Use Cases

   This section demonstrates examples on how the LFB classes defined by
   the Base LFB library in Section 6 are applied to achieve some typical
   router functions.  The functions to demonstrate are:

   o  IPv4 forwarding

   o  ARP processing

   To achieve the functions, processing paths organized by the LFB
   classes with their interconnections should be established in FE.  In
   general, CE controls and manages the processing paths by use of the
   ForCES protocol.

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

7.1.  IPv4 Forwarding

   Figure 1 (Section 3.2.3) shows a normal IPv4 forwarding processing
   path by use of the base LFB classes.  To make it in focus, LFB
   classes that are not close to IPv4 forwarding function are ignored in
   the figure.  Moreover, inputs or outputs of some LFBs that are not
   related to IP forwarding are also ignored in the LFB figure.

   In the example case, network interfaces are limited to copper
   Ethernet ports.  A number of EtherPHYCop LFBs are used to describe
   physical layer functions of the ports.  An EtherMACIn LFB follows
   every EtherPHYCop LFB to describe the MAC layer processing.  A
   PHYPortID metadatum is generated by EtherPHYCop LFB and will be used
   by all the following LFBs.  In EtherMACIn LFB, a locality check of
   MAC addresses may be performed if CE asks to do so by configuring the
   LFB component.

   Ethernet packets out of the EtherMACIn LFB are sent to an
   EtherClassifier LFB to be decapsulated and classified into network
   layer types like IPv4, IPv6, ARP, etc.  In the example case, every
   physical Ethernet interface is associated with one Classifier
   instance, whereas it is also practical that all physical interfaces
   are associated with only one Ethernet Classifier instance.
   EtherClassifier will use PHYPortID and Ethernet type of the input
   packet and VlanID, if exists in the input Ethernet packets, to decide
   the packet network layer type and its output port from this LFB, and
   also to assign a new logical port ID to the packet for later use.  At
   the same time, the LFB also generate some new metadata for every
   packet like EtherType, SrcMAC, DstMAC, LogicPortID, etc for later
   LFBs to use.

   If a packet is classified as an IPv4 packet, it will be sent to an
   IPv4Validator LFB to validate the IPv4 packet.  In the validator LFB,
   IPv4 packets will be classified into IPv4 unicast packets and
   multicast packets, as well as validating the IPv4 packets.

   IPv4 unicast packets will be sent to IPv4UcastLPM LFB, where LPM is
   made and a next hop ID is achieved.  The packet with the next hop ID
   is further sent to an IPv4NextHop LFB, where further next hop
   information is found for this packet.  The information includes where
   the packet is to go next and even the media encapsulation type for
   the port, etc.  An L3PortID is used to identify a next hop output
   port, which is represented as a metadatum associated with the packet
   to be forwarded to via port.  In the example case, the next hop
   output port is an Ethernet type.  As a result, the packet and its L3
   port ID metadatum are sent to an EtherEncap LFB, where the packet is
   encapsulated as an Ethernet packet.  A BasicMetadataDispatch LFB
   follows the EtherEncap LFB where packets will be dispatched to
   different output port according to the L3PortID metadatum sent to the
   LFB.  As a result, IPv4 packets are forwarded out via various output
   ports.

7.2.  ARP processing

   Figure 2 shows the processing path for ARP protocol in the case that
   there is no specific ARP processing LFBs in FE.  In such case, CE
   should implement the ARP processing function.  As usual, to make it
   in focus, the figure ignores LFB classes that are not related to ARP
   processing.  The figure also ignores some inputs or outputs of LFBs
   that are out of the scope of ARP processing.

   The example case still takes Ethernet ports as its network
   interfaces.

          +---+                             +---+
          |   | ARP packets                 |   |
          |   |------------------------+--->|   | To CE
    ...-->|   | .                      |    |   |
          |   | .                      |    +---+
          |   | .                      |   RedirectOut
          +---+                        |
          Ether     EtherEncap         | IPv4 packets lack
        Classifier   +---+             | address resolution information
                     |   |             |
       Packets need  |   |--------->---+
        ...--------->|   |
     L2 Encapsulation|   |
          +---+      |   |                     +------+
          |   |  +-->|   |--+   +---+          |Ether |
          |   |  |   +---+  |   |   |--------->|MACOut|-->...
   From CE|   |--+          +-->|   | .        +------+
          |   |ARP Packets      |   | .
          |   |from CE          |   | .        +------+
          |   |                 |   |--------> |Ether |-->...
          +---+                 +---+          |MACOut|
       RedirectIn            BasicMetadata     +------+
                             Dispatch

                      Figure 2: LFB use case for ARP

   As the figure shows, ARP protocol packets from network interfaces can
   be filtered out by EtherClassifier LFB.  In the example case, we
   presume the FE does not provide ability for ARP processing and relies
   on CE to do the work.  Hence, the classified ARP packets and some
   associated metadata are then sent to RedirectOut LFB so as to be
   transported to CE.  CE can then process the received APR packets to
   get information to establish ARP tables.  While it depends on
   individual implementations how this is implemented and is out of the
   scope of ForCES

   When CE deploys ARP function, it may need to generate ARP request or
   response packets and send them back to outer networks.  To do so, the
   packets are redirected to FE through a RedirectIn LFB first.  Then,
   just like to forward IPv4 packets, the ARP packets are also
   encapsulated to Ethernet format by an EtherEncap LFB, and then
   dispatched to different interfaces via a BasicMetadataDispatch LFB.
   The BasicMetadataDispatch LFB will dispatch the packets according to
   the L3PortID metadatum included in every ARP packet sent from CE.

   The EtherEncap LFB also receives packets that need Ethernet L2
   encapsulating.  If the encapsulator finds that it can not fulfill
   encapsulating some packets because of lack of L2 Ethernet information
   for the packets, the LFB will output the packets from the
   ExceptionOut output of the LFB.  By connecting this output to
   RedirectOut LFB, the packets can be redirected to CE for further ARP
   processing.  See Section 5.1.4 for details.  CE may then generate ARP
   requests based on the packets, and redirect ARP request messages to
   FE to send to networks, just as the procedure shown above.

   With these mechanisms and procedures, ARP function is expected to be
   implemented by CE with the help from FE.

8.  Contributors

   The authors would like to thank Jamal Hadi Salim, Ligang Dong, and
   Fenggen Jia who made major contributions 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

      Fenggen Jia
      National Digital Switching Center(NDSC)
      Jianxue Road
      Zhengzhou 452000
      P.R.China
      EMail: jfg@mail.ndsc.com.cn

9.  Acknowledgements

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

10.  IANA Considerations

   IANA has created a registry of ForCES LFB Class Names and the
   corresponding ForCES LFB Class Identifiers, with the location of the
   definition of the ForCES LFB Class, in accordance with the rules to
   use the namespace.

   The LFB library in this document needs for unique class names and
   numeric class identifiers of all LFBs.  Besides, this document also
   needs to define the following namespaces:

   o  Metadata ID, defined in Section 4.3 and Section 4.4

   o  Exception ID, defined in Section 4.4

   o  Validate Error ID, defined in Section 4.4

10.1.  LFB Class Names and LFB Class Identifiers

   LFB classes defined by this document belongs to IETF defined LFBs by
   Standard Track RFCs.  According to IANA, the identifier namespace for
   these LFB classes is from 3 to 65535.

   The assignment of LFB class names and LFB class identifiers is as in
   the following table.

   +-----------+---------------+------------------------+--------------+
   | LFB Class | LFB Class Name|     Description        |  Reference   |
   | Identifier|               |                        |              |
   +-----------+---------------+------------------------+--------------+
   |     3     |  EtherPHYCop  | Define an Ethernet port|  RFC????(this|
   |           |               | abstracted at physical | document)    |
   |           |               | layer                  | Section 5.1.1|
   |           |               |    --------------      |              |
   |     4     |  EtherMACIn   | Define an Ethernet     |   RFC????    |
   |           |               | input port at MAC data | Section 5.1.2|
   |           |               | link layer             |              |
   |           |               |    --------------      |              |
   |     5     |EtherClassifier| Define the process to  |   RFC????    |
   |           |               | decapsulate Ethernet   | Section 5.1.3|
   |           |               | packets and classify   |              |
   |           |               | the packets            |              |
   |           |               |    --------------      |              |
   |     6     |  EtherEncap   | Define the process to  |   RFC????    |
   |           |               | encapsulate IP packets | Section 5.1.4|
   |           |               | to Ethernet packets    |              |
   |           |               |    --------------      |              |
   |     7     |  EtherMACOut  | Define an Ethernet     |  RFC ????    |
   |           |               | output port at MAC     | Section 5.1.5|
   |           |               | data link layer        |              |
   |           |               |    --------------      |              |
   |     8     | IPv4Validator | Perform IPv4 packets   |   RFC ????   |
   |           |               | validation.            | Section 5.2.1|
   |           |               |    --------------      |              |
   |     9     | IPv6Validator | Perform IPv6 packets   |   RFC ????   |
   |           |               | validation             | Section 5.2.2|
   |           |               |    --------------      |              |
   |     10    | IPv4UcastLPM  | Perform IPv4 Longest   |   RFC ????   |
   |           |               | Prefix Match Lookup    | Section 5.3.1|
   |           |               |    --------------      |              |
   |     11    | IPv6UcastLPM  | Perform IPv6 Longest   |   RFC ????   |
   |           |               | Prefix Match Lookup    | Section 5.3.3|
   |           |               |    --------------      |              |
   |     12    |  IPv4NextHop  | Define the process of  |   RFC ???    |
   |           |               | selecting Ipv4 next hop| Section 5.3.2|
   |           |               | action                 |              |
   |           |               |    --------------      |              |
   |     13    |  IPv6NextHop  | Define the process of  |   RFC ???    |
   |           |               | selecting Ipv6 next hop| Section 5.3.4|
   |           |               | action                 |              |
   |           |               |    --------------      |              |
   |     14    |  RedirectIn   | Define the process for |   RFC ???    |
   |           |               | CE to inject data      | Section 5.4.1|
   |           |               | packets into FE LFB    |              |
   |           |               | topology               |              |
   |           |               |    --------------      |              |
   |     15    |  RedirectOut  | Define the process for |   RFC ???    |
   |           |               | LFBs in FE to deliver  | Section 5.4.2|
   |           |               | data packets to CE     |              |
   |           |               |    --------------      |              |
   |     16    |BasicMetadata  | Dispatch input packets |   RFC ???    |
   |           |Dispatch       | to a group output      | Section 5.5.1|
   |           |               | according to a metadata|              |
   |           |               |    --------------      |              |
   |     17    |Generic        | Define a preliminary   |   RFC ????   |
   |           |Scheduler      | generic scheduling     | Section 5.5.2|
   |           |               | process                |              |
   +-----------+---------------+------------------------+--------------+

                                 Table 1

10.2.  Metadata ID

   The Metadata ID namespace is 32 bits long.  The following is the
   guideline for managing the namespace.

   Metadata ID 0x00000000-0x7FFFFFFF

      Metadata with IDs in this range are Specification Required
      [RFC5226].  A metadata ID using this range MUST be documented in
      an RFC or other permanent and readily available references.

   Values assigned by this specification:

   +--------------+-------------------------+--------------------------+
   |   Value      |           Name          |        Definition        |
   +--------------+-------------------------+--------------------------+
   |  0x00000001  |       EtherPHYCop       |      See Section 4.4     |
   |  0x00000002  |         SrcMAC          |      See Section 4.4     |
   |  0x00000003  |         DstMAC          |      See Section 4.4     |
   |  0x00000004  |       LogicalPortID     |      See Section 4.4     |
   |  0x00000005  |         EtherType       |      See Section 4.4     |
   |  0x00000006  |          VlanID         |      See Section 4.4     |
   |  0x00000007  |       VlanPriority      |      See Section 4.4     |
   |  0x00000008  |       NexthopIPv4Addr   |      See Section 4.4     |
   |  0x00000009  |       NexthopIPv6Addr   |      See Section 4.4     |
   |  0x0000000A  |       HopSelector       |      See Section 4.4     |
   |  0x0000000B  |       ExceptionID       |      See Section 4.4     |
   |  0x0000000C  |      ValidateErrorID    |      See Section 4.4     |
   |  0x0000000D  |         L3PortID        |      See Section 4.4     |
   |  0x0000000E  |       RedirectIndex     |      See Section 4.4     |
   |  0x0000000F  |    MediaEncapInfoIndex  |      See Section 4.4     |
   +--------------+-------------------------+--------------------------+

                                   Table 2

   Metadata ID 0x80000000-0xFFFFFFFFF

      Metadata IDs in this range are reserved for vendor private
      extensions and are the responsibility of individuals.

10.3.  Exception ID

   The Exception ID namespace is 32 bits long.  The following is the
   guideline for managing the Base LFB library namespace.

   Exception ID 0x00000000-0x7FFFFFFF
      Exception IDs in Section 6 this range are applied to achieve typical
   router functions.

   As mentioned in the overview section, typical router functions can Specification Required [RFC5226].
      An exception ID using this range MUST be
   categorized documented in short into an RFC or
      other permanent and readily available references.

   Values assigned by this specification:

   +--------------+---------------------------------+------------------+
   |   Value      |           Name                  |   Definition     |
   +--------------+---------------------------------+------------------+
   |  0x00000000  |  AnyUnrecognizedExceptionCase   | See Section 4.4  |
   |  0x00000001  |         BroadCastPacket         | See Section 4.4  |
   |  0x00000002  |           BadTTL                | See Section 4.4  |
   |  0x00000003  |    IPv4HeaderLengthMismatch     | See Section 4.4  |
   |  0x00000004  |         LengthMismatch          | See Section 4.4  |
   |  0x00000005  |       RouterAlertOptions        | See Section 4.4  |
   |  0x00000006  |      RouteInTableNotFound       | See Section 4.4  |
   |  0x00000007  |         NextHopInvalid          | See Section 4.4  |
   |  0x00000008  |          FragRequired           | See Section 4.4  |
   |  0x00000009  |         LocalDelivery           | See Section 4.4  |
   |  0x0000000A  |          GenerateICMP           | See Section 4.4  |
   |  0x0000000B  |       PrefixIndexInvalid        | See Section 4.4  |
   |  0x0000000C  |         IPv6HopLimitZero        | See Section 4.4  |
   |  0x0000000D  |       IPv6NextHeaderHBH         | See Section 4.4  |
   +--------------+---------------------------------+------------------+

                                  Table 3

   Exception ID 0x80000000-0xFFFFFFFFF

      Exception IDs in this range are reserved for vendor private
      extensions and are the responsibility of individuals.

10.4.  Validate Error ID

   The Validate Error ID namespace is 32 bits long.  The following functions:

   o  IP forwarding

   o  address resolution

   o  ICMP

   o  network management

   o  running routing protocol

   To achieve is
   the functions, processing paths organized by guideline for managing the LFB
   classes with their interconnections should namespace.

   Validate Error ID 0x00000000-0x7FFFFFFF

      Validate Error IDs in this range are Specification Required
      [RFC5226].  A Validate Error ID using this range MUST be established
      documented in FE.  In
   general, CE controls an RFC or other permanent and manages the processing paths readily available
      references.

   Values assigned by use of the
   ForCES protocol.

   Note that LFB class use cases shown this specification:

   +--------------+---------------------------------+------------------+
   |   Value      |           Name                  |   Definition     |
   +--------------+---------------------------------+------------------+
   |  0x00000000  | AnyUnrecognizedValidateErrorCase| See Section 4.4  |
   |  0x00000001  |        InvalidIPv4PacketSize    | See Section 4.4  |
   |  0x00000002  |           NotIPv4Packet         | See Section 4.4  |
   |  0x00000003  |    InvalidIPv4HeaderLengthSize  | See Section 4.4  |
   |  0x00000004  |         InvalidIPv4Checksum     | See Section 4.4  |
   |  0x00000005  |      InvalidIPv4SrcAddrCase1    | See Section 4.4  |
   |  0x00000006  |      InvalidIPv4SrcAddrCase2    | See Section 4.4  |
   |  0x00000007  |      InvalidIPv4SrcAddrCase3    | See Section 4.4  |
   |  0x00000008  |      InvalidIPv4SrcAddrCase4    | See Section 4.4  |
   |  0x00000009  |      InvalidIPv6PakcetSize      | See Section 4.4  |
   |  0x0000000A  |          NotIPv6Packet          | See Section 4.4  |
   |  0x0000000B  |      InvalidIPv6SrcAddrCase1    | See Section 4.4  |
   |  0x0000000C  |      InvalidIPv6SrcAddrCase2    | See Section 4.4  |
   |  0x0000000D  |      InvalidIPv6DstAddrCase1    | See Section 4.4  |
   +--------------+---------------------------------+------------------+
                                   Table 4

   Validate Error ID 0x80000000-0xFFFFFFFFF

      Validate Error IDs in this section range are only as
   examples to demonstrate how typical router functions can be
   implemented with the defined base LFB library.  Users and
   implementers should not be limited by the examples.

7.1.  IP Forwarding

   TBD

8.  Contributors

   The authors would like to thank Jamal Hadi Salim, Ligang Dong, reserved for vendor private
      extensions and
   Fenggen Jia who made major contributions to are the development responsibility 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

      Fenggen Jia
      National Digital Switching Center(NDSC)
      Jianxue Road
      Zhengzhou 452000
      P.R.China
      EMail: jfg@mail.ndsc.com.cn

9.  Acknowledgements

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

10.  IANA Considerations

   (TBD) individuals.

11.  Security Considerations

   These definitions if used by an FE to support

   The ForCES create
   manipulable entities on framework document [RFC3746] provides a comprehensive
   security analysis for the FE.  Manipulation of such objects can
   produce almost unlimited effects on overall ForCES architecture.  For example,
   the FE.  FEs should ensure that
   only properly authenticated ForCES protocol participants are
   performing such manipulations.  Thus entities must be authenticated per the security issues with ForCES
   requirements before they can access the information elements
   described in this
   protocol are defined document via ForCES.  Access to the information
   contained in this document is accomplished via the ForCES protocol [RFC5810].
   protocol[RFC5810], which is defined in separate documents, and thus
   the security issues will be addressed there.

12.  References

12.1.  Normative References

   [RFC5810]  Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang,
              W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and
              Control Element Separation (ForCES) Protocol
              Specification", RFC 5810, March 2010.

   [RFC5812]  Halpern, J. and J. Hadi Salim, "Forwarding and Control
              Element Separation (ForCES) Forwarding Element Model",
              RFC 5812, March 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@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

   Chuanhuang Li
   Hangzhou BAUD Networks
   408 Wen-San Road
   Hangzhou,   310012
   P.R.China

   Phone: +86-571-28877751
   Email: chuanhuang_li@zjgsu.edu.cn

   Halpern Joel
   Ericsson
   P.O. Box 6049
   Leesburg,   20178
   VA

   Phone: +1 703 371 3043
   Email: joel.halpern@ericsson.com