Internet Engineering Task Force W. Wang
Internet-Draft Zhejiang Gongshang University
Intended status: Standards Track E. Haleplidis
Expires: January 11, 2012 University of Patras
K. Ogawa
NTT Corporation
C. Li
Hangzhou BAUD Networks
J. Halpern
Ericsson
July 10, 2011
ForCES Logical Function Block (LFB) Library
draft-ietf-forces-lfb-lib-05
Abstract
This document defines basic classes of Logical Function Blocks (LFBs)
used in the Forwarding and Control Element Separation (ForCES). The
basic LFB classes are defined according to ForCES FE model [RFC5812]
and ForCES protocol [RFC5810] specifications, and are scoped to meet
requirements of typical router functions and considered as the basic
LFB library for ForCES. The library includes the descriptions of the
LFBs and the XML definitions.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 11, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wang, et al. Expires January 11, 2012 [Page 1]
Internet-Draft ForCES LFB Library July 2011
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Terminology and Conventions . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Scope of the Library . . . . . . . . . . . . . . . . . . . 7
3.2. Overview of LFB Classes in the Library . . . . . . . . . . 9
3.2.1. LFB Design Choices . . . . . . . . . . . . . . . . . . 9
3.2.2. LFB Class Groupings . . . . . . . . . . . . . . . . . 9
3.2.3. Sample LFB Class Application . . . . . . . . . . . . . 11
3.3. Document Structure . . . . . . . . . . . . . . . . . . . . 12
4. Base Types . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.1. Atomic . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.2. Compound struct . . . . . . . . . . . . . . . . . . . 15
4.1.3. Compound array . . . . . . . . . . . . . . . . . . . . 15
4.2. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. MetaData Types . . . . . . . . . . . . . . . . . . . . . . 16
4.4. XML for Base Type Library . . . . . . . . . . . . . . . . 17
5. LFB Class Description . . . . . . . . . . . . . . . . . . . . 38
5.1. Ethernet Processing LFBs . . . . . . . . . . . . . . . . . 38
5.1.1. EtherPHYCop . . . . . . . . . . . . . . . . . . . . . 38
5.1.2. EtherMACIn . . . . . . . . . . . . . . . . . . . . . . 40
5.1.3. EtherClassifier . . . . . . . . . . . . . . . . . . . 42
5.1.4. EtherEncap . . . . . . . . . . . . . . . . . . . . . . 44
5.1.5. EtherMACOut . . . . . . . . . . . . . . . . . . . . . 46
5.2. IP Packet Validation LFBs . . . . . . . . . . . . . . . . 47
5.2.1. IPv4Validator . . . . . . . . . . . . . . . . . . . . 47
5.2.2. IPv6Validator . . . . . . . . . . . . . . . . . . . . 49
5.3. IP Forwarding LFBs . . . . . . . . . . . . . . . . . . . . 51
5.3.1. IPv4UcastLPM . . . . . . . . . . . . . . . . . . . . . 51
5.3.2. IPv4NextHop . . . . . . . . . . . . . . . . . . . . . 53
5.3.3. IPv6UcastLPM . . . . . . . . . . . . . . . . . . . . . 55
5.3.4. IPv6NextHop . . . . . . . . . . . . . . . . . . . . . 57
5.4. Redirect LFBs . . . . . . . . . . . . . . . . . . . . . . 58
5.4.1. RedirectIn . . . . . . . . . . . . . . . . . . . . . . 59
Wang, et al. Expires January 11, 2012 [Page 2]
Internet-Draft ForCES LFB Library July 2011
5.4.2. RedirectOut . . . . . . . . . . . . . . . . . . . . . 59
5.5. General Purpose LFBs . . . . . . . . . . . . . . . . . . . 60
5.5.1. BasicMetadataDispatch . . . . . . . . . . . . . . . . 60
5.5.2. GenericScheduler . . . . . . . . . . . . . . . . . . . 61
6. XML for LFB Library . . . . . . . . . . . . . . . . . . . . . 64
7. LFB Class Use Cases . . . . . . . . . . . . . . . . . . . . . 86
7.1. IPv4 Forwarding . . . . . . . . . . . . . . . . . . . . . 86
7.2. ARP processing . . . . . . . . . . . . . . . . . . . . . . 87
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 90
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 91
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 92
10.1. LFB Class Names and LFB Class Identifiers . . . . . . . . 92
10.2. Metadata ID . . . . . . . . . . . . . . . . . . . . . . . 94
10.3. Exception ID . . . . . . . . . . . . . . . . . . . . . . . 94
10.4. Validate Error ID . . . . . . . . . . . . . . . . . . . . 95
11. Security Considerations . . . . . . . . . . . . . . . . . . . 97
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 98
12.1. Normative References . . . . . . . . . . . . . . . . . . . 98
12.2. Informative References . . . . . . . . . . . . . . . . . . 98
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 99
Wang, et al. Expires January 11, 2012 [Page 3]
Internet-Draft ForCES LFB Library July 2011
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].
Wang, et al. Expires January 11, 2012 [Page 4]
Internet-Draft ForCES LFB Library July 2011
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
Wang, et al. Expires January 11, 2012 [Page 5]
Internet-Draft ForCES LFB Library July 2011
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.
Wang, et al. Expires January 11, 2012 [Page 6]
Internet-Draft ForCES LFB Library July 2011
3. Introduction
RFC 3746 [RFC3746] specifies Forwarding and Control Element
Separation (ForCES) framework. In the framework, Control Elements
(CEs) configure and manage one or more separate Forwarding Elements
(FEs) within a Network Element (NE) by use of a ForCES protocol. RFC
5810 [RFC5810] specifies the ForCES protocol. RFC 5812 [RFC5812]
specifies the Forwarding Element (FE) model. In the model, resources
in FEs are described by classes of Logical Function Blocks (LFBs).
The FE model defines the structure and abstract semantics of LFBs,
and provides XML schema for the definitions of LFBs.
This document conforms to the specifications of the FE model
[RFC5812] and specifies detailed definitions of classes of LFBs,
including detailed XML definitions of LFBs. These LFBs form a base
LFB library for ForCES. LFBs in the base library are expected to be
combined to form an LFB topology for a typical router to implement IP
forwarding. It should be emphasized that an LFB is an abstraction of
functions rather than its implementation details. The purpose of the
LFB definitions is to represent functions so as to provide
interoperability between separate CEs and FEs.
More LFB classes with more functions may be developed in future time
and documented by IETF. Vendors may also develop proprietary LFB
classes as described in the FE model [RFC5812].
3.1. Scope of the Library
It is intended that the LFB classes described in this document are
designed to provide the functions of a typical router. RFC 1812
specifies that a typical router is expected to provide functions to:
(1) Interface to packet networks and implement the functions required
by that network. These functions typically include:
o Encapsulating and decapsulating the IP datagrams with the
connected network framing (e.g., an Ethernet header and checksum),
o Sending and receiving IP datagrams up to the maximum size
supported by that network, this size is the network's Maximum
Transmission Unit or MTU,
o Translating the IP destination address into an appropriate
network-level address for the connected network (e.g., an Ethernet
hardware address), if needed, and
o Responding to network flow control and error indications, if any.
Wang, et al. Expires January 11, 2012 [Page 7]
Internet-Draft ForCES LFB Library July 2011
(2) Conform to specific Internet protocols including the Internet
Protocol (IPv4 and/or IPv6), Internet Control Message Protocol
(ICMP), and others as necessary.
(3) Receive and forwards Internet datagrams. Important issues in
this process are buffer management, congestion control, and fairness.
o Recognizes error conditions and generates ICMP error and
information messages as required.
o Drops datagrams whose time-to-live fields have reached zero.
o Fragments datagrams when necessary to fit into the MTU of the next
network.
(4) Choose a next-hop destination for each IP datagram, based on the
information in its routing database.
(5) Usually support an interior gateway protocol (IGP) to carry out
distributed routing and reachability algorithms with the other
routers in the same autonomous system. In addition, some routers
will need to support an exterior gateway protocol (EGP) to exchange
topological information with other autonomous systems. For all
routers, it is essential to provide ability to manage static routing
items.
(6) Provide network management and system support facilities,
including loading, debugging, status reporting, exception reporting
and control.
The classical IP router utilizing the ForCES framework constitutes a
CE running some controlling IGP and/or EGP function and FEs
implementing using Logical Function Blocks (LFBs) conforming to the
FE model[RFC5812] specifications. The CE, in conformance to the
ForCES protocol[RFC5810] and the FE model [RFC5812] specifications,
instructs the LFBs on the FE how to treat received/sent packets.
Packets in an IP router are received and transmitted on physical
media typically referred to as "ports". Different physical port
media will have different way for encapsulating outgoing frames and
decapsulating incoming frames. The different physical media will
also have different attributes that influence its behavior and how
frames get encapsulated or decapsulated. This document will only
deal with Ethernet physical media. Other future documents may deal
with other types of media. This document will also interchangeably
refer to a port to be an abstraction that constitutes a PHY and a MAC
as described by the LFBs like EtherPHYCop, EtherMACIn, and
EtherMACOut.
Wang, et al. Expires January 11, 2012 [Page 8]
Internet-Draft ForCES LFB Library July 2011
IP packets emanating from port LFBs are then processed by a
validation LFB before being further forwarded to the next LFB. After
the validation process the packet is passed to an LFB where IP
forwarding decision is made. In the IP Forwarding LFBs, a Longest
Prefix Match LFB is used to look up the destination information in a
packet and select a next hop index for sending the packet onward. A
next hop LFB uses the next hop index metadata to apply the proper
headers to the IP packets, and direct them to the proper egress.
Note that in the process of IP packets processing, in this document,
we are adhering to the weak-host model[RFC1122] since that is the
most usable model for a packet processing Network Element.
3.2. Overview of LFB Classes in the Library
It is critical to classify functional requirements into various
classes of LFBs and construct a typical but also flexible enough base
LFB library for various IP forwarding equipments.
3.2.1. LFB Design Choices
A few design principles were factored into choosing how the base LFBs
looked like. These are:
o if a function can be designed by either one LFB or two or more
LFBs with the same cost, the choice is to go with two or more LFBs
so as to provide more flexibility for implementers.
o when flexibility is not required, an LFB should take advantage of
its independence as much as possible and have minimal coupling
with other LFBs. The coupling may be from LFB attributes
definitions as well as physical implementations.
o unless there is a clear difference in functionality, similar
packet processing should not be represented as two or more
different LFBs. Or else, it may add extra burden on
implementation to achieve interoperability.
3.2.2. LFB Class Groupings
The document defines groups of LFBs for typical router function
requirements:
(1) A group of Ethernet processing LFBs are defined to abstract the
packet processing for Ethernet as the port media type. As the most
popular media type with rich processing features, Ethernet media
processing LFBs was a natural choice. Definitions for processing of
other port media types like POS or ATM may be incorporated in the
library in future version of the document or in a future separate
Wang, et al. Expires January 11, 2012 [Page 9]
Internet-Draft ForCES LFB Library July 2011
document.
The following LFBs are defined for Ethernet processing:
EtherPHYCop (section 5.1.1)
EtherMACIn (section 5.1.2)
EtherClassifier (section 5.1.3)
EtherEncapsulator (section 5.1.4)
EtherMACOut (section 5.1.5)
(2) A group of LFBs are defined for IP packet validation process.
The following LFBs are defined for IP Validation processing:
IPv4Validator (section 5.2.1)
IPv6Validator (section 5.2.2)
(3) A group of LFBs are defined to abstract IP forwarding process.
The following LFBs are defined for IP Forwarding processing:
IPv4UcastLPM (section 5.3.1)
IPv4NextHop (section 5.3.2)
IPv6UcastLPM (section 5.3.4)
IPv6NextHop (section 5.3.4)
(4) A group of LFBs are defined to abstract the process for redirect
operation, i.e., data packet transmission between CE and FEs.
The following LFBs are defined for redirect processing:
RedirectIn (section 5.4.1)
RedirectOut (section 5.4.2)
(5) A group of LFBs are defined for abstracting some general purpose
packet processing. These processing processes are usually general to
many processing locations in an FE LFB topology.
The following LFBs are defined for redirect processing:
Wang, et al. Expires January 11, 2012 [Page 10]
Internet-Draft ForCES LFB Library July 2011
BasicMetadataDispatch (section 5.5.1)
GenericScheduler (section 5.5.2)
3.2.3. Sample LFB Class Application
Although section 7 will present use cases for LFBs defined in this
document, this section shows a sample LFB class application in
advance so that readers can get a quick overlook of the LFB classes
with the usage.
Figure 1 shows the typical LFB processing path for an IPv4 unicast
forwarding case with Ethernet media interfaces. To focus on the IP
forwarding function, some inputs or outputs of LFBs in the figure
that are not related to the function are ignored. Section 7.1 will
describe the figure in more details.
Wang, et al. Expires January 11, 2012 [Page 11]
Internet-Draft ForCES LFB Library July 2011
+-----+ +------+
| | | |
| |<---------------|Ether |<----------------------------+
| | |MACOut| |
| | | | |
|Ether| +------+ |
|PHY | |
|Cop | +---+ |
|#1 | +-----+ | |----->IPv6 Packets |
| | | | | | |
| | |Ether| | | IPv4 Packets |
| |->|MACIn|-->| |-+ +----+ |
+-----+ | | | | | | |---> Multicast Packets |
+-----+ +---+ | | | +-----+ +---+ |
Ether +->| |------->| | | | |
. Classifier| | |Unicast |IPv4 | | | |
. | | |Packets |Ucast|->| |--+ |
. | +----+ |LPM | | | | |
+---+ | IPv4 +-----+ +---+ | |
+-----+ | | | Validator IPv4 | |
| | | | | NextHop| |
+-----+ |Ether| | |-+ IPv4 Packets | |
| |->|MACIn|-->| | | |
| | | | | |----->IPv6 Packets | |
|Ether| +-----+ +---+ | |
|PHY | Ether +----+ | |
|Cop | Classifier | | +-------+ | |
|#n | +------+ | | |Ether | | |
| | | | | |<--|Encap |<-+ |
| | | |<------| | | | |
| |<---------------|Ether | ...| | +-------+ |
| | |MACOut| +---| | |
| | | | | +----+ |
+-----+ +------+ | BasicMetadataDispatch |
+-------------------------+
Figure 1: LFB use case for IPv4 forwarding
3.3. Document Structure
Base type definitions, including data types, packet frame types, and
etadata types are presented in advance for definitions of various LFB
classes. Section 4 (Base Types Section) provide a description on the
base types used by this LFB library. In order for an extensive use
of these base types for other LFB class definitions, the base type
definitions are provided by an xml file in a way as a library which
is separate from the LFB definition library.
Wang, et al. Expires January 11, 2012 [Page 12]
Internet-Draft ForCES LFB Library July 2011
Within every group of LFB classes, a set of LFBs are defined for
individual function purposes. Section 5 (LFB Class Descriptions
Section) makes text descriptions on the individual LFBs. Note that
for a complete definition of an LFB, a text description as well as a
XML definition is required.
LFB classes are finally defined by XML with specifications and schema
defined in the ForCES FE model[RFC5812]. Section 6 (XML LFB
Definitions Section) provide the complete XML definitions of the base
LFB classes library..
Section 7 provides several use cases on how some typical router
functions can be implemented using the base LFB library defined in
this document.
Wang, et al. Expires January 11, 2012 [Page 13]
Internet-Draft ForCES LFB Library July 2011
4. Base Types
TThe FE model [RFC5812] has specified predefined (built-in) atomic
data-types as below:
char, uchar, int16, uint16, int32, uint32, int64, uint64, string[N],
string, byte[N], boolean, octetstring[N], float16, float32, float64.
Based on the atomic data types and with the use of type definition
elements in the FE model XML schema, new data types, packet frame
types, and metadata types can be defined.
To define a base LFB library for typical router functions, a set of
base data types, frame types, and metadata types should be defined.
This section provides a brief description of the base types and a
full XML definition of them as well.
The base type XML definitions are provided with a separate XML
library file named "BaseTypeLibrary". Users can refer to this
library by the statement:
<load library="BaseTypeLibrary", location="..."/>
4.1. Data Types
Data types defined in the base type library are categorized by types
of atomic, compound struct, and compound array.
4.1.1. Atomic
The following data types are defined as atomic data types and put in
the base type library:
Data Type Name Brief Description
-------------- -----------------
IPv4Addr IPv4 address
IPv6Addr IPv6 address
IEEEMAC IEEE mac address.
LANSpeedType Network speed values
DuplexType Duplex types
PortStatusValues The possible values of port status, used for
both administrative and operative status.
SchdDisciplineType Scheduling discipline type.
Wang, et al. Expires January 11, 2012 [Page 14]
Internet-Draft ForCES LFB Library July 2011
4.1.2. Compound struct
The following compound struct types are defined in the base type
library:
Data Type Name Brief Description
-------------- -----------------
EtherDispatchEntryType Entry type for Ethernet dispatch table.
VlanInputTableEntryType Entry type for VLAN input table.
EncapTableEntryType Entry type for Ethernet encapsulation table.
MACInStatsType Statistics type for EtherMACIn LFB.
MACOutStatsType Statistics type for EtherMACOut LFB.
EtherClassifyStatsType Entry type for statistics table in
EtherClassifier LFB.
IPv4PrefixInfoType Entry type for IPv4 prefix table.
IPv6PrefixInfoType Entry type for IPv6 prefix table
IPv4NextHopInfoType Entry type for IPv4 next hop table.
IPv6NextHopInfoType Entry type for IPv6 next hop table.
IPv4ValidatorStatsType Statistics type in IPv4validator LFB.
IPv6ValidatorStatsType Statistics type in IPv6validator LFB.
IPv4UcastLPMStatsType Statistics type in IPv4Unicast LFB.
IPv6UcastLPMStatsType Statistics type in IPv6Unicast LFB.
QueueDepthType Entry type for queue depth table.
MetadataDispatchType Entry type for metadata dispatch table.
4.1.3. Compound array
Compound array types are mostly created based on compound struct
types for LFB table components. The following compound array types
are defined in this base type library:
Data Type Name Brief Description
-------------- -----------------
EtherClassifyStatsTableType Type for Ethernet classifier statistics
information table
EtherDispatchTableType Type for Ethernet dispatch table.
VlanInputTableType Type for VLAN input table.
EncapTableType Type for Ethernet encapsulation table.
IPv4PrefixTableType Type for IPv4 prefix table.
IPv6PrefixTableType Type for IPv6 prefix table.
IPv4NextHopTableType Type for IPv4 next hop table.
IPv6NextHopTableType Type for IPv6 next hop table.
MetadataDispatchTableType Type for Metadata dispatch table.
QueueDepthTableType Type for Queue depth table.
Wang, et al. Expires January 11, 2012 [Page 15]
Internet-Draft ForCES LFB Library July 2011
4.2. Frame Types
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 and emits at its output port. The <frameDef> element in
the FE model is used to define a new frame type.
The following frame types are defined in the base type library:
Frame Name Brief Description
-------------- ----------------
EthernetII An Ethernet II frame
ARP An ARP packet
IPv4 An IPv4 packet
IPv6 An IPv6 packet
IPv4Unicast An IPv4 unicast packet
IPv4Multicast An IPv4 multicast packet
IPv6Unicast An IPv6 unicast packet
IPv6Multicast An IPv6 multicast packet
Arbitrary Any types of packet frames
4.3. MetaData Types
LFB Metadata is used to communicate per-packet state from one LFB to
another. The <metadataDef> element in the FE model is used to define
a new metadata type.
The following metadata types are currently defined in the base type
library.
Wang, et al. Expires January 11, 2012 [Page 16]
Internet-Draft ForCES LFB Library July 2011
Metadata Name Metadata ID Brief Description
------------ ---------- -------------
PHYPortID 1 The physical port ID that the packet is
inputted.
SrcMAC 2 Source MAC address of the packet.
DstMAC 3 Destination MAC address of the packet.
LogicalPortID 4 ID of a logical port for the packet.
EtherType 5 Indicating the Ethernet type of the
Ethernet packet.
VlanID 6 The VLAN ID of the Ethernet packet.
VlanPriority 7 The priority of the Ethernet packet.
NexthopIPv4Addr 8 Nexthop IPv4 address the packet is sent to.
NexthopIPv6Addr 9 Nexthop IPv6 address the packet is sent to.
HopSelector 10 An index the packet can use to look up a
nexthop table for next hop information of
the packet.
ExceptionID 11 Indicating exception type of the packet
which is exceptional for some processing.
ValidateErrorID 12 Indicating error type of the packet failed
some validation process.
L3PortID 13 ID of L3 port.
RedirectIndex 14 A metadata CE sends to RedirectIn LFB for
the associated packet to select output
port in the LFB group output "PktsOut".
MediaEncapInfoIndex 15 An index the packet uses to look up a media
encapsulation table to select its
encapsulation media as well as followed
encapsulation LFB.
4.4. XML for Base Type Library
<?xml version="1.0" encoding="UTF-8"?>
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
provides="BaseTypeLibrary">
<frameDefs>
<frameDef>
<name>EthernetAll</name>
<synopsis>All kinds of Ethernet frame</synopsis>
</frameDef>
<frameDef>
<name>EthernetII</name>
<synopsis>An Ethernet II frame</synopsis>
</frameDef>
<frameDef>
<name>ARP</name>
<synopsis>An arp packet</synopsis>
Wang, et al. Expires January 11, 2012 [Page 17]
Internet-Draft ForCES LFB Library July 2011
</frameDef>
<frameDef>
<name>IPv4</name>
<synopsis>An IPv4 packet</synopsis>
</frameDef>
<frameDef>
<name>IPv6</name>
<synopsis>An IPv6 packet</synopsis>
</frameDef>
<frameDef>
<name>IPv4Unicast</name>
<synopsis>An IPv4 unicast packet</synopsis>
</frameDef>
<frameDef>
<name>IPv4Multicast</name>
<synopsis>An IPv4 multicast packet</synopsis>
</frameDef>
<frameDef>
<name>IPv6Unicast</name>
<synopsis>An IPv6 unicast packet</synopsis>
</frameDef>
<frameDef>
<name>IPv6Multicast</name>
<synopsis>An IPv6 multicast packet</synopsis>
</frameDef>
<frameDef>
<name>Arbitrary</name>
<synopsis>Any types of packet frames</synopsis>
</frameDef>
</frameDefs>
<dataTypeDefs>
<dataTypeDef>
<name>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 address.</synopsis>
<typeRef>byte[6]</typeRef>
</dataTypeDef>
<dataTypeDef>
<name>LANSpeedType</name>
Wang, et al. Expires January 11, 2012 [Page 18]
Internet-Draft ForCES LFB Library July 2011
<synopsis>Network speed values</synopsis>
<atomic>
<baseType>uint32</baseType>
<specialValues>
<specialValue value="0x00000001">
<name>LAN_SPEED_10M</name>
<synopsis>10M Ethernet</synopsis>
</specialValue>
<specialValue value="0x00000002">
<name>LAN_SPEED_100M</name>
<synopsis>100M Ethernet</synopsis>
</specialValue>
<specialValue value="0x00000003">
<name>LAN_SPEED_1G</name>
<synopsis>1000M Ethernet</synopsis>
</specialValue>
<specialValue value="0x00000004">
<name>LAN_SPEED_10G</name>
<synopsis>10G Ethernet</synopsis>
</specialValue>
<specialValue value="0x00000005">
<name>LAN_SPEED_AUTO</name>
<synopsis>LAN speed auto</synopsis>
</specialValue>
</specialValues>
</atomic>
</dataTypeDef>
<dataTypeDef>
<name>DuplexType</name>
<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 -->
Wang, et al. Expires January 11, 2012 [Page 19]
Internet-Draft ForCES LFB Library July 2011
</dataTypeDef>
<dataTypeDef>
<name>PortStatusValues</name>
<synopsis>The possible values of port status, used for both
administrative and operative 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>Statistics type in EtherMACIn.</synopsis>
<struct>
<component componentID="1">
<name>NumPacketsReceived</name>
<synopsis>The number of packets received.</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name>NumPacketsDropped</name>
<synopsis>The number of packets dropped.</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>MACOutStatsType</name>
<synopsis>Statistics type in EtherMACOut.</synopsis>
<struct>
<component componentID="1">
<name>NumPacketsTransmitted</name>
<synopsis>The number of packets transmitted.</synopsis>
<typeRef>uint64</typeRef>
</component>
Wang, et al. Expires January 11, 2012 [Page 20]
Internet-Draft ForCES LFB Library July 2011
<component componentID="2">
<name>NumPacketsDropped</name>
<synopsis>The number of packets dropped.</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>EtherDispatchEntryType</name>
<synopsis>Entry type for Ethernet dispatch table.</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>LFBOutputSelectIndex</name>
<synopsis>LFB Group output port index to select
downstream LFB port. Some possibilities of downstream
LFB instances are:
a) IPv4Validator
b) IPv6Validator
c) RedirectOut
d) etc
Note: LFBOutputSelectIndex is the FromPortIndex for
the port group "ClassifyOut" in the table LFBTopology
(of FEObject LFB) as defined for the EtherClassifier
LFB.</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>EtherDispatchTableType</name>
<synopsis>Type for Ethernet dispatch table.</synopsis>
<array type="variable-size">
<typeRef>EtherDispatchEntryType</typeRef>
</array>
</dataTypeDef>
<dataTypeDef>
<name>VlanInputTableEntryType</name>
Wang, et al. Expires January 11, 2012 [Page 21]
Internet-Draft ForCES LFB Library July 2011
<synopsis>Entry type for VLAN input table.</synopsis>
<struct>
<component componentID="1">
<name>IncomingPortID</name>
<synopsis>The incoming port ID.</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>VlanID</name>
<synopsis>Vlan ID.</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>LogicalPortID</name>
<synopsis>logical port ID.</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>VlanInputTableType</name>
<synopsis>Type for VLAN input table.</synopsis>
<array type="variable-size">
<typeRef>VlanInputTableEntryType</typeRef>
</array>
</dataTypeDef>
<dataTypeDef>
<name>EtherClassifyStatsType</name>
<synopsis>Entry type for statistics table in EtherClassifier
LFB.</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>Type for Ethernet classifier statistics
information table.</synopsis>
<array type="variable-size">
Wang, et al. Expires January 11, 2012 [Page 22]
Internet-Draft ForCES LFB Library July 2011
<typeRef>EtherClassifyStatsType</typeRef>
</array>
</dataTypeDef>
<dataTypeDef>
<name>IPv4ValidatorStatsType</name>
<synopsis>Statistics type in IPv4validator.</synopsis>
<struct>
<component componentID="1">
<name>badHeaderPkts</name>
<synopsis>Number of bad header packets.</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name>badTotalLengthPkts</name>
<synopsis>Number of bad total length packets.</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="3">
<name>badTTLPkts</name>
<synopsis>Number of bad TTL packets.</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="4">
<name>badChecksumPkts</name>
<synopsis>Number of bad checksum packets.</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv6ValidatorStatsType</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>
Wang, et al. Expires January 11, 2012 [Page 23]
Internet-Draft ForCES LFB Library July 2011
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv4PrefixInfoType</name>
<synopsis>Entry type for IPv4 prefix table.</synopsis>
<struct>
<component componentID="1">
<name>IPv4Address</name>
<synopsis>An IPv4 Address</synopsis>
<typeRef>IPv4Addr</typeRef>
</component>
<component componentID="2">
<name>Prefixlen</name>
<synopsis>The 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>
Wang, et al. Expires January 11, 2012 [Page 24]
Internet-Draft ForCES LFB Library July 2011
<synopsis>A default route flag.</synopsis>
<atomic>
<baseType>boolean</baseType>
<specialValues>
<specialValue value="false">
<name>False</name>
<synopsis>This is not a default route.
</synopsis>
</specialValue>
<specialValue value="true">
<name>True</name>
<synopsis>This route is a default route.
</synopsis>
</specialValue>
</specialValues>
</atomic>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv4PrefixTableType</name>
<synopsis>Type for IPv4 prefix table.</synopsis>
<array type="variable-size">
<typeRef>IPv4PrefixInfoType</typeRef>
</array>
</dataTypeDef>
<dataTypeDef>
<name>IPv4UcastLPMStatsType</name>
<synopsis>Statistics type in IPv4Unicast LFB.</synopsis>
<struct>
<component componentID="1">
<name>InRcvdPkts</name>
<synopsis>The 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>
Wang, et al. Expires January 11, 2012 [Page 25]
Internet-Draft ForCES LFB Library July 2011
</dataTypeDef>
<dataTypeDef>
<name>IPv6PrefixInfoType</name>
<synopsis>Entry type for IPv6 prefix table.</synopsis>
<struct>
<component componentID="1">
<name>IPv6Address</name>
<synopsis>An IPv6 Address</synopsis>
<typeRef>IPv6Addr</typeRef>
</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>
Wang, et al. Expires January 11, 2012 [Page 26]
Internet-Draft ForCES LFB Library July 2011
<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>Type for IPv6 prefix table.</synopsis>
<array type="variable-size">
<typeRef>IPv6PrefixInfoType</typeRef>
</array>
</dataTypeDef>
<dataTypeDef>
<name>IPv6UcastLPMStatsType</name>
<synopsis>Statistics type in IPv6Unicast LFB.</synopsis>
<struct>
<component componentID="1">
<name>InRcvdPkts</name>
<synopsis>The total number of input packets
received</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="2">
<name>FwdPkts</name>
<synopsis>IPv6 packets forwarded by this LFB</synopsis>
<typeRef>uint64</typeRef>
</component>
<component componentID="3">
<name>NoRoutePkts</name>
<synopsis>The number of IP datagrams discarded because
no route could be found.</synopsis>
<typeRef>uint64</typeRef>
</component>
</struct>
</dataTypeDef>
Wang, et al. Expires January 11, 2012 [Page 27]
Internet-Draft ForCES LFB Library July 2011
<dataTypeDef>
<name>IPv4NextHopInfoType</name>
<synopsis>Entry type for IPv4 next hop table.</synopsis>
<struct>
<component componentID="1">
<name>L3PortID</name>
<synopsis>The ID of the Logical/physical Output Port
that we pass onto the neighboring LFB instance. This
ID indicates what port to the neighbor is as defined
by L3.</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>MTU</name>
<synopsis>Maximum Transmission Unit for out going port.
It is for desciding whether the packet need
fragmentation </synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>NextHopIPAddr</name>
<synopsis>Next Hop IPv4 Address</synopsis>
<typeRef>IPv4Addr</typeRef>
</component>
<component componentID="4">
<name>MediaEncapInfoIndex</name>
<synopsis>The 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) EtherEncap
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 IPv4NextHop LFB.
</synopsis>
<typeRef>uint32</typeRef>
</component>
Wang, et al. Expires January 11, 2012 [Page 28]
Internet-Draft ForCES LFB Library July 2011
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv4NextHopTableType</name>
<synopsis>Type for IPv4 next hop table.</synopsis>
<array type="variable-size">
<typeRef>IPv4NextHopInfoType</typeRef>
</array>
</dataTypeDef>
<dataTypeDef>
<name>IPv6NextHopInfoType</name>
<synopsis>Entry type for IPv6 next hop table.</synopsis>
<struct>
<component componentID="1">
<name>L3PortID</name>
<synopsis>The ID of the Logical/physical Output Port
that we pass onto the neighboring LFB instance. This
ID indicates what port to the neighbor is as defined
by L3.</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>MTU</name>
<synopsis>Maximum Transmission Unit for out going port.
It is for desciding whether the packet need
fragmentation.</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>NextHopIPAddr</name>
<synopsis>Next Hop IPv6 Address</synopsis>
<typeRef>IPv6Addr</typeRef>
</component>
<component componentID="4">
<name>MediaEncapInfoIndex</name>
<synopsis>The index we pass onto the neighboring LFB
instance. This index is 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) EtherEncap
b) Other type of media LFB
Wang, et al. Expires January 11, 2012 [Page 29]
Internet-Draft ForCES LFB Library July 2011
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 IPv6NextHop LFB.
</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>IPv6NextHopTableType</name>
<synopsis>Type for IPv6 next hop table.</synopsis>
<array type="variable-size">
<typeRef>IPv6NextHopInfoType</typeRef>
</array>
</dataTypeDef>
<dataTypeDef>
<name>EncapTableEntryType</name>
<synopsis>Entry type for Ethernet encapsulation table.
</synopsis>
<struct>
<component componentID="1">
<name>DstMac</name>
<synopsis>Ethernet Mac of the Neighbor</synopsis>
<typeRef>IEEEMAC</typeRef>
</component>
<component componentID="2">
<name>SrcMac</name>
<synopsis>Source MAC used in encapsulation</synopsis>
<typeRef>IEEEMAC</typeRef>
</component>
<component componentID="3">
<name>VlanID</name>
<synopsis>VLAN ID.</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="4">
<name>L2PortID</name>
<synopsis>Output logical L2 port ID.</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>EncapTableType</name>
<synopsis>Type for Ethernet encapsulation table.</synopsis>
Wang, et al. Expires January 11, 2012 [Page 30]
Internet-Draft ForCES LFB Library July 2011
<array type="variable-size">
<typeRef>EncapTableEntryType</typeRef>
</array>
</dataTypeDef>
<dataTypeDef>
<name>MetadataDispatchType</name>
<synopsis>Entry type for metadata dispatch table.</synopsis>
<struct>
<component componentID="1">
<name>MetadataID</name>
<synopsis>metadata ID</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>MetadataValue</name>
<synopsis>metadata value.</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3">
<name>OutputIndex</name>
<synopsis>group output port index.</synopsis>
<typeRef>uint32</typeRef>
</component>
</struct>
</dataTypeDef>
<dataTypeDef>
<name>MetadataDispatchTableType</name>
<synopsis>Type for Metadata dispatch table.</synopsis>
<array type="variable-size">
<typeRef>MetadataDispatchType</typeRef>
</array>
</dataTypeDef>
<dataTypeDef>
<name>SchdDisciplineType</name>
<synopsis>Scheduling discipline type.</synopsis>
<atomic>
<baseType>uint32</baseType>
<specialValues>
<specialValue value="1">
<name>FIFO</name>
<synopsis>First In First Out scheduler.</synopsis>
</specialValue>
<specialValue value="2">
<name>RR</name>
<synopsis>Round Robin.</synopsis>
</specialValue>
</specialValues>
</atomic>
Wang, et al. Expires January 11, 2012 [Page 31]
Internet-Draft ForCES LFB Library July 2011
</dataTypeDef>
<dataTypeDef>
<name>QueueDepthType</name>
<synopsis>Entry type for queue depth table.</synopsis>
<struct>
<component componentID="1">
<name>QueueID</name>
<synopsis>Queue ID</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="2">
<name>QueueDepthInPackets</name>
<synopsis>the Queue Depth when the 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>Type for Queue depth table.</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 of the packet.</synopsis>
<metadataID>2</metadataID>
<typeRef>IEEEMAC</typeRef>
</metadataDef>
<metadataDef>
<name>DstMAC</name>
Wang, et al. Expires January 11, 2012 [Page 32]
Internet-Draft ForCES LFB Library July 2011
<synopsis>Destination MAC address of the packet.</synopsis>
<metadataID>3</metadataID>
<typeRef>IEEEMAC</typeRef>
</metadataDef>
<metadataDef>
<name>LogicalPortID</name>
<synopsis>ID of a logical port for the packet.</synopsis>
<metadataID>4</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
<metadataDef>
<name>EtherType</name>
<synopsis>Indicating the Ethernet type of the Ethernet packet.
</synopsis>
<metadataID>5</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
<metadataDef>
<name>VlanID</name>
<synopsis>The Vlan ID of the Ethernet packet.</synopsis>
<metadataID>6</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
<metadataDef>
<name>VlanPriority</name>
<synopsis>The priority of the Ethernet packet.</synopsis>
<metadataID>7</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
<metadataDef>
<name>NexthopIPv4Addr</name>
<synopsis>Nexthop IPv4 address the packet is sent to.
</synopsis>
<metadataID>8</metadataID>
<typeRef>IPv4Addr</typeRef>
</metadataDef>
<metadataDef>
<name>NexthopIPv6Addr</name>
<synopsis>Nexthop IPv6 address the packet is sent to.
</synopsis>
<metadataID>9</metadataID>
<typeRef>IPv6Addr</typeRef>
</metadataDef>
<metadataDef>
<name>HopSelector</name>
<synopsis>An index the packet can use to look up a nexthop
table for next hop information of the packet.</synopsis>
<metadataID>10</metadataID>
Wang, et al. Expires January 11, 2012 [Page 33]
Internet-Draft ForCES LFB Library July 2011
<typeRef>uint32</typeRef>
</metadataDef>
<metadataDef>
<name>ExceptionID</name>
<synopsis>Indicating exception type of the packet which is
exceptional for some processing.</synopsis>
<metadataID>11</metadataID>
<atomic>
<baseType>uint32</baseType>
<specialValues>
<specialValue value="0">
<name>AnyUnrecognizedExceptionCase</name>
<synopsis>any unrecognized exception case.</synopsis>
</specialValue>
<specialValue value="1">
<name>BroadCastPacket</name>
<synopsis>Packet with destination address equal to
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's header length 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>
</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>
Wang, et al. Expires January 11, 2012 [Page 34]
Internet-Draft ForCES LFB Library July 2011
</specialValue>
<specialValue value="8">
<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>Indicating error type of the packet failed some
validation process.</synopsis>
<metadataID>12</metadataID>
<atomic>
<baseType>uint32</baseType>
<specialValues>
<specialValue value="0">
<name> AnyUnrecognizedValidateErrorCase</name>
<synopsis> Any unrecognized validate error case.
</synopsis>
</specialValue>
<specialValue value="1">
<name>InvalidIPv4PacketSize</name>
<synopsis>Packet size reported is less than 20
Wang, et al. Expires January 11, 2012 [Page 35]
Internet-Draft ForCES LFB Library July 2011
bytes.</synopsis>
</specialValue>
<specialValue value="2">
<name>NotIPv4Packet</name>
<synopsis>Packet is not IP version 4.</synopsis>
</specialValue>
<specialValue value="3">
<name>InvalidIPv4HeaderLengthSize</name>
<synopsis>Packet's header length is less than 5.
</synopsis>
</specialValue>
<specialValue value="4">
<name>InvalidIPv4Checksum</name>
<synopsis>Packet with invalid checksum.</synopsis>
</specialValue>
<specialValue value="5">
<name>InvalidIPv4SrcAddrCase1</name>
<synopsis>Packet with source address equal to
255.255.255.255.</synopsis>
</specialValue>
<specialValue value="6">
<name>InvalidIPv4SrcAddrCase2</name>
<synopsis>Packet with source address 0.</synopsis>
</specialValue>
<specialValue value="7">
<name>InvalidIPv4SrcAddrCase3</name>
<synopsis>Packet with source address of form
127.any.</synopsis>
</specialValue>
<specialValue value="8">
<name>InvalidIPv4SrcAddrCase4</name>
<synopsis>Packet with source address in Class E
domain.</synopsis>
</specialValue>
<specialValue value="9">
<name>InvalidIPv6PakcetSize</name>
<synopsis>Packet size reported is less than 40
bytes.</synopsis>
</specialValue>
<specialValue value="10">
<name>NotIPv6Packet</name>
<synopsis>Packet is not IP version 6.</synopsis>
</specialValue>
<specialValue value="11">
<name>InvalidIPv6SrcAddrCase1</name>
<synopsis>Packet with multicast source address (the
MSB of the source address is 0xFF).</synopsis>
</specialValue>
Wang, et al. Expires January 11, 2012 [Page 36]
Internet-Draft ForCES LFB Library July 2011
<specialValue value="12">
<name>InvalidIPv6SrcAddrCase2</name>
<synopsis>Packet with source address set to
loopback(::1).</synopsis>
</specialValue>
<specialValue value="13">
<name>InvalidIPv6DstAddrCase1</name>
<synopsis>Packet with destination set to 0 or ::1.
</synopsis>
</specialValue>
</specialValues>
</atomic>
</metadataDef>
<metadataDef>
<name>L3PortID</name>
<synopsis>ID of L3 port.</synopsis>
<metadataID>13</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
<metadataDef>
<name>RedirectIndex</name>
<synopsis>metadata CE sends to RedirectIn LFB for the
associated packet to select output port in the LFB group
output "PktsOut".</synopsis>
<metadataID>14</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
<metadataDef>
<name>MediaEncapInfoIndex</name>
<synopsis>An index the packet uses to look up a media
encapsulation table to select its encapsulation media as
well as followed encapsulation LFB.</synopsis>
<metadataID>15</metadataID>
<typeRef>uint32</typeRef>
</metadataDef>
</metadataDefs>
</LFBLibrary>
Wang, et al. Expires January 11, 2012 [Page 37]
Internet-Draft ForCES LFB Library July 2011
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 physical layer with
media limited to copper.
5.1.1.1. Data Handling
This LFB is the interface to the Ethernet physical media. The LFB
handles ethernet frames coming in from or going out of the FE.
Ethernet frames sent and received cover all packets encapsulated with
Wang, et al. Expires January 11, 2012 [Page 38]
Internet-Draft ForCES LFB Library July 2011
different versions of Ethernet protocols, like Ethernet V2, 802.3
RAW, IEEE 802.3/802.2,IEEE 802.3/802.2 SNAP, including packets
encapsulated with varieties of LAN techniques based on Ethernet, like
various VLANs, MACinMAC, etc. Therefore in the XML an EthernetAll
frame type has been introduced.
Ethernet frames are received from the physical media port and passed
downstream to LFBs such as EtherMACIn via a singleton output known as
"EtherPHYOut". A 'PHYPortID' metadatum, to indicate which physical
port the frame came into from the external world, is passed along
with the frame.
Ethernet packets are received by this LFB from upstream LFBs such
EtherMacOut via the singleton input known as "EtherPHYIn" before
being sent out onto the external world.
5.1.1.2. Components
The AdminStatus component is defined for CE to administratively
manage the status of the LFB. The CE may adminstratively startup or
shutdown the LFB by changing the value of AdminStatus. The default
value is set to 'Down'.
An OperStatus component captures the physical port operational
status. A PHYPortStatusChanged event is defined so the LFB can
report to the CE whenever there is an operational status change of
the physical port.
The PHYPortID component is 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 'PHYPortID' metadatum
at the LFB output and to associate it to every Ethernet packet this
LFB receives. The metadatum will be handed to downstream LFBs for
them to use the PHYPortID.
A group of components are defined for link speed management. The
AdminLinkSpeed is for CE to configure link speed for the port and the
OperLinkSpeed is for CE to query the actual link speed in operation.
The default value for the AdminLinkSpeed is set to auto-negotiation
mode.
A 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 CarrierStatus component captures the status of the carrier and
Wang, et al. Expires January 11, 2012 [Page 39]
Internet-Draft ForCES LFB Library July 2011
specifies whether the port is linked with an operational connector.
The default value for the CarrierStatus is 'false'.
5.1.1.3. Capabilities
The capability information for this LFB includes the link speeds that
are supported by the FE (SupportedLinkSpeed) as well as the supported
duplex modes (SupportedDuplexMode).
5.1.1.4. Events
This LFB is defined to be able to generate several events in which
the CE may be interested. There is an event for changes in the
status of the physical port (PhyPortStatusChanged). Such an event
will notify that the physical port status has been changed and the
report will include the new status of the physical port.
Another event captures changes in the operational link speed
(LinkSpeedChanged). Such an event will notify the CE that the
operational speed has been changed and the report will include the
new negotiated operational speed.
A final event captures changes in the duplex mode
(DuplexModeChanged). Such an event will notify the CE that the
duplex mode has been changed and the report will include the new
negotiated duplex mode.
5.1.2. EtherMACIn
EtherMACIn LFB abstracts an Ethernet 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 expected to receive all types of Ethernet packets, via a
singleton input known as "EtherMACIn", which are usually output from
some Ethernet physical layer LFB, like an EtherPHYCop LFB, alongside
with a metadatum indicating the physical port ID that the packet
comes.
The LFB is defined with two separate singleton outputs. All Output
packets are in Ethernet format, as received from the physical layer
LFB and cover all types of Ethernet packets.
The first singleton output is known as "NormalPathOut". It usually
outputs Ethernet packets to some LFB like an EtherClassifier LFB for
Wang, et al. Expires January 11, 2012 [Page 40]
Internet-Draft ForCES LFB Library July 2011
further L3 forwarding process alongside with a PHYPortID metadata
indicating which physical port the packet came from.
The second singleton output is known as "L2BridgingPathOut".
Although the LFB library this document defines is basically to meet
typical router functions, it will attempt to be forward compatible
with future router functions. 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
that may be defined in the future. If the FE supports L2 bridging,
the CE can enable or disable it by means of a "L2BridgingPathEnable"
component in the FE. If it is enabled, by also instantiating some L2
bridging LFB instances following the L2BridgingPathOut, FEs are
expected to fulfill L2 bridging functions. L2BridgingPathOut will
output packets exactly the same as that in the NormalPathOut 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 the local MAC addresses.
All packets that do not pass through the locality check will be
dropped.
This LFB can perform Ethernet layer flow control. This is usually
implemented cooperatively by the EtherMACIn LFB and the EtherMACOut
LFB. The flow control is further distinguished by Tx flow control
and Rx flow control, separately for sending process and receiving
process flow controls.
5.1.2.2. Components
The AdminStatus component is defined for CE to 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'.
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 L2 bridge. An FE that does not 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 is set to
work as in a promiscuous mode. The default value for is 'false'.
The TxFlowControl component defines whether the LFB is performing
Wang, et al. Expires January 11, 2012 [Page 41]
Internet-Draft ForCES LFB Library July 2011
flow control on sending packets. The default value for is 'false'
The RxFlowControl component defines whether the LFB is performing
flow contron on receiving packets. The default value for is 'false'.
A struct component, MACInStats, defines a set of statistics for this
LFB, including the 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 them.
5.1.3.1. Data Handling
This LFB describes the process of decapsulating Ethernet packets and
classify them into various network layer data packets according to
information included in the Ethernet packets headers.
TThe LFB is expected to receive all types of Ethernet packets,
including VLAN Ethernet types, via a singleton input known as
"EtherPktsIn", which are usually output from an upstream LFB like
EtherMACIn LFB. This 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. This input is capable
of handling this case. Usually, all expected Ethernet Packets will
be associated with a PHYPortID metadatum, indicating the physical
port the packet comes from. In some cases, for instance, like in a
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.
The LFB is defined with a group output known as "ClassifyOut".
Because there may be various types of protocol packets at the output
Wang, et al. Expires January 11, 2012 [Page 42]
Internet-Draft ForCES LFB Library July 2011
ports, the produced output frame 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, which may be used by downstream LFBs
for packet processing, contains the PHYPortID and 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. Lastly, it may
conditionally contain information like VlanID and VlanPriority with
the condition that the packet is a VLAN packet.
5.1.3.2. Components
An EtherDispatchTable array component is defined in the LFB to
dispatch every Ethernet packet to the output group according to the
logical port ID assigned by the VLANInputTable to the packet and the
Ethernet type in the Ethernet packet header. Each row of the array
is a struct containing a Logical Port ID, an EtherType and an Output
Index. With the CE configuring the dispatch table, the LFB can be
expected to classify various network layer protocol type packets and
output them at different output ports. It is expected that the LFB
classify packets according to protocols like IPv4, IPv6, MPLS, ARP,
ND, etc.
A VLANInputTable array component is defined in the LFB to classify
VLAN Ethernet packets. Each row of the array is a strcut containing
an Incoming Port ID, a VLAN ID and a Logical Port ID. 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. Every input
packet is assigned 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.
Note that the 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.
An array component, EtherClassifyStats, defines a set of statistics
Wang, et al. Expires January 11, 2012 [Page 43]
Internet-Draft ForCES LFB Library July 2011
for this LFB, measuring the number of packets per EtherType. Each
row of the array is a struct containing an EtherType and a Packet
number.
5.1.3.3. Capabilities
This LFB does not have a list of capabilities.
5.1.3.4. Events
This LFB has no events specified.
5.1.4. EtherEncap
The EtherEncap LFB abstracts the process to replace or attach
appropriate Ethernet headers to the packet.
5.1.4.1. Data Handling
This LFB abstracts the process to encapsulate IP packets to Ethernet
packets according to the L2 information.
The LFB is expected to receive types of IP packets, including IPv4
and IPv6 types, via a singleton one known as "EncapIn" which may be
connected to an upstream LFB like an IPv4NextHop, an IPv6NextHop,
BasicMetadataDispatch, or any LFB which requires to output packets
for Ethernet encapsulation. The LFB always expects from upstream
LFBs the MediaEncapInfoIndex metadata which is used as an index to
lookup the Encapsulation Table. Optinally an input packet may be
accompanied by a Vlan priority metadata. In this case, default value
for the metadata is 0.
Two singleton output ports are defined to output results.
The first singleton output known as "SuccessOut". Upon a successful
table lookup, the destination and source MAC addresses, and the
logical media port (L2PortID) are found in the matching table entry.
The CE may set the VlanId in case VLANs are used. By default the
table entry for VlanId of 0 is used as per IEEE rules. Whatever the
value of VlanID is, if the Input metadata VlanPriority is non-zero,
the packet will have a VLAN tag. If the VlanPriority and the VlanID
are all zero, there is no VLAN tag to this packet. After replacing
or attaching the appropriate Ethernet headers to the packet is
complete, the packet is passed out on the "SuccessOut" LFB port to a
downstream LFB instance alongside with the L2PortID.
The second singleton output known as "ExceptionOut", which will
output packets for which the table lookup fails, along with an
Wang, et al. Expires January 11, 2012 [Page 44]
Internet-Draft ForCES LFB Library July 2011
additional ExceptionID metadata. Currently defined exception types
only include the following case:
o MediaEncapInfoIndex value is not allocated in the EncapTable.
The upstream LFB may be programmed by the CE to pass along a
MediaEncapInfoIndex that does not exist in the EncapTable. That is
to allow for resolution of the L2 headers, if needed, to be made at
the L2 encapsulation level in this case(ethernet) via ARP, or ND (or
other methods depending on the link layer technology) when a table
miss occurs.
For neighbor L2 header resolution(table miss exception), the
processing LFB may pass this packet to the CE via the redirect LFB or
FE software or another LFB instance for further resolution. In such
a case the metadata NexthopIPv4Addr or NexthopIPv6Addr generated by
Nexthop LFB is also passed to the exception handling. Such an IP
address could be used to do activities such as ARP or ND by the
handler it is passed to.
The result of the L2 resolution is to update the EncapTable as well
as the Nexthop LFB so subsequent packets do not fail EncapTable
lookup. The EtherEncap LFB does not make any assumptions of how the
EncapTable is updated by the CE (or whether ARP/ND is used
dynamically or static maps exist).
Downstream neighboring LFB instances could be either an EtherMACOut
type or a BasicMetadataDispatch type. If the final packet L2
processing is possible to be on per-media-port basis or resides on a
different FE or in cases where L2 header resolution is needed, then
the model makes sense to use a BasicMetadataDispatch LFB to fanout to
different LFB instances. If there is a direct egress port point,
then the model makes sense to have a downstream LFB instance be an
EtherMACOut.
5.1.4.2. Components
This LFB has only one component named EncapTable which is defined as
an array. Each row of the array is a struct containing the
destination MAC address, the source MAC address, the VLAN ID with a
default value of zero and the output logical L2 port ID.
5.1.4.3. Capabilities
This LFB does not have a list of capabilities.
Wang, et al. Expires January 11, 2012 [Page 45]
Internet-Draft ForCES LFB Library July 2011
5.1.4.4. Events
This LFB does not have any events specified.
5.1.5. EtherMACOut
EtherMACOut LFB abstracts an Ethernet port at MAC data link layer.
This LFB describes Ethernet packet output process. Ethernet output
functions are closely related to Ethernet input functions, therefore
many components defined in this LFB are as aliases of EtherMACIn LFB
components.
5.1.5.1. Data Handling
The LFB is expected to receive all types of Ethernet packets, via a
singleton input known as "EtherPktsIn", which are usually output from
an Ethernet encapsulation LFB, alongside with a metadatum indicating
the physical port ID that the packet will go through(editorial note:
need more discussion on the port ID being physical layer or L2
layer).
The LFB is defined with a singleton output. All Output packets are
in Ethernet format, possibly with various Ethernet 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 LFB like EtherPHYcop LFB.
This LFB can perform Ethernet layer flow control. This is usually
implemented cooperatively by the EtherMACIn LFB and the EtherMACOut
LFB. The flow control is further distinguished by Tx flow control
and Rx flow control, separately for sending process and receiving
process flow control.
Note that as a base definition, functions like multiple virtual MAC
layers are not supported in this LFB version. It may be supported in
the future by defining a subclass or a new version of this LFB
5.1.5.2. Components
The AdminStatus component is defined for CE to 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 target component this alias refers,
Wang, et al. Expires January 11, 2012 [Page 46]
Internet-Draft ForCES LFB Library July 2011
which include the target LFB class and instance IDs as well as the
path to the target component. Whereas, these properties are set by
CE only when a system runs, which are outside the XML definitions of
this LFB.
The MTU component defines the maximum transmission unit
The TxFlowControl component defines whether the LFB is performing
flow control on sending packets. The default value for is 'false'.
Note that this component is defined as an alias of TxFlowControl
component in the EtherMACIn LFB.
The RxFlowControl component defines whether the LFB is performing
flow control on receiving packets. The default value for is 'false'.
Note that this component is defined as an alias of RxFlowControl
component in the EtherMACIn LFB.
A struct component, MACOutStats, defines a set of statistics for this
LFB, including the number of transmitted packets and the number of
dropped packets.
5.1.5.3. 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
The LFBs are defined to abstract IP packet validation process. An
IPv4Validator LFB is specifically for IPv4 protocol validation and an
IPv6Validator LFB for IPv6.
5.2.1. IPv4Validator
The IPv4Validator LFB performs IPv4 packets validation according to
RFC 1812.
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, as input, packets which have been indicated
Wang, et al. Expires January 11, 2012 [Page 47]
Internet-Draft ForCES LFB Library July 2011
as IPv4 packets by an upstream LFB, like an EtherClassifier LFB.
There is no specific metadata expected by the input of the 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 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
port known as "IPv4UnicastOut". All validated IPv4 multicast packets
will be output at the singleton port known as "IPv4MulticastOut"
port. There is no metadata specifically required to produce at these
output ports.
A singleton port known as "ExceptionOut" is defined to output packets
which have been validated as exception packets. An exception ID
metadatum is produced to indicate what has caused the exception.
Currently defined exception types include:
o Packet with destination address equal to 255.255.255.255
o Packet with expired TTL
o Packet with header length more than 5 words
o Packet IP head including Router Alert options
Note that, although TTL is checked in this LFB for validity,
operations to TTL like TTL decreasing will be made only in a followed
forwarding LFB.
The final singleton port known as "FailOut" is defined for all
packets which have failed the validation process. A validate error
ID is associated to every failed packet to indicate the reason.
Currently defined reasons include:
o Packet size reported is less than 20 bytes
o Packet with version is not IPv4
Wang, et al. Expires January 11, 2012 [Page 48]
Internet-Draft ForCES LFB Library July 2011
o Packet with header length < 5
o Packet with total length field < 20
o Packet with invalid checksum
o Packet with source address equal to 255.255.255.255
o Packet with source address 0
o Packet with source address of form {127, <any>}
o Packet with source address in Class E domain
5.2.1.2. Components
This LFB has only one struct component, the
IPv4ValidatorStatisticsType, which defines a set of statistics for
validation process, including the number of bad header packets, the
number of bad total length packets, the number of bad TTL packets,
and the number of bad checksum packets.
5.2.1.3. Capabilities
This LFB does not have a list of capabilities
5.2.1.4. Events
This LFB does not have any events specified.
5.2.2. IPv6Validator
The IPv6Validator LFB performs IPv6 packets validation according to
RFC 2460.
5.2.2.1. Data Handling
This LFB performs IPv6 validation according to RFC 2460. Then the
IPv6 packet will be output to the corresponding port regarding of the
validation result, whether the packet is a unicast or a multicast
one, an exception has occurred or the validation failed.
This LFB always expects, as input, packets which have been indicated
as IPv6 packets by an upstream LFB, like an EtherClassifier LFB.
There is no specific metadata expected by the input of the LFB.
Similar to the IPv4validator LFB, IPv6Validator has also defined four
output ports to output packets for various validation results.
Wang, et al. Expires January 11, 2012 [Page 49]
Internet-Draft ForCES LFB Library July 2011
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 exception ID
metadata is produced to indicate what caused the exception.
Currently defined exception types include:
o Packet with hop limit to zero
o Packet with a link-local destination address
o Packet with a link-local source address
o Packet with destination all-routers
o Packet with destination all-nodes
o Packet with next header set to Hop-by-Hop
The final singleton port known as "FailOut" is defined for all
packets which have failed the validation process. A validate error
ID is associated to every failed packet to indicate the reason.
Currently defined reasons include:
o Packet size reported is less than 40 bytes
o Packet with version is not IPv6
o Packet with multicast source address (the MSB of the source
address is 0xFF)
o Packet with destination address set to 0 or ::1
o Packet with source address set to loopback (::1).
Note that in the base type library, definitions for exception ID and
validate error ID metadata are applied to both IPv4Validator and
IPv6Validator LFBs, i.e., the two LFBs share the same medadata
definition, with different ID assignment inside.
5.2.2.2. Components
This LFB has only one struct component, the
IPv6ValidatorStatisticsType, which defines a set of statistics for
Wang, et al. Expires January 11, 2012 [Page 50]
Internet-Draft ForCES LFB Library July 2011
validation process, including the number of bad header packets, the
number of bad total length packets, and the number of bad hop limit
packets.
5.2.2.3. Capabilities
This LFB does not have a list of capabilities
5.2.2.4. Events
This LFB does not have any events specified.
5.3. IP Forwarding LFBs
IP Forwarding LFBs are specifically defined to abstract the IP
forwarding processes. As definitions for a base LFB library, this
document restricts its LFB definition scope for IP forwarding jobs
only to IP unicast forwarding. LFBs for jobs like IP multicast may
be defined in future versions of the document.
A typical IP unicast forwarding job is usually realized by looking up
some forwarding information table to find some next hop information,
and then based on the next hop information, forwarding packets to
specific output ports. It usually takes two steps to do so, firstly
to look up a forwarding information table by means of Longest Prefix
Matching(LPM) rule to find a next hop index, then to use the index to
look up a next hop information table to find enough information to
submit packets to output ports. This document abstracts the
forwarding processes mainly based on the two steps model. However,
there actually exists other models, like one which may only have a
forwarding information base that have conjoined next hop information
together with forwarding information. In this case, if ForCES
technology is to be applied, some translation work will have to be
done in FE to translate attributes defined by this document into real
attributes the implementation has actually applied.
Based on the IP forwarding abstraction, two kind of typical IP
unicast forwarding LFBs are defined, Unicast LPM lookup LFB and next
hop application LFB. They are further distinguished by IPv4 and IPv6
protocols.
5.3.1. IPv4UcastLPM
The IPv4UcastLPM LFB abstracts the IPv4 unicast Longest Prefix Match
(LPM) process..
This LFB also provides facilities to support users to implement
equal-cost multi-path routing (ECMP) or reverse path forwarding
Wang, et al. Expires January 11, 2012 [Page 51]
Internet-Draft ForCES LFB Library July 2011
(RPF). However, this LFB itself does not provide ECMP or RPF. To
fully implement ECMP or RPF, additional specific LFBs, like a
specific ECMP LFB or an RPF LFB, will have to be defined. This work
may be done in the future version of the document.
5.3.1.1. Data Handling
This LFB performs the IPv4 unicast LPM table looking up. It always
expects as input IPv4 unicast packets from one singleton input known
as "PktsIn". Then the LFB uses the destination IPv4 address of every
packet as index to look up the IPv4 prefix table and generate a hop
selector as the matching result. This result will associate to the
packet as a metadatum to output to downstream LFBs, and will usually
be used there as an index to find more next hop information.
Three singleton output ports are defined to output LPM results.
The first singleton output known as "NormalOut", which will output
IPv4 unicast packets that has passed the LPM lookup and got a hop
selector as the lookup result. The hop selector is associated with
the packet as a metadatum. Followed the normal output of the LPM LFB
is usually a next hop application LFB, like an IPv4NextHop LFB.
The second singleton output known as "ECMPOut" is defined to provide
support for users wishing to implement ECMP.
An ECMP flag is defined in the LPM table to enable the LFB to support
ECMP. When a table entry is created with the flag set true, it
indicates this table entry is for ECMP only. A packet, which has
passed through this prefix lookup, will always output from "ECMPOut"
output port, with the hop selector being its lookup result. The
output will usually directly go to a downstream ECMP processing LFB,
where the hop selector can usually further generate optimized one or
multiple next hop routes by use of ECMP algorithms.
A default route flag is defined in the LPM table to enable the LFB to
support a default route, and loose RPF also. When set true, the
table entry is identified a default route and as a forbidden route
for RPF also. If a user wants to implement RPF on FE, a specific RPF
LFB will have to be defined. In such RPF LFB, a component can be
defined as an alias of the prefix table component of this LFB as
described below.
The final singleton output is known as "ExceptionOut" and is defined
to allow exception packets to output here. Exceptions include cases
like:
Wang, et al. Expires January 11, 2012 [Page 52]
Internet-Draft ForCES LFB Library July 2011
o Packets can not find any routes in the prefix table.
The upstream neighboring LFB of this LFB is usually IPv4Validator
LFB. If RPF is to be adopted, the upstream can be an RPF LFB, when
defined.
The downstream neighboring LFB is usually IPv4NextHop LFB. If ECMP
is adopted, the downstream can be an ECMP LFB, when defined.
5.3.1.2. Components
This LFB has two components.
The IPv4PrefixTable component is defined as an array component of the
LFB. Each row of the array contains an IPv4 adrress, a Prefix
length, a Hop Selector, an ECMP flag and a Default Route flag. The
LFB uses the destination IPv4 address of every input packet as index
to look up this table to get a hop selector as the result. The ECMP
flag is for the LFB to support ECMP.The default route flag is for the
LFB to support a default route and for loose RPF.
The IPv4UcastLPMStats component is a struct component which collects
statistics information, including the total number of input packets
received, the IPv4 packets forwarded by this LFB and the number of IP
datagrams discarded due to no route found.
5.3.1.3. Capabilities
This LFB does not have a list of capabilities
5.3.1.4. Events
This LFB does not have any events specified.
5.3.2. IPv4NextHop
This LFB abstracts the process of selecting ipv4 next hop action.
5.3.2.1. Data Handling
The LFB abstracts the process of next hop information application to
IPv4 packets. It receives an IPv4 packet with an associated next hop
ID, and uses the ID to look up a next hop table to find an
appropriate output port from the LFB.
The LFB is expected to receive unicast IPv4 packets, via a singleton
input known as "PcktsIn" along with a HopSelector metadata which is
used as an index to lookup the NextHop table. Data processing
Wang, et al. Expires January 11, 2012 [Page 53]
Internet-Draft ForCES LFB Library July 2011
involves the forwarding TTL decrement and checksum recalculation.
Two output ports are defined to output results.
The first output is a group output port known as "SuccessOut". On
successful data processing the packet is sent out an LFB-port from
within the LFB port group as selected by the LFBOutputSelectIndex
value of the matched table entry. The packet is sent to a downstream
LFB alongside with the L3PortID and MediaEncapInfoIndex metadata.
The second output is a singleton output port known as "ExceptionOut",
which will output packets for which the data processing failed, along
with an additional ExceptionID metadata to indicate what caused the
exception. Currently defined exception types include:
o The HopSelector is invalid
o The MTU for outgoing interface is less than the packet size
o ICMP packet needs to be generated
Downstream neighboring LFB instances could be either a
BasicMetadataDispatch type, used to fanout to different LFB instances
or a media encapsulation related type, such as an EtherEncap type or
a RedirectOut type. For example, there are Ethernet and other tunnel
Encapsulation, then BasicMetadataDispatch can use the L3PortID
metadata to dispatch packets to different Encapsulator.
5.3.2.2. Components
This LFB has only one component named IPv4NextHopTable which is
defined as an array. Each row of the array is a struct containing:
o The L3PortID, which is the ID of the Logical Output Port that is
passed onto the neighboring LFB instance. This ID indicates what
port to the neighbor is as defined by L3.
o MTU, the Maximum Transmission Unit for the outgoing port.
o NextHopIPAddr, the IPv4 next hop Address.
o MediaEncapInfoIndex, the index we pass onto the neighboring LFB
instance. This index is used to lookup a table (typically media
encapsulatation related) further downstream. The CE sets it to a
value that is not allocated in downstream LFB tables. (If a
downstream LFB lookup fails to find it, it indicates some other
way to resolve it may be needed.)
Wang, et al. Expires January 11, 2012 [Page 54]
Internet-Draft ForCES LFB Library July 2011
o LFBOutputSelectIndex, the LFB Group output port index to select
downstream LFB port. This index exactly is the FromPortIndex for
the port group "SuccessOut" in the table LFBTopology of FEObject
LFB as defined for the Nexthop LFB.
5.3.2.3. Capabilities
This LFB does not have a list of capabilities
5.3.2.4. Events
This LFB does not have any events specified.
5.3.3. IPv6UcastLPM
The IPv6UcastLPM LFB abstracts the IPv6 unicast Longest Prefix Match
(LPM) process. The definition of this LFB is similar to the
IPv4UcastLPM LFB except that all IP addresses refer to IPv6
addresses.
This LFB also provides facilities to support users to implement
equal-cost multi-path routing (ECMP) or reverse path forwarding
(RPF). However, this LFB itself does not provide ECMP or RPF. To
fully implement ECMP or RPF, additional specific LFBs, like a
specific ECMP LFB or an RPF LFB, will have to be defined. This work
may be done in the future version of the document.
5.3.3.1. Data Handling
This LFB performs the IPv6 unicast LPM table looking up. It always
expects as input IPv6 unicast packets from one singleton input known
as "PktsIn". Then the LFB uses the destination IPv6 address of every
packet as index to look up the IPv6 prefix table and generate a hop
selector as the matching result. This result will associate to the
packet as a metadatum to output to downstream LFBs, and will usually
be used there as an index to find more next hop information.
Three singleton output ports are defined to output LPM results.
The first singleton output known as "NormalOut", which will output
IPv6 unicast packets that has passed the LPM lookup and got a hop
selector as the lookup result. The hop selector is associated with
the packet as a metadatum. Followed the normal output of the LPM LFB
is usually a next hop application LFB, like an IPv6NextHop LFB.
The second singleton output known as "ECMPOut" is defined to provide
support for users wishing to implement ECMP.
Wang, et al. Expires January 11, 2012 [Page 55]
Internet-Draft ForCES LFB Library July 2011
An ECMP flag is defined in the LPM table to enable the LFB to support
ECMP. When a table entry is created with the flag set true, it
indicates this table entry is for ECMP only. A packet, which has
passed through this prefix lookup, will always output from "ECMPOut"
output port, with the hop selector being its lookup result. The
output will usually directly go to a downstream ECMP processing LFB,
where the hop selector can usually further generate optimized one or
multiple next hop routes by use of ECMP algorithms.
A default route flag is defined in the LPM table to enable the LFB to
support a default route, and loose RPF also. When set true, the
table entry is identified a default route and as a forbidden route
for RPF also. If a user wants to implement RPF on FE, a specific RPF
LFB will have to be defined. In such RPF LFB, a component can be
defined as an alias of the prefix table component of this LFB as
described below.
The final singleton output is known as "ExceptionOut" and is defined
to allow exception packets to output here. Exceptions include cases
like:
o Packets can not find any routes in the prefix table.
The upstream neighboring LFB of this LFB is usually IPv6Validator
LFB. If RPF is to be adopted, the upstream can be an RPF LFB, when
defined.
The downstream neighboring LFB is usually an IPv6NextHop LFB. If
ECMP is adopted, the downstream can be an ECMP LFB, when defined.
5.3.3.2. Components
This LFB has two components.
The IPv6PrefixTable component is defined as an array component of the
LFB. Each row of the array contains an IPv6 adrress, a Prefix
length, a Hop Selector, an ECMP flag and a Default Route flag. The
LFB uses the destination IPv6 address of every input packet as index
to look up this table to get a hop selector as the result. The ECMP
flag is for the LFB to support ECMP. The default route flag is for
the LFB to support a default route and for loose RPF.
The IPv6UcastLPMStats component is a struct component which collects
statistics information, including the total number of input packets
received, the IPv6 packets forwarded by this LFB and the number of IP
datagrams discarded due to no route found.
Wang, et al. Expires January 11, 2012 [Page 56]
Internet-Draft ForCES LFB Library July 2011
5.3.3.3. Capabilities
This LFB does not have a list of capabilities
5.3.3.4. Events
This LFB does not have any events specified.
5.3.4. IPv6NextHop
This LFB abstracts the process of selecting IPv6 next hop action.
5.3.4.1. Data Handling
The LFB abstracts the process of next hop information application to
IPv6 packets. It receives an IPv6 packet with an associated next hop
ID, and uses the ID to look up a next hop table to find an
appropriate output port from the LFB.
The LFB is expected to receive unicast IPv6 packets, via a singleton
input known as "PcktsIn" along with a HopSelector metadata which is
used as an index to lookup the NextHop table.
Two output ports are defined to output results.
The first output is a group output port known as "SuccessOut". On
successful data processing the packet is sent out an LFB-port from
within the LFB port group as selected by the LFBOutputSelectIndex
value of the matched table entry. The packet is sent to a downstream
LFB alongside with the L3PortID and MediaEncapInfoIndex metadata.
The second output is a singleton output port known as "ExceptionOut",
which will output packets for which the data processing failed, along
with an additional ExceptionID metadata to indicate what caused the
exception. Currently defined exception types include:
o The HopSelector is invalid
o The MTU for outgoing interface is less than the packet size
o ICMP packet needs to be generated
Downstream neighboring LFB instances could be either a
BasicMetadataDispatch type, used to fanout to different LFB instances
or a media encapsulatation related type, such as an EtherEncap type
or a RedirectOut type. For example, there are Ethernet and other
tunnel Encapsulation, then BasicMetadataDispatch can use the L3PortID
metadata to dispatch packets to different Encapsulator.
Wang, et al. Expires January 11, 2012 [Page 57]
Internet-Draft ForCES LFB Library July 2011
5.3.4.2. Components
This LFB has only one component named IPv6NextHopTable which is
defined as an array. Each row of the array is a struct containing:
o The L3PortID, which is the ID of the Logical Output Port that is
passed onto the neighboring LFB instance. This ID indicates what
port to the neighbor is as defined by L3.
o MTU, the Maximum Transmission Unit for the outgoing port.
o NextHopIPAddr, the IPv6 next hop Address.
o MediaEncapInfoIndex, the index we pass onto the neighboring LFB
instance. This index is used to lookup a table (typically media
encapsulatation related) further downstream. The CE sets it to a
value that is not allocated in downstream LFB tables. (If a
downstream LFB lookup fails to find it, it indicates some other
way to resolve it may be needed.)
o LFBOutputSelectIndex, the LFB Group output port index to select
downstream LFB port. This index exactly is the FromPortIndex for
the port group "SuccessOut" in the table LFBTopology of FEObject
LFB as defined for the Nexthop LFB.
5.3.4.3. Capabilities
This LFB does not have a list of capabilities
5.3.4.4. Events
This LFB does not have any events specified.
5.4. Redirect LFBs
Redirect LFBs abstract data packets transportation process between CE
and FE. Some packets output from some LFBs may have to 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.
Wang, et al. Expires January 11, 2012 [Page 58]
Internet-Draft ForCES LFB Library July 2011
5.4.1. RedirectIn
RedirectIn LFB abstracts the process for the CE to inject data
packets into the FE data path.
5.4.1.1. Data Handling
A RedirectIn LFB abstracts the process for the CE to inject data
packets into the 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.
The RedirectIn LFB has only one output defined as a group output
known as "PktsOut". Packets produced by this output will have
arbitrary frame types decided by the CE which generated the packets.
Possible frames may include IPv4, IPv6, or ARP protocol packets. The
CE may associate some metadata to indicate the frame types and may
also associate other metadata to indicate various information on the
packets. Among them, there MUST exist a 'RedirectIndex' metadata,
which is an integer acting as an index. When the CE transmits the
metadata along with the packet to a RedirectIn LFB, the LFB will read
the RedirectIndex metadata and output the packet to one of its group
output port instance, whose port index is indicated by the metadata.
All metadata from the 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.
5.4.1.2. Components
There are no components defined for the current version of RedirectIn
LFB.
5.4.1.3. Capabilities
This LFB does not have a list of capabilities
5.4.1.4. Events
This LFB does not have any events specified.
5.4.2. RedirectOut
RedirectOut LFB abstracts the process for LFBs in the FE to deliver
data packets to the CE.
Wang, et al. Expires January 11, 2012 [Page 59]
Internet-Draft ForCES LFB Library July 2011
5.4.2.1. Data Handling
A RedirectOut LFB abstracts the process for LFBs in the FE to deliver
data packets to the CE. From the LFB's topology point of view, the
RedirectOut LFB acts as a sink point for data packets going to the
CE, therefore the RedirectOut LFB is defined with only one input,
while without any output.
The RedirectOut LFB has only one singleton input known as "PktsIn",
but is capable of receiving packets from multiple LFBs by
multiplexing this input. The input expects any kind of frame type
therefore the frame type has been specified as arbitrary and also all
types of metadata are expected. All metadata associated with the
input packets will be delivered to CE via the ForCES protocol
redirect message [RFC5810].
5.4.2.2. Components
There are no components defined for the current version of
RedirectOut LFB.
5.4.2.3. Capabilities
This LFB does not have a list of capabilities
5.4.2.4. Events
This LFB does not have any events specified.
5.5. General Purpose LFBs
5.5.1. BasicMetadataDispatch
A basic medatata dispatch LFB is defined to abstract the process in
which a packet is dispatched to some path based on its associated
metadata value.
5.5.1.1. Data Handling
The BasicMetadataDispatch LFB provides the function to dispatch input
packets to a group output according to a metadata and a dispatch
table.
The BasicMetadataDispatch has only one singleton input known as
"PktsIn" and expects any kind of frame type, therefore it has been
specified as arbitrary, along with a metadata that will be used by
the LFB to do the dispatch. If a packet is not associated with such
a metadata, the packet will be dropped inside the LFB.
Wang, et al. Expires January 11, 2012 [Page 60]
Internet-Draft ForCES LFB Library July 2011
The BasicMetadataDispatch LFB has only one output defined as a group
output known as "PktsOut". 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
Metadata Dispatch table. Currently the BasicMetadataDispatch only
allows an interger value for the metadata to be used for dispatch.
The BasicMetadataDispatch LFB is currently defined with only one
metadata adopted for dispatch, i.e., the metadata ID in 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.5.1.2. Components
This LFB has only one component named MetadataDispatchTable which is
defined as an array. Each row of the array is a struct containing a
Metadata ID, a Metadata value and the OutputIndex to selectt the
output port from the group.
5.5.1.3. Capabilities
This LFB does not have a list of capabilities
5.5.1.4. Events
This LFB does not have any events specified.
5.5.2. GenericScheduler
This is a preliminary generic scheduler LFB for abstracting a simple
scheduling process.
5.5.2.1. Data Handling
There exist various kinds of scheduling strategies with various
implementations. As a base LFB library, this document only defines 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 [RFC5812].
Packets of any arbitrary frame type are received via a group input
known as "PktsIn" with no additional metadata expected. This group
input is capable of multiple input port instances. Each port
instance may be connected to different upstream LFB output.
Wang, et al. Expires January 11, 2012 [Page 61]
Internet-Draft ForCES LFB Library July 2011
Multiple queues reside at the input side, with every input port
instance connected to one queue. Every queue is marked with a queue
ID, and the queue ID is exactly the same as the index of
corresponding input port instance. Scheduling disciplines are
applied to all queues and also all packets in the queues.
Scheduled packets are output from a singleton output port of the LFB
knows as "PktsOut" with no corresponding metadata.
More complex scheduler LFBs may be defined with more complex
scheduling disciplines by succeeding this LFB. For instance, a
priority scheduler LFB may be defined only by inheriting this LFB and
defining a component to indicate priorities for all input queues.
5.5.2.2. Components
The QueueCount component is defined to specify the number of queues
to be scheduled.
The SchedulingDiscipline component is for the CE to specify a
scheduling discipline to the LFB. Currently defined scheduling
disciplines only include FIFO and Round Robin (RR). When a FIFO
discipline is applied, it is requires that there is only one input
port instance for the group input. If the user accidentally defines
multiple input port instances for FIFO scheduling, only packets 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. Note 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).
The CurrentQueueDepth component is defined to allow CE to query every
queue status of the scheduler. It is an array component and each row
of the array is a struct containing a queue ID, the queue depth in
packets and the queue depth in bytes. Using the queue ID as the
index, the CE can query every queue for its used length in unit of
packets or bytes.
5.5.2.3. Capabilities
Three capabilities are currently defined for the GenericScheduler.
o A queue number limit, which specify the limit of the maximum
supported number of queues, which is also the maximum number of
input port instances.
Wang, et al. Expires January 11, 2012 [Page 62]
Internet-Draft ForCES LFB Library July 2011
o The supported scheduling disciplines types by the FE, currently
maximum 6.
o The queue length limit providing the storage ability for every
queue.
5.5.2.4. Events
This LFB does not have any events specified.
Wang, et al. Expires January 11, 2012 [Page 63]
Internet-Draft ForCES LFB Library July 2011
6. XML for LFB Library
<?xml version="1.0" encoding="UTF-8"?>
<LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
provides="BaseLFBLibrary">
<load library="BaseTypeLibrary"/>
<LFBClassDefs>
<LFBClassDef LFBClassID="3">
<name>EtherPHYCop</name>
<synopsis>The LFB describes an Ethernet port abstracted at
physical layer.It limits its physical media to copper.
Multiple virtual PHYs isn't supported in this LFB version.
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>EtherPHYIn</name>
<synopsis>The input port of the EtherPHYCop LFB. It
expects any kind of Ethernet frame.</synopsis>
<expectation>
<frameExpected>
<ref>EthernetAll</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort>
<name>EtherPHYOut</name>
<synopsis>The output port of the EtherPHYCop LFB. It
can produce any kind of Ethernet frame and along with
the frame passes the ID of the Physical Port as
metadata to be used by the next LFBs.</synopsis>
<product>
<frameProduced>
<ref>EthernetAll</ref>
</frameProduced>
<metadataProduced>
<ref>PHYPortID</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1" access="read-only">
<name>PHYPortID</name>
Wang, et al. Expires January 11, 2012 [Page 64]
Internet-Draft ForCES LFB Library July 2011
<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 of the LFB</synopsis>
<typeRef>PortStatusValues</typeRef>
<defaultValue>2</defaultValue>
</component>
<component componentID="3" access="read-only">
<name>OperStatus</name>
<synopsis>Operational 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>
Wang, et al. Expires January 11, 2012 [Page 65]
Internet-Draft ForCES LFB Library July 2011
<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
Wang, et al. Expires January 11, 2012 [Page 66]
Internet-Draft ForCES LFB Library July 2011
is changed, the LFB sends the new operational mode.
</synopsis>
<eventTarget>
<eventField>OperDuplexMode</eventField>
</eventTarget>
<eventChanged/>
<eventReports>
<eventReport>
<eventField>OperDuplexMode</eventField>
</eventReport>
</eventReports>
</event>
</events>
</LFBClassDef>
<LFBClassDef LFBClassID="4">
<name>EtherMACIn</name>
<synopsis>An LFB abstracts an Ethernet port at MAC data link
layer. It specifically describes Ethernet processing functions
like MAC address locality check, deciding if the Ethernet
packets should be bridged, provide Ethernet layer flow control,
etc.Multiple virtual MACs isn't supported in this LFB
version.</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort group="false">
<name>EtherMACIn</name>
<synopsis>The input port of the EtherMACIn. It
expects any kind of Ethernet frame.</synopsis>
<expectation>
<frameExpected>
<ref>EthernetAll</ref>
</frameExpected>
<metadataExpected>
<ref>PHYPortID</ref>
</metadataExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort group="false">
<name>NormalPathOut</name>
<synopsis>The normal output port of the 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>
Wang, et al. Expires January 11, 2012 [Page 67]
Internet-Draft ForCES LFB Library July 2011
</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 of the port</synopsis>
<typeRef>PortStatusValues</typeRef>
<defaultValue>2</defaultValue>
</component>
<component componentID="2" access="read-write">
<name>LocalMACAddresses</name>
<synopsis>Local Mac addresses</synopsis>
<array>
<typeRef>IEEEMAC</typeRef>
</array>
</component>
<component componentID="3" access="read-write">
<name>L2BridgingPathEnable</name>
<synopsis>Is the LFB doing L2 Bridging?</synopsis>
<typeRef>boolean</typeRef>
<defaultValue>false</defaultValue>
</component>
<component componentID="4" access="read-write">
<name>PromiscuousMode</name>
<synopsis>Is the LFB in Promiscuous Mode?</synopsis>
<typeRef>boolean</typeRef>
<defaultValue>false</defaultValue>
</component>
Wang, et al. Expires January 11, 2012 [Page 68]
Internet-Draft ForCES LFB Library July 2011
<component componentID="5" access="read-write">
<name>TxFlowControl</name>
<synopsis>Transmit flow control</synopsis>
<typeRef>boolean</typeRef>
<defaultValue>false</defaultValue>
</component>
<component componentID="6" access="read-write">
<name>RxFlowControl</name>
<synopsis>Receive flow control</synopsis>
<typeRef>boolean</typeRef>
<defaultValue>false</defaultValue>
</component>
<component componentID="7" access="read-reset">
<name>MACInStats</name>
<synopsis>MACIn statistics</synopsis>
<typeRef>MACInStatsType</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="5">
<name>EtherClassifier</name>
<synopsis>This 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.</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>EtherPktsIn</name>
<synopsis>Input port for data packet.</synopsis>
<expectation>
<frameExpected>
<ref>EthernetAll</ref>
</frameExpected>
<metadataExpected>
<ref>PHYPortID</ref>
<ref dependency="optional" defaultValue="0">
LogicalPortID</ref>
</metadataExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort group="true">
<name>ClassifyOut</name>
<synopsis>Output port for classification.</synopsis>
<product>
<frameProduced>
Wang, et al. Expires January 11, 2012 [Page 69]
Internet-Draft ForCES LFB Library July 2011
<ref>Arbitrary</ref>
</frameProduced>
<metadataProduced>
<ref>PHYPortID</ref>
<ref>SrcMAC</ref>
<ref>DstMAC</ref>
<ref>EtherType</ref>
<ref availability="conditional">VlanID</ref>
<ref availability="conditional">VlanPriority</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component access="read-write" componentID="1">
<name>EtherDispatchTable</name>
<synopsis>Ether classify dispatch table</synopsis>
<typeRef>EtherDispatchTableType</typeRef>
</component>
<component access="read-write" componentID="2">
<name>VlanInputTable</name>
<synopsis>Vlan input table</synopsis>
<typeRef>VlanInputTableType</typeRef>
</component>
<component access="read-reset" componentID="3">
<name>EtherClassifyStats</name>
<synopsis>Ether classify statistic table</synopsis>
<typeRef>EtherClassifyStatsTableType</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="6">
<name>EtherEncap</name>
<synopsis>This LFB abstracts the process to encapsulate IP
packets to Ethernet packets according to the L2 information.
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort group="false">
<name>EncapIn</name>
<synopsis>A Single Packet Input</synopsis>
<expectation>
<frameExpected>
<ref>IPv4</ref>
<ref>IPv6</ref>
</frameExpected>
<metadataExpected>
<ref>MediaEncapInfoIndex</ref>
Wang, et al. Expires January 11, 2012 [Page 70]
Internet-Draft ForCES LFB Library July 2011
<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>L2PortID</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort group="false">
<name>ExceptionOut</name>
<synopsis>All packets that fail with the other
operations in this LFB are output via this port.
</synopsis>
<product>
<frameProduced>
<ref>IPv4</ref>
<ref>IPv6</ref>
</frameProduced>
<metadataProduced>
<ref>ExceptionID</ref>
<ref>MediaEncapInfoIndex</ref>
<ref availability="conditional">VlanPriority</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1" access="read-write">
<name>EncapTable</name>
<synopsis>Ethernet Encapsulation table.</synopsis>
<typeRef>EncapTableType</typeRef>
</component>
</components>
</LFBClassDef>
Wang, et al. Expires January 11, 2012 [Page 71]
Internet-Draft ForCES LFB Library July 2011
<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 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-write">
<name>AdminStatus</name>
<synopsis>Admin status of the port. It is the alias of
"AdminStatus" component defined in EtherMACIn.
</synopsis>
<alias>PortStatusValues</alias>
Wang, et al. Expires January 11, 2012 [Page 72]
Internet-Draft ForCES LFB Library July 2011
</component>
<component componentID="2" access="read-write">
<name>MTU</name>
<synopsis>Maximum transmission unit.</synopsis>
<typeRef>uint32</typeRef>
</component>
<component componentID="3" access="read-write">
<name>TxFlowControl</name>
<synopsis>Transmit flow control. It is the alias of
"TxFlowControl" component defined in EtherMACIn.
</synopsis>
<alias>boolean</alias>
</component>
<component componentID="4" access="read-write">
<name>RxFlowControl</name>
<synopsis>Receive flow control. It is the alias of
"RxFlowControl" component defined in EtherMACIn.
</synopsis>
<alias>boolean</alias>
</component>
<component componentID="5" access="read-reset">
<name>MACOutStats</name>
<synopsis>MACOut statistics</synopsis>
<typeRef>MACOutStatsType</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="8">
<name>IPv4Validator</name>
<synopsis>An LFB that performs IPv4 packets validation
according to RFC1812. At the same time, ipv4 unicast and
multicast are classified in this LFB.</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>ValidatePktsIn</name>
<synopsis>Input port for data packet.</synopsis>
<expectation>
<frameExpected>
<ref>Arbitrary</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort>
<name>IPv4UnicastOut</name>
<synopsis>Output for IPv4 unicast packet.</synopsis>
Wang, et al. Expires January 11, 2012 [Page 73]
Internet-Draft ForCES LFB Library July 2011
<product>
<frameProduced>
<ref>IPv4Unicast</ref>
</frameProduced>
</product>
</outputPort>
<outputPort>
<name>IPv4MulticastOut</name>
<synopsis>Output for IPv4 multicast packet.</synopsis>
<product>
<frameProduced>
<ref>IPv4Multicast</ref>
</frameProduced>
</product>
</outputPort>
<outputPort>
<name>ExceptionOut</name>
<synopsis>Output for exception packet.</synopsis>
<product>
<frameProduced>
<ref>IPv4</ref>
</frameProduced>
<metadataProduced>
<ref>ExceptionID</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort>
<name>FailOut</name>
<synopsis>Output for failed validation packet.
</synopsis>
<product>
<frameProduced>
<ref>IPv4</ref>
</frameProduced>
<metadataProduced>
<ref>ValidateErrorID</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component access="read-write" componentID="1">
<name>IPv4ValidatorStats</name>
<synopsis>IPv4 validator statistics information.
</synopsis>
<typeRef>IPv4ValidatorStatsType</typeRef>
</component>
Wang, et al. Expires January 11, 2012 [Page 74]
Internet-Draft ForCES LFB Library July 2011
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="9">
<name>IPv6Validator</name>
<synopsis>An LFB that performs IPv6 packets validation
according to RFC2460. At the same time, ipv6 unicast and
multicast are classified in this LFB.</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>ValidatePktsIn</name>
<synopsis>Input port for data packet.</synopsis>
<expectation>
<frameExpected>
<ref>Arbitrary</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort>
<name>IPv6UnicastOut</name>
<synopsis>Output for IPv6 unicast packet.</synopsis>
<product>
<frameProduced>
<ref>IPv6Unicast</ref>
</frameProduced>
</product>
</outputPort>
<outputPort>
<name>IPv6MulticastOut</name>
<synopsis>Output for IPv6 multicast packet.</synopsis>
<product>
<frameProduced>
<ref>IPv6Multicast</ref>
</frameProduced>
</product>
</outputPort>
<outputPort>
<name>ExceptionOut</name>
<synopsis>Output for exception packet.</synopsis>
<product>
<frameProduced>
<ref>IPv6</ref>
</frameProduced>
<metadataProduced>
<ref>ExceptionID</ref>
</metadataProduced>
Wang, et al. Expires January 11, 2012 [Page 75]
Internet-Draft ForCES LFB Library July 2011
</product>
</outputPort>
<outputPort>
<name>FailOut</name>
<synopsis>Output for failed validation packet.
</synopsis>
<product>
<frameProduced>
<ref>IPv6</ref>
</frameProduced>
<metadataProduced>
<ref>ValidateErrorID</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component access="read-write" componentID="1">
<name>IPv6ValidatorStats</name>
<synopsis>IPv6 validator statistics information.
</synopsis>
<typeRef>IPv6ValidatorStatsType</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="10">
<name>IPv4UcastLPM </name>
<synopsis>An LFB that performs IPv4 Longest Prefix Match
Lookup.It is defined to provide some facilities to support
users to implement equal-cost multi-path routing(ECMP) or
reverse path forwarding (RPF).</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort group="false">
<name>PktsIn</name>
<synopsis>A Single Packet Input</synopsis>
<expectation>
<frameExpected>
<ref>IPv4Unicast</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort group="false">
<name>NormalOut</name>
<synopsis>This output port is connected with
IPv4NextHop LFB</synopsis>
Wang, et al. Expires January 11, 2012 [Page 76]
Internet-Draft ForCES LFB Library July 2011
<product>
<frameProduced>
<ref>IPv4Unicast</ref>
</frameProduced>
<metadataProduced>
<ref>HopSelector</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort group="false">
<name>ECMPOut</name>
<synopsis>This output port is connected with ECMP LFB,
if there is ECMP LFB in the FE.</synopsis>
<product>
<frameProduced>
<ref>IPv4Unicast</ref>
</frameProduced>
<metadataProduced>
<ref>HopSelector</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort group="false">
<name>ExceptionOut</name>
<synopsis>The output for the packet if an exception
occurs</synopsis>
<product>
<frameProduced>
<ref>IPv4Unicast</ref>
</frameProduced>
<metadataProduced>
<ref>ExceptionID</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1" access="read-write">
<name>IPv4PrefixTable</name>
<synopsis>The IPv4 prefix table.</synopsis>
<typeRef>IPv4PrefixTableType</typeRef>
</component>
<component componentID="2" access="read-reset">
<name>IPv4UcastLPMStats</name>
<synopsis>Statistics for IPv4 Unicast Longest Prefix
Match</synopsis>
<typeRef>IPv4UcastLPMStatsType</typeRef>
</component>
Wang, et al. Expires January 11, 2012 [Page 77]
Internet-Draft ForCES LFB Library July 2011
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="11">
<name>IPv6UcastLPM </name>
<synopsis>An LFB that performs IPv6 Longest Prefix Match
Lookup.It is defined to provide some facilities to support
users to implement equal-cost multi-path routing(ECMP) or
reverse path forwarding (RPF).</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort group="false">
<name>PktsIn</name>
<synopsis>A Single Packet Input</synopsis>
<expectation>
<frameExpected>
<ref>IPv6Unicast</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort group="false">
<name>NormalOut</name>
<synopsis>This output port is connected with
IPv6NextHop LFB</synopsis>
<product>
<frameProduced>
<ref>IPv6Unicast</ref>
</frameProduced>
<metadataProduced>
<ref>HopSelector</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort group="false">
<name>ECMPOut</name>
<synopsis>This output port is connected with ECMP LFB,
if there is ECMP LFB in the FE.</synopsis>
<product>
<frameProduced>
<ref>IPv6Unicast</ref>
</frameProduced>
<metadataProduced>
<ref>HopSelector</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort group="false">
Wang, et al. Expires January 11, 2012 [Page 78]
Internet-Draft ForCES LFB Library July 2011
<name>ExceptionOut</name>
<synopsis>The output for the packet if an exception
occurs</synopsis>
<product>
<frameProduced>
<ref>IPv6Unicast</ref>
</frameProduced>
<metadataProduced>
<ref>ExceptionID</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1" access="read-write">
<name>IPv6PrefixTable</name>
<synopsis>The IPv6 prefix table.</synopsis>
<typeRef>IPv6PrefixTableType</typeRef>
</component>
<component componentID="2" access="read-reset">
<name>IPv6UcastLPMStats</name>
<synopsis>Statistics for IPv6 Unicast Longest Prefix
Match</synopsis>
<typeRef>IPv6UcastLPMStatsType</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="12">
<name>IPv4NextHop</name>
<synopsis>This LFB abstracts the process of selecting ipv4
next hop action. It receives an IPv4 packet with an
associated next hop ID, and uses the ID to look up a next
hop table to find an appropriate output port from the LFB.
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort group="false">
<name>PktsIn</name>
<synopsis>A Single Packet Input</synopsis>
<expectation>
<frameExpected>
<ref>IPv4Unicast</ref>
</frameExpected>
<metadataExpected>
<ref>HopSelector</ref>
</metadataExpected>
</expectation>
</inputPort>
Wang, et al. Expires January 11, 2012 [Page 79]
Internet-Draft ForCES LFB Library July 2011
</inputPorts>
<outputPorts>
<outputPort group="true">
<name>SuccessOut</name>
<synopsis>The output for the packet if it is valid to be
forwarded</synopsis>
<product>
<frameProduced>
<ref>IPv4Unicast</ref>
</frameProduced>
<metadataProduced>
<ref>L3PortID</ref>
<ref>NextHopIPv4Addr</ref>
<ref availability="conditional">
MediaEncapInfoIndex</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort group="false">
<name>ExceptionOut</name>
<synopsis>The output for the packet if an exception
occurs</synopsis>
<product>
<frameProduced>
<ref>IPv4Unicast</ref>
</frameProduced>
<metadataProduced>
<ref>ExceptionID</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1">
<name>IPv4NextHopTable</name>
<synopsis>The next hop table.</synopsis>
<typeRef>IPv4NextHopTableType</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="13">
<name>IPv6NextHop</name>
<synopsis>The LFB abstracts the process of next hop
information application to IPv6 packets. It receives an IPv4
packet with an associated next hop ID, and uses the ID to
look up a next hop table to find an appropriate output port
from the LFB..</synopsis>
<version>1.0</version>
Wang, et al. Expires January 11, 2012 [Page 80]
Internet-Draft ForCES LFB Library July 2011
<inputPorts>
<inputPort group="false">
<name>PktsIn</name>
<synopsis>A single packet input.</synopsis>
<expectation>
<frameExpected>
<ref>IPv6Unicast</ref>
</frameExpected>
<metadataExpected>
<ref>HopSelector</ref>
</metadataExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort group="true">
<name>SuccessOut</name>
<synopsis>The output for the packet if it is valid to
be forwarded</synopsis>
<product>
<frameProduced>
<ref>IPv6Unicast</ref>
</frameProduced>
<metadataProduced>
<ref>L3PortID</ref>
<ref>NextHopIPv6Addr</ref>
<ref availability="conditional">
MediaEncapInfoIndex</ref>
</metadataProduced>
</product>
</outputPort>
<outputPort group="false">
<name>ExceptionOut</name>
<synopsis>The output for the packet if an exception
occurs</synopsis>
<product>
<frameProduced>
<ref>IPv6Unicast</ref>
</frameProduced>
<metadataProduced>
<ref>ExceptionID</ref>
</metadataProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component componentID="1">
<name>IPv6NextHopTable</name>
Wang, et al. Expires January 11, 2012 [Page 81]
Internet-Draft ForCES LFB Library July 2011
<synopsis>The next hop table.</synopsis>
<typeRef>IPv6NextHopTableType</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="14">
<name>RedirectIn</name>
<synopsis>The RedirectIn LFB abstracts the process for CE to
inject data packets into FE LFB topology, so as to input data
packets into FE data paths. CE may associate some
metadata to data packets to indicate various information on
the packets. Among them, there MUST exist a 'RedirectIndex'
metadata, which is an integer acting as an output port index.
</synopsis>
<version>1.0</version>
<outputPorts>
<outputPort group="true">
<name>PktsOut</name>
<synopsis>This output group sends the redirected packet
in the data path.</synopsis>
<product>
<frameProduced>
<ref>Arbitrary</ref>
</frameProduced>
</product>
</outputPort>
</outputPorts>
</LFBClassDef>
<LFBClassDef LFBClassID="15">
<name>RedirectOut</name>
<synopsis>The LFB abstracts the process for LFBs in
FE to deliver data packets to CE. All metadata
associated with the input packets will be delivered to CE
via the redirect message of ForCES protocol [RFC5810].
</synopsis>
<version>1.0</version>
<inputPorts>
<inputPort group="false">
<name>PktsIn</name>
<synopsis>This input receives packets to send to
the CE.</synopsis>
<expectation>
<frameExpected>
<ref>Arbitrary</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
Wang, et al. Expires January 11, 2012 [Page 82]
Internet-Draft ForCES LFB Library July 2011
</LFBClassDef>
<LFBClassDef LFBClassID="16">
<name>BasicMetadataDispatch</name>
<synopsis>This LFB provides the function to dispatch input
packets to a group output according to a metadata and a
dispatch table.This LFB currently only allow a metadata with
an interger value to be used for dispatch. </synopsis>
<version>1.0</version>
<inputPorts>
<inputPort>
<name>PktsIn</name>
<synopsis>Input port for data packet.</synopsis>
<expectation>
<frameExpected>
<ref>Arbitrary</ref>
</frameExpected>
<metadataExpected>
<ref>Arbitrary</ref>
</metadataExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort group="true">
<name>PktsOut</name>
<synopsis>Data packet output</synopsis>
<product>
<frameProduced>
<ref>Arbitrary</ref>
</frameProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component access="read-write" componentID="1">
<name>MetadataDispatchTable</name>
<synopsis>Metadata dispatch table.</synopsis>
<typeRef>MetadataDispatchTableType</typeRef>
</component>
</components>
</LFBClassDef>
<LFBClassDef LFBClassID="17">
<name>GenericScheduler</name>
<synopsis>This is a preliminary generic scheduler LFB for
abstracting a simple scheduling process.Users may use this
LFB as a basic scheduler LFB to further construct more
complex scheduler LFBs by means of inheritance as described
in RFC 5812.</synopsis>
Wang, et al. Expires January 11, 2012 [Page 83]
Internet-Draft ForCES LFB Library July 2011
<version>1.0</version>
<inputPorts>
<inputPort group="true">
<name>PktsIn</name>
<synopsis>Input port for data packet.</synopsis>
<expectation>
<frameExpected>
<ref>Arbitrary</ref>
</frameExpected>
</expectation>
</inputPort>
</inputPorts>
<outputPorts>
<outputPort>
<name>PktsOut</name>
<synopsis>Data packet output.</synopsis>
<product>
<frameProduced>
<ref>Arbitrary</ref>
</frameProduced>
</product>
</outputPort>
</outputPorts>
<components>
<component access="read-only" componentID="1">
<name>QueueCount</name>
<synopsis>The number of queues to be scheduled.
</synopsis>
<typeRef>uint32</typeRef>
</component>
<component access="read-write" componentID="2">
<name>SchedulingDiscipline</name>
<synopsis>the Scheduler discipline.</synopsis>
<typeRef>SchdDisciplineType</typeRef>
</component>
<component access="read-only" componentID="3">
<name>CurrentQueueDepth</name>
<synopsis>Current Depth of all queues</synopsis>
<typeRef>QueueDepthTableType</typeRef>
</component>
</components>
<capabilities>
<capability componentID="30">
<name>QueueLenLimit</name>
<synopsis>Maximum length of each queue,the unit is
byte.</synopsis>
<typeRef>uint32</typeRef>
</capability>
Wang, et al. Expires January 11, 2012 [Page 84]
Internet-Draft ForCES LFB Library July 2011
<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>
Wang, et al. Expires January 11, 2012 [Page 85]
Internet-Draft ForCES LFB Library July 2011
7. LFB Class Use Cases
This section demonstrates examples on how the LFB classes defined by
the Base LFB library in Section 6 are applied to achieve some typical
router functions. The functions to demonstrate are:
o IPv4 forwarding
o ARP processing
To achieve the functions, processing paths organized by the LFB
classes with their interconnections should be established in FE. In
general, CE controls and manages the processing paths by use of the
ForCES protocol.
Note that LFB class use cases shown in this section are only as
examples to demonstrate how typical router functions are able to be
implemented with the defined base LFB library. Users and
implementers should not be limited by the example use cases.
7.1. IPv4 Forwarding
Figure 1 (Section 3.2.3) shows a normal IPv4 forwarding processing
path by use of the base LFB classes. To make it in focus, LFB
classes that are not close to IPv4 forwarding function are ignored in
the figure. Moreover, inputs or outputs of some LFBs that are not
related to IP forwarding are also ignored in the LFB figure.
In the example case, network interfaces are limited to copper
Ethernet ports. A number of EtherPHYCop LFBs are used to describe
physical layer functions of the ports. An EtherMACIn LFB follows
every EtherPHYCop LFB to describe the MAC layer processing. A
PHYPortID metadatum is generated by EtherPHYCop LFB and will be used
by all the following LFBs. In EtherMACIn LFB, a locality check of
MAC addresses may be performed if CE asks to do so by configuring the
LFB component.
Ethernet packets out of the EtherMACIn LFB are sent to an
EtherClassifier LFB to be decapsulated and classified into network
layer types like IPv4, IPv6, ARP, etc. In the example case, every
physical Ethernet interface is associated with one Classifier
instance, whereas it is also practical that all physical interfaces
are associated with only one Ethernet Classifier instance.
EtherClassifier will use PHYPortID and Ethernet type of the input
packet and VlanID, if exists in the input Ethernet packets, to decide
the packet network layer type and its output port from this LFB, and
also to assign a new logical port ID to the packet for later use. At
the same time, the LFB also generate some new metadata for every
Wang, et al. Expires January 11, 2012 [Page 86]
Internet-Draft ForCES LFB Library July 2011
packet like EtherType, SrcMAC, DstMAC, LogicPortID, etc for later
LFBs to use.
If a packet is classified as an IPv4 packet, it will be sent to an
IPv4Validator LFB to validate the IPv4 packet. In the validator LFB,
IPv4 packets will be classified into IPv4 unicast packets and
multicast packets, as well as validating the IPv4 packets.
IPv4 unicast packets will be sent to IPv4UcastLPM LFB, where LPM is
made and a next hop ID is achieved. The packet with the next hop ID
is further sent to an IPv4NextHop LFB, where further next hop
information is found for this packet. The information includes where
the packet is to go next and even the media encapsulation type for
the port, etc. An L3PortID is used to identify a next hop output
port, which is represented as a metadatum associated with the packet
to be forwarded to via port. In the example case, the next hop
output port is an Ethernet type. As a result, the packet and its L3
port ID metadatum are sent to an EtherEncap LFB, where the packet is
encapsulated as an Ethernet packet. A BasicMetadataDispatch LFB
follows the EtherEncap LFB where packets will be dispatched to
different output port according to the L3PortID metadatum sent to the
LFB. As a result, IPv4 packets are forwarded out via various output
ports.
7.2. ARP processing
Figure 2 shows the processing path for ARP protocol in the case that
there is no specific ARP processing LFBs in FE. In such case, CE
should implement the ARP processing function. As usual, to make it
in focus, the figure ignores LFB classes that are not related to ARP
processing. The figure also ignores some inputs or outputs of LFBs
that are out of the scope of ARP processing.
The example case still takes Ethernet ports as its network
interfaces.
Wang, et al. Expires January 11, 2012 [Page 87]
Internet-Draft ForCES LFB Library July 2011
+---+ +---+
| | ARP packets | |
| |------------------------+--->| | To CE
...-->| | . | | |
| | . | +---+
| | . | RedirectOut
+---+ |
Ether EtherEncap | IPv4 packets lack
Classifier +---+ | address resolution information
| | |
Packets need | |--------->---+
...--------->| |
L2 Encapsulation| |
+---+ | | +------+
| | +-->| |--+ +---+ |Ether |
| | | +---+ | | |--------->|MACOut|-->...
From CE| |--+ +-->| | . +------+
| |ARP Packets | | .
| |from CE | | . +------+
| | | |--------> |Ether |-->...
+---+ +---+ |MACOut|
RedirectIn BasicMetadata +------+
Dispatch
Figure 2: LFB use case for ARP
As the figure shows, ARP protocol packets from network interfaces can
be filtered out by EtherClassifier LFB. In the example case, we
presume the FE does not provide ability for ARP processing and relies
on CE to do the work. Hence, the classified ARP packets and some
associated metadata are then sent to RedirectOut LFB so as to be
transported to CE. CE can then process the received APR packets to
get information to establish ARP tables. While it depends on
individual implementations how this is implemented and is out of the
scope of ForCES
When CE deploys ARP function, it may need to generate ARP request or
response packets and send them back to outer networks. To do so, the
packets are redirected to FE through a RedirectIn LFB first. Then,
just like to forward IPv4 packets, the ARP packets are also
encapsulated to Ethernet format by an EtherEncap LFB, and then
dispatched to different interfaces via a BasicMetadataDispatch LFB.
The BasicMetadataDispatch LFB will dispatch the packets according to
the L3PortID metadatum included in every ARP packet sent from CE.
The EtherEncap LFB also receives packets that need Ethernet L2
encapsulating. If the encapsulator finds that it can not fulfill
Wang, et al. Expires January 11, 2012 [Page 88]
Internet-Draft ForCES LFB Library July 2011
encapsulating some packets because of lack of L2 Ethernet information
for the packets, the LFB will output the packets from the
ExceptionOut output of the LFB. By connecting this output to
RedirectOut LFB, the packets can be redirected to CE for further ARP
processing. See Section 5.1.4 for details. CE may then generate ARP
requests based on the packets, and redirect ARP request messages to
FE to send to networks, just as the procedure shown above.
With these mechanisms and procedures, ARP function is expected to be
implemented by CE with the help from FE.
Wang, et al. Expires January 11, 2012 [Page 89]
Internet-Draft ForCES LFB Library July 2011
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
Wang, et al. Expires January 11, 2012 [Page 90]
Internet-Draft ForCES LFB Library July 2011
9. Acknowledgements
This document is based on earlier documents from Joel Halpern, Ligang
Dong, Fenggen Jia and Weiming Wang.
Wang, et al. Expires January 11, 2012 [Page 91]
Internet-Draft ForCES LFB Library July 2011
10. IANA Considerations
IANA has created a registry of ForCES LFB Class Names and the
corresponding ForCES LFB Class Identifiers, with the location of the
definition of the ForCES LFB Class, in accordance with the rules to
use the namespace.
The LFB library in this document needs for unique class names and
numeric class identifiers of all LFBs. Besides, this document also
needs to define the following namespaces:
o Metadata ID, defined in Section 4.3 and Section 4.4
o Exception ID, defined in Section 4.4
o Validate Error ID, defined in Section 4.4
10.1. LFB Class Names and LFB Class Identifiers
LFB classes defined by this document belongs to IETF defined LFBs by
Standard Track RFCs. According to IANA, the identifier namespace for
these LFB classes is from 3 to 65535.
The assignment of LFB class names and LFB class identifiers is as in
the following table.
+-----------+---------------+------------------------+--------------+
| LFB Class | LFB Class Name| Description | Reference |
| Identifier| | | |
+-----------+---------------+------------------------+--------------+
| 3 | EtherPHYCop | Define an Ethernet port| RFC????(this|
| | | abstracted at physical | document) |
| | | layer | Section 5.1.1|
| | | -------------- | |
| 4 | EtherMACIn | Define an Ethernet | RFC???? |
| | | input port at MAC data | Section 5.1.2|
| | | link layer | |
| | | -------------- | |
| 5 |EtherClassifier| Define the process to | RFC???? |
| | | decapsulate Ethernet | Section 5.1.3|
| | | packets and classify | |
| | | the packets | |
| | | -------------- | |
| 6 | EtherEncap | Define the process to | RFC???? |
| | | encapsulate IP packets | Section 5.1.4|
| | | to Ethernet packets | |
| | | -------------- | |
Wang, et al. Expires January 11, 2012 [Page 92]
Internet-Draft ForCES LFB Library July 2011
| 7 | EtherMACOut | Define an Ethernet | RFC ???? |
| | | output port at MAC | Section 5.1.5|
| | | data link layer | |
| | | -------------- | |
| 8 | IPv4Validator | Perform IPv4 packets | RFC ???? |
| | | validation. | Section 5.2.1|
| | | -------------- | |
| 9 | IPv6Validator | Perform IPv6 packets | RFC ???? |
| | | validation | Section 5.2.2|
| | | -------------- | |
| 10 | IPv4UcastLPM | Perform IPv4 Longest | RFC ???? |
| | | Prefix Match Lookup | Section 5.3.1|
| | | -------------- | |
| 11 | IPv6UcastLPM | Perform IPv6 Longest | RFC ???? |
| | | Prefix Match Lookup | Section 5.3.3|
| | | -------------- | |
| 12 | IPv4NextHop | Define the process of | RFC ??? |
| | | selecting Ipv4 next hop| Section 5.3.2|
| | | action | |
| | | -------------- | |
| 13 | IPv6NextHop | Define the process of | RFC ??? |
| | | selecting Ipv6 next hop| Section 5.3.4|
| | | action | |
| | | -------------- | |
| 14 | RedirectIn | Define the process for | RFC ??? |
| | | CE to inject data | Section 5.4.1|
| | | packets into FE LFB | |
| | | topology | |
| | | -------------- | |
| 15 | RedirectOut | Define the process for | RFC ??? |
| | | LFBs in FE to deliver | Section 5.4.2|
| | | data packets to CE | |
| | | -------------- | |
| 16 |BasicMetadata | Dispatch input packets | RFC ??? |
| |Dispatch | to a group output | Section 5.5.1|
| | | according to a metadata| |
| | | -------------- | |
| 17 |Generic | Define a preliminary | RFC ???? |
| |Scheduler | generic scheduling | Section 5.5.2|
| | | process | |
+-----------+---------------+------------------------+--------------+
Table 1
Wang, et al. Expires January 11, 2012 [Page 93]
Internet-Draft ForCES LFB Library July 2011
10.2. Metadata ID
The Metadata ID namespace is 32 bits long. The following is the
guideline for managing the namespace.
Metadata ID 0x00000000-0x7FFFFFFF
Metadata with IDs in this range are Specification Required
[RFC5226]. A metadata ID using this range MUST be documented in
an RFC or other permanent and readily available references.
Values assigned by this specification:
+--------------+-------------------------+--------------------------+
| Value | Name | Definition |
+--------------+-------------------------+--------------------------+
| 0x00000001 | EtherPHYCop | See Section 4.4 |
| 0x00000002 | SrcMAC | See Section 4.4 |
| 0x00000003 | DstMAC | See Section 4.4 |
| 0x00000004 | LogicalPortID | See Section 4.4 |
| 0x00000005 | EtherType | See Section 4.4 |
| 0x00000006 | VlanID | See Section 4.4 |
| 0x00000007 | VlanPriority | See Section 4.4 |
| 0x00000008 | NexthopIPv4Addr | See Section 4.4 |
| 0x00000009 | NexthopIPv6Addr | See Section 4.4 |
| 0x0000000A | HopSelector | See Section 4.4 |
| 0x0000000B | ExceptionID | See Section 4.4 |
| 0x0000000C | ValidateErrorID | See Section 4.4 |
| 0x0000000D | L3PortID | See Section 4.4 |
| 0x0000000E | RedirectIndex | See Section 4.4 |
| 0x0000000F | MediaEncapInfoIndex | See Section 4.4 |
+--------------+-------------------------+--------------------------+
Table 2
Metadata ID 0x80000000-0xFFFFFFFFF
Metadata IDs in this range are reserved for vendor private
extensions and are the responsibility of individuals.
10.3. Exception ID
The Exception ID namespace is 32 bits long. The following is the
guideline for managing the namespace.
Exception ID 0x00000000-0x7FFFFFFF
Wang, et al. Expires January 11, 2012 [Page 94]
Internet-Draft ForCES LFB Library July 2011
Exception IDs in this range are Specification Required [RFC5226].
An exception ID using this range MUST be documented in an RFC or
other permanent and readily available references.
Values assigned by this specification:
+--------------+---------------------------------+------------------+
| Value | Name | Definition |
+--------------+---------------------------------+------------------+
| 0x00000000 | AnyUnrecognizedExceptionCase | See Section 4.4 |
| 0x00000001 | BroadCastPacket | See Section 4.4 |
| 0x00000002 | BadTTL | See Section 4.4 |
| 0x00000003 | IPv4HeaderLengthMismatch | See Section 4.4 |
| 0x00000004 | LengthMismatch | See Section 4.4 |
| 0x00000005 | RouterAlertOptions | See Section 4.4 |
| 0x00000006 | RouteInTableNotFound | See Section 4.4 |
| 0x00000007 | NextHopInvalid | See Section 4.4 |
| 0x00000008 | FragRequired | See Section 4.4 |
| 0x00000009 | LocalDelivery | See Section 4.4 |
| 0x0000000A | GenerateICMP | See Section 4.4 |
| 0x0000000B | PrefixIndexInvalid | See Section 4.4 |
| 0x0000000C | IPv6HopLimitZero | See Section 4.4 |
| 0x0000000D | IPv6NextHeaderHBH | See Section 4.4 |
+--------------+---------------------------------+------------------+
Table 3
Exception ID 0x80000000-0xFFFFFFFFF
Exception IDs in this range are reserved for vendor private
extensions and are the responsibility of individuals.
10.4. Validate Error ID
The Validate Error ID namespace is 32 bits long. The following is
the guideline for managing the namespace.
Validate Error ID 0x00000000-0x7FFFFFFF
Validate Error IDs in this range are Specification Required
[RFC5226]. A Validate Error ID using this range MUST be
documented in an RFC or other permanent and readily available
references.
Values assigned by this specification:
Wang, et al. Expires January 11, 2012 [Page 95]
Internet-Draft ForCES LFB Library July 2011
+--------------+---------------------------------+------------------+
| Value | Name | Definition |
+--------------+---------------------------------+------------------+
| 0x00000000 | AnyUnrecognizedValidateErrorCase| See Section 4.4 |
| 0x00000001 | InvalidIPv4PacketSize | See Section 4.4 |
| 0x00000002 | NotIPv4Packet | See Section 4.4 |
| 0x00000003 | InvalidIPv4HeaderLengthSize | See Section 4.4 |
| 0x00000004 | InvalidIPv4Checksum | See Section 4.4 |
| 0x00000005 | InvalidIPv4SrcAddrCase1 | See Section 4.4 |
| 0x00000006 | InvalidIPv4SrcAddrCase2 | See Section 4.4 |
| 0x00000007 | InvalidIPv4SrcAddrCase3 | See Section 4.4 |
| 0x00000008 | InvalidIPv4SrcAddrCase4 | See Section 4.4 |
| 0x00000009 | InvalidIPv6PakcetSize | See Section 4.4 |
| 0x0000000A | NotIPv6Packet | See Section 4.4 |
| 0x0000000B | InvalidIPv6SrcAddrCase1 | See Section 4.4 |
| 0x0000000C | InvalidIPv6SrcAddrCase2 | See Section 4.4 |
| 0x0000000D | InvalidIPv6DstAddrCase1 | See Section 4.4 |
+--------------+---------------------------------+------------------+
Table 4
Validate Error ID 0x80000000-0xFFFFFFFFF
Validate Error IDs in this range are reserved for vendor private
extensions and are the responsibility of individuals.
Wang, et al. Expires January 11, 2012 [Page 96]
Internet-Draft ForCES LFB Library July 2011
11. Security Considerations
The ForCES framework document [RFC3746] provides a comprehensive
security analysis for the overall ForCES architecture. For example,
the ForCES protocol entities must be authenticated per the ForCES
requirements before they can access the information elements
described in this document via ForCES. Access to the information
contained in this document is accomplished via the ForCES
protocol[RFC5810], which is defined in separate documents, and thus
the security issues will be addressed there.
Wang, et al. Expires January 11, 2012 [Page 97]
Internet-Draft ForCES LFB Library July 2011
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.
Wang, et al. Expires January 11, 2012 [Page 98]
Internet-Draft ForCES LFB Library July 2011
Authors' Addresses
Weiming Wang
Zhejiang Gongshang University
18 Xuezheng Str., Xiasha University Town
Hangzhou, 310018
P.R.China
Phone: +86-571-28877721
Email: wmwang@zjgsu.edu.cn
Evangelos Haleplidis
University of Patras
Patras,
Greece
Email: ehalep@ece.upatras.gr
Kentaro Ogawa
NTT Corporation
Tokyo,
Japan
Email: ogawa.kentaro@lab.ntt.co.jp
Chuanhuang Li
Hangzhou BAUD Networks
408 Wen-San Road
Hangzhou, 310012
P.R.China
Phone: +86-571-28877751
Email: chuanhuang_li@zjgsu.edu.cn
Halpern Joel
Ericsson
P.O. Box 6049
Leesburg, 20178
VA
Phone: +1 703 371 3043
Email: joel.halpern@ericsson.com
Wang, et al. Expires January 11, 2012 [Page 99]
