Child pages
  • Candidate Features for Future Releases of TAPI SDK and RIA

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  •  Next Appropriate Release - Priorities and schedule not yet assigned
    •  Candidate refinements (Nigel Davis to refine/itemize)
    •  Temporal Model - available reference material on OIMT/Core IM
      • Including retrieval of temporal planned resources
    •  Enhance Streaming UML for the automatic generation of feature/if-feature statements.
      • Explore the definition of topology/connectivity/oam features.
    •  Path Computation Service / Connectivity Service enhancements (Nigel Davis )
    •  Broader application of spec model Nigel Davis 
      • Determine what the correct Spec reference is (UUID etc.)
      • Ensure that all model elements can refer to a spec
      • Develop spec for each entity through value-justified-steps
    •  Multiple Contexts Nigel Davis
      • Note that this has been moved up from "Next Major Release" as it does not appear to need TAPI changes and is more of a usage description.
      • As Context is the root of the tree, there can clearly only be one context per provider connection
        • There could be multiple alternative connections (connection sets) that would be separately secured where each would provide a context with a specific view (slice etc.).
    •  Further development of transmission capability feature
    •  Documentation enhancements Nigel Davis
      •  Document the extension mechanism
        •  Extension mechanism: This is not documented visibly:
          •  Determine what degree of extension is allowed and where (especially accounting for the spec work – a vendor must be enabled to insert a spec that expresses their precise equipment capability as a replacement for the standard spec (e.g., Ethernet port)
          •  Ensure that we document the approach and define some level of “enforcement”
      •  Overall document structure
        •  may want to separate out informative/explanatory model text from normative text (as per core)
        •  may want to separate out definitions (such as top level connection)
    •  

      UNI Client interfaces modelling Nigel Davis 

      • SIP model, possibly including internal SIP - ServiceInterfacePoint as role/view of NodeEdgePoint
        • Conceptual major change?
      • Using the spec model approach to simplify the SIP layering and also enhance its information opportunity.
    •  TopologyService: Link/Node CRUD intent (Karthik Sethuraman  )Nigel Davis
    •  Ethernet (L2) Andrea Mazzini Karthik Sethuraman
      •  Verify alignment/consistency with "ITU-T G.8052.1 UML & YANG and the IEEE 802.1Qcx CFM YANG" outcomes.
    •  Photonic (L0) enhancements Stephane St-Laurent Malcolm Betts
    •  LLDP Support Bernd Zeuner  Andrea Mazzini
    •  ETSI NFV Nigel Davis Karthik Sethuraman Stephane St-Laurent
      • Touch points (Core LTP/Link) 
      • Use of Processing Construct as VNF proxy 
    •  IETF Topology (RFC 8345) alignment Nigel DavisKarthik Sethuraman
    •  Refinement of Intent modeling (speculative) Nigel Davis 
      • The notion of "capability" replaces the resource/service split
      • Capability Intent is expressed in an Outcome-Oriented Constraint-Based form replacing all "Service" model elements
      • Capability Achievement is expressed in terms of a Constraint-Based form which would cover all "Resource" model representations
    •  Profiles & Templates
    •  Wireless
    •  Device/Equipment configuration interfaces (Sw download, backup, circuit pack configuration)
    •  Mgmt of Device Control interfaces  (Nigel Davis )
    •  Mgmt of Synchronization/Timing  (Nigel Davis )
    •  CHANGE_ONLY (delta) streaming  (Nigel Davis )
    •  Spotlight and snapshot streaming  (Nigel Davis )
    •  Creation of Equipment Intent  (Nigel Davis )
    •  Problem reporting (Nigel Davis )
      •  Where alarm etc. analysis has taken place in the controller and it is able to provide a summary of problems with associated alarms
      •  There are two focusses
        •  Resolving the problem
        •  Understanding the impact
      •  May incorporate service jeopardy reporting
    •  Adoption of a specification model approach as described in the ONF Core model (Nigel Davis )
      •  Each entity/aggregate will have the opportunity for addition of a specification
      •  The specification is per type and it constrains legal values (sometimes to invariant values that then do not need to be reported in the instance)
    •  CSEP and ConnectivityService represent a hybrid of intent and abstraction of actual state of the CEP. The purpose of each field is sometimes unclear. It is important to separate intent from current state clearly.  (Nigel Davis )
      •  The client may also want to send an initialization value but hand control to the provider to choose the value after initialization.
      •  For example, the client may wish to set a constraint on the channel/wavelength or may wish to leave the choice to the provider. Regardless, there will be an actual channel/wavelength. Clearly, the CSEP could reflect the current channel/wavelength, but this must be separate from the intent statement, as otherwise it will appear that the channel/wavelength was an intent.
      •  Considering this, it appears that there are several cases:
        •  Initialization value, that does not need to be retained in the intent once the intent has been initially realized. It is provided in the request but only available until the first realization is determined.
          •  e.g. AdminState of Locked
        •  Constraint value, that does need to be retained in the intent. There should also be an achieved state that is separate from the intent.
          •  e.g., channel should be between 6 and 12... actual channel is 9
        •  No constraint value where current state does not need to be reflected.
          •  e.g., channel where the control plane is fully in charge and the client is not interested in an abstraction of the CEP in the intent as it can get the CEP
        •  Current state that is never has a constraint 
          •  e.g., OperationalState where the client requires a reflection of the operational state of the CEP in the CSEP (why??)
        •  A constraint that is further narrowed on design
          •  e.g., use any connector in the range AccessPort 1 to AccessPort 12. What ever is chosen becomes the intent, so if AccessPort 3 is chosen, the intent changes from 1-12 to 3.
          •  It is not clear whether there is a relevance to keeping the initial intent and the new narrower intent, or whether it is irrelevant.
        •  A preferred value under certain circumstances
        •  etc.
      •  The above list suggest a multiplicity of values for each property
        •  Initialization
        •  Initial intent
        •  Refined intent
        •  Preferred value
        •  Current value
      •  The provider should not reflect an actual value in the initial intent etc.
      •  Where it may not be necessary, based upon some policy, to reflect current state in the CSEP/ConnectivityService as it is considered as pure intent
      •  It should also be recognized that it may not be possible to constrain some parameters under some circumstances.
        •  Ideally, the provider should express capability under all relevant conditions and for all relevant combinations
        •  Minimally, the provider should reject cases that it cannot support
      •  Clearly some constraints may be preferences and/or there may be options. The structure should reflect degree of relevance of a constraint 
        •  And this should be reflected by the provider as appropriately
      •  (Previous item was a subset "Support for "initialization parameters" (Nigel Davis )
        •  For example, where the property is provided in the CSEP but is not intent and hence does not appear in a CSEP read (it is a write only parameter! - need to develop this further)
          •  Note that the property will appear in the CEP and may need to be subsequently adjusted"
    •  TR-547 and TR-548 provide requirements and use cases. Some of the requirements and use cases are very broad with many options. Andrea Mazzini Nigel Davis Ramon Casellas 
      •  When considering compliance, it is not clear what compliance at a provider controller and a client controller actually means wrt the flexibility.
      •  The strandards team should make recommendations on meaningful compliance with the two RIAs.