ForCES Inter-FE LFB

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 .

This document follows the terminology defined by the ForCES Model in . The required definitions are repeated below for clarity. FE Model - The FE model is designed to model the logical processing functions of an FE. 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]. LFB (Logical Functional Block) Class (or type) - A template that represents a fine-grained, logically separable aspect of FE processing. Most LFBs relate to packet processing in the data path. LFB classes are the basic building blocks of the FE model. LFB Instance - As a packet flows through an FE along a data path, it flows through one or multiple LFB instances, where each LFB is an instance of a specific LFB class. Multiple instances of the same LFB class can be present in an FE's data path. Note that we often refer to LFBs without distinguishing between an LFB class and LFB instance when we believe the implied reference is obvious for the given context. LFB Model - The LFB model describes the content and structures in an LFB, plus the associated data definition. XML is used to provide a formal definition of the necessary structures for the modeling. Four types of information are defined in the LFB model. The core part of the LFB model is the LFB class definitions; the other three types of information define constructs associated with and used by the class definition. These are reusable data types, supported frame (packet) formats, and metadata. 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, but not how the per-packet state is implemented within actual hardware. Metadata is sent between the FE and the CE on redirect packets. ForCES Component - A ForCES Component is a well-defined, uniquely identifiable and addressable ForCES model building block. A component has a 32-bit ID, name, type, and an optional synopsis description. These are often referred to simply as components. LFB Component - An LFB component is a ForCES component that defines the Operational parameters of the LFBs that must be visible to the CEs. LFB Topology - LFB topology is a representation of the logical interconnection and the placement of LFB instances along the data path within one FE. Sometimes this representation is called intra-FE topology, to be distinguished from inter-FE topology. LFB topology is outside of the LFB model, but is part of the FE model. FE Topology - FE topology is a representation of how multiple FEs within a single network element (NE) are interconnected. Sometimes this is called inter-FE topology, to be distinguished from intra-FE topology (i.e., LFB topology). An individual FE might not have the global knowledge of the full FE topology, but the local view of its connectivity with other FEs is considered to be part of the FE model. Service Graph - A directed graph of LFB instances whose composition delivers a packet service.

In the ForCES architecture, a packet service can be modelled by composing a graph of one or more LFB instances. The reader is refered to the details in the ForCES Model. The FEObject LFB capabilities as defined in the ForCES Model include an array (SupportedLFBs) that contains the information about each supported LFB class. Each entry in the SupportedLFBs array describes an LFB class that the FE supports. In addition to indicating that the FE supports the class, FEs with modifiable LFB topologies include information about how LFBs of the specified class may be connected to other LFBs. This information describes which LFB classes the specified LFB class may succeed or precede in an LFB topology. The capability of an FE is advertised to the CE upon association. The CE may create a packet service when describing LFB instance graph connections by updating the FEOBject LFBTopology component. The created topology contains information about each inter-LFB link inside the FE, where each link is described in an LFBLinkType dataTypeDef. The LFBLinkType component contains sufficient information to identify precisely the end points of a link of a service graph. Often there are requirements for the packet service graph to cross FE boundaries. This could be from a desire to scale the service or need to interact with LFBs which reside in a separate FE (eg lookaside interface to a shared TCAM, an interconnected chip, or as coarse grained functionality as an external NAT FE box being part of the service graph etc). Given that the ForCES inter-LFB architecture calls out for ability to pass metadata between LFBs, it is imperative to define mechanisms to allow passing the metadata between inter-FE LFBs (given that packet data passing is already taken care of). The ForCES charter restricts the LFB links in a topology to be within a single FE (intra-FE connectivity) and as such both the relevant capabilities and component definitions in the FEObject LFB are restricted to that scope. This document describes extending the LFB topology across FEs i.e inter-FE connectivity without needing any changes to the ForCES definitions.

A sample LFB topology demonstrates a service graph for delivering basic IPV4 forwarding service within one FE. Note: although the diagram shows LFB classes connecting in the graph in reality it is a graph of LFB class instances that are inter-connected. The illustration is meant only as an exercise to showcase how data and metadata is sent down or upstream on a graph of LFBs. For this reason, it abstracts out any ports in both directions and talks about a generic ingress and egress LFB. For illustration purposes, the diagram does not show expection or error paths. Also left out are details on Reverse Path Filtering, ECMP, multicast handling etc. In other words, this is not meant to be a complete description of an IPV4 forwarding application; for a more complete example, please refer to the LFBlib document[XXX: ref here]. The output of the ingress LFB(s) coming into the IPv4 Validator LFB will have both the IPV4 packets and, depending on the implementation, a variety of ingress metadata such as offsets into the different headers, any classification metadata, physical and virtual ports encountered, tunnelling information etc. These metadata are lumped together as "ingress metadata". Once the IPV4 validator vets the packet (example ensures that no expired TTL etc), it feeds the packet and inherited metadata into the IPV4 unicast LPM LFB.

