Decouple PCE from local NSA configuration.

[jmacauley]

The PCE currently utilized the DDS "local" document API to retrieve the NSA description document associated with the local NSA instance. The NSA identifier from this context is then used to perform control plane path finding and populate path results with the next hop NSA for a reservation request.

The primary issue is that the PCE is bound to a single NSA as it can only correctly respond to path requests for the NSA running the DDS to which the PCE is bound. Any time a request comes into the PCE it uses the local NSA context from the DDS as the root of the graph for the control plane path computation. Removing the dependency on the DDS "local" document API means the PCE could use any DDS available on the network. In addition, having the client of the PCE pass in the NSA context would allow a single PCE to service path requests from any number of NSA instances.

The following changes would be required:

1. The northbound path API would need to pass in the NSA identifier providing context for the control plane path computation.
2. The PCE would no longer use the DDS /local API for determining the local NSA identifier, and instead use the NSA identifier passed in through the northbound API.

[erikrozendaal]

We can pass the NSA identifier in a new top-level field aggregatorNSA in the PathComputationRequest. Is this OK with you?

[jmacauley]

Can we just call it nsaId since the PCE could be used in a non-aggregator context?

Thanks!

[erikrozendaal]

Safnari now passes its ID in the nsaId top-level field as part of the path computation request: BandwidthOnDemand/nsi-safnari@8a0ff0e