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

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

Abstract

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

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 June December 4, 2011.

Copyright Notice

   Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     4.2.  Frame  . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     4.3.  MetaData . . . . . . . . . . . . . . . . . . . . . . . . . 15
     4.4.  XML for Base Type Library  . . . . . . . . . . . . . . . . 15
   5.  LFB Class Description  . . . . . . . . . . . . . . . . . . . . 36
     5.1.  Ethernet Processing LFBs . . . . . . . . . . . . . . . . . 36
       5.1.1.  EtherPHYCop  . . . . . . . . . . . . . . . . . . . . . 36
       5.1.2.  EtherMACIn
         5.1.1.1.  Data Handling  . . . . . . . . . . . . . . . . . . 36
         5.1.1.2.  Components . . . . 38
       5.1.3.  EtherClassifier . . . . . . . . . . . . . . . . 37
         5.1.1.3.  Capabilities . . . 40
       5.1.4.  EtherEncapsulator . . . . . . . . . . . . . . . . 38
         5.1.1.4.  Events . . 41
       5.1.5.  EtherMACOut . . . . . . . . . . . . . . . . . . . . 38
       5.1.2.  EtherMACIn . 44
     5.2.  IP Packet Validation LFBs . . . . . . . . . . . . . . . . 45
       5.2.1.  IPv4Validator . . . . . 38
         5.1.2.1.  Data Handling  . . . . . . . . . . . . . . . 45
       5.2.2.  IPv6Validator . . . 38
         5.1.2.2.  Components . . . . . . . . . . . . . . . . . 46
     5.3.  IP Forwarding LFBs . . . 39
         5.1.2.3.  Capabilities . . . . . . . . . . . . . . . . . 47
       5.3.1.  IPv4UcastLPM . . 40
         5.1.2.4.  Events . . . . . . . . . . . . . . . . . . . 48
       5.3.2.  IPv4NextHop . . . 40
       5.1.3.  EtherClassifier  . . . . . . . . . . . . . . . . . . 49
       5.3.3.  IPv6UcastLPM . 40
       5.1.4.  EtherEncapsulator  . . . . . . . . . . . . . . . . . . 42
       5.1.5.  EtherMACOut  . . 51
       5.3.4.  IPv6NextHop . . . . . . . . . . . . . . . . . . . 45
         5.1.5.1.  Data Handling  . . 51
     5.4.  Address Resolution LFBs . . . . . . . . . . . . . . . . 45
         5.1.5.2.  Components . 51
       5.4.1.  ARP . . . . . . . . . . . . . . . . . . . 45
         5.1.5.3.  Capabilities . . . . . . 51
       5.4.2.  ND . . . . . . . . . . . . . 46
         5.1.5.4.  Events . . . . . . . . . . . . . 53
     5.5.  Redirect . . . . . . . . . 46
     5.2.  IP Packet Validation LFBs  . . . . . . . . . . . . . . . . 46
       5.2.1.  IPv4Validator  . . . . . . 53
       5.5.1.  RedirectIn . . . . . . . . . . . . . . 46
         5.2.1.1.  Data Handling  . . . . . . . . 53
       5.5.2.  RedirectOut . . . . . . . . . . 46
         5.2.1.2.  Components . . . . . . . . . . . 54
     5.6.  General Purpose LFBs . . . . . . . . . 48
         5.2.1.3.  Capabilities . . . . . . . . . . 54
       5.6.1.  BasicMetadataDispatch . . . . . . . . . 48
         5.2.1.4.  Events . . . . . . . 54
       5.6.2.  GenericScheduler . . . . . . . . . . . . . . . 48
       5.2.2.  IPv6Validator  . . . . 55
   6.  XML for LFB Library . . . . . . . . . . . . . . . . 48
         5.2.2.1.  Data Handling  . . . . . 57
   7.  LFB Class Use Cases . . . . . . . . . . . . . 48
         5.2.2.2.  Components . . . . . . . . 83
     7.1.  IP Forwarding . . . . . . . . . . . . 50
         5.2.2.3.  Capabilities . . . . . . . . . . 83
     7.2.  Address Resolution . . . . . . . . . 50
         5.2.2.4.  Events . . . . . . . . . . . 83
     7.3.  ICMP . . . . . . . . . . . 50
     5.3.  IP Forwarding LFBs . . . . . . . . . . . . . . . . 83
     7.4.  Running Routing Protocol . . . . 50
       5.3.1.  IPv4UcastLPM . . . . . . . . . . . . . 83
     7.5.  Network Management . . . . . . . . 51
       5.3.2.  IPv4NextHop  . . . . . . . . . . . . 84
   8.  Contributors . . . . . . . . . 52
       5.3.3.  IPv6UcastLPM . . . . . . . . . . . . . . . . 85
   9.  Acknowledgements . . . . . 54
       5.3.4.  IPv6NextHop  . . . . . . . . . . . . . . . . . . 86
   10. IANA Considerations . . . 54
     5.4.  Redirect LFBs  . . . . . . . . . . . . . . . . . . 87
   11. Security Considerations . . . . 54
       5.4.1.  RedirectIn . . . . . . . . . . . . . . . 88
   12. References . . . . . . . 54
       5.4.2.  RedirectOut  . . . . . . . . . . . . . . . . . . . 89
     12.1. Normative References . . 55
     5.5.  General Purpose LFBs . . . . . . . . . . . . . . . . . 89
     12.2. Informative References . . 55
       5.5.1.  BasicMetadataDispatch  . . . . . . . . . . . . . . . . 89
   Authors' Addresses 56
       5.5.2.  GenericScheduler . . . . . . . . . . . . . . . . . . . 56
   6.  XML for LFB Library  . . . . . 90

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 . . . . . . . . . . . . . . . . 58
   7.  LFB Class Use Cases  . . . . . . . . . . . . . . . . . . . . . 80
     7.1.  IP 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) - A logical entity that implements the ForCES
      protocol and uses it to instruct one or more FEs on how to process
      packets.  CEs handle functionality such as the execution of
      control and signaling protocols.

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

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

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

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

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

      LFB Metadata - Metadata is used to communicate per-packet state
      from one LFB to another, but is not sent across the network.  The
      FE model defines how such metadata is identified, produced and
      consumed by the LFBs.  It defines the functionality but not how
      metadata is encoded within an implementation.

      LFB Component - Operational parameters of the LFBs that must be
      visible to the CEs are conceptualized in the FE model as the LFB
      components.  The LFB components include, for example, flags,
      single parameter arguments, complex arguments, and tables that the
      CE can read and/or write via the ForCES protocol (see below).

      LFB Topology - Representation of how the LFB instances are
      logically interconnected and placed along the datapath within one
      FE.  Sometimes it is also called intra-FE topology, to be
      distinguished from inter-FE topology.

      ForCES Protocol - While there may be multiple protocols used
      within the overall ForCES architecture, the term "ForCES protocol"
      and "protocol" refer to the Fp reference points in the ForCES
      Framework in [RFC3746].  This protocol does not apply to CE-to-CE
      communication, FE-to-FE communication, or to communication between
      FE and CE managers.  Basically, the ForCES protocol works in a
      master-slave mode in which FEs are slaves and CEs are masters.
      This document defines the specifications for this ForCES protocol.

