tree: 1ec6e5c496e218f5200f9aa242ebf36f1e399857 [path history] [tgz]
  1. .gitignore
  2. Makefile
  3. README.md
  4. SUMMARY.md
  5. Service.png
  6. ServiceChain.png
  7. contribute_docs.md
  8. core_models.md
  9. dev/
  10. example_service.md
  11. migrate_4.0.md
  12. modeling_conventions.md
  13. modules/
  14. scripts/
  15. security_policies.md
  16. static/
  17. swagger/
  18. venv-xosdocs.sh
  19. xos_internals.md
docs/README.md

Defining Models for CORD

CORD adopts a model-based design, which is to say all aspects of operating and managing CORD is mediated by a model-based control plane. XOS is the component in CORD that implements this control plane.

This guide describes XOS, and the role it plays in the CORD Controller. XOS is not a monolithic component. It is best viewed as having three inter-related aspects, and this guide is organized accordingly.

First, XOS defines a modeling framework, which includes both a modeling language (xproto) and a generative toolchain (xosgenx). The core abstractions that define CORD's behavior are expressed in xproto, with xosgenx then used to generate code for several elements required to control CORD (including an API that serves the set of models that have been loaded into XOS).

Second, CORD is based on a core set of models. These models are expressed and realized using XOS, but they are architecturally independent of XOS. These models are central to defining what CORD is, including its core abstractions and the security policies that govern how various principals can act on those abstractions in a multi-tenant environment.

Third, XOS defines a synchronization framework that actuates the CORD data model. This framework is reponsible for driving the underlying components configured into CORD (for example, services, access devices) towards the desired state.