Table of Contents
https://git.opendaylight.org/gerrit/#/q/topic:service-binding-on-tunnels
Service Binding On Tunnels Feature enables applications to bind multiple services on an ingress/egress tunnel.
Currently GENIUS does not provide a generic mechanism to support binding services on all interfaces.Ingress service binding pipeline is different for l2vlan interfaces and tunnel interfaces.Similarly, egress Service Binding is only supported for l2vlan interfaces.
Today when ingress services are bound on a tunnel, the highest priority service gets
bound in INTERFACE INGRESS TABLE(0)
itself, and remaining service entries get
populated in LPORT DISPATCHER TABLE(17)
, which is not in alignment with the service
binding logic for VM ports. As part of this feature, we enable ingress/egress service
binding support for tunnels in the same way as for VM interfaces. This feature also enables
service-binding based on a tunnel-type which is basically meant for optimizing the number
of flow entries in dispatcher tables.
This feature will support following use cases:
LPORT
DISPATCHER TABLE(17)
.Following use cases will not be supported:
The proposed change extends the current l2vlan service binding functionality to tunnel
interfaces. With this feature, multiple applications can bind their services on the same
tunnel interface, and traffic will be processed on an application priority basis.
Applications are given the flexibility to provide service specific actions while they
bind their services. Normally service binding actions include
go-to-service-pipeline-entry-table. Packets will enter a particular service based
on the service priority, and if the packet is not consumed by the service,
it is the application’s responsibility to resubmit the packet back to the egress/ingress
dispatcher table
for further processing by next priority service. Egress Dispatcher
Table will have a default service priority entry per tunnel interface to egress the
packet on the tunnel port.So, if there are no egress services bound on a tunnel interface,
this default entry will take care of taking the packet out of the switch.
The feature also enables service binding based on tunnel type. This way number of entries in Dispatcher Tables can be optimized if all the packets entering on tunnel of a particular type needs to be handled in the same way.
There is a pipeline change introduced as part of this feature for tunnel egress as well as ingress, and is captured in genius pipeline document patch [2].
With this feature, all traffic from INTERFACE_INGRESS_TABLE(0) will be dispatched to LPORT_DISPATCHER_TABLE(17), from where the packets will be dispatched to the respective applications on a priority basis.
Register6 will be used to set the ingress tunnel-type in Table0, and this can be used to match in Table17 to identify the respective applications bound on the tunnel-type. Remaining logic of ingress service binding will remain as is, and service-priority and interface-tag will be set in metadata as usual. The bits from 25-28 of Register6 will be used to indicate tunnel-type.
After the ingress service processing, packets which are identified to be egressed on tunnel interfaces, currently directly go to the tunnel port. With this feature, these packets will goto Egress Dispatcher Table[Table 220] first, where the packet will be processed by Egress Services on the tunnel interface one by one, and finally will egress the switch.
Register6 will be used to indicate service priority as well as interface tag for the egress tunnel interface, in Egress Dispatcher Table, and when there are N services bound on a tunnel interface, there will be N+1 entries in Egress Dispatcher Table, the additional one for the default tunnel entry. The first 4 bits of Register6 will be used to indicate the service priority and the next 20 bits for interface Tag, and this will be the match criteria for packet redirection to service pipeline in Egress Dispatcher Table. Before sending the packet to the service, Egress Dispatcher Table will set the service index to the next service’ priority. Same as ingress, Register6 will be used for egress tunnel-type matching, if there are services bound on tunnel-type.
TABLE | MATCH | ACTION |
---|---|---|
INTERFACE_INGRESS_TABLE | in_port | SI=0,reg6=interface_type, metadata=lport tag, goto table 17 |
LPORT_DISPATCHER_TABLE | metadata=service priority && lport-tag(priority=10) | increment SI, apply service specific actions, goto ingress service |
reg6=tunnel-type priority=5 | increment SI, apply service specific actions, goto ingress service | |
EGRESS_DISPATCHER_TABLE | Reg6==service Priority && lport-tag(priority=10) | increment SI, apply service specific actions, goto egress service |
reg6=tunnel-type priority=5 | increment SI, apply service specific actions, goto egress service |
GetEgressActionsForInterface
RPC in interface-manager currently returns the output:port
action for tunnel interfaces. This will be changed to return
set_field_reg6(default-service-index + interface-tag) and resubmit(egress_dispatcher_table).
No yang changes are needed, as binding on tunnel-type is enabled by having reserved keywords for interface-names
service-priority
, service-mode
and instructions
for service being bound on the tunnel interface.service-priority
and interface-tag
value with actions
pointing to the service specific actions supplied by the application.service-priority
and
service-mode
for service being unbound on the tunnel interface.service-mode
and instructions
for service being bound. The reserved keywords will be
ALL_VXLAN_INTERNAL
, ALL_VXLAN_EXTERNAL
, and ALL_MPLS_OVER_GRE
.service-priority
and
tunnel-type
value with actions pointing to the service specific actions
supplied by the application will be created on each DPN.service-mode
for service being
unbound on all connected DPNs.This change doesn’t add or modify any configuration parameters.
The solution is supported on a 3-node cluster.
Carbon.
N/A
This feature doesn’t add any new karaf feature.Installing any of the below features can enable the service:
odl-genius-ui odl-genius-rest odl-genius
This use case is mainly for those who want to write applications using Genius and/or want to create individual tunnel interfaces. Note that this is a simpler easy way to create tunnels without needing to delve into how OVSDB Plugin creates tunnels.
Refer Genius User Guide [4]_ for more details on this.
URL: restconf/config/ietf-interfaces:interfaces
Sample JSON data
{
"interfaces": {
"interface": [
{
"name": "vxlan_tunnel",
"type": "iana-if-type:tunnel",
"odl-interface:tunnel-interface-type": "odl-interface:tunnel-type-vxlan",
"odl-interface:datapath-node-identifier": "1",
"odl-interface:tunnel-source": "192.168.56.101",
"odl-interface:tunnel-destination": "192.168.56.102",
"odl-interface:monitor-enabled": false,
"odl-interface:monitor-interval": 10000,
"enabled": true
}
]
}
}
URL: http://localhost:8181/restconf/config/interface-service-bindings:service-bindings/services-info/{tunnel-interface-name}/interface-service-bindings:service-mode-egress
Sample JSON data
{
"bound-services": [
{
"service-name": "service1",
"flow-priority": "5",
"service-type": "service-type-flow-based",
"instruction": [
{
"order": 1,
"go-to-table": {
"table_id": 88
}
}],
"service-priority": "2",
"flow-cookie": "1"
}
]
}
LPORT_DISPATCHER_TABLE
set_field_reg_6
and resubmit(220)
action to actions returned in
getEgressActionsForInterface()
for Tunnels.Genius, Netvirt
There will be several impacts on netvirt pipeline with this change. A brief overview is given in the table below:
Capture details of testing that will need to be added.
New junits will be added to InterfaceManagerConfigurationTest to cover the following :
The following TCs should be added to CSIT to cover this feature:
This will require changes to User Guide and Developer Guide.
There is a pipeline change for tunnel datapath introduced due to this change. This should go in User Guide.
Developer Guide should capture how to configure egress service binding on tunnels.
[1] | Genius Carbon Release Plan https://wiki.opendaylight.org/view/Genius:Carbon_Release_Plan |
[2] | Netvirt Pipeline Diagram http://docs.opendaylight.org/en/latest/submodules/genius/docs/pipeline.html |
[3] | Genius Trello Card https://trello.com/c/S8lNGd9S/6-service-binding-on-tunnel-interfaces |
[4] | Genius User Guide http://docs.opendaylight.org/en/latest/user-guide/genius-user-guide.html#creating-overlay-tunnel-interfaces |
Note
This template was derived from [2], and has been modified to support our project.
This work is licensed under a Creative Commons Attribution 3.0 Unported License. http://creativecommons.org/licenses/by/3.0/legalcode