3.  Introduction

   RFC 3746 [RFC3746] specifies Forwarding and Control Element
   Separation (ForCES) 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). checksum),

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

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

   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.  In
   a typical packet flow within

   Packets in an IP router, a port LFB receives
   packets router are received and decapsulates them transmitted on physical
   media typically referred to form IP level packets. as "ports".  Different physical port
   media will have different ways to achieve the goal of
   decapsulating media-specific headers and therefore LFBs way for various encapsulating outgoing frames and
   decapsulating incoming frames.  The different physical media will
   also have to be defined although this 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 sticks will also interchangeably
   refer to
   ethernet only. 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 weak-host model[RFC1122] since that is the
   most usable model for a packet processing Network
   Element(NE).  (Editorial note - describe how a strong host model is
   achieved if needed.) 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 (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 address resolution LFBs are defined for the purpose to
   abstract the process for address resolution function.

   The following LFBs are defined for Address Resolution processing:

      ARP (section 5.4.1)

      ND (section 5.4.2)

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

      RedirectOut (section 5.5.2)

   (6)

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

      GenericScheduler (section 5.6.2)

3.2.3.  Sample LFB Class Application

   Although Section 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. classes

   Figure 1 shows the typical LFB processing path for the 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.  Section 7.1 will
   describe the LFB topology in more details.

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

                      Figure 1: A Sample of LFB Class Application AIPv4 Forwarding Case

3.3.  Document Structure

   Base type definitions, including data types, packet frame types, and
   metadata
   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. 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

   The

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

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

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

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

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

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

4.1.  Data

   The following data types are currently defined 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 types of frames the LFB expects at its
   input port(s) and emits at its output port(s).  The <frameDef>
   element in the FE model is used to define a new frame type.

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

   (TBD)

4.3.  MetaData

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

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

   (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 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 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>
          <!-- XXX: This doesnt look like the SNMP
      definitions. We should look at the SNMP
      definitions for guidance; we should not have
      limitations that SNMP has such as being
      restricted to 32 bits"
      "refer to RFC 3635 ifSpeed and ifHighSpeed"
          -->
         </atomic>
       </dataTypeDef>
       <dataTypeDef>
         <name>DuplexType</name>
         <!-- <typeRef>IEEENegotiationType</typeRef> -->
         <synopsis>Duplex types</synopsis>
         <atomic>
          <baseType>uint32</baseType>
          <specialValues>
            <specialValue value="0x00000001">
             <name>Auto</name>
             <synopsis>Auto negotitation.</synopsis>
            </specialValue>
            <specialValue value="0x00000002">
             <name>Half-duplex</name>
             <synopsis>port negotitation half duplex</synopsis>
            </specialValue>
            <specialValue value="0x00000003">
             <name>Full-duplex</name>
             <synopsis>port negotitation full duplex</synopsis>
            </specialValue>
          </specialValues>
         </atomic>
         <!-- XXX: This is very IEEE specific -->
       </dataTypeDef>
       <dataTypeDef>
         <name>PortStatusValues</name>
         <synopsis>
               The possible values of status. Used for both
               administrative and operation status
             </synopsis>
         <atomic>
          <baseType>uchar</baseType>
          <specialValues>
            <specialValue value="0">
             <name>Disabled </name>
             <synopsis>the port is operatively disabled.</synopsis>
            </specialValue>
            <specialValue value="1">
             <name>UP</name>
             <synopsis>the port is up.</synopsis>
            </specialValue>
            <specialValue value="2">
             <name>Down</name>
             <synopsis>The port is down.</synopsis>
            </specialValue>
          </specialValues>
          <!-- XXX: We need to conform with Administrative and
               operational status -->
         </atomic>
       </dataTypeDef>
       <dataTypeDef>
         <name>PortStatsType</name>
         <synopsis>Port statistics</synopsis>
         <struct>
          <component componentID="1">
            <name>InUcastPkts</name>
            <synopsis>Number of unicast packets received</synopsis>
            <typeRef>uint64</typeRef>
          </component>
          <component componentID="2">
            <name>InMulticastPkts</name>
            <synopsis>Number of multicast packets received</synopsis>
            <typeRef>uint64</typeRef>
          </component>
          <component componentID="3">
            <name>InBroadcastPkts</name>
            <synopsis>Number of broadcast packets received</synopsis>
            <typeRef>uint64</typeRef>
          </component>
          <component componentID="4">
            <name>InOctets</name>
            <synopsis>number of octets received</synopsis>
            <typeRef>uint64</typeRef>
          </component>
          <component componentID="5">
            <name>OutUcastPkts</name>
            <synopsis>Number of unicast packets transmitted</synopsis>
            <typeRef>uint64</typeRef>
          </component>
          <component componentID="6">
            <name>OutMulticastPkts</name>
            <synopsis>Number of multicast packets transmitted</synopsis>
            <typeRef>uint64</typeRef>
          </component>
          <component componentID="7">
            <name>OutBroadcastPkts</name>
            <synopsis>Number of broadcast packets transmitted</synopsis>
            <typeRef>uint64</typeRef>
          </component>
          <component componentID="8">
            <name>OutOcetes</name>
            <synopsis>Number of octets transmitted</synopsis>
            <typeRef>uint64</typeRef>
          </component>
          <component componentID="9">
            <name>InErrorPkts</name>
            <synopsis>Number of input error packets</synopsis>
            <typeRef>uint64</typeRef>
          </component>
          <component componentID="10">
            <name>OutErrorPkts</name>
            <synopsis>Number of output error packets</synopsis>
            <typeRef>uint64</typeRef>
          </component>
         </struct>
         <!-- XXX: Make sure we validate with SNMP Port Stats -->
         <synopsis>The possible values of status. Used for both
               administrative and operation status.</synopsis>
         <atomic>
          <baseType>uchar</baseType>
          <specialValues>
            <specialValue value="0">
             <name>Disabled </name>
             <synopsis>the port is operatively disabled.</synopsis>
            </specialValue>
            <specialValue value="1">
             <name>UP</name>
             <synopsis>the port is up.</synopsis>

            </specialValue>
            <specialValue value="2">
             <name>Down</name>
             <synopsis>The port is down.</synopsis>
            </specialValue>
          </specialValues>
         </atomic>
       </dataTypeDef>
       <dataTypeDef>
          <name>MACInStatsType</name>
          <synopsis>The content of statistic for EtherMACIn.</synopsis>
          <struct>
             <component componentID="1">
                <name>NumPacketsReceived</name>
                <synopsis>The number of packets received.</synopsis>
                <typeRef>uint64</typeRef>
             </component>
             <component componentID="2">
                <name>NumPacketsDroped</name>
                <name>NumPacketsDropped</name>
                <synopsis>The number of packets droped.</synopsis> dropped.</synopsis>
                <typeRef>uint64</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
          <name>MACOutStatsType</name>
          <synopsis>The content of statistic for EtherMACOut.</synopsis>
          <struct>
             <component componentID="1">
                <name>NumPacketsTransimtted</name>
                <name>NumPacketsTransmitted</name>
                <synopsis>The number of packets transimtted.</synopsis> transmitted.</synopsis>
                <typeRef>uint64</typeRef>
             </component>
             <component componentID="2">
                <name>NumPacketsDroped</name>
                <name>NumPacketsDropped</name>
                <synopsis>The number of packets droped.</synopsis> dropped.</synopsis>
                <typeRef>uint64</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
          <name>EtherDispatchTableType</name>
          <name>EtherDispatchEntryType</name>
          <synopsis>the type of etherDispatch EtherDispatch table entry.</synopsis>
          <struct>
             <component componentID="1">
                <name>LogicalPortID</name>
                <synopsis>Logical 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 output port index.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
          <name>VlanInputTableType</name>
          <synopsis>VLAN Output
          <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 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
                <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>
       <dataTypeDef>
          <name>EtherClassifyStatsType</name>
          <synopsis>VLAN Output
          <name>VlanInputTableType</name>
          <synopsis>Vlan input table entry type.</synopsis>
          <array type="variable-size">
            <typeRef>VlanInputTableEntryType</typeRef>
          </array>

       </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>
       </dataTypeDef>
       <dataTypeDef>
          <name>EtherClassifyStatsTableType</name>
          <synopsis>Ether classify statistic information
           table type.</synopsis>
          <array type="variable-size">
            <typeRef>EtherClassifyStatsType</typeRef>
          </array>
       </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>uint32</typeRef>
                <typeRef>uint64</typeRef>
             </component>
             <component componentID="2">
                <name>badTotalLengthPkts</name>
                <synopsis>Number of bad total length packets.</synopsis>
                <typeRef>uint32</typeRef>
                <typeRef>uint64</typeRef>
             </component>
             <component componentID="3">
                <name>badTTLPkts</name>
                <synopsis>Number of bad TTL packets.</synopsis>
                <typeRef>uint32</typeRef>
                <typeRef>uint64</typeRef>
             </component>
             <component componentID="4">
                <name>badChecksum</name>
                <name>badChecksumPkts</name>
                <synopsis>Number of bad checksum packets.</synopsis>
                <typeRef>uint32</typeRef>
                <typeRef>uint64</typeRef>

             </component>
          </struct>
       </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>IPv4PrefixTableType</name>
          <synopsis>Each row of the IPv4
          <name>IPv4PrefixInfoType</name>
          <synopsis>IPv4 Prefix Table</synopsis> 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>
                <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 for supporting loose RPF.
                </synopsis>
                <atomic>
                   <baseType>boolean</baseType>
                   <specialValues>
                      <specialValue value="false">
                         <name>False</name>
                         <synopsis>This is not a default route.
                         </synopsis>
                      </specialValue>
                      <specialValue value="true">
                         <name>True</name>
                         <synopsis>This route is a default route. for
                         supporting the loose RPF.</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>
          <synopsis>Statistics type in IPv4Unicast.</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>IPv4 packets forwarded by this LFB</synopsis>
                <typeRef>uint64</typeRef>
             </component>
             <component componentID="3">
                <name>NoRoutePkts</name>
                <synopsis>The number of IP datagrams discarded because
                no route could be found.</synopsis>
                <typeRef>uint64</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
          <name>IPv6PrefixTableType</name>
          <synopsis>Each row of the IPv6
          <name>IPv6PrefixInfoType</name>
          <synopsis>IPv6 Prefix Table</synopsis> information,entry type for
           IPv6 prefix table</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>
                <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 datagrams discarded because
                no route could be found.</synopsis>
                <typeRef>uint64</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
          <name>NexthopOptionType</name>
          <synopsis>Special Values of NextHopOption Type</synopsis>
          <atomic>
             <baseType>uint8</baseType>
             <specialValues>
                <specialValue value="1">
                   <name>Normal</name>
                   <synopsis>Normal Forwarding</synopsis>
                </specialValue>
                <specialValue value="2">
                   <name>Local</name>
                   <synopsis>The packet need to be forwarded to locally
                   attached host</synopsis>
                </specialValue>
             </specialValues>
          </atomic>
       </dataTypeDef>
       <dataTypeDef>
          <name>IPv4NextHopTableType</name>
          <synopsis>Each row of
          <name>IPv4NextHopInfoType</name>
          <synopsis>IPv4 next hop information. Entry type for the
             IPv4 NextHop Table</synopsis> next hop table.</synopsis>
          <struct>
             <component componentID="1">
                <name>NexthopID</name>
                <synopsis>ID of the NextHop</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="2">
                <name>OutputLogicalPortID</name>
                <name>L3PortID</name>
                <synopsis>The ID of the Logical OutputPort</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="3">
                <name>MTU</name>
                <synopsis>Maximum Transmission Unit for out going port.
               It is for desciding whether the packet need fragmentation
                </synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="4">
                <name>NexthopIPAddr</name>
                <synopsis>Next Hop IPv4 Address</synopsis>
                <typeRef>IPv4Addr</typeRef>
             </component>
             <component componentID="5">
                <name>NexthopOption</name>
                <synopsis>Next Hop Option</synopsis>
                <typeRef>NexthopOptionType</typeRef>
             </component>
             <component componentID="6">
                <name>EncapOutputIndex</name>
                <synopsis>Group output port index</synopsis>
                <typeRef>uint32</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
          <name>IPv6NextHopTableType</name>
          <synopsis>Each row of the IPv4 NextHop Table</synopsis>
          <struct>
             <component componentID="1">
                <name>NexthopID</name>
                <synopsis>ID of Logical/physical Output Port
                that we pass onto the NextHop</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="2">
                <name>OutputLogicalPortID</name>
                <synopsis>The neighboring LFB instance. This
                ID of indicates what port to the Logical OutputPort</synopsis> neighbor is as defined
                by L3.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="3"> componentID="2">
                <name>MTU</name>
                <synopsis>Maximum Transmission Unit for out going port.
                 It is for desciding whether the packet need
                 fragmentation </synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="4">
                <name>NexthopIPAddr</name> componentID="3">
                <name>NextHopIPAddr</name>
                <synopsis>Next Hop IPv4 Address</synopsis>
                <typeRef>IPv6Addr</typeRef>
                <typeRef>IPv4Addr</typeRef>
             </component>
             <component componentID="5">
                <name>NexthopOption</name>
                <synopsis>Next Hop Option</synopsis>
                <typeRef>NexthopOptionType</typeRef> 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="6">
                <name>EncapOutputIndex</name>
                <synopsis>Group componentID="5">
                <name>LFBOutputSelectIndex</name>
                 <synopsis>LFB Group output port index</synopsis> 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 port group "successout" in the table LFBTopology
                 (of FEObject LFB) as defined for the NH LFB.
                 </synopsis>
                <typeRef>uint32</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
          <name>ArpTableType</name>
          <synopsis>ARP
          <name>IPv4NextHopTableType</name>
          <synopsis>IPv4 next hop table entry type.</synopsis> type</synopsis>
          <array type="variable-size">
            <typeRef>IPv4NextHopInfoType</typeRef>
          </array>
       </dataTypeDef>
       <dataTypeDef>
          <name>IPv6NextHopInfoType</name>
          <synopsis>IPv6 next hop information. Entry type for the
             IPv6NextHopTable.</synopsis>
          <struct>
             <component componentID="1">
                <name>LogicalPortID</name>
                <synopsis>Logical
                <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 ID.</synopsis> to the neighbor is as defined
                by L3.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="2">
                <name>DstIPv4Address</name>
                <synopsis>Destination IPv4 address.</synopsis>
                <typeRef>IPv4Addr</typeRef>
                <name>MTU</name>
                <synopsis>Maximum Transmission Unit for out going port.
                 It is for desciding whether the packet need
                 fragmentation.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="3">
                <name>DstMac</name>
                <synopsis>Mac of the Neighbor.</synopsis>
                <typeRef>IEEEMAC</typeRef>
                <name>NextHopIPAddr</name>
                <synopsis>Next Hop IPv6 Address</synopsis>
                <typeRef>IPv6Addr</typeRef>
             </component>
             <component componentID="4">
                <name>SrcMac</name>
                <synopsis>Source MAC.</synopsis>
                <typeRef>IEEEMAC</typeRef>
                <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 port group "successout" in the table LFBTopology
                (of FEObject LFB) as defined for the NH LFB.
                 </synopsis>
                <typeRef>uint32</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
          <name>NbrTableType</name>
          <name>IPv6NextHopTableType</name>
          <synopsis>IPv6 neighbour next hop table type</synopsis>
          <array type="variable-size">
            <typeRef>IPv6NextHopInfoType</typeRef>
          </array>
       </dataTypeDef>
       <dataTypeDef>
          <name>EncapTableEntryType</name>
          <synopsis>Ethernet encapsulation table entry type.</synopsis>
          <struct>
             <component componentID="1">
                <name>LogicalPortID</name>
                <synopsis>Logical port ID.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="2">
                <name>DstIPv6Address</name>
                <synopsis>Destination IPv4 address.</synopsis>
                <typeRef>IPv6Addr</typeRef>
             </component>
             <component componentID="3">
                <name>DstMac</name>
                <synopsis>Mac
                <synopsis>Ethernet Mac of the Neighbor.</synopsis> Neighbor</synopsis>
                <typeRef>IEEEMAC</typeRef>
             </component>
             <component componentID="4"> componentID="2">
                <name>SrcMac</name>
                <synopsis>Source MAC.</synopsis>
                <typeRef>IEEEMAC</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
          <name>VlanOutputTableType</name>
          <synopsis>Vlan Output table entry type.</synopsis>
          <struct>
             <component componentID="1">
                <name>LogicalPortID</name>
                <synopsis>Logical port ID.</synopsis>
                <typeRef>uint32</typeRef> MAC used in encapsulation</synopsis>
                <typeRef>IEEEMAC</typeRef>
             </component>
             <component componentID="2"> componentID="3">
                <name>VlanID</name>
                <synopsis>VLAN ID.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="3">
                <name>OutputLogicalPortID</name> componentID="4">
                <name>L2PortID</name>
                <synopsis>Output logical L2 port ID.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
          <name>Portv4AddressInforType</name>
          <synopsis>Port address information, for v4 port.</synopsis>
          <struct>
             <component componentID="1">
                <name>IPv4Address</name>
                <synopsis>IPv4 address</synopsis>
                <typeRef>IPv4Addr</typeRef>
             </component>
             <component componentID="2">
                <name>IPv4NetMask</name>
                <synopsis>IPv4 net mask length</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="3">
                <name>SrcMAC</name>
                <synopsis>Source Mac address</synopsis>
                <typeRef>IEEEMAC</typeRef>
             </component>

          </struct>
       </dataTypeDef>
       <dataTypeDef>
          <name>Portv4AddrInfoTableType</name>
          <synopsis>Logical port (v4) address information
          <name>EncapTableType</name>
          <synopsis>Ethernet encapsulation table type
          </synopsis>
          <struct>
             <component componentID="1">
                <name>LogicalPortID</name>
                <synopsis>Logical port id.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="2">
                <name>Portv4AddrInfo</name>
                <synopsis></synopsis>
                <array>
                   <typeRef>Portv4AddressInforType</typeRef> type</synopsis>
          <array type="variable-size">
            <typeRef>EncapTableEntryType</typeRef>
          </array>
             </component>
          </struct>
       </dataTypeDef>
       <dataTypeDef>
          <name>MetadataDispatchTableType</name>
          <synopsis>Metadata
          <name>MetadataDispatchType</name>
          <synopsis>The entry type for Metadata dispatch table type.</synopsis> 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> 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 Depth of Queue.</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 depth units
                are packets.</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="3">
                <name>QueueDepthInBytes</name>
                <synopsis>the Queue Depth when the depth units
                are bytes.</synopsis>
                <typeRef>uint32</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>
          <synopsis>The physical port ID that a packet has entered.
          </synopsis>
          <metadataID>1</metadataID>
          <typeRef>uint32</typeRef>
       </metadataDef>
       <metadataDef>
          <name>SrcMAC</name>
          <synopsis>Source MAC Address</synopsis>
          <metadataID>2</metadataID>
          <typeRef>IEEEMAC</typeRef>
       </metadataDef>
       <metadataDef>
          <name>DstMAC</name>
          <synopsis>Destination MAC Address</synopsis>
          <metadataID>3</metadataID>
          <typeRef>IEEEMAC</typeRef>
       </metadataDef>
       <metadataDef>
          <name>LogicalPortID</name>
          <synopsis>ID of logical port.</synopsis>
          <metadataID>4</metadataID>
          <typeRef>uint32</typeRef>
       </metadataDef>
       <metadataDef>
          <name>EtherType</name>
          <synopsis>The value 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>
          <synopsis>The priority of Vlan.</synopsis>
          <metadataID>7</metadataID>
          <typeRef>uint32</typeRef>
       </metadataDef>
       <metadataDef>
          <name>NexthopIPv4Addr</name>
          <synopsis>Nexthop IP address.</synopsis>
          <metadataID>8</metadataID>
          <typeRef>IPv4Addr</typeRef>
       </metadataDef>
       <metadataDef>
          <name>NexthopIPv6Addr</name>
          <synopsis>Nexthop IP address.</synopsis>
          <metadataID>9</metadataID>
          <typeRef>IPv6Addr</typeRef>
       </metadataDef>
       <metadataDef>
          <name>HopSelector</name>
          <synopsis>HopSelector is the nexthop ID which points to the
          nexthop table </synopsis>
          <metadataID>10</metadataID>
          <typeRef>uint32</typeRef>
       </metadataDef>
       <metadataDef>
          <name>ExceptionID</name>
       <!-- XXX: Needs more discussion. See that it applies to
         all LFBs. -->
          <synopsis>Exception Types</synopsis>
          <metadataID>11</metadataID>
          <atomic>
             <baseType>uint32</baseType>
             <specialValues>
                 <specialValue value="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>
                 </specialValue>
                 <specialValue value="2">
                   <name>BadTTL</name>
                   <synopsis>The packet can't be forwarded as the TTL
                   has expired.</synopsis>
                 </specialValue>
                 <specialValue value="3">
                   <name>IPv4HeaderLengthMismatch</name>
                   <synopsis>IPv4 Packet with Packet's header length > 5</synopsis> is less
                   than 5.</synopsis>
                 </specialValue>
                 <specialValue value="4">
                    <name>LengthMismatch</name>
                    <synopsis>The packet length reported by link layer
                    is less than the total length field.</synopsis>
                 </specialValue>
                 <specialValue value="5">
                    <name>RouterAlertOptions</name>
                    <synopsis>Packet IP head include Router Alert options.
                </synopsis>
                    options.</synopsis>
                 </specialValue>
                 <specialValue value="6">
                    <name>RouteInTableNotFound</name>
                    <synopsis>There is no route in the route table
                    corresponding to the 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 outgoing interface is less than
                the packet size.</synopsis>
                    <name>FragRequired</name>
                    <synopsis>The MTU for outgoing interface is less
                    than the packet size.</synopsis>
                 </specialValue>
                 <specialValue value="9">
                    <name>LocalDelivery</name>
                    <synopsis>The packet is for a local interface.
                    </synopsis>
                 </specialValue>
                 <specialValue value="10">
                    <name>GenerateICMP</name>
                    <synopsis>ICMP packet needs to be 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 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 is 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>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>LocalDelivery</name>
                <synopsis>The packet
                    <name>InvalidIPv6PakcetSize</name>
                    <synopsis>Packet size reported is for a local interface.
                </synopsis> less than 40
                    bytes.</synopsis>
                 </specialValue>
                 <specialValue value="10">
                <name>GenerateICMP</name>
                <synopsis>ICMP packet needs to be generated.</synopsis>
             </specialValue>
             <specialValue value="11">
                <name>PrefixIndexInvalid</name>
                <synopsis>The prefixIndex
                    <name>NotIPv6Packet</name>
                    <synopsis>Packet is wrong.</synopsis> not IP version 6.</synopsis>
                 </specialValue>
                 <specialValue value="12">
                <name>ArpTableL2NotFound</name> value="11">
                    <name>InvalidIPv6SrcAddr1</name>
                    <synopsis>Packet can't find the associated L2
                information in with multicast source address (the
                    MSB of the Arptable</synopsis>
             </specialValue>
             <specialValue value="13">
                <name>OutputLogiclPortIDNotFound</name>
                <synopsis>Packet can't find OutputLogicalPortID in
                VLANOutputTable</synopsis> source address is 0xFF).</synopsis>
                 </specialValue>
                 <specialValue value="14">
                <name>IPv6HopLimitZero</name> value="12">
                    <name>InvalidIPv6SrcAddr2</name>
                    <synopsis>Packet with Hop Limit zero </synopsis> source address set to
                    loopback(::1).</synopsis>
                 </specialValue>
                 <specialValue value="15">
                <name>IPv6NextHeaderHBH</name> value="13">
                    <name>InvalidIPv6DstAddr1</name>
                    <synopsis>Packet with next header destination set to Hop-by-Hop 0 or ::1.
                    </synopsis>
                 </specialValue>
              </specialValues>
           </atomic>
       </metadataDef>
       <metadataDef>
          <name>OutputLogicalPortID</name>
          <name>L3PortID</name>
          <synopsis>ID of output logical L3 port.</synopsis>
          <metadataID>12</metadataID>
          <metadataID>13</metadataID>
          <typeRef>uint32</typeRef>
       </metadataDef>
       <metadataDef>
          <name>RedirectIndex</name>
          <synopsis>Redirect Output port index.</synopsis>
          <metadataID>13</metadataID>
          <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, LFB (Logical Function Block) is a
   well defined, logically separable functional block that resides in an
   FE, and is a functionally accurate abstraction of the FE's processing
   capabilities.  An LFB Class (or type) is a template that represents a
   fine-grained, logically separable aspect of FE processing.  Most LFBs
   are related to packet processing in the data path.  LFB classes are
   the basic building blocks of the FE model.  Note that RFC 5810 has
   already defined an 'FE Protocol LFB' which is as a logical entity in
   each FE to control the ForCES protocol.  RFC 5812 has already defined
   an 'FE Object LFB'.  Information like the FE Name, FE ID, FE State,
   LFB 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 Processing LFBs

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

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

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

5.1.1.  EtherPHYCop

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

   The

5.1.1.1.  Data Handling

   This LFB is defined with one singleton input.  The input data of the
   LFB are expected interface to be the Ethernet packets.  Note that physical media.  The LFB
   handles ethernet frames coming in from or going out of the FE.
   Ethernet packets
   here 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,IEEE 802.3/802.2 SNAP.  It also includes SNAP, including packets
   encapsulated with varieties of LAN techniques based on Ethernet, like
   various VLANs, MACinMAC, etc.  As a result, we define various Ethernet frames as a
   frame name called 'EthernetAll'.  In an LFB abstracted processing
   path, usually  Therefore in the XML an EthernetAll
   frame type has been introduced.

   Ethernet packets frames are received from an upstream LFB like an
   EtherMACOut LFB.  It is not expected that an input Ethernet packet be
   associated with some metadata.  After the LFB receives the Ethernet
   packets, it will further process the packets at physical layer and
   eventually put them on the physical media wire for transmission.
   Note that the media wire transmission process in the LFB is
   abstracted port and passed
   downstream to LFBs such as EtherMACIn via a default function of the LFB rather than an input or
   output interface of the LFB.

   The LFB is also defined with one singleton output.  The output data
   produced are also with 'EthernetAll' frame type.  Every output data
   packet is associated with a known as
   "EtherPHYOut".  A 'PHYPortID' metadata metadatum, to indicate later
   processing LFBs of which physical
   port the packet is from.  Note that
   all the data packets are originated frame came into from media wire inside the LFB,
   which external world, is defined as a default function of the LFB.  As a physical
   layer abstraction module, the LFB does not possess passed along
   with the ability to
   specify encapsulations of types of Ethernet, rather, it produces
   various Ethernet types just according to what it receives from frame.

   Ethernet media wire.  In an LFB-based processing path topology, packets output from the EtherPHYCop lFB will usually go to an LFB
   like EtherMACIn LFB for further Ethernet processing.

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

   Several components are defined for singleton input known as "EtherPHYIn" before
   being sent out onto the LFB. external world.

5.1.1.2.  Components

   The AdminStatus component is defined for CE to administratively
   manage the status of the LFB.  Via the component,  The CE may adminstratively startup or
   shutdown the LFB. LFB by changing the value of AdminStatus.  The default status
   value is set to 'Down'.

   An OperStatus component is
   specifically defined for CE to access captures the actual operational status
   of the LFB, in case that a physical layer port may be in a failed
   state that its operational status does not correctly reflect
   administrative
   status.  A PHYPortStatusChanged event is defined for so the LFB to can
   report to the CE whenever there is a port an operational status change during
   operation. of
   the physical port.

   The PHYPortID component is defined for CE to assign an ID to the a unique identification 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 metadata associated
   with every Ethernet packet 'PHYPortID' metadatum
   at the LFB receives from media output and is going to hand associate it to every Ethernet packet this
   LFB receives.  The metadatum will be handed to later downstream LFBs for further processing.
   them to use the PHYPortID.

   A group of components are defined for link speed management.  The
   AdminLinkSpeed is for CE to configure proper link speed for the port and the
   OperLinkSpeed is for CE to query the actual link speed in operation.
   The default value for the AdminLinkSpeed is set to auto-
   negotiation auto-negotiation
   mode.

   A SupportedLinkSpeed capability attribute is also
   defined for CE to query the link speed ability.  A LinkSpeedChanged
   event is defined for the LFB to report to CE whenever there is a link
   speed change during operation.

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

   A SupportedDuplexMode capability CarrierStatus component captures the status of the carrier and
   specifies whether the port is also
   defined linked with an operational connector.
   The default value for CE to query the port duplex mode ability.  A
   DuplexModeChanged event CarrierStatus is defined '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 to report be able to CE
   whenever there is a duplex mode change during operation.

   There are also some other components, capabilities, generate several events defined in which
   the LFB for various purposes.  See section 6 CE may be interested.  There is an event for detailed XML
   definitions changes in the
   status of the LFB. 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 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 is defined with one singleton input.  The input is expected to receive all types of Ethernet packets packets, via a
   singleton input known as "EtherMACIn", which are usually output from
   some Ethernet physical abstraction layer LFB, like an EtherPHYCop LFB.  Every input packet is associated LFB, alongside
   with a metadatum indicating the physical port ID that the packet
   comes.

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

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

   The first singleton output is called NormalPathOut. known as "NormalPathOut".  It usually
   outputs Ethernet packets to some LFB like an EtherClassifier LFB for
   further L3 forwarding process.  Metadata associated process alongside with every packet from
   this output is PHYPortID, which keeps a PHYPortID metadata
   indicating which physical port the packet is came from.

   Another

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

   This LFB can be set to work in a Promiscuous Mode, allowing all
   packets to pass through the LFB without being dropped.  Otherwise, a
   locality check will be performed based on if the L2 output
   is local MAC addresses.
   All packets that do not pass through the same as normal output).  The metadata associated with every
   packet is also PHYPortID. locality check will be
   dropped.

   This LFB can perform Ethernet layer flow control control.  This is usually
   implemented cooperatively by
   EtherMACIn LFB and EtherMACOut LFB.  How the flow control is
   implemented is vendor-specific.  As an abstraction, this LFB defines
   two flag components for CE to enable or disable the flow control
   functions.  The flow control is further distinguished by Tx flow
   control and Rx flow control, separately for sending process and
   receiving process flow controls.  A TxFlowControl flag and a
   RxFlowControl flag are then separately defined.  In order for
   EtherMACOut LFB able to cooperatively work for flow control, the
   flags are also referenced in EtherMACIn LFB and the EtherMACOut LFB as aliases in this
   LFB.  The flow control is further distinguished by 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 administratively
   manage the status of the LFB.  Via the component,  The CE can may administratively startup or
   shutdown the LFB. LFB by changing the value of AdminStatus.  The default status
   value is set to 'Down'. /

   Note that

   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 set to
   work as a base definition, functions like multiple virtual MAC
   layers are L2 bridge.  An FE that does not supported in support bridging will
   internally set this flag to false, and additionally set the flag
   property as read-only.  The default value for is 'false'.

   The PromiscuousMode component specifies whether the LFB version.  It may be supported is set to
   work as in
   the future by defining a subclass or a new version of this LFB.

   There are also some other components, capabilities, events defined in promiscuous mode.  The default value for is 'false'.

   The TxFlowControl component defines whether the LFB is performing
   flow control on sending packets.  The default value for various purposes.  See section 6 is 'false'

   The RxFlowControl component defines whether the LFB is performing
   flow contron on receiving packets.  The default value for detailed XML
   definitions is 'false'.

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

5.1.2.3.  Capabilities

   This LFB does not have a list of capabilities.

5.1.2.4.  Events

   This LFB does not have any events specified.

5.1.3.  EtherClassifier

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

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

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

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

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

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

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

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

5.1.4.  EtherEncapsulator

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   Successfully encapsulated packets are then output via success output
   port.

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

5.1.5.  EtherMACOut

   EtherMACOut LFB abstracts an Ethernet port at MAC data link layer.
   It specifically
   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 actually alias are as aliases of EtherMACIn LFB.

   The LFB is defined with one singleton input(Editorial note: do we
   need another input for L2 bridging input?).
   components.

5.1.5.1.  Data Handling

   The input LFB is expected to receive all types of Ethernet packets packets, via a
   singleton input known as "EtherPktsIn", which are usually output from
   some
   an Ethernet encapsulation LFB.  Every input packet is associated LFB, alongside with a metadatum indicating
   the physical port ID that the packet will
   go(Editorial go through(editorial note: Ethernet encapsulation LFB actually generate
   logical
   need more discussion on the port ID metadata, how has it been changed to being physical port
   ID?). layer or L2
   layer).

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

   This LFB can perform Ethernet layer flow control control.  This is usually
   implemented cooperatively by the EtherMACIn LFB and the EtherMACOut
   LFB.  How the  The flow control is
   implemented is vendor-specific.  As an abstraction, 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 defines
   two flag components version.  It may be supported in
   the future by defining a subclass or a new version of this LFB

5.1.5.2.  Components

   The AdminStatus component is defined for CE to enable or disable administratively
   manage the status of the LFB.  The CE may administratively startup or
   shutdown the LFB by changing the value of AdminStatus.  The default
   value is set to 'Down'.  Note that this component is defined as an
   alias of the AdminStatus component in the EtherMACIn LFB.  This
   infers that an EtherMACOut LFB usually coexists with an EtherMACIn
   LFB, both of which share the same administrative status management by
   CE.  Alias properties as defined in the ForCES FE model (RFC 5812)
   will be used by CE to declare the flow control
   functions, a TxFlowControl flag 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 RxFlowControl flag, and they system runs, which are all defined as aliases outside the XML definitions of EtherMACIn
   this LFB.

   AdminStatus

   The MTU component defines the maximum transmission unit

   The TxFlowControl component defines whether the LFB is defined performing
   flow control on sending packets.  The default value for CE to administratively manage the status is 'false'.
   Note that this component is defined as an alias of TxFlowControl
   component in the EtherMACIn LFB.  Via the component, CE can startup or shutdown

   The RxFlowControl component defines whether the LFB. LFB is performing
   flow control on receiving packets.  The default status value for is set to 'Down'. 'false'.
   Note that as a base definition, functions like multiple virtual MAC
   layers are not supported in this LFB version.  It may be supported component is defined as an alias of RxFlowControl
   component in the future by defining a subclass or EtherMACIn LFB.

   A struct component, MACOutStats, defines a new version set of statistics for this LFB.

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

5.1.5.3.  Capabilities

   This LFB does not have a list of capabilities.

5.1.5.4.  Events

   This LFB does not have any events specified.

5.2.  IP Packet Validation LFBs

   An LFB is

   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

   This

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

   Input

5.2.1.1.  Data Handling

   This LFB performs IPv4 validation according to RFC 1812.  Then the
   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 expects, as input, packets which have been indicated
   as IPv4 packets by an upstream LFB, like an EtherClassifier LFB.
   There is no specific metadata expected by the input of the validator LFB.

   Note that, as a default provision of RFC 5812, in FE model, all
   metadata produced by upstream LFBs will pass through all downstream
   LFBs by default without being specified by input port or output port.
   Only those metadata that will be used(consumed) by an LFB will be
   explicitly marked in input of the LFB as expected metadata.  For
   instance, in this LFB, even there is no specific metadata expected,
   metadata like PHYPortID produced by some upstreaming PHY 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 been expected or not.

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

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

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

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

5.2.2.  IPv6Validator

   This LFB performs IPv6 packets validation according to RFC 2460.

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

   Similar to IPv4 validator LFB, IPv6Validator LFB metadata has also defined
   four been expected or not.

   Four output ports are defined to output various validation results.

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

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

      a packet with hop limit to zero

      a packet with a link-local destination address.

      a packet with a link-local source address.

      a packet include:

   o  Packet with destination all-routers.

      a packet address equal to 255.255.255.255

   o  Packet with destination all-nodes.

      a packet expired TTL

   o  Packet with next header set length more than 5 words

   o  Packet IP head including Router Alert options

   Note that, although TTL is checked in this LFB for validity,
   operations to Hop-by-Hop.

   A TTL like TTL decreasing will be made only in a followed
   forwarding LFB.

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

   o  Packet size reported is less than 20 bytes

   o  Packet with version is not IPv4

   o  Packet with header length < 5

   o  Packet with total length field < 20

   o  Packet with invalid packet size, wrong IPv6 protocol version, wrong checksum

   o  Packet with source or destination IPv6 addresses, etc.

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

5.3.  IP Forwarding LFBs

   IP Forwarding LFBs are specifically defined address equal to abstract the IP
   forwarding processes.  As definitions for a base LFB library, this
   document restricts its 255.255.255.255

   o  Packet with source address 0

   o  Packet with source address of form {127, <any>}

   o  Packet with source address in Class E domain

5.2.1.2.  Components

   This LFB definition scope for IP forwarding jobs has only to IP unicast forwarding.  LFBs one struct component, the
   IPv4ValidatorStatisticsType, which defines a set of statistics for jobs like IP multicast may
   be defined in future versions
   validation process, including the number of bad header packets, the document.

   A typical IP unicast forwarding job is usually realized by looking up
   some forwarding information table to find some next hop information,
   and then based on
   number of bad total length packets, the next hop information, forwarding packets to
   specific output ports.  It usually takes two steps to do so, firstly
   to look up a forwarding information table by means number of Longest Prefix
   Matching(LPM) rule to find a next hop index, then to use bad TTL packets,
   and the index to
   look up a next hop information table to find enough information to
   submit packets to output ports. number of bad checksum packets.

5.2.1.3.  Capabilities

   This document abstracts the
   forwarding processes mainly based on the two steps model.  However,
   there actually exists other models, like one which may only LFB does not have a
   forwarding information base that list of capabilities

5.2.1.4.  Events

   This LFB does not have conjoined next hop information
   together with forwarding information.  In this case, if ForCES
   technology is any events specified.

5.2.2.  IPv6Validator

   The IPv6Validator LFB performs IPv6 packets validation according to be applied, some translation work will have
   RFC 2460.

5.2.2.1.  Data Handling

   This LFB performs IPv6 validation according to RFC 2460.  Then the
   IPv6 packet will be
   done in FE output to translate attributes defined by this document into real
   attributes the implementation has actually applied.

   Based on the IP forwarding abstraction, two kind corresponding port regarding of typical IP the
   validation result, whether the packet is a unicast forwarding LFBs are defined, Unicast LPM lookup or a multicast
   one, an exception has occurred or the validation failed.

   This LFB and next
   hop application always expects, as input, packets which have been indicated
   as IPv6 packets by an upstream LFB, like an EtherClassifier LFB.  They are further distinguished

   There is no specific metadata expected by IPv4 and IPv6
   protocols.

5.3.1.  IPv4UcastLPM

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

   Input input of the LFB always expects LFB.

   Similar to receive IPv4 the IPv4validator LFB, IPv6Validator has also defined four
   output ports to 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 produce at these
   output ports.

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

   o  Packet with hop limit to zero

   o  Packet with a component 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 header set to Hop-by-Hop

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

   o  Packet size reported is less than 40 bytes

   o  Packet with version is not IPv6

   o  Packet with multicast source address (the MSB of every packet is as the index source
      address is 0xFF)

   o  Packet with destination address set to look up the table 0 or ::1

   o  Packet with the
   rule of longest prefix matching(LPM).  A hop selector is the matching
   result, which will be output source address set to downstream LFBs as an index for next
   hop information.

   Normal output of the LFB is a singleton output, which will output
   IPv4 unicast packet loopback (::1).

   Note that has passed in the LPM lookup base type library, definitions for exception ID and got a hop
   selector as
   validate error ID metadata are applied to both IPv4Validator and
   IPv6Validator LFBs, i.e., the lookup result.  The hop selector is associated two LFBs share the same medadata
   definition, with different ID assignment inside.

5.2.2.2.  Components

   This LFB has only one struct component, the packet as
   IPv6ValidatorStatisticsType, which defines a metadatum.  Followed set of statistics for
   validation process, including the normal output number of bad header packets, the LPM LFB
   is usually a next hop applicator LFB.  The LFB receives packets with
   their next hop IDs
   number of bad total length packets, and based on the next number of bad hop IDs to forward the limit
   packets.  A hop selector associated with every packet from the normal
   output will directly act as a next hop ID for

5.2.2.3.  Capabilities

   This LFB does not have a next hop applicator
   LFB.

   The list of capabilities

5.2.2.4.  Events

   This LFB is does not have any events specified.

5.3.  IP Forwarding LFBs

   IP Forwarding LFBs are specifically defined to provide some facilities to support users to
   implement equal-cost multi-path routing (ECMP) or reverse path abstract the IP
   forwarding (RPF).  However, processes.  As definitions for a base LFB library, this
   document restricts its LFB itself does not provide ECMP or
   RPF.  To implement ECMP or RPF, additional specific LFBs, like a
   specific ECMP LFB, will have definition scope for IP forwarding jobs
   only to be defined.  This work IP unicast forwarding.  LFBs for jobs like IP multicast may
   be done defined in
   the future version versions of the document.

   For the LFB to support ECMP, an ECMP flag is defined in the prefix
   table entries.  When the flag is set to true, it indicates this table
   entry

   A typical IP unicast forwarding job is for ECMP only.  In this case, the hop selector in this usually realized by looking up
   some forwarding information table
   entry will be used as an index for a downstream specific ECMP LFB to find its correspondent next hop IDs.  When ECMP is applied, it will
   usually get multiple some next hops information.

   To distinguish normal output from ECMP case output, a specific ECMP
   output is defined.  A packet, which has passed through prefix table
   entry lookup with true ECMP flag, will always output from this 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, information,
   and then based on the hop selector, multiple next hop IDs may be found,
   and more ECMP algorithms may be applied information, forwarding packets to optimize the route.  As
   the result of the ECMP LFB, it will
   specific output optimized one or multiple
   next hop IDs to its downstream LFB that is 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
   applicator LFB.

   For index, then to use the LFB index to support RPF,
   look up a default route flag is defined in the
   prefix next hop information table entry.  When set true, the prefix entry is identified as
   a default route, and also as a forbidden route for RPF.  To implement
   various RPF, one or more specific LFBs have to be defined. find enough information to
   submit packets to output ports.  This job
   may be done for document abstracts the future version of
   forwarding processes mainly based on the library.

   An exception output two steps model.  However,
   there actually exists other models, like one which may only have a
   forwarding information base that have conjoined next hop information
   together with forwarding information.  In this case, if ForCES
   technology is defined to allow be applied, some exceptional packets translation work will have to
   output here.  Exceptions include cases like packets can not find any
   routes be
   done in FE to translate attributes defined by this document into real
   attributes the prefix table.

   There are also some other components defined in implementation has actually applied.

   Based on the LFB for various
   purposes.  See section 6 for detailed XML definitions IP forwarding abstraction, two kind of the typical IP
   unicast forwarding LFBs are defined, Unicast LPM lookup LFB and next
   hop application LFB.

5.3.2.  IPv4NextHop

   This  They are further distinguished by IPv4 and IPv6
   protocols.

5.3.1.  IPv4UcastLPM

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

   Input of next hop information application the LFB always expects to receive IPv4 unicast packets.  An
   IPv4 prefix table is defined as a component for the LFB to provide
   forwarding information for every input packet.  The LFB receives an destination IPv4
   address of every packet with an associated next hop ID, and
   uses is as the ID index to look up a next hop the table with the
   rule of longest prefix matching(LPM).  A hop selector is the matching
   result, which will be output to find downstream LFBs as an appropriate index for next
   hop information.

   Normal output
   port from the LFB.  Simultaneously, the LFB also implements TTL
   operation and checksum recalculation of every IPv4 packet received.

   Input of the LFB is a singleton one output, which expects to receive will output
   IPv4 unicast packets packet that has passed the LPM lookup and got a hop
   selector metadata from an upstream LFB.
   Usually, as the upstream LFB is directly an IPv4UnicastLPM LFB.  While
   it is possible some other upstream LFB may be applied.  For instance,
   when ECMP lookup result.  The hop selector is supported, associated with
   the upstream packet as a metadatum.  Followed the normal output of the LPM LFB may be some specific ECMP
   is usually a next hop applicator LFB.  The LFB receives packets with
   their next hop ID in IDs and based on the next hop IDs to forward the
   packets.  A hop selector metadata of a associated with every packet is then used from the normal
   output will directly act as
   an index a next hop ID for a next hop applicator
   LFB..

   The LFB is defined to provide some facilities to support users to
   implement equal-cost multi-path routing (ECMP) or reverse path
   forwarding (RPF).  However, this LFB itself does not provide ECMP or
   RPF.  To implement ECMP or RPF, additional specific LFBs, like a
   specific ECMP LFB, will have to be defined.  This work may be done in
   the future version of the document.

   For the LFB to look up a next hop table support ECMP, an ECMP flag is defined in the LFB.  Via this prefix
   table and entries.  When the next hop index, important information flag is set to true, it indicates this table
   entry is for forwarding ECMP only.  In this case, the packet is found.  The information includes:

      output logical port ID, which hop selector in this table
   entry will be used by as an index for a downstream LFBs specific ECMP LFB to
   find proper output port.

      next hop option, which decides if the packet should be locally
      processed or not.  For packets that will be redirected to CE for
      processing or that need FE local processing, its correspondent next hop option will
      be marked as 'forwarded to locally attached host' .  Packets that
      will be normally forwarded IDs.  When ECMP is applied, it will be marked as 'normal forwarding'.
   usually get multiple next hop IP address, which will be used by downstream LFB to find
      proper hops information.

   To distinguish normal output port IP address for this packet.

      encapsulation from ECMP case output, a specific ECMP
   output index, which is used by the packet to find
      proper defined.  A packet, which has passed through prefix table
   entry lookup with true ECMP flag, will always output of from this LFB.

   There are two output ports.  One is for success output and another is
   for exception output.  Success output is a group output, port,
   with an
   index to indicate which output instance in the group is adopted.  The
   index is the encapsulation output index described above.  Downstream
   LFBs connected hop selector being its lookup result.  The output will
   usually directly go to a downstream ECMP processing LFB.  In the success output group ECMP
   LFB, based on the hop selector, multiple next hop IDs may be various LFBs for
   encapsulation like LFBs for Ethernet encapsulation and for PPP
   encapsulation, various LFBs for local processing, found,
   and LFBs for
   redirecting packets more ECMP algorithms may be applied to CE for processing.  Next hop table uses optimize the
   encapsulation output index to indicate which port instance in route.  As
   the
   output group a packet should go.

   Every port instance result of the success output group ECMP LFB, it will produce metadata
   of output logical port ID and optimized one or multiple
   next hop IP address for every output
   packet.  These metadata will be used by downstream LFBs IDs to further
   implementing forwarding process.

   Note its downstream LFB that for next hop option marked as local host processing, the is usually a next hop IP address for
   applicator LFB.

   For the packet LFB to support RPF, a default route flag is exactly the destination IP
   address of defined in the packet.

   The exception output of
   prefix table entry.  When set true, the LFB prefix entry is identified as
   a singleton output.  It outputs
   packets with exceptional cases.  An exception ID further indicates
   the exception reasons.  Exception may happen when default route, and also as a hop selector is
   found invalid, forbidden route for RPF.  To implement
   various RPF, one or ICMP packets need more specific LFBs have to be generated (Editorial note:
   more discussions here), etc.  The defined.  This job
   may be done for the future version of the library.

   An exception ID output is also produced as a
   metadata defined to allow some exceptional packets to
   output here.  Exceptions include cases like packets can not find any
   routes by the output to be transmitted to a downstream LFB. prefix table.

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

5.3.3.  IPv6UcastLPM

   The LFB abstracts 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 IPv6 addresses.  See section 6 for detailed
   XML definitions of this LFB.

5.3.4.  IPv6NextHop

5.3.2.  IPv4NextHop

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

   Definitions of this IPv6NextHop

   The LFB is very identical receives an IPv4 packet with an associated next hop ID, and
   uses the ID to IPv4NextHop
   LFB except that all IP addresses related are changed 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
   addresses to IPv6 addresses.  See section 6 for detailed XML
   definitions packet received.

   Input of this the LFB is a singleton one which expects to receive IPv4
   unicast packets and hop selector metadata from an upstream LFB.

5.4.  Address Resolution LFBs

   The address resolution LFBs abstracts
   Usually, the process for address
   resolution functions.  In 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 process, address resolution protocols,
   like ARP protocol for IPv4 upstream LFB may be some specific ECMP
   LFB.

   The next hop ID in hop selector metadata of a packet is then used as
   an index to look up a next hop table defined in the LFB.  Via this
   table and neighbor discovery protocol the next hop index, important information for IPv6,
   are applied.

   There exist two schema under ForCES architecture to implement address
   resolution function.  One forwarding
   the packet is for FE to implement found.  Every next hop table entry includes the address
   resolution
   following information:

      output logical port ID, which will be used by use of address resolution downstream LFBs as defined to
      find proper 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 are hosts in the same subnet with this
   section.  The other
      router.  Next hop option is marked as 'forwarded to offload locally
      attached host' if the address resolution from FE to
   CE.  In this case, address resolution LFBs next hop entry is for locally attached hosts
      delivery.  All other next hop entry will not be used.  All marked with 'normal
      forwarding'.  If a data packet passes through next hop entries
      with its next hop option marked with forwarded to locally attached
      host, the next hop IP address resolution protocol messages FE has received metadata associated with the data
      packet when output from the LFB will be
   redirected forced to CE via ForCES protocol [RFC5810].  CE is responsible set to
   process the protocol messages and generate new
      destination IP address resolution
   messages to send to outer network via FE using ForCES prococol
   [RFC5810].  CE of the data packet.  If a data packet
      passes through a next hop entry with its option being normal
      forwarding, the next hop IP address metadata at output will also use ForCES protocol be set
      to manage the next hop IP address
   resolution tables, like the ARP table and the neighbor table, in
   Ethernet encapsulator LFB.

   According as indicated by this next hop entry.
      Advantage to address resolution individually define this next hop option for IPv4 or IPv6
   packets, an ARP LFB and an ND(neighbor discovery) LFB are defined as
   below.

5.4.1.  ARP

   The ARP LFB provides locally attached
      hosts is, in this way, the function next hop entry number may be greatly
      reduced in 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 resolution for IPv4
   nodes.  Two singleton inputs are defined for this packet.  Note that when
      next hop option is set to 'forwarded to locally attached host',
      this entry field becomes invalid.  In this case the LFB.  One next hop IP
      address is for ARP
   protocol assigned directly by destination IP address of the data
      packet input.  The packets are usually come from upstream
   LFBs like an Ethernet classifier LFB where ARP protocol messages are
   categorized.  The frame type hence expected pass through this entry check.

      encapsulation output index, which is used by data packet to find
      proper output of this LFB.  Usually, this index can be used to
      indicate which encapsulation followed the ARP protocol
   message type.  The other singleton input is for IPv4 packets that
   usually come from Ethernet encapsulator LFB may be applied to
      data packets pass through this next hop entry check and are unable to find L2
   information
      classify the packets to different instance of a group output port.
      Moreover, this index can also be used to purely indicate output
      port instance to finish act as a classifier based on next hop IDs.  For
      instance, a next hop table entry can be defined with its
      encapsulation process in output index being directed to an output port which
      is followed with LFBs that LFB.  The
   associated metadata include a will redirect data packets to Control
      Element(CE).  A next hop IPv4 address, which is the
   encapsulator LFB entry can not find its binding Ethernet MAC address, the
   logical port ID, and the VLAN ID (Editorial note: need more
   discussions on what metadata these inputs should expect.)

   There are two components also be defined in for some data
      packets that need special local processing of the ARP LFB.  One Forwarding
      Element(FE).  In this case it is not really acting as an
      encapsulation index, rather a pure output index.

   As a result, the ARP
   table.  Note that ARP table in this LFB is defined as with two output ports.  One is for
   success output and another is for exception output.  Success output
   is a group output, with an alias
   component of ARP table index to indicate which output instance in Ethernet encapsulator LFB.  This means
   management of the ARP table will be shared by both of
   the LFBs. group is adopted.  The
   ARP LFB will manage the table and refresh index is exactly the table entries based on encapsulation output
   index described above.  Downstream LFBs connected to the ARP protocol messages received.  The protocol messages provide
   bindings of IPv4 addresses with destination MAC addresses.  The ARP
   table fields include destination IP address, logical port ID, source
   MAC address, success
   output group may be various LFBs for encapsulation like LFBs for
   Ethernet encapsulation and destination MAC address (Editorial note: need more
   discussions on what fields needed).

   Another component defined is the for PPP encapsulation, various LFBs for
   local IPv4 address table processing, and LFBs for all
   ports of redirecting packets to CE for
   processing.  Next hop table uses the FE.  An FE encapsulation output index to
   indicate which port here is indexed by instance in the output group a logical port ID.
   Note that every physical packet should go.

   Every port may be capable instance of multiple logical
   ports with multiple IP or MAC addresses.  The port IPv4 address table
   provides binding the success output group will produce metadata
   of a output logical port to an IP address ID and a MAC address
   (Editorial note: is it possible one logical port binds multiple next hop IP
   addresses?).  The table address for every output
   packet.  These metadata will be used by the ARP LFB downstream LFBs to check locality
   of arrived ARP protocol messages.  Usually the table will be
   configured by CE via ForCES protocol.(Editorial note: need more
   discussions on what fields further
   implementing forwarding or local processing.  Note that for next hop
   option marked as local host processing, the port next hop IP address table needs and how
   metadata for the logical port ID and MAC packet is exactly substituted with the destination
   IP address take effect in of the process).

   Two singleton outputs are defined for packet.

   The exception output of the ARP LFB.  One LFB is for ARP
   protocol message a singleton output.  All ARP request and response packets are
   sent out from here to downstream LFB, which usually is Ethernet
   encapsulation LFB.

   Another output is for sending all  It outputs
   packets that are input to this LFB
   because they can not find L2 encapsulation information when doing
   encapsulation in an Ethernet encapsulation LFB.  They are just sent
   back to the LFB for encapsulation again with exceptional cases.  An exception ID further indicates
   the expected refreshed
   ARP table contents. exception reasons.  Exception may happen when a hop selector is
   found invalid, or ICMP packets need to be generated (Editorial note: need
   more discussions on how here), etc.  The exception ID is also produced as a
   metadata by the mechanism should output to be defined for those packets unable transmitted to do
   encapsulation a downstream LFB.

   There are also some other components defined in encapsulation the LFB for various
   purposes.  See section 6 for detailed XML definitions of the LFB.  An alternative schema is to let

5.3.3.  IPv6UcastLPM

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

   Definitions of this IPv6UcastLPM LFB is very identical to do encapsulation rather than send them back
   IPv4UcastLPM LFB except that all IP addresses related are changed
   from IPv4 addresses to
   encapsulation LFB, then output IPv6 addresses.  See section 6 for detailed
   XML definitions of this LFB.

5.3.4.  IPv6NextHop

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

   Definitions of this IPv6NextHop LFB after
   the encapsulation LFB).

