Sometimes seen as a middle ground between. ⢠SOA (Service Oriented Architectures) and ROA. (Resource-Oriented Architectures (ROA). ⢠SBA inherits service ...
SERVICE BASED ARCHITECTURES Application to NFV Bruno Chatras, ISG NFV Vice-Chairman
SERVICE BASED ARCHITECTURE (SBA) No strict definition! A feeling of déjà vu? Sometimes seen as a middle ground between • SOA (Service Oriented Architectures) and ROA (Resource-Oriented Architectures (ROA)
• SBA inherits service registration and discovery features from SOA and the RESTful API design from ROA.
• SOA and Microservices
• Service-based architectures consist of tens of deployable
services, rather than the hundreds or thousands advocated by Microservices purists.
Context of the presentation: What does SBA mean when applied to the functional architecture of a system?
SBA KEY DESIGN PROPERTIES - 1 All network Functional Blocks (FB) expose one or more services – through Service-Based Interfaces (SBI) - that may be consumed by any other functional block as if they were all connected to a shared “Service Bus” • You no longer need to specify explicit reference points between pairs of functional blocks
SBA KEY DESIGN PROPERTIES - 3 SBA does not require a common data storage approach but is compatible with it. • Some functional blocks on the “service bus” can expose a data storage service, where other services can store any kind of data, including state.
WHAT SBA MEANS FOR 3GPP 3GPP uses SBA as a representation of the functional architecture of the control plane of a 5G Core Network • and is about to use it for management plane as well (TS 28.533) Conventional approach AUSF
STEP 1: APPLY THE SERVICE BUS PARADIGM From RP-oriented GSs to Interface/API/serviceoriented GSs. • Primarily a change in documentation structure, to detach interfaces from reference points. • No or limited technical impact? Potential benefits: Clarify to the industry that API specifications can resist to various architectural changes, e .g. • New currently unforeseen relationships between existing FBs • FB split into multiple FBs, each consuming or producing a different subset of the APIs currently bound to a reference point
STEP 2: DYNAMIC REGISTRATION AND DISCOVERY Each time an FB instance is created it registers itself in a special FBs acting as a registry. A FB can query the registry to discover an FB instance that provides the service it needs. Potential benefits: Facilitate MANO management
• Facilitate discovery of new NFV-MANO functional entity instances (and their capabilities) – See GR NFV-IFA021 requirements and GS NFV-IFA 031
STEP 3: COMMON DATA STORAGE Create one or two specific FBs that would model the database functionality for storing • VNF and NS catalogues (i.e. collections of VNFDs, PNFDs, and NSDs) • Run-time information about VNF instances and NS instances (i.e. collections of VNFRs, PNFRs, and NSRs) Potential benefits: • Simplify NFVO / VNFM failover • Makes the catalogues and instances inventory independent from the NFVO and VNFMs, directly accessible by any other FBs.
WAY FORWARD Is there sufficient interest to launch a study on the “SBA-ization” of NFV? Objectives would be to assess the technical feasibility and ROI of the different transformation steps.