| |------------->| | | | | + ingress | | + ingress |IPv4 | IPV4 pkt | | | metadata | | metadata |Ucast|------------>| |--+ | +----+ |LPM | + ingress | | | +-+-+ IPv4 +-----+ + NHinfo +---+ | | | Validator metadata IPv4 | | | LFB NextHop| | | LFB | | | | | | IPV4 pkt +---+ + {ingress + NHdetails} Ingress metadata | LFB +-------+ | |Egress | | <--|LFB |<------------------+ +-------+ ]]> The IPV4 unicast LPM LFB does a longest prefix match lookup on the IPV4 FIB using the destination IP address as a search key. The result is typically a next hop selector which is passed downstream as metadata. The Nexthop LFB receives the IPv4 packet with an associated next hop info metadata. The NextHop LFB consumes the NH info metadata and derives from it a table index to look up the next hop table in order to find the appropriate egress information. The lookup result is used to build the next hop details to be used downstream on the egress. This information may include any source and destination information (MAC address to use, if ethernet;) as well egress ports. [Note: It is also at this LFB where typically the forwarding TTL decrement and IP checksum recalculation occurs.] The details of the egress LFB are left out intentionally from this discussion. Suffice it is to say that somewhere within or beyond the Egress LFB the IPV4 packet will be sent out a port (ethernet, virtual or physical etc).

demonstrates one way the LFB topology in may be split across two FEs (eg two ASICs). shows the LFB topology split across FEs after the IPV4 unicast LPM LFB.

| |------------->| | | | | | + ingress | | + ingress |IPv4 | | | +----------+ metadata | | metadata |Ucast| | | ^ +----+ |LPM | | | | IPv4 +-----+ | | | Validator | | | LFB | | +---------------------------------------------------|---------+ | IPv4 packet + {ingress + NHinfo} metadata FE2 | +---------------------------------------------------|---------+ | V | | +--------+ +--------+ | | | Egress | IPV4 packet | IPV4 | | | <-----| LFB |<-------------------- |NextHop | | | | |{ingress + NHdetails} | LFB | | | +--------+ metadata +--------+ | +-------------------------------------------------------------+ ]]> Some proprietary inter-connect (example Broadcom Higig over XAUI (XXX: ref needed)) maybe used to carry both the IPV4 packet and the related metadata between the IPV4 Unicast LFB and IPV4 NextHop LFB across the two FEs.

We address the inter-FE connectivity by proposing an inter-FE LFB. Using an LFB implies no change to the basic ForCES architecture in the form of the core LFBs (FE Protocol or Object LFBs). This design choice was made after considering an alternative approach that would have required changes to both the FE Object capabilities (SupportedLFBs) as well LFBTopology component to describe the inter-FE connectivity capabilities as well as runtime topology of the LFB instances.

The distributed LFB topology described in is re-illustrated in to show the topology location where the inter-FE LFB would fit in. As can be observed in , the same details passed between IPV4 unicast LPM LFB and the IPV4 NH LFB are passed to the egress side of the Inter-FE LFB. In addition an index for the inter-FE LFB (interFEid) is passed as metadata.

| |------------->| | | | | | + ingress | | + ingress |IPv4 | | | +----------+ metadata | | metadata |Ucast| | | ^ +----+ |LPM | | | | IPv4 +-----+ | | | Validator | | | | LFB | | | | IPv4 pkt + metadata | | | {ingress + NHinfo + InterFEid}| | | | | | +----V----+ | | | InterFE | | | | LFB | | | +---------+ | +---------------------------------------------------|---------+ IPv4 packet and metadata {ingress + NHinfo + InterFEinfo} FE2 | +---------------------------------------------------|---------+ | +----V----+ | | | InterFE | | | | LFB | | | +---------+ | | | | | IPv4 pkt + metadata | | {ingress + NHinfo} | | | | | +--------+ +----V---+ | | | Egress | IPV4 packet | IPV4 | | | <-----| LFB |<-------------------- |NextHop | | | | |{ingress + NHdetails} | LFB | | | +--------+ metadata +--------+ | +-------------------------------------------------------------+ ]]> The egress of the inter-FE LFB uses the received Inter-FE index (InterFEid metadata) to select details for encapsulation towards the neighboring FE. These details, encapsulated as InterFEinfo metadata, will include what the source and destination FEID, LFB class and LFB instance are to be used. In addition to the newly constructed metadata, the original metadata is left untouched and passed along with the IPV4 packet. On the ingress side of the inter-FE LFB, the InterFEinfo metadata is used to decide the graph continuation i.e which LFB instance is to be passed the packet plus the origial metadata. In this case an IPV4 Nexthop LFB instance. The ingress side of the inter-FE LFB consumes the InterFEinfo metadata and passes on the IPV4 packet alongside with the ingress + NHinfo metadata to the IPV4 NextHop LFB as was done earlier in both and .

