Child pages
  • Contributions

INTERNATIONAL TELECOMMUNICATION UNION

TELECOMMUNICATION
STANDARDIZATION SECTOR

STUDY PERIOD 2017-2020

SG15-TD 163R1/Plen

STUDY GROUP 15

Original: English

Question(s):

14/15

Meeting:

Geneva, 29 Jan. – 9 Feb. 2018

Study Group:

Study Group 15

Working Party:

WP3

Source:

Editors G.7711/Y.1702

Title:

Draft revised Recommendation ITU-T G.7711/Y.1702 (Editor version v2.02) Generic protocol-neutral information model for transport resources (for consent)

Purpose:

[Choose a purpose from the dropdown list]

Contact:

Hing-Kam LAM
FiberHome
P.R. China
 

Tel: +1 732 275 4646
Fax: +xx
E-mail: kamlam@fiberhome.com

Contact:

Xiang YUN

FiberHome

China

Tel: +86.135.1720.3187
Fax:
Email:yunxig@fiberhome.com

 

Scott Mansfield

Ericsson

Canada

Tel: +1 724-931-9316

Fax:

Email: scott.mansfield@ericsson.com

Keywords:

G.7711/Y.1702;  

Abstract:

The document contains the editor version of G.7711 “Generic protocol-neutral information model for transport resources”.  The document will be used for preparing the future Amendment or Revision of the Recommendation.

 

EDITOR NOTE:

 

 

Document history :

Version

Date

Description

2.01

WD35 (2/2017) Beijing

Initial version created by taking the in-force (pre-published) G.7711 (12/2016) as the base and incorporating the following updates

  • Update Appendix IV.6 per the agreement of the WD21 discussion
  •  

Model development environment

  • Eclipse: Mars.3 (4.5.3)
  • Papyrus: 1.1.0
  • Open Model Profile: 0.2.0

2.01.1

WD091014-28 (4/2017 Tokyo)

Update clause 8, Appendix IV, and add bibliography for pointing to the software repository of the UML model files, profile files, and data dictionary.

No update to the UML model.

To do in June regarding the environment: Update the profile for all models together

2.02

TD163R1/PLEN (2/2018)

     Align the text with the 12/2016 in-force published version

     Update the G.7711 UML model to align the Core Model with ONF TR-512 v1.3.1

     Add description text:

-           New Annex H, I, J, K

-           New Appendix V, VI, VII, VIII, IX, X, XI, XII, XIII, XIV

-           Update main clause and other annexes & appendixes

     Update the document structure as agreed at the 12/2017 London Interim meeting (see Annex 7 of the London meeting report TD144/WP3)

      

 

NOTE: For the editor draft of G.7711, a 2-field or 3-field version numbering convention is used.

-           The first field indicates the public publication revision number.

-           The second field indicates the editor version of the UML model (and base document). This field is incremented when the UML model, and thus the base document too, are updated.

-           The third field is used to indicate only the base document is updated and there is no update to the UML model.


Fond-Rec_e  

 

 

International Telecommunication Union

 

 

ITU-T

G.7711/Y.1702

TELECOMMUNICATION
STANDARDIZATION SECTOR
OF ITU

(12/2016)  

 

SERIES G: TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKS

Data over Transport – Generic aspects   – Transport network control aspects

SERIES Y: GLOBAL INFORMATION INFRASTRUCTURE, INTERNET PROTOCOL ASPECTS, NEXT-GENERATION NETWORKS, INTERNET OF THINGS AND SMART CITIES

Internet protocol aspects   – Operation, administration and maintenance

 

Generic protocol-neutral information model for transport resources

 

Recommendation  ITU T  G.7711/Y.1702

 

logo_E


ITU-T G-SERIES RECOMMENDATIONS

TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKS

 

 

INTERNATIONAL TELEPHONE CONNECTIONS AND CIRCUITS

G.100–G.199

GENERAL CHARACTERISTICS COMMON TO ALL ANALOGUE CARRIER-TRANSMISSION SYSTEMS

G.200–G.299

INDIVIDUAL CHARACTERISTICS OF INTERNATIONAL CARRIER TELEPHONE SYSTEMS ON METALLIC LINES

G.300–G.399

GENERAL CHARACTERISTICS OF INTERNATIONAL CARRIER TELEPHONE SYSTEMS ON RADIO-RELAY OR SATELLITE LINKS AND INTERCONNECTION WITH METALLIC LINES

G.400–G.449

COORDINATION OF RADIOTELEPHONY AND LINE TELEPHONY

G.450–G.499

TRANSMISSION MEDIA AND OPTICAL SYSTEMS CHARACTERISTICS

G.600–G.699

DIGITAL TERMINAL EQUIPMENTS

G.700–G.799

DIGITAL NETWORKS

G.800–G.899

DIGITAL SECTIONS AND DIGITAL LINE SYSTEM

G.900–G.999

MULTIMEDIA QUALITY OF SERVICE AND PERFORMANCE – GENERIC AND USER-RELATED ASPECTS

G.1000–G.1999

TRANSMISSION MEDIA CHARACTERISTICS

G.6000–G.6999

DATA OVER TRANSPORT – GENERIC ASPECTS

G.7000–G.7999

General

G.7000–G.7099

Transport network control aspects

G.7700–G.7799

PACKET OVER TRANSPORT ASPECTS

G.8000–G.8999

ACCESS NETWORKS

G.9000–G.9999

 

 

For further details, please refer to the list of ITU-T Recommendations.

 

 


Clause 1 through Clause 8

 

Editor Note: See the companion file “ TD163r1.PLEN_g7711_v2.02_ PART-1 _Body.docx ” for the text of Clause 1 through Clause 8 of the Recommendation.


Annex A through Annex K

 

Editor Note: See the companion file “ TD163r1.PLEN_g7711_v2.02_ PART-2 _Annex.docx ” for the text of Annex A through Annex K.


Appendix I

Mapping of ITU-T G.7711/Y.1702 to ONF technical recommendations

(This appendix does not form an integral part of this Recommendation.)

The core model of the CIM has also been published as [b-ONF TR-512]. This appendix provides a mapping between the documentation structure of this Recommendation and ONF technical recommendations, in particular [b-ONF TR-512]. See Table I.1.

Table I.1   – Mapping of the documentation structure of this Recommendation
and ONF technical recommendations

ITU-T G.7711 /Y.1702 structure

ONF TR-512 equivalent

g7711_v3.0.zip

TR-512_v1.3.1-info.zip

Software (folder)

 

G.7711_v3.0_PAP (folder)

 

G7711Model (folder)

.project, CoreModel.di, .notation, .uml

 

OpenModelProfile (folder)

.project, OpenModel_Profile.di, .notation, .uml

 

G.7711_v3.0_DD.docx

TR-512.DD_v1.3.1-info_OnfCoreIm-DataDictionary.docx

G.7711_v3.0_DD_Script_for_Gendoc.docx

 

G.7711_v3.0_ Script_for_Gendoc.docx

 

Readme.txt (TSB)

 

ITU-T G7711-Y1702.docx

TR-512.1_v1.3.1_OnfCoreIm-Overview.docx

Annex A Guidelines And Tooling (pointer)

TR-514 v1.2 and TR-515 v1.2

Annex B Forwarding And Termination

TR-512.2_v1.3.1_OnfCoreIm-FaT.docx

Annex C Foundation – Identifiers, Naming, States

TR-512.3_v1.3.1_OnfCoreIm-Foundation.docx

Annex D Topology

TR-512.4_v1.3.1_OnfCoreIm-Topology.docx

Annex E Resilience

TR-512.5_v1.3.1_OnfCoreIm-Resilience.docx

Annex F Physical

TR-512.6_v1.3.1_OnfCoreIm-Physical.docx

Annex G Specification

TR-512.7_v1.3.1_OnfCoreIm-Specification.docx

Annex H Control

TR-512.8_v1.3.1 Control

Annex I OAM

TR-512.9_v1.3.1 OAM

Annex J Operation Pattern

TR-512.10_v1.3.1 Operation Pattern

Annex K Processing Construct

TR-512.11_v1.3.1 Construct

Appendix I Mapping of this Recommendation to ONF technical reports

Add TR-512.A.1

Appendix II Data Dictionary
(ptr to G.7711_v2.0_DD.docx)

TR-512.DD_v1.3.1_OnfCoreIm-DataDictionary.docx

Appendix III Terminology Mapping

TR-512.TM_v1.3.1_OnfCoreIm-Terminology.docx

Appendix IV Core Model Enhancement

TR-512.FE_v1.3.1_OnfCoreIm-FurtherEnhancement.docx

 

TR-512.11_v1.3.1_CommonDefinitions.docx

Appendix V

A.2 Model Struct pattern & Architecture

Appendix VI

A.3 Rationale of Models

Appendix VII

A.4 Analogue and Media (L0) examples

Appendix VIII

A.5 Circuit Switched (L1 & L2) examples

Appendix IX

A.6 Packet Switched (L2 & L3) examples

Appendix X

A.7 Control and Signalling examples

Appendix XI

A.8 Timing & Synchronization examples

Appendix XII

A.9 Processing Construct examples

Appendix XIII

A.10 Specification examples

Appendix XIV

A.11 Resilience examples

Appendix XV

A.12 Application (L4 and above) examples

 

 

The following subclauses provide an overview of Appendix V through Appendix XIV. These appendix clauses provide descriptive support for the CIM by explaining the rationale behind the model and giving examples.

I.1 Model Structural Patterns and Architecture ( Appendix V )

This appendix explains the model patterns and architecture that underpin the CIM. It:

  • Works through the key patterns in the model such as hypergraph and component-system.
  • Discusses the fundamentals of transport and how these are described in terms of the patterns
  • Shows some high level examples of the patterns
  • Explains how the patterns can be intertwined to form the architecture of the network from a control perspective

The descriptions in this appendix are built from descriptions in earlier referenced works.

Figure I- 1 The Component

I.2 Rationale Behind the CIM (Appendix VI)

This appendix provides the drivers for the CIM work and highlights benefits of the work to the industry.

The appendix explains that management of networks and devices today is a complex operational challenge resulting from, and exacerbated by, the plethora of conflicting standards and incompatible implementations. Almost all of the existing models use inconsistent terminology and outdated concepts that aren't applicable to SDN/NFV scenarios.

The appendix goes on the explain that the Information Modeling team:

  • Has defined a consistent set of fundamental concepts and the relationship among them by leveraging the knowledge gained from years of management standards evolution and pragmatic implementation/software development experience. These concepts are capable of representing both legacy management and SDN/NFV concepts/scenarios, while allowing for consistent management in hybrid environments.
  • Employs a realistic federated model with a layered model architecture and managed dependencies. This is comprised of a stable core model (which is itself modular for scalability) and technology-specific model extensions that can be added in a timely manner without destabilizing the core.

It is emphasized that the CIM model is not a purist, theoretical artifact, but a pragmatic one that forms part of a tooling chain, enabling context and technology specific interfaces in different languages to be generated from a key set of definitions. 

The appendix explains the growing utilization of the CIM across various bodies such as ONF, ETSI NFV, MEF and TMF, as well as by some major service providers.

I.3 Analogue and Media (L0) examples (Appendix VII)

This appendix explains the model in terms of examples applied to the analogue space of Layer 0 (L0). The appendix focuses on optical photonics and guides the use of the model to represent both device functions and network structures.

 

Figure I- 2 Network Domain Channel formed from Media Channels

 

I.4 Circuit Switched (L1 & L2) examples (Appendix VIII)

This appendix progresses from basic single device circuit switched examples through to complex protection scenarios and multi-layer circuit switched examples. The appendix also provides multi-layer examples where:

  • Circuit switched forwarding is carried by an analogue server
  • An analogue signal is carried by a circuit switched system
  • There is a critical differential delay and a critical round trip delay consideration

I.5 Packet Switched (L2 & L3) examples (Appendix IX)

This appendix is not yet provided in this Revision of the Recommendation. It will be provided in a later Revision. The appendix will progress from basic single device packet switched examples through to complex network scenarios including multi-layer packet switched examples. The appendix  will also provide multi-layer examples where:

  • Packet switched forwarding is carried by a circuit switched server
  • Circuit switched forwarding is carried by a packet switched server
  • Packet switched forwarding is carried by an analogue server.

I.6 Control and Signaling examples (Appendix X)

This appendix is not yet provided in this Revision of the Recommendation. It will be provided in a later Revision. The appendix will progress from basic single device control examples through to complex peered control and multi-level control scenarios.

The appendix will also consider interworking with legacy control models.

I.7 Timing & Synchronization examples ( Appendix XI )

This appendix provides a description of time and frequency synchronization in a telecommunications network and provides examples of the use of the model to represent these synchronization functions.

Figure I- 3 Example synchronization distribution network

I.8 Processing Construct examples ( Appendix XII )

This appendix provides various examples of the use of the ProcessingConstruct model to represent complex functions.

 

Figure I- 4 "Virtual Device"

 

I.9 Specification examples (Appendix XIII)

This appendix provides various examples of the use of the CIM specification model to express constraints in various real contexts.

Figure I- 5 Example Use of FD Spec

 

I.10 Resilience examples ( XIV )

This appendix provides various examples of the use of the CIM to represent common resilience schemes. This appendix is not exhaustive. The model is built from a several generalized constructs that should readily support many other protection schemes not described here.

Figure I- 6 Simple summary example of 1?1 cases (represented  via partition)

 

I.11 Application (L4 and above) examples (Appendix XV)

This appendix is not yet provided in this Revision of the Recommendation. It will be provided in a later Revision. The appendix will progress from basic simple application through to complex application assemblies.


Appendix II

Data dictionary

(This appendix does not form an integral part of this Recommendation.)

The Data Dictionary contains, in MS Word document format, the details of the OTN NE management-protocol-neutral information model, including the description and properties of the object classes and their attributes and operations. These details information are generated automatically by a Gendoc tool from the UML model.

The ITU-T G.7711/Y.1702 data dictionary is provided in the G.7711_v2.00_DD.zip file at the repository website mentioned in Clause 8.

The data dictionary is divided up into four sections based upon the division of the CoreModel and maturity of work. The first three sections provide key information about the core network model (which includes topology), the core foundation model, the physical model and the specification model.

 

 


Appendix III

Terminology mapping

(This appendix does not form an integral part of this Recommendation.)

The focus of this appendix is mapping of terminology from that used in the Core Model to terminology from some other normative documents. This appendix only provides a lightweight view. The mappings provided are preliminary and may change.

A data dictionary that sets out the details of all classes, data types and attributes is also provided (Appendix II).

III.1 Terminology mapping table

Table III.1 sets out class mappings between the core model work and the work of a number of other bodies.

Table III.1 does not yet cover:

The specification classes (where there is a relationship to work in TMF)

Mappings to:

Neutron

IETF TEAS

OpenConfig

DMTF

ETSI-NFV

Etc.

The grey cells indicate that the work of the body does not have specific classes that directly support the meaning of the row (see the right most column). The pink cells identify where work is still required to determine the mappings.

 


Table III.1 – Class mappings

ONF

OIF

TMF MTNM

[b-TMF GB922]
Converged Network ABE

[b-TMF TR225]

[ITU-T G.8080]

[ITU-T G.800]

TAPI

Other terms

Brief meaning of the terms in the row

ForwardingDomain (FD)

 

Multi-Layer SubNetwork (MLSN)

ForwardingDomain

ForwardingDomain

 

Subnetwork

 

Network

A multi-layer form
Dealing with connection oriented

 

FlowDomain

 

Dealing with connectionless

 

MatrixFlowDomain

 

 

Switch fabric
Matrix

The switching capability in a network device that may be represented by an FD.

Subnetwork/Vertex

 

Subnetwork

 

Node

Element of a graph

Routing Area/Topology

Multi-Layer Routing Area (MLRA)

Routing Area

 

Routing domain

Domain for routing

Abstract Node

 

 

 

 

Abstract node

 

 

 

 

 

 

Node

 

The opaque view of an FD

 

 

 

 

 

 

Topology

 

The aspect of the FD that is the container of the layout of the topology

Link

 

 

TopologicalLink

ForwardingConstruct (use of)

 

 

Link

 

A fixed relationship between NodeEdgePoints in a Topology

 

 

Link

Link

 

 

A fixed relationship between subnetwork at a specific (CI) layerProtocol

 

SnppLink

 

 

 

 

An ITU-T G.800 link in the context of the ASON control plane

TopologicalLink

 

 

 

 

 

 

 

TopologicalLink

 

 

 

 

The abstract essence of the Trail

Link

 

 

 

 

 

 

Edge

 

 

 

 

 

Element of a graph

 

 

 

Transitional Link

 

 

A link where the ends are in different layers or sub-layers (e.g., an Ethernet TAG has been added)

 

 

 

 

 

Tunnel Facility

 

LinkPort

 

Element in a list in a TopologicalLink representing an end of the TopologicalLink

Element in a list in a TopologicalLink representing an end of the TopologicalLink or SnppLink

FcEndPoint of ForwardingConstruct

 

Link Port

LinkPort

 

A port on the component called Link

LogicalTerminationPoint (LTP)

 

 

Transmission path endpoint (TPE)

 

 

 

 

 

 

 

 

 

 

 

TPE

 

 

 

 

 

 

