NORDUnet/opennsa

Incorrect modelling of ReserveTimeout in the reservationState machine.

Opened this issue · 0 comments

This 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:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns2:QuerySummaryResultType xmlns:ns6="http://schemas.ogf.org/nsi/2013/12/framework/types" xmlns:ns5="http://www.w3.org/2000/09/xmldsig#" xmlns:ns8="http://schemas.ogf.org/nsi/2013/12/framework/headers" xmlns:ns7="http://schemas.ogf.org/nsi/2013/12/services/point2point" xmlns:ns2="http://schemas.ogf.org/nsi/2013/12/connection/types" xmlns:ns4="http://www.w3.org/2001/04/xmlenc#" xmlns:ns3="urn:oasis:names:tc:SAML:2.0:assertion">
    <connectionId>LS-cd202541ea</connectionId>
    <globalReservationId>urn:ogf:network:lsanca.pacificwave.net:2016:pw-losa2-1:switch:EVTS.A-GOLE:conn+66c1950a-4bcf-464c-ad8c-559cc20a0edb:resource+links-connection_1:vlan+3601</globalReservationId>
    <description>deltaId+c7544ad5-7d9f-49f2-90e2-9baddecddbe6:uuid+950bc160-7fa3-4fba-8be1-daf8f9e71ff5</description>
    <criteria version="0">
        <schedule>
            <endTime>2021-09-24T13:36:24.224000Z</endTime>
        </schedule>
        <serviceType>http://services.ogf.org/nsi/2013/07/descriptions/EVTS.A-GOLE</serviceType>
        <children/>
        <ns7:p2ps>
            <capacity>10000</capacity>
            <directionality>Bidirectional</directionality>
            <symmetricPath>false</symmetricPath>
            <sourceSTP>urn:ogf:network:lsanca.pacificwave.net:2016:pw-losa2-1:snvl2-pw-sw-1?vlan=3601</sourceSTP>
            <destSTP>urn:ogf:network:lsanca.pacificwave.net:2016:pw-losa2-1:ultralight?vlan=3601</destSTP>
        </ns7:p2ps>
    </criteria>
    <requesterNSA>urn:ogf:network:lsanca.pacificwave.net:2016:sense:pw-losa2-1</requesterNSA>
    <connectionStates>
        <reservationState>ReserveHeld</reservationState>
        <provisionState>Released</provisionState>
        <lifecycleState>Created</lifecycleState>
        <dataPlaneStatus>
            <active>false</active>
            <version>0</version>
            <versionConsistent>false</versionConsistent>
        </dataPlaneStatus>
    </connectionStates>
    <notificationId>1089211</notificationId>
    <resultId>0</resultId>
</ns2:QuerySummaryResultType>

It seems that even though the reservation timed out it remains in the “ReserveHeld” state. This presents a problem in that it is not a valid transition (ie. it should be in the ReserveTimeout state), and I still see my reservation in a ReserveHeld state but cannot commit it.

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.