It is expected there will be several inter-FE transport possibilities. We describe the suggested encapsulation format () extended from the ForCES redirect packet format. We expect that for any transport mechanism used, that a description of how the different fields will be encapsulated to be explained. We provide a description of how ethernet encapsulation will be used in this case in .

The NESelector and LFBSelector are considered to be part of the InterFEinfo metadata described earlier. In some cases, each or both of these metadatum may be left out in the encapsulation activity (by the inter-FE LFB implementation) if they are already implicitly defined. An example where that may make sense is in the case of look-aside interfaces or proprietary hard-coded connections (such as the one shown in ). For this reason they are tagged as optional. The NESelector carries a 32-bit NEID which defaults to 0. It also carries the destination and source FEIDs. This TLV is new to ForCES and sits in the global ForCES TLV namespace. The LFBSelector is as defined in RFC 5810 section 7.5.1. It carries a 32-bit LFB Classid and a 32-bit LFB InstanceID. The METADATA and REDIRECTDATA TLV encapsulations are taken directly from section 7.9.

Although it is expected that multiple transport encapsulations could be used they are all expected to carry the format described in or in the case of legacy formats be able to intepret the inter-FE config and translate into proprietary or legacy formatting. Already a variety of metadata passing encapsulations exist which are proprieatary or semi-standard by virtue of being widely deployed. These include the NPF LA-1 (XXX: ref here), Broadcom Higig/2 (XXX: ref here), as well as interlaken(XXX: ref here). In this section we describe a format that is to be used over Ethernet. It is expected that an ethernet type (To be defined) will be used to imply that a wire format is carrying an inter-FE LFB packet. XXX: The finer details on what the source and destination MAC address selection are left out for the next draft release. Also left out are any load balancing/multi-pathing activities across selections of destinations FEs.

There are several issues that may arise due to using direct ethernet encapsulation. The frame may end up being larger than the MTU. There are several possible solutions: One possible solution is to use large MTUs; however, even that will have limits since the the ethernet frames could grow arbitrarily large with increasing metadata being encapsulated. An alternative approach is to add a fragmentation detail in the encapsulation. A simple approach is to have the inter-FE LFB (egress) add another header which submits total count of fragments and the fragment number of the submitted packet. The ingress of the inter-FE LFB will keep track of the fragments, assemble them as well as have a timer to discard outstanding fragments. A third option is to limit the amount of metadata that could be transmitted so that the frame is sub-MTU size in presence of large MTU values. It will mean to add knobs to filter out or select which metadata gets encapsulated. The frame may be dropped if there is congestion on the receiving FE side. This may necessitate a retransmission mechanism to be built in. One approach to mitigate this issue is to make sure that inter-FE LFB frames receive the highest priority treatment when scheduled on the wire. XXX: This issue will be addressed further in the next draft release. Suggestions welcome.

The inter-FE LFB has a single LFB input port and two LFB output ports.

The Inter-FE LFB receives packet and metadata. The InterFEid metadatum MUST be present. It is expected that the formating of the received packet buffer and metadata is implementation specific. If the location of the Inter-FE LFB format is such that it is at the ingress of the FE, then it is expected that some parsing LFB would already have formated the packet and metadata into native format. The Inter-FE LFB uses the InterFEid metadatum to lookup the NextFE table. The output result constitutes a table row which has the InterFEinfo details i.e. the tuple {NEID,Destination FEID,Source FEID, Destination LFB class,Destination LFB Instance}. In the case of successful lookup, for the introduced ethernet formating, the inter-FE LFB will create an ethernet frame with ethertype XXXX. add the NESelector data from the lookup result add the LFBSelector data from the lookup result walk all the passed metadatum and encapsulate them within the METADATA-TLV Encapsulate the data in REDIRECTDATA-TLV The resulting packet is sent to the LFB instance connected to the OUT LFB port. In the case of failure, the packet and metadata are sent out the EXCEPTIONOUT LFB port with proper error id (XXX: More description to be added).

There is a single LFB component populated by the CE. The component is an array component known as the NextFE table. Each row of the table constitutes the columns with {NEID,Destination FEID,Source FEID,Destination LFB class, Destination LFB Instance}. The table is looked up by a 32 bit index passed from an upstream LFB class instance in the form of InterFEid metadatum. The CE programs LFB instances in a service graph that require inter-FE connectivity with InterFEid values to correspond to the inter-FE LFB NextFE table entries to use.

XXX: If we support multiple encapsulation methods(other than ethernet), then we could use capabilities to advertise them as different possibilities. It is envisioned then that the NextFE table row will have column indicating to the inter-FE LFB how to encapsulate the different matches.

TBA

The author would like to thank Jamal Hadi Salim for reviewing this draft and making suggestions to make it align better with the ForCES architecture.

This memo includes no request to IANA.

TBD