- To an optical network: The port maybe *abstract*, yet the optical
wavelength is *concrete*.
- **Note**
+.. note::
*This is a very domain specific analogy, tied to something most
readers will understand. It in no way implies the **GBP** should be
It is important to show the overall philosophy of **GBP** as it sets the
project’s direction.
-In the Beryllium release of OpenDaylight, **GBP** focused on **expressed
+In this release of OpenDaylight, **GBP** focused on **expressed
intent**, **refactoring of how renderers consume and publish Subject
Feature Definitions for multi-renderer support**.
resolution process.
.. figure:: ./images/groupbasedpolicy/GBPTerminology1.png
- :alt: GBP Access Model Terminology - Endpoints, EndpointGroups,
- Contract
+ :alt: GBP Access Model Terminology - Endpoints, EndpointGroups, Contract
GBP Access Model Terminology - Endpoints, EndpointGroups, Contract
GBP Access Model Terminology - Subject, Classifier, Action
.. figure:: ./images/groupbasedpolicy/GBPTerminology3.png
- :alt: GBP Forwarding Model Terminology - L3 Context, L2 Bridge
- Context, L2 Flood Context/Domain, Subnet
+ :alt: GBP Forwarding Model Terminology - L3 Context, L2 Bridge Context, L2 Flood Context/Domain, Subnet
GBP Forwarding Model Terminology - L3 Context, L2 Bridge Context, L2
Flood Context/Domain, Subnet
- Endpoints:
- Define concrete uniquely identifiable entities. In Beryllium,
+ Define concrete uniquely identifiable entities. In this release,
examples could be a Docker container, or a Neutron port
- EndpointGroups:
Architecture and Value Proposition
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-**GBP** offers an intent based interface, accessed via the `UX <#UX>`__,
+**GBP** offers an intent based interface, accessed via the :ref:`UX <gbp-ux>`,
via the `REST API <#REST>`__ or directly from a domain-specific-language
-such as `Neutron <#Neutron>`__ through a mapping interface.
+such as :ref:`Neutron <gbp-neutron>` through a mapping interface.
There are two models in **GBP**:
The *classifier* and *action* portions of the model can be thought of as
hooks, with their definition provided by each *renderer* about its
-domain specific capabilities. In **GBP** Beryllium, there is one
-renderer, the *`OpenFlow Overlay renderer (OfOverlay). <#OfOverlay>`__*
+domain specific capabilities. In **GBP** for this release, there is one
+renderer, the :ref:`OpenFlow Overlay renderer (OfOverlay). <gbp-of-overlay>`
These hooks are filled with *definitions* of the types of *features* the
renderer can provide the *subject*, and are called
High-level implementation Architecture
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-The overall architecture, including *`Neutron <#Neutron>`__* domain
-specific mapping, and the `OpenFlow Overlay renderer <#OfOverlay>`__
+The overall architecture, including :ref:`Neutron <gbp-neutron>` domain
+specific mapping, and the :ref:`OpenFlow Overlay renderer <gbp-of-overlay>`
looks as so:
.. figure:: ./images/groupbasedpolicy/GBP_High-levelBerylliumArchitecture.png
- :alt: GBP High Level Beryllium Architecture
+ :alt: GBP High Level Architecture
- GBP High Level Beryllium Architecture
+ GBP High Level Architecture
The major benefit of this architecture is that the mapping of the
domain-specific-language is completely separate and independent of the
underlying renderer implementation.
-For instance, using the `Neutron Mapper <#Neutron>`__, which maps the
+For instance, using the :ref:`Neutron Mapper <gbp-neutron>`, which maps the
Neutron API to the **GBP** core model, any contract automatically
-generated from this mapping can be augmented via the `UX <#UX>`__ to use
-`Service Function Chaining <#SFC>`__, a capability not currently
+generated from this mapping can be augmented via the :ref:`UX <gbp-ux>` to use
+:ref:`Service Function Chaining <gbp-sfc>`, a capability not currently
available in OpenStack Neutron.
When another renderer is added, for instance, NetConf, the same policy
can now be leveraged across NetConf devices simultaneously:
.. figure:: ./images/groupbasedpolicy/GBP_High-levelExtraRenderer.png
- :alt: GBP High Level Beryllium Architecture - adding a renderer
+ :alt: GBP High Level Architecture - adding a renderer
- GBP High Level Beryllium Architecture - adding a renderer
+ GBP High Level Architecture - adding a renderer
As other domain-specific mappings occur, they too can leverage the same
renderers, as the renderers only need to implement the **GBP** access
mapping to the access and forwarding models. For instance:
.. figure:: ./images/groupbasedpolicy/High-levelBerylliumArchitectureEvolution2.png
- :alt: GBP High Level Beryllium Architecture - adding a renderer
+ :alt: GBP High Level Architecture - adding a renderer
- GBP High Level Beryllium Architecture - adding a renderer
+ GBP High Level Architecture - adding a renderer
In summary, the **GBP** architecture:
- Consumer Endpoint Identification Constraint
- Label based criteria for matching against endpoints. In Beryllium
+ Label based criteria for matching against endpoints. In this release
this can be used to label endpoints based on IpPrefix.
The second category is the provider matchers, which match against the
- Consumer Endpoint Identification Constraint
- Label based criteria for matching against endpoints. In Beryllium
+ Label based criteria for matching against endpoints. In this release
this can be used to label endpoints based on IpPrefix.
Clauses have a list of subjects that apply when all the matchers in the
particular cookie. Actions are specific actions that need to be taken on
the traffic before it reaches its destination. Actions could include
tagging or encapsulating the traffic in some way, redirecting the
-traffic, or applying a `service function chain <#SFC>`__.
+traffic, or applying a :ref:`service function chain <gbp-sfc>`.
Rules, subjects, and actions have an *order* parameter, where a lower
order value means that a particular item will be applied first. All
purpose of matching. Otherwise, the label with the same name will
completely override the label from the parent.
+.. _gbp-ux:
+
Using the GBP UX interface
--------------------------
Below the select box are buttons which display Expressed or Delivered
policy of Governance section. In the bottom half of this section is
select box with list of renderers for select. There is currently only
-`OfOverlay <#OfOverlay>`__ renderer available.
+:ref:`OfOverlay <gbp-of-overlay>` renderer available.
Below the select box is Renderer configuration button, which switch the
app into the Policy expression view with Renderers section expanded for
By single-clicking on any contract or EPG, the data of actual selected
element will be shown in the right column below the menu. A Manage
button launches a display wizard window for managing configuration of
-items such as `Service Function Chaining <#SFC>`__.
+items such as :ref:`Service Function Chaining <gbp-sfc>`.
.. figure:: ./images/groupbasedpolicy/ui-3-governanceview-expressed.png
:alt: Expressed policy
Please see:
-- `Using the GBP OpenFlow Overlay (OfOverlay) renderer <#OfOverlay>`__
+- :ref:`gbp-of-overlay`
-- `Policy Resolution <#policyresolution>`__
+- `Policy Resolution`_
- `Forwarding Model <#forwarding>`__
It is recommended to use either:
-- `Neutron mapper <#Neutron>`__
+- `Neutron mapper <gbp-neutron>`
-- `the UX <#UX>`__
+- :ref:`the UX <gbp-ux>`
If the REST API must be used, and the above resources are not
sufficient:
- feature:install odl-dlux-yangui
- browse to:
- `http://<odl-controller>:8181/index.html <http://<odl-controller>:8181/index.html>`__
+ ``http://<odl-controller>:8181/index.html``
and select YangUI from the left menu.
to explore the various **GBP** REST options
+.. _gbp-neutron:
+
Using OpenStack with GBP
------------------------
REST calls from OpenStack Neutron are by the Neutron NorthBound project.
**GBP** provides the implementation of the `Neutron V2.0
-API <http://developer.openstack.org/api-ref-networking-v2.html>`__.
+API <http://developer.openstack.org/api-ref-networking-v2.html>`_.
Features
~~~~~~~~
**Neutron FloatingIP**
When associated with a Neutron Port, this leverages the
-`OfOverlay <#OfOverlay>`__ renderer’s NAT capabilities.
+:ref:`OfOverlay <gbp-of-overlay>` renderer’s NAT capabilities.
A dedicated *external* interface on each Nova compute host allows for
disitributed external access. Each Nova instance associated with a
Assuming the gateway provisioned in the Neutron Subnet command for the
external network is reachable, the combination of **GBP** Neutron Mapper
-and `OfOverlay renderer <#OfOverlay>`__ will automatically ARP for this
+and :ref:`OfOverlay renderer <gbp-of-overlay>` will automatically ARP for this
default gateway, requiring no user intervention.
**Troubleshooting within GBP**
No intervention passed initial OpenStack setup is required by the user.
More information about configuration can be found in our DevStack demo
-environment on the `**GBP**
-wiki <https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)>`__.
+environment on the `GBP
+wiki <https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)>`_.
Administering or Managing GBP Neutron
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For consistencies sake, all provisioning should be performed via the
Neutron API. (CLI or Horizon).
-The mapped policies can be augmented via the **GBP** `UX <#UX>`__, to:
+The mapped policies can be augmented via the **GBP** :ref:`UX <gbp-ux>`, to:
-- Enable `Service Function Chaining <#SFC>`__
+- Enable :ref:`Service Function Chaining <gbp-sfc>`
- Add endpoints from outside of Neutron i.e. VMs/containers not
provisioned in OpenStack
Tutorials
~~~~~~~~~
-A DevStack demo environment can be found on the `**GBP**
-wiki <https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)>`__.
+A DevStack demo environment can be found on the `GBP
+wiki <https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)>`_.
+
+GBP Renderer manager
+--------------------
+
+Overview
+~~~~~~~~
+
+The GBP Renderer manager is an integral part of **GBP** base module.
+It dispatches information about endpoints'
+policy configuration to specific device renderer
+by writing a renderer policy configuration into the
+registered renderer's policy store.
+
+Installing and Pre-requisites
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Renderer manager is integrated into GBP base module,
+so no additional installation is required.
+
+Architecture
+~~~~~~~~~~~~
+
+Renderer manager gets data notifications about:
+
+- Endoints (base-endpoint.yang)
+
+- EndpointLocations (base-endpoint.yang)
+
+- ResolvedPolicies (resolved-policy.yang)
+
+- Forwarding (forwarding.yang)
+
+Based on data from notifications it creates a configuration task for
+specific renderers by writing a renderer policy configuration into the
+registered renderer's policy store.
+Configuration is stored to CONF data store as Renderers (renderer.yang).
+
+Configuration is signed with version number which is incremented by every change.
+All renderers are supposed to be on the same version. Renderer manager waits
+for all renderers to respond with version update in OPER data store.
+After a version of every renderer in OPER data store has the same value
+as the one in CONF data store,
+renderer manager moves to the next configuration with incremented version.
+
+GBP Location manager
+--------------------
+
+Overview
+~~~~~~~~
+
+Location manager monitors information about Endpoint Location providers
+(see endpoint-location-provider.yang) and manages Endpoint locations in OPER data store accordingly.
+
+Installing and Pre-requisites
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Location manager is integrated into GBP base module,
+so no additional installation is required.
+
+Architecture
+~~~~~~~~~~~~
+
+The endpoint-locations container in OPER data store (see base-endpoint.yang)
+contains two lists for two types of EP location,
+namely address-endpoint-location and containment-endpoint-location.
+LocationResolver is a class that processes Location providers in CONF data store
+and puts location information to OPER data store.
+
+When a new Location provider is created in CONF data store, its Address EP locations
+are being processed first, and their info is stored locally in accordance with processed
+Location provider's priority. Then a location of type "absolute" with the highest priority
+is selected for an EP, and is put in OPER data store. If Address EP locations contain
+locations of type "relative", those are put to OPER data store.
+
+If current Location provider contains Containment EP locations of type "relative",
+then those are put to OPER data store.
+
+Similarly, when a Location provider is deleted, information of its locations
+is removed from the OPER data store.
+
+.. _gbp-of-overlay:
Using the GBP OpenFlow Overlay (OfOverlay) renderer
---------------------------------------------------
This renderer is designed to work with OpenVSwitch (OVS) 2.1+ (although
2.3 is strongly recommended) and OpenFlow 1.3.
-When used in conjunction with the `Neutron Mapper feature <#Neutron>`__
+When used in conjunction with the :ref:`Neutron Mapper feature <gbp-neutron>`
no extra OfOverlay specific setup is required.
When this feature is loaded "standalone", the user is required to
- and creating the VXLAN/VXLAN-GPE tunnel ports on the bridges.
+.. _gbp-offset:
+
The **GBP** OfOverlay renderer also supports a table offset option, to
offset the pipeline post-table 0. The value of table offset is stored in
the config datastore and it may be rewritten at runtime.
Policy resolution is completely domain independent, and the OfOverlay
leverages process policy information internally. See `Policy Resolution
-process <#policyresolution>`__.
+process <Policy Resolution>`_.
It listens to inputs to the *Tenants* configuration datastore, validates
tenant input, then writes this to the Tenants operational datastore.
The endpoint repository operates in **orchestrated** mode. This means
the user is responsible for the provisioning of endpoints via:
-- `UX/GUI <#UX>`__
+- :ref:`UX/GUI <gbp-ux>`
- REST API
- **Note**
+.. note::
- When using the `Neutron mapper <#Neutron>`__ feature, everything is
+ When using the :ref:`Neutron mapper <gbp-neutron>` feature, everything is
managed transparently via Neutron.
The Endpoint Manager is responsible for listening to Endpoint repository
**Ingress NAT Mapper**
-Table `*offset* <#offset>`__\ +1.
+Table :ref:`offset <gbp-offset>` +1.
ARP responder for external NAT address:
**Source Mapper**
-Table `*offset* <#offset>`__\ +2.
+Table :ref:`offset <gbp-offset>` +2.
Determines based on characteristics from the ingress port, which:
**Destination Mapper**
-Table `*offset* <#offset>`__\ +3.
+Table :ref:`offset <gbp-offset>` +3.
Determines based on characteristics of the endpoint:
**Policy Enforcer**
-Table `*offset* <#offset>`__\ +4.
+Table :ref:`offset <gbp-offset>` +4.
Once the Source and Destination EndpointGroups are assigned, policy is
enforced based on resolved rules.
-In the case of `Service Function Chaining <#SFC>`__, the encapsulation
+In the case of :ref:`Service Function Chaining <gbp-sfc>`, the encapsulation
and destination for traffic destined to a chain, is discovered and
enforced.
**Egress NAT Mapper**
-Table `*offset* <#offset>`__\ +5.
+Table :ref:`offset <gbp-offset>` +5.
Performs NAT function before Egressing OVS instance to the underlay
network.
**External Mapper**
-Table `*offset* <#offset>`__\ +6.
+Table :ref:`offset <gbp-offset>` +6.
Manages post-policy enforcement for endpoint specific destination
-effects. Specifically for `Service Function Chaining <#SFC>`__, which is
+effects. Specifically for :ref:`Service Function Chaining <gbp-sfc>`, which is
why we can support both symmetric and asymmetric chains and distributed
ingress/egress classification.
Configuring OpenFlow Overlay via REST
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- **Note**
+.. note::
- Please see the `UX <#UX>`__ section on how to configure **GBP** via
+ Please see the :ref:`UX <gbp-ux>` section on how to configure **GBP** via
the GUI.
**Endpoint**
}
}
- **Note**
+.. note::
The usage of "port-name" preceded by "ofoverlay". In OpenDaylight,
base datastore objects can be *augmented*. In **GBP**, the base
}
}
-**Tenants** see `Policy Resolution <#policyresolution>`__ and
+**Tenants** see `Policy Resolution`_ and
`Forwarding Model <#forwarding>`__ for details:
::
~~~~~~~~~
Comprehensive tutorials, along with a demonstration environment
-leveraging Vagrant can be found on the `**GBP**
+leveraging Vagrant can be found on the `GBP
wiki <https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)>`__
Using the GBP eBPF IO Visor Agent renderer
feature:install odl-groupbasedpolicy-iovisor odl-restconf
Installation details, usage, and other information for the IO Visor GBP
-module can be found here: `**IO Visor** github repo for IO
-Modules <https://github.com/iovisor/iomodules>`__
+module can be found here: `IO Visor github repo for IO
+Modules <https://github.com/iovisor/iomodules>`_
Using the GBP FaaS renderer
---------------------------
More information about FaaS can be found here:
https://wiki.opendaylight.org/view/FaaS:GBPIntegration
+.. _gbp-sfc:
+
Using Service Function Chaining (SFC) with GBP Neutron Mapper and OfOverlay
---------------------------------------------------------------------------
This takes the form of an *action* in **GBP**.
-Using the `**GBP** demo and development environment <#demo>`__ as an
+Using the `GBP demo and development environment <#demo>`__ as an
example:
.. figure:: ./images/groupbasedpolicy/sfc-1-topology.png
Demo/Development environment
----------------------------
-The **GBP** project for Beryllium has two demo/development environments.
+The **GBP** project for this release has two demo/development environments.
- Docker based GBP and GBP+SFC integration Vagrant environment
- DevStack based GBP+Neutron integration Vagrant environment
`Demo @ GBP
-wiki <https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)/Consumability/Demo>`__
+wiki <https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)/Consumability/Demo>`_
Code Review / docs.git / blobdiff