TP [precision time protocol/ connection termination point/ floating termination point (PTP/CTP/(FTP)]

 

Adaptation function Termination function
Forwarding Point
Forwarding End Point

 

TTP, CTP

The LTP is used to represent any of the ITU-T G.800 constructs, or a combination of these constructs across multiple layers

Edge Resource

 

SNP

 

 

 

An abstraction that represents a connection point (CP) or termination connection point (TCP)

 

SNPP

SNPP

 

 

 

Pool of SNPs, e.g., at the end of a link

 

 

 

 

 

Facility
Port
Protocol Endpoint

 

 

 

 

 

NodeEdgePoint

 

 

 

 

 

 

ServiceEndPoint

 

 

 

 

 

 

ConnectionEndPoint

 

 

LayerProtocol

 

Element in a list in TP

LayerTermination

LayerTermination

 

 

 

 

 

 

 

 

 

 

 

Adaptation function Termination function
Forwarding Point
Forwarding End Point

 

TTP
CTP

The LP is used to represent any of the ITU-T G.800 constructs, or a combination of these constructs in a single layers

ForwardingConstruct

Connection

SNC

Frame reference event (FRE)

ForwardingConstruct

Connection

SNC

Connection
ConnectivityService

 

A connection between CPs

 

 

 

Trail

 

 

A connection between access points

 

Forwarding domain fragment (FDFr)

 

 

 

 

Enabled forwarding for Connectionless.

 

Matrix forwarding domain fragment (MFDFr)

 

 

 

 

Enabled forwarding for Connectionless in a fabric.

Call

Call

Call

 

 

 

An association between two or more users that supports an instance of a service.

 

 

 

 

 

AccessRelationship
Tunnel
Line
Section
CrossConnection

 

 

 

 

 

SNP Link Connection

LinkConnection

 

 

 

FcPort

 

Element in a list in a SNC/Call representing an end of the SNC/Call

Endpoint

FcEndpoint

 

 

ConnectionPort
ServicePort

 

A port on a component called ForwardingConstruct

FcSwitch

 

Attributes in SNC

Attributes in FRE

 

 

 

 

 

 

FcRoute

 

Route

Route

 

Route

 

 

 

 

TopologicalEntity

 

 

 

 

 

 

 

 

 

TransferTiming_Pac

 

 

 

 

 

 

 

 

 

TransferIntegrity_Pac

 

 

 

 

 

 

 

 

 

TransferCost_Pac

 

 

 

 

 

 

 

 

 

RiskParameter_Pac

 

 

 

 

 

 

 

 

 

TransferCapacity_Pac

 

 

 

 

 

 

 

 

 

LayerProtocolTransition_Pac

 

 

 

 

 

 

 

 

 

Validation_Pac

 

 

 

 

 

 

 

 

 

SdnController

 

 

 

 

 

 

 

 

 

NetworkControlDomain

 

 

 

 

 

 

 

 

 

NetworkElement

 

ManagedElement

 

 

 

 

 

 

 

LayerProtocol

Layer

LayerRate

LayerRate

 

 

Layer

 

 

 

GlobalId

 

 

 

 

 

 

 

 

 

LocalId

 

 

 

 

 

 

 

 

 

Name

 

 

 

 

 

 

 

 

 

Address

 

 

 

 

 

 

 

 

 

Comments on column

Derived from work of and co-developed with ITU-T

Derived from ITU-T work

Derived from ITU-T work

Convergence of several TMF models

 

Generalized architecture

Pruned/refactored ONF Core Network Model (see Figure III.1).

 

 

 

 


III.2 Detailed view of transport application programming interface to core model mapping

Figure III.1 is a snapshot of the ONF TAPI to Core Model mapping. It is possible that the details of the mapping will change. For the most up to date mapping, see [b ONF/Snowmass].

C:\Users\ndavis\git\ONFOpenTransport\TransportAPI\UML\figures\Tapi_Core_Mapping.PNG

Figure III.1 – Core – Transport application programming interface mapping
(via pruning and refactoring)

III.3 Model evolution

Figure III.2 shows the relationships between some key modelling activities. Figure III.2 is somewhat speculative. The joint working proposed has not yet materialized.

Figure III.2 – Model Evolution History and Proposal


Appendix IV

Core model enhancement

(This appendix does not form an integral part of this Recommendation.)

The focus of this appendix is areas of ongoing work that are not represented in the annexes.

A data dictionary that sets out the details of all classes is given in IV.1 to IV.5, data types and attributes are also provided in Appendix II. Clauses IV.1 to IV.6 provide a summary of the enhancements.

EDITORIAL NOTE – The UML figures contained in this Recommendation are also available in png format here .

Potential future areas of work in the CoreModel include, not in any particular order:

  • Signaling and management-control messaging (Annex H, Appendix IX and Appendix X)
    • Developing models for signaling/messaging in the context of ECC/DCN and protection
      • This leads to the need to develop support for basic IP networking
  • Interface patterns for advancement of TAPI etc (Annex J and Appendix X)
    • Completion of the generalized operations pattern covering range of cases including intend and CRUD
      • Support operations patterns including intent
      • Support TOSCA and policy
      • Operations interaction model
      • Operations temporality
    • Understand the relationship with Dynamic APIs and Strategic Mediation
  • Support for specific interface development in TAPI (various)
    • More layer examples (Appendix VII, Appendix VIII, and Appendix IX)
  • OAM functions (Annex I and Appendix X)
    • Generalization of OAM functions, e.g., generalized MEPs
    • Consider use cases and scenarios to guide development of the generalized model
  • Assurance (Annex J and Appendix X)
    • Modeling of events and the reporting of events
  • Patterns and architectures (Appendix V)
    • Continue construction of models that explore the pattern underlying Link/FC/FD and minimally represent that pattern and show derivation of Link/FC/FD from that pattern.
  • Dependency graph representation of telecommunications technology including flow semantics (Appendix V)
    • For expression of detailed processes of a telecommunications technology to enable interpretation of a new technology
  • Profiles, Templates and Specifications (Annex G and Appendix XIII)
    • Completion of spec model and addition of profiles model in the spec context
    • Further development of constraint models (also covering policy)
    • Complete pattern and migrate model to use pattern
    • Develop class based rule mechanism and consider more fluid approach to Core model
    • Provide further examples of usage
    • Develop detailed rules
    • Refine model to deal with rule interaction
    • Consider FD/FC spec convergence
      • FdPort added will help here
    • When dealing with Compound Links we need to consider whether rules are necessary for Link (the same structure will apply but an additional association from Link to FD will be necessary)
    • Development of a specification toolkit including standardized rules and structures
    • DSGL (Domain Specific Graphical Language to ease spec construction)
    • Model v specification (see also notes in Annex G):
      • Implication of the work so far is that the specification structure is the model structure and that the schema for any particular case has some parts of the structure in compile time form and other parts in runtime only form where the runtime form may have static parts only in the spec form
      • Is a replication of the model structure in formal model but that formal model should be decoupled at various points and extensible in a constrained way at various points.
      • Considerations of "model viscosity"  (all models are fluid over some timeframe)
    • Dealing with LTP and LP formal sub-structuring challenge
      • Related to the previous bullet… should the LP sub structuring of the spec model be part of the LP model
    • Migration of operations from non-spec to spec
      • Continuum of usage approaches from "phrase book user" to "orator"
    • FcSpec refinements
      • Should the FC spec be rationalized to recognise that MSUF is essential an FC (implications etc)?
    • Moving to the generalized spec
      • How should constraints on each class spec be expressed in the context of a generalized spec?
    • Understanding the relationship to Dynamic APIs, Strategic Mediation and the Operations Patterns
    • Enhance the extension mechanism
    • Development of the scheme specification
      • Generalization to deal with specification of any network structure
      • Enhance the application to protection
  • Resilience (Annex E and Appendix XIV)
    • Further development of the scheme specifications for resilience schemes
    • Carry out further work on the unexpected flow query
    • Use of partition v route and use in combination (see .5 for some notes)
    • Build on the model of signalling to deal specifically with resilience schemes (see Annex E for some detailed considerations). This will be related to work in
      • Annex H as this will be part of the MCC work as the C&SC is a controller and general messaging and signalling will be covered in Annex H
      • Annex G as there is a specification aspect
    • Refine documentation on relationship to protectionGroups (see notes in Annex E)
    • Complete route feeds port relationship
    • Complete route lifecycle documentation (see Annex E)
    • Indication of encapsulated resilience on FC and Link
    • Further examples including dual homed cases
  • Control (Annex H, Annex K, Appendix X and Appendix XII)
    • Improvements to documentation on replacement of NE
  • Timing and Synchronization model including frequency and time/phase (Annex B and Appendix XI)
    • Complete work and examples
  • Physical Equipment (Annex F)
    • Completion of the equipment model
    • Enhancements to the expectation v actual model approach (see detailed notes in Annex F)
    • Progress attribute details to «Preliminary» or «Mature»
    • Rationalize attribute groupings
    • Look for formal sources for physical properties and work towards a P&R relationship to these sources
    • Strengthen linkage and improve decoupling wrt other model areas
      • For functional work wrt ProcessingConstruct (Annex K and Appendix XII) and OAM functions (Annex I and Appendix X)
        • Also see detail notes in Annex F
    • Separate out Management-Control parts into Management-Control model (Annex H and Annex X)
    • Refine and move specification model detail from Physical model document to Specification model document and move model as appropriate (Annex G and Appendix XIII).
    • Addressing of ports (see Annex F for some details)
  • Software (new Annex and Appendix)
    • Representation of software and relationship to physical (Annex F)  and functional (Annex K) models
  • ProcessingConstruct (Annex K and Appendix XII)
    • Document relationship to:
      • TOSCA meta-model
      • Component
      • VNF
    • Degree of specialization (related to Appendix V.A.2)
      • PC v ControlComponent v C&SC
      • PC v FC
      • CD v FD
    • Component-System recursion and projecting views
    • PC emergence from software (see also Software in this list)
    • CD/PC spec
  • FC, FD, Link and Topology (Annex B and Annex D)
    • Various detailed enhancements including considerations of merging of FC and Link
    • Consider merging FD and Link
    • Improve derivation of FD/FC/Link from Component-System pattern (Appendix V)
      • Consider FC/Link convergence (Annex D)
    • Further clarification of off-network "things" (could be a link topology)
    • Various illustration of FD/Link lifecycle
      • Consider generalized lifecycle state and state interaction
    • Cost algorithm
    • Illustrate use of model for inverse multiplexing cases (Appendixes VII, VIII, and IX)
    • Improve documentation on terminationState
    • Stating detailed properties on topology
    • Rationalize use of NearEnd/FarEnd, Input/Output, Ingress/Egress etc
    • Further develop Transitional Link examples (in A.5 and .A.6) to cover complex Links (see Annex D)
    • Further develop non0orthogonal FDs (see .4) and provide examples (in Appendixes VII, VIII, and IX)
  • View abstraction (Annex D)
    • Enhancements to view abstraction examples and cases, including FD view, FC view, Call view, Service view, Connection view
    • Further work on rules for virtualization (e.g. what from one view can be grouped in the same link from another view)
  • Lifecycle (Annex C)
    • Entity lifecycles including splits and merges
  • Mapping to other models (Appendix III)
    • Enhancements to the mapping to OpenFlow
    • Development of mappings to IETF models (e.g. TEAS)
    • Mapping to TOSCA
    • Aim for convergence of industry models
  • Temporal properties (new Annex and Appendix document)
    • Determining how to inject temporal aspects into the model process
  • Stating rules and constraints (various including Annex A and Annex D)
    • Method for statement of inter-attribute and inter-association rules
    • See also subsections below
  • Model restructuring (Main body and new Appendix)
    • Decoupling for improved modularity and independent working (new Appendix)
    • Model federation (new Appendix)
    • Model patterns (new Appendix)
  • Minor enhancements
    • Rename the LayerProtocol class
  • Documentation
    • Ongoing improvements

The following are some detailed notes on future enhancement.

IV.1 Controller model

Work is underway to develop a model of management-control that replaces the SdnController, NetworkControlDomain and the NetworkElement with a unified model of control that also includes the ConfigurationAndSwitchController discussed in Annex E.

 

IV.2 State extensions

There are a number of experimental items in the state model shown in Figure IV.2. These are included in the main data dictionary.

 

Source Papyrus CoreModel diagram: EnhancedStates

Figure IV.2 – State model with enhancements

IV.3 Model structure rules

Some of the associations in the model are interrelated by some pattern. Figures IV.3 to IV.6 explore ways of expressing the patterns and interrelationships.

 

Source Papyrus CoreModel diagram: HighLevelSkeltonOverviewWithLoopsHighlighted-Altenative1

Figure IV.3 – Association interrelationship rules alternative 1

Source Papyrus CoreModel diagram: AlternativeNavigationRuleExample-LinkFdLtp

Figure IV.4 – Highlighting loops and spirals

Source Papyrus CoreModel diagram: AlternativeNavigationRuleExample-FcPort

Figure IV.5 – Highlighting loops and spirals - FC, FcPort and FcSwitch example

Source Papyrus CoreModel diagram: NoLoopRuleExample-FdLinkAndFcFcRoute

Figure IV.6 – No Loops Rule

IV.4 Strict Composition

Although the concept is now relatively stable, there are some potential enhancements. The Strict Composite form is shown in Figure IV.7.

The approach uses a stereotype to identify complete dependency. In the model shown in Figure IV.7, reporting the FC without its FcPorts is not useful, whereas reporting the FC without its FcRoute is useful.

A route has a life bounded by that of the containing FC, as does an FcPort.

 

Source Papyrus CoreModel diagram: StrictCompositionFcDetailExample

Figure IV.7 – Strict Composite

IV.5 Multiplicity restrictions

Many multiplicity ranges have subtle case based restrictions that are not reflected in the model. Figure   IV.8 provides a view of a simple approach to recording multiplicity restrictions.

Source Papyrus CoreModel diagram: MultiplicityRuleExamples

Figure IV.8 – Multiplicity rule example

 

 


Appendix V

Model Structure, Patterns and Architecture

(This appendix does not form an integral part of this Recommendation.)

This appendix explains the model patterns and architecture that underpin the CIM. The document:

  • Works through the key patterns in the model such as hypergraph and component-system.
  • Discusses the fundamentals of transport and how these are described in terms of the patterns
  • Shows some high-level examples of the patterns
  • Explains how the patterns can be intertwined to form the architecture of the network from a control perspective

The descriptions in this document are built from descriptions in earlier referenced works.

V.1 A progression patterns – intertwining and unfolding

This clause works through rationale for the formation of the model by considering the essential underlying patterns that govern the inherent structure of the problems space it is based heavily on work from TM Forum that was liaised to ONF for developing the Core Model, with corporation with ITU-T.

A number of patterns are explored in a progression from the most fundamental through to more problem space specific. Each of the patterns is introduced in the context of the emerging model, first working towards an information architecture and then on to the CIM.

The basic underpinning of the model is essentially the representation of adjacency (connectedness) and through this adjacency there is an opportunity for some essence to pass between the adjacent places. The fundamental representation of this opportunity is the notion of a graph and due to the complexity of the problem space the hypergraph generalization of the graph has been chosen as a basis.

V.1.1 Hypergraph pattern

A hypergraph [1] is a generalization of a graph in which an edge can associate any number of vertices (see http://en.wikipedia.org/wiki/Hypergraph ). The edge in a hypergraph is called a hyper edge (or hyperarc). The hyper edge can be directed (see http://www.scielo.br/scielo.php?script=sci_arttext&pid=S0101-74382005000300005 ).

The basic hypergraph is represented in the UML fragment below.

 

CoreModel diagram: Hypergraph-BasicStructure

Figure V- 1 The basic hypergraph model fragment

The hypergraph appears to have flexibility beyond that required by the problem space.

  1. The general hypergraph allows the hyper edge to exist without any vertexes and the vertex to exist without any hyperedges. The vertex and hyper edge appear symmetric.
    • In the model above the vertex has been constrained to only be allowed in the presence of at least one hyperedge
    • The vertex appears to represent both the potential to join hyperedges and the actual joining of hyperedges
    • A constrained form of hypergraph has been developed below that restricts the vertex to only be allowed in the presence of two or more hyper edges such that the vertex represents only the joining of hyperedges. The potential to join is separated out and associated with the hyperedge as a vertex opportunity
  2. A hyperedge has no restriction on the number of hyperedges it can associate with via vertexes. In the problem space there is always at least an upper bound and in many cases a specific set of opportunities.
    • The constrained form of hypergraph is defined such that joining is only allowed where there is a stated opportunity (a VertexOpportunity).
  3. A hyper edge can exist with no vertexes.
    • Whilst it seems reasonable that a hyperedge may be not associated with a another hyperedge via a vertex it does not appear meaningful for a hyper edge to exist with no vertex opportunities hence the vertex opportunity is [1..*]
    • A thing with no ability to form a relationship with other things appears irrelevant. A thing is nothing without its relationship

 

CoreModel diagram: Hypergraph-BasicConstrained

Figure V- 2 A constrained hypergraph

In the figure above the direct association between the hyperedge and the vertex is simply a summary of the associations via the vertex opportunity. The vertex only represents the joining of two hyperedges through their vertex opportunities.

The figure below adds directedness recognizing that the edge represents an adjacency only in one direction and hence there is an opportunity to pass from one vertex to another but not the reverse. The directionality has been added to the vertex opportunities rather that the edge to provide the necessary clarity.

 

CoreModel diagram: Hypergraph-BasicDirectedConstrained

Figure 3 - 3 A constrained hypergraph

In general a directed hyperedge may represent adjacency between several ingress vertex opportunities and several egress opportunity. It is also possible that although a hyperedge groups a set of non-disjoint vertex opportunities not all ingress vertex opportunities are adjacent to all egress opportunities. This can be expressed as hypergraph encapsulated within the hyperedge where the hypergraph expresses the restrictions of the hyperedge. The association HypergraphViewedAsOpaqueHyperEdge in the figure below enables this.

It appears that the basic hyperedge is a unidirectional construct with a n ingress opportunities and m egress opportunities where all ingresses are adjacent to all egresses. This element appears to be the basis of all topological forms.

It is possible for a specific hyperedge that some vertex opportunities may be bidirectional and others unidirectional. This may also be expressed as an underlying hypergraph.

Some of the vertex opportunities of hyperedges in a hypergraph may be exposed as hyperedges at the boundary of the encapsulating (more abstract view) hyperedge whilst others may be internal and not exposed. The hyper edge is an opaque view of and underlying hypergraph that may be asymmetric.

It is possible that several vertex opportunities in a detailed view can be considered as a single vertex opportunity in an abstract view. It is also possible that a vertex opportunity can appear in several abstract views.

 

CoreModel diagram: Hypergraph-RecursiveConstrainedForm

Figure V- 4 A recursive hypergraph

The vertex appears somewhat redundant as it now only represents the binding of two vertex opportunities and hence it can be replaced with a simple association which represents the touching of two vertex opportunities as shown in the figure below.

 

CoreModel diagram: Hypergraph-RecursiveConstrainedHypergraphWithImplicitVertex

Figure V- 5 A recursive hypergraph

V.1.2 Component – System pattern

Up to this point the adjacency has been considered as invariant and absolute. In any natural context the structure will vary over time and the degree of adjacency will not be absolute. This is considered in more detail below and in a later section. From a general perspective each adjacency can be considered as having a time dimension and variable degree of adjacency between the vertex opportunities. This variability can be expressed in terms of some adjacency function. A simple form of this could a binary on/off consideration but in general this would be a combination of analogue properties.

As noted earlier the adjacency represents the opportunity to pass from one vertex opportunity to another. The time variable function adjusts opportunity to pass between the vertex opportunities.

Some of the variation may be "natural" whereas other variation will result from modulating control. The modulating control would essentially define the function [2] . The modulating control is itself formed from a complex hypergraph.

As a result complex behaviour can be built up in the form of hypergraphs of time variable hyperedges. In this context the terms component and system (a complex assembly) appear more appropriate. The figure below shows the adjustment of hypergraph to relate to component-system. In this view the vertex opportunity becomes a port of the component. This is essentially the core of the component – system pattern.

 

CoreModel diagram: Hypergraph-RecastingRecursiveHypergraphAsComponentSystem

Figure V- 6 A recursive hypergraph

In the communication/compute/cloud problem space the pure hyperedge is insufficient as a representation of communications and processing structure and the component – system pattern appears suitable. As noted above the component aspect of the Component-System pattern is developed from the "multi-pointed" time-varying (functional) hyperedge. From a communications perspective adjacency being the opportunity to pass from one vertex opportunity to another deals with the concept of flow across the hyperedge/component (this is discussed further later) and asymmetry of the flow, i.e. that the accesses via the vertex opportunities of the hyperedge are not all equal.

In essence, the component is an extension of hyperedge where the Component is a hyperedge endowed with functionality to support processing of information [3] and endowed with properties at its facets (where vertexes can be) that describe inherent asymmetry and capability.

The System aspect of the Component-System pattern is developed from the hypergraph where a mesh of Components interrelated at two sided vertexes to form a system.

The Component in the pattern is an encapsulation of a System. A fabric of interconnected components can be viewed in many ways and hence there are potentially many Encapsulation views. The process of transitioning from the System to Component is not necessarily partitioning and hence the representation of transition from one view to another is not composition.

  • A component is an encapsulation view of an underlying system of components
    • It is defined by a boundary with ports
    • It obscures the encapsulated system (it is essentially opaque)
    • As it is a view it cannot be assumed that the underlying system has an actual boundary where it appears to be in the view, i.e. there is no enforced containment
    • Essentially there may be many offset views of the underlying system
    • Note that the components in the system of components are also views!
  • The characteristics of a component can be described in terms of an apparent system of components joining its ports
    • The apparent system of components may be quite unlike the actual encapsulated system
    • When managing a component the MCC (Management Control Continuum) [4] component talks to the component about the components that describe its capabilities
    • An MCC component presents a view of the system of components it is managing-controlling. Another MCC component may talk to the MCC component about those components it is managing-controlling

On investigation, the traditional notion in telecoms of the fabric of a switch being the vertex (node) in a graph appeared inappropriate. The original exploration recast the Subnetwork/fabric/etc and the Link/Trail/etc essentially as hyperedges. It was noted that a vertex could be limited to one pair of hyperedges. Subsequently it became apparent that the traditional point in the telecoms model was actually also a small hyperedge and it was instead, for example, the interface formed between a facet of the hyperedge representing the point and a facet of the hyperedge representing the Subnetwork that was the two-sided vertex.

V.1.2.1 Aspects not yet covered

The following areas need to be explored further:

       Directionality

       Add input and output to the vertex opportunities

       Show edges encapsulating edges to give bidirectional

       Merge and split of model elements over time

       Develop notion of information flow (and information passing) and note dimensions wrt essence of information and function

       Consider disjoint sets and note complex multidimensional jointedness (where it is a common property – i.e. some mediation)

V.1.3 Encapsulation pattern

The encapsulation pattern focusses on the notion of enclosing the detail, such as structure, information and properties, of some assembly of things in another thing such that the detail is not visible at all, or is only visible in abstract form as properties and at ports of the enclosing thing.

In a Hypergraph, a hyperedge apparent in one view may be concealing detail of a subordinate hypergraph in another view, i.e. the concealing hyperedge can itself be decomposed into a hypergraph of hyperedges and vertices where vertices of the concealing hyperedge are abstract representation of verticies at the edges of the concealed hypergraph.

Encapsulation is a process of transition from one view to another. A single model may encompass several views, and the views are not constructed by simple processes such as partitioning although in some cases they may appear to be.

To implement the pattern as a model, there needs to be representations that allow the encapsulating class to associate to the encapsulated classes and associations in such a way as to prevent illegal encapsulations (e.g. of one lone association, associations that are not related to the encapsulated classes) [5] . The rules that govern the encapsulation should be formalized and codified in a compact language representation [6] .

Within a view, encapsulation may vary across the view and may vary for any particular instances over time depending upon specific interest and allowed visibility. A variable encapsulation approach is already used for the LTP [7] .

V.1.3.1 Related modeling principles

  • If the positional bounds of two related concept instances are coincident for their entire lifecycle, then they may be merged into a single entity instance representing the composite concept and hence share an identifier etc.
  • If the positional bound of one concept instance is a subset of the positional bound of another concept to which it is related for its entire lifecycle and where that larger concept can be considered as a dominate definition, then the entity representing the smaller concept may be subsumed into the entity representing the larger concept and hence be identified as part of the entity for that larger concept in terms of attributes of that larger concept
  • If the positional bounds of several instances of a concept are all subsets of the positional bound of another concept to which they are related for their entire lifecycle and where that larger concept can be considered as a dominate definition, then they may be subsumed into the entity via a composition relationship
  • If a concept instance that bridges two other concept instances (of the same or different types) is, in the particular case, devoid of anything but identity then it may be represented simply by associations between the entities representing the two other concept instances
    • The associations may be two way navigable or one way navigable depending upon the original associations
  • If a concept instance that is a leaf is devoid of anything but identity, then it may be omitted

V.1.4 Transfer – Transform pattern [8]

The essential purpose of a telecommunications system is to make distant things seem adjacent (it provides an apparent adjacency service). This is achieved by transfer of information, and hence the fundamental function of telecommunications is the Transfer function. From the user perspective the telecommunications system is a (rather vast) Transfer Component.

To achieve transfer, there is a need for some mechanism to encode the information in a way that allows the transfer of (the client) information and hence a need to transform the information (and eventually transform the resultant information into a signal that can be propagated in a media). So the second vital function is signal Transformation and hence the second element of this essential telecommunications pattern is Transform.

In the most abstract form, the Telecommunications network is a system of Transfer and Transform Components. 

Both Transfer and Transform components follow the Component-System pattern discussed above and hence have ports. These ports are bound to form a network of components where the bindings form interfaces (or points) [9] .

V.1.5 Realized Potential

Transfer/Transform capacity in the telecommunications system may either be available to be configured for use (potential to enable Transfer/Transform functions) or may be allocated, configured and enabled for use in some way (enabled constrained Transfer/Transform functions) or may be being used (used Transfer/Transform functions). From a Management/Control perspective the potential to enable functionality and the enabled constrained functionality are two key considerations.

The Transfer – Transform pattern can be duplicated and intertwined in such a way as to form a two level model where one level represents the potential functionality (which is essentially a pool of available capacity) and the other the enabled functionality (which is essentially capacity used from the pool).

Because of the hypergraph nature of the Transfer – Transform pattern, these two levels are interdependent hypergraphs where the topology of the enabled functionality hypergraph is necessarily the same as that of a subgraph of the potential functionality hypergraph.

Because of the Component System nature of the Transfer – Transform pattern, a view of the functional hypergraph may be taken where subgraphs of that hypergraph are encapsulated. Each subgraph is encapsulated in a single Transfer/Transform Component. The whole assembly of Components constructed via these encapsulations forms a more compact and abstracted functional hypergraph.

V.1.6 Protocol "layering"

First it is necessary to clarify the Transform function by considering the following

  • There is some need to transfer "payload" [10] (Client) information to achieve the "proximity" service noted earlier
  • A protocol is invented and defined in terms of some data structures that carry information necessary to enable the transfer of the "payload" information.
  • The protocol is defined to enable a transmitter to be constructed that can format a signal as per a defined structure to carry the necessary information to a receiver so that that receiver can then decode the structure and extract the "payload" information with no relevant change to that "payload" (it may be delayed a bit etc. but that is within its spec)
  • The protocol includes various structures of "maintenance" information to ensure error detection and potentially error correction within the bounds of some defined operations limit, as well as to enable various other integrity validation and communication mechanisms to operate that are deemed necessary or considered useful in the transfer of the "payload" information. Some elements of the protocol may be optional
  • Any receiver that can interpret all of the mandatory structure of the protocol is sufficiently conformant with the protocol to provide basic interoperability
  • It is possible that two protocols are defined that have some subset of interoperability (like OC3 and STM1), and hence some protocols may be semi-compatible (as per the OC3/STM1 example).
  • The protocol can be defined in terms of Characteristic Information (CI) which includes the mandatory "maintenance" information of the protocol along with the "payload" information container structure (but clearly not content). There will be constraints on properties of the payload information for it to be compatible with the container.
  • It is possible that several streams of (client) information could be conveyed together within one payload envelope, i.e. the protocol and hence the transform process is defined to achieved as this

The flow of the signal from transmitter to receiver is itself a flow of encoded information. This information flow may be the (client) payload of another protocol "layer".

Hence the Transfer/Transform-potential/enabled structure is recursive, enabling the formation of a client-server stack of protocols (layers) that support the transfer of any particular "ultimate" [11] payload where that payload may be made up of one or more client streams as may any transformation further down the stack.

It is important to note that:

  • There is no specific order in the layering of protocols and, a specific protocol may appear several times in the protocol stack supporting any particular transfer of payload, the layer ordering, although not arbitrary, is in no way constrainable
  • Although protocol overlap is relatively limited, signals may pass directly from one protocol domain to another so long as they are constrained to the compatible subset

Hence overemphasis on layering rigidity or protocol purity in the model may prevent the model from readily supporting all cases.

V.1.7 Forwarding phases

So far the model constructed from the patterns simply described:

  • The transformation to a protocol to enable transmission and transfer to a receiver for transformation back to extract the payload.
  • The transformation of the "protocol for transfer" into another protocol for transfer, i.e. layering
  • The ability to carry several client streams in one transformed stream

The activity of transformation (the function) takes place within a processing engine of some form, but the relevant transfer discussed so far is between peer processing engines and hence "external" to those engines (ultimately over a wire, fiber or air-gap [12] ).

In addition, it is often necessary to transfer a signal essentially unchanged across the processing engine [13] . Indeed the method of passing signal from one layer to another is a somewhat degenerate transfer inside a processing engine. This transfer is "internal" to the processing engine.

This leads to two "phases" of transfer, internal and external, where the external phase is supported by a server layer protocol and the internal phase by the processing engine.

V.1.8 Information architecture

The intertwining of the patterns identified in the sections above yields an information architecture. The information architecture formed can be seen as essentially the structure described in [ITU-T G.805] and [ITU-T G.800] where the two Transfer/Forwarding [14] phases and the two Realized Potential phases are exposed as distinct entities:

  • Subnetwork – internal potential
  • Link – external potential
  • Subnetwork Connection – internal enabled
  • Link Connection – external enabled

V.1.9 Views of the architecture

The CIM CoreNetworkModel provides a view of the information architecture that can be understood as a Pruned & Refactored form of the architecture that compacts some aspects of layering and that focuses on the relevant structures for Management-Control.

In the view provided by the CIM the two phases "internal enabled" and "external enabled" are both represented by the ForwardingConstruct whereas the two potential phases are represented by distinct classes Link (external) and ForwardingDomain (internal).

In general, the degree of specialization depends upon the purpose and focus of the view. It is important to distinguish between entities being the same vs. being similar enough to be represented by the same abstraction. From a network architecture perspective, considering Forwarding, it appears important to distinguish between all four phases. Whereas, from an MCC perspective it seems appropriate to not distinguish in class between the internal and external phases of enabled forwarding.

Considering all viewpoints, it appears to be a viewpoint judgement as to whether everything is represented

  • as a thing with properties where instances of thing only differ in properties,
  • as distinct classes of thing where instances of the distinct classes only differ in properties but instances of thing differ in class and properties
  • as simply distinct instances where each instance is considered as distinct and fundamentally different to any other instance

Regardless, any instance differs in at least one property from any other instance. A challenge is what is relevantly the same and what relevantly different. A further challenge is how to emphasize the sameness whilst avoiding the rigidity of classification [15] .

V.1.10 Deriving relevant application models [16]

The general approach is to formally Prune & Refactor (P&R) the CIM to form an application specific view, normally for use on an interface. This was the approach taken to form the TAPI model from the CIM.

Whilst it is intended that in the longer term the generalized models of the CIM (with expected evolution taking advantage more and more of Component-System pattern) will be used directly as the representation of the semantics of interaction, the P&R approach is taken to overcome several challenges:

  • The apparent distance of the model terminology and granularity from the specific terminology of the current market place (where various different traditional terminology sets are used)
    • These different terminologies and granularities do not benefit M2M, they are there as a result of legacy H2M approaches
    • It is expected that approaches for representation of the problem semantics will continue to evolve and that the Component-System pattern will be an important factor in that evolution
  • The apparent looseness of elements in the model as compared to current implementation use cases
    • There is a tendency to focus on highly specific use cases rather than patterns and to code in terminology of the specific use case.
    • The expectation is that this specificity will move to into data in a specification model [17] (which could be considered as a further level of coding) that constrains the generalized model for specific cases but in such a way as to not create specialized classes and as to create a continuum
  • The need for decoration of the structure with specific technology etc. detail
    • Again, using the specification model approach to decorate the generalized classes
  • The need to have simple models for simple cases
    • This tends, again, to lead to specific models
    • The expectation is that a variable encapsulation approach (see section V.1.3) which is related to the approach proposed in Annex J will be used where the model complexity is "folded-away" for the simple cases but provides the necessary sophistication for the complex cases

V.1.11 The Component and the Classes in the CoreNetworkModel

This section provides a sequence of figures that explain the fundamental relationship between the Component-System Pattern and the CoreNetworkModel.

Figure V- 7 A generalized component

 

Figure V- 8 A system of components

 

Figure V- 9 A system of components viewed as a component

  • A component encapsulates components
    • The encapsulated components are in a system (this is not just a bag of components)
  • The pattern is familiar as it appears in networking
    • A subnetwork encapsulates subnetworks and Links
  • All functional things that can be interconnected can be considered as components
    • They expose services that are defined for the purpose of interconnecting to others

Consider the classes in the CIM in the Core Network Model. Apparent adjacency is achieved by rapid transfer of information using a forwarding function.  Using the component concept a forwarding function is encapsulated in a component to enable use in a system.

 

Figure V- 10 A Forwarding Component

The ForwardingConstruct is essentially a Forwarding Component.

To achieve forwarding it is necessary to carry the information over some bearer and to do this it is necessary to encode the information. This and other functions transform (and temporarily augment) the information. These transform functions are considered as Termination.

 

Figure V- 11 A Termination Component

The LogicalTerminationPoint is essentially a Termination Component

Figure V- 12 Network of Forwarding Components and Termination Components

Figure V- 13 Network showing Link and Trail

Figure V- 14 Forwarding

  • Several different representations of FC
  • Component ports are called endpoints in the UML model
    • Note port aligns with G.80x
  • The Component has a type
  • The ports (FcPorts) have roles with respect to the type

 

Figure V- 15 A Termination

  • A list of LayerProtocol (LP) elements are encapsulated in a LogicalTerminationPoint (LTP)
  • The LTP encapsulation rules are such that the LTP can expose at most one client, one peer and one server port
    • These may be from different LPs
    • The client port may give rise to multiple instances of clients and the server port may build on multiple severs (not shown in the figure above)
  • The LP and LTP ports are not exposed directly in the information model but instead are absorbed in association types

Figure V- 16 LTP and LP In physical port context

 

In the figure above:

  • A list of LayerProtocol (LP) elements are encapsulated in a LogicalTerminationPoint (LTP)
  • The LTP encapsulation rules are such that the LTP can expose at most one client, one peer and one server port
    • These may be from different LPs
    • The client port may give rise to multiple instances of clients and the server port may build on multiple severs
  • The LP and LTP ports are not exposed directly in the information model but instead are absorbed in association types

 

Figure V- 17 Associating ports of components

Conceptually …

       An atomic function is at a single point

       Two functions cannot be at the same point

       Two adjacent atomic functions touch such that the adjacency is zero length

       A complex function is made by joining multiple atomic functions as a system of adjacent atomic functions

       The atomic functions forming a complex function are necessarily spread over a space

       Assuming normal space, for any particular complex function, regardless of the choice of specific arrangement of atomic functions some atomic functions that need to be adjacent to form the logic of the system cannot be actually adjacent as they are at a distant and hence must be joined via atomic functions that simply transfer information. This transfer forms a virtual adjacency.

       Adjacency between two complex functions can be represented as if a true adjacency, as for atomic functions, however in most cases the adjacency will:

       Be achieved via atomic functions that simply transfer

       Be spread over spread over space

       Will represent multiple parallel/simultaneous semantic interactions

       Perfect transfer of information (zero time, infinite capacity) is represented in yellow in the figure as it is the essential property of a forwarding entity

       Forwarding is imperfect transfer.

 


Appendix VI

Model Rationale

(This appendix does not form an integral part of this Recommendation.)

This appendix explains the reasoning behind the current model and its evolution. The appendix relates some of the patterns and architecture in Appendix V to business need and vision. The appendix:

  • Works through business need.
  • Discusses the implications
  • Discusses the challenge of evolution
  • Explains how the current model satisfies the need in the context of the current stage of evolution
  • Explains the next steps in the context of evolution and vision

The descriptions in this appendix are built from descriptions in earlier referenced works.

VI.1 Business need

Management of networks and devices today is a complex operational challenge resulting from, and exacerbated by, the plethora of conflicting standards and incompatible implementations. Almost all the existing models use inconsistent terminology and outdated concepts that aren't applicable to SDN/NFV scenarios [18] .

The root cause of many of the issues encountered centers around the approaches that have been used to create these standards and interfaces; e.g.:

  • A 'handcrafted silo' approach that initially produces good point solutions results but doesn't scale, ultimately creating a morass requiring complex mappings between the silos;
  • A vast monolithic 'one central model' that results in slow progress after long lead times with second-rate results that don't meet stakeholder needs.

Whenever new technologies and management/control paradigms arise, such as SDN and virtualization, they initially all seems different, new and special. But eventually we realize that there is rather a lot in common, as we again see the patterns. In fact, neither SDN/NFV [19] nor virtualization [20] are in any way new. There are increasingly complex resource interactions to be managed-controlled such as virtual machines supporting virtual switches. But it seems there are consistent patterns that could be leveraged.

So, there are opportunities, and our goal should be, to massively improve the realization of the value fabric:

  • The way in which providers of services interact, intertwine and interdepend to provide every increasing value - we are all providers of service
  • There is a need to enable an ecosystem of developers and an ever-changing structure of interacting parties.

It is undeniable that the value fabric has high inherent complexity (deep recursions, fractals and continuums) but there are artificial boundaries (which cause unnecessary cost) [21] . There is a need for coherent treatment, broad perspective and long-term view, and for players to abide by enabling constraints to allow efficient interaction.

Management is control (e.g., EMS/NMS flow through and restoration). Management and control is a continuum (MCC). Any artificial boundaries only complicate the solutions. The solution should focus on a coherent component architecture and structure.

VI.2 Benefit of the CIM

Information Modeling is the process of identifying, defining, consistently labeling, and recording the key concepts (functional things, physical things etc.) in a problem space as well as the interrelationships between them. An information model defines and labels the things in a domain—for example, a telecommunications network—in terms of objects, such as links, terminations and controllers; their properties or attributes, such as latency; and their relationships—for example, a link is bounded by terminations. By normalizing the concepts, objects, interfaces, etc., an information model reduces complexity (see Figure VI-1). In addition, an information model can be used, with appropriate tooling, to automate code production, helping accelerate product and service development while reducing coding errors and interoperability issues.

Figure VI- 1 Normalization in Information Modeling

To avoid the pitfalls mentioned in clause VI.1 above, the Information Modelling team:

  • Has defined a consistent set of fundamental concepts and the relationship among them by leveraging the knowledge gained from years of management standards evolution and pragmatic implementation/software development experience. These concepts are capable of representing both legacy management and SDN/NFV concepts/scenarios, while allowing for consistent management in hybrid environments.
  • Employs a realistic federated model with a layered model architecture and managed dependencies. This is comprised of a stable core model (which is itself modular for scalability) and technology-specific model extensions that can be added in a timely manner without destabilizing the core.

The Information model is not a purist, theoretical artifact, but a pragmatic one that forms part of a tooling chain, enabling context and technology specific interfaces in different languages to be generated from a key set of definitions. Automating the interface writing avoids inconsistent silos as a change can be simultaneously made in many interfaces in a consistent manner. This approach has led to the development of TAPI, which formally incorporates transport technology specific properties from ITU-T.

The value of a common model approach has been recognized both within ITU-T SG15 and by external SDOs such as ONF, ETSI NFV, MEF and TMF, as well as by some major service providers. These SDOs recognized that the model draws on many years of experience to consolidate the key aspects of existing standards; is a stable base to work from and is more advanced than their current work in these areas. To further its development, the MEF, ONF and TMF have signed a formal collaboration agreement to continue develop this common information model. In addition, ITU-T has re-published the Core Model as Recommendation G.7711.

VI.3 Model evolution

The CIM, which built on 30 years of implementation experience and standards evolution (see Figure 2-2 below), provides a rich [22] , compact [23]   canonical [24]   model covering the problems spaces relevant to management/control for open networking.

Figure VI- 2 Relationship between past current and future network model work

Whilst the Core Model could be used directly to construct interfaces, the modeling team recognizes that an interface should be oriented towards the user's needs from the user's viewpoint (terminology/structure etc.). That orientation includes removal of aspects not relevant to the viewpoint and also refactoring/relabeling the representation to suit the viewpoint. A process called "Pruning and Refactoring" is used to construct information model representations of relevant interface views from the Core Model [25] . This supports the current variety of terminology whilst providing a rigorous mapping back to the canonical form [26] .

Having a Core Model, a process for using the Core Model to construct interface views (Pruning and Refactoring) and to convert those views to implementation schema (e.g., UML-to-YANG Mapping Guidelines (see [b-UML-YANG GUIDE])) along with tools that support the process is vital. Using tooling (e.g., UML-to-YANG tool (see [b-UML-YANG TOOL])) that consistently generates the implementations is key to ensuring unambiguous and interoperable products and open source software. This also helps reduce errors and enables code to be more easily produced. The [OSSDN-Eagle] (IISOMI) activity currently focuses on process/methodology and tooling.

As the Core Model is network technology agnostic (see Annex B ) it is important that there is a mechanism to enable consistent addition of specific technology details. The CIM provides such a mechanism that is also designed to support network technology evolution. The modeling team looks to source to provide the interface definitions (e.g., the OTN IM in [ITU-T G.874.1]). The mechanism also allows vendor proprietary addition. For example, a pre-standard vendor innovation may be accommodated on an equal footing with the technology standard properties.

Addition of network technology details employs a specification mechanism defined in the Core Model (see Annex G ). Technology specific specification classes are used to augment the core model classes (e.g., media for information transfer). Where a new technology introduces a capability that has structure that could be applied more broadly, this structure will be incorporated in the Core Model. A vendor may take a technology specification, prune out parts that are not supported by their implementation, add vendor proprietary parts and then publish the results in a per-case specification. This specification can then be used to drive the augmentation of the Core Model and any derivative of the model.

VI.3.1 Agile approach for model evolution

An agile architecture approach has been used by the modeling team to develop the Information model:

  • Take some specific and general use cases in the context of control of networking
  • Explore and generate/refine the model [27] /guidelines/tooling building on the existing model/guidelines/tooling
  • Use the Prune and Refactor process to propagate the model changes to each existing interface views [b-ONF TAPI] and to generate new interface views
  • Update the data schema related to each view [b-ONF TAPI] using the appropriate tooling (e.g. UML to YANG automated generator)
  • Generate the appropriate Interface schema
  • Generate reference implementations
  • Construct proprietary and open source solutions [e.g. OIF/ONF and MEF PoC/Trial activities]
  • Gain insights from implementation and feedback insights/issues to further evolve the model/guidelines/tooling

 

 

Figure VI- 3 Agile Architecture process

The above cycle can be run asynchronously at different rates depending upon the specific aspect/use case. Experimental changes can take place in the model/guidelines/tooling within a day (in the ongoing work).

The modeling team has promoted open source software tooling and hence there is a strong association between the modeling work and software in that dimension. This software is being developed using an agile approach and hence there have been incremental releases on a regular basis supporting use cases defined for interface views. This software is a step in a progression towards a model driven implementation environment. The intention is to reduce the need to hand craft interface (and in the longer term potentially algorithmic) implementations.

To help enable evolution and to deal with the stages of innovation value lifecycle, each aspect and element of the Information Model is developed through a lifecycle where the lifecycle stage/state (Experimental, Preliminary, Mature, etc.) of the aspect/element is marked using Lifecycle Stereotypes define in the Open Model profile [b-ONF TR-514]. Any particular part of the model may include elements with any mix of lifecycle stages. The full model, including experimental and preliminary work, is published as a snapshot.

VI.3.2 Industry cooperation in model evolution

The modeling team has strongly promoted the use of the CIM within ITU-T and also with other industry groups, including ONF, MEF, TMF, ETSI-NFV, [b-OASIS TOSCA], OIF, IETF, and BBF etc. ONF has signed a collaboration agreement [b-ONF-TMF-MEF] with MEF and TMF to work jointly on information modeling and the intention is that the ONF CIM form a key part of this joint modeling work.  Work in TMF provides guidance and content for the new solution, such as SDF and DSRA provide architecture, eTOM provides processes, and SID provides information structuring. The MEF and TMF have already chosen to take advantage of the ONF CIM in place of their own work and ITU-T have republished the ONF Core Model [b-ONF TR-512] in [ITU-T G.7711]. Work in ETSI-NFV has led to the recognition of the CIM as a suitable representation of networking in an NFV context and this has led to the construction of a touch point model relating ETSI-NFV classes to networking classes. 

The ONF modeling team is also tasked with providing recommendations for modeling tools and guidelines. Tooling and guidelines are dealt with in the ONF-sponsored open source SDN project EAGLE/IISOMI [b-OSSDN-EAGLE]. This work is shared and co-developed with individuals who are active in ETSI-NFV, ONF, TMF, MEF and ITU-T. [b-OSSDN-EAGLE] is also the home of tooling that takes an appropriately formed information model in Papyrus UML and generates interface definitions (currently in YANG and JSON schema but the intention is to generate any appropriate schema/API definition).

 


Appendix VII

Analogue and Media (Layer 0) Examples

(This appendix does not form an integral part of this Recommendation.)

This appendix provides various examples of the use of the CIM to model analogue and media structures

The examples in this appendix are built from descriptions other appendixes. The media examples are supported by a combination of the FC/LTP (as described in Annex B), the physical model (as described in Annex F) and the specification model (as described in Annex G).

Each case discussed in this document will be supported by FC specs, LTP specs and scheme specs. Most cases do not explicitly show the scheme spec but have been described using the base classes (FC, LTP etc) from which the scheme spec can be derived.

VII.1 Optical Media

 

The network model required to support media is discussed in Annex B .

This appendix provides examples of usage of the network model to represent various photonic media functions and devices. For each example detailed stylized layouts of functions that are used to drive FD, FC, LTP and scheme spec are provided along with the resulting simple compact representation.

It is intended that sufficient stylized cases are covered here to allow a modeler to represent their specific function/device.  It is not intended that all possible cases are covered.

The spec models provide detail to allow interpretation of the properties compacted into the simplified model and hence allow faults to be diagnosed. The figures in this document are essentially pictorial views of specs.

VII.1.1 The basic components of the mode

VII.1.1.1 The basic attenuator and filter

The following figure shows symbols for the basic attenuator and filter. Attenuators and filters are inherently omnidirectional.

Figure VII.1- 1 Attenuator and Filter (explaining the symbol set)

The filter models the ability to allow only those photons that are within in a defined portion of spectrum to be passed. The filter is described as a media channel and is represented by an FC.

The portion of the spectrum is called a frequency slot and is described by centre frequency and width. Frequency slot is an administrative concept and is conceptually square. The actual pass-band of the filter is not square. The frequency slot and pass band relationship is challenging and not covered here.

A single port of a filter can support more than one media channels (see later).

As the filter is represented by an FC the characteristics are expressed in an FcSpec (see Annex G ).

Figure VII.1- 2 Pictorial view of example spec model for attenuator

The figure shows the two port FC along with three spec forms:

  • Asymmetric: This allows the parameters for both directions of flow to be different. This is the easiest form to read and is recommended even when the device is symmetric
  • Basic Symmetric: Appropriate where the device has exactly the same effect on both flows and there is no independent control of the flows. The current rule for an FcSpec of this form is that there is no flow from a port to itself so this does not readily allow reflection characteristics to be expressed (the FcSpec rule would need to become flexible per flow expression)
  • Asymmetric with reflection: Shows a long hand form of the spec. Note that this is relatively verbose for a two port device. For a multi-port device, explicit expression seems particularly verbose and a more compact form of expression would be beneficial.

The parameter blocks in the spec provide invariant and adjustable values. Any aging characteristics could be stated in the parameter blocks.

For a complex filter with different characteristics per "band" the spec could either code the complexity in an expression or show separate "flows" (green) per "band". It is also possible to have a filter instance per "band".

The model (and symbol set) allows for a variable attenuator.

VII.1.1.2 Coupler-Splitter

The following figure shows basic coupler/splitters. Coupler-splitters are inherently omnidirectional.

 

Figure VII.1- 3 Coupler/Splitter

The Coupler/Splitter provides a set of atomic media channels between one (common) port and two or more other (branch) ports. All of these atomic media channels have the same frequency slot. In the root to leaf direction the "splitter" attenuates the signal, in the leaf to root direction the "coupler" has negligible attenuation.

VII.1.1.3 The circulator

The circulator is a media component that takes advantage of non-linear characteristics to essentially provide a unidirectional flow. A circulator as shown in the figure below.

Figure VII.1- 4 The circulator

In the circulator depicted, photons that arrive at FcPort A will emerge from FcPort B, photons that arrive at FcPort B will emerge at FcPort C and photons that arrive at FcPort C will emerge from FcPort A.

VII.1.1.4 The photodiode

The photodiode is a media component that converts a photonic signal (in a frequency slot) to an electrical signal. Both the signal domain and the media change (the domain changes from photonic to electrical and the media from glass to copper (via various intermediate media)) [28] . There is a media channel from the So to the converter (an adaptation) and a different media channel from the converter to the Se, however it is the domain change that is emphasized by the adapter symbol rather than the media change (as the physical layer is only modeled in abstract). The third symbol shows media transition. The assumption is that the FC is essentially electrical and the element that is not is exposed as an embedded FC with some fiber specification.

Figure VII.1- 5 Photodiode as an active element (showing media)

The figure below shows the spec model for the Photodiode highlighting:

  • The media specification
  • The LTP spec representing the transformation from optical to electrical
  • A specification of the reflection characteristics.

The bias signal is not supported at this stage.

Figure VII.1- 6 Pictorial view of example spec model for Photodiode

The figure below shows a photodiode in the context of an LP. The photodiode may be extract signal or may be used for power measurement. The optical power monitor measures the power of any optical signals that are present in a media channel.

Figure VII.1- 7 Photodiode as an active element showing power monitor

 

VII.1.2 Complex assemblies

VII.1.2.1 The Laser

The laser is a media component that takes advantage of non-linear characteristics to essentially convert an electrical signal to a photonic signal (in one frequency slot).

Figure VII.1- 8 Laser as an active elements (showing media)

The lasing medium when stimulated with an electrical signal produces an equivalent photon signal. In the actual implementation the photons emerge at two facets. The "back" facet photon stream is used to measure the output of the laser. The measurement is fed to a control function that adjusts the electrical input to the laser.

The Laser with back diode is shown in the context of the E-O Source LP.

Figure VII.1- 9 Laser as an active element (showing media)

The spec for the E-O Source explains the arrangement of functions and provides a mapping to the E-O LP instance and content. From the figure it can be seen that the LP includes two Terminations an adapter, two FCs and a C&SC. The two FCs can be merged and the spec for the LP then looks as in the figure below.

Figure VII.1- 10 Spec for Laser

A compact view of the media E-O LP is shown in the diagram below [29] .

Figure VII.1- 11 Essential functions of a laser and abstracted symbol for a laser

An alternative construction of a photonic transmitter is shown in the figure below. In this case, rather than an output that is amplitude modulated with the signal, the output is phase modulated or amplitude modulated (or both) by an external device. In this case the electrical signal carrying the information is applied to the external modulator and the laser produces a constant power output.

Figure VII.1- 12 Sketch of phase modulated output

VII.1.2.2 The coherent receiver

The figure below shows the simplified view of a coherent receiver with digital signal processing (DSP) [30] . A coherent receiver uses a heterodyne detector to convert the information carried by the photons into a "baseband" electrical signal that is then processed by DSP to correct for impairments introduced by the network domain channel. The abstracted symbol encapsulates the frequency tuning aspects and the DSP in the FC but separates out a termination to deal with the optical to electrical conversion. The symbol is not an accurate depiction of the actual processing but it allows for a more consistent representation from a management-control perspective.

Figure VII.1- 13 Coherent receiver assembly with simplified symbol

VII.1.3 Network considerations

This section provides views of the basic elements described in the previous section combined into network constructs.

VII.1.3.1 The Media Channel and Information Transfer

Figure VII.1- 14 Network Domain Channel formed from Media Channels

In this document the Network Domain Channel (the FCs NDCA and NDCB) is considered as being from the point of injection of electrons into the laser medium or external modulator to the point of emergence of electrons from the photodiode [31] . The NDCs shown are formed as a result of the effects of the filters in the coupler C and splitter D which are reflected in the Media Channels MCY and MCZ (both of which are FCs with three FcPorts). It is not until the lasers A and B are applied to the MCY and MCZ that the effective NDCs can be determined. In the figure, Y and Z are wide band receivers. If A and B were tuned such that A D1 (and hence A∩D2=Ø) and B D2(and hence B∩D1=Ø) then NDCA would go from A to Y and NDCB from B to Z.

The figure below shows a basic consideration of information transfer. For the broad band receiver the information transfer capability is dictated by the NDC.

Figure VII.1- 15 Information Transfer Channel formed from Media Channels for broadband receiver

The figure below shows MCZ and MCY are transparent. The ability to transfer information is dictated by setting of the tunabe laser, the setting of the hetrodyne detector and the capabilities of the receiver DSP. The figure provides a somewhat simplified representation of the information transfer capability.

Figure VII.1- 16 Information Transfer Channel formed from Media Channels for coherent receiver

 

VII.1.3.2 The amplifier

Amplification is achieved using non-linear characteristics of fiber. The optical amplifier acts on a band of frequencies to increase the optical power level .

VII.1.3.2.1 General considerations

The abstract symbol for an amplifier element is shown in the figure below.

Figure VII.1- 17 Abstract symbol for an amplifier

The abstract symbol can be used to represent an amplifier where a detailed consideration is not relevant. In a simplified view the gain parameters are parameters of the FC and the input and output power measures are parameters of the FcPorts. The spec model set provides the mapping from the parameters in the simplified view and the detailed interpretable view.

Where the amplifier provides different amplification for different bands/slots a number of instances of the symbol can be used as shown below. Where control/monitoring is relevant parameters can be offered on a per amplifier FC or FcPort basis as appropriate.

Figure VII.1- 18 Abstract Symbol for a multi-band/slot amplifier

For more complex cases a more detailed model will be required. The following sections detail different applification methods.

VII.1.3.2.2 Erbium Doped Fiber Amplifier (EDFA)

This amplifier uses a short length of fiber doped with Erbium as the non-linear element that is fed at one or more points by pump lasers of specific wavelengths. This combination causes power transfer to a set of signal wavelengths that arrive at the input side of the amplifier. The EDFA is unidirectional.

The following figure shows a stylized view of an EDFA with one forward (co-directional) pump laser and fragment of control (including measurement of one band of incoming/outgoing signal only). In a full form, many bands may be measured, there may be many pumps in an amplifier and there may be two or more amplifiers in parallel amplifying different bands (e.g. L band and C band [32] ).

Figure VII.1- 19 A stylized view of a fragment of an EDFA

The essential function of the amplifier is to provide balanced amplification to all relevant incoming signals. To enable interpretation of the measures and adjustment of the controls a suitably detailed spec model should be provided. The spec model should show necessary detail such that the effects of each control and the meaning of each measure can be interpreted. Certain elements of the EDFA (such as the circulators) are not relevant from this perspective. The spec may represent the amplifier as a set of parallel per band amplifiers from this perspective.

Considering fault analysis, it may be necessary to represent the amplifier in more precise detail especially where the amplifier is constructed from a number of separate field replaceable units.

It is likely that several related spec models will be necessary in the most complex case [33] .

The following figure shows a fragment of a model of an EDFA with a backward pump.

Figure VII.1- 20 A further fragment of an EDFA with a forward and a backward pump

 

VII.1.3.3 Amplification using the Raman effect

The following figure shows a stylized view of a Raman amplifier. The amplifier uses the main transmission fiber as the amplification element. Various other filters and monitors may be present in full representation.

As for the EDFA there may be a need for several related spec models to provide views for different purposes.

A simplified view may use the amplifier symbol in the figure above or amplification can be shown on the FC for the transmission fiber (as in the figure below).

Figure VII.1- 21 Stylized model view of a Raman amplifier

 

VII.1.3.4 OMS and OTS

This section deals with the monitoring of sections of a photonic network. The model is derived from representations in [ITU-T G.872]. The following figure shows a fragment of topology positioning the OMS and OTS with respect the photonic and electronic components.

The figure includes three diagrams. The detailed view shows a layout of components (each component view is itself simplified). The measures in the detailed view can be projected to the corresponding points in the simplified view. A set of scheme spec would explain the relationship between the simplified view and the detailed view (and clearly further spec would explain the measures on each component in terms of further detail).

 

 

Figure VII.1- 22 Topology fragment showing OTS in detail and OMS in abstract (assuming EDFA)

The OMS information is conveyed via the OSC. The OSC terminates for each OTS span and hence the OMS information needs to be propagated between OSCs at the points of OTS termination. This detail is not shown but would be explicitly modeled in the relevant specs (essentially simple forwarding). Bidirectional considerations of the OMS, OTS and OSC are not covered here.

Note that the OTS monitors shown in the figure above will probably be the monitors of the amplifier itself and hence the OTS OSME will extend between the output port and the input of the amplifiers as show in the simplified view such that the OTS and OTS OSME become coincident.

The OTS, OTS OSME, OMS and OMS OSME are represented by FCs. OTS FC is between the output of one amplifier and the input of the next. The OMS FC is between a point of aggregation and a point of disaggregation.

The Optical Supervisory Channel is essentially an NDC and is represented by an FC.

VII.1.3.5 OTSi in context of OTU, OMS-O and OTS-O

The following figure provides a detailed view of the representation of the LTPs and FCs that represent OTU mapping onto media.

 

Figure VII.1- 23 OTSi in context of OUT, OMS and OTS

An OTU is supported by a set of one or more OTSi ( Optical Tributary Signal)

The set of OTSis that carry a single OTU are considered as a group (OTSiG) from a management-control perspective. The OTSi is characterized by the central frequency and an application identifier. Each OTSi is carried in an independent NDC. The differential delay between members of the OTSiG must be controlled.

If the OTSiG O is used, then all members of the OTSiG and the OSC that carries the OTSiG O are carried over the same fiber .

The OSC is an OTSi that is used to carry the OTSiG O and a Data Communications Channel

VII.1.4 The Field Replaceable Unit (FRU) and the Media Element (ME)

Each functional component discussed up to this point do not necessarily equate to an FRU. It is often the case that a function will be supported by several FRUs and also that several functions will be supported by a single FRU. From a maintenance perspective, the FRU is the relevant construct. The FRU is modeled as a Replaceable Equipment.

The following figured depict Media Elements (MEs). It is assumed that MEs equate to Field Replaceable Assemblies of one or more FRUs [34] .

 

 

Figure VII.1- 24 One of the many possible ME arrangements

The Raman amplifier case would have a similar arrangement to the figure above recognizing that again that the receive side monitors will probably be those of the amplifier itself and that in the case of Raman the amplifier is the fiber.

The figure below shows other possible arrangements of MEs (recognizing that the upper diagram is probably unlikely as the monitor is likely to be part of the amplifier as discussed earlier).

Figure VII.1- 25 Two other possible ME arrangements

The ME

  • Encompasses one or more media constructs.
  • Can encompass one or more MEs [35] .
  • Has one or more ports
  • Has zero or more interfaces for management
  • May be opaque such that the internal structure is not visible BUT
    • Clearly there are parameters that will be positioned against the inputs, the function or the outputs
    • The spec structure should explain sufficient of the structure to allow suitable interpretation of the reported information and controls.
  • Is described in most cases as one of more FCs [36]

An example media element is a reconfigurable add-drop. [37]

VII.2 For further study

VII.2.1 Photonic and Media parameters

The normative source of media parameters will be chosen (ITU-T), the model from that source will be Pruned and Refactored as appropriate and the parameters will be assembled in example spec models. The parameters will be mainly represented in LtpSpecs [38] . All parameters will be available and a selection can be made by the vendor etc.

The spec provides interrelationship rules between the parameters.

VII.2.2 Considering G.872

       Media port

        Media construct/element boundary

        Media Port : a logical abstraction that represents the ends of a media channel, the boundary of a media construct or the boundary of a media element              

Comment: This appear to be somewhat jumbled. Coherent places appear to be the FcPort, the LTP and the Pin. It seems that MediaPort blurs this.

       Media channel – represented by the FC

        Media Channel (MC) (see Figure 8-1 of [ITU-T G.872]): represents both the path through the media and the resource (frequency slot) that it occupies.

        "Atomic" MC: It is a MC at bottom of MC-decomposition in the context of a particular view

        Network Media Channel (NMC) – output of a modulator to input of demodulator [39]

       Media Link – represented by the FC

        Pure topological relationship

        One or more media channels [40]

        Media Link : represents path through the media

Comment: An example of a media link is a uni-directional OMS that uses C-band and L-band amplifiers. The C-band and L-band are represented each represented as media channels (with the same end points each with its own frequency slot. There is some "dead" or unusable spectrum between these frequency slots and hence the combination of these two media channels does not result in a single media channel. A bidirectional media link may also be used to represent a pair of (counter directional) unidirectional OMS media links. In the case where the OMS uses both C-band and L-band amplifiers it would represent four unidirectional media channels.

       Media Subnetwork

        Flexible connectivity

        Media Subnetwork : a topological construct that represents a point of flexibility where the associations (represented by media channels) between the media ports of the media subnetwork may be created or deleted

Comment: Provides constraints to indicate which MCs can be created by control action. BUT probably best represented as FC in FC rather than FD for some cases but as FD for the case where, for example a subnetwork or flexible grid capable filter, had no contained FCs i.e. no enabled forwarding. Since media subnetworks typically have some (load dependent) blocking normally a FC spec is used to describe these constraints.

VII.2.3 Other technology considerations

This section lists other relevant considerations that will be accounted for in future releases:

  • Implications of the Media model for Wireless
  • Raman OTS/OMS.
  • The media element
    • The ME is not simply an FD although the FD is useful in grouping aspects of capability.
    • The boundaries do not look coherent (with Raman, there is no hard end to the amplifier). In some cases it is LTP in others it is some multi-LTP construct
    • Question about the Media Element grouping. The groupings do not look useful from a maintenance/control perspective.
    • Why is the electrical monitoring stack and the corresponding media stuff not grouped? This is more like a normal TTP and then LTP
  • FcSpec: frequency (mandatory; m,n 12.5 step, 25 width; [ITU-T G.694.1]), transfer characteristic, etc.
  • G.694.1 uses the (m,n) schema. There may be other standards schema and proprietary schema.
  • Use identifiers to identify the frequency specification schemas.  
  • OMS Media Channel could be shared by multiple Media Channel
  • Picture using FC for network media channel without power but yet have OMS etc. available.

VII.2.4 Other Pictorial cases

This section includes a number of cases from [ITU-T G.872].

  Figure VII.2- 1 Copy of Figure 8-13 from [ITU-T G.872]

 

Figure VII.2- 2 Copy of Figure 8-15 from [ITU-T G.872]

It is assumed that the "NE" carries out the coordination identified e.g. for managing an OTU connection. But for some applications e.g. inventory, fault management an "external" system needs to understand the relationships.. This needs to be verified.

 

Figure VII.2- 3 Copy of Figure 8-16 from [ITU-T G.872] (on left) with basic proposal (on right)

 

Figure VII.2- 4 Copy of Figure 8-16 from [ITU-T G.872] (on left) with enhanced proposal (on right)

 

 

Figure VII.2- 5 Copy of Figure 8-12 from [ITU-T G.872]

NOTE: Need to extend model to show Raman.


Appendix VIII

Circuit Switched (L1) Examples

(This appendix does not form an integral part of this Recommendation.)

 

This appendix provides various examples of the use of the CIM to model circuit switched network structures.

This appendix is not intent to be exhaustive; it does not show all possible examples. The intention is that this appendix provides sufficient structure patterns to enable someone with appropriate knowledge of management/control of circuit switched protocols and corresponding devices to model the ports of those devices. The appendix should be used in conjunction with Appendix VII and Appendix IX (to be published in a later edition of this Recommendation) to model multi-layer-protocol devices.

The examples in this appendix are built from descriptions in earlier referenced works.

VIII.1 General c ircuit examples

This appendix introduces a model of layer protocols for circuit switched systems. The figures show a compact diagrammatic representation of the order of layer protocols for various port types. Some of the figures show a representation aligned with that in Annex B Figure B.2-10.

Some of the earlier examples show both the layering and then the ports assembled into a stylized device with a somewhat arbitrary arrangement of layer protocol terminations on circuit packs, cards etc. (Equipment) of the device.

 

VIII.1.1 Basic OTN device example

 

T he following figure shows the model for a fragment of a device where an OC48_STM-16 Tributary is interconnected to an OTN line port. In this case the device offers only single layer connection flexibility at ODU1 [41] .

The OC48_STM-16 signal received on the tributary port is terminated to expose the STM-16 MS signal. This signal is mapped into an ODU1. This is then forwarded, via an FC, to the Line port where it is multiplexed into an ODU 2. The ODU2 supports four instances of ODU1. The ODU1 is mapped via a number of intermediate adaptations into the ODU2. The ODU2 is multiplexed into an ODU4. The ODU4 supports 10 instances of ODU2.  The ODU2 is mapped via intermediate adaptations into the ODU4. The ODU4 is then mapped into onto the MEDIA via an OTSi. For this case, it is assumed that there is only one OTSi required to carry the ODU4 and that the ODU4 fully occupies the OTSi. It is also assumed that this OTSi is the only one carried by the media channel.

The details of the media mappings and overhead are covered by Appendix VII . The figure in this appendix only shows a simplified summary of the media layering.

The figure follows the usual convention (see Clause 5 ) shows LTPs (green/purple boxes) and LP instance (dashed lines in the green/purple boxes). The figure highlights all levels of adaptation that are identified in the corresponding ITU-T recommendations (see References in Clause 2 ).

 

 

Figure VIII.1 - 1   Basic OTN device example showing STM-16 Tributary and Line

In this and the following figures, the cardinality between the client and server is shown as m/n e.g. ODU1 / ODU2 is 1 / 4.

A simplified representation is shown in Figure VIII.1-2. This simplified form has been used in the examples. In the simplified representation the ODTUG and the OPU have been absorbed in the ODU client-side adapter and the OTU has been absorbed in the ODU termination since they always have a 1:1 relationship.

Figure VIII.1 - 2   Basic OTN device example showing compact representation of a STM-16 Tributary and OTN Line

Figure VIII.1-3 shows a device that supports the STM-16 to OTU4 mapping shown above. The device has four tributary slots (only one is equipped). The equipped tributary card supports four ODU1 capacity ports that map each STM16 into an ODU1. One of the ODU1s is connected to the left Line Card where it is then multiplexed into an ODU2, as ODU1 #1. The ODU2 is multiplexed into an ODU4, as ODU2 #1. The ODU4 is carried directly by a single OTSi that is the only one using the MEDIA at this point.

In addition, an ODU1, is connected between the right and left Line Cards. The ODU1 is #4 in ODU2 #1 on both sides [42] .

 

 

 

Figure VIII.1- 3   Basic OTN device supporting STM 16 tributary ports

VIII.2 Circuit layer examples

VIII.2.1 Single layer examples

Figure VIII.2 - 1 shows multiplexing of ODU2 into ODU4.

 

Figure VIII.2- 1   ODU4 server with ODU2 clients

Figure VIII.2 - 2 show s an ODU4 supporting both ODU0 and ODU2 clients at the same time.

Figure VIII.2- 2   ODU4 server with both ODU0 and ODU2 clients

Figure VIII.2 - 3 shows the mapping of a 100GE client into an ODU4.

Figure VIII.2- 3   ODU4 server with 100GE client (direct mapping)

VIII.2.2 Multi-layer examples

Figure VIII.2 - 4 , shows the multiplexing of ODU2 into ODU4. Then the ODU4 is mapped into an OTU4.

Figure VIII.2- 4   OTU4 server with ODU4 client with ODU2 clients

Figure VIII.2 - 5, shows an Ethernet client GFP-F mapped into an ODUFlex which is multiplexed into an ODU4.

Figure VIII.2- 5   ODU4 server with ODUFlex client with a GFP-F mapped Ethernet client

Figure VIII.2-6 shows an ODU4 server with both ODU2 and ODUFlex clients.

Figure VIII.2- 6   ODU4 server with both ODU2 and ODUFlex clients

 

 


Appendix IX

Packet Switched (L2 & L3) Examples

(This appendix does not form an integral part of this Recommendation.)

 

The content of this Appendix is for further study.

 

 


Appendix X

Control and Signalling Examples

(This appendix does not form an integral part of this Recommendation.)

 

The content of this Appendix is for further study.

 

 


Appendix XI

Timing and Synchronization Examples

(This appendix does not form an integral part of this Recommendation.)

This appendix provides a description of time and frequency synchronization in a telecommunications network and provides examples of the use of the CIM abstractions to model these synchronization functions.

The examples in this appendix extend the simple examples given in Annex K .

XI.1 Network synchronization overview

The figure below shows an example of a (simple) synchronization network.

Figure XI.1- 1 Example synchronization distribution network

From a management perspective, the Master Clock can be represented by an instance of the clock and the node containing a network equipment clock can be represented by instances of Processing Construct (PC), that encompass LTP, FD and clock, with links to interconnect the nodes. Typically, only a subset of the links in a network are enabled, by management/control actions, to support the transfer timing information. Two types of information may be carried over these links: The timing information (frequency or time stamp) and (optionally) information about the source of the timing information. These links are typically used to carry both timing information and network traffic but some may be dedicated to synchronization. This is illustrated in the figure below.

Figure XI.1- 2 Full timing distribution topology

The ensure the correct operation of the synchronization network each node will select one of the timing inputs and distribute the resultant timing information. This results in a pruned topology as illustrated below.

Figure XI.1- 3 Reduced/pruned timing distribution topology

The pruned topology could be defined manually or: By allowing the nodes to be autonomously configured by PTP (using BMCA) or by Sync Status Messages (SSM) or: by some combination of manual and autonomous configuration. If some degree of autonomous control is permitted, then the selected topology will be updated when a failure occurs. Typically, a network operator would define the set of inputs that are used in the autonomous selection process and the priority assigned to each of these enabled inputs.

To ensure correct operation of the synchronization network the input used by the network element clocks should, when possible, be derived from the master clock. It is essential that, under fault conditions, the formation of timing loops is prevented.

Standard SSM messages only provide clock quality information which is insufficient to guarantee loop free operation under fault conditions so the links that are enabled to support timing information must be selected to avoid timing loops.

The PTP protocol provides both clock quality information and additional information about the clock source including its identity and domain membership. This allows the BCMA to select the best quality input, from those clocks within the timing domain, and avoid timing loops.

The simple network example shows a single master clock, however, in a typical synchronization network additional (secondary) master clocks are present.

XI.2 Processing of timing information in a node

To fully describe and manage the synchronization aspects of a node the PC describe above must be expanded to expose the internal details. This expansion, for a PTP clock, is shown in the figure below.

Figure XI.2- 1 PTP node expansion

The termination of the trails carrying the timing information is represented with an LTP with the appropriate layer protocol(s). The extraction of the components of the timing information (time stamp and timing source information) is represented by a LTP with a layer protocol of synchronization (Sync LTP). The time stamp is forwarded to a FC, this FC has m inputs and one output. The timing source information is forwarded to a Configuration and switch controller (C&SC). The Sync LTP and the relationship to the FC and C&SC is only present for those inputs that have been enabled to support synchronization. The management/control system also assigns a selection priority to each input. The C&SC uses the timing source information together with the locally configured priority and any local commands to configure the FC to forward the time stamp from the selected input to the clock. If none of the inputs are selected the clock enters hold-over or free-run mode. The clock is an analog device that essentially integrates the time stamps and produces a smoothed output time stamp. The output time stamp is forwarded to all of the Sync LTP that have been enabled to support timing information. The clock source/quality information is also forwarded to these sync LTP. The C&SC informs the sync LTPs which input has been selected and the Sync LTPs modify the clock source/quality information.

The same abstraction, with the appropriate parameters, can be used for frequency synchronization.

Typically, a node will support redundant clocks. This is illustrated in the figure below.

Figure XI.2- 2 Node with redundant clocks

Both clocks receive the same time stamp input, one is selected as the master and provides a phase alignment signal to the slave. The FC protection selects the master clock and forwards the time stamp to the enabled sync LTPs. The clock source/quality information is also forwarded to these sync LTP by the FC protection. The master can be selected either automatically based on the status of the clocks, or by a local management inputs.

XI.2.1 Refactoring the synch model

If visibility of the operation of the node is not required the sync model can be refactored into a Processing Construct that encompasses the Sync LTPs, FC-selector, C&SC, clock and FC protection. This is illustrated in the figure below.

Figure XI.2- 3 Node represented by a processing construct

In this case the Sync LTP attributes are reported against ports on the PC and the parameters of the clock are reported against the PC.

XI.3 Synchronization model attributes

The attributes provided in this section [43] support frequency synchronization using SSM and time synchronization using the Telecom profile of [IEEE 1588]. These parameters need to be validated by ITU-T SG15, Q13/15 and Q14/15.

XI.3.1 Existing NE object

 

Attribute Name

Description

Type

Sync_Support _freq

Indicate whether the NE has the capability to support frequency synchronization.

Enumeration – Read only:
[ITU-T G.813]; [ITU-T G.812]; etc.

Freq Sync support enabled

Allows the frequency sync functions to be deactivated

Boolean – Read/Write:

Default : enabled

Sync_Support_time

Indicate whether the NE has the capability to support time synchronization.

Enumeration – Read only:
Boundary clock (BC); Transparent clock (TC) etc.

Time Sync support enabled

Allows the time sync functions to be deactivated

Boolean – Read/Write:
Default: enabled

 

XI.3.2 Clock

XI.3.2.1 Frequency sync (SSM) pac

 

Attribute Name

Description

Type

system clock ID

The ID of the SyncClock_Frequency object.

Object ID
frequ and PTP could use a common attribute definition

Object ID read only

associated node ID

The SyncClock_Frequency object is associated with the NE of this node ID.

Object ID
frequ and PTP could use a common attribute definition

Object ID read only

run-mode

The run-mode of the frequency system clock, such as freerun, locked, and holdover.

Enumeration - Read only;
Freerun; locked; holdover
frequ and PTP could use a common attribute definition

Enumeration – r ead only

internal clock SSM

The SSM quality level of internal clock of the NE.

Enumeration - Read only
[ITU-T G.813]; [ITU-T G.812]; ???
frequ and PTP could use a common attribute definition

Enumeration – r ead only

 

XI.3.2.2 Time Sync (PTP) pac

 

Attribute Name

Description

Type

PTP system clock ID

The ID of the SyncClock_Time object.

Object ID
frequ and PTP could use a common attribute definition

Object ID read only

associated node ID

The SyncClock_Time object is associated with the NE of this node ID.

Object ID
frequ and PTP could use a common attribute definition

Object ID read only

PTP enable status

Indicate whether the NE enables PTP function or not.

Boolean – read/write?

Boolean – read/write

run-mode

The run-mode of the PTP system clock, such as tracing and non-tracing.

Enumeration - Read only:
Freerun; locked; holdover
frequ and PTP could use a common attribute definition

Enumeration – r ead only

PTP domain

The PTP domain number of the NE.

Integer or string – Read/write?

Integer – r ead/write

PTP device-type

Three PTP device types are included: boundary clock (BC), transparent clock (TC), and ordinary clock (OC).

Enumeration - Read only
boundary clock (BC), transparent clock (TC), and ordinary clock (OC).
frequ and PTP could use a common attribute definition with different enumerations

Enumeration – r ead /write

PTP slaveonly

Indicate whether the NE can only be used as PTP slave or not.

Boolean - Read only?

Boolean – read/write

PTP source dataset

The PTP status dataset of current tracing source.

Ordered list - Read only:

grandmasterIdentity – Object ID – Read only ,

parent ID – Object ID – Read only ,

priority 1 – Integer – Read only,

priority 2 – Integer – Read only,

clockClass – Integer – Read only,

accuracy – Integer – Read only,

offsetScaledLogVariance – Integer – Read only,

timesource – Enumeration – Read only,

stepsRemoved – Integer – Read only,

currentUtcOffset – Integer – Read only,

ptpTimescale – Enumeration – Read only,

timeTraceable – Boolean – Read only,

frequencyTraceable – Boolean – Read only,

[IEEE 1588] protocol version – Integer – Read only,,

current absolute time – Integer – Read only.

PTP default dataset

The PTP status dataset of internal clock of the NE

Ordered list – Read/Write:

CLK ID – Object ID – Read/Write,

priority 1 – Integer – Read/Write,

priority 2 – Integer – Read/Write,

clockClass – Integer – Read/Write,

accuracy – Integer – Read/Write,

offsetScaledLogVariance – Integer – Read/Write,

timesource – Integer – Read/Write,

stepsRemoved – Integer – Read/Write,

[IEEE 1588] protocol version – Integer – Read/Write.

 

XI.3.3 Sync LTP

XI.3.3.1 SSM in band pac

All of the attributes that report/manage SSM quality level can use a common enumeration.

 

Attribute Name

Description

Type

clock port ID

The ID of the SyncLTP_In_Band_Clock object.

Object ID – read only

associated port ID

The SyncLTP_In_Band_Clock object is associated with the physical port LTP of this port ID.

Object ID – read only

SSM output enable status

Indicate whether to send SSM messages or not.

Boolean – read/write

SSM information

Current input and output SSM quality levels used by the port. The SSM quality level can be set manually or automatically.

Enumeration – Read/Write

e.g: PRC, SSU-A, SSU-B, QL-SEC, DNU, etc.

SSM mode

Indicate whether to use manual or automatic input and output SSM quality levels.

Enumeration– Read/Write:

Manual or Automatic

SSM configuration

The input and output SSM quality levels set manually.

Enumeration – read/write

 

XI.3.3.2 SSM external clock

 

Attribute Name

Description

Type

external port ID

The ID of the SyncLTP_External_Clock object.

Object ID – read only

external port enable status

Indicate whether to enable this external port or not.

Boolean – read/write

bits-type

The type of this port, such as 2048kb/s or 2048kHz.

Enumeration read only

SSM sa-bit

Indicate which sa-bit bits are used for carrying input and output SSM quality levels.

Enumeration – read/write

SSM out-threshold

The external port stops transmitting when the SSM quality level is lower than the threshold.

Enumeration – read/write

SSM information

Current input and output SSM quality levels used by the port. The SSM quality level can be set manually or automatically.

Enumeration – read only

SSM mode

Indicate whether to use manual or automatic input and output SSM quality levels.

Enumeration– Read/Write:

Manual or Automatic

SSM configuration

The input and output SSM quality levels set manually.

Enumeration – read/write

 

XI.3.3.3 PTP pac

 

Attribute Name

Description

Type

PTP port ID

The ID of the SyncLTP_PTP object.

Object ID – read only

associated port ID

The SyncLTP_PTP object is associated with the physical port LTP of this port ID.

Object ID – read only

PTP port enable status

Indicate whether to enable this PTP port or not.

Boolean – read/write

PTP port state

The current PTP state of the PTP port, such as master, slave, passive, initializing, listening, premaster, uncalibrated, and faulty.

Enumeration – read only

PTP asymmetry-correction

The asymmetry correction value of this PTP port.

Integer, nano seconds – read/write
same as external time port delay compensation?

Integer – read/write

PTP clock-step

Indicate whether one-step or two-step mechanism is adopted.

Enumeration – read only

PTP udp-egress  configuration

The configuration of PTP UDP encapsulation, including source IP address, destination IP address and IPv4/IPv6 protocol .

Ordered list – Read/Write:

source IP address – String – Read/Write ,

destination IP address – String – Read/Write ,

IPv4/IPv6 protocol – Enumeration – Read/Write .

PTP mac-egress  configuration

The configuration of PTP MAC encapsulation, including source MAC address, destination MAC address and VLAN configuration.

Ordered list – Read/Write:

source MAC address – String – Read only ,

destination MAC address – String – Read only ,

VLAN configuration – String – Read/Write

PTP announce-interval

The sending interval of PTP announce message.

Integer: milli seconds – read/write

PTP announce receipt-timeout

It is used for fault detection of PTP announce messages.

Integer: milli seconds – read/write

PTP sync-interval

The sending interval of PTP Sync message.

Integer: milli seconds – read/write

PTP min-delayreq-interval

The sending interval of PTP Delay_req message.

Integer: milli seconds – read/write

 

XI.3.3.4 PTP 1PPS + ToD pac

 

Attribute Name

Description

Type

external port ID

The ID of the SyncLTP_External_Time object.

Object ID – read only

external time port status

Indicate whether this external time port is used as an input or output port.

Boolean - read only

external time port dataset

The status dataset of this port

Ordered list – Read / W rite :

grandmasterIdentity – Object ID – Read / W rite ,

priority 1 – Integer – Read / W rite ,

priority 2 – Integer – Read / W rite ,

clockClass – Integer – Read / W rite ,

accuracy – Integer – Read / W rite ,

offsetScaledLogVariance – Integer – Read / W rite ,

timesource – Integer – Read / W rite ,

stepsRemoved – Integer – Read / W rite ,

currentUtcOffset – Integer – Read / W rite .

external time port delay compensation

The delay compensation value of this external port.

Integer, nano seconds – read/write
Same as PTP asymmetry-correction?

Integer – read/write

 


Appendix XII

Processing Construct Examples

(This appendix does not form an integral part of this Recommendation.)

This appendix provides various examples of the use of the ProcessingConstruct model to represent complex functions.

The examples in this document extend the simple examples given in Annex K

XII.1 General examples

XII.1.1 Types of Processing Construct

In this clause, we will go through a number of different types of 'device' and show how the ProcessingConstruct concept allows us to represent them all in a consistent way.

XII.1.1.1 Traditional 'Device' [44]

The simplest common case that we have is where we have a physical unit that is logically a single unit and is managed as a single unit. That is, the physical, logical and management scopes are congruent.

Figure XI.1- 1 Traditional 'Device' representation deconstructed

Because a number of simple devices fit this special case, unfortunately it was used as the general case, which is problematic for the other cases that we will now look at.

XII.1.1.2 Partitioned 'Device'

For this example, we will assume that we have a single physical unit that can be logically partitioned and that the management is also partitioned. There may be a number of variations on this theme but we will just cover this basic case.

The traditional NetworkElement concept can't effectively represent this case because it assumes congruence between the physical, logical and management scopes.

Figure XI.1- 2 Partitioned 'Device'

We will now look at how to use the ProcessingConstruct and ConstraintDomain classes to model this case.

The first thing to understand is that there will be some constraints related to the physical scope, and a ConstraintDomain instance should be created to support that.

Secondly, we also have constraints that are related to the partitions, and a ConstraintDomain should be created per partition.

Note that in our example, one of the domains has a larger scope than the others – this will depend on how the partitioning works and there may be many options – the important thing is to create the CD to match the scopes.

XII.1.1.3 Distributed 'Device'

For this example, we will assume that we have many physical units that can be logically aggregated to behave as a single logical unit and that the management is also aggregated. There may be a number of variations on this theme but we will just cover the basic case where we have one central unit and one or more 'satellite' units.

Again, the traditional NetworkElement concept can't effectively represent this case because it assumes congruence between the physical, logical and management scopes.

Figure XI.1- 3 Distributed 'Device' with separate Management Agents

We will now look at how to use the ProcessingConstruct and ConstraintDomain classes to model this case.

The first thing to understand is that there will be some constraints related to the physical scopes, and ConstraintDomain instances should be created to support that.

Secondly, we also have constraints that are related to the aggregated functionality, and a ConstraintDomain should be created for the 'distributed device'.

ProcessingConstructs should be created to map to how the functionality works; some PC may be constrained by the physical scopes and some may span the entire logical device. Partial control plane synchronization technologies [45] like ICCP ( Inter-Chassis Communication Protocol RFC 7275) , vPC (Virtual Port Channel, multi-chassis link aggregation) would be associated with the 'distributed device' Constraint Domain. In these cases, there are multiple control planes (where only part of the configuration is synchronized).

In the management plane, there may be some independent device management, or the management may be only at the distributed device level.  Lightweight Wireless Access Points that are remotely managed may be an example of the aggregated management case. Aggregating technologies like stacked switches and VSS that merge complete control planes are another example of this case (two peer devices share the one control plane and the one MA).

Shown below is a more complex example where we combine partitioning and aggregation. If you try and draw a 'NE boundary' similar to those in the figure above, you will quickly find that there isn't a sensible answer.

Figure XI.1- 4 Logically Split Chassis

The steps to model this are the same as before:

  • Create ConstraintDomains to represent the actual constraint scopes
  • Create ProcessingConstructs and assign them to the relevant ConstraintDomains

XII.1.1.4 Virtual ‘Device'

Here we will assume that we have a physical host (of some form factor) that is running a virtualization technology (Virtual Machine or Container) that is running software that provides some managed functionality.

 

Figure XI.1- 5 " Virtual" Device

We will now look at how to use the ProcessingConstruct and ConstraintDomain classes to model this case.

The first thing to understand is that there will be some constraints related to the physical scope, and a ConstraintDomain instance should be created to support that.

Secondly, we also have constraints that are related to each VM / Container, and a ConstraintDomain should be created for each of these. Note that in this release of the ONF CIM, we don't have a software model that would allow us to represent the guest and host operating systems or the hypervisor / VMM (Virtual Machine Manager).

XII.1.1.5 Virtual Distributed ‘Device’

For this example, we will assume that we have many 'virtual' units that can be logically aggregated to behave as a single logical unit and that the management is also aggregated. There may be a number of variations on this theme but we will just cover the basic case where we have one central unit and one or more 'satellite' units.

As shown in the diagram below, we have a distributed virtual switch (DVS), where a VM runs a central switch module and remote modules run on other VMs. Note that other complete or partial control plane synchronization technologies [46] like stacked switches and VSS, ICCP ( Interchassis Communication Protocol RFC 7275 ), vPC (Virtual Port Channel, multi-chassis link aggregation) would be associated with a 'distributed device' Constraint Domain.

Figure XI.1- 6 "Virtual" Distributed Device

We will now look at how to use the ProcessingConstruct and ConstraintDomain classes to model this case.

The first thing to understand is that there will be some constraints related to the physical host scopes, and ConstraintDomain instances should be created to support that.

Secondly, we also have constraints that are related to each VM / Container, and a ConstraintDomain should be created for each of these. Note that in this release of the ONF CIM, we don't have a software model that would allow us to represent the guest and host operating systems or the hypervisor / VMM.

Thirdly we also have constraints that are related to the aggregated functionality, and a ConstraintDomain should be created for the 'distributed device'.

ProcessingConstructs should be created to map to how the functionality works; some PC may be constrained by the physical scopes and some may span the entire logical device.

In the management plane there may be some independent device management, or the management may be only at the distributed device level. 

XII.1.1.6 SDN Controller [47]

Shown below is a simplified block diagram of a SDN controller.

The SDN controller itself is similar to (the control plane of) a network element, so we will represent it using a ConstraintDomain. PeerContext is a generalization of client and server context and because it is a scoping concept, representing it as a ConstraintDomain would be appropriate.

If other scoping concepts such as resource groups are required, then they would also be ConstraintDomains.

Inside the SDN controller will be a number of processing constructs. Similar to our other examples this could include things like a BGP routing control process, a PTP clock control process or an ERP G.8032 control process. The SDN controller itself isn't one massive ProcessingConstruct.

Figure XI.1- 7 SDN Controller

The SDN controller host (physical or VM container) would be represented as shown in the other examples.

Also, the PC/CD model can cope with the SDN controller being centralized or distributed, as shown in the other examples.

XII.1.1.7 Other 'Devices'

The previous examples show a number of basic ways that functionality can be related to the underlying hardware and to the management plane.

There may be other real world cases (that are probably hybrids of these fundamental cases), but the important thing is that the decoupled model design allows for many other options.

XII.1.2 PTP Clock Example

The figure below is covered at a high level in Annex K and now we will look at it in more detail.

Figure XI.1- 8 PTP Clock Concepts

Given the functional block diagram above, the question is what the resultant model should be.

The UML class diagram below shows a possible solution.

The PTP clock PC function (in the figure above) is in PtpClockFunction class (in the figure below) and the attributes of the PcPort (shown as "In" and "Out" in the figure above) are in PtpClockPort (in the figure below).

The PTP protocol also has a domain concept, where clock domains form separate topologies (clocks only peer when the domain matches). A ConstraintDomain can be used to show this network level constraint (PtpClockDomain below).

Figure XI.1- 9 PTP Model sketch

XII.1.3 ERPS G.8032 Example

The figure below is covered at a high level in Annex K , and now we will look at it in more detail.

Figure XI.1- 10 ERP G.8032 Concept Example

Given the functional block diagram above, the question is what the resultant model should be.

The UML class diagram below shows a possible solution.

ErpNodeCd is a ConstraintDomain that can be used to group all of the ERP rings in the device (shown as ERP Node X in the figure above). It can also be used to hold any 'device level ERP global attributes'.

ErpRingNode is a ConstraintDomain representing the part of the ring in the 'device' (shown as ERP Node X Ring Y in the figure above) and has the related Po and P1 port configuration attached.

ErpInstanceNode is the ProcessingConstruct representing the instance of the ring on the 'device' (shown as ERP Node X Ring Y Instance Z in the figure above) [48] and has its related port configurations.

An ErpRingNode can contain many ErpInstanceNodes.

As discussed in the main document, the network level scopes of ErpRing and ErpRingInstance can be represented using ConstraintDomain and the relevant PC related to these CD.

Figure XI.1- 11 ERP Model Sketch

 

 

 

 


Appendix XIII

Specification Examples

(This appendix does not form an integral part of this Recommendation.)

This appendix provides various examples of the use of the CIM specification model to express constraints in various real contexts.

The examples in this document are built from descriptions in earlier referenced works. 

XIII.1 General examples

 

XIII.1.1 The FD and FC Spec

This section focusses on the use of the FD spec to state restrictions in a network or NE/device wrt creation of FCs. The FD spec is used in conjunction with the FC spec for this purpose. A "fabricated example" NE/device is used where the rules and restrictions do not represent any particular device/NE type known. It is likely that those familiar with various devices from various vendors will be able to recognize where rules of the sort described could be used.

XIII.1.1.1 A basic NE/device example

XIII.1.1.1.1 FC spec used for the basic NE/device

The following figure provides an FC spec for a NE/device.

Figure XIII.1- 1 FC spec for unprotected FC

XIII.1.1.1.2 The NE rules

The NE has the following characteristics:

       The NE supports bidirectional "Point-To-Point" FCs (specs shown below) with "traditional" restrictions described below.

        All ports on the NE are multi-channel

       The NE has 4 card types

        Type 1 which has a single port which does not allow connectivity between channels on the port

        Type 2 which has 8 ports that cannot do any port to port connectivity within the card

        Type 3 which has 8 ports that can do arbitrary port to port within the card including from a channel within a port to another channel within the same port

        Type 4 which has 8 ports that can do arbitrary port to port but cannot do connect two channels in the same port

       A port on a Type 1 card can connect to a port on

        Another card of Type 1 on a same channel basis  (or no vid swapping etc)

        A Type 2/3/4 card with no channel restriction

       There is a backplane capacity limit between trib and Line port cards of one Line port capacity

        A traditional NE might call the port on the Type 1 card a Line port and a port on the Type 2/3/4 card a trib port

XIII.1.1.1.3 Representing the NE restrictions

The NE can be represented using FD rules as set out in the figure below.

Figure XIII.1- 2 FD spec for a "fabricated" NE/device type

From the figure it can be seen, for example, that:

  • Any "channel" on a port on an instance of card type 3 (in slot 3 and slot 6) can connect to any "channel" on any port (including the same port) on the same card instance.
  • A "channel" on the port of the instance of card type 1 in slot 1 can connect to the same "channel" on the port of the instance of card type 1 in slot 2.
  • Any "channel" on the port on an instance of card type 3 (in slot 3) can connect to any "channel" on any port on the same card instance.
  • Any "channel" on a port on an instance of card type 4 (in slot 5) can connect to any "channel" on any port (but excluding the same port) on the same card instance.
  • There is a capacity limit between the ports on the left and the ports on the right such that FC can be constructed between those ports until the capacity is reached.

The above rules are encoded in data following the model shown in the figure and discussed in more detail in Annex G . Instances of class of the model can be arranged to show the restrictions of a device or a network. If there are many instances of device with the same restrictions the same instances of rules can be used.

XIII.1.1.2 Enhancements to the basic NE

In the figure below the device discussed above is enhanced such that it is possible to set up FCs between ports in slot 4 and ports in slot 5 on a same "channel" basis.

Figure XIII.1- 3 Simple FD Spec showing further overlay of rules

 

       As before the NE supports "Point-To-Point" FCs with traditional restrictions

       The NE also supports "Protected" FCs with similar (related) restrictions

        A trib port can be protected by the Line ports where there is the same channel between Line ports but the trib port may be any channel

       And the NE supports "Back-To-BackSNCP" FCs

        Two trib ports on any cards can be protected by and can protect two Line ports where there is a same channel rule between Line ports but no channel restriction on the trib ports

       Finally the NE supports "Root-leaf" FCs

        Where the Line ports are the roots and the tribs the leaves

        Leaves can be interconnected on some cards

        Some cards can only support a single leaf

       With all of the above there is a total backplane capacity limit between Trib and Line port cards of one Line port capacity (x)

XIII.1.1.3 NE supporting more FC types

XIII.1.1.3.1 FC specs for more sophisticated NE example

The figure below shows FC specs for protected and root/leaf FCs.

Figure XIII.1- 4 FC spec for protected and root/leaf FCs

XIII.1.1.3.2 Representing the NE restrictions

A device could support the FC types set out above as shown below. As overlaying all the rules would make the figure impossible to read the overlays are set out side by side. The "fabricated" device has a single FD that supports all capabilities set out in the figure below.

Figure XIII.1- 5 Simple FD Spec showing additional capabilities

XIII.1.1.4 Alternative representations of the same capability

The rule system allows various representations of the same capability. It is not intended that the patterns of rules be standardized. It is expected that the rules will be interpreted and hence as long as the rules conform with the rule model then an interpreter should be able to follow them. Some rule combinations will be more efficient than others at stating the viability of a particular FC. It is up to the coder of the rules to choose the rule form.

Figure XIII.1- 6 Simple FD Spec showing additional capabilities

It should be noted that the rule system can be used to create a connectivity/connectability matrix if every channel of every port has a dedicated rule statement to every channel of every other port in the device. Clearly this yields an extremely verbose solution where the construction of the rule structure would be particularly prone to error. Unless the forwarding restrictions of the device/network are extremely complicate and are not patterned it is recommended that a connectivity/connectability matrix approach is not used.

XIII.1.1.5 FD rule precedence

The overlaid FDs interact both at an FD level and at a rule level

XIII.1.1.5.1 Rule FD precedence

Overlaid FDs interact such that:

       An FD with no rule FDs has no restrictions and is essentially May/Any

       LTPs in an FD that are also in a rule FD contained in the FD

        Abide by the rules of the rule FD

        Are interconnectable to any LTP in the FD not in any contained rule FDs on a May/Any basis

       An FD that has no rule FDs but that is contained in an FD with contained rule FDs is essentially May/Any but FCs will be indirectly restricted by the superior FD rules

        It is expected that in any view the rule FDs will be at the lowest levels of decomposition

XIII.1.1.5.2 Rule precedence

Rules interact such that:

       Priority n rules override priority n+1 rules

       Within a priority the rules override as follows (lower number overrides higher number)

  1. Not (MUST_NOT_CONNECT)
  2. Must (MUST_CONNNECT)
  3. May (MAY_CONNECT)
  4. Null (NULL_FORWARDING_RULE (default))

       Which overrides nothing regardless of the override priority

       Within a rule the flexibility rules override as follow:

  1. Any
  2. Same X
  3. Same X and Same Y rule will form an intersection such that both need to be met

 

XIII.1.2 Applying rules

This section explores, via some abstract examples, the application of specifications to instances of classes.

XIII.1.2.1 Basic application of specs to a class and instances

The figure below shows the basic use of a spec, via an example, where each instance references both the class, X (by definition), and a schema defined by one or more other classes P, Q or R. The instance gains the attributes of the Class X and the relevant spec classes (in the case of Instance X.1 the attributes are acquired from spec P (i.e. attribute P)). Class X indicates in its definition that instances of it will reference one or more specs. Each spec indicates the classes that it can apply to and in this case P, Q and R can all apply to Class X. Clearly there will be other classes in the model that P does not apply, there may be other classes that P does apply to and there may be other specs that do not apply to Class X.

 

Figure XIII.1- 7 Basic spec application

XIII.1.2.2 Spec with outgoing pointer

The figure below builds on the figure in the previous section and adds a simple reference from a spec class to a class, Class Y (assumed for this example to be in the same model as class X). There is nothing special about the relationship from P to Class Y. The instance of X that reference spec class P acquire the attribute pointer to Class Y and hence can reference an instance of Y. In the example shown below the Instance X.1 reference Instance Y.6 via the attribute acquired from spec class P.

As Instance X.2 refers to a spec class R that does not refer to Class Y, Instance X.2 cannot reference an instance of Class Y. So Instance X.2 references Instance Y.9 is not allowed.

Figure XIII.1- 8 Outgoing pointer from spec

XIII.1.2.3 Spec with outgoing pointer from spec to spec

A spec can be composed of other specs. The figure below shows how a spec class J is a composed part of spec class P. In the example, Instance X.1 refers to spec class P and hence acquires the attributes of P but it also acquires the composed part Jx which is locally identified in Instance X.1 where Jx conforms to the spec class J. J may be used in the specs of many classes in the model.

Figure XIII.1- 9 Outgoing pointer from spec to spec

 

XIII.1.2.4 Incoming pointer to spec

The previous cases were somewhat normal in form. The case described here is more complex. An instance of Class Y can have an association to an instance of Class X only where the instance of Class X references spec class P.

Class Y has a normal association to Class X but the association end attribute has a constraint that references spec class P. As Instance X.2 does not reference spec class P, Instance Y.6 is not allowed to reference Instance X.2 (note that in the diagram Instance Y.6 is shown twice).

Figure XIII.1- 10 Incoming pointer to spec

In the following figure, Class Y simply has a constraint list entry of spec class P. The specific mechanism is that Class Y has an association to spec class P. In the instantiation of Class Y the association is transformed to an attribute of an unspecified class that takes that can reference any Instance.

The only instances that are allowed to be referenced are those that reference spec class P. In this case Instance X.1 references spec class P and so can be referenced by Instance Y.6 but Instance X.2 does not reference spec class P and so cannot be referenced by Instance Y.6 (note that in the diagram Instance Y.6 is shown twice).

In this form, unlike the previous form, any class that spec class P references can have instances that can be referenced by Instances of Class Y (i.e. not just instances of Class X).

 

Figure XIII.1- 11 Incoming pointer to spec – sparse form

XIII.1.2.5 Outgoing pointer from spec to spec

In this case, it is necessary for some but not all cases of one class (in this example Class X) to be allowed to relate to some but not all cases of another class (in this example Class Y). To achieve this, a spec class, P, that specifies Class X references a spec class, F, that specifies Class Y.

In the instantiation, just as in the previous case, the association end attribute is of unspecified class. So, whilst the association end attribute in spec class P is specific to spec class F, the attribute in Instance X.4 is unspecialized, i.e. can reference an instance of any class.

Figure XIII.1- 12 Outgoing pointer from spec to spec

XIII.1.2.6 Incoming pointer from spec extension to spec

In some cases, a spec class may be extended after it has been defined (i.e. independently of its construction) without changing the spec class. The extension is composition but the spec class to be extended does not carry the attribute reference. The extension provides a reference that is essentially reverse navigable.

In the example an Instance X.1 references spec class P and acquires those attributes, it also has a composition navigable from Instance X.1 to local Instance Jx, where Instance Jx reference spec class J. This is valid against the specs due to the reverse navigable composition.

Figure XIII.1- 13 Incoming pointer from spec extension to spec

The figure below provides a sketch of the realization of an instance of X. The "Instantiation Policy" guides the "Instantiation Engine" to extend instances of Class X that are specified by spec class P with spec class J. If, as is probably normally the case, all instances of Class X that are specified by spec class P should also be extend by spec class J, then the policy can be automatically constructed by exploring the spec repository for all spec that have appropriate references to spec class P and ensuring that the policy includes the extension. In this case it is assumed that only spec class J exists as an extension of spec class P.

Figure XIII.1- 14 Incoming pointer from spec extension to spec with policy

XIII.1.3 LTP spec examples

Examples of LTP/LP spec will be provided in a later release. Work is proceeding on [ONF TAPI] on LTP/LP Specs.

 


Appendix XIV

Resilience Examples

(This appendix does not form an integral part of this Recommendation.)

This appendix provides various examples of the use of the CIM to represent common resilience schemes. This appendix is not exhaustive. The model is built from a several generalized constructs that should readily support many other protection schemes not described here.

The examples in this appendix are built from descriptions in other parts of the Recommendation, especially Annex E [49] .

The following diagram highlights the symbols used for various classes in the resilience model.

  Figure XIV- 1 Instance diagram key

XIV.1 Linear protection schemes

XIV.1.1 1?1 cases

 

This section deals with basic 1+1 and 1:1 cases and shows how they can be represented. The abbreviation 1?1 has been used where the description is common between both 1+1 and 1:1.

Figure XIV.1- 1 Simple summary example of 1?1 cases (represented  via partition)

The figure above shows a simple summary example of a 1?1 case in a basic network with three NEs. Clearly this can be generalized further to be in a rule form. A specific solution can include zero or more NEs on either path [50] . The end-end FC is partitioned into subordinate (i.e. is an aggregation of the subordinate parts via FcHasLowerLevelFcs). The scheme may involve signalling.

Figure XIV.1- 2 Showing detail of a single ended view of 1+1 and 1:1 switches

The figure above shows a nodal view and highlights ConfiguraionAndSwitchControllers (C&SC) encapsulated in the FcSwitch in some cases and in FC in others. The encapsulation chosen depends upon the scope of control of the C&SC. The encapsulation is via FcSwitchCoordinatedByInternalControl when in the FcSwitch and FcSwitchesInFcCoordinatedBySwitchCoordinator when in the FC.

Figure XIV.1- 3 Showing an emergent abstract controller in a 1:1 case

 

The figure above shows a case of 1:1 independent switching (where the two directions of traffic are switched independently). The figure assumes that there is a distributed control solution (where the C&SCs in the FCs signal each other) and highlights an emergent C&SC which does not actually exist in the real control solution but which can be expressed to collect together parameters that should be set to the same value at both ends. In the network the coordination occurs through peer signaling. Above the network the SDN controller may realize the coordination [51] .

Figure XIV.1- 4 Showing a basic route based representation of the 1?1 protection scheme

The figure above shows an alternative representation of the 1?1 to that shown in Figure XIV.1- 1 Simple summary example of 1?1 cases . In the representation above two FcRoutes are used to represent the two alternative flows across the network. It should be noted that the FCs at the ends of each route are associated with the same LTPs and are only not conflicting because of the switches that they encapsulate (which when appropriately coordinated can ensure that only one FC is feeding the LTP at any time). The FcPort that can be switched off, i.e. be open, to ensure conflict can be avoided are depicted in grey (an output FcPort that can be switched off can share an LTP with another similar output FcPort and hence is called a sharing FcPort in this document). The FcSpec would identify the port via the switch configuration definition.

The figure below shows an alternative, slightly more verbose, representation of the 1?1 protection using two levels of route whether the top level routes have FCs that have the same span and the end-end FC [52]

The FCs of the route are contained in the route via the RouteIsDescribedByFc composition association and hence are not members of an FD. The FCs are used to represent flow and are defined in terms of the LTPs they reference in the context of the Route. The FD if visible would still have the FCs as shown in Figure 3 - 1 Simple summary example of 1?1 cases .

 

Figure XIV.1- 5 Showing a two level route based representation of the 1?1 protection scheme

The figure below shows the preferred route based representation which is a hybrid of the two where the FC of a route is described in terms of FCs via the FcHasLowerLevelFcs such that the lower level (nodal) FCs are in the context of FDs via the FdContainsFcs aggregation (a usual partition).

Figure XIV.1- 6 Showing the preferred route based representation of the 1?1 protection scheme

This approach for the 1?1 case, which may involve signalling, with a decomposition then partition is used in following diagrams.

The figure below shows the ConfigurationAndSwitchController (C&SC) positions and their associations (ControllerGovernsSubordinateController). The figure shows a number of potential emergent controllers as well as some real controllers assuming a distributed control scheme.

Figure XIV.1- 7 Route based representation of the 1?1 protection scheme showing C&SCs

 

The figure below shows a nodal view for one route and highlights ConfiguraionAndSwitchControllers (C&SC) encapsulated in the FcSwitch in some cases and in FC in others. The encapsulation chosen depends upon the scope of control of the C&SC. The encapsulation is via FcSwitchCoordinatedByInternalControl when in the FcSwitch and FcSwitchesInFcCoordinatedBySwitchCoordinator when in the FC.

Some of the diagrams in the figure below (in dotted red ellipses) use a mixture of output and input switches (designated by "o" and "i" respectively).

 

Figure XIV.1- 8 Showing detail of a single ended view of 1+1 and 1:1 switches in a route context

The figure below shows the interaction between the C&SCs of the FCs of the two routes. The interaction is via a balanced dual form of the ControllerGovernsController [53] association used to indicate a peer relationship. Setting values for one controller will affect the values in the peer.

Rules for the effect need to be stated in the spec. If aspects of the peering can be disabled this would lead to attributes to control those aspects.

 

Figure XIV.1- 9 Single ended view of 1:1 switches in a route context with peer C&SC coordination

The figure below shows the controller peering between routes (emergent as the scheme is assumed to be a distributed control scheme) and also the emergent control in the end-end FC. It is proposed that the orientation convention is that input switch is preferred when ambiguous.

 

 

Figure XIV.1- 10 Nodal controller peering in a route context

XIV.1.2 1?1 open protection cases

The figures in this section are similar to those in the previous section.

Figure XIV.1- 11 Simple summary example of open 1?1 cases

The figure above shows a simple summary example of an open 1?1 case (e.g. where only one end of the recovery scheme is within the scope of the SDN controller) in a basic network with three NEs. Clearly this can be generalized further to be in a rule form.

Figure XIV.1- 12 Showing an emergent abstract controller in an open 1?1

The figure above shows a case of 1:1 independent switching (where the two directions of traffic are switched independently). The figure assumes that there is a distributed control solution (where the C&SCs in the FCs signal each other) and highlights an emergent C&SC which does not actually exist in the real control solution but which can be expressed to collect together parameters that should be set to the same value at both ends. In the network the coordination occurs through peer signaling where the peer signaling is between C&SCs one of which is outside this view. Above the network the SDN controller may realize the coordination but to do this it will itself need to have communication with network peers (SDN controllers or other management-control entities) that control the off-network end(s) of the protection scheme.

Figure XIV.1- 13 Simple summary example of open 1?1 cases showing route approach

The figure below shows the preferred route based representation which is a hybrid of the two where the FC of a route is described in terms of FCs via the FcHasLowerLevelFcs such that the lower level (nodal) FCs are in the context of FDs via the FdContainsFcs aggregation (a usual partition).

The figure below shows the interaction between the C&SCs of the FCs of the two routes. The interaction is the same as discussed earlier for Figure XIV.1- 9 Single ended view of 1:1 switches in a route context with peer C&SC coordination .

Figure XIV.1- 14 Single ended view of open 1:1 switches in a route context with peer C&SC coordination

The figure below shows the controller peering between routes (emergent as the scheme is assumed to be a distributed control scheme) and also the emergent control in the end-end FC.

Figure XIV.1- 15 Nodal controller peering in a route context

XIV.1.3 1:N Cases

This section deals with basic 1:N cases and shows how they can be represented.

Figure XIV.1- 16 Simple summary example of 1:N cases (represented via partition)

The figure above shows a simple summary example of a 1:N case in a basic network. As shown in the detailed NE view at the bottom of the figure, the scheme provides protection to three traffic signals (1, 2 and 3) and also provides a lower grade path for "Extra Traffic" (E). The traffic signals 1, 2 and 3 normally each use a dedicated "Worker" [54] paths (W1-W3 (numbered to match the traffic signal numbers)). The Protection path (P) provides an alternative for any one of the Workers.  The "Extra Traffic", E, uses the protection path, P, when it is not needed to protect any of W1-W3. Clearly this can be generalized further to be in a rule form. A specific solution can include one more traffic paths.

The FC view shows only one of the traffic paths (1) and the "Extra Traffic" (E). The end-end FC representing the traffic path is partitioned into subordinate (i.e. is an aggregation of the subordinate parts via FcHasLowerLevelFcs) as is the "Extra Traffic" path (E). It should be noted that the nodal FC from E to P and the FC from 1 to W1 and P use the same LTP at P. The apparent conflict is resolved by the C&SC (not shown). The scheme will involve signalling.

 

 

Figure XIV.1- 17 Showing detail of a single ended view of 1:N line system

The figure above shows a nodal view and highlights ConfiguraionAndSwitchControllers (C&SC) encapsulated in the FcSwitch in some cases and in FC in others. The encapsulation chosen depends upon the scope of control of the C&SC. The encapsulation is via FcSwitchCoordinatedByInternalControl when in the FcSwitch and FcSwitchesInFcCoordinatedBySwitchCoordinator when in the FC.

In the case of 1:N with Extra Traffic it is necessary for the switch of the Extra Traffic to be coordinated with the switches for protection of the main traffic (and likewise for the switches of each of the main traffic signals to be coordinated). It is assumed here that there is a real C&SC that carries out that coordination. The C&SCs encapsulated in the FCs/FcSwitches are assumed subordinate and hence the ControllerGovernsController association is one way from the independent C&SC to the C&SCs in the FCs/FcSwitches.

 

 

Figure XIV.1- 18 Showing an emergent abstract controller in a 1:N case

The figure above shows a case of 1:N independent switching (where the two directions of traffic are switched independently). The figure assumes that there is a distributed control solution (where the C&SCs in the FCs signal each other) and highlights the emergent C&SCs (not all controllers are relevant for control and control may be scattered across the controllers [55] ).

The abstract C&SCs can be expressed to collect together parameters that should be set to the same value at both ends or to some other complementary values for competing switches at the same end. In the network the coordination occurs through peer signaling. Above the network the SDN controller may realize the coordination [56] .

In the figure above the Extra Traffic has been switched off although only one direction of the Protection route is being used. It is assumed here that the Extra Traffic is bidirectional in nature and the loss one direction makes the signal useless (and hence both directions should be switched together.

 

Figure XIV.1- 19 Showing route based representation of the 1:N protection scheme

The figure above shows a fragment of the route based representation.  The figure detail only shows one traffic signal to avoid clutter. All traffic signals and the Extra Traffic are modeled with the same essential form. Extra Traffic is shown in the figure below.

Figure XIV.1- 20 Showing Extra Traffic in a route based representation of the 1:N protection scheme

The figure below shows detail of C&SCs and switches for W1 in the 1:N scheme.

 

Figure XIV.1- 21 Showing independent two ended view of W1 route detail in a 1:N protection scheme

XIV.2 Mesh Network cases

XIV.2.1 N:1 with multicast nodal Cases

The figure below shows a fragment of an N:1 network wide scheme. It is assumed in the figure that I1 is an input from a network external to the one depicted and hence I1 is represented in the upper FC.

The scheme depicted is related to distribution unidirectional signal that has multiple resilient sources (rom left to right in the figure). There is assumed to be a single network that has essentially one vast network FC representing the points in the network where the signals are originated and are terminated and used etc. The depiction of the upper FC is intentionally vague as the focus here is not on the representation of termination but solely on the protection scheme. This structure would apply to broadcast TV and to time synchronization. The timing network is represented in detail as described in Annex B and Appendix XI .

Considering the protection scheme:

  • There may be many inputs carrying the same signal (or an equivalent)
  • There may be many outputs for this signal to be propagated to other places
  • There may be monitoring or use of the signal at any switching point
  • In the case of time synchronization there is some processing of the signal on transit that needs to be represented

The figure below only shows one node in detail. The small FC taking the inputs I1 to In feeds to a signal processing element represented by an LTP (grey) that then feeds O1 to Om via a single unidirectional multi-cast FC.

Figure XIV.2- 1 Showing a unidirectional N:1 scheme fragment

XIV.3 Ethernet Ring Protection [ITU-T G.8032]

XIV.3.1 The protection scheme

The [ITU-T G.8032] protection scheme is a network scheme that is built by constructing logical rings that are formed from assemblies of the basic nodal structure shown in the figure below.

Figure XIV.3- 1 [ITU-T G.8032] Ring node control and signaling

A logical ring is defined by the flow of signalling messages that control the protected ring. The protected traffic and control messages use the same links between nodes. When traffic frame enters the protected ring it is sent both ways round the ring. Continuous circulation of Ethernet frames within the ring is prevented by blocks in both the control and the traffic forwarding paths at some point in the ring. When a failure occurs these blocks are moved to position over the failure thus maintaining the flow of both traffic and signalling.

The scope of the scheme can be extended beyond the ring by adding Sub-Rings. The Sub-Ring is a partial ring from a signalling perspective. When one or more Sub-Rings are present the complete ring is called a Major Ring. The Sub-Ring closes protection via the Major Ring.

The two figures below show a view of [ITU-T G.8032] protection highlighting major ring and sub-ring configurations and examples ring behaviour on failure.

Figure XIV.3- 2 [ITU-T G.8032] Rings showing traffic flow under normal and failure conditions (1)

The figure above shows traffic that flows between a node in the Major Ring and a node in the Sub-Ring. The figure below shows how the major ring offers protection to traffic that is between nodes in the Sub-Ring

Figure XIV.3- 3 [ITU-T G.8032] Rings showing traffic flow under normal and failure conditions (2)

 

In a major ring that has no failure present the traffic block is typically positioned in the same place as the control signalling block (although fundamentally it need not be the case). In a sub-ring only the traffic needs to be blocked. Each active node in a ring has a controller for the ring to ensure the block behaviour. The signalling may transit nodes that are not involved in the scheme so long as the traffic transits the same nodes with no drop opportunity.

The protection scheme supports multiple overlaid logical rings (see Figure XIV.3- 13 Two overlaid [ITU-T G.8032] Major Rings ). The protection scheme uses reserved MAC addresses for the ring controllers. All controllers on any specific ring have the same (reserved) MAC address. Part of the MAC address is the Ring ID. All controllers for any case of ring ID have the same MAC address and it is this MAC ring that essentially defines the boundary of an individual protection control domain. A single VID can be used to carry signalling (the R-APS VID) for multiple different rings (where each ring has a different ring IDs). Each traffic ring has one of more dedicated VIDs. Multiple traffic VIDs may be controlled by a single protection control domain.

The Controller controls a subset of the FCs passing through the NE (see Base Model in Figure XIV.3- 9 View of NE actively participating in two rings showing spec and encapsulation ). The blocking of the signalling is per MAC address whereas the blocking of traffic is per VID.

Signalling goes both clockwise and anticlockwise. Signalling traffic uses the normal multi-cast drop and continue forwarding behaviour.

In the ring node model shown in the figure below there is a clear split between VID termination and MAC termination to handle the different multiplicity (one VID and n MAC terminations).

Note that in an implementation the Control functionality may be shared between rings but in the model it is the logical function that is considered and from that perspective the control functions are completely separate/disjoint.

Figure XIV.3- 4 Basic model for a ring node

 

The model reflects the following key features

       Propagation of signalling is by drop and continue

        The effect in the Ring is that messages do not terminate and hence there is a signalling block

       The ring is defined by the RingId in the last byte of the MAC Address

       The signalling FC is at the VID scope and hence it is a filter [57] in the LTP not a switch in the FC that does the ring block

        The block on the signalling VID on a per MAC basis

        Not all rings using the same VID need to be blocked at the same node

        Not all rings using the same VID need to be co-routed

       The signalling VID block is constructed by provisioning MAC to propagate (the RingX signalling block is formed by not configuring the MAC address (this is a detail))

       The signal block and the traffic block are assumed to be at the same node for a ring (this appears to be a minor simplification).

       The traffic block could be represented as as switch in the FC or an attribute in the LTP

The figure below shows expanded detail in the LTPs that deals with signaling.

Figure XIV.3- 5 Detailed node model focusing on signal flow

In the figure above the FC supports the signalling information flow (i.e. it is no different to the traffic forwarding function).

The figure above shows a single C&SC. There would be a C&SC for each ring. The C&SC is a relatively complex function as shown in the figure below but dealing with the detail in the controller appears not relevant. In a future form that detail could (should) be laid out in a scheme spec (as it is invariant) such that in future a smart controller could interpret failure modes etc.

Figure XIV.3- 6 Detailed view of a control function from [ITU-T G.8032]

 

There are several different views of the ring control that can be derived from the protection model:

  • The raw functionality can be exposed per logical ring node as shown in Figure XIV.3- 5 Detailed node model focusing on signal flow
  • The functionality, VID through signalling traffic and all C&SCs related to the signalling VID can be encapsulated in a larger C&SC where that element would represent the control of all rings (see the figure below). This encapsulation obscures some details. For example;
    • If there is a ring that simply passes through the node then that Ring ID is not apparent other than via configuration of the C&SC ports.
    • Where there is an intermediate NE that does not engage in the protection scheme but does pass the signalling there would be a normal FC such that the representation is not uniform from NE to NE.
  • Both the control and the traffic VIDs could be encapsulated in a C&SC
    • The model supports this view as any VIDs for the FD can be allocated to the C&SC as the FCs are created. The traffic VIDs are not directly owned by the C&SC other than when the traffic FCs are created

Figure XIV.3- 7 Ring node represented by C&SC encapsulations

 

XIV.3.2 Relevant pieces of the resilience model for [ITU-T G.8032]

The figure below highlights the key classes and associations used to represent [ITU-T G.8032].

 

CoreModel diagram: Resilience-G.8032-Pattern

Figure XIV.3- 8 Resilience model structure for G.8032

XIV.3.3 Using the spec model to explain the alternative raw and encapsulation forms sodel to explain the alternative encapsulations functiin dividual protcetion basic nodaliption..rspective traffic

The [ITU-T G.8032] ring is can be defined by a scheme spec. In a full model the scheme spec mechanism would apply as shown below to represent the basic model, an encapsulation form and the relationship between the encapsulation form and the basic model.

Figure XIV.3- 9 View of NE actively participating in two rings showing spec and encapsulation

The "Base model" diagram shows an example layout, in an instance diagram form, of a single [ITU-T G.8032] node that is involved in two protected rings (R1 and R2).

The "Base scheme spec sketch…" diagram shows a detailed representation of the nodal aspects of the [ITU-T G.8032] protection scheme spec (see Annex G Core IM Specification for more details on scheme specs). The elements of the spec are created from the ONF CIM using the "Prune and Refactor" (P&R) approach. This supports the construction of several cases of any class from the model with corresponding associations from the ONF CIM. The spec is augmented with rules that constrain the creation of instances of entities of the scheme so as to abide by the scheme definition. For example, "no more than two ports per ring id" on the signaling FC.

The "C&SC Encapsulated…" diagram shows the results of a second P&R stage where the scheme spec is taken and embedded in a C&SC shell. This intermediate step provides an aspect of the mapping of the raw scheme to the "Abstracted C&SC spec". As the FCs and LTP cannot be embedded in the C&SC the model is somewhat of a hybrid but it allows the next step of construction.

The "Abstracted C&SC spec" diagram shows the results of a third P&R stage where the properties of the LTPs (including association ends) are merged into the corresponding C&SC ports as are the port properties of the FC and the FC itself (the FC itself has no relevant properties).

In this case the "Base scheme spec…" is further backed up by a more detailed set of specs for the C&SC for [ITU-T G.8032]. At this point the spec for [ITU-T G.8032] is not documented in a machine interpretable form. The longer term intention is that it would be machine interpretable. 

As a consequence of the above steps there is a formal path from the "Abstracted C&SC spec" to the definition of the detailed underlying mechanism. As a consequence the representation from an implementation that uses the "Abstract C&SC spec" form can be transformed in a running solution to a view that follows the "Base scheme spec.." using a machine interpretable definition of the transformation.

As the detailed set of specs are moved to machine interpretable forms an advanced controller will have the information to fully interpret the protection scheme and its data.

 

  Figure XIV.3- 10 Relationship between the two instance views shown via their related spec

The figure above shows the relationship between instance sketches and the corresponding specs and highlights the relationship between the specs.

The scheme specs and the rigorous relationship between those enable a controller to interpret and expand a compact form. If any other compact forms are chosen they should be rigorously related

XIV.3.4 Representing the block sodel to explain the alternative encapsulations functiin dividual protcetion basic nodaliption..rspective traffic

Figure XIV.3- 11 Applying the "blocks" to the ring

The CascPort supports both the sending of signaling through and/or application of control to the associated LTP and/or the gathering of monitoring information from the associated LTP. The controls can be applied directly to the associated LTP and/or indirectly to an appropriately deterministically related LTP peer or server to the associated LTP as described by the scheme spec and illustrated in the figure above. The same applies to the gathering of monitoring information.

Considering [ITU-T G.8032] protection as an example the control parameter related to the "isRelatedControlFlowDisabled" property of the port applies also to the indirectly related LTP dealing with the control signal and the "isControlledFcPortDisabled" property of the port applies specifically to the port of the controlled FC as explained by the scheme spec.

In addition the scheme spec will indicate whether the actual state of each individual controlled FC can be determined directly from the FC or whether only the aggregate state is available. Clearly the former may cause performance issues in an implementation if hundreds of FCs are controlled and switched together especially if notifications are sent for changes in every one independently.

XIV.3.5 Forming the ring sodel to explain the alternative encapsulations functiin dividual protcetion basic nodaliption..rspective traffic

The figure below shows an example of the protection scheme where there is only one ring set up (controllers and signaling) and there is no traffic applied to the ring. As noted previously the ring is emergent from the signaling and nodal control arrangement. The ring can be represented by a superior C&SC that groups the nodal C&SCs for the ring.

Figure XIV.3- 12 The basic [ITU-T G.8032] ring

Whilst in this simple case there also appears to be a control forwarding ring formed from the FCs, in more complex cases with various overlaid rings the control FC can become a complex structure where the VID is used by multiple rings that are not co-routed. This is because it is at the MAC level that the ring appears rather than at the VID level.

The following figure emphasizes the point as it shows two overlaid rings that are not co-routed. The figure could represent a deployment situation where protected private networks are being supported and two customers of the provider have private networks that happen to have some sites in common.

In this case there is no need to pass traffic between the two private networks. If traffic were to need to be passed traffic from the two rings could only be interconnected at one point to prevent loops. In this configuration there would be a single point of failure. To enable protection without a single point of failure an alternative configuration is constructed that uses Sub-Rings. Sub-Rings are shown in later figures.

 

 

Figure XIV.3- 13 Two overlaid [ITU-T G.8032] Major Rings showing signaling only

As can be seen from the figure the two rings share a single VID for signaling but are not co-routed. Ring 2 simply transits through NE D and NE E (there is no controller present that deals specifically with Ring 2 but the signaling VID is set up to allow Ring 2 MAC to pass).

Figure XIV.3- 14 Basic [ITU-T G.8032] Sub-Ring

The figure above shows a sub-ring configuration. As described earlier, the Sub-Ring closes protection through a Major Ring (or another Sub-Ring where the Sub-Ring configuration is attached to at least one Major Ring. A Major Ring may support many Sub-Rings.

The figure below shows a Major Ring with one protected Traffic VID between ports on NE A and NE E. In the figure the block is such that the traffic will flow via D.

Figure XIV.3- 15 Major Ring showing Traffic

The figure below shows a Sub-Ring and associated a Major Ring from a signaling perspective. As the figure only shows signaling the two rings appear to have no association.

Figure XIV.3- 16 Basic [ITU-T G.8032] Major Ring and Sub-Ring

The figure below shows a single traffic VID between ports on NE A and NE F. In NE B and NE E there are three-way FCs that provide a broadcast that enables the protection scheme. The figure shows the necessary traffic bocks in NE A and NE F. 

Figure XIV.3- 17 [ITU-T G.8032] Major Ring and Sub-Ring showing traffic

To reduce the clutter the figure below shows only the traffic.

 

 

Figure XIV.3- 18 [ITU-T G.8032] Major Ring and Sub-Ring showing only traffic

In the approach shown in the two figures above the FCs in NE B and NE E are partly controlled by C&SC 1 and partly controlled by C&SC 2. The figure below shows an alternative layout of traffic where there are dedicated FCs per control domain which are interconnected via a zero length link which is an artificial termination construct that represents the boundary of the control domains.

Figure XIV.3- 19 [ITU-T G.8032] Major Ring and Sub-Ring showing traffic with zero length link

A zero length link can be added per traffic VID. T

To reduce clutter the figure below shows only the traffic.

Figure XIV.3- 20 [ITU-T G.8032] Major Ring & Sub-Ring showing only traffic with zero length link

The approach using a zero length link adds complexity to the traffic path model but does allow a representation of control isolation.

The figure below show arrangements of rings in a mesh network. Each numbered Ring can use the same signalling VID so long as the Ring IDs are different for each Ring at an intersecting Node. In the example if the number is the ring ID then the VID can be the same. If the rings all have the same Ring ID then the number represents the VID.

Figure XIV.3- 21 [ITU-T G.8032] Major Rings in a mesh

 

 

More complex cases including those shown below, although not detailed here, are also covered by the model [58] .

  Figure XIV.3- 22 MEPs and R-APS insertion [ITU-T G.8032]

 

Figure XIV.3- 23 MEPs and R-APS insertion without R-APS virtual Channel [ITU-T G.8032]

In the figure above, it is not clear how the two Service_FF blocks are joined. This appears to be FC to FC (achievable with the current model), but there may be more complex behaviour that is implied by the figure. This requires further study.

XIV.4 Other protected ring schemes

This section details some other ring schemes. The following diagram key applies.

Figure XIV.4- 1 Diagram key

The figure below shows the basic network used to explain several ring based resilience schemes showing where a break will occur.

 

Figure XIV.4- 2 The network

  • The network technology [59] is such that there are 8 channels of capacity on each link where 4 channels are available for traffic and 4 for protection.
  • A single traffic signal could use just a single channel, could use two channels or could use all four channels
    • In the two channel case any available channels from the 4 can be used to make the capacity, i.e. the channels do not need to be adjacent
    • Different channels can be used on different links in the ring
    • Hence blocking is simply on capacity not channel
  • The signals are numbered 1-4 for the single channel signal  (B1) and 1-2 for the two channel signal  (B2)

XIV.4.1 Network Wrapping

XIV.4.1.1 The scheme

The figure below shows a view of the network wrapping scheme.

 

Figure XIV.4 6 - 3 The network showing wrapping

 

  • A signal is passing from port 3 node W to port 3 node Z
  • When a link Y-Z fails the traffic is routed back round the ring from the break on the corresponding protection capacity B2.P1
  • Traffic can be monitored at intermediate points
  • The following figures only show the 2 channel and 4 channel traffic (B2 and B4 respectively)
  • To simplify the figures:
    • The same channel is maintained throughout the ring for both normal path and protection such that B2.1 must use B2.P1
    • No extra traffic is shown
  • B1.n and B1.Pn is not shown. There is no B1 traffic in the ring
  • Somewhere in the cloud there is a B2.2 service and a B4.1 service that require protection hence in all NEs shown there will be a B2.P2 and B4.P1 opportunity enabled.
    • If there was no B2.2 connection anywhere in the ring the B2.P2 would not be required.
    • If there was no B4.1 connection anywhere in the ring B4.P1 would not be required.

XIV.4.1.2 The model applied

The following figures show the LTP and FC configurations for nodes in the ring under normal and failure condition.

Figure XIV.4- 4 Wrapping: NE X and NE Y (no failure in ring)

The figure above shows the configurations of NE X and Y with the switches set to normal position.  There is an actual FC allowing signal to flow between B2.1 on port 1 and B2.1 on port 2. There is potential for Signal to flow between B2.P1 on port 1 and B2.P1 on port 2 etc. and hence potential FCs are shown. Because B2.1 is used on port 1 then B4.1 cannot be used etc.

Figure XIV.4- 5 Wrapping: NE Z (no failure in ring)

The figure above shows the configurations of NE Z with the switches set to normal position.  There is an actual FC allowing signal to flow between B2.1 on port 1 and port 3 (in this case B2.1 on port 2 is not used). There is potential for Signal to flow between B2.P1 on port 1 and B2.P1 on port 2 etc. and hence potential FCs are shown.

Note that NE W has essentially the same configuration although port 2 is used for normal signal flow and the protection faces port 1 not port 2.

 

Figure XIV.4- 6 Wrapping: NE Y with failure on port 2

The figure above shows the configurations of NE Y with a failure on port 2 such that the switches on the left have been set to select B2.P1 on port 1.  The FC allows signal to flow between B2.1 on port 1 and B2.P1 on port 1 such that the signal is wrapped back to port 1. There is no longer a potential for Signal to flow between B2.P1 on port 1 and B2.P1 on port 2 as B2.P1 on port 1 is now used for protection and hence potential FCs are shown as not usable. Because B2.P1 is used on port 1, B4.P1 cannot be used on port 1 and hence the FC between B4.P1 on port 1 and B4.P1 on port 2 cannot be used. B4.P1 on port 2 could be used but there is no other use shown.

 

Figure XIV.4- 7 Wrapping: NE X with failure on NE Y port 2

The figure above shows the configurations of NE X for the failure on NE Y shown in the previous figure.  There is an actual FC allowing signal to flow between B2.1 on port 1 and B2.1 on port 2. There is now also an actual FC shown between B2.P1 on port 1 and B2.P1 on port 2 that carries the protection traffic due to the wrap in NE Y shown in the previous figure. This actual FC is allowed due to the switch positions in the FC between B2.1 on port 1 and B2.1 on port 2 which do NOT select the B2.P1 channels on port 1 and port 2. Because the of the B2.P1 usage on both port 2 and port 2 the B4.P1 FC and LTPs on both port 1 and port 2 cannot be used. The potential FC between B2.P2 on port 1 and B2.P2 on port 2 is still available. The assumption is that somewhere else in the ring B2.P2 is being used (otherwise there would be no need to commit the potential).

 

Figure XIV.4- 8 Wrapping: NE Z with failure on NE Y port 2

The figure above shows the case for NE Z where the port 3 signal is wrapped onto B2.P1 on port 2. The figure does not show a failure on port 1. The assumption here is that the failure is only detected in NE Y. The assumption is that the scheme does bidirectional switching. It is possible that signal can still flow from port 2 on NE Y to port 1 on NE Z but as the protection scheme is bidirectional it switches both directions of traffic and hence the unidirectionally viable link from NE Y to NE Z is not used.

NE W does not need to switch to protect the signal as NE Y and NE Z perform the protection function in this case. In general, for the wrapping scheme, the NEs either side of the failure perform the protection function.

XIV.4.2 Network Steering

XIV.4.2.1 The scheme

 

Figure XIV.4- 9 Network showing steering

  • A signal is passing from port 3 node X to port 3 node Z
  • When a link Y-Z fails the traffic is routed back round the ring from origin on corresponding protection capacity B2.P1
  • Traffic can be monitored at intermediate points
  • The following figures only show the 2 channel and 4 channel traffic (B2 and B4 respectively)

XIV.4.2.2 The model applied

The following figures show the LTP and FC configurations for nodes in the ring under normal and failure condition. The explanations for the figures is similar to that in the previous subsection and hence only differences have been highlighted.

 

Figure XIV.4- 10 Steering: NE Z (no failure in ring)

Essentially as for the wrapping case.

Figure XIV.4- 11 Steering: NE X (no failure in ring)

 

Figure XIV.4- 12 Steering: NE Y (no failure in ring)

Note that unlike the wrapping scheme, NE Y has no switching capability enabled, as in this scheme, switching is only performed at the entry points to the ring.

 

Figure XIV.4- 13 Steering: NE W (no failure in ring)

NE W does not participate in the main path of the signal.

Figure XIV.4- 14 Steering: NE Z with failure on NE Y port 2

The figure above is the same as for the wrapping case because the failure is between NE Y port 2 and NE Z port 1 and NE Z is also the entry point for the signal.

 

Figure XIV.4- 15 Steering: NE Y with failure on port 2 (same as no failure)

No change takes place in NE Y when the failure occurs as the responsibility to protect is at the NEs where the signal is applied to the protection scheme. For the wrapping scheme NE Y was involved in the protection.

 

Figure XIV.4- 16 Steering: NE X with failure on NE Y port 2

The figure above show the switching occurring at the point of entry of the signal to the scheme. There is no failure either side of NE X so in the wrapping scheme NE X would NOT switch.

Figure XIV.4- 17 Steering: NE W with failure on NE Y port 2

NE W enables signal to pass through supporting the new path resulting from the steering at NE X and NE Z.

 

XIV.4.3 The model in detail for both Steering and Wrapping

 

  • Three methods depending upon details of the actual scheme… FCs are
  1. "created" as potential and then activated when protection requires
    • The controller requests that particular FCs are changed from potential to actual (this potentially involves the controller communicating with all NEs when a protection/restoration action is required)
  1. not present until protection requires but are known to be potential through a specification
    • The controller coordinates the creation/deletion of FCs based upon the scheme description in the scheme spec. (this potentially involves the controller communicating with all NEs when a protection/restoration action is required)
  2. created as actual (rather than potential) with a switch disabling them and are switched on when protection requires
    • The controller requests the change of switch state
  3. The LTPs approach could be the same as the FC approach but there are some hybrids possible
    • The LTPs could be not present even if the FC is until selected by a switch
  • Regardless of the approach from the methods described, use one or more specs to explain what can exist and what needs to be created when to form the correct behaviour
    • The spec can remove the need to report/notify entities
  • A composite notification could be designed to inform of a complex configuration change if defined in a spec
  • Potential LTPs and FCs can be considered as "partially created" in that a query on the live system could return them as instances and when they become active this could be considered as a state change rather than a creation (as the rule is indeed known by the NE)
  • A hybrid (with a switch) of potential+off and actual+on could be considered
    • When an LTP is disabled it is potential and when enabled it is actual
    • When LTPs and FCs are gathered /notified, only enabled FCs and LTPs would be reported
  • States may be
    • Actual
    • Potential
    • Potential – disallowed
  • Creation v state change when spec is provided…
    • Seems that much of the CTP/FC would be known from the spec so a simple state change is all that is required
  • Spec could identify group notifications that indicate a change of state of many classes or a batch notification could be provided
  • Challenges: Potential misalignment between spec and reality
  • Note that the S&SC is really just a Controller

The actual state MUST be available, the question is how much potential should be reported and how much should be in the spec. The feeling at this point is that the potentials should NOT be reported other than via the spec.


Appendix XV

Application (L4 and above) examples

(This appendix does not form an integral part of this Recommendation.)

 

The content of this Appendix is for further study.

 

 

 

 

Bibliography

 

[b-Eclipse-Papyrus] Papyrus Eclipse UML Modelling Tool.
< https://www.eclipse.org/papyrus/ >

[b-IETF draft-lam] IETF draft-lam-teas-usage-info-model-net-topology-04 (2016) , Usage of IM for network topology to support TE topology YANG module development.

[b-IETF RFC 4122] IETF RFC 4122 (2005), A Universally Unique Identifier (UUID) URN Namespace .

[b-OASIS TOSCA] https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=tosca.

[b-ONF-TMF-MEF] MEF ONF TMF Collaboration Agreement (see https://login.opennetworking.org/bin/c5i?mid=38&rid=61&cid=3&k1=1567&tid=1483824677).

[b-ONF TR-512] ONF TR-512 (2015), Core Information Model (CoreModel) .

[b-ONF TR-513] ONF TR-513 (2016), Common Information Model: Overview .

[b-ONF TR-514] IISOMI 514 (2016), UML modeling guidelines.

[b-ONF TR-515] IISOMI 515 (2016), ONF Papyrus guidelines .

[b-ONF TR-521] ONF TR-521 (V1.1):: ONF SDN Architecture 1.1, February 2016 (https://3vf60mmveq1g8vzn48q2o71a-wpengine.netdna-ssl.com/wp-content/uploads/2014/10/TR-521_SDN_Architecture_issue_1.1.pdf) .

[b-ONF TS-025] ONF TS-025 (2015), OpenFlow switch specification , Version 1.5.1.

[b-OSSDN-EAGLE, 2017] Open source SDN.
< https://community.opensourcesdn.org/wg/EAGLE/dashboard >

[b-ONF/Snowmass] Open Networking Foundation/Snowmass ONFOpen Transport.
Repository for Open Transport API Project .
< https://github.com/OpenNetworkingFoundation/Snowmass-ONFOpenTransport >
         and Open Source SDN . < https://groups.opensourcesdn.org/wg/SNOWMASS/dashboard >

[b-ONF TAPI] ONF Transport API (see [b-ONF/Snowmass]) .

[b-TMF GB922] TM Forum GB922 (2017) Information framework (SID).

[b-TMF IG1118] TM Forum IG1118 OSS/BSS Futures – Architecture R15.5.1 .

[b-TMF MTOSI] TM Forum MTOSI (4.0), Multi-Technology OS Interface .

[b-TMF TR215] TM Forum TR215 (2014), Logical resource-network model advancements and insights.

[b-TMF TR225] TM Forum TR225 (2016), Logical resource: Network function model.

[b-TMF MTOSI] TM Forum MTOSI (4.0), Multi-Technology OS Interface .

[b-UML-YANG GUIDE] UML- YANG Mapping Guidelines https://community.opensourcesdn.org/wg/EAGLE/document/172 .

[b-UML-YANG TOOL] UML- YANG Mapping Tooling Navigate via https://github.com/OpenNetworkingFoundation/EAGLE-Open-Model-Profile-and-Tools .

[b-UUID, 2017] Universally_unique_identifier . < https://en.wikipedia.org/wiki/Universally_unique_identifier >

[b-Eclipse-Papyrus] Papyrus Eclipse UML Modelling Tool ( https://www.eclipse.org/papyrus/ )

[b-IISOMI-515] IISOMI-515_Papyrus-Guidelines.docx (https://community.opensourcesdn.org/wg/EAGLE/document/171)

 

 

 


ITU-T Y-SERIES RECOMMENDATIONS

GLOBAL INFORMATION INFRASTRUCTURE, INTERNET PROTOCOL ASPECTS, NEXT-GENERATION NETWORKS, INTERNET OF THINGS AND SMART CITIES

 

 

GLOBAL INFORMATION INFRASTRUCTURE

 

General

Y.100–Y.199

Services, applications and middleware

Y.200–Y.299

Network aspects

Y.300–Y.399

Interfaces and protocols

Y.400–Y.499

Numbering, addressing and naming

Y.500–Y.599

Operation, administration and maintenance

Y.600–Y.699

Security

Y.700–Y.799

Performances

Y.800–Y.899

INTERNET PROTOCOL ASPECTS

 

General

Y.1000–Y.1099

Services and applications

Y.1100–Y.1199

Architecture, access, network capabilities and resource management

Y.1200–Y.1299

Transport

Y.1300–Y.1399

Interworking

Y.1400–Y.1499

Quality of service and network performance

Y.1500–Y.1599

Signalling

Y.1600–Y.1699

Operation, administration and maintenance

Y.1700–Y.1799

Charging

Y.1800–Y.1899

IPTV over NGN

Y.1900–Y.1999

NEXT GENERATION NETWORKS

 

Frameworks and functional architecture models

Y.2000–Y.2099

Quality of Service and performance

Y.2100–Y.2199

Service aspects: Service capabilities and service architecture

Y.2200–Y.2249

Service aspects: Interoperability of services and networks in NGN

Y.2250–Y.2299

Enhancements to NGN

Y.2300–Y.2399

Network management

Y.2400–Y.2499

Network control architectures and protocols

Y.2500–Y.2599

Packet-based Networks

Y.2600–Y.2699

Security

Y.2700–Y.2799

Generalized mobility

Y.2800–Y.2899

Carrier grade open environment

Y.2900–Y.2999

FUTURE NETWORKS

Y.3000–Y.3499

CLOUD COMPUTING

Y.3500–Y.3999

INTERNET OF THINGS AND SMART CITIES AND COMMUNITIES

 

General

Y.4000–Y.4049

Definitions and terminologies

Y.4050–Y.4099

Requirements and use cases

Y.4100–Y.4249

Infrastructure, connectivity and networks

Y.4250–Y.4399

Frameworks, architectures and protocols

Y.4400–Y.4549

Services, applications, computation and data processing

Y.4550–Y.4699

Management, control and performance

Y.4700–Y.4799

Identification and security

Y.4800–Y.4899

Evaluation and assessment

Y.4900–Y.4999

 

 

For further details, please refer to the list of ITU-T Recommendations.

 

 


 

SERIES OF ITU-T RECOMMENDATIONS

Series A

Organization of the work of ITU-T

Series D

Tariff and accounting principles and international telecommunication/ICT economic and policy issues

Series E

Overall network operation, telephone service, service operation and human factors

Series F

Non-telephone telecommunication services

Series G

Transmission systems and media, digital systems and networks

Series H

Audiovisual and multimedia systems

Series I

Integrated services digital network

Series J

Cable networks and transmission of television, sound programme and other multimedia signals

Series K

Protection against interference

Series L

Environment and ICTs, climate change, e-waste, energy efficiency; construction, installation and protection of cables and other elements of outside plant

Series M

Telecommunication management, including TMN and network maintenance

Series N

Maintenance: international sound programme and television transmission circuits

Series O

Specifications of measuring equipment

Series P

Telephone transmission quality, telephone installations, local line networks

Series Q

Switching and signalling, and associated measurements and tests

Series R

Telegraph transmission

Series S

Telegraph services terminal equipment

Series T

Terminals for telematic services

Series U

Telegraph switching

Series V

Data communication over the telephone network

Series X

Data networks, open system communications and security

Series Y

Global information infrastructure, Internet protocol aspects, next-generation networks, Internet of Things and smart cities

Series Z

Languages and general software aspects for telecommunication systems

 

 

 


[1] The hypergraph was identified as similar in pattern to the multi-pointed forwarding leading to this rationalization of the model.

[2] Essentially this leads to decomposition to a perfect analogue gate. This argument has been cut short. There is a need to introduce a storage element and a consideration of non-linear behaviour etc. It seems 

[3] Again the argument has been cut short here. The hypergraph sets out adjacencies, these adjacencies are applied to cases where information is made available at one side of the adjacency for use at the other. The adjacency is not transparent and functions are applied to the information as it transitions the adjacency.

[4] Recognizes that management is control and that traditional boundaries drawn between EMS and OSS etc are not relevant architectural boundaries. The solution should be described n terms of a recursion of control.

[5] This is not simply the composite pattern as rules relate the parts and related their “ports” to the exposed “ports” of the encapsulating entity.

[6] UML seems lacking in this area.

[7] Generalized variable encapsulation requires further analysis.

[8] Modelling the development of Component-System to Transfer-Transform is for further study.

[9] It is important to distinguish between the digital layer that transfer information and the media layer that transfers signals (that may carry encoded information). It is possible to consider everything as simply information but there is a significant transition that takes place between the digital layers and the media that is best dealt with at this point by considering media as transferring signal.

[10] This is not an ideal term. The provider of the “payload” does not necessarily pay anything directly. The key is that the information of the payload is the thing to be carried and carrying the payload is the purpose of the network and by doing so it supports and achieves the desired outcome of the proximity service. An alternative term is workload.

[11] Consider especially an “ultimate payload”, i.e. the information that comes entirely from a source not related to construction of a telecommunications protocol such as a postal address directory).

[12] The signal transfer in these cases is at the subatomic level. This is clearly also a femto-scale system but that is not relevant here.

[13] Obviously further rationale for this could be set out but that is not relevant to the argument here and so it is assumed to be obvious why this is necessary.

[14] The term Forwarding and Transfer are synonymous in this context

[15] This will be explored further in later releases.

[16] This will be expanded in a later release.

[17] See especially Scheme Spec in Annex G .

[18] The current drive for SDN and virtualization give us an opportunity though to change the way of operating.

[19] Much of what is described in SDN/NFV as control appears already present in networks as Management. SDN/NFV control layer functions are mostly the same as functions in the OSS/NMS.

[20] Virtualization is not new but has been ad-hoc. Most of the functions of OSS/BSS environment are necessary even in the most virtualized and automated world.

[21] Existing divisions should be ignored so that to allow reconsideration of structure of the solution.

[22] Including all problem space semantics. Some aspects of the problem space are covered by other standards activities (the properties of particular transport protocols for example) and, as described, a method for federating activities has been developed so that the work of each body can be applied efficiently and coherently to an implementation.

[23] A particular level of encapsulation of semantics is used that has been developed over many years of practical experience. This reduces volume in implementations compared to an atomic form. The model takes full advantage of the patterns of networking such that one small set of entities cover ALL technologies without the need for network technology based subclassing specialization (i.e. the model is network technology agnostic).

[24] Each concept is represented once.

[25] Tooling is under agile development in the ONF-sponsored Open Source [b-OSSDN-EAGLE] project to ease the Pruning and Refactoring process.

[26] The current state of unnecessary variety of terminology that has emerged as a result of the various origins of what is now one piece of work needs to be accommodated. The methodology promotes the reduction of this variety over time (as machines do not benefit from the variety but instead run most efficiently using the patterns).

[27] Includes Core Model and Profiles

[28] It was concluded that it was not helpful to indicate media change. The key information relates to domain change. In detail, there are at least four media here and probably more. Fiber to p-type to n-type to copper. This complexity does not add value.

[29] The structures shown here and throughout this document need to be described in LTP and FC specs (see Annex G. The actual spec forms will be developed in the next release.

[30] This model will potentially need enhancement when SD FEC (Soft Decision Forward Error Correction) is included.

[31] Network Domain Channel is used in this document to define the “end to end” span of potentially mixed media that can carry a signal of a particular domain. For example, it is defined from the point at which electrons are converted to (modulated) photons to the point where the information carried by the photons is converted to electrons. The term Network Media Channel is not used in this document. An NMC is an MC that spans from the output of a laser to the input of a photo diode. It is potentially mixed media. The MCY and MCZ in the diagram are essentially Network Media Channels. This designation is not helpful in understanding the model or the application. 

[33] Sufficient detail is required in the spec of the amplifier to allow interpretation of the detected conditions. The detail will in part depend upon the FRU structure of the amplifier. The model approach is intended to be suitable for use by the controller that interfaces directly to the optical components, i.e. where there is no lower level controller abstraction and/or analyzing/interpreting the detectors.

 

[34] An ME larger than an FRU is not ideal as the FRU is the key granularity for field replacement. If an ME is deemed to have failed all FRUs that it is built from will need to be replaced. The ME appears to not include the control functionality. This is not a useful management/control construct.

[35] For normal maintenance physical ports must be visible on the FRUs.  The recursive ME not remove the need for full visibility of FRUs.

[36] Back to back FCs can be used were there is no exposed physical boundary. An FD or CD will be necessary to bound MEs where the ME boundary is not coincident with a physical port. BUT if not coincident with a physical port it is not clear how the ME can be useful wrt field replaceability. The opaqueness may also make the ME not useful.

[37] This appears to be too large a unit for useful management/control.

[38] Note that for management purposes some "parasitic" parameters e.g reverse loss in an isolator may not need to be represented.

[39] As noted earlier the NMC is not a useful concept.

[40] A media channel has a contiguous spectrum. A media link can represent a set of one or more media channels where the spectrum is not contiguous. An example of this is a media link that represents a chain of c-band and l-band amplifiers. This would have two media channels and the spectrum “between” the c-band and l-band media channels is not supported by a media channel.

[41] Further examples will be added that illustrate devices with multiple layers of flexibility.

[42] This symmetry may be due to a device limitation or may be coincidental. To determine which the specs for the device could be inspected. See Annex G for details on FD specs.

[43] NE sync status has not been fully covered in this release.

[44] Here we will use the term ‘device’ in a loose and undefined manner to aid in the discussion. The term is not defined because it is not important for our discussion, the generally understood concept is sufficient

[45] http://www.cse.wustl.edu/~jain/cse570-13/ Multi-Tenant Isolation and Network Virtualization in Cloud Data Centers, slide 4

[46] http://www.cse.wustl.edu/~jain/cse570-13/ Multi-Tenant Isolation and Network Virtualization in Cloud Data Centers, slide 4

[47] Deeper examples that show the relationship to the general control model will be added in a later release.

[48] ErpInstance is a [ITU-T G.8032] term and shouldn't be confused with model class instances

[49] Many of the examples in this appendix were in Annex E.

[50] Note that there is work in progress to develop scheme specs that will provide a rule based view of the scheme.

[51] This recognition of levels of control from the most basis local two state switch controller through the various levels shown here and on two ring controllers and the SDN controller peer-hierarchy is a manifestation of and a validation of the concept of the Management-Control Continuum. Representation of the Management-Control Continuum will be further explored in the next release.

[52] This pattern of “decomposition” of the FC into two parallel FCs is also used when the FC is representing a Control Plane Call and when there is a need to combine two unidirectional FCs into a bidirectional FC. In these cases the decomposition takes place via the FcHasLowerLevelFcs association and the FCs are members of an FD via the FdContainsFc association.

[53] Note that this association is Experimental

[54] The term “Worker” means normal path for particular traffic

[55] At a later point this will be clarified and the C&SCs that are relevant for control will be highlighted. The scheme spec will define which C&SCs are the target for commands etc

[56] This recognition of levels of control from the most basis local two state switch controller through the various levels shown here and on two ring controllers and the SDN controller peer-hierarchy is a manifestation of and a validation of the concept of the Management-Control Continuum. Representation of the Management-Control Continuum will be further explored in the next release.

[57] A filter in the LTP is essentially a switch in an FC encapsulated in the LTP

[58] Further work will be carried out in a later release to show these and other more complex cases in detail.

[59] This is not a real network technology. It has been contrived to make the case easier to express.