Open-source implementation of the NSI protocol with support for different backends
NORDUnet, updated
🕥
2022-10-06 13:19:05
OpenNSA
OpenNSA is an implementation of the Network Service Interface (NSI).
NSI (Network Service Interface) is a technology agnostic protocol for provisioning network circuits. For more information on NSI, see project page at OGF: https://redmine.ogf.org/projects/nsi-wg
OpenNSA is currently in a state of heavy development, and many features are only partially implemented.
OpenNSA features
- Open-source NSI implementation
- Pluggable backends to support different equipment
- Support: Junox MX, Force10 switch (etherscale), Dell Powerconnect
- DUD backend for easy testing
- Any custom Python backend
- Easy development of new backends
- Easy creation of NML topology from short-hand topology specification
- Topology aggregation and path finding to do multi-domain circuit creation
- PostgreSQL for database
- Includes command line tool for basic operations
Documentation
Full and detailed documentation available here
License
NORDUnet License (3-clause BSD). See LICENSE for more details.
Contact
- Johannes Garm Houen - jgh @ nordu.net
- Samir Faci - samir @ es.net
Copyright
NORDUnet (2011-2015)
Issues
Access control not enforced on terminate action.
opened on 2022-05-04 16:18:03 by jmacauleyThis one is pretty simple. The query operation filters reservations based on the requester's nsaId so an NSA only sees reservation created by itself, however, OpenNSA does not restrict the terminate operation on NSA to terminate a second NSA's reservation.
Add support for SOAPFaults.
opened on 2021-09-29 16:53:06 by jmacauleyLook like onsa command line has issues handling SOAP faults returned from service providers. The following error was generated when a SOAP fault was received for invalid message contents.
```
[email protected]:~$ onsa reserveprovision -s calit2.optiputer.net:2020:prism-core:k8s-gen4-01#vlan=1779 -d calit2.optiputer.net:2020:prism-core:k8s-gen4-02#vlan=1779 -y
Site (TLS) starting on 7080
Starting factory
(TLS Port 7080 Closed)
Stopping factory
Here is the SOAP Fault generated by the Safnari NSI provider:
```
Implement ifModifiedSince functionality as per NSI CS 2.1 specification
opened on 2021-09-28 14:26:05 by jmacauleyTitle says it all. Would like OpenNSA to support the ifModifiedSince query functionality as per NSI CS 2.1 specification.
Error Loading CA certificate
opened on 2021-08-10 21:27:42 by marcosfschRunning the OpenNSA (master) docker with TLS, I always get a fatal error on twisted.
opennsa_1 | 2021-08-10 21:20:14Z [-] Loading opennsa.tac...
opennsa_1 | 2021-08-10 21:20:14Z [-] Loaded.
opennsa_1 | 2021-08-10 21:20:14Z [-] twistd 21.7.0 (/usr/bin/python3 3.7.3) starting up.
opennsa_1 | 2021-08-10 21:20:14Z [-] reactor class: twisted.internet.epollreactor.EPollReactor.
opennsa_1 | 2021-08-10 21:20:14Z [-] OpenNSA service initializing
opennsa_1 | 2021-08-10 21:20:14Z [opennsaTlsContext] Loaded CA certificate commonName b'OISTE WISeKey Global Root GB CA'
opennsa_1 | 2021-08-10 21:20:14Z [opennsaTlsContext] Loaded CA certificate commonName b'Baltimore CyberTrust Root'
opennsa_1 | 2021-08-10 21:20:14Z [opennsaTlsContext] Loaded CA certificate commonName b'Certum Trusted Network CA 2'
opennsa_1 | 2021-08-10 21:20:14Z [-] Traceback (most recent call last):
opennsa_1 | 2021-08-10 21:20:14Z [-] File "/usr/local/lib/python3.7/dist-packages/twisted/internet/_sslverify.py", line 324, in getattr
opennsa_1 | 2021-08-10 21:20:14Z [-] return self[_x509names[attr]]
opennsa_1 | 2021-08-10 21:20:14Z [-] KeyError: 'commonName'
opennsa_1 | 2021-08-10 21:20:14Z [-]
opennsa_1 | 2021-08-10 21:20:14Z [-] During handling of the above exception, another exception occurred:
opennsa_1 | 2021-08-10 21:20:14Z [-]
opennsa_1 | 2021-08-10 21:20:14Z [-] Traceback (most recent call last):
opennsa_1 | 2021-08-10 21:20:14Z [-] File "/usr/local/bin/twistd", line 10, in
Incorrect modelling of ReserveTimeout in the reservationState machine.
opened on 2020-11-06 18:20:42 by jmacauleyThis issue relates to state transitions in the reservationState machine. Using the following reserveTimeout message for illustration:
``` 2020-09-24 06:38:24,764 [ConnectionService] reserveTimeout for { providerNSA = urn:ogf:network:lsanca.pacificwave.net:2016:nsa, correlationId = urn:uuid:3846121e-fe6b-11ea-af4e-525400c57fcf, connectionId = LS-cd202541ea, notificationId = 46, timeStamp = 2020-09-24T13:38:24.723135Z, originatingNSA = urn:ogf:network:lsanca.pacificwave.net:2016:nsa, originatingConnectionId = JUNOS-711498, timeoutValue = 120 }
``` I received this timeout message for reservation”LS-cd202541ea“ and transition my internal reservationState machine to “ReserveTimeout” which is a stable state in the machine. However, the next time I queried this reservation I got the following:
``` 2020-09-24 06:39:05,970 [QuerySummary] incoming providerNSA = urn:ogf:network:lsanca.pacificwave.net:2016:nsa, QuerySummaryResultType:
In the NSI CS 2.1 protocol the aggregator also models the reserve timeout state two provide a consistent view of the reservation throughout the connection hierarchy.
originatingConnectionId incorrect in reserveTimeout message.
opened on 2020-11-06 18:17:36 by jmacauleyWhen the reservation reserveTimeout event is return by an aggregator OpenNSA on PacificWave I get the following content:
reserveTimeout {
providerNSA = urn:ogf:network:lsanca.pacificwave.net:2016:nsa,
correlationId = urn:uuid:3846121e-fe6b-11ea-af4e-525400c57fcf,
connectionId = LS-cd202541ea,
notificationId = 46,
timeStamp = 2020-09-24T13:38:24.723135Z,
originatingNSA = urn:ogf:network:lsanca.pacificwave.net:2016:nsa,
originatingConnectionId = JUNOS-711498,
timeoutValue = 120
}
In this case the “originatingConnectionId” should be set to “LS-cd202541ea” since this NSA is the originating NSA of the timeout. If the aggregator had exposed the underlying uPA then the “originatingNSA” field would have been set to that uPA, and then “originatingConnectionId” as the connectionId in the context of the uPA. However, since there is no visibility of an NSA other than “urn:ogf:network:lsanca.pacificwave.net:2016:nsa” we need it set to “LS-cd202541ea” since this is the uPA reservation in the context of NSI.
Releases
3.0.2 2021-11-26 07:43:26
What's Changed
- Support configuration for any backend by @bjpbakker in https://github.com/NORDUnet/opennsa/pull/5
- Adding json content-type by @mkrogh in https://github.com/NORDUnet/opennsa/pull/6
- Change bandwidth to capacity by @mkrogh in https://github.com/NORDUnet/opennsa/pull/7
- Update rest interface documentation by @mkrogh in https://github.com/NORDUnet/opennsa/pull/8
- Use the same names as GET for start_time and end_time by @mkrogh in https://github.com/NORDUnet/opennsa/pull/9
- Bump twisted from 15.2.1 to 19.7.0 by @dependabot in https://github.com/NORDUnet/opennsa/pull/10
- build docker container with opennsa v3 and python3 by @hanstrompert in https://github.com/NORDUnet/opennsa/pull/13
- New twisted client TLS context with correct peer verification and SNI support by @hanstrompert in https://github.com/NORDUnet/opennsa/pull/18
- not all certificates have a common name by @hanstrompert in https://github.com/NORDUnet/opennsa/pull/22
- Removed necessity for --squash by @marcosfsch in https://github.com/NORDUnet/opennsa/pull/21
- Docker Overall Improvement and workflow changes by @safaci2000 in https://github.com/NORDUnet/opennsa/pull/23
- Updated oess.py to python3 by @marcosfsch in https://github.com/NORDUnet/opennsa/pull/20
- Introduce Admin access to querySummary by @safaci2000 in https://github.com/NORDUnet/opennsa/pull/29
- Adding CI/CD by @safaci2000 in https://github.com/NORDUnet/opennsa/pull/30
- Adding instructions for local CI/CD exec by @safaci2000 in https://github.com/NORDUnet/opennsa/pull/32
- Proxied setup support by @hanstrompert in https://github.com/NORDUnet/opennsa/pull/31
- [TechDebt] Adding a CI health badge by @safaci2000 in https://github.com/NORDUnet/opennsa/pull/34
- [TechDebt] Adding automatic docker publishing. by @safaci2000 in https://github.com/NORDUnet/opennsa/pull/35
- an http request should return bytes by @hanstrompert in https://github.com/NORDUnet/opennsa/pull/33
New Contributors
- @bjpbakker made their first contribution in https://github.com/NORDUnet/opennsa/pull/5
- @mkrogh made their first contribution in https://github.com/NORDUnet/opennsa/pull/6
- @dependabot made their first contribution in https://github.com/NORDUnet/opennsa/pull/10
- @hanstrompert made their first contribution in https://github.com/NORDUnet/opennsa/pull/13
- @marcosfsch made their first contribution in https://github.com/NORDUnet/opennsa/pull/21
- @safaci2000 made their first contribution in https://github.com/NORDUnet/opennsa/pull/23
Full Changelog: https://github.com/NORDUnet/opennsa/commits/3.0.2
OpenNSA 3.0.1 2020-06-11 06:33:29
- Partial port of the the brocade backend to Python 3
- Updated docker buildfile for Python 3 (kindly provided by Hans Trompert, SURFnet)
- Some initial tests with multi-NSA setups
- Fix issue with nml network displaying the wrong network names
- Some slight clarification around OpenNSA 3 migration.
- Fix issue with remote network being omitted in nml topology
- Better error message if the cerficate directory is not a directory
- Fix issue with the object id being listed in the discovery.xml (and not nsa id)
- Improved logging (missing system variables / better explanations, linkvector)
- Some spelling/grammar fixes on the documentation
- Fix issue with undefined variable being used in httpclient
- Improve parsing of peers url list
- Better documentation around having multiple peers
- Several fixes regarding byte/string in all of the code base
- Updated requirements to specify twistar 2.0
Special thanks to John Hess for a lot of feedback and patches for this release.
OpenNSA 3.0.0 2020-01-22 12:43:18
- Port to Python 3
- Support for multiple backends
- More tests added
- Better pathfinder and pathfinding in general
- Better logging in several odd error cases
- Lots of small fixes
This release requires some small changes to configuration file. See docs/migration for details.