rfc-8013

Forwarding and Control Element Separation (ForCES) Inter-FE Logical Functional Block (LFB)

D. Joachimpillai, J. Hadi Salim
date2017-02 streamIETF wgnon working group statusPROPOSED STANDARD pages25 canonicalhttps://www.rfc-editor.org/rfc/rfc8013 doi10.17487/RFC8013 errataview
This document describes how to extend the Forwarding and Control Element Separation (ForCES) Logical Functional Block (LFB) topology across Forwarding Elements (FEs) by defining the inter-FE LFB class. The inter-FE LFB class provides the ability to pass data and metadata across FEs without needing any changes to the ForCES specification. The document focuses on Ethernet transport.

Extracted elements (23)

design-rationale §5.2

A 16-bit TLV encoding is used for metadata rather than a ForCES Index-Length-Value (ILV), which would use 32-bit component IDs. This saves 4 bytes per metadatum transferred at the cost of restricting metadata IDs to 16 bits, deemed sufficient at publication time.

design-rationale §4

The inter-FE LFB is implemented as a standard LFB class definition rather than modifying the core ForCES architecture (FE Object capabilities such as SupportedLFBs or LFBTopology). This avoids any changes to the ForCES specification while enabling cross-FE LFB topology extension.

security

design-rationale §3.1

The specification focuses exclusively on Ethernet as the inter-FE transport because it is commonly used for FE interconnection. Other transports (UDP over IP, or lower-layer alternatives) are noted as possible but out of scope.

interoperability-note §5.2

All TLVs within the inter-FE Ethernet frame MUST be 32-bit aligned; padding of zeroes must be appended at the end of each TLV as needed. The TLV type field carries the ForCES metadata ID registered with IANA.

registry

interoperability-note §5.2

The 16-bit metadata length field in the inter-FE Ethernet frame includes the 2 bytes used by the length field itself. Implementations must account for this self-inclusion when computing total metadata size.

interoperability-note §5.1.1

When sizing the egress port MTU to accommodate inter-FE metadata overhead, care must be taken not to report an MTU below the protocol minimums: 64 octets for IPv4 (RFC 791) and 1280 octets for IPv6 (RFC 2460).

ip

normative-requirement §5.1.3 SHOULD

Additional measures SHOULD be imposed to restrict the impact of inter-FE-encapsulated traffic, including rate-limiting at an upstream LFB, managing circuit breaking, and isolating inter-FE traffic via dedicated interfaces or VLANs.

congestion, qos

normative-requirement §6.1.2 MUST

During ingress processing, if an unknown metadata ID is encountered or if the metaID is not in the allowed filter list, the implementation MUST ignore it, increment the packet error statistic, and continue processing other metadata.

normative-requirement §6.1.1 MUST

If the optional IFETYPE field is absent from the IFETable row, the standard inter-FE LFB ethertype ED3E (hexadecimal) MUST be used in the outgoing Ethernet frame.

normative-requirement §6.1.1 MUST

On egress, if the additional Ethernet header and encapsulated metadata overhead would exceed the MTU, the packet MUST be sent to EXCEPTIONOUT with exceptionID FragRequired rather than fragmented or silently dropped.

normative-requirement §5.1.3 MUST

The inter-FE LFB MUST only be deployed within a single network with a single operator, or within an adjacent set of cooperating network operators where traffic is managed to avoid congestion, i.e., a Controlled Environment as defined by the UDP Usage Guidelines.

congestion

normative-requirement §5.1.3 SHOULD

Traffic engineering SHOULD be performed when deploying inter-FE encapsulation because the additional ForCES metadata increases packet size and therefore requires additional bandwidth on inter-FE links.

congestion

protocol-element §6.2

The IFEStats component (componentID 2, read-only) is an indexed array of bstats structures, each containing bytes (uint64), packets (uint32), and errors (uint32) counters corresponding to IFETable entries.

protocol-element §6.2

The IFETable component (componentID 1, read-write) is a variable-size array of IFEInfo structs, each containing: optional IFETYPE (uint16 ethertype), optional StatId (uint32 index into IFEStats), mandatory DSTFE (6-byte destination MAC), mandatory SRCFE (6-byte source MAC), and optional MetaFilterList (variable-size array of uint32 metadata IDs acting as a whitelist).

protocol-element §6

The inter-FE LFB (LFB Class ID 18, name IFE, version 1.0) has two input port groups: EgressInGroup (accepts any packet plus metadata for encapsulation) and IngressInGroup (accepts inter-FE-encapsulated Ethernet frames for decapsulation). It has three output ports: OUT1 (encapsulated frame), OUT2 (decapsulated packet and metadata), and EXCEPTIONOUT (error path with ExceptionID metadata).

registry §7

IANA registered LFB Class Identifier 18 with class name 'IFE' and version 1.0 in the 'Logical Functional Block (LFB) Class Names and Class Identifiers' subregistry of the ForCES registry, referencing this document.

registry

security-consideration §9 SHOULD

Inter-FE LFB implementations SHOULD support MACsec (IEEE 802.1AE) to provide message authentication and optional confidentiality for frames exchanged between FEs within the same administrative Ethernet LAN. MACsec can be configured manually via shared keys or automatically via MACsec Key Agreement (MKA) over IEEE 802.1x EAP.

security, crypto

security-consideration §9 SHOULD

Operators SHOULD configure strict validation mode so that all non-protected, invalid, or non-verifiable Ethernet frames MUST be dropped. If an FE is compromised, an entity on that FE can fake or modify inter-FE frames, causing adverse outcomes.

security

security-consideration §9 SHOULD

Operators SHOULD configure the same security policies (including pre-shared Security Association Keys) for all FEs in the NE cluster to ensure uniform operations. When using MKA, FEs must identify themselves with a shared Connectivity Association Key (CAK) and CKN, and EAP-TLS SHOULD be used as the EAP method.

security, crypto

security-consideration §9

The inter-FE LFB is scoped to FEs within the same Network Element, operating in a single administrative private Ethernet LAN. Security is therefore NE-wide; once MACsec is enabled for a chosen security level (Authentication or Confidentiality), it applies for the entire duration of the session.

security

state-machine §6.1.1

Egress processing: (1) look up IFETable using incoming EgressInGroup port; on miss, send to EXCEPTIONOUT with EncapTableLookupFailed. (2) Apply MetaFilterList whitelist; if no metadata passes, send to EXCEPTIONOUT. (3) Check that Ethernet header plus encapsulated metadata does not exceed MTU; on failure, send to EXCEPTIONOUT with FragRequired. (4) Build Ethernet header, TLV-encode allowed metadata, append original payload, forward to OUT1.

state-machine §6.1.2

Ingress processing: (1) identify inter-FE frame by ethertype and optionally MAC addresses, map to IngressInGroup port. (2) Walk TLVs using metadata length field; for each metadatum, compare against MetaFilterList whitelist—unknown or disallowed IDs are ignored and the error statistic is incremented. (3) Reset data pointer past IFE header to reconstruct original packet and metadata; forward to OUT2. On failure, send to EXCEPTIONOUT.

wire-format §5.2

The inter-FE Ethernet frame is 32-bit aligned and contains: 6-byte Destination MAC (identifying destination FEID), 6-byte Source MAC (identifying source FEID), 16-bit Inter-FE ethertype (ED3E hex), 16-bit metadata length (including the length field itself), one or more 32-bit-aligned 16-bit TLV-encoded metadata items, followed by the original packet payload.