Multiple network providers per span and node

[duncandewhurst]

Currently, Span.networkProvider and Node.networkProvider are objects, i.e. there is a 1:1 relationship between Span/Node and networkProvider.

Therefore, to represent a span with many network providers (a common situation), implementers would need to publish multiple spans - one for each network provider.

This is a problem because properties of Span and Node that relate to the physical infrastructure would need to be repeated for each span/node, which could lead to double-counting, e.g. fibreCount.

Proposal

• Replace Span.networkProvider (an object) with Span.networkProviders (an array).
• Replace Node.networkProvider (an object) with Node.networkProviders (an array)

Related issues

The following issues are related, but not addressed by the proposal:

• Allow multiple physical infrastructure providers per span and node. #199
• Enable users to determine the difference between multiple operators using the same fibre vs multiple operators with different lengths of fibre in the ground. #192
• Span.route: Clarify semantics with respect to schematic data #193

Analysis

Schema and codelist changes

This section provides an analysis of the changes to schema and codelists resulting from the proposed change.

Span

The following fields relate to the active layer so descriptions may need to be updated. Proposed changes are shown in italics:

• status('operational' code):

'The active network infrastructure for at least one network provider on the span is live and carrying traffic.'

• readyForServiceDate:

'The date this span was ready to carry traffic. For spans with multiple network providers, the earliest of the dates at which each provider's network was ready to carry traffic on this span'.

• technologies:

`The active technologies used on this span,from the open spanTechnologies codelist. For spans with multiple network providers, the union of the active technologies used by each provider.

• capacity:

'The transmission rate, or throughput, of this span, expressed in Gbit/sec (Gbps). The equipped capacity is the total capacity of the circuits (e.g. E1, DS3, STM-1 etc.) which have been activated in the network transmission equipment of the span. For spans with multiple network providers, the sum of the capacity of each provider's network on this span. Further details of this span’s capacity can be provided in .capacityDetails. '

• capacityDetails: No change required.

The following fields relate to the passive (physical) layer so they are not affected by the cardinality of .networkProvider:

• id
• name
• phase
• start
• end
• directed
• route
• physicalInfrastructureProvider
• supplier
• transmissionMedium
• deployment
• deploymentDetails
• darkFibre
• fibreType
• fibreTypeDetails
• fibreCount
• fibreLength
• countries

Node

The following fields relate to the active layer so descriptions may need to be updated. Proposed changes are shown in italics:

• status ('operational' code):

'The active network infrastructure for at least one network provider at the node is live and carrying traffic.'

• type:

'The type of this node, from the open nodeType codelist. For nodes with multiple network providers, the union of the node types for each provider.'

• accessPoint: No change required.
• technologies:

'The active technologies used at this node, from the open nodeTechnologies codelist. For nodes with multiple network providers, the union of the active technologies used by each provider.'

The following fields relate to the passive (physical) layer so they are not affected by the cardinality of .networkProvider:

• id
• name
• phase
• location
• address
• internationalConnections
• power
• physicalInfrastructureProvider

Publication models

This section provides an analysis of how the proposed changes would apply to aggregated and distributed publication models in the following scenario:

FibreCo provides the physical infrastructure, operates their own network and leases dark fibre to ProviderCo.

Aggregated publication

FibreCo publishes details of their own network and names ProviderCo as a network provider:

{
  "networks": [
    {
      "publisher": {
        "name": "FibreCo"
      },
      "spans": [
        {
          "physicalInfrastructureProvider": {
            "name": "FibreCo"
          },
          "networkProviders": [
            {
              "name": "FibreCo"
            },
            {
              "name": "FastWeb"
            }
          ],
          "darkFibre": true
        }
      ]
    }
  ]
}

Distributed publication

FibreCo publishes details of their own network without naming ProviderCo as a network provider. ProviderCo publishes details of their own network and names FibreCo as the physical infrastructure provider:

{
  "networks": [
    {
      "publisher": {
        "name": "FibreCo"
      },
      "id": "a096d627-72e1-4f9b-b129-951b1737bff4",
      "spans": [
        {
          "id": "1",
          "physicalInfrastructureProvider": {
            "name": "FibreCo"
          },
          "networkProviders": [
            {
              "name": "FibreCo"
            }
          ],
          "darkFibre": true
        }
      ]
    },
    {
      "publisher": {
        "name": "FastWeb"
      },
      "id": "6187511d-2ec4-4d24-bc97-6289fa6fd4a8",
      "spans": [
        {
          "id": "A",
          "physicalInfrastructureProvider": {
            "name": "FibreCo"
          },
          "networkProviders": [
            {
              "name": "FastWeb"
            }
          ]
        }
      ]
    }
  ]
}

Publication formats

This section provides an analysis of how the proposed changes would affect the GeoJSON and CSV publication formats.

GeoJSON

The following fields will change:

• nodes.geojson: features/properties/networkProvider (object) -> features/properties/networkProviders (array)
• spans.geojson: features/properties/networkProvider (object) -> features/properties/networkProviders (array)

CSV

The CSV publication format will include two additional tables:

• node_networkProviders (id, nodes/0/id, nodes/0/networkProviders/0/id, nodes/0/networkProviders/0/name)
• span_networkProviders (id, spans/0/id, spans/0/networkProviders/0/id, spans/0/networkProviders/0/name)

Data use

This section provides an analysis of the impact on data use.

Mapping

If a user wants to colour the spans and nodes in a network by the network provider, there are several options:

1. Categorise according to the set of network providers, e.g.

• [{"name": "Org A"}]: Red
• [{"name": "Org B"}]: Blue
• [{"name": "Org A"}, {"name": "Org B"}]: Green
• [{"name": "Org B"}, {"name": "Org A"}]: Green

2. Categorise according to the presence of a particular network provider, e.g. for 'Org A':

• [{"name": "Org A"}]: Red
• [{"name": "Org B"}]: Blue
• [{"name": "Org A"}, {"name": "Org B"}]: Red
• [{"name": "Org B"}, {"name": "Org A"}]: Red

3. Create a separate layer for each network provider, e.g.

• 'Org A':
  • [{"name": "Org A"}]: Red
  • [{"name": "Org B"}]: Discard
  • [{"name": "Org A"}, {"name": "Org B"}]: Red
  • [{"name": "Org B"}, {"name": "Org A"}]: Red
• 'Org B':
  • [{"name": "Org A"}]: Discard
  • [{"name": "Org B"}]: Blue
  • [{"name": "Org A"}, {"name": "Org B"}]: Blue
  • [{"name": "Org B"}, {"name": "Org A"}]: Blue

Option 3. is essentially equivalent to the current model of a 1:1 relationship between Span/Node and networkProvider.

Reconciliation

In the distributed publication model discussed above, if the spans declared by each publisher share similar start and end locations and similar routes, a user could infer that they are the same span. In the aggregated distribution model, that fact could be declared explicitly.

[lgs85]

Thanks for this @duncandewhurst - all very comprehensive and clear.

The following issues are related, but not addressed by the proposal

I agree, but think that the issue of one vs multiple spans is partially addressed by this, in that it increases the likelihood that users will be able reconcile spans, and provides a starting point for reconciliation conversations, as you lay out in your final point here.

My view is that though this makes data visualisation and analysis slightly more tricky, the benefits far outweigh the costs, and we should implement this proposal.

[duncandewhurst]

To clarify regarding reconciliation, it is possible to reconcile under the current data model:

• Organisation A publishes a span on which they declare that they are the physical infrastructure provider and the network provider
• Organisation B publishes a span on which they declare that they are the network provider and that Organisation A is the physical infrastructure provider.
• If the spans share similar start and end locations and similar routes, a user could infer that they are the same span and that Organisation B provides their network using Organisation A's physical infrastructure.

The proposal in this issue means that a user could record and publish the network that they have inferred (a single span with two network providers) in conformance with OFDS, which is not possible under the current data model.