TAPI support for Control Plane #657
Description
TAPI provides some support for control plane capabilities but does not support all flexibility necessary in some networks.
Several extensions are required based on the ITU-T ASON/ASTN definitions focussing on network modelling, with a similar scope to that used by TM Forum in TMF814 (as described in SD1-45 and SD1-46) for a single routing area. The solution should be developed considering concepts and terminology but utilizing standard TAPI classes where possible.
Supporting
- Link abstraction from native technology to SNPP Link joining SNPPs... where the abstraction allows both the partition of resources from the underlying technology and the aggregation of capacity from several partitions
- Use of Path and Path Sets... allowing path set and path to be constraints in a connectivity service request
- Control plane connection terminated on SNPs within SNPPs... Control Plane connection may be supported by several native technology connections and where a native technology connection may support several control plane connections (e.g., unidirectional)
Considering reuse of existing TAPI classes (each with a distinguishing property), use of Path and PathSet implies that the SNPP Link capability should be modelled as a TAPI Link, then:
- SNPP SubNetworkPointPool) would be modelled as a NEP
- SNP (SubNetworkPoint) would be modelled as a CEP
- Control Plane connection would be modelled as a TAPI connection
The model should allow for simplification where the relationship between the control plane link has a 1:1 relationship with the native technology link and where the control plane connection has a 1:1 relationship with a native technology top connection. This would allow the current representations to remain compliant whilst also providing an approach to support more sophisticated solutions.
Note: This issue was raised by Nigel Davis on behalf of Marie-Hélène Payette of Bell Canada.