Open Transport Configuration & Control
Space shortcuts
Expand all   Collapse all
Child pages
  • Candidate Features for Future Releases of TAPI SDK and RIA
Skip to end of metadata
Go to start of metadata


  • For the below listed items contributions are necessary (red items need to be carefully assessed)

    • Integration of Streaming/Notification related to Object change contents
    • Physical Route for correlation and for routing diversity
      • SRG - besides link, include nodal group, e.g. power and air conditioning, etc.
    • OAM enhancements:
      • Media Channel OAM
      • PM enhancements for Streaming
        • Efficient PM streaming taking advantage of same value suppression etc.
        • Potential use of gnmi/protobuf encoding
    • Manual switch operations on protection/restoration schemes - depending on RIA UCs
    • OAM Job and generalized Task Nigel Davis 
      • Generalize the model of OamJob so it can be used for any Tasks
    • All properties, augments etc. should be conditional mandatory where clear conditions are identified. Nigel Davis  
      • This allows for use of the objects:
        • In notification and streaming to represent any delta (as it is conformant to include only a single attribute)
        • In specifications
        • In other patterns
      • Conditions include feature based control
      • CEP/NEP/etc. augments should be conditional on layer etc.
        • This should also allow vendor specific augments (that are perhaps narrower than the formal layer augment)


  • No specific delivery
    • Updated OAS (tooling)
      • Target is improve the quality of OAS modules - either improving the tool or manually if feasible.
      • Necessary to find resources within OIMT/OTCC. Note that the "Restconf compliance" is not still well specified, subject to local/bounded agreements. No external authority.
      • In general, no open source tool available to generate code from YANG schema. Issue is interoperability.


  • 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 and other approaches to providing views of subsets of information 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.).
      • This could be used as a solution to provide only relevant profiles (e.g., the client is only interested in OAM profiles and other OAM things as it deals only with OAM so there is an OAM Context)
      • An alternative solution for providing subsets (as opposed to using a full context) is for a "constrain domain" equivalent to be used to collect together things of interest based upon some policy etc. and that list of items can then be retrieved as a collection or streamed based upon the collection
        • This could collect all oam profiles or all services of a particular characteristic etc.
      • This could be used
        • Get the "constraint domain" to provide the list of uuids and then getting each individually
    • 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 Nigel Davis 
    • 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.
    • Add a reference property to node to references all devices that support the node
      • Note that the current version of TR-547 has a 1:1 relationship between node and device. As the general case is n:m the property should be a list.
    • Provisioning risk-characteristics on links
      • Whilst TAPI provides definition for risk-characteristics applied to Links and Nodes, there is no defined way to set those characteristics. It is assumed that the risk-characteristics have been set via some mechanism other than TAPI. Considering that the risk-characteristics cannot be discovered from the network devices and need to be determined through of analysis of the physical environment during the planning/design of the physical network, it seems reasonable to expect the risk-characteristics to be conveyed through TAPI from the physical network planning/design tools to be applied in the controller network model and to any relevant control planes coordinated by the controller. As a consequence work will be required in the TAPI standard to support the Use Case of setting the risk-characteristics on the nodes and links.
    • Linkage between TAPI model and IETF model to allow navigation from photonic/OTN to IP layers
    • Dealing with equipment removal and slot unequipping when the equipment supports resources that are being used in connectivity services. 
      • This appears to potentially require a deleted-supporting state to maintain the presence of the resources used, even though they are not present in the network, as clearly the connectivity-service is intent and the current solution may be working adequately (as it has protection).
      • An alternative is to strip out the porting of the service that is no longer relevant so as to cause rerouting etc.
      • The behavior may depend upon policy and hence perhaps there is a set of candidate behaviors including both of the above etc.
    • Gather Ethernet model work from MEF (via liaison) and update TAPI. Develop TR-547 equivalent use cases for Ethernet.
    •  
  • No labels