5.4.2.  ND

   (TBD)

5.5. is very identical to IPv4NextHop
   LFB except that all IP addresses related are changed from IPv4
   addresses to IPv6 addresses.  See section 6 for detailed XML
   definitions of this LFB.

5.4.  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, and some packets generated by CE may
   have to 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 process, a RedirectIn LFB and a RedirectOut LFB.  Usually, in an
   LFB topology of an FE, only one RedirectIn LFB instance and one
   RedirectOut LFB instance exist.

5.5.1.

5.4.1.  RedirectIn

   A RedirectIn LFB abstracts the process for CE to inject data packets
   into FE LFB topology so as to input data packets into FE data paths.

   From LFB topology point of view, the RedirectIn LFB acts as a source
   point for data packets coming from CE, therefore the RedirectIn LFB
   is defined with only one output, while without any input.

   Output of the RedirectIn LFB is defined as a group output.  Packets
   produced by the output will have arbitrary frame types decided by CE
   which generates the packets.  Possible frames may include IPv4, IPv6,
   or ARP protocol packets.  CE may associate some metadata to indicate
   the frame types.  CE may also associate other metadata to data
   packets to indicate various information on the packets.  Among them,
   there MUST exist a 'RedirectIndex' metadata, which is an integer
   acting as an index.  When CE transmits the metadata and a binging
   packet to a RedirectIn LFB, the LFB will read the metadata and output
   the packet to one of its group output port instance, whose port index
   is just as indicated by the metadata.  Detailed XML definition of the
   metadata is in the XML for base type library as in Section 4.4.

   All metadata from CE other than the 'RedirectIndex' metadata will
   output from the RedirectIn LFB along with their binding packets.
   Note that, a packet without a 'RedirectIndex' metadata associated
   will be dropped by the LFB.

   There is no component defined for current version of RedirectIn LFB.
   Detailed XML definitions of the LFB can be found in Section 6.

