Skip to content
GitLab
Closed
Issue created by Lluis Gifre Renom@gifrerenomMaintainer

(CTTC) Forecaster component

Proposers

  • Daniel Adanza (CTTC)
  • Lluis Gifre (CTTC)
  • Ricard Vilalta (CTTC)

Description

Forecaster component will be used to make predictions over the KPIs registered by the Monitoring component. Forecaster component is integrated using gRPC protocol with rest of components. When PathComp component needs to run a computation, it might interrogate the Forecaster to ensure resources will be available in the near future for the new requested service.

Demo or definition of done

When a PathComp is requested for a service carrying a schedule and shortest path has not enough capacity, it should retrieve a (possibly) longer path with available resources in the forecasted window. If no link has enough capacity, PathComp should block the request.

References

None

Feature Design (for New-Features)

Clarifications to Expected Behavior Changes

  • The Forecaster will expose methods ForecastLinkCapacity and ForecastTopologyCapacity.
  • Context component needs to be extended to store the total capacity of links.
  • Monitoring component needs to be extended to store the historical capacities of links.
  • PathComp component needs to be extended to request a traffic forecast (configurable through a setting) when a service is requested with some durability.

References

None

Assumptions

None

Impacted Components

  • ProtoBuffers needs to be extended
  • Modified components: Context, Monitoring, PathComp
  • New component: Forecaster

ProtoBuffers Impact

  • Add gRPC methods for the Forecaster component (see Forecaster component).
  • Add LinkAttributes (total_capacity_gbps, used_capacity_gbps) to Link object (see Context component).
  • Add KpiSampleTypes (KPISAMPLETYPE_LINK_TOTAL_CAPACITY_GBPS, KPISAMPLETYPE_LINK_USED_CAPACITY_GBPS).

Context Impact

  • Store total and currently used capacity of links.
  • Extend protocol buffers with link attributes:
message LinkAttributes {
  float total_capacity_gbps = 1;
  float used_capacity_gbps  = 2;
}
  • Extend database schema and the logic to manage database entities.
  • Extend unitary tests and MockServicer_Context to make rest of unitary tests consistent.

Monitoring Impact

  • Monitoring component needs to be extended to store the historical capacities of links.
  • KPI database schema needs to be extended with the link identifier.
  • New KPIs needs to be created in protocol buffers.
Added KPIs to protos:
    ...
    KPISAMPLETYPE_LINK_TOTAL_CAPACITY_GBPS      = 301;
    KPISAMPLETYPE_LINK_USED_CAPACITY_GBPS       = 302;
    ...
  • Methods to retrieve/store KPIs needs to be extended with link identifiers.
  • Extend unitary tests and MockServicer_Monitoring to make rest of unitary tests consistent.

Forecaster Impact

  • Depends on Context and Monitoring components.
  • New ProtoBuf file needs to be created with the gRPC methods and messages (see below).
service ForecasterService {
  rpc ForecastLinkCapacity    (ForecastLinkCapacityRequest    ) returns (ForecastLinkCapacityReply    ) {}
  rpc ForecastTopologyCapacity(ForecastTopologyCapacityRequest) returns (ForecastTopologyCapacityReply) {}
}

message ForecastLinkCapacityRequest {
  context.LinkId link_id                 = 1;
  float          forecast_window_seconds = 2;
}

message ForecastLinkCapacityReply {
  context.LinkId link_id                     = 1;
  float          total_capacity_gbps         = 2;
  float          current_used_capacity_gbps  = 3;
  float          forecast_used_capacity_gbps = 4;
}

message ForecastTopologyCapacityRequest {
  context.TopologyId topology_id             = 1;
  float              forecast_window_seconds = 2;
}

message ForecastTopologyCapacityReply {
  repeated ForecastLinkCapacityReply link_capacities = 1;
}
  • Pseudocode for topology forecasting (link forecasting is a subset):
  # Setting to configure the ratio between requested forecast and amount of historical data to be used for the forecast.
  # E.g., if forecast window is 1 week, compute forecast based on 10 weeks of historical data.
  FORECAST_TO_HISTORY_RATIO = 10

  history_window_seconds = FORECAST_TO_HISTORY_RATIO * request.forecast_window_seconds

  forecast_reply = ForecastTopologyCapacityReply()

  topology = context_client.GetTopology(topology_id)
  for link_id in topology.link_ids:
    link = context_client.GetLink(link_id)

    used_capacity_history_gbps = monitoring_client.GetKPIValue(link_id, KPI.LinkUsedCapacity, window=history_window_seconds)
    forecast_used_capacity_gbps = compute_forecast(used_capacity_history_gbps, forecast_window_seconds)

    forecast_reply.link_capacities.append(ForecastLinkCapacityReply(
      link_id=link_id,
      total_capacity_gbps=link.total_capacity_gbps,
      current_used_capacity_gbps=link.used_capacity_gbps,
      forecast_used_capacity_gbps=forecast_used_capacity_gbps
    ))

  return forecast_reply
  • New unitary tests needs to be created.

PathComp Impact

  • If the service has a duration constraint configured, the PathComp component should interrogate the Forecaster and request a topology forecast according to the requested duration of the service.

  • The computed link capacity forecast should be used as link capacity in path computations.

  • If multiple services are requested at once, current logic prevents computing a reasonable forecast, so a single service request with traffic capacity forecasting is permitted by now.

  • If Forecaster component is not deployed or explicitly deactivated, forecasting logic should be bypassed.

  • A new setting ENABLE_FORECASTER needs to be added to explicitly disable Forecasting in PathComp, even if Forecaster is deployed.

  • Extension in Pseudocode:

  link_capacities : Dict[str, float] = dict() # link_uuid => available_capacity_gbps
  service_duration = get_service_duration(request.service)
  if service_duration is None:
    topology = context_client.GetTopologyDetails(topology_id)
    for link in topology.links:
      link_capacities[link.link_id.uuid] = link.available_capacity_gbps
  else:
    forecast_request = ForecastTopology(
      topology_id = TopologyId(service.context_id, admin),
      forecast_window_seconds = service_duration
    )
    forecast_reply = forecaster_client.ComputeTopologyForecast(forecast_request)
    for link_capacity in forecast_reply.link_capacities:
      total_capacity_gbps = link_capacity.total_capacity_gbps
      forecast_used_capacity_gbps = link_capacity.forecast_used_capacity_gbps
      forecast_available_capacity_gbps = total_capacity_gbps - forecast_used_capacity_gbps
      link_capacities[link_capacity.link_id.uuid] = forecast_available_capacity_gbps

  # Continue path computation passing link_capacities to the path comp algorithms.

Testing

Testing steps:

  • Onboard a topology defining total link capacities
  • Pre-populate Monitoring with historical link capacity data
  • Request a service setup carrying a schedule
  • Pathcomp should interrogate Forecaster and use retrieved values for path computation
  • If shortest path has not enough forecasted capacity
    • PathComp should retrieve a (possibly) longer path with available resources in the forecasted window.
    • If no enough forecasted capacity available
      • PathComp should block the request
  • When a service is setup, Service component should update consumed capacity in Context and Monitoring
Edited by Lluis Gifre Renom