Work Items


1. Frankfurt Improvements

No.TrackDescriptionJiraPriorityImpactsRemarks
1.1NST selectionImplementation of NST selection in HAS
1HASCommon understanding of how to fetch template details from SDC
1.2Implement callback for NST selection
1OSDF, SO
1.3NSI selectionAPI improvements - For NSI selection, NSST details should be provided in the request from SO (NSMF). NumSolutions should be provided by SO. Service/Slice Profile attributes, json blob at the end
1
Domain type (AN/TN/CN) should be also included in the Slice Profile (Modeling consideration?)
1.4OOF response shall NOT contain NSSI info (only NSI if available/usable, and Slice Profiles will be sent back).
1

1.5

During NSI selection, when the attribute (e.g., reliability) in Threshold Policy is not part of Slice Profile, it should be ignored by HAS (error should not be returned)



HASAlready implemented
1.6

Aggregate policy to be implemented, e.g., latency of all Slice Profiles (across subnets) chosen to be < latency in Service Profile.


1
independent improvement
1.7

When considering existing NSSI as a candidate, consider ALL slice profiles (not just “best” one).


2

1.8Slice profile generation - candidates should be generated at appropriate granularity
1
  • To be generated even when reusing an existing NSI
  • Which parameters to generate (per domain type) to be policy driven or come from Slice Profile Template, as well as should depend on the parameters received in the service profile 
1.9Slice profile selection - choose best one, based on service profile, subnet capabilities (and optionally existing NSSIs, if sharing is allowed???)
1
Priority can be revisited
1.10Implement callback for NSI selection
1OSDFAdditional components - SO
1.11Selecting "final" solution(s) by OOF based on policy - minimum change policy, maximum slice count policy, reuse policy, etc. subject to the numSolutions limit sent by SO.
2

HAS


OOF API shall still contain 'list' of solutions

OSDF - translation of Policy

1.12NSI TerminationAPI and response for NSI termination - yes or no (check Policy also)

1 - functionality

2- OOF impacted

OSDF, SORequest should come from SO acting as NSMF

2. NSSI Selection

No.TrackDescriptionJiraPriorityImpactsRemarks
2.1NSSI Selection

Select appropriate NSSI, return "no solution" if no solution exists

(Send Slice Profiles also in case of RAN NSSI selection for Option 1)


1
Intention is to make NSSI selection domain agnostic.
2.2Implement callback for NSSI selection
1

2.3NSSI TerminationAPI and response for NSSI termination - yes or no (check Policy also)

1 - functionality

2 - OOF impacted

OSDF, SORequest should come from SO acting as NSSMF



  • No labels

2 Comments

  1. Danh D. Le

    Hi Swaminathan Seetharaman

    On the point 1.3- Domain type (AN/TN/CN) should be also included in the Slice Profile (Modeling consideration?).

    In case a single NSSMF provides functionalities for different domain (AN/CN), then how does it distinguish which domain NSSI is being asked?

    Do you have further information about the modeling aspect of this point?


    Thanks,

    Danh

  2. Swaminathan Seetharaman

    Hi Danh D. Le

    Yes, domain type should also be included. Details of modeling aspects can be found at Modeling enhancements.

    Thank you.

    Swami.