5.5.2.

5.4.2.  RedirectOut

   A RedirectOut LFB abstracts the process for LFBs in FE to deliver
   data packets to CE.  From LFB topology point of view, the RedirectOut
   LFB acts as a sink point for data packets going to CE, therefore the
   RedirectOut LFB is defined with only one input, while without any
   output.

   Input of the RedirectOut LFB is defined as a singleton input, but it
   is capable of receiving packets from multiple LFBs by multiplexing
   the singleton input.  Packets expected by the input will have
   arbitrary frame types.  All metadata associated with the input
   packets will be delivered to CE via a ForCES protocol redirect
   message [RFC5810].  The input will expect all types of metadata.

   There is no component defined for current version of RedirectOut LFB.
   Detailed XML definitions of the LFB can be found in Section 6.

5.6.

5.5.  General Purpose LFBs

5.6.1.
5.5.1.  BasicMetadataDispatch

   A basic medatata dispatch LFB is defined to abstract a process in
   which a packet is dispatched to some path based on its associated
   metadata value.

   The LFB is with a singleton input.  Packets of arbitrary frame types
   can input into the LFB.  Whereas, every input packet is required to
   be associated with a metadata that will be used by the LFB to do
   dispatch.  If a packet is not associated with such metadata, the
   packet will be dropped inside the LFB.

   A group of output is defined to output packets according to a
   MetaDispatchTable as defined a component in the LFB.  The table
   contains the fields of a metadata ID, a metadata value, and an output
   port index.  A packet, if it is associated with a metadata with the
   metadata ID, will be output to the group port instance with the index
   corresponding to the metadata value in the table.  The metadata value
   ussed by the table is required with an interger data type.  This
   means this LFB currently only allow a metadata with an interger value
   to be used for dispatch.

   Moreover, the LFB is defined with only one metadata adopted for
   dispatch, i.e., the metadata ID in the dispatch table is always the
   same for all table rows.

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

