Merge "Modifying ONOS configuration to reflect change 12013"
diff --git a/README.md b/README.md
index a25b9d8..248aff3 100644
--- a/README.md
+++ b/README.md
@@ -2,11 +2,12 @@
This guide describes how to install CORD. It identifies a set of
[prerequisites](prereqs/README.md), and then walks through
-the steps involved in bringing up one of three CORD profiles:
+the steps involved in bringing up the [Platform](platform.md). Once
+the Platform is installed, you are ready to bring up one of the
+available Profiles:
-* [R-CORD](./profiles/rcord/install.md)
-* [M-CORD](./profiles/mcord/install.md)
* [SEBA](./profiles/seba/install.md)
+* [M-CORD](./profiles/mcord/install.md)
If you are anxious to jump straight to a [Quick Start](quickstart.md)
procedure that brings up an emulated version of CORD running
diff --git a/SUMMARY.md b/SUMMARY.md
index cc83143..3bd98dd 100644
--- a/SUMMARY.md
+++ b/SUMMARY.md
@@ -5,6 +5,9 @@
* [Quick Start](quickstart.md)
* [MacOS](macos.md)
* [Linux](linux.md)
+
+## Guides
+
* [Installation Guide](README.md)
* [Prerequisites](prereqs/README.md)
* [Hardware Requirements](prereqs/hardware.md)
@@ -17,75 +20,28 @@
* [Optional Packages](prereqs/optional.md)
* [OpenStack](prereqs/openstack-helm.md)
* [Fabric Software Setup](fabric-setup.md)
- * [Bringing Up CORD](profiles/intro.md)
- * [R-CORD](profiles/rcord/install.md)
- * [EdgeCore (OpenOLT driver) Setup](openolt/README.md)
- * [Celestica / Microsemi Setup](profiles/rcord/celestica-olt-setup.md)
- * [Emulated OLT/ONU](profiles/rcord/emulate.md)
- * [M-CORD](profiles/mcord/install.md)
- * [EnodeB Setup](profiles/mcord/enodeb-setup.md)
- * [SEBA](profiles/seba/install.md)
- * [SEBA-in-a-Box](profiles/seba/siab.md)
- * [SEBA-in-a-Box with a fabric switch](profiles/seba/siab-with-fabric-switch.md)
- * [Offline POD install](offline-install.md)
- * [Helm Reference](charts/helm.md)
- * [XOS-CORE](charts/xos-core.md)
- * [ONOS](charts/onos.md)
- * [VOLTHA](charts/voltha.md)
- * [Kafka](charts/kafka.md)
- * [Hippie OSS](charts/hippie-oss.md)
- * [Base OpenStack](charts/base-openstack.md)
- * [VTN Setup](prereqs/vtn-setup.md)
- * [R-CORD](charts/rcord.md)
- * [M-CORD](charts/mcord.md)
- * [XOSSH](charts/xossh.md)
- * [Logging and Monitoring](charts/logging-monitoring.md)
- * [Persistent Storage](charts/storage.md)
- * [BBSim](charts/bbsim.md)
+ * [Install Platform](platform.md)
+ * [Install Profile](profiles.md)
+ * [Offline Install](offline-install.md)
+ * [Attach containers to external NICs](operating_cord/veth_intf.md)
* [Operations Guide](operating_cord/operating_cord.md)
* [General Info](operating_cord/general.md)
* [GUI](operating_cord/gui.md)
* [Configuring the Service Graph](xos-gui/developer/service_graph.md)
* [XOSSH](xos/dev/xossh.md)
- * [XOS Internals](operating_cord/xos_internals.md)
- * [XOS Containers](xos/xos_internals.md)
- * [XOS Configuration](xos/modules/xosconfig.md)
- * [Configuring Profiles](operating_cord/profiles.md)
- * [R-CORD](profiles/rcord/configuration.md)
- * Workflows
- * [AT&T](profiles/rcord/workflows/att.md)
- * [M-CORD](profiles/mcord/configuration.md)
- * [Configuring Services](operating_cord/services.md)
- * [Fabric](fabric/README.md)
- * [ONOS](onos-service/README.md)
- * [RCORD](rcord/README.md)
- * [vOLT](olt-service/README.md)
- * [vRouter](vrouter/README.md)
- * [AT&T Workflow Driver](att-workflow-driver/README.md)
- * [Attach containers to external NICs](operating_cord/veth_intf.md)
-* [API Guide](api/api.md)
- * [gRPC API Tutorial](xos/dev/grpc_api.md)
- * [REST API](operating_cord/rest_apis.md)
- * [TOSCA](xos-tosca/README.md)
+ * [APIs](operating_cord/api.md)
+ * [gRPC API](xos/dev/grpc_api.md)
+ * [REST API](operating_cord/rest_apis.md)
+ * [TOSCA](xos-tosca/README.md)
+ * [Monitoring and Logging](operating_cord/diag.md)
+ * [Prometheus](operating_cord/prometheus.md)
+ * [ELK Stack](operating_cord/elk_stack.md)
* [Development Guide](developer/developer.md)
* [Getting the Source Code](developer/getting_the_code.md)
- * [Writing Models and Synchronizers](xos/intro.md)
- * [XOS Modeling Framework](xos/dev/xproto.md)
- * [XOS Tool Chain (Internals)](xos/dev/xosgenx.md)
- * [XOS Synchronizer Framework](xos/dev/synchronizers.md)
- * [Synchronizer Design](xos/dev/sync_arch.md)
- * [Synchronizer Implementation](xos/dev/sync_impl.md)
- * [Synchronizer Reference](xos/dev/sync_reference.md)
- * [Core Models](xos/core_models.md)
- * [Security Policies](xos/security_policies.md)
- * [Tutorial](xos/tutorials/basic_synchronizer.md)
+ * [Modeling Services](developer/xos-intro.md)
* [Developer Workflows](developer/workflows.md)
* [Working on R-CORD Without an OLT/ONU](developer/configuration_rcord.md)
* [Building Docker Images](developer/imagebuilder.md)
- * [Platform Services](developer/platform.md)
- * [Kubernetes](kubernetes-service/kubernetes-service.md)
- * [OpenStack](openstack/openstack-service.md)
- * [VTN and Service Composition](xos/xos_vtn.md)
* [Example Services](examples/examples.md)
* [SimpleExampleService](simpleexampleservice/simple-example-service.md)
* [ExampleService](exampleservice/example-service.md)
@@ -103,3 +59,47 @@
* [Test Environment](cord-tester/qa_testenv.md)
* [System Tests](cord-tester/validate_pods.md)
+## References
+
+* [Profile Reference](profiles/intro.md)
+ * [SEBA](profiles/seba/README.md)
+ * Install
+ * [Install SEBA Charts](profiles/seba/install.md)
+ * [SEBA-in-a-Box](profiles/seba/siab.md)
+ * [SEBA-in-a-Box with Fabric Switch](profiles/seba/siab-with-fabric-switch.md)
+ * [Scale testing with BBSim](profiles/seba/bbsim.md)
+ * [Celestica / Microsemi Setup](profiles/rcord/celestica-olt-setup.md)
+ * [Emulated OLT/ONU](profiles/rcord/emulate.md)
+ * Workflows
+ * [AT&T](profiles/seba/workflows/att.md)
+ * [Configure](profiles/seba/configuration.md)
+ * [M-CORD](profiles/mcord/README.md)
+ * Install
+ * [Install M-CORD Charts](profiles/mcord/install.md)
+ * [EnodeB Setup](profiles/mcord/enodeb-setup.md)
+ * [Configure](profiles/mcord/configuration.md)
+* [Service Reference](operating_cord/services.md)
+ * [Fabric](fabric/README.md)
+ * [ONOS](onos-service/README.md)
+ * [RCORD](rcord/README.md)
+ * [vOLT](olt-service/README.md)
+ * [vRouter](vrouter/README.md)
+ * [AT&T Workflow Driver](att-workflow-driver/README.md)
+ * [Kubernetes](kubernetes-service/kubernetes-service.md)
+ * [OpenStack](openstack/openstack-service.md)
+ * [VTN](xos/xos_vtn.md)
+* [Helm Reference](charts/helm.md)
+ * [XOS-CORE](charts/xos-core.md)
+ * [ONOS](charts/onos.md)
+ * [VOLTHA](charts/voltha.md)
+ * [Kafka](charts/kafka.md)
+ * [Hippie OSS](charts/hippie-oss.md)
+ * [Base OpenStack](charts/base-openstack.md)
+ * [VTN Setup](prereqs/vtn-setup.md)
+ * [R-CORD](charts/rcord.md)
+ * [M-CORD](charts/mcord.md)
+ * [XOSSH](charts/xossh.md)
+ * [Logging and Monitoring](charts/logging-monitoring.md)
+ * [Persistent Storage](charts/storage.md)
+ * [BBSim](charts/bbsim.md)
+
diff --git a/api/api.md b/api/api.md
deleted file mode 100644
index 1948c3f..0000000
--- a/api/api.md
+++ /dev/null
@@ -1,14 +0,0 @@
-# API Guide
-
-This guide describes workflows for interacting with the API of the NEM. There
-are several different API mechanisms that the NEM supports. Some of them are
-used in a Northbound context, for services sitting on top the NEM to interact
-with the NEM, and some are used internally for components to communicate with each other.
-
-* [gRPC](/xos/dev/grpc_api.md). The gRPC API is used internally for synchronizers and for Chameleon to speak with the XOS core. It's also available as a Northbound API.
-
-* [REST](/operating_cord/rest_apis.md). The REST API is implemented by the Chameleon container. In addition to being a popular Northbound API, it's also used by the XOS GUI.
-
-* [TOSCA](/xos-tosca/README.md). TOSCA is implemented by the xos-tosca container and is typically used to configure and provision a
- POD. Later sections of this guide give examples of TOSCA workflows used to provision and configure various
- [profiles](/operating_cord/profiles.md) and [services](/operating_cord/services.md). TOSCA can also be used as a general-purpose runtime API.
diff --git a/book.json b/book.json
index 0bf2058..99c87d6 100644
--- a/book.json
+++ b/book.json
@@ -13,10 +13,12 @@
"plugins": [
"anchorjs",
"smart-nav-collapse",
+ "custom-favicon",
"page-toc",
"versions-select"
],
- "pluginsConfig": {
+"pluginsConfig": {
+ "favicon": "images/cord.ico",
"versions": {
"options": [
{
diff --git a/charts/rcord.md b/charts/rcord.md
new file mode 100644
index 0000000..789d8a7
--- /dev/null
+++ b/charts/rcord.md
@@ -0,0 +1,2 @@
+# R-CORD
+
diff --git a/charts/seba-services.md b/charts/seba-services.md
new file mode 100644
index 0000000..3145bdc
--- /dev/null
+++ b/charts/seba-services.md
@@ -0,0 +1,10 @@
+# SEBA Services
+
+This chart contains all the XOS services needed to install SEBA.
+
+You can install it using:
+
+```bash
+helm dep update xos-profiles/seba-services
+helm install -n seba-service xos-profiles/seba-services/
+```
\ No newline at end of file
diff --git a/developer/xos-intro.md b/developer/xos-intro.md
new file mode 100644
index 0000000..5249f3f
--- /dev/null
+++ b/developer/xos-intro.md
@@ -0,0 +1,20 @@
+# Modeling Services
+
+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 a tool that CORD uses to implement this
+control plane. For an overview of XOS, see the following white paper:
+[XOS: Modeling-as-a-Service](https://wiki.opencord.org/display/CORD/XOS+and+the+CORD+Controller?preview=/1279317/4981376/XOS%20Modeling-as-a-Service.pdf).
+
+XOS is a self-contained component of CORD, with its own
+[Guide](https://guide.xosproject.org). Consult this Guide to learn how
+to [use XOS](https://guide.xosproject.org/use.html) to write models
+and synchronizers for CORD services. The Guide also describes how
+to [install XOS](https://guide.xosproject.org/install.html) as a
+stand-alone platform, which can be useful when developing models
+and synchronizers.
+
+
+
+
+
diff --git a/images/cord.ico b/images/cord.ico
new file mode 100644
index 0000000..1322921
--- /dev/null
+++ b/images/cord.ico
Binary files differ
diff --git a/images/layers.png b/images/layers.png
new file mode 100644
index 0000000..4df9160
--- /dev/null
+++ b/images/layers.png
Binary files differ
diff --git a/navigate.md b/navigate.md
index 0a6db80..2acf404 100644
--- a/navigate.md
+++ b/navigate.md
@@ -1,5 +1,37 @@
# Navigating CORD
+## Assembled in Layers
+
+A given instance of CORD is constructed from a set of disaggregated
+components. This assembly is done according to the general pattern
+shown in the following conceptual diagram.
+
+
+
+The three layers are:
+
+* **Platform:** The bottom-most layer consists of ONOS, XOS,
+ Kafka, and collection of Logging and Monitoring micro-services,
+ all running on a Kubernetes foundation (not shown). This is the
+ starting point for all configurations of CORD.
+
+* **Profile:** The middle layer typically consists of a set of
+ services (e.g., access services, VNFs, other cloud services). These
+ components run on the underlying platform, and includes both
+ abstract services on-boarded into XOS and SDN control apps running
+ on ONOS.
+
+* **Workflows:** The top-most layer consists of one or more
+ workflows, each of which defines the business logic and state
+ machine for one of the access technologies included in the
+ profile. A workflow augments/parameterizes a profile for the target
+ deployment environment; it's not a software layer, per se.
+
+The diagram also shows a hardware bill-of-materials, which must be
+defined for a given POD.
+
+## Operationalized in Stages
+
Understanding the relationship between installing, operating, and developing
CORD—and the corresponding toolsets and specification files used by
each stage—is helpful in navigating CORD.
diff --git a/offline-install.md b/offline-install.md
index 9026e93..dc209ef 100644
--- a/offline-install.md
+++ b/offline-install.md
@@ -1,4 +1,4 @@
-# Offline installation
+# Offline Install
Often, CORD PODs' (management networks) don't have access to Internet.
diff --git a/operating_cord/api.md b/operating_cord/api.md
new file mode 100644
index 0000000..9d98092
--- /dev/null
+++ b/operating_cord/api.md
@@ -0,0 +1,22 @@
+# APIs
+
+This section describes workflows for interacting with the API of the
+CORD. There are multiple APIs. Some of them are used in a
+Northbound context, for services sitting on top the CORD, and some are
+used internally for components to communicate with each other.
+
+* [gRPC](/xos/dev/grpc_api.md). The gRPC API is used internally for
+ synchronizers and for Chameleon to speak with the XOS core. It's
+ also available as a Northbound API.
+
+* [REST](/operating_cord/rest_apis.md). The REST API is implemented by
+ the Chameleon container. In addition to being a popular Northbound
+ API, it's also used by the XOS GUI.
+
+* [TOSCA](/xos-tosca/README.md). TOSCA is implemented by the
+ xos-tosca container and is typically used to configure and provision
+ a POD. The following two references describe how to use TOSCA to
+ configure Profiles and Services, respectively:
+
+ * [Configuring Profiles](../profiles/intro.md)
+ * [Configuring Services](../operating_cord/services.md)
diff --git a/operating_cord/diag.md b/operating_cord/diag.md
index 947b342..6f45f4c 100644
--- a/operating_cord/diag.md
+++ b/operating_cord/diag.md
@@ -1 +1,5 @@
-# Diagnostics
+# Monitoring and Logging
+
+CORD is usually configured with monitoring and logging capabilities,
+built around Prometheus and ELK Stack, respectively. Both work on
+events/logs posted to Kafka and display results on a Kibana dashboard.
diff --git a/operating_cord/elk_stack.md b/operating_cord/elk_stack.md
index a2d45d6..f0aeea4 100644
--- a/operating_cord/elk_stack.md
+++ b/operating_cord/elk_stack.md
@@ -1,4 +1,4 @@
-# Diagnostics
+# ELK Stack
CORD uses ELK Stack for logging information at all levels. CORD’s ELK Stack
logger collects information from several components, including the XOS Core,
diff --git a/operating_cord/general.md b/operating_cord/general.md
index 10a7ec4..560e8aa 100644
--- a/operating_cord/general.md
+++ b/operating_cord/general.md
@@ -1,9 +1,11 @@
# General Info
-This section of the guide describes tools for interacting with CORD. These tools generally interact with
-CORD over a variety of APIs that are described [here](/api/api.md). Most notably:
+This section of the guide describes tools for interacting with CORD.
+These tools generally interact with CORD over a variety of APIs that
+are described [here](api.md). Most notably:
* A graphical interface is documented [here](gui.md).
-* A text shell, [XOSSH](/xos/dev/xossh.md), can be used to operate on objects in the CORD data model.
+* A text shell, [XOSSH](/xos/dev/xossh.md), can be used to operate on
+ objects in the CORD data model.
diff --git a/operating_cord/operating_cord.md b/operating_cord/operating_cord.md
index 5de08ea..a78f5c8 100644
--- a/operating_cord/operating_cord.md
+++ b/operating_cord/operating_cord.md
@@ -1,14 +1,18 @@
# Operations Guide
-This guide defines various processes and procedures for operating a
-CORD POD. It assumes the [install](../README.md) is already
-complete, and you want to operate and manage a running POD.
+This guide defines various processes, procedures, and tools for
+operating a CORD POD. It assumes the [install](../README.md) is
+already complete, and you want to operate and manage a running POD.
-Today, CORD most often runs for demo, development, or evaluation
-purposes, so this guide is limited to simple procedures suitable for
-such settings. We expect more realistic operational scenarios will be
-supported in the future.
+Note that the first step in operating a POD is to provision and configure
+the set of *Services* included in the selected *Profile*. Configuration
+details are specified in the follow two References:
+* [Configuring Profiles](../profiles/intro.md)
+* [Configuring Services](services.md)
+
+Default configurations are currently loaded into the POD at
+installation time.
diff --git a/operating_cord/prometheus.md b/operating_cord/prometheus.md
new file mode 100644
index 0000000..c387479
--- /dev/null
+++ b/operating_cord/prometheus.md
@@ -0,0 +1,3 @@
+# Prometheus
+
+This is a placeholder for information on monitoring...
diff --git a/operating_cord/services.md b/operating_cord/services.md
index ded5c92..d8780d9 100644
--- a/operating_cord/services.md
+++ b/operating_cord/services.md
@@ -1,7 +1,7 @@
-# Configuring Services
+# Service Reference
-This sections contains detailed instructions about how to configure
-individual services. Among other things, it describes what services
-depend on, which is particularly useful in case you want to create
-your own service graph. As with profiles, services are typically
-configured using a TOSCA workflow.
+Each release of CORD includes a collection of services, some of which
+are considered *platform services* (i.e., configured into all profiles) and
+some of which are *profile-specific*. The following documents the
+available services, specifying how each is modeled using `xproto`, and
+how each is configured and provisioned using TOSCA.
diff --git a/operating_cord/xos_internals.md b/operating_cord/xos_internals.md
index 735e69d..03bceef 100644
--- a/operating_cord/xos_internals.md
+++ b/operating_cord/xos_internals.md
@@ -2,13 +2,9 @@
XOS is the component of CORD that implements the control plane
through which operators control and manage CORD. This normally
-happens through a set of XOS-generated interfaces:
-
-* [TOSCA](../xos-tosca/README.md)
-* [REST API](rest_apis.md)
-* [XOSSH](../xos/dev/xossh.md)
+happens through a set of XOS-generated [APIs](api.md).
This section describes XOS internals, including how it is configured and
deployed on a running POD. Additional information about how to write
XOS models (from which these interfaces are generated) is
-described [elsewhere](../xos/README.md) in thie guide.
+described a separate [XOS Guide](https://guide.xosproject.org).
diff --git a/overview.md b/overview.md
index c6a67da..ce3e3aa 100644
--- a/overview.md
+++ b/overview.md
@@ -1,7 +1,14 @@
# CORD Guide
-This is a curated set of guides that describe how to install, operate, test,
-and develop [CORD](https://opencord.org).
+This is a curated set of documents that describe how to install, operate, test,
+and develop [CORD](https://www.opennetworking.org/cord/).
+The material is organized in two parts:
+
+* *Guides:* Outlines the process of installing, operating, testing and
+ developing for CORD as a whole.
+
+* *References:* Definitions and specifications about individual
+ components that make up CORD.
CORD is a community-based open source project. In addition to this guide, you
can find information about this community, its projects, and its governance on
@@ -9,9 +16,9 @@
and design notes that have shaped [CORD's
architecture](https://wiki.opencord.org/display/CORD/Documentation).
-## Navigating the Guide
+## Navigating the Guides
-The guide is organized around the major stages in the lifecycle of CORD:
+The guides are organized around the major stages in the lifecycle of CORD:
* [Installation](README.md): Installing (and later upgrading) CORD.
* [Operations](operating_cord/operating_cord.md): Operating an already
@@ -24,7 +31,24 @@
These are all fairly obvious. What's less obvious is the relationship among
these stages, which is helpful in [Navigating CORD](navigate.md).
-## Making Changes to the Guide
+## Navigating the References
+
+CORD is built from components and the aggregation of components into a
+coherent solution. The References are organized accordingly:
+
+* [Profile Reference](profiles/intro.md): Installation and
+ configuation details for specific solutions built using CORD
+ components.
+* [Service Reference](operating_cord/services.md): Configuration
+ (TOSCA) and modeling (xproto) definitions for individual CORD
+ components.
+* [Helm Refernce](charts/helm.md): Helm charts used to install
+ individual CORD components.
+
+For more information on the relationship between Profiles and
+Services, see [Navigating CORD](navigate.md).
+
+## Making Changes to this Document
The [http://guide.opencord.org](http://guide.opencord.org) website is built
using the [GitBook Toolchain](https://toolchain.gitbook.com/), with the
diff --git a/platform.md b/platform.md
new file mode 100644
index 0000000..46b4851
--- /dev/null
+++ b/platform.md
@@ -0,0 +1,24 @@
+# Install Platform
+
+Once the prerequisites have been met, the next step to installing CORD is
+to bring up the Helm charts for the platform components. This includes the
+following steps:
+
+## Install ONOS
+
+Install [onos](./charts/onos.md#onos-manages-fabric--voltha).
+It will manage the fabric infrastructure.
+
+## Install XOS
+
+Install [xos-core](./charts/xos-core.md). It will orchestrate the services.
+
+## Install Kafka
+
+Install [cord-kafka](./charts/kafka.md). It will implement a shared
+message bus.
+
+## Install Logging and Monitoring
+
+Install [loggin-monitoring](./charts/logging-monitoring.md). Log and monitor
+events in the POD.
diff --git a/profiles.md b/profiles.md
new file mode 100644
index 0000000..16e47a9
--- /dev/null
+++ b/profiles.md
@@ -0,0 +1,4 @@
+# Install Profile
+
+Once the [platform](platform.md) is installed, you are ready to bring up one
+of the available [profiles](profiles/intro.md).
diff --git a/profiles/intro.md b/profiles/intro.md
index 37646b3..5c049ee 100644
--- a/profiles/intro.md
+++ b/profiles/intro.md
@@ -1,7 +1,7 @@
-# Bringing Up CORD
+# Profile Reference
CORD is a general-purpose platform that is able to run one or more
-profiles, each of which includes some access technology (e.g., OLT,
+*profiles*, each of which includes some access technology (e.g., OLT,
RAN) and some collection of services (called a service graph or
service mesh).
diff --git a/profiles/mcord/README.md b/profiles/mcord/README.md
new file mode 100644
index 0000000..ac0281f
--- /dev/null
+++ b/profiles/mcord/README.md
@@ -0,0 +1,5 @@
+# M-CORD Profile
+
+M-CORD is supported in 6.0 and will be supported again in 7.0, but it
+is not currently available as part of 6.1.
+
diff --git a/profiles/mcord/install.md b/profiles/mcord/install.md
index bf842b4..81018af 100644
--- a/profiles/mcord/install.md
+++ b/profiles/mcord/install.md
@@ -1,4 +1,4 @@
-# M-CORD
+# Install M-CORD Charts
> **Note**: Currently the M-CORD is under maintenance.
> Check the link below for more information:
diff --git a/profiles/seba/README.md b/profiles/seba/README.md
new file mode 100644
index 0000000..a23023d
--- /dev/null
+++ b/profiles/seba/README.md
@@ -0,0 +1,8 @@
+# SEBA Profile
+
+SEBA (Software-Enabled Broadband Access) is a lightweight profile that
+supports white-box OLT devices.
+[Click here for a high-level overview.](https://www.opennetworking.org/seba/).
+
+The following pages describe how to install SEBA with some workload,
+and how to configure an installed SEBA POD.
diff --git a/profiles/seba/bbsim.md b/profiles/seba/bbsim.md
new file mode 100644
index 0000000..12f8e67
--- /dev/null
+++ b/profiles/seba/bbsim.md
@@ -0,0 +1,33 @@
+# Scale testing using BBSim
+
+Broadband Simulator (BBSim) is a control-plane only simulator that is used to
+test the sistem at scale.
+
+You can run BBSim on top of any SEBA installation, for instructions on how to
+install it you can refer to the [bbsim](../../charts/bbsim.md) helm reference.
+
+## System configurations that affects BBSim
+
+The most important detail that determine how BBSim will behave is the DHCP
+configuration.
+
+There are two options:
+
+- sending packets out of the switch
+- sending packets back to the OLT
+
+### DHCP Packets through the aggregation switch
+
+This is the way a physical POD is set up to work. If you decide to follow this
+route no changes are required in the configuration but you'll need to make sure
+your DHCP server is configured to assign IP Addresses to subscriber requesting
+them with `S-Tag` set as `999` and `C-Tag` starting from `900` for the first
+subscriber and increasing by one for each subscriber.
+
+### DHCP Packets back to the OLT
+
+If you don't have a DHCP server configured accordingly you can use the DHCP server
+that runs inside BBSim itself. To do that you need to send the DHCP Packets
+back to the OLT.
+
+To do that you can use this TOSCA recipe: <https://github.com/opencord/helm-charts/blob/master/examples/bbsim-dhcp.yaml>
\ No newline at end of file
diff --git a/profiles/seba/celestica-olt-setup.md b/profiles/seba/celestica-olt-setup.md
new file mode 100644
index 0000000..cab0435
--- /dev/null
+++ b/profiles/seba/celestica-olt-setup.md
@@ -0,0 +1,68 @@
+# Celestica OLT setup
+
+Celestica provides a GPON based OLT device that can work with Voltha and CORD.
+The OLT (also known as Microsemi OLT) model is called *CLS Ruby S1010*. For more info on the hardware models and the supported optics, look at the [recommended hardware page](../../prereqs/hardware.md#recommended-hardware).
+
+The following guide explains how to integrate the Celestica OLT with Voltha, and more in general with CORD.
+
+## OLT hardware notes and ports configuration
+
+The OLT has two lines of ports. Upper ports are master ports and should be used first. Lower ports act as backup ports for the upper ports.
+The OLT has 48 UNI ports (24 master, and 24 backups) and 6 NNI ports (3 master, and 3 backups).
+The UNI ports are divided in three PON groups. Each PON group is associated to an NNI port. The most right NNI port group is used for the most left PON group, and so on.
+Each PON group is divided in 4 PONs (each with four PON ports - the two upper, master, and the two lower, backup). Each port can support up to 32 connections.
+Each PON (each couple of vertically grouped ports, one master, one backup) will appear as a different OLT device in Voltha.
+
+## How to manage the OLT (access the CLI)
+
+As far as we know, the out-of-band OLT management port is disabled by default, and the OLT can be managed -including by Voltha- only in-band.
+Also, the OLT is managed as a L2 device by Voltha. As such, no IP addresses can be assigned to the OLT. The OLT doesn't need any specific configuration. Anyway, you may need to access the CLI for debug purposes. The CLI can be accessed from the console port for debugging.
+
+## OLT pre-installed software notes
+
+The Celestica box should come with ONIE and its own OS pre-installed. No additional configurations are required.
+
+## Get the OLTs MAC addresses
+
+The MAC addresses of the OLTs are needed to perform a successful Voltha configuration. To get the OLT MAC address, from the OLT CLI type:
+
+```shell
+/voltapp/onie-syseeprom
+```
+
+The command will only show the MAC address of the first OLT (first couple of ports from the left). To know the MAC addresses of the other OLTs, add 1 to the first MAC address, for each couple of next ports. For example, the MAC address of the second OLT (the second couple of vertical ports from the left) will be the MAC address returned by the command above plus 1.
+
+## Discover the OLT in Voltha
+
+Once the MAC address is known, pre-provision the OLT from Voltha
+
+```shell
+preprovision_olt --device-type=microsemi_olt --mac-address=11:22:33:44:55:66
+```
+
+where *11:22:33:44:55:66* is the MAC address of your OLT device.
+
+Then, enable the OLT, typing
+
+```shell
+enable
+```
+
+Voltha will start to send L2 packets to the OLT, until it gets discovered.
+
+> **NOTE:** at the moment, the microsemi_olt adapter sends only few packets to the OLT box after the *enable* command has been input. Recently, a *reboot* command has been added for this adapter. The command restarts the provisioning process.
+
+## Celestica OLT and R-CORD
+
+As said, the Celestica OLT can be used with Voltha, so in principle with R-CORD as well. At the moment, this requires some additional configuration to allow the in-band management communication between Voltha and the OLT.
+
+As in-band communication is done by L2 MAC address, the NNI port of OLT needs to have a L2 connection with Voltha.
+
+More specifically, in a typical CORD deployment Voltha runs as a set of container managed by k8s, which in turn runs on a (physical or virtual) machine. This machine is usually connected to the management network only. In a deployment using Celestica boxes instead, the server running Voltha will need to have an extra connection to the data plane (usually the CORD fabric switches).
+
+Of course, also the OLT NNI port needs to be connected as well to the same fabric switch.
+If both the OLT and the server running Voltha are connected to the same fabric switch, a path needs to be provisioned between the two. This can be achieved -for example- in the CORD fabric using Trellis, through the configuration of a VLAN cross-connect or a pseudo-wire.
+
+Further more, the Voltha vcore container (called voltha in the Kubernetes based deployment) should be connected to the data plane port, connected to the OLT, which is a quite trivial but manual operation. The steps to connect containers and server ports can be found in the [veth interface configuration guide](../../operating_cord/veth_intf.md).
+
+> **NOTE:** the Celestica OLT is known to work *only* with the top-down R-CORD configuration workflow.
diff --git a/profiles/seba/configuration.md b/profiles/seba/configuration.md
new file mode 100644
index 0000000..8a2a271
--- /dev/null
+++ b/profiles/seba/configuration.md
@@ -0,0 +1,225 @@
+# SEBA Configuration
+
+Once all the components needed for the SEBA profile are up and
+running on your POD, you will need to configure it. This is typically
+done using TOSCA. This configuration is environment specific, so
+you will need to create your own, but the following can serve as a
+reference:
+
+```yaml
+tosca_definitions_version: tosca_simple_yaml_1_0
+imports:
+ - custom_types/oltdevice.yaml
+ - custom_types/switch.yaml
+ - custom_types/switchport.yaml
+ - custom_types/portinterface.yaml
+ - custom_types/voltservice.yaml
+ - custom_types/vrouterserviceinstance.yaml
+ - custom_types/vrouterstaticroute.yaml
+
+description: Configures a full SEBA POD
+
+topology_template:
+ node_templates:
+ # Fabric configuration
+ switch#my_fabric_switch:
+ type: tosca.nodes.Switch
+ properties:
+ driver: ofdpa3
+ ipv4Loopback: 192.168.0.201
+ ipv4NodeSid: 17
+ isEdgeRouter: True
+ name: my_fabric_switch
+ ofId: of:0000000000000001
+ routerMac: 00:00:02:01:06:01
+
+ # Setup the OLT switch port
+ port#olt_port:
+ type: tosca.nodes.SwitchPort
+ properties:
+ portId: 1
+ host_learning: false
+ requirements:
+ - switch:
+ node: switch#my_fabric_switch
+ relationship: tosca.relationships.BelongsToOne
+
+ # Setup the OLT switch port interface
+ interface#olt_interface:
+ type: tosca.nodes.PortInterface
+ properties:
+ ips: 192.168.0.254/24
+ name: olt_interface
+ requirements:
+ - port:
+ node: port#olt_port
+ relationship: tosca.relationships.BelongsToOne
+
+ # Setup the fabric switch port where the external
+ # router is connected to
+ port#vrouter_port:
+ type: tosca.nodes.SwitchPort
+ properties:
+ portId: 31
+ requirements:
+ - switch:
+ node: switch#my_fabric_switch
+ relationship: tosca.relationships.BelongsToOne
+
+ # Setup the fabric switch port interface where the
+ # external router is connected to
+ interface#vrouter_interface:
+ type: tosca.nodes.PortInterface
+ properties:
+ name: vrouter_interface
+ vlanUntagged: 40
+ ips: 10.231.254.2/29
+ requirements:
+ - port:
+ node: port#vrouter_port
+ relationship: tosca.relationships.BelongsToOne
+
+ # Add a vRouter (ONOS)
+ vrouter#my_vrouter:
+ type: tosca.nodes.VRouterServiceInstance
+ properties:
+ name: my_vrouter
+
+ # Add a static route to the vRouter (ONOS)
+ route#my_route:
+ type: tosca.nodes.VRouterStaticRoute
+ properties:
+ prefix: "0.0.0.0/0"
+ next_hop: "10.231.254.1"
+ requirements:
+ - vrouter:
+ node: vrouter#my_vrouter
+ relationship: tosca.relationships.BelongsToOne
+
+ # Setup the OLT service
+ service#volt:
+ type: tosca.nodes.VOLTService
+ properties:
+ name: volt
+ must-exist: true
+
+ # Setup the OLT device
+ olt_device:
+ type: tosca.nodes.OLTDevice
+ properties:
+ name: volt-1
+ device_type: openolt
+ host: 10.90.0.114
+ port: 9191
+ switch_datapath_id: of:0000000000000001
+ switch_port: "1"
+ outer_tpid: "0x8100"
+ uplink: "128"
+ requirements:
+ - volt_service:
+ node: service#volt
+ relationship: tosca.relationships.BelongsToOne
+```
+
+For instructions on how to push TOSCA into a CORD POD, please
+refer to this [guide](../../xos-tosca/README.md).
+
+## Top-Down Subscriber Provisioning
+
+Once the POD has been configured, you can create a subscriber. This
+section describes a "top-down" approach for doing that. (The following
+section describes an alternative, "bottom up" approach.)
+
+To create a subscriber, you need to retrieve some information:
+
+- ONU Serial Number
+- Mac Address
+- IP Address
+
+### Find ONU Serial Number
+
+Once your POD is set up and the OLT has been pushed and activated in VOLTHA,
+XOS will discover the ONUs available in the system.
+
+You can find them through:
+
+- XOS GUI: on the left side click on `vOLT > ONUDevices`
+- XOS Rest API: `http://<pod-id>:<chameleon-port|30006>/xosapi/v1/volt/onudevices`
+- VOLTHA CLI: [Command Line Interface](../../charts/voltha.md#how-to-access-the-voltha-cli)
+
+If you are connected to the VOLTHA CLI you can use the following
+command to list all the existing devices:
+
+```shell
+(voltha) devices
+Devices:
++------------------+--------------+------+------------------+-------------+-------------+----------------+----------------+------------------+----------+-------------------------+----------------------+------------------------------+
+| id | type | root | parent_id | admin_state | oper_status | connect_status | parent_port_no | host_and_port | vendor_id| proxy_address.device_id | proxy_address.onu_id | proxy_address.onu_session_id |
++------------------+--------------+------+------------------+-------------+-------------+----------------+----------------+------------------+----------+-------------------------+----------------------+------------------------------+
+| 0001941bd45e71d8 | openolt | True | 000100000a5a0072 | ENABLED | ACTIVE | REACHABLE | | 10.90.0.114:9191 | | | | |
+| 00015698e67dc060 | broadcom_onu | True | 0001941bd45e71d8 | ENABLED | ACTIVE | REACHABLE | 536870912 | | BRCM| 0001941bd45e71d8 | 1 | 1 |
++------------------+--------------+------+------------------+-------------+-------------+----------------+----------------+------------------+----------+-------------------------+----------------------+------------------------------+
+```
+
+Locate the correct ONU, then:
+
+```shell
+(voltha) device 00015698e67dc060
+(device 00015698e67dc060) show
+Device 00015698e67dc060
++------------------------------+------------------+
+| field | value |
++------------------------------+------------------+
+| id | 00015698e67dc060 |
+| type | broadcom_onu |
+| root | True |
+| parent_id | 0001941bd45e71d8 |
+| vendor | Broadcom |
+| model | n/a |
+| hardware_version | to be filled |
+| firmware_version | to be filled |
+| images.image | 1 item(s) |
+| serial_number | BRCM22222222 |
++------------------------------+------------------+
+| adapter | broadcom_onu |
+| admin_state | 3 |
+| oper_status | 4 |
+| connect_status | 2 |
+| proxy_address.device_id | 0001941bd45e71d8 |
+| proxy_address.onu_id | 1 |
+| proxy_address.onu_session_id | 1 |
+| parent_port_no | 536870912 |
+| vendor_id | BRCM |
+| ports | 2 item(s) |
++------------------------------+------------------+
+| flows.items | 5 item(s) |
++------------------------------+------------------+
+```
+
+to find the correct serial number.
+
+### Push a Subscriber into CORD
+
+Once you have this information, you can create the subscriber by
+customizing the following TOSCA and passing it into the POD:
+
+```yaml
+tosca_definitions_version: tosca_simple_yaml_1_0
+imports:
+ - custom_types/rcordsubscriber.yaml
+description: Create a test subscriber
+topology_template:
+ node_templates:
+ # A subscriber
+ my_house:
+ type: tosca.nodes.RCORDSubscriber
+ properties:
+ name: My House
+ c_tag: 111
+ onu_device: BRCM1234 # Serial Number of the ONU Device to which this subscriber is connected
+ mac_address: 00:AA:00:00:00:01 # subscriber mac address
+ ip_address: 10.8.2.1 # subscriber IP
+```
+
+For instructions on how to push TOSCA into a CORD POD, please
+refer to this [guide](../../xos-tosca/README.md).
diff --git a/profiles/seba/install.md b/profiles/seba/install.md
index 212157d..f37dcbc 100644
--- a/profiles/seba/install.md
+++ b/profiles/seba/install.md
@@ -1,6 +1,15 @@
-# SEBA Profile
+# Install SEBA Charts
-SEBA is a lightweight platform based on a variant of R-CORD.
-[Click here for a high-level overview.](https://www.opennetworking.org/seba/)
+This page walks through the sequence of Helm operations needed to
+bring up the SEBA profile. It assumes the Platform has already been
+installed.
-Quick start: [SEBA-in-a-Box](siab.md)
+## Install VOLTHA
+
+Install [voltha](../../charts/voltha.md).
+It will manage the OLT devices.
+
+## Install Seba-Services
+
+Install [seba-services](../../charts/seba-services.md).
+This will run all the XOS services necessary to manage the data plane.
diff --git a/profiles/rcord/workflows/att.md b/profiles/seba/workflows/att.md
similarity index 100%
rename from profiles/rcord/workflows/att.md
rename to profiles/seba/workflows/att.md
diff --git a/quickstart.md b/quickstart.md
index bf1354d..544963d 100644
--- a/quickstart.md
+++ b/quickstart.md
@@ -1,13 +1,14 @@
# Quick Start
This section walks you through an example installation sequence on two
-different platforms. If you'd prefer to understand the installation
-process in more depth, including the full range of deployment options,
-you might start with the [Installation Guide](README.md) instead.
+different Unix-based platforms. This is just a surface introduction to
+CORD. If you'd prefer to understand the installation process in more
+depth, including the full range of deployment options, you should
+start with the [Installation Guide](README.md) instead.
-This Quick Start describes how to install the R-CORD profile, plus a
-`SimpleExampleService`, on a single machine. Once you complete these
-steps, you might be interested in jumping ahead to the
+This Quick Start describes how to install a subset of the CORD
+platform, plus a `SimpleExampleService`, on a single machine. Once you
+complete these steps, you might be interested in jumping ahead to the
[SimpleExampleService Tutorial](simpleexampleservice/simple-example-service.md)
to learn more about the make-up of a CORD service. Another option
would be to explore CORD's [operational interfaces](operating_cord/general.md).
