Internet Engineering Task Force W. Wang Internet-Draft Zhejiang Gongshang University Intended status: Standards Track E. Haleplidis Expires: July 15, 2012 University of Patras K. Ogawa NTT Corporation C. Li Hangzhou H3C Tech. Co., Ltd. J. Halpern Ericsson January 12, 2012 ForCES Logical Function Block (LFB) Library draft-ietf-forces-lfb-lib-07 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 and ForCES protocol 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 July 15, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. Wang, et al. Expires July 15, 2012 [Page 1] Internet-Draft ForCES LFB Library January 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Scope of the Library . . . . . . . . . . . . . . . . . . 8 3.2. Overview of LFB Classes in the Library . . . . . . . . . 10 3.2.1. LFB Design Choices . . . . . . . . . . . . . . . . . 10 3.2.2. LFB Class Groupings . . . . . . . . . . . . . . . . . 10 3.2.3. Sample LFB Class Application . . . . . . . . . . . . 12 3.3. Document Structure . . . . . . . . . . . . . . . . . . . 13 4. Base Types . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.1. Atomic . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.2. Compound struct . . . . . . . . . . . . . . . . . . . 16 4.1.3. Compound array . . . . . . . . . . . . . . . . . . . 16 4.2. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 17 4.3. MetaData Types . . . . . . . . . . . . . . . . . . . . . 17 4.4. XML for Base Type Library . . . . . . . . . . . . . . . . 18 5. LFB Class Description . . . . . . . . . . . . . . . . . . . . 40 5.1. Ethernet Processing LFBs . . . . . . . . . . . . . . . . 40 5.1.1. EtherPHYCop . . . . . . . . . . . . . . . . . . . . . 41 5.1.2. EtherMACIn . . . . . . . . . . . . . . . . . . . . . 43 5.1.3. EtherClassifier . . . . . . . . . . . . . . . . . . . 44 5.1.4. EtherEncap . . . . . . . . . . . . . . . . . . . . . 47 5.1.5. EtherMACOut . . . . . . . . . . . . . . . . . . . . . 49 5.2. IP Packet Validation LFBs . . . . . . . . . . . . . . . . 50 5.2.1. IPv4Validator . . . . . . . . . . . . . . . . . . . . 50 5.2.2. IPv6Validator . . . . . . . . . . . . . . . . . . . . 52 5.3. IP Forwarding LFBs . . . . . . . . . . . . . . . . . . . 53 5.3.1. IPv4UcastLPM . . . . . . . . . . . . . . . . . . . . 54 5.3.2. IPv4NextHop . . . . . . . . . . . . . . . . . . . . . 56 5.3.3. IPv6UcastLPM . . . . . . . . . . . . . . . . . . . . 58 5.3.4. IPv6NextHop . . . . . . . . . . . . . . . . . . . . . 60 5.4. Redirect LFBs . . . . . . . . . . . . . . . . . . . . . . 62 5.4.1. RedirectIn . . . . . . . . . . . . . . . . . . . . . 62 Wang, et al. Expires July 15, 2012 [Page 2] Internet-Draft ForCES LFB Library January 2012 5.4.2. RedirectOut . . . . . . . . . . . . . . . . . . . . . 63 5.5. General Purpose LFBs . . . . . . . . . . . . . . . . . . 64 5.5.1. BasicMetadataDispatch . . . . . . . . . . . . . . . . 64 5.5.2. GenericScheduler . . . . . . . . . . . . . . . . . . 65 6. XML for LFB Library . . . . . . . . . . . . . . . . . . . . . 68 7. LFB Class Use Cases . . . . . . . . . . . . . . . . . . . . . 90 7.1. IPv4 Forwarding . . . . . . . . . . . . . . . . . . . . . 90 7.2. ARP processing . . . . . . . . . . . . . . . . . . . . . 91 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 94 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 95 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 96 10.1. LFB Class Names and LFB Class Identifiers . . . . . . . . 96 10.2. Metadata ID . . . . . . . . . . . . . . . . . . . . . . . 98 10.3. Exception ID . . . . . . . . . . . . . . . . . . . . . . 98 10.4. Validate Error ID . . . . . . . . . . . . . . . . . . . . 99 11. Security Considerations . . . . . . . . . . . . . . . . . . . 101 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 102 12.1. Normative References . . . . . . . . . . . . . . . . . . 102 12.2. Informative References . . . . . . . . . . . . . . . . . 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 103 Wang, et al. Expires July 15, 2012 [Page 3] Internet-Draft ForCES LFB Library January 2012 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 July 15, 2012 [Page 4] Internet-Draft ForCES LFB Library January 2012 2. Definitions This document follows the terminology defined by the ForCES protocol in [RFC5810] and by the ForCES FE model in [RFC5812]. 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 Model - The FE model is designed to model the logical processing functions of an FE, which is defined by the ForCES FE model document [RFC5812]. The FE model proposed in this document includes three components; the LFB modeling of individual Logical Functional Block (LFB model), the logical interconnection between LFBs (LFB topology), and the FE-level attributes, including FE capabilities. The FE model provides the basis to define the information elements exchanged between the CE and the FE in the ForCES protocol [RFC5810]. 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). Wang, et al. Expires July 15, 2012 [Page 5] Internet-Draft ForCES LFB Library January 2012 LFB Class and LFB Instance - LFBs are categorized by LFB Classes. An LFB Instance represents an LFB Class (or Type) existence. There may be multiple instances of the same LFB Class (or Type) in an FE. An LFB Class is represented by an LFB Class ID, and an LFB Instance is represented by an LFB Instance ID. As a result, an LFB Class ID associated with an LFB Instance ID uniquely specifies an LFB existence. LFB Metadata - Metadata is used to communicate per-packet state from one LFB to another, but is not sent across the network. The FE model defines how such metadata is identified, produced and consumed by the LFBs. It defines the functionality but not how metadata is encoded within an implementation. LFB Component - Operational parameters of the LFBs that must be visible to the CEs are conceptualized in the FE model as the LFB components. The LFB components include, for example, flags, single parameter arguments, complex arguments, and tables that the CE can read and/or write via the ForCES protocol (see below). LFB Topology - Representation of how the LFB instances are logically interconnected and placed along the datapath within one FE. Sometimes it is also called intra-FE topology, to be distinguished from inter-FE topology. Data Path - A conceptual path taken by packets within the forwarding plane inside an FE. Note that more than one data path can exist within an FE. 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. LFB Port - A port refers to an LFB input port or output port. See Section 3.2 of [RFC5812] for more detailed definitions. Physical Port - A port refers to a physical media input port or output port of an FE. A physical port is usually assigned with a physical port ID, abbreviated with a PHYPortID. This document mainly deals with physical ports with Ethernet media. Wang, et al. Expires July 15, 2012 [Page 6] Internet-Draft ForCES LFB Library January 2012 Logical Port - A conceptually virtual port at data link layer (L2) or network layer (L3). A logical port is usually assigned with a logical port ID, abbreviated with a LogicalPortID. The logical ports can be further categorized with a L2 logical port or a L3 logical port. An L2 logical port can be assigned with a L2 logical port ID, abbreviated with a L2PortID. An L3 logical port can be assigned with a L3 logical port ID, abbreviated with a L3PortID. MAC layer VLAN ports belongs to L2 logical ports as well as logical ports. LFB Class Library - The LFB class library is a set of LFB classes that has been identified as the most common functions found in most FEs and hence should be defined first by the ForCES Working Group. The LFB Class Library is defined by this document. Wang, et al. Expires July 15, 2012 [Page 7] Internet-Draft ForCES LFB Library January 2012 3. Introduction [RFC5810] 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. [RFC5810] specifies the ForCES protocol. [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. [RFC5812] 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: * Encapsulating and decapsulating the IP datagrams with the connected network framing (e.g., an Ethernet header and checksum), * 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, * Translating the IP destination address into an appropriate network-level address for the connected network (e.g., an Ethernet hardware address), if needed, and Wang, et al. Expires July 15, 2012 [Page 8] Internet-Draft ForCES LFB Library January 2012 * Responding to network flow control and error indications, if any. (2) Conform to specific Internet protocols including the Internet Protocol (IPv4 and/or IPv6), Internet Control Message Protocol (ICMP), and others as necessary. (3) Receive and forward Internet datagrams. Important issues in this process are buffer management, congestion control, and fairness. * Recognizes error conditions and generates ICMP error and information messages as required. * Drops datagrams whose time-to-live fields have reached zero. * Fragments datagrams when necessary to fit into the MTU of the next network. (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 or static route setup 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 ways 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 Wang, et al. Expires July 15, 2012 [Page 9] Internet-Draft ForCES LFB Library January 2012 deal with Ethernet physical media. Other future documents may deal with other types of media. This document will also interchangeably refer to a port to be an abstraction that constitutes a PHY and a MAC as described by the LFBs like EtherPHYCop, EtherMACIn, and EtherMACOut. IP packets emanating from port LFBs are then processed by a validation LFB before being further forwarded to the next LFB. After the validation process the packet is passed to an LFB where IP forwarding decision is made. In the IP Forwarding LFBs, a Longest Prefix Match LFB is used to look up the destination information in a packet and select a next hop index for sending the packet onward. A next hop LFB uses the next hop index metadata to apply the proper headers to the IP packets, and direct them to the proper egress. Note that in the process of IP packets processing, in this document, we are adhering to the weak-host model [RFC1122] since that is the most usable model for a packet processing Network Element. 3.2. Overview of LFB Classes in the Library It is critical to classify functional requirements into various classes of LFBs and construct a typical but also flexible enough base LFB library for various IP forwarding equipments. 3.2.1. LFB Design Choices A few design principles were factored into choosing how the base LFBs looked like. These are: o if a function can be designed by either one LFB or two or more LFBs with the same cost, the choice is to go with two or more LFBs so as to provide more flexibility for implementers. o when flexibility is not required, an LFB should take advantage of its independence as much as possible and have minimal coupling with other LFBs. The coupling may be from LFB attributes definitions as well as physical implementations. o unless there is a clear difference in functionality, similar packet processing should not be represented as two or more different LFBs. Or else, it may add extra burden on implementation to achieve interoperability. 3.2.2. LFB Class Groupings The document defines groups of LFBs for typical router function requirements: Wang, et al. Expires July 15, 2012 [Page 10] Internet-Draft ForCES LFB Library January 2012 (1) A group of Ethernet processing LFBs are defined to abstract the packet processing for Ethernet as the port media type. As the most popular media type with rich processing features, Ethernet media processing LFBs was a natural choice. Definitions for processing of other port media types like POS or ATM may be incorporated in the library in future version of the document or in a future separate document. The following LFBs are defined for Ethernet processing: * EtherPHYCop (Section 5.1.1) * EtherMACIn (Section 5.1.2) * EtherClassifier (Section 5.1.3) * EtherEncap (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.3) * 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) Wang, et al. Expires July 15, 2012 [Page 11] Internet-Draft ForCES LFB Library January 2012 (5) A group of LFBs are defined for abstracting some general purpose packet processing. These processing processes are usually general to many processing locations in an FE LFB topology. The following LFBs are defined for redirect processing: * BasicMetadataDispatch (Section 5.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 details. Wang, et al. Expires July 15, 2012 [Page 12] Internet-Draft ForCES LFB Library January 2012 +-----+ +------+ | | | | | |<---------------|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 metadata types are presented in advance for definitions of various LFB classes. Section 4 (Base Types section) provides a description on the base types used by this LFB library. To enable extensive use of these base types by other LFB class definitions, the base type definitions are provided as a separate library. Wang, et al. Expires July 15, 2012 [Page 13] Internet-Draft ForCES LFB Library January 2012 Within every group of LFB classes, a set of LFBs are defined for individual function purposes. Section 5 (LFB Class Descriptions section) provides 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) provides 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 July 15, 2012 [Page 14] Internet-Draft ForCES LFB Library January 2012 4. Base Types The 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: 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 VlanIDType The type of VLAN ID VlanPriorityType The type of VLAN priority SchdDisciplineType Scheduling discipline type Wang, et al. Expires July 15, 2012 [Page 15] Internet-Draft ForCES LFB Library January 2012 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 QueueStatsType 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 QueueStatsTableType Type for Queue depth table Wang, et al. Expires July 15, 2012 [Page 16] Internet-Draft ForCES LFB Library January 2012 4.2. Frame Types According to FE model [RFC5812], frame types are used in LFB definitions to define packet frame types both an LFB expects at its input port and the LFB emits at its output port. The 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 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 July 15, 2012 [Page 17] Internet-Draft ForCES LFB Library January 2012 Metadata Name Metadata ID Brief Description ------------ ---------- ------------- PHYPortID 1 The ingress physical port that the packet arrived on 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 The packet's Ethernet type 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 A search key 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 A search key 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 EthernetAll All kinds of Ethernet frame EthernetII An Ethernet II frame ARP An arp packet Wang, et al. Expires July 15, 2012 [Page 18] Internet-Draft ForCES LFB Library January 2012 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 IPv4Addr IPv4 address byte[4] IPv6Addr IPv6 address byte[16] IEEEMAC IEEE MAC address. byte[6] LANSpeedType Network speed values Wang, et al. Expires July 15, 2012 [Page 19] Internet-Draft ForCES LFB Library January 2012 uint32 LAN_SPEED_10M 10M Ethernet LAN_SPEED_100M 100M Ethernet LAN_SPEED_1G 1000M Ethernet LAN_SPEED_10G 10G Ethernet LAN_SPEED_AUTO LAN speed auto DuplexType Duplex types uint32 Auto Auto negotitation. Half-duplex port negotitation half duplex Full-duplex port negotitation full duplex Wang, et al. Expires July 15, 2012 [Page 20] Internet-Draft ForCES LFB Library January 2012 PortStatusValues The possible values of port status, used for both administrative and operative status. uchar Disabled the port is operatively disabled. UP the port is up. Down The port is down. MACInStatsType Statistics type in EtherMACIn LFB. NumPacketsReceived The number of packets received. uint64 NumPacketsDropped The number of packets dropped. uint64 MACOutStatsType Statistics type in EtherMACOut LFB. NumPacketsTransmitted The number of packets transmitted. uint64 NumPacketsDropped Wang, et al. Expires July 15, 2012 [Page 21] Internet-Draft ForCES LFB Library January 2012 The number of packets dropped. uint64 EtherDispatchEntryType Entry type for Ethernet dispatch table in EtherClassifier LFB. LogicalPortID Logical port ID. uint32 EtherType The EtherType value in the Ether head. uint32 LFBOutputSelectIndex 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. uint32 EtherDispatchTableType Type for Ethernet dispatch table.This table is used in EtherClassifier LFB. Every Ethernet packet can be dispatched to the LFB output group ports according to the logical port ID. EtherDispatchEntryType Wang, et al. Expires July 15, 2012 [Page 22] Internet-Draft ForCES LFB Library January 2012 VlanIDType The type of VLAN ID uint16 VlanPriorityType The type of VLAN priority. uchar VlanInputTableEntryType Entry type for VLAN input table in EtherClassifier LFB. IncomingPortID The incoming port ID. uint32 VlanID Vlan ID. VlanIDType LogicalPortID logical port ID. uint32 VlanInputTableType Type for VLAN input table.This table is used in EtherClassifier LFB. Every Ethernet packet can get a new LogicalPortID according to the IncomingPortID and VlanID. Wang, et al. Expires July 15, 2012 [Page 23] Internet-Draft ForCES LFB Library January 2012 VlanInputTableEntryType EtherClassifyStatsType Entry type for statistics table in EtherClassifier LFB. EtherType The EtherType value uint32 PacketsNum Packets number uint64 EtherClassifyStatsTableType Type for Ethernet classifier statistics information table in EtherClassifier LFB. EtherClassifyStatsType IPv4ValidatorStatsType Statistics type in IPv4validator LFB. badHeaderPkts Number of bad header packets. uint64 badTotalLengthPkts Number of bad total length packets. uint64 badTTLPkts Number of bad TTL packets. uint64 Wang, et al. Expires July 15, 2012 [Page 24] Internet-Draft ForCES LFB Library January 2012 badChecksumPkts Number of bad checksum packets. uint64 IPv6ValidatorStatsType Statistics type in IPv6validator LFB. badHeaderPkts Number of bad header packets. uint64 badTotalLengthPkts Number of bad total length packets. uint64 badHopLimitPkts Number of bad Hop limit packets. uint64 IPv4PrefixInfoType Entry type for IPv4 prefix table. IPv4Address An IPv4 Address IPv4Addr Prefixlen The prefix length uchar Wang, et al. Expires July 15, 2012 [Page 25] Internet-Draft ForCES LFB Library January 2012 HopSelector HopSelector is the nexthop ID which points to the nexthop table uint32 ECMPFlag An ECMP Flag for this route boolean False This route does not have multiple nexthops. True This route has multiple nexthops. DefaultRouteFlag A default route flag. boolean False This is not a default route. True This route is a default route. IPv4PrefixTableType Type for IPv4 prefix table. This table is currently Wang, et al. Expires July 15, 2012 [Page 26] Internet-Draft ForCES LFB Library January 2012 used in IPv4UcastLPM LFB. The LFB uses the destination IPv4 address of every input packet as search key to look up this table in order extract a next hop selector. IPv4PrefixInfoType IPv4UcastLPMStatsType Statistics type in IPv4Unicast LFB. InRcvdPkts The total number of input packets received. uint64 FwdPkts IPv4 packets forwarded by this LFB uint64 NoRoutePkts The number of IP datagrams discarded because no route could be found. uint64 IPv6PrefixInfoType Entry type for IPv6 prefix table. IPv6Address An IPv6 Address IPv6Addr Prefixlen The prefix length uchar Wang, et al. Expires July 15, 2012 [Page 27] Internet-Draft ForCES LFB Library January 2012 HopSelector HopSelector is the nexthop ID which points to the nexthop table uint32 ECMPFlag An ECMP Flag for this route boolean False This route does not have multiple nexthops. True This route has multiple nexthops. DefaultRouteFlag A Default Route Flag. boolean False This is not a default route. True This route is a default route. Wang, et al. Expires July 15, 2012 [Page 28] Internet-Draft ForCES LFB Library January 2012 IPv6PrefixTableType Type for IPv6 prefix table.This table is currently used in IPv6UcastLPM LFB. The LFB uses the destination IPv6 address of every input packet as search key to look up this table in order extract a next hop selector. IPv6PrefixInfoType IPv6UcastLPMStatsType Statistics type in IPv6Unicast LFB. InRcvdPkts The total number of input packets received uint64 FwdPkts IPv6 packets forwarded by this LFB uint64 NoRoutePkts The number of IP datagrams discarded because no route could be found. uint64 IPv4NextHopInfoType Entry type for IPv4 next hop table. L3PortID The ID of the Logical/physical Output Port that we pass onto the downstream LFB instance. This ID indicates what port to the neighbor is as defined by L3. uint32 MTU Maximum Transmission Unit for out going port. It is for desciding whether the packet need Wang, et al. Expires July 15, 2012 [Page 29] Internet-Draft ForCES LFB Library January 2012 fragmentation uint32 NextHopIPAddr Next Hop IPv4 Address IPv4Addr MediaEncapInfoIndex The index we pass onto the downstream LFB instance. This index is used to lookup a table (typically media encapsulatation related) further downstream. uint32 LFBOutputSelectIndex 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. uint32 IPv4NextHopTableType Type for IPv4 next hop table. This table is used in IPv4NextHop LFB. The LFB uses metadata "HopSelector" received to match the array index to get the next hop information. IPv4NextHopInfoType IPv6NextHopInfoType Entry type for IPv6 next hop table. Wang, et al. Expires July 15, 2012 [Page 30] Internet-Draft ForCES LFB Library January 2012 L3PortID The ID of the Logical/physical Output Port that we pass onto the downstream LFB instance. This ID indicates what port to the neighbor is as defined by L3. uint32 MTU Maximum Transmission Unit for out going port. It is for desciding whether the packet need fragmentation. uint32 NextHopIPAddr Next Hop IPv6 Address IPv6Addr MediaEncapInfoIndex The index we pass onto the downstream LFB instance. This index is used to lookup a table (typically media encapsulatation related) further downstream. uint32 LFBOutputSelectIndex 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 IPv6NextHop LFB. uint32 IPv6NextHopTableType Wang, et al. Expires July 15, 2012 [Page 31] Internet-Draft ForCES LFB Library January 2012 Type for IPv6 next hop table. This table is used in IPv6NextHop LFB. The LFB uses metadata "HopSelector" received to match the array index to get the next hop information. IPv6NextHopInfoType EncapTableEntryType Entry type for Ethernet encapsulation table in EtherEncap LFB. DstMac Ethernet Mac of the Neighbor IEEEMAC SrcMac Source MAC used in encapsulation IEEEMAC VlanID VLAN ID. VlanIDType L2PortID Output logical L2 port ID. uint32 EncapTableType Type for Ethernet encapsulation table. This table is used in EtherEncap LFB. The LFB uses the metadata "MediaEncapInfoIndex " received to get the encapsulation information. EncapTableEntryType MetadataDispatchType Entry type for Metadata dispatch table in Wang, et al. Expires July 15, 2012 [Page 32] Internet-Draft ForCES LFB Library January 2012 BasicMetadataDispatch LFB. MetadataValue metadata value. uint32 OutputIndex group output port index. uint32 MetadataDispatchTableType Type for Metadata dispatch table. This table is used in BasicMetadataDispatch LFB. The LFB uses MetadataValue to get the LFB group output port index. MetadataDispatchType MetadataValue SchdDisciplineType Scheduling discipline type. uint32 RR Round Robin scheduler. QueueStatsType Entry type for queue statistics table in GenericScheduler LFB. QueueID Queue ID uint32 Wang, et al. Expires July 15, 2012 [Page 33] Internet-Draft ForCES LFB Library January 2012 QueueDepthInPackets the Queue Depth when the depth units are packets. uint32 QueueDepthInBytes the Queue Depth when the depth units are bytes. uint32 QueueStatsTableType Type for Queue statistics table in GenericScheduler LFB. QueueDepthType PHYPortID The physical port ID that a packet has entered. 1 uint32 SrcMAC Source MAC address of the packet. 2 IEEEMAC DstMAC Destination MAC address of the packet. 3 IEEEMAC LogicalPortID ID of a logical port for the packet. 4 Wang, et al. Expires July 15, 2012 [Page 34] Internet-Draft ForCES LFB Library January 2012 uint32 EtherType Indicating the Ethernet type of the Ethernet packet. 5 uint32 VlanID The Vlan ID of the Ethernet packet. 6 VlanIDType VlanPriority The priority of the Ethernet packet. 7 VlanPriorityType NexthopIPv4Addr Nexthop IPv4 address the packet is sent to. 8 IPv4Addr NexthopIPv6Addr Nexthop IPv6 address the packet is sent to. 9 IPv6Addr HopSelector A search key the packet can use to look up a nexthop table for next hop information of the packet. 10 uint32 ExceptionID Indicating exception type of the packet which is exceptional for some processing. 11 Wang, et al. Expires July 15, 2012 [Page 35] Internet-Draft ForCES LFB Library January 2012 uint32 AnyUnrecognizedExceptionCase any unrecognized exception case. ClassifyNoMatching There is no matching when classifying the packet in EtherClassifier LFB. MediaEncapInfoIndexInvalid The MediaEncapInfoIndex value of the packet is invalid and can not be allocated in the EncapTable. EncapTableLookupFailed The packet failed lookup of the EncapTable table even though the MediaEncapInfoIndex is valid. BadTTL Packet with expired TTL. IPv4HeaderLengthMismatch Packet with header length more than 5 words. RouterAlertOptions Packet IP head include Router Alert options. IPv6HopLimitZero Packet with Hop Limit zero IPv6NextHeaderHBH Packet with next header set to Hop-by-Hop SrcAddressExecption Wang, et al. Expires July 15, 2012 [Page 36] Internet-Draft ForCES LFB Library January 2012 Packet with exceptional source address. DstAddressExecption Packet with exceptional destination address LPMLookupFailed The packet failed the LPM lookup of the prefix table. HopSelectorInvalid The HopSelector for the packet is invalid. NextHopLookupFailed The packet failed lookup of the NextHop table even though the HopSelector is valid. FragRequired The MTU for outgoing interface is less than the packet size. MetadataNoMatching There is no matching when looking up the metadata dispatch table. ValidateErrorID Indicating error type of the packet failed some validation process. 12 uint32 AnyUnrecognizedValidateErrorCase Any unrecognized validate error case. Wang, et al. Expires July 15, 2012 [Page 37] Internet-Draft ForCES LFB Library January 2012 InvalidIPv4PacketSize Packet size reported is less than 20 bytes. NotIPv4Packet Packet is not IP version 4. InvalidIPv4HeaderLengthSize Packet with header length less than 5 words. InvalidIPv4LengthFieldSize Packet with total length field less than 20 bytes. InvalidIPv4Checksum Packet with invalid checksum. InvalidIPv4SrcAddr Packet with invalid source address. InvalidIPv4DstAddr Packet with source address 0. InvalidIPv6PacketSize Packet size reported is less than 40 bytes. NotIPv6Packet Packet is not IP version 6. InvalidIPv6SrcAddr Packet with invalid source address. Wang, et al. Expires July 15, 2012 [Page 38] Internet-Draft ForCES LFB Library January 2012 InvalidIPv6DstAddr Packet with invalid destination address. L3PortID ID of L3 port. See the definition in IPv4NextHopInfoType. 13 uint32 RedirectIndex metadata CE sends to RedirectIn LFB for the associated packet to select output port in the LFB group output "PktsOut". 14 uint32 MediaEncapInfoIndex A search key the packet uses to look up a media encapsulation table to select its encapsulation media as well as followed encapsulation LFB. 15 uint32 Wang, et al. Expires July 15, 2012 [Page 39] Internet-Draft ForCES LFB Library January 2012 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 [RFC5810] has already defined an 'FE Protocol LFB' which is a logical entity in each FE to control the ForCES protocol. [RFC5812] 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 on 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. In this section, the terms "upstream LFB" and "downstream LFB" are used. These are used relative to an LFB to an LFB that is being described. An "upstream LFB" is one whose output ports are connected to input ports of the LFB under consideration such that output (typically packets with metadata) can be sent from the "upstream LFB" to the LFB under consideration. Similarly, a "downstream LFB" whose input ports are connected to output ports of the LFB under consideration such that the LFB under consideration can send information to the "downstream LFB". Note that in some rare topologies, an LFB may be both upstream and downstream relative to another LFB. Also note that, as a default provision of [RFC5812], 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 downstream LFBs of a physical layer LFB, even there is no specific metadata expected, metadata like PHYPortID produced by the physical layer LFB will always pass through all downstream LFBs regardless of whether the metadata has been expected by the LFBs or not. 5.1. Ethernet Processing LFBs As the most popular physical and data link layer protocols, Ethernet is widely deployed. It becomes a basic requirement for a router to be able to process various Ethernet data packets. Wang, et al. Expires July 15, 2012 [Page 40] Internet-Draft ForCES LFB Library January 2012 Note that there exist different versions of Ethernet formats, 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 starting point, 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 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' metadata, 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 as EtherMacOut LFBs 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 administratively 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 Wang, et al. Expires July 15, 2012 [Page 41] Internet-Draft ForCES LFB Library January 2012 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' metadata at the LFB output and to associate it to every Ethernet packet this LFB receives. The metadata 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 specifies whether the port link is operationally up. 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 Several events are generated. 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 Wang, et al. Expires July 15, 2012 [Page 42] Internet-Draft ForCES LFB Library January 2012 negotiated duplex mode. 5.1.2. EtherMACIn EtherMACIn LFB abstracts an Ethernet port at MAC data link layer. This LFB describes Ethernet processing functions like MAC address locality check, deciding if the Ethernet packets should be bridged, providing 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 "EtherPktsIn", which are usually output from some Ethernet physical layer LFB, like an EtherPHYCop LFB, alongside with a metadata indicating the physical port ID that the packet arrived on. The LFB is defined with two separate singleton outputs. All Output packets are emitted in the original ethernet format received at the physical port, unchanged, and cover all types of ethernet types. The first singleton output is known as "NormalPathOut". It usually outputs Ethernet packets to some LFB like an EtherClassifier LFB for 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 participates in Ethernet flow control in cooperation with EtherMACOut LFB. This document does not go into the details of how this is implemented; the reader may refer to some relevant Wang, et al. Expires July 15, 2012 [Page 43] Internet-Draft ForCES LFB Library January 2012 references. This document also does not describe how the buffers which induce the flow control messages behave - it is assumed that such artifacts exist and describing them is out of scope in this document. 5.1.2.2. Components The AdminStatus component is defined for the 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 flow control on sending packets. The default value for is 'false'. The RxFlowControl component defines whether the LFB is performing flow control 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 then classify them. Wang, et al. Expires July 15, 2012 [Page 44] Internet-Draft ForCES LFB Library January 2012 5.1.3.1. Data Handling This LFB describes the process of decapsulating Ethernet packets and classifying them into various network layer data packets according to information included in the Ethernet packets headers. The LFB is expected to receive all types of Ethernet packets, 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 such a case. Usually, all expected Ethernet Packets will be associated with a PHYPortID metadata, indicating the physical port the packet comes from. In some cases, for instance, like in a MACinMAC case, a LogicalPortID metadata 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. Two output LFB ports are defined. The first output is a group output port known as "ClassifyOut". Types of network layer protocol packets are output to instances of the port group. Because there may be various types of protocol packets at the output ports, the produced output frame is defined as arbitrary for the purpose of wide extensibility in the future. Metadata to be carried along with the packet data is produced at this LFB for consumption by downstream LFBs. The metadata passed downstream includes PHYPortID, as well as information on Ethernet type, source MAC address, destination MAC address and the logical port ID. .If the original packet is a VLAN packet and contains a VLAN ID and a VLAN priority value, then the VLAN ID and the VLAN priority value are also carried downstream as metadata. As a result, the VLAN ID and priority metadata are defined with the availability of "conditional". 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 There is no matching when classifying the packet. Usually the exception out port may point to no where, indicating Wang, et al. Expires July 15, 2012 [Page 45] Internet-Draft ForCES LFB Library January 2012 packets with exceptions are dropped, while in some cases, the output may be pointed to the path to the CE for further processing, depending on individual implementations. 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 struct 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. 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 logical port ID if a logical port ID is associated with the packet, or a physical port ID if no logical port ID associated. The VLAN ID is exactly the VLAN ID in the packet if it is a VLAN packet, or 0 if it is not. 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 a 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 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. Wang, et al. Expires July 15, 2012 [Page 46] Internet-Draft ForCES LFB Library January 2012 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 of encapsulating Ethernet headers onto received packets. The encapsulation is based on passed metadata. The LFB is expected to receive IPv4 and IPv6 packets, via a singleton input port 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 a search key to lookup the Encapsulation Table. An input packet may also optionally receive a VLAN priority metadata, indicating that the packet is originally with a priority value. The priority value will be loaded back to the packet when encapsulating. The optional VLAN priority metadata is defined with a default value 0. Two singleton output LFB ports are defined. 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 additional ExceptionID metadata. Currently defined exception types only include the following case: o The MediaEncapInfoIndex value of the packet is invalid and can not be allocated in the EncapTable. Wang, et al. Expires July 15, 2012 [Page 47] Internet-Draft ForCES LFB Library January 2012 o The packet failed lookup of the EncapTable table even though the MediaEncapInfoIndex is valid. 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 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 being 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. 5.1.4.4. Events This LFB does not have any events specified. Wang, et al. Expires July 15, 2012 [Page 48] Internet-Draft ForCES LFB Library January 2012 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 metadata indicating the physical port ID that the packet will go through. The LFB is defined with a singleton output. All Output packets are in Ethernet format, possibly with various Ethernet types, alongside with a metadata 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 participates in Ethernet flow control in cooperation with EtherMACIn LFB. This document does not go into the details of how this is implemented; the reader may refer to some relevant references. This document also does not describe how the buffers which induce the flow control messages behave - it is assumed that such artifacts exist and describing them is out of scope in this document. 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 [RFC5812] will be used by CE to declare the target component this alias refers, which include the target LFB class and instance IDs as well as the path to the target component. The MTU component defines the maximum transmission unit. Wang, et al. Expires July 15, 2012 [Page 49] Internet-Draft ForCES LFB Library January 2012 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 [RFC5812]. 5.2.1.1. Data Handling This LFB performs IPv4 validation according to [RFC5812]. The IPv4 packet will be output to the corresponding LFB port the indication whether the packet is unicast, multicast or whether an exception has occurred or the validation failed. This LFB always expects, as input, packets which have been indicated as IPv4 packets by an upstream LFB, like an EtherClassifier LFB. There is no specific metadata expected by the input of the LFB. Four output LFB ports are defined. All validated IPv4 unicast packets will be output at the singleton port known as "IPv4UnicastOut". All validated IPv4 multicast packets Wang, et al. Expires July 15, 2012 [Page 50] Internet-Draft ForCES LFB Library January 2012 will be output at the singleton port known as "IPv4MulticastOut" port. 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 has caused the exception. An exception case is the case when a packet needs further processing before being normally forwarded. Currently defined exception types include: o Packet with expired TTL o Packet with header length more than 5 words o Packet IP head including Router Alert options o Packet with exceptional source address o Packet with exceptional destination address Note that although TTL is checked in this LFB for validity, operations like TTL decrement are made by the downstream forwarding LFB. The final singleton port known as "FailOut" is defined for all packets which have errors and failed the validation process. An error case is the case when a packet is unable to be further processed nor forwarded except being dropped. An error ID is associated a packet to indicate the failure reason. Currently defined failure reasons include: o Packet with size reported less than 20 bytes o Packet with version is not IPv4 o Packet with header length less than 5 words o Packet with total length field less than 20 bytes o Packet with invalid checksum o Packet with invalid source address o Packet with invalid destination address Wang, et al. Expires July 15, 2012 [Page 51] Internet-Draft ForCES LFB Library January 2012 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 [RFC2460]. 5.2.2.1. Data Handling This LFB performs IPv6 validation according to [RFC2460]. 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 LFB has also defined four output ports to emit packets with various validation results. All validated IPv6 unicast packets will be output at the singleton port known as "IPv6UnicastOut". All validated IPv6 multicast packets will be output at the singleton port known as "IPv6MulticastOut" port. There is no metadata produced at this LFB. A singleton port known as "ExceptionOut" is defined to output packets which have been validated as exception packets. An exception case is the case when a packet needs further processing before being normally forwarded. An exception ID metadata is produced to indicate what caused the exception. Currently defined exception types include: Wang, et al. Expires July 15, 2012 [Page 52] Internet-Draft ForCES LFB Library January 2012 o Packet with hop limit to zero o Packet with next header set to Hop-by-Hop o Packet with exceptional source address o Packet with exceptional destination address The final singleton port known as "FailOut" is defined for all packets which have errors and failed the validation process. An error case is the case when a packet is unable to be further processed nor forwarded except being dropped. A validate error ID is associated to every failed packet to indicate the reason. Currently defined reasons include: o Packet with size reported less than 40 bytes o Packet with not IPv6 version o Packet with invalid source address o Packet with invalid destination address 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 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 Wang, et al. Expires July 15, 2012 [Page 53] Internet-Draft ForCES LFB Library January 2012 document restricts its LFB definition scope only to IP unicast forwarding. IP multicast may be defined in future documents. A typical IP unicast forwarding job is usually realized by looking up the forwarding information table to find next hop information, and then based on the next hop information, forwarding packets to specific physical 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 as a search key 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 the FE to translate attributes defined by this document into attributes related to the implementation. Based on the IP forwarding abstraction, two kind of typical IP unicast forwarding LFBs are defined, Unicast LPM lookup LFB and next hop application LFB. They are further distinguished by IPv4 and IPv6 protocols. 5.3.1. IPv4UcastLPM The IPv4UcastLPM LFB abstracts the IPv4 unicast Longest Prefix Match (LPM) process. This LFB also provides facilities to support users to implement equal-cost multi-path routing (ECMP) or reverse path forwarding (RPF). However, this LFB itself does not provide ECMP or RPF. To fully implement ECMP or RPF, additional specific LFBs, like a specific ECMP LFB or an RPF LFB, will have to be defined. This work may be done in the future version of the document. 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 search key to look up the IPv4 prefix table and generate a hop selector as the matching result. The hop selector is passed as packet metadata to downstream LFBs, and will usually be used there as a search index to find more next hop information. Three singleton output LFB ports are defined. Wang, et al. Expires July 15, 2012 [Page 54] Internet-Draft ForCES LFB Library January 2012 The first singleton output known as "NormalOut" outputs IPv4 unicast packets that succeed the LPM lookup and (got a hop selector). The hop selector is associated with the packet as a metadata. Downstream from 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 as well as loose RPF. When this flag is set true, the table entry is identified a default route which also implies that the route is forbidden for RPF. 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, along with an ExceptionID metadata to indicate what caused the exception. Currently defined exception types include: o The packet failed the LPM lookup of the prefix table. The upstream 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 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 address, 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 search key to look up this table in order extract a next hop selector. The Wang, et al. Expires July 15, 2012 [Page 55] Internet-Draft ForCES LFB Library January 2012 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 identifier (HopSelector), and uses the identifier as a table index to look up a next hop table to find an appropriate LFB output port. 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 a table index to lookup the NextHop table. The data processing involves the forwarding TTL decrement and IP checksum recalculation. Two output LFB ports are defined. 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: Wang, et al. Expires July 15, 2012 [Page 56] Internet-Draft ForCES LFB Library January 2012 o The HopSelector for the packet is invalid. o The packet failed lookup of the NextHop table even though the HopSelector is valid. o The MTU for outgoing interface is less than the packet size. Downstream LFB instances could be either a BasicMetadataDispatch type (Section 5.5.1), used to fanout to different LFB instances or a media encapsulation related type, such as an EtherEncap type or a RedirectOut type(Section 5.4.2). For example, if there are Ethernet and other tunnel Encapsulation, then a BasicMetadataDispatch LFB can use the L3PortID metadata (Section 5.3.2.2) 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. The HopSelector received is used to match the array index of IPv4NextHopTable to find out a row of the table as the next hop information result. 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 downstream LFB instance. This ID indicates what port to the neighbor is as defined by L3. Usually this ID is used for the NextHop LFB to distinguish packets that need different L2 encapsulating. For instance, some packets may require general Ethernet encapsulation while others may require various types of tunnel encapsulations. In such case, different L3PortIDs are assigned to the packets and are as metadata passed to downstream LFB. A BasicMetadataDispatch LFB(Section 5.5.1) may have to be applied as the downstream LFB so as to dispatch packets to different encapsulation LFB insatnces according to the L3PortIDs. 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 downstream encapsulation LFB instance and that is used there as a search key to lookup a table (typically media encapsulation related) for further encapsulation information. Note that an encapsulation LFB instance may not directly follow the NextHop LFB, but the index is passed as a metadata associated, as such an encapsulation LFB instance even further downstream to the NextHop LFB can still use the index. In some cases, depending on implementation, the CE may set the MediaEncapInfoIndex passed downstream to a value that will Wang, et al. Expires July 15, 2012 [Page 57] Internet-Draft ForCES LFB Library January 2012 fail lookup when it gets to a target encapsulation LFB; such a lookup failure at that point is an indication that further resolution is needed. For an example of this approach refer to Section 7.2 which talks about ARP and mentions this approach. o LFBOutputSelectIndex, the LFB Group output port index to select downstream LFB port. It is a 1-to-1 mapping with FEObject LFB's table LFBTopology (See [RFC5812]) component FromPortIndex corresponding to the port group mapping FromLFBID as IPv4NextHop LFB instance. 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 look up. It always expects as input IPv6 unicast packets from one singleton input known as "PktsIn". The destination IPv6 address of an incoming packet is used as search key to look up the IPv6 prefix table and generate a hop selector. This hop selector result is associated to the packet as a metadata and sent to downstream LFBs, and will usually be used in downstream LFBs as a search key to find more next hop information. Three singleton output LFB ports are defined. The first singleton output known as "NormalOut" outputs IPv6 unicast packets that succeed the LPM lookup (and got a hop selector). The hop selector is associated with the packet as a metadata. Downstream Wang, et al. Expires July 15, 2012 [Page 58] Internet-Draft ForCES LFB Library January 2012 from 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. 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 as well as loose RPF. When this flag is set true, the table entry is identified a default route which also implies that the route is forbidden for RPF. 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, along with an ExceptionID metadata to indicate what caused the exception. Currently defined exception types include: o The packet failed the LPM lookup of the prefix table. The upstream 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 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 address, a Prefix length, a Hop Selector, an ECMP flag and a Default Route flag. The ECMP flag is so the LFB can support ECMP. The default route flag is for the LFB to support a default route and for loose RPF as described earlier. Wang, et al. Expires July 15, 2012 [Page 59] Internet-Draft ForCES LFB Library January 2012 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. 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 identifier (HopSelector), and uses the identifier 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 a table index to lookup the NextHop table. Two output LFB ports are defined. 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 for the packet is invalid. o The packet failed lookup of the NextHop table even though the HopSelector is valid. o The MTU for outgoing interface is less than the packet size. Wang, et al. Expires July 15, 2012 [Page 60] Internet-Draft ForCES LFB Library January 2012 Downstream 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, when the downstream LFB is BasicMetadataDispatch, and there exist Ethernet and other tunnel Encapsulation downstream from BasicMetadataDispatch, then the BasicMetadataDispatch LFB can use the L3PortID metadata (See section below) to dispatch packets to the different Encapsulator LFBs. 5.3.4.2. Components This LFB has only one component named IPv6NextHopTable which is defined as an array. The array index of IPv6NextHopTable is used for a HopSelector to find out a row of the table as the next hop information. 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 downstream LFB instance. This ID indicates what port to the neighbor is as defined by L3. Usually this ID is used for the NextHop LFB to distinguish packets that need different L2 encapsulating. For instance, some packets may require general Ethernet encapsulation while others may require various types of tunnel encapsulations. In such case, different L3PortIDs are assigned to the packets and are as metadata passed to downstream LFB. A BasicMetadataDispatch LFB(Section 5.5.1) may have to be applied as the downstream LFB so as to dispatch packets to different encapsulation LFB instances according to the L3PortIDs. 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 downstream encapsulation LFB instance and that is used there as a search key to lookup a table (typically media encapsulation related) for further encapsulation information. Note that an encapsulation LFB instance may not directly follow the NextHop LFB, but the index is passed as a metadata associated, as such an encapsulation LFB instance even further downstream to the NextHop LFB can still use the index. In some cases, depending on implementation, the CE may set the MediaEncapInfoIndex passed downstream to a value that will fail lookup when it gets to a target encapsulation LFB; such a lookup failure at that point is an indication that further resolution is needed. For an example of this approach refer to Section 7.2 which talks about ARP and mentions this approach. o LFBOutputSelectIndex, the LFB Group output port index to select downstream LFB port. It is a 1-to-1 mapping with FEObject LFB's Wang, et al. Expires July 15, 2012 [Page 61] Internet-Draft ForCES LFB Library January 2012 table LFBTopology (See [RFC5812]) component FromPortIndex corresponding to the port group mapping FromLFBID as IPv4NextHop LFB instance. 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 [RFC5810], data packets and their associated metadata are encapsulated in ForCES redirect message for transportation between CE and FE. We define two LFBs to abstract the process, a RedirectIn LFB and a RedirectOut LFB. Usually, in an LFB topology of an FE, only one RedirectIn LFB instance and one RedirectOut LFB instance exist. 5.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 RedirectIn LFB is defined with a single output LFB port (and no input LFB port). The single output port of RedirectIn LFB is defined as a group output type, with the name of "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 Wang, et al. Expires July 15, 2012 [Page 62] Internet-Draft ForCES LFB Library January 2012 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 this metadata. Any other metadata, in addition to 'RedirectIndex', will be passed untouched along the packet delivered by the CE to downstream LFB. This means the 'RedirectIndex' metadata from CE will be "consumed" by the RedirectIn LFB and will not be passed to downstream LFB. Note that, a packet from CE 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. 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 RedirectOut LFB is defined with a single input LFB port (and no output LFB port). 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 associated metadata produced (but not consumed) by previous processed LFBs should be delivered to CE via the ForCES protocol redirect message [RFC5810]. The CE can decide on how to process the redirected packet by referencing the associated metadata. As an example, a packet could be redirected by the FE to the CE because the EtherEncap LFB is not able to resolve L2 information. The metadata "ExceptionID", created by the EtherEncap LFB is passed along with the packet and should be sufficient for the Wang, et al. Expires July 15, 2012 [Page 63] Internet-Draft ForCES LFB Library January 2012 CE to do the necessary processing and resolve the L2 entry required. 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 The BasicMetadataDispatch LFB is defined to abstract the process in which a packet is dispatched to some output path based on its associated metadata value. 5.5.1.1. Data Handling The BasicMetadataDispatch has only one singleton input known as "PktsIn". Every input packet should be associated with a metadata that will be used by the LFB to do the dispatch. This LFB contains a Metadata ID component a dispatch table named MetadataDispatchTable, all configured by the CE. The Metadata ID specifies which metadata is to be used for dispatching packets. The MetadataDispatchTable contains entries of a Metadata value and an OutputIndex, specifying that the packet with the metadata value must go out from the LFB group output port instance with the OutputIndex. Two output LFB ports are defined. The first output is a group output port known as "PktsOut". A packet with its associated metadata having found an OutputIndex by successfully looking up the dispatch table will be output to the group port instance with the corresponding index. 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: Wang, et al. Expires July 15, 2012 [Page 64] Internet-Draft ForCES LFB Library January 2012 o There is no matching when looking up the metadata dispatch table. As an example, if the CE decides to dispatch packets according to a physical port ID (PHYPortID), the CE may set the ID of PHYPortID metadata to the LFB first. Moreover, the CE also sets the PHYPortID actual values (the metadata values) and assigned OutputIndex for the values to the dispatch table in the LFB. When a packet arrives, a PHYPortID metadata is found associated with the packet, the metadata value is further used as a key to look up the dispatch table to find out an output port instance for the packet. Currently the BasicMetadataDispatch LFB only allows the metadata value of the dispatch table entry be 32-bits integer. A metadata with other types of value is not supported in this version. A more complex metadata dispatch LFB may be defined in future version of the library. In that LFB, multiple tuples of metadata with more value types supported may be used to dispatch packets. 5.5.1.2. Components This LFB has two components. One component is MetadataID and the other is MetadataDispatchTable. Each row entry of the dispatch table is a struct containing metadata value and the OutputIndex. Note that currently, the metadata value is only allowed to be 32-bits integer. The metadata value is also defined as a content key for the table. The concept of content key is a searching key for tables which is defined in the ForCES FE Model [RFC5812]. See this document and also the ForCES Protocol [RFC5810] for more details on the definition and use of a content key. 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 Wang, et al. Expires July 15, 2012 [Page 65] Internet-Draft ForCES LFB Library January 2012 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 [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. Multiple queues reside at the input side, with every input LFB 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 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 Round Robin (RR) strategy. The default scheduling discipline is RR then. The QueueStats 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. Currently defined queue status includes 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 The following capability is currently defined for the GenericScheduler. o The queue length limit providing the storage ability for every queue. Wang, et al. Expires July 15, 2012 [Page 66] Internet-Draft ForCES LFB Library January 2012 5.5.2.4. Events This LFB does not have any events specified. Wang, et al. Expires July 15, 2012 [Page 67] Internet-Draft ForCES LFB Library January 2012 6. XML for LFB Library EtherPHYCop 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. 1.0 EtherPHYIn The input port of the EtherPHYCop LFB. It expects any kind of Ethernet frame. EthernetAll EtherPHYOut 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. EthernetAll PHYPortID PHYPortID Wang, et al. Expires July 15, 2012 [Page 68] Internet-Draft ForCES LFB Library January 2012 The ID of the physical port that this LFB handles. uint32 AdminStatus Admin status of the LFB PortStatusValues 2 OperStatus Operational status of the LFB. PortStatusValues AdminLinkSpeed The link speed that the admin has requested. LANSpeedType LAN_SPEED_AUTO OperLinkSpeed The actual operational link speed. LANSpeedType AdminDuplexMode The duplex mode that the admin has requested. DuplexType Auto OperDuplexMode The actual duplex mode. DuplexType CarrierStatus The status of the Carrier. Whether the port is linked with an operational connector. boolean false Wang, et al. Expires July 15, 2012 [Page 69] Internet-Draft ForCES LFB Library January 2012 SupportedLinkSpeed Supported Link Speeds LANSpeedType SupportedDuplexMode Supported Duplex Modes DuplexType PHYPortStatusChanged When the status of the Physical port is changed,the LFB sends the new status. OperStatus OperStatus LinkSpeedChanged When the operational speed of the link is changed, the LFB sends the new operational link speed. OperLinkSpeed OperLinkSpeed DuplexModeChanged When the operational duplex mode Wang, et al. Expires July 15, 2012 [Page 70] Internet-Draft ForCES LFB Library January 2012 is changed, the LFB sends the new operational mode. OperDuplexMode OperDuplexMode EtherMACIn 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. 1.0 EtherPktsIn The input port of the EtherMACIn. It expects any kind of Ethernet frame. EthernetAll PHYPortID NormalPathOut 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. EthernetAll Wang, et al. Expires July 15, 2012 [Page 71] Internet-Draft ForCES LFB Library January 2012 PHYPortID L2BridgingPathOut 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. EthernetAll PHYPortID AdminStatus Admin status of the port PortStatusValues 2 LocalMACAddresses Local Mac addresses IEEEMAC L2BridgingPathEnable Is the LFB doing L2 Bridging? boolean false PromiscuousMode Is the LFB in Promiscuous Mode? boolean false Wang, et al. Expires July 15, 2012 [Page 72] Internet-Draft ForCES LFB Library January 2012 TxFlowControl Transmit flow control boolean false RxFlowControl Receive flow control boolean false MACInStats MACIn statistics MACInStatsType EtherClassifier 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. 1.0 EtherPktsIn Input port for data packet. EthernetAll PHYPortID LogicalPortID ClassifyOut Output port for classification. Wang, et al. Expires July 15, 2012 [Page 73] Internet-Draft ForCES LFB Library January 2012 Arbitrary PHYPortID SrcMAC DstMAC EtherType VlanID VlanPriority EtherDispatchTable Ether classify dispatch table EtherDispatchTableType VlanInputTable Vlan input table VlanInputTableType EtherClassifyStats Ether classify statistic table EtherClassifyStatsTableType EtherEncap This LFB abstracts the process to encapsulate IP packets to Ethernet packets according to the L2 information. 1.0 EncapIn A Single Packet Input IPv4 IPv6 MediaEncapInfoIndex Wang, et al. Expires July 15, 2012 [Page 74] Internet-Draft ForCES LFB Library January 2012 VlanPriority SuccessOut Output port for Packets which have found Ethernet L2 information and have been successfully encapsulated to an Ethernet packet. IPv4 IPv6 L2PortID ExceptionOut All packets that fail with the other operations in this LFB are output via this port. IPv4 IPv6 ExceptionID MediaEncapInfoIndex VlanPriority EncapTable Ethernet Encapsulation table. EncapTableType Wang, et al. Expires July 15, 2012 [Page 75] Internet-Draft ForCES LFB Library January 2012 EtherMACOut EtherMACOut LFB abstracts an Ethernet port at MAC data link layer. It specifically describes Ethernet packet output process. Ethernet output functions are closely related to Ethernet input functions, therefore some components defined in this LFB are actually alias of EtherMACIn LFB. 1.0 EtherPktsIn The Input Port of the EtherMACIn. It expects any kind of Ethernet frame. EthernetAll PHYPortID EtherPktsOut 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. EthernetAll PHYPortID AdminStatus Admin status of the port. It is the alias of "AdminStatus" component defined in EtherMACIn. PortStatusValues Wang, et al. Expires July 15, 2012 [Page 76] Internet-Draft ForCES LFB Library January 2012 MTU Maximum transmission unit. uint32 TxFlowControl Transmit flow control. It is the alias of "TxFlowControl" component defined in EtherMACIn. boolean RxFlowControl Receive flow control. It is the alias of "RxFlowControl" component defined in EtherMACIn. boolean MACOutStats MACOut statistics MACOutStatsType IPv4Validator An LFB that performs IPv4 packets validation according to RFC1812. At the same time, ipv4 unicast and multicast are classified in this LFB. 1.0 ValidatePktsIn Input port for data packet. Arbitrary IPv4UnicastOut Output for IPv4 unicast packet. Wang, et al. Expires July 15, 2012 [Page 77] Internet-Draft ForCES LFB Library January 2012 IPv4Unicast IPv4MulticastOut Output for IPv4 multicast packet. IPv4Multicast ExceptionOut Output for exception packet. IPv4 ExceptionID FailOut Output for failed validation packet. IPv4 ValidateErrorID IPv4ValidatorStats IPv4 validator statistics information. IPv4ValidatorStatsType Wang, et al. Expires July 15, 2012 [Page 78] Internet-Draft ForCES LFB Library January 2012 IPv6Validator An LFB that performs IPv6 packets validation according to RFC2460. At the same time, ipv6 unicast and multicast are classified in this LFB. 1.0 ValidatePktsIn Input port for data packet. Arbitrary IPv6UnicastOut Output for IPv6 unicast packet. IPv6Unicast IPv6MulticastOut Output for IPv6 multicast packet. IPv6Multicast ExceptionOut Output for exception packet. IPv6 ExceptionID Wang, et al. Expires July 15, 2012 [Page 79] Internet-Draft ForCES LFB Library January 2012 FailOut Output for failed validation packet. IPv6 ValidateErrorID IPv6ValidatorStats IPv6 validator statistics information. IPv6ValidatorStatsType IPv4UcastLPM 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). 1.0 PktsIn A Single Packet Input IPv4Unicast NormalOut This output port is connected with IPv4NextHop LFB Wang, et al. Expires July 15, 2012 [Page 80] Internet-Draft ForCES LFB Library January 2012 IPv4Unicast HopSelector ECMPOut This output port is connected with ECMP LFB, if there is ECMP LFB in the FE. IPv4Unicast HopSelector ExceptionOut The output for the packet if an exception occurs IPv4Unicast ExceptionID IPv4PrefixTable The IPv4 prefix table. IPv4PrefixTableType IPv4UcastLPMStats Statistics for IPv4 Unicast Longest Prefix Match IPv4UcastLPMStatsType Wang, et al. Expires July 15, 2012 [Page 81] Internet-Draft ForCES LFB Library January 2012 IPv6UcastLPM 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). 1.0 PktsIn A Single Packet Input IPv6Unicast NormalOut This output port is connected with IPv6NextHop LFB IPv6Unicast HopSelector ECMPOut This output port is connected with ECMP LFB, if there is ECMP LFB in the FE. IPv6Unicast HopSelector Wang, et al. Expires July 15, 2012 [Page 82] Internet-Draft ForCES LFB Library January 2012 ExceptionOut The output for the packet if an exception occurs IPv6Unicast ExceptionID IPv6PrefixTable The IPv6 prefix table. IPv6PrefixTableType IPv6UcastLPMStats Statistics for IPv6 Unicast Longest Prefix Match IPv6UcastLPMStatsType IPv4NextHop 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. 1.0 PktsIn A Single Packet Input IPv4Unicast HopSelector Wang, et al. Expires July 15, 2012 [Page 83] Internet-Draft ForCES LFB Library January 2012 SuccessOut The output for the packet if it is valid to be forwarded IPv4Unicast L3PortID NextHopIPv4Addr MediaEncapInfoIndex ExceptionOut The output for the packet if an exception occurs IPv4Unicast ExceptionID IPv4NextHopTable The next hop table. IPv4NextHopTableType IPv6NextHop 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.. 1.0 Wang, et al. Expires July 15, 2012 [Page 84] Internet-Draft ForCES LFB Library January 2012 PktsIn A single packet input. IPv6Unicast HopSelector SuccessOut The output for the packet if it is valid to be forwarded IPv6Unicast L3PortID NextHopIPv6Addr MediaEncapInfoIndex ExceptionOut The output for the packet if an exception occurs IPv6Unicast ExceptionID IPv6NextHopTable Wang, et al. Expires July 15, 2012 [Page 85] Internet-Draft ForCES LFB Library January 2012 The next hop table. IPv6NextHopTableType RedirectIn 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. 1.0 PktsOut This output group sends the redirected packet in the data path. Arbitrary RedirectOut 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]. 1.0 PktsIn This input receives packets to send to the CE. Arbitrary Wang, et al. Expires July 15, 2012 [Page 86] Internet-Draft ForCES LFB Library January 2012 BasicMetadataDispatch 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. 1.0 PktsIn Input port for data packet. Arbitrary Arbitrary PktsOut Data packet output Arbitrary MetadataID the metadata ID for dispatching uint32 MetadataDispatchTable Metadata dispatch table. MetadataDispatchTableType GenericScheduler Wang, et al. Expires July 15, 2012 [Page 87] Internet-Draft ForCES LFB Library January 2012 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 RFC5812. 1.0 PktsIn Input port for data packet. Arbitrary PktsOut Data packet output. Arbitrary QueueCount The number of queues to be scheduled. uint32 SchedulingDiscipline the Scheduler discipline. SchdDisciplineType QueueStats Current statistics for all queues QueueStatsTableType Wang, et al. Expires July 15, 2012 [Page 88] Internet-Draft ForCES LFB Library January 2012 QueueLenLimit Maximum length of each queue,the unit is byte. uint32 Wang, et al. Expires July 15, 2012 [Page 89] Internet-Draft ForCES LFB Library January 2012 7. LFB Class Use Cases This section demonstrates examples on how the LFB classes defined by the Base LFB library in Section 6 can be applied to achieve some typical router functions. The functions demonstrated are: o IPv4 forwarding o ARP processing It is assumed the LFB topology on the FE described has already been established by the CE and maps to the use cases illustrated in this section. The use cases demonstrated in this section are mere examples and by no means should be treated as the only way one would construct router functionality from LFBs; based on the capability of the FE(s), a CE should be able to express different NE applications. 7.1. IPv4 Forwarding Figure 1 (Section 3.2.3) shows a typical IPv4 forwarding processing path by use of the base LFB classes. A number of EtherPHYCop LFB(Section 5.1.1) instances are used to describe physical layer functions of the ports. PHYPortID metadata is generated by EtherPHYCop LFB and is used by all the subsequent downstream LFBs. An EtherMACIn LFB(Section 5.1.2), which describe the MAC layer processing, follows every EtherPHYCop LFB. The EtherMACIn LFB may do a locality check of MAC addresses if the CE configures the appropriate EtherMACIn LFB component. Ethernet packets out of the EtherMACIn LFB are sent to an EtherClassifier LFB (Section 5.1.3) to be decapsulated and classified into network layer types like IPv4, IPv6, ARP, etc. In the example use case, every physical Ethernet interface is associated with one Classifier instance; although not illustrated, it is also feasible that all physical interfaces are associated with only one Ethernet Classifier instance. EtherClassifier uses the PHYPortID metadata, the Ethernet type of the input packet, and VlanID (if present in the input Ethernet packets), to decide the packet network layer type and the LFB output port to the downstream LFB. The EtherClassifier LFB also assigns a new logical port ID metadata to the packet for later use. The EtherClassifier may also generate some new metadata for every packet like EtherType, SrcMAC, DstMAC, LogicPortID, etc for consumption by downstream LFBs. Wang, et al. Expires July 15, 2012 [Page 90] Internet-Draft ForCES LFB Library January 2012 If a packet is classified as an IPv4 packet, it is sent downstream to an IPv4Validator LFB (Section 5.2.1) to validate the IPv4 packet. In the validator LFB, IPv4 packets are validated and are additionally classified into either IPv4 unicast packets or multicast packets. IPv4 unicast packets are sent to downstream to the IPv4UcastLPM LFB (Section 5.3.1). The IPv4UcastLPM LFB is where the longest prefix match decision is made, and a next hop selection is selected. The nexthop ID metadata is generated by the IPv4UcastLPM LFB to be consumed downstream by the IPv4NextHop LFB (Section 5.3.2). The IPv4NextHop LFB uses the nexthop ID metadata to do derive where the packet is to go next and the media encapsulation type for the port, etc. The IPv4NextHop LFB generates the L3PortID metadata used to identify a next hop output physical/logical port. In the example use case, the next hop output port is an Ethernet type; as a result, the packet and its L3 port ID metadata are sent downstream to an EtherEncap LFB (Section 5.1.4). The EtherEncap LFB encapsulates the incoming packet into an Ethernet frame. A BasicMetadataDispatch LFB (Section 5.5.1) follows the EtherEncap LFB. The BasicMetadataDispatch LFB is where packets are finally dispatched to different output physical/logical ports based on the L3PortID metadata sent to the LFB. 7.2. ARP processing Figure 2 shows the processing path for ARP protocol in the case the CE implements the ARP processing function. By no means is this the only way ARP processing could be achieved; as an example ARP processing could happen at the FE - but that discussion is out of scope for this use case. Wang, et al. Expires July 15, 2012 [Page 91] Internet-Draft ForCES LFB Library January 2012 +---+ +---+ | | 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 There are two ways ARP processing could be triggered in the CE as illustrated in Figure 2: o ARP packets arriving from outside of the NE. o IPV4 packets failing to resolve within the FE. ARP packets from network interfaces are filtered out by EtherClassifier LFB. The classified ARP packets and associated metadata are then sent downstream to the RedirectOut LFB (Section 5.4.2) to be transported to CE. The EtherEncap LFB, as described earlier, receives packets that need Ethernet L2 encapsulating. When the EtherEncap LFB fails to find the necessary L2 Ethernet information to encapsulate the packet with, it outputs the packet to its ExceptionOut LFB port. Downstream to EtherEncap LFB's ExceptionOut LFB port is the RedirectOut LFB which transports the packet to the CE (Section 5.1.4 on EtherEncap LFB for details). To achieve its goal, the CE needs to generate ARP request and response packets and send them to external (to the NE) networks. ARP Wang, et al. Expires July 15, 2012 [Page 92] Internet-Draft ForCES LFB Library January 2012 request and response packets from the CE are redirected to an FE via a RedirectIn LFB (Section 5.4.1). As was the case with forwarded IPv4 packets, outgoing ARP packets are also encapsulated to Ethernet format by the EtherEncap LFB, and then dispatched to different interfaces via a BasicMetadataDispatch LFB. The BasicMetadataDispatch LFB dispatches the packets according to the L3PortID metadata included in every ARP packet sent from CE. Wang, et al. Expires July 15, 2012 [Page 93] Internet-Draft ForCES LFB Library January 2012 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 July 15, 2012 [Page 94] Internet-Draft ForCES LFB Library January 2012 9. Acknowledgements This document is based on earlier documents from Joel Halpern, Ligang Dong, Fenggen Jia and Weiming Wang. Wang, et al. Expires July 15, 2012 [Page 95] Internet-Draft ForCES LFB Library January 2012 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 July 15, 2012 [Page 96] Internet-Draft ForCES LFB Library January 2012 | 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 July 15, 2012 [Page 97] Internet-Draft ForCES LFB Library January 2012 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 | PHYPortID | 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-0xFFFFFFFF 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. Wang, et al. Expires July 15, 2012 [Page 98] Internet-Draft ForCES LFB Library January 2012 Exception ID 0x00000000-0x7FFFFFFF 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 | ClassifyNoMatching | See Section 4.4 | | 0x00000002 | MediaEncapInfoIndexInvalid | See Section 4.4 | | 0x00000003 | EncapTableLookupFailed | See Section 4.4 | | 0x00000004 | BadTTL | See Section 4.4 | | 0x00000005 | IPv4HeaderLengthMismatch | See Section 4.4 | | 0x00000006 | RouterAlertOptions | See Section 4.4 | | 0x00000007 | IPv6HopLimitZero | See Section 4.4 | | 0x00000008 | IPv6NextHeaderHBH | See Section 4.4 | | 0x00000009 | SrcAddressExecption | See Section 4.4 | | 0x0000000A | DstAddressExecption | See Section 4.4 | | 0x0000000B | LPMLookupFailed | See Section 4.4 | | 0x0000000C | HopSelectorInvalid | See Section 4.4 | | 0x0000000D | NextHopLookupFailed | See Section 4.4 | | 0x0000000E | FragRequired | See Section 4.4 | | 0x0000000F | MetadataNoMatching | See Section 4.4 | +--------------+---------------------------------+------------------+ Table 3 Exception ID 0x80000000-0xFFFFFFFF 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. Wang, et al. Expires July 15, 2012 [Page 99] Internet-Draft ForCES LFB Library January 2012 Values assigned by this specification: +--------------+---------------------------------+------------------+ | Value | Name | Definition | +--------------+---------------------------------+------------------+ | 0x00000000 | AnyUnrecognizedValidateErrorCase| See Section 4.4 | | 0x00000001 | InvalidIPv4PacketSize | See Section 4.4 | | 0x00000002 | NotIPv4Packet | See Section 4.4 | | 0x00000003 | InvalidIPv4HeaderLengthSize | See Section 4.4 | | 0x00000004 | InvalidIPv4LengthFieldSize | See Section 4.4 | | 0x00000005 | InvalidIPv4Checksum | See Section 4.4 | | 0x00000006 | InvalidIPv4SrcAddr | See Section 4.4 | | 0x00000007 | InvalidIPv4DstAddr | See Section 4.4 | | 0x00000008 | InvalidIPv6PakcetSize | See Section 4.4 | | 0x00000009 | NotIPv6Packet | See Section 4.4 | | 0x0000000A | InvalidIPv6SrcAddr | See Section 4.4 | | 0x0000000B | InvalidIPv6DstAddr | See Section 4.4 | +--------------+---------------------------------+------------------+ Table 4 Validate Error ID 0x80000000-0xFFFFFFFF Validate Error IDs in this range are reserved for vendor private extensions and are the responsibility of individuals. Wang, et al. Expires July 15, 2012 [Page 100] Internet-Draft ForCES LFB Library January 2012 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 July 15, 2012 [Page 101] Internet-Draft ForCES LFB Library January 2012 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 [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [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. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [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 July 15, 2012 [Page 102] Internet-Draft ForCES LFB Library January 2012 Authors' Addresses Weiming Wang Zhejiang Gongshang University 18 Xuezheng Str., Xiasha University Town Hangzhou, 310018 P.R.China Phone: +86 571 28877721 Email: wmwang@zjsu.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 H3C Tech. Co., Ltd. 310 Liuhe Road, Zhijiang Science Park Hangzhou, 310053 P.R.China Phone: +86 571 86760000 Email: chuanhuang_li@zjsu.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 July 15, 2012 [Page 103]