5.6.2.

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

   The LFB describes scheduling process in the following model:

   o  It is with a group input and expects packets with arbitrary frame
      types to arrive for scheduling.  The group input is capable of
      multiple input port instances.  Each port instance may be
      connected to different upstream LFB output.  No metadata is
      expected for each input packet.

   o  Multiple queues reside at the input side, with every input port
      instance connected to one queue.

   o  Every queue is marked with a queue ID, and the queue ID is exactly
      the same as the index of corresponding input port instance.

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

   o  Scheduled packets are output from a singleton output port of the
      LFB.

   Two LFB components are defined to further describe above model.  A
   scheduling discipline component is defined for CE to specify a
   scheduling discipline to the LFB.  Currently defined scheduling
   disciplines only include FIFO and round robin(RR).  For FIFO, we
   limit above model that when a FIFO discipline is applied, it is
   require that there is only one input port instance for the group
   input.  If user accidentally defines multiple input port instances
   for FIFO scheduling, only packets in the input port with lowest port
   index will be scheduled to output port, and all packets in other
   input port instances will just ignored.

   We specify that if the generic scheduler LFB is defined only one
   input port instance, the default scheduling discipline is FIFO.  If
   the LFB is defined with more than one input port instances, the
   default scheduling discipline is round robin (RR).

   A current queue depth component is defined to allow CE to query every
   queue status of the scheduler.  Using the queue ID as the index, CE
   can query every queue for its used length in unit of packets or
   bytes.

   Several capabilities are defined for the LFB.  A queue number limit
   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 types
   supported by the FE to CE.  Queue length limit provides the
   capability of storage ability for every queue.

   More complex scheduler LFB may be defined with more complex
   scheduling discipline by succeeding this LFB.  For instance, a
   priority scheduler LFB may be defined only by inheriting this LFB 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 input port of the EtherPHYLFB. 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 output port of the EtherPHYLFB. 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>EthernetII</ref>
                     <ref>EthernetAll</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>PHYPortID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component componentID="1" access="read-write"> access="read-only">
               <name>PHYPortID</name>
               <synopsis>The ID of the physical port that this LFB
               handles.</synopsis>
               <typeRef>uint32</typeRef>
            </component>
            <component componentID="2" access="read-write">
               <name>AdminStatus</name>
               <synopsis>Admin Status status of the LFB</synopsis>
               <typeRef>PortStatusValues</typeRef>
               <defaultValue>2</defaultValue>
            </component>
            <component componentID="3" access="read-only">
               <name>OperStatus</name>
               <synopsis>Operational Status status of the LFB.</synopsis>
               <typeRef>PortStatusValues</typeRef>
            </component>
            <component componentID="4" access="read-write">
               <name>AdminLinkSpeed</name>
               <synopsis>The link speed that the admin has requested.
               </synopsis>
               <typeRef>LANSpeedType</typeRef>
               <defaultValue>0x00000005</defaultValue>
            </component>
            <component componentID="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 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 the Carrier. Whether 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 the status of the Physical port is
               changed,the 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 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.

                speed.</synopsis>

               </synopsis>
               <eventTarget>
                  <eventField>OperDuplexMode</eventField>
               </eventTarget>
               <eventChanged/>
               <eventReports>
                  <eventReport>
                     <eventField>OperDuplexMode</eventField>
                  </eventReport>
               </eventReports>
            </event>
         </events>
      </LFBClassDef>
      <LFBClassDef LFBClassID="4">
         <name>EtherMACIn</name>
          <synopsis>a
         <synopsis>An LFB abstracts an Ethernet port at MAC data link
         layer. Multiple 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>EtherMACIn</name>
               <synopsis>The Input Port input port of the EtherMACIn. It
               expects any kind of Ethernet frame.</synopsis>
               <expectation>
                  <frameExpected>
                     <ref>EthernetAll</ref>
                  </frameExpected>
                  <metadataExpected>
                     <ref>PHYPortID</ref>
                  </metadataExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort group="false">
               <name>NormalPathOut</name>
               <synopsis>The Normal Output Port normal output port of the 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>EthernetAll</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>PHYPortID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
            <outputPort>
               <name>L2BridgingPathOut</name>
               <synopsis>The Bridging Output Port of the 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>EthernetAll</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>PHYPortID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component componentID="1" access="read-write">
               <name>AdminStatus</name>
               <synopsis>Admin Status 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> 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 flow control</synopsis>
               <typeRef>boolean</typeRef>
               <defaultValue>false</defaultValue>
            </component>
            <component componentID="6" access="read-write">
               <name>RxFlowControl</name>
               <synopsis>Receive Flow flow control</synopsis>
               <typeRef>boolean</typeRef>
               <defaultValue>false</defaultValue>
            </component>
            <component componentID="7" access="read-write">
                <name>MTU</name>
                <synopsis>Maximum Transmission Unit</synopsis>
                <typeRef>uint32</typeRef>
             </component>
             <component componentID="8" access="read-reset">
               <name>MACInStats</name>
               <synopsis>MACIn statistics</synopsis>
               <typeRef>MACInStatsType</typeRef>
            </component>
         </components>
      </LFBClassDef>
      <LFBClassDef LFBClassID="5">
         <name>EtherClassifier</name>
          <synopsis>LFB that decapsulates
         <synopsis>This LFB abstracts the process to decapsulate
          Ethernet II packets and
          classifies them.</synopsis> classify the data packets into
          various network layer data packets according to information
           included in 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>Classify Out</synopsis>
               <synopsis>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>
                <array>
               <typeRef>EtherDispatchTableType</typeRef>
                </array>
            </component>
            <component access="read-write" componentID="2">
               <name>VlanInputTable</name>
               <synopsis>Vlan input table</synopsis>
                <array>
               <typeRef>VlanInputTableType</typeRef>
                </array>
            </component>
            <component access="read-reset" componentID="3">
               <name>EtherClassifyStats</name>
               <synopsis>Ether Classify classify statistic table</synopsis>
                <array>
                   <typeRef>EtherClassifyStatsType</typeRef>
                </array>
               <typeRef>EtherClassifyStatsTableType</typeRef>
            </component>
         </components>
          <capabilities>
             <capability componentID="30">
                <name>MaxOutputPorts</name>
                <synopsis>Maximum number of ports in the output
                group.</synopsis>
                <typeRef>uint32</typeRef>
             </capability>
          </capabilities>
       </LFBClassDef>
      <LFBClassDef LFBClassID="6">
         <name>EtherEncapsulator</name>
          <synopsis>A
         <synopsis>This LFB that performs abstracts the process to encapsulate IP
         packets ethernet to Ethernet packets according to the L2
          encapsulation.</synopsis> 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>
                   <one-of>
                      <ref>NexthopIPv4Addr</ref>
                      <ref>NexthopIPv6Addr</ref>
                   </one-of>
                   <ref>OutputLogicalPortID</ref>
                  <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 have found
               Ethernet L2 information and have been successfully
               encapsulated to an Ethernet packet.</synopsis>
               <product>
                  <frameProduced>
                     <ref>IPv4</ref>
                     <ref>IPv6</ref>
                  </frameProduced>
                  <metadataProduced>
                      <ref>OutputLogicalPortID</ref>
                   </metadataProduced>
                </product>
             </outputPort>
             <outputPort group="false">
                <name>PakcetNoARPOut</name>
                <synopsis>Output port for packets can't find the
                associated L2 information in the ARP table.</synopsis>
                <product>
                   <frameProduced>
                      <ref>IPv4</ref>
                   </frameProduced>
                   <metadataProduced>
                      <ref>OutputLogicalPortID</ref>
                      <ref>NexthopIPv4Addr</ref>
                      <ref availability="conditional">VlanPriority</ref>
                   </metadataProduced>
                </product>
             </outputPort>
             <outputPort group="false">
                <name>PakcetNoNbrOut</name>
                <synopsis>Output port for packets can't find the
                associated L2 information in the Nbr table.</synopsis>
                <product>
                   <frameProduced>
                      <ref>IPv6</ref>
                   </frameProduced>
                   <metadataProduced>
                      <ref>OutputLogicalPortID</ref>
                      <ref>NexthopIPv6Addr</ref>
                      <ref availability="conditional">VlanPriority</ref>
                     <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>OutputLogicalPortID</ref>
                      <one-of>
                         <ref>NexthopIPv4Addr</ref>
                         <ref>NexthopIPv6Addr</ref>
                      </one-of>
                     <ref>MediaEncapInfoIndex</ref>
                     <ref availability="conditional">VlanPriority</ref>
                  </metadataProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component componentID="1" access="read-write">
                <name>ArpTable</name>
                <synopsis>ARP table.</synopsis>
                <array type="variable-size">
                   <typeRef>ArpTableType</typeRef>

                </array>
             </component>
             <component componentID="2" access="read-write">
                <name>NbrTable</name>
                <synopsis>Nbr table.</synopsis>
                <array type="variable-size">
                   <typeRef>NbrTableType</typeRef>
                </array>
             </component>
             <component componentID="3" access="read-write">
                <name>VLANOutputTable</name>
                <synopsis>VLAN output
               <name>EncapTable</name>
               <synopsis>Ethernet Encapsulation table.</synopsis>
                <array type="variable-size">
                   <typeRef>VLANOutputTableType</typeRef>
                </array>
               <typeRef>EncapTableType</typeRef>
            </component>
         </components>
      </LFBClassDef>
      <LFBClassDef LFBClassID="7">
         <name>EtherMACOut</name>
         <synopsis>EtherMACOut LFB abstracts an Ethernet port at MAC
         data link layer. It specifically describes Ethernet packet
         output process. Ethernet output functions are closely related
         to Ethernet input functions, therefore many some components
         defined in 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 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 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>EthernetAll</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>PHYPortID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component componentID="1" access="read-only">
                <name>OperStatus</name>
                <synopsis>Operational Status access="read-write">
               <name>AdminStatus</name>
               <synopsis>Admin status of the LFB.</synopsis>
                <typeRef>PortStatusValues</typeRef> port. It is the alias of
               "AdminStatus" component 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</synopsis>
                <typeRef>boolean</typeRef>
                <defaultValue>false</defaultValue> flow control. It is the alias of
               "TxFlowControl" component defined in EtherMACIn.
               </synopsis>
               <alias>boolean</alias>
            </component>
            <component componentID="3" componentID="4" access="read-write">
               <name>RxFlowControl</name>
               <synopsis>Receive Flow control</synopsis>
                <typeRef>boolean</typeRef>
                <defaultValue>false</defaultValue> flow control. It is the alias of
               "RxFlowControl" component defined in EtherMACIn.
               </synopsis>
               <alias>boolean</alias>
            </component>
            <component componentID="4" 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>a
         <synopsis>An LFB that performs IPv4 packets validation
         according to RFC1812 RFC1812. At the same time, ipv4 unicast and RFC2644.</synopsis>
         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>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>Ether classify dispatch table</synopsis>
               <synopsis>IPv4 validator statistics information.
               </synopsis>
               <typeRef>IPv4ValidatorStatisticsType</typeRef>
            </component>
         </components>

       </LFBClassDef>
      <LFBClassDef LFBClassID="9">
         <name>IPv6Validator</name>
          <synopsis>A
         <synopsis>An LFB that performs IPv6 packets validation
         according to RFC2460 RFC2460. At the same time, ipv6 unicast and RFC4291.</synopsis>
         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>Ether classify dispatch table</synopsis>
               <synopsis>IPv6 validator statistics information.
               </synopsis>
               <typeRef>IPv6ValidatorStatisticsType</typeRef>
            </component>
         </components>
       </LFBClassDef>
      <LFBClassDef LFBClassID="10">
         <name>IPv4UcastLPM </name>
          <synopsis>a
         <synopsis>An LFB that performs IPv4 Longest Prefix Match
          Lookup.</synopsis>
         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>
                <metadataExpected>
                   <ref>DstIPv4Address</ref>
                </metadataExpected>
               </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>
                <array type="variable-size"> prefix table.</synopsis>
               <typeRef>IPv4PrefixTableType</typeRef>

                </array>
            </component>
            <component componentID="2" access="read-reset">
               <name>IPv4UcastLPMStats</name>
               <synopsis>Statistics for IPv4 Unicast Longest Prefix
               Match</synopsis>
               <typeRef>IPv4UcastLPMStatsType</typeRef>
            </component>
         </components>

      </LFBClassDef>
      <LFBClassDef LFBClassID="11">
         <name>IPv6UcastLPM </name>
          <synopsis>A
         <synopsis>An LFB that performs IPv6 Longest Prefix Match
          Lookup.</synopsis>
         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>
                <metadataExpected>
                   <ref>DstIPv6Address</ref>
                </metadataExpected>
               </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>
                <array type="variable-size"> prefix table.</synopsis>
               <typeRef>IPv6PrefixTableType</typeRef>
                </array>
            </component>
            <component componentID="2" access="read-reset">
               <name>IPv6UcastLPMStats</name>
               <synopsis>Statistics for IPv6 Unicast Longest Prefix
               Match</synopsis>
               <typeRef>IPv6UcastLPMStatsType</typeRef>
            </component>
         </components>
      </LFBClassDef>
      <LFBClassDef LFBClassID="12">
         <name>IPv4NextHop</name>
          <synopsis>A
         <synopsis>This LFB for applicating abstracts the process of selecting ipv4
         next hop action to action. It receives an IPv4
          packets,the actions include:TTL operation,checksum
          recalculation. The input packets packet with an
         associated next hop ID, and uses the metadata
          "HopSelector"(the nexthop ID), get the nexthop
          information through looking ID to look up nexthop table.</synopsis> 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>OutputLogicalPortID</ref>
                     <ref>NextHopIPv4Addr</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>
                <array> next hop table.</synopsis>
               <typeRef>IPv4NextHopTableType</typeRef>
                </array>
            </component>
         </components>
          <capabilities>
             <capability componentID="30">
                <name>MaxOutputPorts</name>
                <synopsis>Maximum number of ports in the output group.
                </synopsis>
                <typeRef>uint32</typeRef>
             </capability>
          </capabilities>
      </LFBClassDef>
      <LFBClassDef LFBClassID="13">
         <name>IPv6NextHop</name>
          <synopsis>A
         <synopsis>The LFB definition for applicating abstracts the process of next hop action
         information application to IPv6 packets. The input packets It receives an IPv4
         packet with an associated next hop ID, and uses the metadata
           "HopSelector"(the nexthop ID), get the nexthop information
          through looking ID to
         look up nexthop table.</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 a next hop table to
                be forwarded</synopsis>
                <product>
                   <frameProduced>
                      <ref>IPv6Unicast</ref>
                   </frameProduced>
                   <metadataProduced>
                      <ref>OutputLogicalPortID</ref>
                      <ref>NextHopIPv6Addr</ref>
                   </metadataProduced>
                </product>
             </outputPort>
             <outputPort group="false">
                <name>ExceptionOut</name>
                <synopsis>The output for the packet if find 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>
                <array>
                   <typeRef>IPv6NextHopTableType</typeRef>
                </array>
             </component>
          </components>
          <capabilities>
             <capability componentID="30">
                <name>MaxOutputPorts</name>
                <synopsis>Maximum number of ports in the appropriate output group.
                </synopsis>
                <typeRef>uint32</typeRef>
             </capability>
          </capabilities>
       </LFBClassDef>
       <LFBClassDef LFBClassID="14">
          <name>ARP</name>
          <synopsis>ARP</synopsis> port
         from the LFB..</synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort group="false">
                <name>ArpPktsIn</name>
                <synopsis>The input port for ARP packets.</synopsis>
                <expectation>
                      <frameExpected>
                         <ref>ARP</ref>
                      </frameExpected>
                      <metadataExpected>
                         <ref>PHYPortID</ref>
                         <ref>LogicalPortID</ref>
                         <ref>SrcMAC</ref>
                         <ref>DstMAC</ref>

                      </metadataExpected>
                   </expectation>
                </inputPort>
             <inputPort group="false">
                <name>AddrResDataPktsIn</name>
                <synopsis>The input port for the
               <name>PktsIn</name>
               <synopsis>A single packet which need
                address resolution..</synopsis> input.</synopsis>
               <expectation>
               <frameExpected>
                         <ref>IPv4</ref>
                  <ref>IPv6Unicast</ref>
               </frameExpected>
               <metadataExpected>
                         <ref>NexthopIPv4Addr</ref>
                         <ref>OutputLogicalPortID</ref>
                         <ref dependency="optional" defaultValue="0">
                         VlanID</ref>
                         <ref dependency="optional" defaultValue="0">
                         VlanPriority</ref>
                  <ref>HopSelector</ref>
               </metadataExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort group="false">
                <name>ArpPktsOut</name> group="true">
               <name>SuccessOut</name>
               <synopsis>The output port for Arp packets.</synopsis> the packet if it is valid to
               be forwarded</synopsis>
               <product>
                  <frameProduced>
                      <ref>EthernetII</ref>
                     <ref>IPv6Unicast</ref>
                  </frameProduced>
                  <metadataProduced>
                     <ref>OutputLogicalPortID</ref>
                     <ref>NextHopIPv6Addr</ref>
                  </metadataProduced>
               </product>
            </outputPort>
            <outputPort group="false">
                <name>AddrResDataPktsOut</name>
               <name>ExceptionOut</name>
               <synopsis>The output port for the packet which has been
                encapsulated with the L2 head.</synopsis> if an exception
               occurs</synopsis>
               <product>
                  <frameProduced>
                      <ref>EthernetII</ref>
                     <ref>IPv6Unicast</ref>
                  </frameProduced>
                  <metadataProduced>
                      <ref>OutputLogicalPortID</ref>
                     <ref>ExceptionID</ref>
                  </metadataProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component componentID="1">
                <name>PortV4AddrInfoTable</name>
               <name>IPv6NextHopTable</name>
               <synopsis>The IPv4 address for all local ports.
                </synopsis>
                <array>
                   <typeRef>Portv4AddrInfoTableType</typeRef>
                </array> next hop table.</synopsis>
               <typeRef>IPv6NextHopTableType</typeRef>
            </component>
         </components>
      </LFBClassDef>
      <LFBClassDef LFBClassID="15">
          <name>ND</name>
          <synopsis>TBD</synopsis>
          <version>1.0</version>
       </LFBClassDef>
       <LFBClassDef LFBClassID="16"> 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. From LFB topology point of view,
           the RedirectIn LFB acts as a source point for data packets
           coming from CE, therefore the RedirectIn LFB is defined with
          only one output, while without any input. Output of the
          RedirectIn LFB is defined as a group output. Packets produced
          by the output will have arbitrary frame types decided by CE
          which generates the packets. Possible frames may include IPv4,
          IPv6, or ARP protocol packets. CE may associate some metadata
          to indicate the frame types. CE may also associate other
          metadata to data packets to indicate various information on
          the packets. Among them, there MUST exist a 'RedirectIndex'
          metadata, which is an integer acting as an index. When CE
          transmits the metadata and a binging packet to a RedirectIn
          LFB, the LFB will read the metadata and output the packet to
          one of its group output port instance, whose port index is
          just topology, so as indicated by the metadata.All metadata from to input data
          packets into FE data paths. CE other
          than the 'RedirectIndex' may associate some
         metadata will output from to data packets to indicate various information on
         the
          RedirectIn LFB along with their binding packets. Note that,
          a packet without Among them, there MUST exist a 'RedirectIndex' metadata associated
          will be dropped by the LFB.</synopsis>
         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>
          <capabilities>
             <capability componentID="30">
                <name>MaxOutputPorts</name>
                <synopsis>Maximum number of ports in the output group
                </synopsis>
                <typeRef>uint32</typeRef>
             </capability>
          </capabilities>
      </LFBClassDef>
      <LFBClassDef LFBClassID="17"> LFBClassID="15">
         <name>RedirectOut</name>
          <synopsis>A RedirectOut
         <synopsis>The LFB abstracts the process for LFBs in
         FE to deliver data packets to CE. From LFB topology point of
          view, the RedirectOut LFB acts as a sink point for data
          packets going to CE, therefore the RedirectOut LFB is defined
          with only one input, while without any output.Input of the
          RedirectOut LFB is defined as a singleton input, but it is
          capable of receiving packets from multiple LFBs by
          multiplexing the singleton input. Packets expected by the
          input will have arbitrary frame types. All metadata
         associated with the input packets will be delivered to CE
         via the redirect message of ForCES protocol [RFC5810],
          therefore the input will expect all types of metadata. [RFC5810].
         </synopsis>
         <version>1.0</version>
         <inputPorts>
            <inputPort group="false">
               <name>PktsIn</name>
               <synopsis>This input group receives packets to send to
               the CE.</synopsis>
               <expectation>
                  <frameExpected>
                     <ref>Arbitrary</ref>
                  </frameExpected>
               </expectation>
            </inputPort>
         </inputPorts>
      </LFBClassDef>
      <LFBClassDef LFBClassID="18"> 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.</synopsis> 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>PacketsIn</name>
               <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>PacketsOut</name>
               <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
               <synopsis>Metadata dispatch table.</synopsis>
               <typeRef>MetadataDispatchTableType</typeRef>
            </component>
         </components>
          <capabilities>
             <capability componentID="30">
                <name>MaxOutputPorts</name>
                <synopsis>Maxium number of ports in the output group.
                </synopsis>
                <typeRef>uint32</typeRef>
             </capability>
          </capabilities>
       </LFBClassDef>
      <LFBClassDef LFBClassID="19"> LFBClassID="17">
         <name>GenericScheduler</name>
          <synopsis>Generic Scheduler LFB.</synopsis>
         <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>PacketsIn</name>
               <name>PktsIn</name>
               <synopsis>Input port for data packet.</synopsis>
               <expectation>
                  <frameExpected>
                     <ref>Arbitrary</ref>
                  </frameExpected>
               </expectation>
            </inputPort>
         </inputPorts>
         <outputPorts>
            <outputPort>
                <name>PacketsOut</name>
               <name>PktsOut</name>
               <synopsis>Data packet output</synopsis> output.</synopsis>
               <product>
                  <frameProduced>
                     <ref>Arbitrary</ref>
                  </frameProduced>
               </product>
            </outputPort>
         </outputPorts>
         <components>
            <component access="read-only" componentID="1">
               <name>QueueCount</name>
                <synopsis>the
               <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>
                <array>
                   <typeRef>QueueDepth</typeRef>
                </array>
               <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 typical
   router functions.

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

   o  IP forwarding

   o  address resolution

   o  ICMP

   o  network management

   o  running routing protocol

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

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

7.1.  IP Forwarding

   TBD

7.2.  Address Resolution

   TBD

7.3.  ICMP

   TBD

7.4.  Running Routing Protocol

   TBD

7.5.  Network Management

   TBD

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

   (TBD)

11.  Security Considerations

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

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@mail.zjgsu.edu.cn 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