110 likes | 210 Vues
This document presents the Functional Model for Forwarding Element, detailing the FE blocks, stages, and directed graphs. It covers the FE capability, state, configuration, and block library requirements. It addresses topology control issues between FE and CE, emphasizing balance and flexibility. The document also discusses representation challenges in topology and configuration, proposing semi-dynamic resolution and data modeling language candidates.
E N D
ForCES Forwarding Element Functional Model Lily Yang, Joel Halpern, Ram Gopal, Ram Dantu <draft-yang-forces-model-02.txt>
Overview • FE Model • Open Issues & Next Steps
Motivation FE capability: what FE can be FE CE FE state: what FE is now FE configuration: what FE should be FE Functional Model
FE Block • FE Block = Abstract Base Class for FE logical functions • An FE block specifies: • Block ID or name (functional type) • Textual description of the function • Need a namespace: • Extensible (to allow new functions later)
Block Library • Requirements to support 8 categories of FE functions: • Forwarding • QoS • Filtering • Port • Security • High touch • Off-loaded • Vendor specific
FE stage & Directed Graph • FE Stage: an instance of an FE block in a data path • Stage id (unique within the FE) • Block Name or ID • Number of downstream stages • List of downstream stage Ids • FE Directed Graph: • Interconnection of the FE stages • Can support logical loops by configuring FE Block(s)
Issues List – FE/CE Topology control • FE graph • Topology discovery should be out of scope (during initial stage of design) • No restriction of FE Block layout • Smart CE should be able to figure out and allow/disallow functions. (Current draft addresses this) • Control of Topology • FE has full control , less flexibility • CE has full control, flexibility, but FE may not like all possible configuration on graph elements • Balance approach will be better • Provide bunch of handles and don’t represent topology • Most of the interconnection are hard wired
Issue List – Topology vs. Configuration (1) • Graph representation • CE get bigger picture and important for behavior of NE • It’s a constrained graph (pointers to existing work) • Difficulty in representation • CE don’t have capability for any network, any FE , any protocol • Logical loops and physical Loops representation • CE interpreting any graph is complicated • Element configuration • Focus on configuration and control • Converting FE’s Topology to represent NE
Issue List – Topology vs. Configuration (2) • Resolution • Complete dynamic is out of scope. • Semi-dynamic - Configurablity by manipulating properties of FE Blocks(s) (eg., QoS, IPsec, L5 switching ) • Describe list of function blocks for the model
TO DO List • TO DO List • Data modeling language: representation • Candidates : SMI/SPPI/ASN.1/XML/UML • Describe list of function blocks for the model • WG Document?